[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normativestatement
Simon,
I agree with you that it has to be (1). I don't see how it could ever be
(3) -- how does a service advertise and implement a fire-and-forget
method (queuing scenario) that may or may not have reliability
guarantees? The reference side and the service side must have the same
view wrt whether a method is one way or not. @Oneway annotation can
affect bindings.
This is a separate issue, but there is no RFC2119 statement about the
fact that the one-way method return type must be void and not have any
declared exceptions. It is mentioned in section 7.1 but without any 2119
keywords. In any case, I think it should be part of section 10.13
-Anish
--
Simon Nash wrote:
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]