We have no current distinction between
implementation intents and interaction intents. If that doesn’t help,
assume that they are implementation intents that may apply to bindings (which I
think you agree is possible).
Michael
From: Mike
Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, February 12, 2008
4:32 PM
To: OASIS Policy
Subject: RE: [sca-policy] ISSUE 38
- Improve description of the overides available to the two different
hierarchies in SCA: Proposal, Updated
Michael,
I
see the point you're making - but how come an implementation intent applies to
<implementation.composite/>
in
one place and then somehow leaps to attach itself to <service/> in
another place?
Rule
3 is all about implementation intents. Deliberately so. Without it, there
is no way in which a using
component
can influence the intents that apply to implementations within the composite
used as an
implementation.
In
your example, which are i4 and i6 - implementation or interaction?
Or
is there something a lot deeper here that I've missed?
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
"Michael
Rowley" <mrowley@bea.com>
12/02/2008 21:13
|
To
|
Mike Edwards/UK/IBM@IBMGB, "OASIS
Policy" <sca-policy@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [sca-policy] ISSUE 38 - Improve description
of the overides available to the two different hierarchies in SCA:
Proposal, Updated
|
|
I’m concerned about this new rule 3:
Rule 3: For a composite used as an implementation by a higher-level component,
if the higher level component applies implementation intents to the composite,
those intents act as if they are attached to the <composite/> element and
are applied to components contained within the composite as defined by Rule 1
for the structural hierarchy.
I believe that you may end up having intents that were meant
to be defaults looping back and turning into strict requirements.
I hope the following example will illustrate.
I’ll start with the higher composite in the implementation
hierarchy (I removed some things that don’t apply to my case):
<composite
name="C2" requires="i4"
xmlns:foo=”http://foo”>
<component name="Y">
<implementation.composite name="foo:C1"/>
<service name="S" requires="i6">
</component>
</composite>
Imagine that i4 and i6 are mutually exclusive.
According to the structural hierarchy, this should be OK, and i6 will
override i4.
However, i4 will also be pushed down into the
“foo:C1” composite, as if it had written:
<composite
name="C1" requires="i4"
targetNamespace=”http://foo”>
<service name="S" promotes="X/S">
<binding.ws>
</service>
<component name="X">
<implementation.java class="foo"/>
<service name="S">
</component>
</composite>
The structural inheritance will then push that i4 down to the
service, as if it had said:
<service name="S" promotes="X/S"
requires=”i4”>
This means that the implied component type of C1 will have a
service with @requires=”i4”.
Finally, due to Rule 2, the @requires=”i4” of the
C1’s component type will conflict with the service line in C2:
<service name="S"
requires="i6"> -- conflicts with the “i4” that
came up from the component type
Do you see the problem?
Michael
From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, February 12, 2008 6:30 AM
To: OASIS Policy
Subject: [sca-policy] ISSUE 38 - Improve description of the overides
available to the two different hierarchies in SCA: Proposal, Updated
Folks,
Here is an updated version of the proposal for Issue 38:
Comments welcome.
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
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