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: Fw: [sca-j] ISSUE 25 - Callback Simplification



I'm forwarding this to the list on behalf of Michael R.  He's unable to post directly at the moment.

    Simon

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

----- Forwarded by Simon Nash/UK/IBM on 03/04/2008 16:43 -----
"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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]