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