[OASIS Issue Tracker] Commented: (CAMP-153) Two approaches to identify services in a DP?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36377#action_36377 ] 

Gilbert Pilz commented on CAMP-153:
-----------------------------------

I'm not sure if I agree that services "should" be a first class entity in a Plan. Keep in mind that the ServiceSpecifications in a Plan are not a complete description of the service but rather an outline of the characteristics that are important to that application. The meaning is "find a service that matches all (or at least some) of these characteristics" *not* "create a service with these characteristics".

That being said, I prefer to minimize the number of ways to support a set of use cases if there is no compelling reason for multiple solutions.

> Two approaches to identify services in a DP?
> --------------------------------------------
>
>                 Key: CAMP-153
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-153
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>         Environment: CAMP Version 1.1 Draft 32 (dated: 5 December 2013).
>            Reporter: Martin Chapman 
>            Assignee: Adrian Otto
>            Priority: Minor
>
> This is 2) from https://lists.oasis-open.org/archives/camp-comment/201312/msg00000.html
> "
> 2) Is there a reason why there should be two approaches to identify services in a DP?
> Example 4 in Section 4.2.2.1 demonstrates one approach. In this the "service" section
> is not explicitly called out. It is defined under the "fulfillment" section which 
> is hidden under the "RequirementType" relation.
> Example 5 demonstrates second approach. In this the "services" section is explicitly called out.
> I feel that services should be a first class entity of a DP, and providing an abstraction to
> explicitly identify them would make that status clear. Therefore, approach shown in example 5
> is better than that in example 4, imo. Is there any reason to keep both approaches?
> If not, can the spec be prescriptive about one approach (my vote is for approach in example 5)."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira