sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] Re: ISSUE 18 - Clarify the rules on which queues andtopics are used for responses and callbacks
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Thu, 10 Jan 2008 13:26:12 +0000
Folks,
Unless I've misunderstood the new wording,
I think there is a problem with the proposal here -
comments inline as <mje>...</mje>
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
Simon Holdsworth/UK/IBM@IBMGB
09/01/2008 13:22
|
To
| sca-bindings@lists.oasis-open.org
|
cc
|
|
Subject
| [sca-bindings] Re: ISSUE 18 - Clarify
the rules on which queues and topics are used for responses and callbacks |
|
Here's the proposal for issue BINDINGS-18
http://www.osoa.org/jira/browse/BINDINGS-18
Solution proposal:
Messages sent from a JMS reference with a response queue have the JMS replyTo
queue set to the response queue name. For messages received by a service,
by default the replyTo, if present, overrides any defined response element.
If scaCallbackQueue is present in a message, the callback binding destination
is ignored. Clarify that in the callback/conversation section that the
use of replyTo and service callback queue are there for interacting with
non-SCA applications
Specific updates, referencing sca-jmsbinding-1.1-spec-WD-01.pdf:
Section 4, JMS Binding Schema, line 175/176, replace with the following
text:
/binding.jms/response – defines the resources used for handling response
messages. References use this element to define the resources used to receive
responses, in which case the replyTo destination in messages sent from
such a reference should be set to the identified destination. Services
use this element to define the resources used to send responses. In
this case the replyTo destination in messages received by such a service,
if present, should be used in preference to the destination element.
<mje>
I had to scan these words
many times before I grasped the meaning. So let me try and spell
it out to see if it can be made clearer:
When a Reference communicates
with a Service using JMS, there is the need to consider the case where
the message exchange pattern is request/response. In particular,
when the service receives the request message, it needs to know where to
send the response message - and when using JMS, this means defining the
destination resource to which the response messages are sent.
The destination resource
for the response messages can be defined in a number of ways:
1) For a message sent from
a reference, the resource for the response messages may be carried in the
replyTo destination in the message itself
For an SCA reference, the
value of the replyTo destination can be set by the reference using its
/binding.jms/response attribute. If one is not set, the SCA runtime
will generate one automatically.
2) Where a service receives
a message without a replyTo destination specified (typically from a sender
outside the SCA domain), the responses are sent to the destination resource
identified by the /binding.jms/response attribibute of the service. If
no destination is specified by either means, it is an error and an exception
is raised.
....did I get it right???
</mje>
Section 7.2, line 282-291, replace with the following text:
When an SCA component with a reference with a bidirectional interface and
JMS binding ("the sender") invokes an operation on that interface,
the JMS message that is sent may identify the target for callbacks using
the "scaCallbackQueue" user property, or for one way operations
the JMS replyTo header may be used, to allow a level of interoperation
with non-SCA JMS applications.
<mje> I'm probably
being a bit slow here, but a) why do we need a separate scaCallbackQueue
if JMS replyTo can also be used? and b) why are one way operations
different from request/response ?
</mje>
The invoked SCA component ("the receiver") can only invoke operations
on the callback interface during the execution of the target operation
for such a message, or when the service's callback binding identifies a
fixed callback queue.
<mje>
I'm having real trouble
with this notion. Basically, this way of thinking about callbacks
does not jive with the Assembly view of callbacks, in my opinion.
Let's see if I can explain
the gist of it:
Where there is a service
interface with a callback, all that SCA says is that IF an operation is
called on the service, then the service may call back to the invoker, using
any of the operations in the callback interface - and that the invoker
is expected to supply those operations. SCA does NOT say which of
the operations are called, how many operations are called (0, 1, many are
allowed), what order they are called or how long it will take to complete
those calls.
Now, that phrase "can
only invoke operations on the callback interface during the execution of
the target operation" is a problem. It is perfectly reasonable
to consider a service provider that has some long running process which
is invoked by a client - and the initial invocation operation will complete
and return long before the process itself is completed (think "days").
It should be reasonable for the provider component to access the
callback object (thinking in Java implementation terms for a moment) on
the initial invocation and for the provider to store that callback object
for later use. The callback object should have all the information
needed to execute a successful invocation of any of the callback operations
- and should also allow for any number of operations to be invoked at any
later time. With this, it is clear that there should NOT be a limit
on when the callback operations can be invoked - all that is necessary
is that the callback information is preserved until it is needed.
So, bascially, I don't
agree with the phrase.
</mje>
If the received message includes a value
for the scaCallbackQueue, then that should be used in preference to any
that may be defined on the service's callback binding. Note that the use
of a fixed callback queue is primarily for interaction with non-SCA JMS
applications, as SCA JMS applications should set the scaCallbackQueue JMS
user property.
<mje>
What if scaCallbackQueue
is NOT present, but replyTo is set?
</mje>
The sender's callback queue can be specified on the reference's JMS callback
binding, or it can be left to the runtime to provide one, by omitting the
callbackService element, the JMS callback binding, or omitting the uri
and destination from the JMS callback binding.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]