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:
>
> 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 <>
>
> To:
> Simon Nash <>
>
> Cc:
> OASIS Bindings <>
>
> 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
>
>
>
