[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
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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]