[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Re: [sca-assembly] [ISSUE 33] Updated Proposalfor Issue 33
Mike, >I think I agree that you can't really mix > callbacks and this new "long running" async style of service. Why not? I think it should be possible. asyncInvocation is just a req-res where the response is sent over a separate connection. This is independent of callbacks. Yes, it is possible to do a asyncInvocation using callbacks and one-way operations. But the critical difference here is that the asyncInvocation consists of only one reply/response. -Anish -- Mike Edwards wrote: > > Folks, > > Comments inline... > > 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 Holdsworth/UK/IBM@IBMGB > To: sca-assembly@lists.oasis-open.org > Date: 19/11/2008 11:09 > Subject: Re: [sca-assembly] [ISSUE 33] Updated Proposal for Issue 33 > > > ------------------------------------------------------------------------ > > > > > Mike, > > My initial reaction to this is that it conflicts with the existing > conversational support, although I see that there is a new issue to > remove that support from the spec. If that doesn't get accepted, are > you comfortable with the spec including all of callbacks, conversations > and async invocations? > > *<mje> * > *I'm not sure what the conflict is, although as you say, this may be a > moot point. However, I don't view this "long running" support as being > much different to callbacks. I think I agree that you can't really mix > callbacks and this new "long running" async style of service. Mixing > with conversational seems no more complex than mixing conversations with > callbacks (yes, there is complexity there, I agree).* > *</mje>* > > The text says: "the binding must be able to treat the transmission of > the request message separately from the transmission of the response > message, with an arbitrarily large time interval between the two > transmissions.". Does that leave space for an implementation to include > timeouts, or to hold correlation information non-persistently? Even for > HTTP some amount of asynchonous invocation is possible, at least from > the point of view of the interacting components, although the connection > would be lost if either party terminates or some comms error occurs. > *<mje>* > *Not sure I follow your point about HTTP providing "some amount of > asynchronous invocation" unless you mean that HTTP can wait for a > limited time for a response - like a small number of minutes. What I am > trying to say is that if a service is marked as "long running" then the > binding CANNOT assume that a "small number of minutes" is going to cut > it. The proposal says that the binding MUST assume that the response > will be a separate transmission at some arbitrarily later time* > *</mje>* > > I'd note that for the web services example given, the non-anonymous > response URI allows a client of a service to act asynchronously, but it > does not mean that the service itself will dispatch the request on its > target component and handle the response asynchronously. > *<mje>* > *Not quite sure what point you're making here. * > > *As far as the target component is concerned, the whole point of the > marking of the interface is that it indicates that the service > operations are going to be "long running" implying "asynchronous". For > the service to be able to do this, the implementation type MUST be able > to support such a concept - if it can't then tough, you can't implement > the service in that language. HOW it is done is up to the > implementation language specs. In the examples for Java that are in one > of the documents that I sent out, there are examples of two alternatives > - one based on standard Java method calls with responses provided via > return values in the normal way, the other based on using a callback > reference to dispatch the response message. Frankly, the first of these > depends on the calling thread blocking and waiting at some point which > is pretty fragile and would not be my choice in most cases. The second > way allows for the callback to be stored into a database and retrieved > at some later point whenever the asynchronous activities complete - much > more likely to be robust. * > > *Whether other languages can support some style(s) equivalent to these > is up to the relevant implementation TCs to decide.* > *</mje>* > > Regards, Simon > > Simon Holdsworth > STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair > MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK > Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898 > Internet - Simon_Holdsworth@uk.ibm.com > > *Mike Edwards/UK/IBM@IBMGB* > > 19/11/2008 10:51 > > > To > "OASIS Assembly" <sca-assembly@lists.oasis-open.org> > cc > > Subject > [sca-assembly] [ISSUE 33] Updated Proposal for Issue 33 > > > > > > > > > > > > Folks, > > Here is an updated version of the proposal for Issue 33 following the > discussion on the call yesterday: > > > > > This is the version that I am sending to the other TCs. > > Note that the current Assembly specification does not define the > requirements that bidirectional interfaces place on bindings, so the > text in this proposal is the first place that this is defined for the > Assembly specification. > > > 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/ > > > > > > [attachment "2008-11-12 - SCA-Assembly Issue 33 - Proposal_2.doc" > deleted by Mike Edwards/UK/IBM] [attachment "2008-11-12 - SCA-Assembly > Issue 33 - Java Mapping_2.doc" deleted by Mike Edwards/UK/IBM] > --------------------------------------------------------------------- > 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]