[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Re: [sca-j] ASSEMBLY-218: Review Interface Compatibilitylogic 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]