[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: > 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. The service gets to decide what the values of wsa:Action and wsa:RefPs are, so it *could* decide to make them unique and 'route' it based on those values. I mention that because a lot of implementations do route based on the value of wsa:Action/payload. But I agree that it is the wsa:RelatesTo that is guaranteed to provide the ability to distinguish between the two. But then again, this has nothing to do with the callback protocol. This situation can occur between two components that both offer services and use WSA anon as reply-to values. > >>> >>>> 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? > This is no different than the sync req-res case (client *not* behind a firewall): how does the client know to keep listening on the callback address? This is general problem with async stuff. How do you know that you are done (either wrt listening or polling)? > 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? How does the client know, in the non-MC case to keep listening? Forever? > >>> 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. > I support writing up how these things work. But we have to keep in mind that we are really writing a primer for how MC works in various scenarios. I don't mind having an appendix that talks some of this in summary form. But detailed discussion should really be pulled out in a primer or some sort. > 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 >> >> > > > > --------------------------------------------------------------------- > 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]