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

[Simon Nash <oasis@cjnash.com>]

Anish Karmarkar wrote:
> 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.
> 
It does not depend on the configuration of the composite file.  The
class itself defines (by the presence or absence of @Service annotations)
what service interfaces it is exposing.

> As someone (I think Dave) had suggested, perhaps we should require the 
> interface/implementation separation.
> 
This should be handled as a separate issue.  It impacts many parts
of the specifrications.

> 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.
 >
It was suggested as a simplification to avoid the problems of merging
method-level intents from the implementation and the interface, and to
avoid the need for synthetic service interfaces.

>         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
 >
This would be allowed.

> 2) promotes the component service with an interface that is a Java 
> interface (and different from the underlying impl class).
> 
This should be allowed if the interface has identical intent annotations
on its methods.  I need to check the ASSEMBLY-117 resolution to see if
the definition of "compatible" included this.

   Simon

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