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:
Simon Nash <> 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:
> >
> > Simon Nash <> 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:
> > > >
> > > > Simon Nash <> 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:
> > > > > >
> > > > > > 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 <>
> > > > > >
> > > > > > To:
> > > > > > OASIS Java <>
> > > > > >
> > > > > > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
