[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
Thanks...finally we're done. No comments 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/16/2009 10:49:08 AM:
> [image removed]
>
> Re: [sca-j] JAVA-98: Simplified proposed direction for resolution
>
> Simon Nash
>
> to:
>
> sca-j
>
> 04/16/2009 10:50 AM
>
> Dave,
> See responses inline.
>
> Simon
>
> David Booz wrote:
> > 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.
> >
> Yes, that's what I mean. I'm fine with using the words you suggested.
> This would reword the paragraph as follows, using bullets for clarity:
>
> Intents can be applied to the following:
> . a Java interface used as an SCA service interface, and the
> methods of such an interface
> . a Java class used both as an SCA service implementation and a
> service interface, and the methods of such a class
> . a Java class used only as an SCA service implementation
> . a Java reference
> . a Java interface for a reference
> . a method of a Java interface for a reference
> It is an error to apply an intent to a method of a Java class used
> only as an SCA service implementation.
>
> > > 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. :-)
> >
> Sounds like a different issue to me :-) I have some sympathy, as this
> is starting to look like a feature motivated by "convenience/simplicity"
> that actually introduces complexity because of the cases that it adds.
>
> > >
> > > > >
> > > > > > >
> > > > > > > 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 intentswhich 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.
> >
> Thanks for the clarification. I was seeing the step B) merge as a
> copy, not a move. Step B) is defining what applies to the methods,
> and there was no intention to suggest that it would remove anything
> from the class. I can reword step B) to clarify this.
>
> Simon
>
> >
> > > > 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 thatconstrain
> > > > > 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
> > >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]