[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Re: Proposed resolution to issue BINDINGS-39
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. -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]