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:35:53 +0100
Anish,
I think your 3) is much the same as
my 1)....
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:
| Anish Karmarkar <Anish.Karmarkar@oracle.com>
|
To:
| Mike Edwards/UK/IBM@IBMGB
|
Cc:
| sca-j@lists.oasis-open.org
|
Date:
| 02/05/2009 00:29
|
Subject:
| Re: [sca-j] [NEW ISSUE] Section 10.13
on @OneWay requires a normative statement |
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.
>
> 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/
>
>
>
>
>
>
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]