sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-j] ISSUE 25 - Callback Simplification
- From: Simon Nash <NASH@uk.ibm.com>
- To: mrowley@bea.com
- Date: Thu, 3 Apr 2008 17:13:06 +0100
There's a basic problem with this approach.
Whether or not B has conversational scope depends on its interactions
with A. In a single A to B conversation, the same conversational
instance of B might place 5 orders with C. Using the A to B conversation
ID to identify the order that was placed is therefore never safe, even
if B is conversational.
The only way this approach could work
is if B were to generate a new "callback conversation ID" for
every request that it sends to C. This would be different from any
regular conversation ID that B may be sending to C as part of a B to C
conversation. Here are the steps that would need to be followed.
1. B generates a new "callback
conversation ID" and associates it with its reference for C. This
needs to happen before any calls to C are made.
2. An API needs to be defined to allow
B to get this "callback conversation ID" before it makes the
placeOrder() call to C. B stores the "callback conversation
ID" and associates it with the order it is placing.
3. B makes a placeOrder() call to C.
4. The SCA infrastructure transmits
the "callback conversation ID" from B to C with the placeOrder()
call.
5. C stores the "callback conversation
ID" in the callback reference so that it can be returned to B in any
callbacks.
6. C makes a callback to B.
7. The SCA infrastructure transmits
the "callback conversation ID" from C to B with the callback.
8. An API needs to be defined to allow
B to get this "callback conversation ID" when the callback is
executing. This ID is different from the conversation ID that's active
for the A to B conversation.
All of the above are not needed if the
correlation information is passed as business data, which is a much simpler
approach.
I considered this approach when I was
trying to come up with a good definition of conversational callback interfaces
between the 3/20 and 3/27 calls, but I rejected it because I did not believe
that the value justified the complexity.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Michael Rowley"
<mnrowley@gmail.com>
03/04/2008 15:40
Please respond to
mrowley@bea.com |
|
To
| Simon Nash/UK/IBM@IBMGB, sca-j@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [sca-j] ISSUE 25 - Callback Simplification |
|
I like the fact that, in Simon's
model, callbacks always go back to the instance that made the outbound
call. However, it looks like he does not take advantage of that fact
in the interfaces of the examples that he created. For example, he
has the following:
@Callback(OrderCallback.class)
public interface Order {
void placeOrder(String
orderID, String orderData);
}
public interface OrderCallback {
void confirm(String
orderID);
void update(String
orderID, String status);
}
However, since you know that
the order callback goes back to the right instance, you should be able
to define the callback interface as follows:
public interface OrderCallback {
void confirm();
void update(String
status);
}
In Simon's model this should
be possible, but there is a catch. If the callback interface is defined
this way, the client has to use a conversational scope. If the client
is stateless or composite scoped, then the routing of the callback to the
right instance doesn't say anything useful about what is being confirmed.
I would like to enable this
style of callback interface irrespective of the scope of the client. As
with Simon's approach, if the client is conversational scoped, then the
client is especially simple and does not have to do any correlation at
all. However, if the client needs to use some other scope, for whatever
reason, then the service with the callback can still be used. However,
it just needs to get the callback ID (or conversation ID) that is associated
with the callback in order to determine what the callback is talking about.
Michael
From: Simon Nash [mailto:NASH@uk.ibm.com]
Sent: Thursday, March 27, 2008 11:47 AM
To: sca-j@lists.oasis-open.org
Subject: Re: [sca-j] ISSUE 25 - Callback Simplification
There's an update to this proposal at
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27733/JAVA-25-Proposal-2.doc
This version removes conversational callbacks as all my attempts to define
these involve more complexity than is justified by the functional value
of this capability.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Simon Nash/UK/IBM@IBMGB
20/03/2008 11:01
|
|
Last week I took an action to produce a written up proposal for callback
simplification by today. I have uploaded this to the document repository
as
http://www.oasis-open.org/apps/org/workgroup/sca-j/download.php/27649/JAVA-25-Proposal.doc.
The content of this proposal corresponds to the "Callback Simplification"
section of the proposal sent out by Michael R, and does not address the
changes proposed in the "API Simplification" section. I
think it is best to have these discussions separately.
This proposal corresponds to what I was describing at the sca-j F2F with
two changes / additions:
1. Outstanding callbacks don't pin conversational objects after the conversation's
creator has ended the conversation.
2. In all cases, the caller of a bidirectional interface creates the callback
EPR that will be used (including any reference parameters needed).
I believe the issues that still need to be discussed and resolved are as
follows:
a) Should all 4 combinations of conversational and non-conversational forward
and callback interfaces be allowed, or only 2 of these?
b) Should the callback interface used to make callbacks to a conversation-scoped
component be marked as conversational?
c) Should each forward request within a conversation generate a unique
ID that is not part of business data and is returned with the callback?
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
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
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]