[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Issue 2: proposal v11
Anish, This is a useful discussion. See responses inline. Simon Anish Karmarkar wrote: > 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. > I presume this is the normal wsa:RelatesTo for replies and not the new callback relationship that SCA is defining. It would be useful to point this out explicitly. I don't think either wsa:Action or wsa:RefPs could be used to distinguish these cases, as they are both possible for requests and replies. >> >>> 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. > OK, I agree that the service can't send a response to the original request as part of the 2.1/2.2 message exchange. However, I think it's possible to support two-way service requests and multiple callbacks by having the client keep sending MC requests until the service sends back the response to the two-way service request. Here's an example of using this approach for a two-way service that makes two callbacks: 0.1) Reference --> [HTTP req msg + service req] --> Service 0.2) Reference <-- [HTTP res msg (2xx) + empty entity body] <-- Service 1.1) Reference --> [HTTP req msg + MC] --> Service 1.2) Reference <-- [HTTP res msg + callback1 req] <-- Service 2.1) Reference --> [HTTP req msg + callback1 res] --> Service 2.2) Reference <-- [HTTP res msg (2xx) + empty entity body] <-- Service 3.1) Reference --> [HTTP req msg + MC] --> Service 3.2) Reference <-- [HTTP res msg + callback2 req] <-- Service 4.1) Reference --> [HTTP req msg + callback2 res] --> Service 4.2) Reference <-- [HTTP res msg (2xx) + empty entity body] <-- Service 5.1) Reference --> [HTTP req msg + MC] --> Service 5.2) Reference <-- [HTTP res msg + service res] <-- Service The problem with this is that there's no good way for the service to make callbacks after the two-way service request has returned. The client could keep sending MC requests, but how does it know how many to send and when to stop sending them? A similar problem applies to one-way service requests. How long does the client keep sending MC requests? Your MC example shows a single callback. How does the client know whether it should stop sending MC requests after one callback? What if the service makes zero callbacks? Will the client poll endlessly for a callback that will never happpen? >> 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. > See above for a suggested protocol that I think solves this problem. >> 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? > ;-) > We definitely need to call out which parts of SCA callback semantics can be supported with MC and which can't be. At the moment I think I know how to support any number (0 or more) of callbacks within a two-way request. I don't know how to support callbacks for a one-way request or after a two-way request has completed, without imposing some arbitrary restriction like requiring there to be exactly one such callback. Simon > -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]