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: sca-j@lists.oasis-open.org
- Date: Thu, 7 May 2009 15:48:30 +0100
Simon,
In response to your comment:
"I don't
see how one-way semantics could be supported
for an invocation though a reference whose type is a Java class.
The reference would have to contain an instance of the class, and
a method call through the reference would execute the implementation
method synchronously rather than asynchronously."
This depends on the strategy for dealing
with these object-defined interfaces - for local interactions,
the runtime can muss up a proxy object
that subclasses the original object, captures all methods
and forwards invocations to a separate
target object, which in principle permits asynchronous
operation. That does require the
original object class to be subclassable, of course.
However, thinking about this further,
given that one-way async interaction style is not a normal programming
idiom for pure Java, it may be simpler
to completely suppress the ability to have @OneWay apply to a
Java class - it can only be done for
interfaces. This cannot adversely affect existing Java classes
that were never designed for remote
services-style operation - and Java classes designed with
that in mind should be using @Remotable
style interfaces in the first place.
I will send out a new proposal embodying
that idea...
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:
| 02/05/2009 11:41
|
Subject:
| Re: [sca-j] [NEW ISSUE] Section 10.13
on @OneWay requires a normative statement |
Anish Karmarkar wrote:
> 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.
>>
The use of a Java class to define a service contract isn't limited
to local services. The resolution to JAVA-134 has made it possible
for @Remotable to be applied to a service implementation class that
is used as an SCA service contract.
Even if we were to reverse JAVA-134 to prevent @Remotable from being
used in this case, I don't see how one-way semantics could be supported
for an invocation though a reference whose type is a Java class.
The reference would have to contain an instance of the class, and
a method call through the reference would execute the implementation
method synchronously rather than asynchronously.
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: 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/
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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]