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