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

[Simon Nash <oasis@cjnash.com>]

Jim,
We have reached the same conclusion, but for different reasons
(see the last paragraph of my email).  I would be interested
in your reaction to the proposal I made in my follow-up email.

   Simon

Jim Marino wrote:
> Sorry I haven't been able to participate lately in the calls to do other 
> obligations at the same time, but I wanted to comment on an item I feel 
> is very important to get right. Comments inline.
> 
> Jim
> 
> On May 1, 2009, at 9:47 AM, 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.
>>
> 
> I definitely do :-) And I'm surprised changes this significant are being 
> brought up this late in the specification process. The original design 
> for making contracts defined by a Java interface local by default was 
> twofold:
> 
> 1. To require developers to explicitly design service contracts with 
> "remotability" in mind
> 2. To cater to the common case in application design and thereby meet 
> the expectations of most developers (at least Java developers).
> 
> In regards to item 2, most applications have many more local services 
> than remotable ones. This has been recognized by nearly all modern Java 
> programming models (EJB3, Spring, Guice, Seam) which have local, 
> by-reference semantics as the default. There are a few programming 
> models which did not take this approach and adopted one similar to 
> option C. Of these, EJB 1-2 comes to mind, which is generally regarded 
> as a technical failure. A strong argument can be made that a key 
> contributing factor to this failure was EJB's focus on remotability at 
> the expense of optimized local interactions.
> 
> Beyond catering to the common use case, IMO it is also very important to 
> enable use of "POJOs designed to be collocated in the same JVM and 
> easily convert these to local-only SCA components and services." For 
> example, JPA (and other persistence technologies) requires by reference 
> semantics for the most common operations (e.g. lazy loading of  entity 
> relationships). In many applications, it's common to have data access 
> objects that manage persistence using JPA. These DAOs are typically 
> POJOs that use JPA and hence require by-reference semantics.  Also, DAOs 
> are often reused across projects. One of the advantages of the original 
> SCA design regarding local services was these DAOs - containing a lot of 
> an application's logic - could be used as is. Option C appears to 
> prohibit this.
> 
> It's also worth pointing out a change this drastic would break backward 
> compatibility and force all applications using prior versions of SCA to 
> undergo significant alteration.
> 
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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
> 
>