sca-policy message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ISSUE 43: Updated Proposal
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Mon, 19 May 2008 15:58:33 +0100
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]