Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic toaccomodate @Remotable attribute in the SCDL - proposal

Hi,

The links to issues are incorrect. They
should be:

http://www.osoa.org/jira/browse/JAVA-125

http://www.osoa.org/jira/browse/JAVA-153

IMO, the @remotable attribute in SCDL
is tricky because it is the first case that component configuration starts
to alter the interface remotability in the componentType. There are basically
two use cases:

* A java component implements a "local"
java interface and we want to expose such service to a remote binding.

* A java component with a reference
of a "local" java interface and we want to use it to access a
remote service.

Did we consider the case that more than
one component uses the same Java implementation class, for example:

Component C1 exposing S1 as web service.

<component name="C1">

        <implementation.java
class="test.TestServiceImpl"/>

        <service
name="S1">

         
      <interface.java interface="test.TestService"
remotable="true"/> <!-- test.TestService interface doesn't
have @Remotable -->

         
      <binding.ws .../>

        </service>

</component>

Component C2 exposing S1 as a local
service for binding.sca.

<component name="C2">

        <implementation.java
class="test.TestServiceImpl"/>

        <service
name="S1">

         
      <interface.java interface="test.TestService"/>

        </service>

</component>

Is this allowed? If so, do we expect
test.TestServiceImpl to support both the local pass-by-reference or remote
pass-by-value semantics depending on the components that use the impl class?

A few crazy thoughts:

1) Based on the original use case, should
we only allow the SCA componentType to set the interface.java to be remotable
instead of the component, for example:

<componentType ...>

        <service
name="S1">

         
      <interface.java interface="test.TestService"
remotable="true"/>

        </service>

</componentType>    
   

(Please note that componentType can
be just an in-memory model. The XML is for illustration purpose.)

In fact, when we (Tuscany) implement
OSGi remote services using SCA, we generate the componentType from the
OSGi properties (service.exported.interfaces) so that the java interface
is remotable.

2) For the direct use of "local"
java interfaces as remotable in Java components, can we just have a subinterface
so that:

@Remotable

public interface RemotableJavaInterface
extends LocalJavaInterface {

} 

Thanks,

Raymond

Raymond Feng

Senior Software Engineer, Apache Tuscany PMC Member & Committer 

IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400,
Foster City, CA 94404, USA

E-mail: ,
Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117,
T/L: 367-8117

Personal Web Site: www.enjoyjava.com

Apache Tuscany: http://tuscany.apache.org

Co-author of Tuscany In Action: http://www.manning.com/laws

From:
David Booz/Poughkeepsie/IBM@IBMUS

To:


Cc:


Date:
02/16/2010 09:38 AM

Subject:
[sca-j] ASSEMBLY-218: Review Interface
Compatibility logic to accomodate @Remotable attribute in the SCDL - proposal

Following discussion of Assembly-218 [1] on the Assembly TC telecon today,

I took a closer look at the Assembly, Java CAA and Java POJO specs. I've

copied the Java TC on this email for awareness.

The assembly spec rule for matching interfaces based on remotability is

fundamentally important, so I don't think we can change that.  The
Java CAA

spec is the one that defines @remotable for <interface.java/>.  The
Java

POJO spec contains the componentType introspection rules and describes
the

use of Java POJOs for component implementations.

IMHO, if there is any spec text in error or at the very least that we

should consider updating, it is the Java POJO spec [2]. Issue Java-125
[3]

and Java-153 [4] introduced the @remotable attribute but did not address

the trip hazard that is described in Assembly-218.

In the Java POJO spec [2], see section 2.2 (toward the end) and section

2.3.  At both points the spec makes some very specific statements
about

interface remotability but leaves out any mention that the determination
of

remotability could be further altered by the introduction of @remotable
on

a component definition.  Interestingly, section 2.2 was heavily updated

when Java issues 125 and 153 were resolved.  Those were the Java issues

that introduced @remotable on <interface.java/> in the first place.
 The

Java POJO spec is (in general) maniacally focused on the componentType
of a

Java component (I'm sure that's what was in all of the Java TC minds when

it resolved 125 and 153).  This trip hazard [1] comes along with the

combination of a component definition which seems to have the ability to

assert remotability into an underlying componentType and an introspected

componentType which says local.

Let's see if others buy this analysis before I suggest moving the issue
to

the Java TC.

[1] http://www.osoa.org/jira/browse/ASSEMBLY-218

[2]

http://www.oasis-open.org/committees/download.php/36414/sca-javaci-1.1-spec-cd02.doc

[3] http://www.osoa.org/jira/browse/ASSEMBLY-125

[4] http://www.osoa.org/jira/browse/ASSEMBLY-153

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:

---------------------------------------------------------------------

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

S/MIME Cryptographic Signature