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

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>

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

>  >     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().

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

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

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

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]