sca-j message
[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
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Fri, 1 May 2009 09:14:03 +0100
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]