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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Java" <sca-j@lists.oasis-open.org>
- Date: Thu, 7 May 2009 15:32:21 +0100
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]