Re: [sca-j] JAVA-153: Proposed resolution rev3

[David Booz <booz@us.ibm.com>]

More comments inline

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/16/2009 05:05:02 AM:

> [image removed]
>
> Re: [sca-j] JAVA-153: Proposed resolution rev3
>
> Simon Nash
>
> to:
>
> David Booz
>
> 06/16/2009 05:05 AM
>
> Cc:
>
> sca-j
>
> 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?
>

Yes, even for interfaces.

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

So your view is that @remotable in a component carries no meaning, but it
is tolerated as long as it's consistent with componentType.  This is actually
an argument for always putting it in the componentType when present in any
implementation language specific artifact (impl class, interface class, etc).

> >  >
> >  > 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'm merely pointing out that ISSUE-125 is still not completely correct.

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