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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Policy" <sca-policy@lists.oasis-open.org>
- Date: Mon, 7 Jul 2008 16:46:14 +0100
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]