OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


Simon,

I think that it is 1), except that "must obey" is a strange wording for it
- "one way" says that the client must expect no response of any kind from the service operation.
- it does affect both client and service provider since it is ALSO saying to the service end to
honour the one way MEP
- the client "takes advantage" of this by not hanging around for any response.

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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]