[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-14) Policy Language(s)
[ http://tools.oasis-open.org/issues/browse/TOSCA-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30061#action_30061 ]
Frank Leymann commented on TOSCA-14:
-------------------------------------
Let me try to clarify terminology just to make sure that we do not miscommunicate: A "policy language" is a metamodel and related rendering to specify non-functional properties. A "policy" is a concrete expression of capabilities or requirements or behavior wrt non-functional properties. Known policy languages are KAoS or WS-Policy, for example. Policies expressed using WS-Policy are available for securtiy, transaction processing, reliable messaging and so on.
Thus, the question is of course not (!) whether or not we should agree on a collection of policies. The question is whether or not to agree on a set of policy languages that domain users can use to specify policies understood by a TOSCA environment.
If we decide not to agree on a set of policy languages, then a TOSCA environment may (must?) reject a service definition during its import because the environment will not be able to process a policy expressed in a policy language not supported in the environment. This will restrict portability from the outset. If this is fine with the TC, so be it. But it should be a concious decision.
As I said during the last TC call, a grouping concept based on an attachment mechanism can easily be specified in such a manner that it is independent from WS-Policy. All that is needed it to use the TOSCA <Policy> element instead of the <wsp:Policy> element in the attachement mechanism sketched in the document submitted on TOSCA-3.
This will have impact on the current spec because we need a means to allow specifying policies as first class citizen for (i) easy reference from an attachment, and for (ii) modularity of service definitions (i.e. reuse of policies across service templates). Furthermore, the elements that have nested policies in TOSCA today must be modified to refer to those first class citizens, i.e. to globally defined or imported <Policy> elements.
> Policy Language(s)
> ------------------
>
> Key: TOSCA-14
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-14
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Sub-task
> Components: Spec
> Reporter: Frank Leymann
>
> During review of the proposal to resolve issue TOSCA-3 a discussion about policy languages came up. See the following meeting notices:
> http://www.oasis-open.org/apps/org/workgroup/tosca/download.php/45574
> Some TC members felt that a strong tie to WS-Policy is not appropriate. There are other approaches to define policies that are relevant for particular domains. Thus, this sub-task should review such other approaches and propose how to define policies in TOSCA. Alternatives might be (i) to support multiple approaches, or (ii) to invent a new TOSCA policy language that abstracts the policy approaches considered to be relevant for TOSCA.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]