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

[Simon Nash <oasis@cjnash.com>]

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