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] ASSEMBLY-218: Review Interface Compatibility logic toaccomodate @Remotable attribute in the SCDL - proposal



Raymond,

OK, so this is arguing that <interface.java/> in an SCA <component/> should not be allowed to have a @remotable
attribute setting that is different from that in the <componentType/> of the implementation used by the component.

So one use case that was argued is the one where the Java interface and the Java service implementation is fixed
and unchangable - and that neither says @Remotable, although it is known that the interface & implementation are
indeed remotable,  In this case, I don't see that anyone can use either of the techniques in your first bullet.

Introspection will show the implementation as using the unannotated interface and that will be interpreted as "local".
Creating a subinterface will not help since introspection will only see the original implementation and its reference
to the original interface.  If we follow you approach below, then nothing can be done for such pre-existing implementations
- they are always interpreted as local and nothing can be done about them.

Or rather - I feel a Mediation coming on...   ;-)


We may argue that it is presumptious to take an existing implementation class and assume we can treat it as @Remotable
even though it was not created with that in mind.  However, I think that this flies in the face of reality.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



From: Raymond Feng/Burlingame/IBM@IBMUS
To: Mike Edwards <mike_edwards@uk.ibm.com>
Cc: "OASIS Java" <sca-j@lists.oasis-open.org>
Date: 24/02/2010 18:44
Subject: Re: [sca-j] Re: [sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to accomodate @Remotable attribute in the SCDL - proposal




Sorry for the confusion but I meant to be the other way around:

* For implementation.java, we can annotate the interface @Remotable or create a subinterface of an existing one and add @Remotable. The componentType introspection will set the "remotable" flag.
* For other implementation types such as "implementation.osgi",  we don't have the luxury to annotate the interfaces. But when we map them into an SCA componentType, we know that an interface from "service.exported.interfaces" property is meant to be remotable. So the introspection of implementation.osgi componentType can set the "remotable" flag.

What I'm trying to say is that we should always control the "remotable" from the componentType and the component configuration should just adapt to it.

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





From: Mike Edwards <mike_edwards@uk.ibm.com>
To: "OASIS Java" <sca-j@lists.oasis-open.org>
Date: 02/23/2010 11:43 PM
Subject: Re: [sca-j] Re: [sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to accomodate @Remotable attribute in the SCDL - proposal






Raymond,


You seem to be implying that for some Java implementation types, that it is possible to set the content of the componentType

so that some <interface.java/> element, @remotable="true" would be set where the referenced Java interface class does not

have the @Remotable annotation.


In general, componentType is introspected from the Java artifacts - componentType side files are used only where no other

mechanism is available (eg in C++ where introspection is only possible on the original source code).  


So, how can the componentType of these implementation types be manipulated to apply the @remotable attribute?



Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com


From: Raymond Feng <rfeng@us.ibm.com>
To: David Booz <booz@us.ibm.com>
Cc: sca-assembly@lists.oasis-open.org, sca-j@lists.oasis-open.org
Date: 24/02/2010 01:14
Subject: [sca-j] Re: [sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to accomodate @Remotable attribute in the SCDL - proposal






IIRC, the use case is not to take a "local" java interface as-is for SCA Java components. Instead, it was proposed to cover other POJO-style implementation types such as OSGi where a set of interfaces are listed in the "
service.exported.interfaces" property for remote services. In such cases, we derive an SCA componentType from the OSGi properties and the "remotable" flag can be set in the componentType service/reference interfaces.

To use a "local" java interface for SCA components, we can create a subinterface and annotate it with @Remotable. It should be acceptable because we are building an SCA java component (not wrapping other technology that doesn't have the notion of Remotable).

What I'm arguing here is that allowing the component configuration (SCDL interface.java/@remotable) to override the remotability of the componentType service/reference doesn't seem to be a good practice. IMO, it should be set in the componentType and the component should adapt to it.


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


From: David Booz/Poughkeepsie/IBM@IBMUS
To: sca-assembly@lists.oasis-open.org, sca-j@lists.oasis-open.org
Date: 02/16/2010 11:48 AM
Subject: Re: [sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to accomodate @Remotable attribute in the SCDL - proposal







Thanks for cleaning up for the issue references.

I don't quite agree with your use cases.  IIRC, the reason @remotable was
added was to allow for the case where a Java interface, which cannot be
modified, is used as a remotable interface.  Since there's no opportunity
to add the @Remotable annotation, an alternative mechanism was added.
However, since the SCA java component implementation spec decided not to
support the use of a componentType side file, there is no place other than
a component definition which can contain the remotable assertion.  We did
discuss the subclassing option was way to add remotability to an otherwise
unmodifiable interface class.  It was tossed out as too cumbersome.

The cases you cited below are different because they run into the by-value,
by-reference issues that you outlined.  I don't think we should be in the
business of overriding local interfaces and allowing them to be turned into
remote interfaces (and vice versa which can be even more dangerous).  The
problem is that in the absence of an @Local annotation, SCA doesn't know if
the interface is truly local or remote.

WRT your C1 and C2 example, it certainly doesn't seem like a smart thing to
do, but I don't see any reason to stop it.

In 1) you suggest removing @remotable from component interfaces.  If we
did, that would disallow the use case for which we added the support in the
first place.

...still, it's ugly...


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


|------------>
| From:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Raymond Feng/Burlingame/IBM@IBMUS                                                                                                                 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|David Booz/Poughkeepsie/IBM@IBMUS                                                                                                                 |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|sca-assembly@lists.oasis-open.org, sca-j@lists.oasis-open.org                                                                                     |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|02/16/2010 01:56 PM                                                                                                                               |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to accomodate @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: 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


                                                                       
From: David Booz/Poughkeepsie/IBM@IBMUS                                  
                                                                       
                                                                       
To:   sca-assembly@lists.oasis-open.org                                  
                                                                       
Cc:   sca-j@lists.oasis-open.org                                          
                                                                       
Date: 02/16/2010 09:38 AM                                                
                                                                       
                                                                       
Subje [sca-j] ASSEMBLY-218: Review Interface Compatibility logic to      
ct:   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: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





---------------------------------------------------------------------
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








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU









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