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