[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] JAVA-98: Simplified proposed direction for resolution
Dave,
See responses inline.
Simon
David Booz wrote:
> Thanks Simon, more below.
>
> I'm really starting to dislike the use of impl classes as service
> interfaces.
>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>
> Simon Nash <oasis@cjnash.com> wrote on 04/08/2009 10:42:29 AM:
>
> > [image removed]
> >
> > Re: [sca-j] JAVA-98: Simplified proposed direction for resolution
> >
> > Simon Nash
> >
> > to:
> >
> > 04/08/2009 10:45 AM
> >
> > Cc:
> >
> > sca-j
> >
> > Dave,
> > Thanks for the quick review and comments. See comments inline.
> >
> > Simon
> >
> > David Booz wrote:
> > > See below please.
> > >
> > > Dave Booz
> > > STSM, BPM and SCA Architecture
> > > Co-Chair OASIS SCA-Policy TC and SCA-J TC
> > > "Distributed objects first, then world hunger"
> > > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> > > e-mail:booz@us.ibm.com
> > >
> > > Simon Nash <oasis@cjnash.com> wrote on 04/07/2009 06:39:36 PM:
> > >
> > > > [image removed]
> > > >
> > > > [sca-j] JAVA-98: Simplified proposed direction for resolution
> > > >
> > > > Simon Nash
> > > >
> > > > to:
> > > >
> > > > OASIS Java
> > > >
> > > > 04/07/2009 06:40 PM
> > > >
> > > > Here is a simplified version of the proposal with the following
> changes
> > > > from the previous proposal:
> > > > 1. Disallow intents on implementation methods.
> > > > 2. Allow implementation intents on interface methods and
> interfaces.
> > > >
> > > > A) Specific intent annotations can appear together with @Requires
> > > > on the same Java program element. If they do, the annotations
> > > > contributed by specific intent annotations are merged with those
> > > > contributed by @Requires, following the policy rules for merging
> > > > intents at the same hierarchy level.
> > > >
> > > > Intents can be applied to a Java class or Java interface used as
> > > > an SCA service interface, a method of a Java class or Java
> interface
> > > > used as an SCA service interface, a Java class used as an
> > > > SCA service implementation, a Java reference, a Java
> interface for
> > > > a reference, or a method of a Java interface for a
> reference. It is
> > > > an error to apply an intent to a method of a Java class not
> used as
> > > > an SCA service interface.
> > >
> > > So then is the following legal? I thought we were disallowing intents
> > > on implementation methods, but your words above seem to allow this
> case.
> > >
> > > <component name="TestClient">
> > > <implementation.java class="test.ASM_0002_Client"/>
> > > <service name="TestInvocation">
> > > <interface.java interface="test.ASM_0002_Client"/>
> > > </service>
> > > </component>
> > >
> > > package test;
> > > public class ASM_0002_Client {
> > > @Confidentiality
> > > public void method1(int x) {}
> > > }
> > >
> > This component definition is not a valid configuration of the
> > specified implementation class, because it specifies a service
> > TestInvocation that does not appear in the Java implementation
> > or the introspected componentType.
> >
> > On the assumption that you intended the component service name
> > to be ASM_0002_Client, not TestInvocation....
>
> Yes, my bad. You're assumption is correct.
>
> >
> > This is an annotation on an interface method, because the Java class
> > ASM_0002_Client is being used as an SCA service interface. There is
> > no problem with allowing this, because it doesn't introduce the
> > need for merging intents between implementation methods and
> > interface methods, and it doesn't lead to the need to create
> > synthetic interfaces. The introspected componentType is simply:
> >
> > <componentType>
> > <service name="ASM_0002_Client">
> > <interface.java interface="test.ASM_0002_Client"/>
> > </service>
> > </componentType>
>
> Ok, then we need to clarify the words when they get put into a
> formal proposal, because they are contradictory right now.
>
I don't see the contradiction. I said:
Intents can be applied to a Java class or Java interface used as
an SCA service interface, a **method of a Java class** or Java interface
**used as an SCA service interface**, a Java class used as an
SCA service implementation, a Java reference, a Java interface for
a reference, or a method of a Java interface for a reference. It is
an error to apply an intent to a **method of a Java class not used as
an SCA service interface**.
The ** notations highlight the case we are discussing. Intents are
allowed on a method of a Java class used as an SCA service interface.
They are not allowed on a method of a Java class not used as an
SCA service interface. There is no contradiction or inconsistency.
The
> goal you're really trying to achieve is the absence of conflicting
> intent attachments by multiple levels in the hierarchy. I came away
> from the call with the impression that we were eliminating intents on
> impl classes, which you've shown clearly is not the case.
>
My recollection was that the proposed simplification was to remove
intents from implementation methods (not classes) while still
allowing them on interface methods. This leaves the implementation-
as-interface case debatable, but I don't see any problem with
allowing it.
> >
> > > >
> > > > B) The effective intents for a method of an SCA interface defined by
> > > > <interface.java> are computed by the following algorithm:
> > > > 1. Use the rules in A) above to find the intents for the method
> > >
> > > I see where this is specified in A).
> > >
> > > > and the intents for its declaring class or interface.
> > >
> > > I don't see where this is specified in A). The only thing A) talks
> > > about is what to do for same method attachment.
> > >
> > The first paragraph of A) talks generically about merging different
> > intent annotations on the same Java program element. This description
> > applies equally to program elements that are classes, interfaces,
> > methods, references or constructor parameters.
>
> Ok, so then step 1 is simply to normalize the list of intents which are
> attached to any given Java program element, and indirectly this is how
> you are handling MUX and qualified intents.
>
Yes, we agreed not to repeat the Policy words saying how these cases are
handled when merging at the same hierarchy level. That discussion might
have been on the call that you were not able to attend.
> >
> > > > 2. Use the policy rules for merging intents within a structural
> > > > hierarchy to merge the intents found in step 1 above,
> with the
> > > > method at the lower level and the method's declaring class or
> > > > interface at the higher level.
> > >
> > > I'm just not following this....what is a method at the lower level?
> > > I thought B) was resolving intents at the interface level esp. since
> > > intents can't be attached to implementation methods. An example
> > > might help me.
> > >
> > Suppose there are two mutually exclusive intents @Foo and @Bar.
> > Consider the following interface:
> >
> > @Foo
> > public interface MyFoo {
> > public void method1();
> > @Bar
> > public void method2();
> > }
> >
> > The merged intents are @Foo for method1() and @Bar for method2().
> > The policy hierarchy is
> > interface MyFoo
> > method method1
> > method method2
> > with MyFoo at the higher level and method1 and method2 at the
> > lower level underneath MyFoo. An intent at a lower level causes
> > any mutually exclusive intents at a higher level to be ignored,
> > so the presence of @Bar on method2() causes @Foo to be ignored
> > when computing which intents apply to method2().
>
> ok, intents are merged downward from class level to method level, again
> taking account for MUX and qualified intents as per structural hierarchy
> rules in policy spec.
>
We also agreed not to repeat the Policy words saying how these cases
are handled when merging different levels in a hierarchy. That discussion
might have been on the call that you were not able to attend.
> Inheritance is off the table entirely so the structural hierarchy is
> the only one we have to deal with.
>
That's correct as far as step B) is concerned. The implementation
hierarchy does come into play as part of step C).
> >
> > > > These rules are applied to the methods of a Java implementation
> > > > class or Java interface used to define an SCA service interface,
> > > > and to the methods of the Java interface for a reference.
> > > >
> > > > C) The effective intents for each method of an SCA service are
> computed
> > > > by applying the rules in the Policy specification to the
> intropected
> > > > component type implied by the rules in D) below, using the
> effective
> > > > intent computation rules in B) above.
> > > >
> > > > D) The componentType introspection rules for intents are as follows:
> > > > 1. Intents on the service implementation class are placed on the
> > > > <implementation.java> element in the componentType.
> > >
> > > Do you mean class level attached intents?
> > >
> > Yes, these are the intents attached directly to the Java implementation
> > class for the SCA service. I can reword this to make it clearer and/or
> > show an example.
>
> Step B) merged the class level intents downward so how are there any
> remaining at the class level to be considered?
>
The problem here is that in the implementation-as-interface case, it
isn't clear whether implementation intents on the implementation
class should be applied to the implementation in the componentType or
applied to the SCA service and its interface by doing the step B) merge
with intents on interface methods. Given that implementation intents
can apply to interface methods, I didn't want to rule out the possibility
that implementation intents on an implementation-as-interface can apply
to the interface and participate in the step B) merging.
Whether or not these intents are intended for the implementation will
depend on the semantics of the particular intent involved. So this rule
is intended as "belt and braces" to make sure we don't omit anything
from the implementation that might apply to it. I'm open to other
suggestions for how to handle this ambiguity.
If the implementation is not the interface, there's no ambiguity.
Any intents on the implementation class need to go on the implementation
in the componentType, because there's nowhere else to put them.
> If the impl class is used as the interface, will any intents show up on the
> <implementation.java> element? You're example above says no which would seem
> to be a problem for transactions (at least).
>
They will show up, and I don't know which example you think is saying
that they won't. I didn't give an example of an impl-as-interface
with intents on the impl-as-interface. We can modify your example to
include this as follows:
package test;
@SomeImplIntent
public class ASM_0003_Client {
@Confidentiality
public void method1(int x) {}
}
The componentType for this would be:
<componentType>
<implementation.java class="test.ASM_0003_Client" requires="someimplintent"/>
<service name="ASM_0003_Client">
<interface.java interface="test.ASM_0003_Client"/>
</service>
</componentType>
Simon
> >
> > > > 2. For all SCA services defined using Java interfaces,
> intents on
> > > > the service implementation class are placed on the
> corresponding
> > > > <service> elements in the componentType.
> > >
> > > So, impl class level attachment results in the intents being placed
> on both
> > > the implementation element and the service element?
> > >
> > Yes. I included this because of two possibilities:
> > a) these intents could include implementation intents that constrain
> > bindings used by the service.
> > b) these intents could include interaction intents that constrain
> > wiring of the service.
>
> Ok, that's the case I was thinking about.
>
> >
> > > > 3. Intents on Java references are placed on the corresponding
> > > > <reference> elements in the componentType.
> > > >
> > > > Simon
> > >
> > > I really think we need a few examples to work through this. I'd offer
> > > a few but I'm not sure if I have the right mental model yet.
> > >
> > I'll write another email including some examples. I'll try to do it
> > today before I leave for my vacation.
>
> thanks
>
> >
> > Simon
> >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > > generates this mail. Follow this link to all your TCs in OASIS at:
> > > >
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> > > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]