[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
more below
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 06:35:43 PM:
> [image removed]
>
> Re: [sca-j] JAVA-98: Simplified proposed direction for resolution
>
> Simon Nash
>
> to:
>
> sca-j
>
> 04/08/2009 06:37 PM
>
> 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.
>
We're mincing words, and the ones you're using just don't work for me.
When the same class is used for both purposes, I find the existing words
to be contradictory:
- Is the class used as an implementation class? yes, can't do method intents
- Is the class used as an interface class? yes, can do method intents.
I think what you mean is that it's ok to annotate an impl class method that is
also (boolean AND) used as an interface def'n. But it's never ok to annotate
an impl class method if it's ONLY used as a component impl.
> 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.
At this point I'd vote to remove the ability to use an impl class as
a service interface def'n. :-)
>
> > >
> > > > >
> > > > > 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.
>
I was asking a different question, so I'll restate it to try to clarify.
Step B point 2) merged the intents to the method level. That implies a
move not a copy. Once you logically move the intents to the method level
then there are no more class level attachments, so Step D point 1) wouldn't
find any class level intents to put on the componentType. I think what you
might be saying is that the algorithm starts over with a pre-merged view
of the class and then runs step D of the algorithm.
> > 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
>
See my restated question above.
> > >
> > > > > 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
> > >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]