Re: [sca-j] JAVA-153: Proposed resolution

[Simon Nash <oasis@cjnash.com>]

I'm beginning to like Mike's suggestion to add annotation metadata
so that the introspection algorithm could produce the new JAVA-125
form of <interface.java>, i.e., with a Java interface that doesn't
have a @Remotable annotation, but is declared as being remotable by
including the @remotable="true" attribute.

For service declarations, we could add a "remotable" attribute to
@Service, defined as follows:
   Class<?>[] remotable() default {};
The value of this attribute is an array of one or more interface
or class objects that MUST be introspected as remotable in the
componentType.  The interface or class objects passed on the
"remotable" attribute MUST also be present on either the "value"
or "interfaces" attribute.

For reference declarations, we could permit @Remotable to be
specified on the reference itself as Mike has suggested.

This retains the simplicity of option A as discussed on Friday's
call (componentType interfaces are always fixed as either local or
remotable), while providing flexibility for an introspected
componentType to include remotable interfaces that don't contain
a @Remotable annotation.

   Simon

Simon Nash wrote:
> I'd like to explore the implications of the option C that we discussed
> on today's call.  This would change the meaning of a Java interface
> not annotated as @Remotable.  Instead of requiring it to use local
> semantics (by-reference parameters and return values), it would allow
> either local or remotable semantics depending on what is specified in
> the component definition.
> 
> This would mean that implementations using these interfaces would
> need to be coded in a way that isn't dependent on whether by-value or
> by-reference semantics are be used.  This is effectively equivalent
> to the code that would be needed if the @AllowsPassByReference
> annotation is used.
> 
> This seems attractive because it would allow us to reduce the
> number of different cases.  Today we have:
>   1. Remotable interfaces requiring copy semantics
>   2. Remotable interfaces with @AllowsPassByReference, allowing
>      either copy semantics or by-ref semantics
>   3. Local interfaces, requiring by-ref semantics
> 
> If we went with option C, case 3 would be eliminated, which would
> effectively give all SCA Java interfaces remotable semantics.
> If they require copy semantics (case 1), they would be marked
> @Remotable.  If they are agnostic between copy semantics and by-ref
> semantics, they would be unmarked in the implementation and
> the introspected componentType.  It's hard to see why we would
> still need @Remotable with @AllowsPassByReference.
> 
> The effect of these changes would be to make Java interfaces
> remotable (or potentially remotable) by default.  This means we
> could change the semantics of <interface.java> to say that if the
> interface is unmarked, it is considered to be remotable unless
> it is explicitly defined as local by specifying @remotable="false".
> 
> This change would mean we lose the ability for people to make
> SCA service interfaces from POJO interfaces that were not designed
> with remotability in mind and therefore require by-ref semantics.
> So someone can't just take a bunch of POJOs designed to always be
> collocated in the same JVM and easily convert these to local-only
> SCA components and services.  For me this wouldn't be a big loss,
> though others might take a different view.
> 
> A bigger problem IMO would be the change of semantics for an
> unannotated Java interface used as an SCA service interface.
> Instead of this having the same semantics as Java (by-ref only),
> Java implementations of these unannotated interfaces would need
> to obey the @Remotable plus @AllowsPassByReference rules.
> Many Java programmers wouldn't understand this subtle semantic
> implication of an unannotated interface, and the result would be
> many SCA implementations with hard-to-find bugs that only manifest
> themselves with specific local/remote deployment combinations.
> 
> Comments, thoughts?
> 
>   Simon
> 
> David Booz wrote:
>> I'm struggling with the wording.
>>
>> I think it would be more appropriate to say that "the service contract 
>> for a Java component cannot be defined by the <interface.java> XML 
>> element" Instead of "cannot be", "is not" might be an improvement. We 
>> might also consider explaining why this is so, "because the service 
>> contract for a Java component is always introspected from the Java 
>> implementation class."
>>
>> And a similar change for section 2.5.
>>
>>
>> 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 05/01/2009 03:43:49 AM:
>>
>>  > [image removed]
>>  >
>>  > [sca-j] JAVA-153: Proposed resolution
>>  >
>>  > Simon Nash
>>  >
>>  > to:
>>  >
>>  > OASIS Java
>>  >
>>  > 05/01/2009 03:44 AM
>>  >
>>  > I am attaching a Java CI spec with inline proposed changes to
>>  > resolve JAVA-153.  The changes are in sections 2.2 and 2.5 (the
>>  > latter is needed because it turns out we also have a problem
>>  > with the Java CI spec's description of the callbackInterface
>>  > attribute of <interface.java>).
>>  >
>>  >    Simon
>>  >
>>  > [attachment "sca-javaci-1.1-spec-wd10+issue153.doc" deleted by David
>>  > Booz/Poughkeepsie/IBM]
>>  > ---------------------------------------------------------------------
>>  > 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
> 
>