[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] NEWclass ISSUE: Java CI should have corresponding changesin JAVA-125 - [JAVA-153]
I thought of another possible use case. Some standard may have defined a Java interface that is semantically remotable but is not marked with the @Remotable annotation. Let's say this interface is org.foo.Bar. A vendor would like to create an SCA component with a remotable service that implements the org.foo.Bar interface. It can do this by extending the org.foo.Bar interface with a stub interface and adding an @Remotable annotation on the stub interface. Here's some example code to do this: package com.somevendor; @Remotable public interface BarService extends org.foo.Bar { } public class BarRemotableImpl implements BarService { .... } The componentType will have a service BarService whose interface is com.somevendor.BarService. In the component configuration, the service interface could be configured as <service name="BarService"> <interface.java interface="org.foo.Bar" remotable="true"/> </service> This avoids the need to expose the stub interface com.somevendor.BarService to clients of the service. Unfortunately it will be necessary for SCA clients to create a similar stub interface on their end to create references that can be wired to the service. It is possible that non-SCA clients could use the org.foo.Bar interface directly. Simon Simon Nash wrote: > David Booz wrote: >> This calls into question the resolution of issue 125. It doesn't seem >> possible for a CI to support the use of @remotable on interface.java >> unless the CI support componentType side files and the specification >> of @remotable appears in a componentType. >> >> Either that or we have to change the assembly rules and allow a >> component interface declaration to assert the remotable aspect onto a >> componentType, which doesn't seem desirable. >> >> For JCI, we could decide that interface.java/@remotable is just not >> supported but leave it there in the JCAA for other Java based CIs to >> use. Graham may have had some other use cases in mind which we should >> not arbitrarily remove. >> > We should leave it there. It could be used in a contrainingType. > > Simon > >> >> 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 >> >> Inactive hide details for Simon Nash ---04/21/2009 06:22:59 AM---Mike, >> The paragraph in question (in section 2.3) says which seSimon Nash >> ---04/21/2009 06:22:59 AM---Mike, The paragraph in question (in >> section 2.3) says which services are >> >> >> From: >> Simon Nash <oasis@cjnash.com> >> >> To: >> sca-j@lists.oasis-open.org >> >> Date: >> 04/21/2009 06:22 AM >> >> Subject: >> Re: [sca-j] NEW ISSUE: Java CI should have corresponding changes in >> JAVA-125 - [JAVA-153] >> >> ------------------------------------------------------------------------ >> >> >> >> Mike, >> The paragraph in question (in section 2.3) says which services are >> selected by the component type introspection algorithm in the absence >> of @Service annotations. This paragraph currently says that only >> those interfaces with a @Remotable annotation would be selected. >> The proposed change attempts to broaden this, and from your comments >> here I believe you are agreeing that this broadening would not >> be possible. >> >> Regarding your second point of using <interface.java> in a component >> definition to affect the remotable state of the interface, we realised >> on yesterday's call that this doesn't work because it violates the >> compatibility relationship between component type and component. >> If the introspected component type detects a service interface as >> being local because it isn't annotated with @Remotable, the component >> definition cannot specify a remotable interface because this would >> violate the definition of compatibility in the Assembly spec. >> >> I think the only way round this would be to re-introduce a >> .componentType side file for Java implementations so that the >> component type's service interface could be marked as remotable >> using the @remotable attribute on <interface.java>. >> >> Simon >> >> Mike Edwards wrote: >> > >> > Simon, >> > >> > I don't read the new sections in the way that you do and I don't see a >> > problem. >> > >> > I agree that if a Java POJO implements an interface that is not marked >> > remotable and >> > does not mark that interface as being a Service, then it will not >> appear >> > in the component >> > type of the POJO as a service and so cannot be used as such - >> making the >> > question >> > of marking it remotable with <interface,java/> moot. >> > >> > However, Mark's suggested sections don't contradict this. The section >> > on calculation >> > of component type remains unchanged. Only once the service appears in >> > the component >> > type can the use of the attribute on <interface.java/> affect the >> > remotable state of the >> > interface.... >> > >> > >> > 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: Simon Nash <oasis@cjnash.com> >> > To: sca-j@lists.oasis-open.org >> > Date: 20/04/2009 15:30 >> > Subject: Re: [sca-j] NEW ISSUE: Java CI should have corresponding >> > changes in JAVA-125 - [JAVA-153] >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > >> > >> > Mike, >> > My concern is not about local services but about remotable services. >> > >> > In the absence of @Service, the introspection algorithm identifies >> > interfaces implemented by the implementation class as being >> > SCA services if they carry a @Remotable annotation. The proposed >> > change would extend this to include the case where the interface >> > doesn't carry a @Remotable annotation, but the <interface.java> >> > element in a component configuration carries a @remotable attribute. >> > >> > This can't work because the introspection algorithm for discovering >> > which services should be included in the componentType only has >> > access to the Java interfaces and not to any component configurations >> > that may configure these Java interfaces as being remotable SCA >> > services. In order to do this, the @Service annotation would need >> > to be used. >> > >> > Simon >> > >> > Mike Edwards wrote: >> > > >> > > Simon, >> > > >> > > I don't follow your point below. >> > > >> > > Mark's text seems to work just fine. So you can't introspect a >> local >> > > interface as a Service if it is not >> > > used by a @Service annotation. I agree - but that does not >> contradict >> > > the statements made in Mark's >> > > formulation. >> > > >> > > 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: Simon Nash <oasis@cjnash.com> >> > > To: sca-j@lists.oasis-open.org >> > > Date: 20/04/2009 13:26 >> > > Subject: Re: [sca-j] NEW ISSUE: Java CI should >> have >> > corresponding >> > > changes in JAVA-125 - [JAVA-153] >> > > >> > > >> > > >> ------------------------------------------------------------------------ >> > > >> > > >> > > >> > > Mark Combellack wrote: >> > > > Hi, >> > > > >> > > > > > > >> > > > Raised as new issue 153. See >> http://www.osoa.org/jira/browse/JAVA-153 >> > > > >> > > > > > > >> > > > Thanks, >> > > > >> > > > > > > >> > > > Mark >> > > > >> > > > > > > >> > > > Mark Combellack| Software Developer| Avaya | Eastern Business >> Park >> > | St. >> > > > Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 | >> > > > mcombellack@avaya.com <mailto:|mcombellack@avaya.com> >> > > > >> > > > >> > >> ------------------------------------------------------------------------ >> > > > >> > > > *From:* David Booz [mailto:booz@us.ibm.com] >> > > > *Sent:* 26 March 2009 13:11 >> > > > *To:* sca-j@lists.oasis-open.org >> > > > *Subject:* [sca-j] NEW ISSUE: Java CI should have corresponding >> > changes >> > > > in JAVA-125 >> > > > >> > > > > > > >> > > > TARGET: Java C&I WD05 [1] >> > > > >> > > > DESCRIPTION: >> > > > Issue 125 [2] should have had corresponding changes in Java >> C&I spec, >> > > > see Section 2.2. >> > > > >> > > > PROPOSAL: >> > > > Section 2.2 line 144-146, change to: >> > > > A Java service contract defined by an interface or >> implementation >> > class >> > > > uses the @Remotable annotation or @remotable on >> <interface.java/> to >> > > > declare that the service follows the semantics of remotable >> > services as >> > > > defined by the SCA Assembly Specification, otherwise it is >> inferred to >> > > > be a local service. >> > > > >> > > > Delete Line 156-158. >> > > > >> > > > Line 164-169, change to: >> > > > If the interfaces of the SCA services are not specified with the >> > > > @Service annotation on the implementation class, it is assumed >> > that all >> > > > implemented interfaces that are remotable, as defined in >> > [JAVACAA], are >> > > > the service interfaces provided by the component. If an >> implementation >> > > > class has only implemented interfaces that are not remotable, >> the >> > class >> > > > is considered to implement a single */local/* service whose >> type is >> > > > defined by the class (note that local services can be typed >> using >> > either >> > > > Java interfaces or classes). >> > > > >> > > This doesn't work because the list of available services is part of >> > > the componentType and is determined by introspection. If one of >> the >> > > interfaces implemented doesn't use @Remotable but is configured in >> > > the component definition using the @remotable attribute, it >> can't be >> > > introspected as a service interface for the componentType. >> > > >> > > Simon >> > > > >> > > > [1] >> > > > >> > > >> > >> http://www.oasis-open.org/committees/download.php/31836/sca-javaci-1.1-spec-wd05.pdf >> >> > > > [2] http://www.osoa.org/jira/browse/JAVA-125 >> > > > >> > > > >> > > > >> > > > 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 >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> ------------------------------------------------------------------------ >> > > >> > > / >> > > / >> > > >> > > /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/ >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > --------------------------------------------------------------------- >> > 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/ >> > >> > >> > >> > >> > >> > >> >> >> >> --------------------------------------------------------------------- >> 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]