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

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

one comment 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/16/2009 04:12:57 PM:

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

Formality takes more work but it ensures that everyone is aware of
important changes in the document.  I think we need an issue for this (or
re-opening 125).

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