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

[Simon Nash <oasis@cjnash.com>]

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.

I will also add normative rules in chapter 8 for these introspection
scenarios.  This was an inadvertent omission from rev3.

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

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.

   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