Re: [sca-j] ISSUE 25: Detailed proposal for non-conversational callbacks

[Mike Edwards <mike_edwards@uk.ibm.com>]

Jim,

Could correlation of Callbacks be done
entirely with Business Data?

The answer is an emphatic "yes".

It isn't as simple as you make out in
your example.  The business interface would
have to provide a data field which allows
the labelling of each forward request
("let me dub this "requestID")
and an equivalent field in each callback operation
which is available to indicate for which
forward request this callback is a response.

This would very likely NOT be some business-related
field like "OrderID", for the very
simple reason that multiple forward
and callback operations might relate to the same
OrderID.  In general, there IS
a need for the client to be able to work out which response
relates to which request..  A simple
example:

- envisage a service which allows 1)
Creation of an order 2) Adding items to an order
3) Cancelling an Order

- envisage that there is the possibility
of calling operations 2) and 3) and getting
"RequestRejected" as a response
(presumably due to some aspect of the request not being valid)

- clearly, any response to 2) and 3)
will contain the OrderID - but unless the client
is told whether the rejection is from
a 2) request or a 3) request, then the client will
not know the true state of play.  A
requestID is essential - and the service MUST copy
the requestID from the forward call
to the response - otherwise the client is hosed.


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

Jim Marino <jim.marino@gmail.com> wrote on 08/08/2008
22:22:36:

> [image removed] 
> 
> Re: [sca-j] ISSUE 25: Detailed proposal for non-conversational callbacks
> 
> Jim Marino 
> 
> to:
> 
> OASIS Java
> 
> 08/08/2008 23:10
> 
> Hi Simon,
> 
> I question the utility of CallableReference and believe having the
> runtime perform this type of correlation introduces more complexity
> for developers than delegating to application code. So, I'd like us
> to consider a simple alternative: requiring the application to flow
> specific callback correlation as operation data. Of course, the 
> runtime would still be responsible for callback routing, i.e. 
> dispatching to the correct client instance. This may come as a 
> surprise given my proposal for conversations, but it is one case 
> where I believe application code can handle correlation in a more
> elegant and straightforward fashion. 
> 
> I prefer this approach for the following reasons:
> 
> 1. It is easier and more readable from the application developer 
> perspective (shown below)
> 
> 2. This alternative explicitly acknowledges coupling of the client
> and service provider via callback correlation in the service 
> contract. When a client and service provider are coupled via shared
> state, the @Conversational annotation is used to declare that on the
> service contract. When a client and service provider are coupled via
> a bidirectional interface, the @Callback annotation is used to 
> declare that on the service contract. When a client and service 
> provider are coupled via callback correlation, there is nothing 
> analogous in your proposal. My alternative would declare that 
> coupling as part of the service contract, in the operation signatures.
  
> 
> 3. This alternative would add very little to the spec and allow us
> to remove a bunch of extraneous APIs that are not needed. 
> 
> 4. It avoids the distinction in API usage for stateless and 
> conversational scoped components introduced in your proposal. I 
> provide an example of where this is the case in my comments below.
I
> believe that distinction will lead to confusion and is error-prone
> for developers. 
>  
> 5. It is much easier to test out-of-container.
> 
> I've in-lined alternative examples using this approach to illustrate
> these points.
> 
> Jim

---

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