Re: [sca-bindings] Re: Proposed resolution to issue BINDINGS-39

[Simon Nash <oasis@cjnash.com>]

Eric Johnson wrote:
> Hi Anish, Simon,
> 
> Anish Karmarkar wrote:
>> This assumes that a callback *address* is sufficient. In the case of
>> binding.ws, an optional correlation ID is also part of the protocol.
>>
>> Wouldn't it be easier to say what happens when the same protocol is
>> used for both forward and callback interface and leave mixing of
>> protocols undefined/extensibility point?
> Yes, except perhaps the word "protocol" is overloaded here.  Seems like
> you want define the behavior only if the same *binding* is used.
> 
I agree with this.  It would mean that the case that's left undefined
is when the binding type specified in the <callback> element is different
from the binding type configured for the forward direction.

   Simon

> -Eric.
>> -Anish
>> -- 
>>
>> Simon Holdsworth wrote:
>>> Folks,
>>>
>>> Following the comments on my proposed resolution to BINDINGS-39, I
>>> thought I would pull out the pieces of the proposal that refer to the
>>> possibility of use of other bindings.
>>>
>>> In writing this text I had envisaged a possible scenario where
>>> binding.jms is used for the forward interface, and some other binding
>>> used for callbacks; In this case the source component may want to
>>> pass a callback address to be used to send callbacks for that
>>> particular client - in this case the forward message would need to be
>>> able to carry this callback address, and it would typically be of a
>>> form not native to the forward binding.  e.g. a JMS message used to
>>> carry an HTTP callback address.
>>>
>>> Other than renaming scaCallbackDestination to scaCallbackAddress, the
>>> following paragraphs specifically mention the possibility of other
>>> bindings, but do not define behaviour when other bindings are used:
>>>
>>>     * "*/scaCallbackAddress/*" holds the address to which callback
>>>       messages are sent. This address is of an appropriate format for
>>>       the callback binding, for example for binding.jms a JMS
>>>       Destination name.
>>>
>>> The use of */JMSReplyTo/* for this purpose is to enable interaction
>>> with non-SCA JMS applications, as described below, and is only used
>>> when the callback binding is able to use a JMS Destination as the
>>> callback address.
>>>
>>> If the callback address is a JMS Destination the SCA runtime MAY also
>>> set the */JMSReplyTo/* destination to this value
>>>
>>> If the callback binding is binding.jms, the SCA runtime MUST set the
>>> */JMSReplyTo/* destination and correlation identifier in the callback
>>> request message as defined in sections 7.1 or 7.2 as appropriate for
>>> the type of the callback operation invoked.
>>>
>>>
>>> If people think that this is too problematic, then the other
>>> alternative is simply to add a statement that this protocol is only
>>> valid when both forward and callback binding is binding.jms and leave
>>> it at that...  In that case I would expect the same to apply to the
>>> web service binding definition of callbacks.
>>>
>>> Regards, Simon
>>>
>>> Simon Holdsworth
>>> STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC
>>> Chair
>>> MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
>>> Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
>>> Internet - Simon_Holdsworth@uk.ibm.com
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> /
>>> /
>>>
>>> /Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with
>>> number 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>> PO6 3AU/
>>>
>>>
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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 
> 
> 
>