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

[Simon Nash <oasis@cjnash.com>]

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
>