Hi Raymond,
I'm not on the Java TC, so this response won't go to them, I'm afraid.
Thanks for the example. It clarified the question for me.
Seems like it would be incumbent on a Java implementation to state whether it requires the pass-by-reference semantics. If it doesn't state a preference, why should it care whether it is invoke in a local or remote manner?
That's what I see as the missing piece.
Eric 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: rfeng@us.ibm.com,
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
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:booz@us.ibm.com
---------------------------------------------------------------------
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
|