[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] JAVA-153: Proposed resolution rev3
David Booz wrote: > Hi Simon, inline below. > > 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 > > Simon Nash <oasis@cjnash.com> wrote on 06/15/2009 09:54:06 AM: > > > [image removed] > > > > Re: [sca-j] JAVA-153: Proposed resolution rev3 > > > > Simon Nash > > > > to: > > > > David Booz > > > > 06/15/2009 09:55 AM > > > > Cc: > > > > sca-j > > > > Dave, > > See inline below. > > > > Simon > > > > David Booz wrote: > > > Hi Simon, > > > > > > Two points: > > > > > > (1) > > > > > > So then based on your proposal, is the following example correct? > > > > > > Implementation class: > > > > > > *package* services.hello; > > > > > > @Remotable > > > @Service(HelloServiceImpl.class) > > > *public class *HelloServiceImpl { > > > > > > *public *String hello(String message) { > > > > > > ... } > > > } > > > > > > In this case the introspected component type for the implementation > uses > > > the @remotable attribute of the <interface.java/> element, as shown in > > > the following snippet: > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > <componentType xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200903 > > > <http://docs.oasis-open.org/ns/opencsa/sca/200712>"> > > > <service name="HelloServiceImpl"> > > > > > > <interface.java interface="services.hello.HelloServiceImpl" > > > remotable="true"/> > > > > > > </service> > > > > > > </componentType> > > > > > > > > The source code is correct. I would expect the component type to > > omit the @remotable attribute from <interface.java/> because this > > is already implied by the @Remotable annotation on the service > > interface (which just happens to also be the implementation class). > > To avoid any ambiguity, I will add this example to section 2.2. > > > > Hmmm...this seems counter-intuitive. Seems like it would be better to > always have @remotable present in the componentType if that's what the > implementation says, regardless of how or where it is said. > Are you applying this only to @Remotable on implementations? What about @Remotable on interfaces? Do you think this should cause the @remotable attribute to appear in the component type? My view is that the @remotable attribute should appear only when necessary, i.e., when it is not already implied by the contents of the "interface" attribute. > > I will also add normative rules in chapter 8 for these introspection > > scenarios. This was an inadvertent omission from rev3. > > > > Ok, good. That would have been my next question. > > > > > > > > > > (2) > > > I looked back at the resolution for JAVA-125 and noticed that it > did not > > > address a question that arises from line 277-278 (from > > > sca-javacaa-1.1-spec-cd03+issue125-rev2.doc) which has the following > > > statement: > > > > > > The @remotable attribute is intended as an alternative to using the > > > @Remotable annotation. > > > > > > > > > That's quite a strong statement and it implies semantics which > allow the > > > ability for a component definition to assert remotability onto a > service > > > interface. Remember that <interface.java/> is used on both > > > componentTypes and component definitions. I quite like the ability to > > > assert remotability in this way, but I suspect there are also > dissenting > > > opinions. I want to make sure we have a consistent story across the > specs. > > > > > The language in lines 277-278 was written before the resolution to > > JAVA-125 extended the semantics of the @Remotable annotation so that > > it applies to service implemementations and references. To faithfully > > render the intention of this pre-125 quoted sentence using post-125 > > language, the sentence should now read: > > The @remotable attribute is intended as an alternative to using the > > @Remotable annotation on a service interface. > > I don't think this wording addresses your concerns. I read that text > the same way I read the existing text. Service interfaces can be > declared on a component. I think you want to limit the use of > @remotable to <interface.java> that appears in a componentType. > No, I don't want to limit @remotable in the way that you are suggesting. It's fine to have @remotable on <interface.java> in component definitions, as long as this does not contradict the remotability/locality setting that was defined by the component type. > > > > If we agree that this is the meaning, then the resolution to JAVA-125 > > is entirely consistent with this by providing two new alternative > > mechanisms for making an SCA service interface remotable (i.e., > specifying > > @Remotable on a service implementation or a reference). > > > > The alternative interpretation, which had not occurred to me before > > I read this message, is that the @remotable attribute provides an > > alternative to all possible uses of the @Remotable annotation, i.e., it > > is used to assert remotability at the component level even though the > > Java interface and implementation have no knowledge of remotability > > and don't use any of the possible forms of @Remotable. I disagree with > > this interpretation for the reasons we have discussed in previous emails. > > I'm not surprised, but that's how I read the text. I think you need to open > an issue if you want to change it. > The compatibility rules in the Assembly spec do not allow a component definition to change an interface defined as local in the component type into a remotable interface in the configured component. If you think this should be allowed, you need to open an Assembly issue to change it. I don't read the text in JavaCAA as contradictory to this Assembly rule. I believe the meaning is I stated in my previous email, i.e., that the @remotable attribute is intended as an alternative to using the @Remotable annotation on a Java service interface. This allows remotable SCA services to be defined using Java interfaces that represent remotable semantics but don't physically contain a @Remotable annotation. This applies to both component types and component definitions. Simon > > > > 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 ---06/15/2009 07:40:03 AM---I am > > > attaching a revised proposed resolution for JAVA-153, as Simon Nash > > > ---06/15/2009 07:40:03 AM---I am attaching a revised proposed > resolution > > > for JAVA-153, as discussed on last Monday's call. > > > > > > > > > From: > > > Simon Nash <oasis@cjnash.com> > > > > > > To: > > > OASIS Java <sca-j@lists.oasis-open.org> > > > > > > Date: > > > 06/15/2009 07:40 AM > > > > > > Subject: > > > [sca-j] JAVA-153: Proposed resolution rev3 > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > I am attaching a revised proposed resolution for JAVA-153, > > > as discussed on last Monday's call. > > > > > > Simon > > > /(See attached file: > > > sca-javaci-1.1-spec-cd01+issue153- > > > rev3.doc)/--------------------------------------------------------------------- > > > 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]