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