[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 2: proposal v11
David Booz wrote: > Just so that I'm clear, is it true that any given: > > [HTTP req msg + MC] --> Service > > could be answered by any one of: > > [HTTP res msg + callback req] <-- Service > > OR > > [HTTP res msg (2xx) + empty entity body] <-- Service > This is part of the MC protocol. If there is a pending message (for a match for the MC anon URI) you respond to the poll with the pending message (in this case the callback req). If there is no pending messsage then you return a 202 with empty enity body. > > > The response for req msg is ONLY obtained by: what's in the ???? empty > body+MC headers? Same as first message? > Not sure what you mean. The term 'req msg' is overloaded here. Perhaps we can talk about this on the call. -Anish -- > [HTTP req msg + ????] --> Service > [HTTP res msg (2xx) + resp msg] <-- Service > > > > > 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 Anish Karmarkar ---03/05/2009 04:11:13 > AM---Simon Nash wrote: > See comments inline.Anish Karmarkar > ---03/05/2009 04:11:13 AM---Simon Nash wrote: > See comments inline. > > > From: > Anish Karmarkar <Anish.Karmarkar@oracle.com> > > To: > Simon Nash <oasis@cjnash.com> > > Cc: > OASIS Bindings <sca-bindings@lists.oasis-open.org> > > Date: > 03/05/2009 04:11 AM > > Subject: > Re: [sca-bindings] Issue 2: proposal v11 > > ------------------------------------------------------------------------ > > > > Simon Nash wrote: > > See comments inline. > > > > Simon > > > > Anish Karmarkar wrote: > >> Eric Johnson wrote: > >>> There's one point that I tripped on. At the very end, with the example > >>> using "WS-MakeConnection", you say: > >>> > >>> "3) Callback request message (from the service to the reference) > sent as > >>> a “response” to MakeConnection" - Doesn't it need to be simply > "callback > >>> message (from the ..." - I don't see an opportunity for a > >>> request/response exchange here." > >>> > >> > >> The reason "response" is in quotes is because this would be a response > >> at the transport/transfer protocol level. When using HTTP, the > >> MakeConnection SOAP messages is sent with the HTTP request, the SCA > >> callback request message is sent back on the HTTP response. > >> > >>> Do we need to flag, at the first introduction of WS-MakeConnection, > that > >>> it can only be used for one-way operations on the callback interface? > >>> > >> > >> It can be used with a WSDL req-response operation on the callback > >> interface. This is similar to how WSDL req-res operation works when > >> the wsa:ReplyTo is non-anonymous. In the case of req-res SCA callback > >> operation, the message exchange will consists of 2 separate HTTP > >> connection as follows: > >> > >> 1.1) Reference --> [HTTP req msg + MC] --> Service > >> 1.2) Reference <-- [HTTP res msg + callback req] <-- Service > >> > >> 2.1) Reference --> [HTTP req msg + callback res] --> Service > > > > > How does the service know that this message contains a callback response > > rather than a new service request? > > The payload should tell the service that. > Plus you have wsa:Action wsa:RelatesTo and wsa:RefPs. > > > > >> 2.2) Reference <-- [HTTP res msg (2xx) + empty entity body] <-- Service > >> > > What if the original service request is request/response? This messsage > > would need to carry the response to that request, not an empty entity > body. > > Is this possible? > > > > Not when using WS-MC. > The original service request's wsa:ReplyTo will have to be respected. > That wsa:ReplyTo would be a WS-MC anonymous, which would require the > service to send the response to the original request as a response to a > MC request. > > > Another possibility is that the service sends a second callback request. > > I presume this is OK, and that it would be addressed to the same > > MC endpoint as the first callback request. > > > > Yes, in theory. > But in practice, this would be an interop nightmare, I would think. The > reference component would have to expect such a piggy-backed 2nd > callback request and process it. Since this wasn't a HTTP response to a > MC request, it may not have expected this message and may not process it. > > > To clarify what happens for all these cases, I think we need to add some > > interaction flow diagrams (similar to the above) for all the one-way and > > req-res combinations. > > > > Hmm. I don't know, since we don't write WS-* specs (although we do write > specs that walk and quack like it), don't you think having the > WS-Callback stuff be longer than the binding.ws part would be a problem? ;-) > > -Anish > -- > > > Simon > > > >> -Anish > >> -- > >> > >>> -Eric. > >>> > >>> Anish Karmarkar wrote: > >>>> Thanks for the comments. Mostly agree with all of them. > >>>> > >>>> -Anish > >>>> -- > >>>> > >>>> Simon Nash wrote: > >>>>> Anish, > >>>>> My comments are inline in the attached document. > >>>>> > >>>>> Simon > >>>>> > >>>>> Anish Karmarkar wrote: > >>>>>> Attached. > >>>>>> > >>>>>> I accepted changes from v10 and made additional changes as I was > >>>>>> tasked to do during the last call. This should address all the > >>>>>> comments/issues so far except for one, which is the name of the > >>>>>> WS-Policy assertion. > >>>>>> > >>>>>> I have changed it from sca:CallbackAssertion to sca:WSCallback. My > >>>>>> rationale for this is: > >>>>>> 1) 'Assertion' is redundunt, so removal just makes it shorter and > >>>>>> shorter is better. > >>>>>> 2) This is a callback mechanism that is defined for Web services. > >>>>>> Other bidnings/technologies that are used in SCA may have a > >>>>>> different mechanism for callback so the previx 'WS' makes sense. > >>>>>> This constrains it to the realm of Web services. > >>>>>> > >>>>>> The other suggestion that was made by Mike was > >>>>>> sca:CallbackAssertion_WSA. I prefer a WS (or WSA) prefix rather than > >>>>>> a suffix and the underscore is unnecessary. So I suppose another > >>>>>> alternative would be 'sca:WSACallback'. > >>>>>> > >>>>>> -Anish > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> > ------------------------------------------------------------------------ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> 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 > >>> > >>> --------------------------------------------------------------------- > >>> 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]