OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ISSUE 43: Updated Proposal



Folks,

Following from last week's TC meeting, I got an action item to prepare revised proposal wording for Issue 43
(Action 20080512-01):

I decided on a very different approach to the words and their location in the document.  Rather than
messing about with the algoritm in section 4.10, I decided to deal with the component type information
in section 4.6....

The following is based on the Policy spec as in:  sca-policy-1.1-spec-cd-01_Issue38_Proposal.doc

It is a replacement of the Section 4.6:


Intents and PolicySets on Implementations and Component Types

It is possible to specify required intents and policySets within a component’s implementation,
which get exposed to SCA through the corresponding component type. How the intents or
policies are specified within an implementation depends on the implementation technology.
For example, Java can use the @requires annotation to specify intents.  It is also possible
to define an implementation's componentType using a component type file - and intents
and policySets can be specified in the component type file.

The required intents and policySets specified within an implementation can be found on the
<sca:implementation.*> and the <sca:service> and <sca:reference> elements of the component
type, for example:

<omponentType>
<implementation.* requires="listOfQNames"
policySets="="listOfQNames">
 ...
</implementation>
<service name="myService" requires="listOfQNames"
policySets="listOfQNames">
 ...
</service>
<reference name="myReference" requires="listOfQNames"
policySets="="listOfQNames">
 ...
</reference>

</componentType>

Intents expressed in the component type are handled according to the rule defined for the
implementation hierarchy. Where a component in a composite uses an implementation,
intents attached to elements of the component type are carried across to the equivalent
subelements of the component, and are treated as if they are attached there. If the
component subelement has a mutually exclusive intent already attached to it, this is
an error and the SCA runtime MUST raise an exception.

So, for example, if the implementation has a component type with the "confidentiality" intent
applied to its <reference name="foo"/> element, the component's <reference name="foo"/>
element is treated as if @requires="confidentiality" is applied to it.

PolicySets may also be attached to elements of the component type.  Where a policySet is
attached to an element of the component type, it is carried across to the equivalent
subelement of the component and is treated as if it is attached there.  For explicitly listed
policySets, the list in the component using the implementation may override
policySets from the component type. More precisely, a policySet on the componentType is
considered to be overridden, and is not used, if it has a @provides list that includes an intent
that is also listed in any component policySet @provides list.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]