OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]