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 52: Policy algorithm gets required intents from what interfacesdefinitions/declarations? - Proposal



NB  ** This proposal is also intended as a proposal to resolve Issue 55 **

This proposal is based on sca-policy-1.1-spec-wd-06.doc


---------------------------------------------------

Proposal 1)  Add a new section "4.7 Intents on Interfaces" following line 971
(text below)

Proposal 2) Modify line 1179 (section 4.10) to read:

"2. Add intents found in any related interface definition or declaration, as described in
4.7 Intents on Interfaces"

Proposal 3) Add the following after line 825:

Implementation intents are calculated before the structural intents.  In other words, Rule 2 is applied BEFORE Rule 1, where
there are intents present in both hierarchies.


Proposal 4) Add the following after line 826:

Note that each of the elements in the hierarchy below a <component> element, such as <service/>, <reference/> or <binding/>,
inherits intents from the equivalent elements in the componentType of the implementation used by the component.  So the
<service/> element of the <component> inherits any intents on the <service/> element with the same name in the <componentType>
- and a <binding/> element under the service in the component inherits any intents on the <binding/> element of the service (with
the same name) in the componentType.  Errors caused by mutually exclusive intents appearing on elements in the
component and on those in the componentType only occur when those elements match one-to-one.  Mutually exclusive intents
can validly occur on elements that are at different levels in the structural hierarchy (as defined in Rule 1).

Note that it may often be the case that <binding/> elements will be specified in the structure under the <component/> element in
the composite file (especially at the Domain level, where final deployment configuration is applied) - these elements may have no
corresponding elements defined in the componentType structure.  In this situation, the <binding/> elements don't acquire any
intents from the componentType directly (ie there are no elements in the implementation hierarchy of the <binding/> elements),
but those <binding/> elements will acquire intents "flowing down" their structural hierarchy as defined in Rule 1 - so, for example
if the <service/> element is marked with @requires="confidentiality", the bindings of that service will all inherit that intent, assuming
that they don't have their own exclusive intents specified.

Also, for example, where say a component <service.../> element has an intent that
is mutually exclusive with an intent in the componentType<service.../> element with the same name, it is an error, but this differs
when compared with the case of the <component.../> element having an intent that is mutually exclusive with an intent on the
componentType <service/> element - because they are at different structural levels: the intent on the <component/> is ignored
for that <service/> element and there is no error.

-------------------------------------------------------
Wording for the new section 4.7:

4.7 Intents on Interfaces

Interfaces are used in association with SCA services and references.  These interfaces can be declared in SCA composite files
and also in SCA componentType files.  The interfaces can be defined using a number of different interface definition languages
which include WSDL, Java interfaces and C++ header files.  

It is possible for some interfaces to be referenced from an implementation rather than directly from any SCA files.  An example of
this usage is a Java implementation class file that has a reference declared that in turn uses a Java interface defined separately.
When this occurs, the interface definition is treated from an SCA perspective as part of the componentType of the implementation,
logically being part of the declaration of the related service or reference element.

Both the declaration of interfaces in SCA and also the definitions of interfaces MAY carry policy-related information.  In particular,
both the declarations and the definitions can have either intents attached to them, or policySets attached to them - or both.
For SCA declarations, the intents and policySets always apply to the whole of the interface (ie all operations and all messages
within each operation).  For interface definitions, intents and policySets can apply to the whole interface or they may apply only
to specific operations within the interface or they may even apply only to specific messages within particular operations. (To
see how this is done, refer to the places in the SCA specifications that deal with the relevant interface definition language)

This means, in effect, that there are 4 places which can hold policy related information for interfaces:
1. The interface definition file that is referenced from the component type.
2. The interface declaration for a service in the component type
3. The interface definition file that is referenced from the component declaration in a composite
4. The interface declaration within a component

When calculating the set of intents and set of policySets which apply to either a service element or to a reference element of a
component, intents and policySets from the interface definition and from the interface declaration(s) are combined together,
before being combined with intents and policySets applied to the service or reference element and the binding element(s)
belonging to those elements.

For the intents, the locations defined above are part of the implementation hierarchy as defined in "Section 4.2 4.2        Usage of
@requires attribute for specifying intents" and they obey Rule 2 defined in that section, where location "1" is lower in the
hierarchy than location "2" (and so on).  



---------------------------------------------------


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]