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


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