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
>
>
