OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



Mike,
At first sight this idea seems appealing.  On closer scrutiny, I don't think it fits with the normal semantics of Futures.  When the Future receives a callback, the only thing it can do is pass the callback on to the calling component (B).  It can't support polling or blocking because the very nature of a callback is to do something rather than just returning a result as is the case for a normal Future.  Given this, what's the value of putting an intermediary (a Future object) between the callback initiator C and the callback recipient B?

If the Future is to do more than simply forward callback messages from C to B, then it will need to have business methods to handle the callback semantics.  This is not how Futures currently work.  Mixing infrastructure behaviour and business logic on the Future object doesn't seem like a good idea to me.

Alternatively we could limit callbacks so that they follow a simple setter pattern, and have the Future provide those methods together with corresponding getter methods for the client to use to support polling and blocking.  This is very different from the callback concept that we have in SCA today.  It would require extra mechanisms to create the appropriate setter and getter method implementations on the Future object.  This mixture of limited functionality and extra complexity is not very appealing.

Could you use Example 2 in my proposal to show how the Future approach would work, listing all the flows and objects involved?

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Mike Edwards/UK/IBM@IBMGB

04/04/2008 12:03

To
"OASIS Java" <sca-j@lists.oasis-open.org>
cc
Subject
RE: [sca-j] ISSUE 25 - Callback Simplification






Folks,


I agree with Simon's analysis.


For callbacks, it should in general be possible to make multiple "overlapping" forward calls from a client to a given service.


If such overlapping calls are made, then it is important for the client to be able to distinguish the asynchronous response messages

resulting from each forward call.


This must either be done in business data, as shown in Simon's example forward & callback interfaces, or it must be done through

infrastructure - equivalent to the "callbackID" that was part of our model.




I would like to point out a "simpler approach" to the case that Simon describes below for "callbackID".  I've talked about this before

to some of you but I've never written it down and shared it with everyone on the list.


An alternative and simpler approach to functionality equivalent to "callbackID" is to use the design of the "JAX-WS" asynchronous

client API - ie have a form of the forward API call that returns a Future<?> - the Future represents the communication from the client to

the service.  The client invokes this async form of the forward API and gets the Future.  When asynchronous responses are

received from the service, they flow not to the client itself, but instead flow to the Future object (which implements the callback

interface).  The Future object reports these responses back to the client by the usual means for a Future (polling, blocking or

callback method invocation).


This dispenses with the need for callbackIDs.  What flows with the forward messages is simply an EPR for the Future object - and

this is used on each callback (under the covers, by the infrastructure).  When the response message arrives back at the client,

it is the Future object that gets the reply message.  The Future object then does what it does.


This approach has the virtue of marrying together both forms of client asychronous API - that for async client to a synchronous
service (ie the standard JAX-WS async client to a sync service) and that for an async client to an async service.


One beauty of this approach I note is that it works even where the originating forward call is itself call-and-return.  In that case,

the API for that forward call simply follows the form dictated by the JAX-WS async rules.  Where the service also has callbacks,

the only difference is that the returned Future is a more complex one - one that will report on all the responses from the service.



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 Nash/UK/IBM@IBMGB

03/04/2008 17:13


To
mrowley@bea.com
cc
sca-j@lists.oasis-open.org
Subject
RE: [sca-j] ISSUE 25 - Callback Simplification








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


To
sca-j@lists.oasis-open.org
cc
 
Subject
[sca-j] ISSUE 25 - Callback Simplification

 


   








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











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]