Re: Proposed resolution to issue BINDINGS-39

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Folks,

Following the discussion on Wednesday's
call, and the general feeling that any change that enables different forward
and callback binding is likely to open a can of worms, here's my updated
proposal:

Section 6.4: Callbacks, add sentence
to the end of :

"SCA runtimes MUST follow the behaviour
described in this section and its subsections when binding.jms is used
in both the forward and callback directions.  SCA runtimes MAY use
different bindings for forward calls and callbacks, however the behaviour
and requirements on messages is vendor-specific."

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

__________________

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

---

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