Re: [sca-bindings] Issue 2: proposal v11

[David Booz <booz@us.ibm.com>]

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



The response for req msg is ONLY obtained by: what's in the ???? empty body+MC headers? Same as first message?

[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:booz@us.ibm.com

Anish Karmarkar ---03/05/2009 04:11:13 AM---Simon Nash wrote: > See comments inline.

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	Simon Nash <oasis@cjnash.com>
Cc:	OASIS Bindings <sca-bindings@lists.oasis-open.org>
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