OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[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]