Re: [ISSUE 157] Section 10.13 on @OneWay requires a normative statement

[Mike Edwards <mike_edwards@uk.ibm.com>]

Anish,

I think your 3) is much the same as
my 1)....

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	Mike Edwards/UK/IBM@IBMGB
Cc:	sca-j@lists.oasis-open.org
Date:	02/05/2009 00:29
Subject:	Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement

---

Mike Edwards wrote:
> 
> Folks,
> 
> I think we've lost sight of something here.
> 
> If the intention is to use the whole of an implementation class as
the 
> definition of a service interface (case of
> unannotated POJO implementing 0 remotable interfaces), I find it very
> odd that the client of such a
> service is not able to use that class as the type of the reference.
> 
> It has been stated that this is not possible, but instead the client
> must obtain or create an */interface class/*
> that implements "an interface that is compatible with the target
> implementation class".
> 
> If this is the case, then I think the average developer will think
we 
> have gone off our heads!  They will have
> a very hard time understanding why they cannot use the POJO class
> directly - and there are no easy tools
> that will build the implied interface.
> 
> I think that EITHER:
> 
> 1) We should suppress the ability for an unannotated implementation
> class to be treated as the definition of
> a service interface.
> 
> 2) We should permit the use of an unannotated implementation class
as 
> the definition of the interface for a
> reference.
> 

OR (3) require a clean separate of service interfaces and implementation
classes. I.e., all service contracts are specified only with Java 
interfaces.

-Anish
--

> 
> I recognise that option 2) may give SCA runtime implementations some
fun 
> in implementing what is required
> which may in turn cause there to be restrictions on the form of the
> unannotated POJO.  On the other hand let us
> remember that this can ONLY apply to local services that are certainly
> running in the same JVM as the client.
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
 
> Email:  mike_edwards@uk.ibm.com
> 
> 
> From:                
 Simon Nash <oasis@cjnash.com>
> To:                
 sca-j@lists.oasis-open.org
> Date:                
 30/04/2009 20:29
> Subject:              
   Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires
a 
> normative statement
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Simon Nash wrote:
>  > Dave,
>  > Thanks, this is a more useful way to express the issue.
>  >
>  > The question is whether one-way invocation is
>  >  1) a property of the service, that the reference
must obey
>  >  2) a property of the service, that the reference
can choose
>  >     whether to use or not
>  >  3) a property of the reference, that the service
doesn't
>  >     know is happening
>  >
> After a little bit of further thought, I think the answer has
> to be 1).  This is because the @OneWay annotation maps to a
> one-way MEP in the WSDL portType.  By the Assembly compatibility
> rules, if either the reference or the service uses a one-way MEP,
> then both sides would have to do this.
> 
> If we agree on this, the conclusion is that we do need to allow
> @OneWay on service implementation classes for the case where the
> service interface is defined using the implementation class.
> In this case, @OneWay would also need to be specified on the
> reference interface.
> 
>   Simon
> 
>  >   Simon
>  >
>  > David Booz wrote:
>  >> Thanks for clarifying. I see that you're questioning
the validity of
>  >> specifying @OneWay methods on service interfaces.
>  >>
>  >> I was a bit surprised to find that the Assemlby spec
doesn't say
>  >> anything about one-way/non-blocking behavior. There's
a hole here in
>  >> that another CI spec could define it as a service runtime
behavior,
>  >> resulting in no one performing the asynchronous dispatch.
Is this a
>  >> discussion we've had before?
>  >>
>  >> Java CAA certainly hints that it's the client runtime
(probably the
>  >> binding) which implements the behavior but we could
definitely make
>  >> this more explicit with RFC2119 words.
>  >>
>  >> 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 ---04/29/2009
05:12:29 PM---Mike
>  >> Edwards wrote: >Simon Nash ---04/29/2009 05:12:29
PM---Mike Edwards
>  >> wrote: >
>  >>
>  >>
>  >> From:  
>  >> Simon Nash <oasis@cjnash.com>
>  >>
>  >> To:  
>  >> OASIS Java <sca-j@lists.oasis-open.org>
>  >>
>  >> Date:  
>  >> 04/29/2009 05:12 PM
>  >>
>  >> Subject:  
>  >> Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires
a normative
>  >> statement
>  >>
>  >> ------------------------------------------------------------------------
>  >>
>  >>
>  >>
>  >> Mike Edwards wrote:
>  >>  >
>  >>  > Simon,
>  >>  >
>  >>  > So, if an unannotated Java POJO implements
only local interfaces
>  >> and is
>  >>  > introspected as a single local service
>  >>  > typed by the POJO class itself, as described
in JAVA CI spec sections
>  >>  > 2.3 and 8, what does the componentType
>  >>  > of that service look like and how would
a <reference/> element be
>  >>  > configured in order to invoke the service
offered
>  >>  > by a component using the unannotated POJO
as an implementation?
>  >>  >
>  >> The componentType of the service component would have
a <service>
>  >> element with <interface.java interface="name-of-the-impl-class"/>
>  >>
>  >> So far, so good.  On the reference side, things
get more tricky.
>  >> For example, if the reference is an injected field,
the type of
>  >> this field can't be declared in Java code with a type
of
>  >> "name-of-the-impl-class".  In order
for the SCA runtime to
>  >> successfully inject a reference proxy, the type of
the field
>  >> would need to be an interface type that is compatible
(in the SCA
>  >> sense) with the class that is used for the service's
interface.
>  >>
>  >> For any one-way methods that are part of the service
contract,
>  >> the @OneWay annotation would need to appear on that
method in
>  >> the reference's interface, so that the reference side
SCA runtime
>  >> would know that a non-blocking invocation is required.
>  >>
>  >> It is an interesting question whether or not @OneWay
would also
>  >> need to appear on the corresponding method of the service's
>  >> interface (aka impl-class).  The non-blocking
invocation is
>  >> performed on the reference side, so from that perspective
it
>  >> would make no difference whether or not @OneWay appears
on
>  >> the service side.  If the Assembly compatibility
rules required
>  >> matching one-way annotations on methods, this would
require @OneWay
>  >> to appear on the service side as well.  However,
the interface
>  >> compatibility rules as currently written don't require
this, so
>  >> the following would be legal:
>  >>
>  >> (on service side)
>  >>
>  >> public class MyServiceImpl {
>  >>     public void myAsyncMethod() {
>  >>         ...
>  >>     }
>  >> }
>  >>
>  >> (on reference side)
>  >>
>  >> public interface MyService {
>  >>     @OneWay
>  >>     public void myAsyncMethod();
>  >> }
>  >>
>  >> public class MyClientImpl {
>  >>
>  >>     @Reference
>  >>     protected MyService ref;
>  >>
>  >>     ...
>  >>     ref.myAsyncMethod(); // non-blocking
invocation
>  >>     ...
>  >> }
>  >>
>  >> In this example, it makes no difference whether or
not the
>  >> method myAsyncMethod() of MyServiceImpl has a @OneWay
>  >> annotation.
>  >>
>  >>   Simon
>  >>
>  >>  >
>  >>  > Yours,  Mike.
>  >>  >
>  >>  > Strategist - Emerging Technologies, SCA
& SDO.
>  >>  > Co Chair OASIS SCA Assembly TC.
>  >>  > IBM Hursley Park, Mail Point 146, Winchester,
SO21 2JN, Great 
> Britain.
>  >>  > Phone & FAX: +44-1962-818014  
 Mobile: +44-7802-467431   > Email:  
>  >> mike_edwards@uk.ibm.com
>  >>  >
>  >>  >
>  >>  > From: Simon Nash <oasis@cjnash.com>
>  >>  > To: sca-j@lists.oasis-open.org
>  >>  > Date: 28/04/2009 14:38
>  >>  > Subject: Re: [sca-j] [NEW ISSUE] Section
10.13 on @OneWay requires a
>  >>  > normative statement
>  >>  >
>  >>  >
>  >>  >
>  >> ------------------------------------------------------------------------
>  >>  >
>  >>  >
>  >>  >
>  >>  > The problem with this interpretation is
that @OneWay would need
>  >>  > to appear on the reference side, and a reference
must use a
>  >>  > Java interface and not a Java class.
>  >>  >
>  >>  >   Simon
>  >>  >
>  >>  > David Booz wrote:
>  >>  >  > +1
>  >>  >  >
>  >>  >  > 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 Mike
Edwards ---04/28/2009 08:59:22
>  >>  >  > AM---Simon, I don't think it
was the intention of the original
>  >> woMike
>  >>  >  > Edwards ---04/28/2009 08:59:22
AM---Simon, I don't think it 
> was the
>  >>  >  > intention of the original wording
of the spec to
>  >>  >  >
>  >>  >  >
>  >>  >  > From:        
        >  > Mike Edwards <mike_edwards@uk.ibm.com>
>  >>  >  >
>  >>  >  > To:        
        >  > OASIS Java <sca-j@lists.oasis-open.org>
>  >>  >  >
>  >>  >  > Date:        
        >  > 04/28/2009 08:59 AM
>  >>  >  >
>  >>  >  > Subject:      
          >  > Re: [sca-j] [NEW ISSUE]
Section
>  >> 10.13 on @OneWay requires a normative
>  >>  >  > statement
>  >>  >  >
>  >>  >  >
>  >> ------------------------------------------------------------------------
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  > Simon,
>  >>  >  >
>  >>  >  > I don't think it was the intention
of the original wording of
>  >> the spec
>  >>  >  > to permit the implementation
>  >>  >  > pattern that you describe below.
>  >>  >  >
>  >>  >  > I think that the case of class
methods being annotated was 
> there to
>  >>  >  > cover the case where the
>  >>  >  > whole class defines the interface
- as occurs for unannotated
>  >> classes
>  >>  >  > with purely local interfaces.
>  >>  >  >
>  >>  >  > Maybe I have this wrong, but
that is how I understand it.
>  >>  >  >
>  >>  >  >
>  >>  >  > Yours, Mike.
>  >>  >  >
>  >>  >  > Strategist - Emerging Technologies,
SCA & SDO.
>  >>  >  > Co Chair OASIS SCA Assembly TC.
>  >>  >  > IBM Hursley Park, Mail Point
146, Winchester, SO21 2JN, Great
>  >> Britain.
>  >>  >  > Phone & FAX: +44-1962-818014
Mobile: +44-7802-467431
>  >>  >  > Email: mike_edwards@uk.ibm.com
>  >>  >  >
>  >>  >  > From:        
         Simon Nash <oasis@cjnash.com>
>  >>  >  > To:        
         OASIS Java <sca-j@lists.oasis-open.org>
>  >>  >  > Date:        
         28/04/2009 12:43
>  >>  >  > Subject:      
           Re: [sca-j] [NEW ISSUE] Section
10.13 on
>  >>  > @OneWay requires a
>  >>  >  > normative statement
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >> ------------------------------------------------------------------------
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  > Mike,
>  >>  >  > I agree that this needs to be
made normative.
>  >>  >  >
>  >>  >  > I had always thought that @OneWay
applied only to interface
>  >> methods.
>  >>  >  > The reference to class methods
(in the original text and your
>  >> proposal)
>  >>  >  > surprises and intrigues me, because
this suggests that @OneWay
>  >> could
>  >>  >  > be applied to a service implementation
method without being
>  >> applied to
>  >>  >  > the corresponding interface method.
 If this is legal, it would
>  >> mean
>  >>  >  > that the client invokes the service
synchronously, and the service
>  >>  >  > returns back to the client immediately
and dispatches the method
>  >> for
>  >>  >  > subsequent execution.
>  >>  >  >
>  >>  >  > Do we want to allow this interaction
pattern?  If we do want to
>  >> allow
>  >>  >  > it, then I think we need to make
this more explicit in the text.
>  >>  >  >
>  >>  >  >  Simon
>  >>  >  >
>  >>  >  > Mike Edwards wrote:
>  >>  >  >  >
>  >>  >  >  > *** NB I am happy
for this new issue to be treated as a
>  >> comment on the
>  >>  >  >  > Public Review draft
- I just don't want this item lost ***
>  >>  >  >  >
>  >>  >  >  > Raiser:    
           Mike Edwards
>  >>  >  >  >
>  >>  >  >  > Target:    
           sca-javacaa-1.1-spec-cd02-rev6.doc
>  >>  >  >  >
>  >>  >  >  > Description:
>  >>  >  >  >
>  >>  >  >  > There is a sentence
in section 10.13 about @OneWay which in
>  >> effect
>  >>  >  >  > describes a normative
requirement but is not in the
>  >>  >  >  > form of a normative
statement:
>  >>  >  >  >
>  >>  >  >  > Lines 1923 - 1925:
>  >>  >  >  >
>  >>  >  >  > "The @OneWay
annotation is used on a Java interface or class
>  >> method to
>  >>  >  >  > indicate that invocations
will be dispatched
>  >>  >  >  > in a non-blocking
fashion as described in the section on
>  >> Asynchronous
>  >>  >  >  > Programming."
>  >>  >  >  >
>  >>  >  >  > This must be recast
into the form of a normative statement
>  >>  >  >  >
>  >>  >  >  > Proposal:
>  >>  >  >  >
>  >>  >  >  > Replace lines 1923
- 1925 with the following normative
>  >> statement:
>  >>  >  >  >
>  >>  >  >  > When a Java interface
method or a Java class method is
>  >> annotated with
>  >>  >  >  > @OneWay, the SCA runtime
MUST ensure that all
>  >>  >  >  > invocations of that
method are executed in a non-blocking
>  >> fashion, as
>  >>  >  >  > described in the section
on Asynchonous Programming.
>  >>  >  >  > [JCA90052]
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  > Yours,  Mike.
>  >>  >  >  >
>  >>  >  >  > Strategist - Emerging
Technologies, SCA & SDO.
>  >>  >  >  > Co Chair OASIS SCA
Assembly TC.
>  >>  >  >  > IBM Hursley Park,
Mail Point 146, Winchester, SO21 2JN, Great
>  >> Britain.
>  >>  >  >  > Phone & FAX: +44-1962-818014
   Mobile: +44-7802-467431   >  
>  >> >  > Email:  mike_edwards@uk.ibm.com
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  >
>  >>  >
>  >> ------------------------------------------------------------------------
>  >>  >  >  >
>  >>  >  >  > /
>  >>  >  >  > /
>  >>  >  >  >
>  >>  >  >  > /Unless stated otherwise
above:
>  >>  >  >  > IBM United Kingdom
Limited - Registered in England and Wales
>  >> with
>  >>  > number
>  >>  >  >  > 741598.
>  >>  >  >  > Registered office:
PO Box 41, North Harbour, Portsmouth,
>  >> Hampshire
>  >>  >  > PO6 3AU/
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >> ---------------------------------------------------------------------
>  >>  >  > 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_
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >> ------------------------------------------------------------------------
>  >>  >  > /
>  >>  >  > /
>  >>  >  >
>  >>  >  > /Unless stated otherwise above:
>  >>  >  > IBM United Kingdom Limited -
Registered in England and Wales
>  >> with number
>  >>  >  > 741598.
>  >>  >  > Registered office: PO Box 41,
North Harbour, Portsmouth, Hampshire
>  >>  > PO6 3AU/
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >  >
>  >>  >
>  >>  >
>  >>  >
>  >>  > ---------------------------------------------------------------------
>  >>  > 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
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >> ------------------------------------------------------------------------
>  >>  >
>  >>  > /
>  >>  > /
>  >>  >
>  >>  > /Unless stated otherwise above:
>  >>  > IBM United Kingdom Limited - Registered
in England and Wales with
>  >> number
>  >>  > 741598.
>  >>  > Registered office: PO Box 41, North Harbour,
Portsmouth, Hampshire
>  >> PO6 3AU/
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>  >
>  >>
>  >>
>  >>
>  >> ---------------------------------------------------------------------
>  >> 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
>  >
>  >
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU/
> 
> 
> 
> 
> 
>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU