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