Uploaded image for project: 'OASIS Cloud Application Management for Platforms (CAMP) TC'
  1. OASIS Cloud Application Management for Platforms (CAMP) TC
  2. CAMP-169

CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Applied
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Primer
    • Labels:
      None

      Description

      https://lists.oasis-open.org/archives/camp-comment/201402/msg00001.html

      Hi Adrian,

      Recently I got a chance to take a look at CAMP working draft 39 (dated February 3, 2014).

      I was specifically looking to see how the issue filed here
      https://tools.oasis-open.org/issues/browse/CAMP-153
      has been resolved.

      Upon reading through the comments on the issue, I am not sure I agree to the
      justification given to keep two different service specification formats.

      If I understand the justification correctly, it is saying that
      the 'in-line' format of service specification is useful for the use case when multiple artifacts don't
      want to share services. In such situations, the required services can be specified
      'in-line' with each artifact, whereas, if multiple artifacts need to share a service (same instance of it) then such a
      service specification should be defined in the services section.

      I still think that one could achieve both these use cases by having a single
      way of defining required services in a separate top-level services section.

      Having two different formats will lead to model interpreter complexity
      without providing significant gain.

      If, however, the TC wants to keep two different formats then one suggestion that I would like to make
      is to enforce the distinction through the specification.
      Currently the 'in-line' format is still exactly same as the 'out-of-line' format,
      the specification does not explicitly restrict/enforce when to use one over the other.
      One way to enforce this would be to remove the 'id' field from the 'in-line' definition of a service.
      That way, it won't even be possible to reference an in-line defined service from outside
      the defining artifact's scope. (to be concrete: remove 'id' from being a child of 'fulfillment' node
      on line 14 of page 31).

      In case this is not an option then another suggestion would be to at least explicitly call out
      in the specification the need for providing two different ways to specify services and to suggest when
      one format should be used over the other.

      Regards,
      Devdatta

        Attachments

          Activity

            People

            • Assignee:
              gilbert.pilz Gilbert Pilz
              Reporter:
              martin.chapman Martin Chapman
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: