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

[Simon Nash <oasis@cjnash.com>]

Dave,
See comments inline.

   Simon

David Booz wrote:
> 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.
> 
I think we need to be consistent here.  It seems to me that there are
two possible consistent positions:

1. In the component type, specify the @remotable attribute only when
    necessary (i.e., include it only when its value is "true" and when
    it is needed to override the remotability setting that would
    otherwise be inferred from the @interface attribute).

2. In the component type, always specify the @remotable attribute
    (i.e., include it with an explicit value of "true" or "false"
    whether or not this duplicates information in the @interface attribute).

My preference is for 1, as in general I think it's better not to
specify redundant information.  I think your preference is for 2.
Any other views on this?

>  > 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).
> 
I don't think it carries no meaning.  Its meaning is very well defined
by JavaCAA and the compatibility rules for component types and components
are very well defined by Assembly.

I don't see why the requirement for component type and component to be
consistent is a reason to always make the @remotable attribute explicit in
the component type.  There is no requirement to always make the @remotable
attribute explicit in the component definition.  Also, the remotability
semantics of the component type and component are not dependent on whether
the @remotable attribute is explicit or implicit.

>  > >  >
>  > >  > 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.
> 
This small clarification to existing text was overlooked when we resolved
JAVA-125.  This language is non-normative and I would have thought that
the change could be handled editorially.  If as chair you think that a
formal resolution is needed to add these few words of clarification, I will
propose reopening JAVA-125 so that these words can we added to the sentence
in chapter 3.

   Simon

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