Re: [sca-j] JAVA-98: Updated proposed direction for resolution

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Simon Nash wrote:
> Here is a revised and consolidated version of the previous proposed
> direction for resolution, including the examples and Dave's comments.
> 
> I am hoping that on today's call the TC will vote to accept this as
> a direction for resolving JAVA-98.  I would then be able to produce
> a full proposal with inline updates to the specification text, and
> distribute it later today so that we can consider it on Monday's call.
> 
> 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 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
>    . the methods 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.
> 

Is there a way we can avoid this? I don't like this since, in addition 
to making the rules complex, it depends on the configuration (of the 
composite file). A Java class that uses method-level intent annotation 
is conformant, but it imposes restrictions on the composite 
configuration wrt the interface that is exposed.

As someone (I think Dave) had suggested, perhaps we should require the 
interface/implementation separation.

Could you pl. remind me why this (@Requires cannot be used on a method 
of a Java class that is used only as an SCA service impl) restriction 
exists. And how does it relate (if at all) to a composite that
1) contains a single component with <implementation.java> that points to 
an impl class that has a method-level @Requires and that class is also 
used as the service interface
2) promotes the component service with an interface that is a Java 
interface (and different from the underlying impl class).

-Anish
--

> 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
>       and the intents for its declaring class or interface.
>    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.
>    These rules are applied to the following:
>    . the methods of a Java interface used as an SCA service interface
>    . the methods of a Java class used both as an SCA service
>      implementation and a service interface
>    . the methods of a Java interface for a reference
>    The merging process does not remove or change any intents that were
>    applied to classes or interfaces.
> 
> 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.
>    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.
>    3. Intents on Java references are placed on the corresponding
>       <reference> elements in the componentType.
> 
> The following examples show how the various points of this proposal
> would work.  In these examples, it is assumed that @ManagedTransaction
> has been defined as a specific intent annotation for the SCA intent
> "managedTransaction".
> 
> No examples are given for point C) above because this delegates to
> the Policy spec and is not Java-specific.
> 
> Example A1:
> 
> In the following Java code, the intents on myref are "authentication"
> and "confidentiality.message".
> 
>  @Authentication
>  @Requires(CONFIDENTIALITY)
>  @Confidentiality("message")
>  @Reference
>  protected MyService myref;
> 
> Example A2:
> 
> The following Java code is in error because of contradictory mutually
> exclusive intents "managedTransaction" and "noManagedTransaction".
> 
>  @ManagedTransaction
>  @Requires(SCA_PREFIX+"noManagedTransaction")
>  @Reference
>  protected MyService myref;
> 
> Example A3:
> 
> The following intents are legal:
> 
>  @Authentication
>  public class MyService {
>      @Confidentiality
>      public void mymethod() {...}
>  }
> 
> Example A4:
> 
> The following intents are legal:
> 
>  @Authentication
>  public interface MyService {
>      @Confidentiality
>      public void mymethod();
>  }
>  @Service(MyService.class)
>  @ManagedTransaction
>  public class MyServiceImpl {
>      public void mymethod() {...}
>  }
> 
> Example A5:
> 
> The following intents are legal:
> 
>  @Authentication
>  public interface MyRefInt {
>      @Integrity
>      public void mymethod();
>  }
>  @Service(MyService.class)
>  public class MyServiceImpl {
>      @Confidentiality
>      @Reference
>      protected MyRefInt myRef;
>  }
> 
> Example A6:
> 
> The following intent is illegal:
> 
>  @Service(MyService.class)
>  public class MyServiceImpl {
>     @Authentication
>     public void mymethod() {...}
>  }
> 
> Example B1:
> 
> The effective intents for mymethod() are "authentication" and
> "confidentiality".
> 
>  @Authentication
>  public interface MyService {
>      @Confidentiality
>      public void mymethod();
>  }
> 
> Example B2:
> 
> The effective intent for mymethod() is "confidentiality.message".
> 
>  @Confidentiality("message")
>  public interface MyService {
>      @Confidentiality
>      public void mymethod();
>  }
> 
> Example B3:
> 
> The effective intent for mymethod1() is "managedTransaction"
> and the effective intent for mymethod2() is "noManagedTransaction".
> 
>  @ManagedTransaction
>  public interface MyService {
>      public void mymethod1();
>      @Requires(SCA_PREFIX+"noManagedTransaction")
>      public void mymethod2();
>  }
> 
> Example D1:
> 
> For the following Java code:
> 
>  @Authentication
>  public interface MyService {
>      @Confidentiality
>      public void mymethod();
>  }
>  public interface MyRefInt {
>      @Integrity
>      public void mymethod1();
>  }
>  @Service(MyService.class)
>  @ManagedTransaction
>  public class MyServiceImpl {
>      @Confidentiality
>      @Reference
>      protected MyRefInt myRef;
> 
>      public void mymethod() {...}
>  }
> 
> the intropected componentType is:
> 
> <componentType>
>     <implementation.java class="MyServiceImpl" 
> requires="managedTransaction"/>
>     <service name="MyService" requires="managedTransaction">
>         <interface.java interface="MyService"/>
>     </service>
>     <reference name="myRef" requires="confidentiality">
>         <interface.java interface="MyRefInt"/>
>     </reference>
> </componentType>
> 
> 
>   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