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

[Simon Nash <oasis@cjnash.com>]

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?

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

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.

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.

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