Greg Dritschler (JIRA) wrote:
Support for mutually-exclusive intents
--------------------------------------
Key: TUSCANY-2239
URL: https://issues.apache.org/jira/browse/TUSCANY-2239
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Core Runtime
Reporter: Greg Dritschler
The SCA Policy specification does not provide a means to define intents which
are mutually exclusive. This is a noticeable omission when considering the
intents in the SCA Transaction specification which are mutually exclusive by
nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs.
suspendsTransaction). There is a need to be able to define intents which are
mutually exclusive and for the exclusion to be checked by the SCA runtime to
avoid the error of specifying exclusive intents on a single artifact. In
addition, there should be rules defined for the handling of mutually exclusive
intents which are attached at different levels of a composite or a hierarchy of
composites.
I have attached a patch to provide the capability to define mutually exclusive
intents. This is achieved using a new @excludes attribute on the <intent/>
element in definitions.xml. For example:
<intent name="propagatesTransaction" constrains="implementation"
excludes="suspendsTransaction"/>
@excludes is a list of intents which are mutually-exclusive with the named
intent. In order to be effective, a reciprocal definition needs to be made as
shown below.
<intent name="suspendsTransaction" constrains="implementation"
excludes="propagatesTransaction"/>
The patch makes no assumptions about the relationship of qualified intents to
the base intent. Therefore exclusive relationships between qualified intents
need to be spelled out.
<intent name="noManagedTransaction" constrains="implementation"
excludes="managedTransaction managedTransaction.global
managedTransaction.local"/>
A key part of the patch is that there now are two types of intent inheritance with
respect to exclusive intents. There is a "default" inheritance between certain
hierarchical elements within a composite. For example consider this snippet from a
composite:
<component name="C1" requires="propagatesTransaction">
<reference name="r1"/>
<reference name="r2"/>
<reference name="r3" requires="suspendsTransaction"/>
</component>
In this case the first two references inherit the default intent "propagatesTransaction"
from the component element. However the third reference does not inherit it because it specifies
an exclusive intent "suspendsTransaction" which overrides the component-level default.
The second type of inheritance is used when inheriting intents from an
implementation (e.g. introspected Java code, or an implementation composite).
In this case the intents of the implementation cannot be overridden. Consider
this example:
<component name="D1">
<implementation.composite name="CZ1"/>
<reference name="r1" requires="suspendsTransaction"/>
</component>
Let's assume CZ1 contains the component C1 shown earlier and that it promotes the
component reference C1/r1 as r1. C1/r1 has the intent "propagatesTransaction".
This intent is considered a requirement of the implementation and it cannot be
overridden by the using composite. Therefore D1 is in error.
Folks,
I would like to make everyone aware that the OASIS Policy TC have been
working on the topic of mutually exclusive intents and there is both a
formal Issue and an agreed resolution to that issue.
The related topic of inheritance of intents has also received the same
treatment!
The issues concerned are:
a) Issue 39 Need Support for Mutually exclusive intents
http://www.osoa.org/jira/browse/POLICY-39
The agreed resolution is on the page linked above.
It is very close to the solution expressed above, but it does deal with
qualified intents in detail.
b) Issue 38 Improve description of the overides available to the two
different hierarchies in SCA
http://www.osoa.org/jira/browse/POLICY-38
This is a comprehensive description of how intents are inherited by a
given element in SCA - both from the surrounding SCDL and also from any
implementations that are being used.
The full resolution text is attached to the following email:
http://lists.oasis-open.org/archives/sca-policy/200804/msg00018.html
...this is actually a complete updated version of the Policy
specification with change markings.
Hope this clarifies things,
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
