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

["Meeraj Kunnumpurath" <mkunnumpurath@googlemail.com>]

Simon,

Thanks for your kind response, pls see my comments inline.

Thanks
Meeraj

On Wed, Aug 13, 2008 at 4:33 PM, Simon Nash <NASH@uk.ibm.com> wrote:

Meeraj,
Thanks for these comments and questions.  My responses are inline as <scn>....</scn>.

    Simon

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

"Meeraj Kunnumpurath" <mkunnumpurath@googlemail.com>

12/08/2008 16:38

To	Simon Nash/UK/IBM@IBMGB
cc	sca-j@lists.oasis-open.org
Subject	Re: [sca-j] ISSUE 25: Detailed proposal for non-conversational callbacks

Simon,

Sure, I thought I had replied to the TC list, anyway I have copied.

Thanks
Meeraj

On Tue, Aug 12, 2008 at 10:09 AM, Simon Nash <NASH@uk.ibm.com> wrote:

Meeraj,
These are good comments and questions and I'm sure other TC members will be interested in the discussion.  Are you OK if I copy the sca-j list on my response?

   Simon

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

"Meeraj Kunnumpurath" <mkunnumpurath@googlemail.com>

11/08/2008 23:30

To	Simon Nash/UK/IBM@IBMGB
cc
Subject	Re: [sca-j] ISSUE 25: Detailed proposal for non-conversational callbacks

Simon,

I have a few questions/comments on the proposal, both from a user's and implementor's perspectives, if you could kindly clarify.

1. From the title of the note I assume, the proposal is for callbacks to composite and stateless components, both synchronous and otherwise.

<scn>Yes.</scn>

2. Correlation is important on asynchronous callbacks, as multiple callbacks can come out of order, where as with synchronous callbacks, clients don't need any additional information for correlation as one forward call would result in one or more synchronous callbacks (may be not for composite scope components).

<scn>I don't think this is correct.  There could be multiple synchronous callbacks in progress on different threads, with each of them issuing callbacks.  If a callback needs to be correlated to a forward call, it needs to carry the identity of that forward call, as there could be multiple forward calls in progress at the same time.</scn>

I assume multiple synchronous callbacks coming back on to the same component instance is applicable only for components in the composite scope? With stateless components, currently callbacks are received on an instance different to the component that initiated the forward call. From your code example, each time we create an instance of the CallableReference, the reference to it is stored in an instance variable by the user code. When a callback comes in, the callable reference stored in the instance variable is compared against what is retrieved from the request context. In case of stateless components, since the callback is going to come on a different instance of the component to the one which initiated the forward call, the instance variable in which the callable reference was stored by the user code during the foward invocation will be null. With composite components, as multiple threads are performing the forward invocation, each will b overwriting the instance variable that stores the callable reference. So I dont see how this will work for both stateless and composite components, unless I am missing something obvious.

3. With stateless components, both synchronous and asynchronous callbacks are going to come to a different instance than the component that actually made the forward invocation. So, any instance information (like the callable reference), wouldn't be of any use for correlating the callback to the forward call.

<scn>Callable references can be compared for equality.  They can also be sent across business interfaces (with their identity preserved).  So any stateful component in the domain could perform this correlation, using the original callable reference (sent to it by the stateless instance that made the forward call) and the callback's callable reference (sent to it by the stateless instance that received the callback).</scn>

Could you pls explain, how a stateless component that is making a forward call and acting as the callback, could use CallableReference for correlating forward and callback calls? My understanding is that for stateless components, callbacks dont come on the same instance that initiated the forward call.

4. For composite components, unless we use some smart proxy on the callable reference, there is a potential threading issue in using any instance information for correlating callbacks. Also, any business state stored as instance variables on composite components would be inherently thread unsafe.

<scn>I'm not quite sure I understand the point you are making here.  The threading issues that we have with the current APIs are resolved by this proposal, as all callable references are immutable.  To transmit a request with a different identity, a new callable reference must be created.  There is no operation to set a new identity into a callable reference, which would cause threading problems as you describe.  For correlation information such as a table of pending requests and immutable identifiers for them, there are many Java techniques for handling such data in a thread-safe way.</scn>

In the code example, the callable references are stored into instance variable explicitly by the user code. So with composite scope components in a multi-threaded scenario, how do we ensure each thread doesn't overwrite the reference written by another thread?

5. In my opinion, the semantics of correlating forward and callback invocations belong to the user domain and should be achieved using user data, rather than using the API.

<scn>It could be done that way.  My earlier proposal (see http://www.oasis-open.org/apps/org/workgroup/sca-j/email/archives/200803/msg00064.html) did exactly that.  However, my current proposal has the advantage that each client of a service can choose whether or not it needs per-call correlation, without affecting the service's interface or implementation.  This provides a clean separation between what the service needs and what the client needs, thus reducing client/service coupling.  The other approach of adding user data for correlation purposes means that if a service chooses to support correlation, every client of that service must always pass the correlation data, even if it doesn't require correlation.  (See Mike E's recent email on this topic.)</scn>

To take your example, you call service to order a given quantity of fruit and the service callas back confirming just the number. Semantically from a business perspective, I would say the service contract for the callback would include the type of fruit and the confirmed quantity. Both of these are information recognizable within the business domain and can be used for supporting the business need of confirming the number of a given type of fruit ordered using SCA callbacks. I would say as a user, in most of the cases correlation between forward and callback invocations are to meet certain business needs and are often achieved using business data.

As a general point, may I express my genuine concern (which I have already expressed in a previous thread) of bleeding technology API (like CallableReference) into the user code. As a user, I would always want the technology to be non-invasive, and being able to provide whatever infrastructure it provides to be transparent to the user code.

<scn>This proposal keeps that to an absolute minimum.  We already have APIs for a client to use a CallableReference object to make an invocation and for a service to obtain a CallableReference object representing its invocation.  This proposal is a small extension of those existing APIs.  It also allows the current APIs that manipulate callback IDs to be removed, while providing equivalent functionality.  Overall I believe it's a simplification of what is currently in the API.</scn>

Please forgive my ignorance here, is this only for clients from a non-SCA domain accessing SCA services, or clients from the SCA domain accessing SCA services?

Kind regards
Meeraj

On Thu, Aug 7, 2008 at 11:43 PM, Simon Nash <

NASH@uk.ibm.com> wrote:

Here is a proposed semantic model for callbacks that is independent of implementation type or binding type.

Insert the following text after line 2455 in the SCA Assembly spec, CD01 rev1.

A call from a client component to a service that is defined using a bidirectional interface element (a bidirectional service) conceptually carries the following information in additional to its business data.  The actual form of the information that is passed from client to service depends on the binding that is used for the wire connecting the reference and the service.

The information passed is as follows:

1. A callback address that the service can use to make callback invocations on the client.  This MUST either be a physical address such as a network-addressable endpoint to which callback invocations are made, or a logical identifier that can be used by the client to identify a callback that it is expected to process (for example, if the client obtains callbacks by polling).  This address MUST be present on every service invocation, and MUST be generated by the client.

2. An invocation identifier that the client can use to correlate callback invocations with service invocations that it has made previously.  This identifier MAY be present on a service invocation, as decided by the client.  If it is present, it MUST be generated by the client.  If a bidirectional service receives an invocation containing this identifier, the service MUST attach the same invocation identifier to all callbacks that are semantically associated with that service invocation, as determined by the service's business logic.  SCA runtimes MUST support client-side comparison of invocation identifiers for equality or inequality with other invocation identifiers.

The generation of a callback address is determined by the binding in use, and is described in the relevant binding specification.  The generation and comparison of invocation identifiers by a client is determined by the client's language implementation, and is described in the relevant implementation specification.  The association of callback invocations to service invocations is determined by the service's language implementation, and is described in the relevant implementation specification.

- - - - - - - - - - - - - - - - -

Here is a proposed Java language binding for the above semantic model.

For a Java client of a bidrectional service, the invocation identifier is determined by the CallableReference object that was used for the invocation.  This is the CallableReference object that would be obtained by invoking the ComponentContext.cast() API on the type-safe proxy through which the invocation was made.  If a client wishes to attach a different invocation identifier to a subsequent invocation, it does this by calling the CallableReference.createCallableReference() API to create a new CallableReference object, and using this CallableReference object to make the subsequent invocation.  The CallableReference object returned by createCallableReference() MUST have an invocation identifier that differs from the invocation identifiers of the original CallableReference object and all other CallableReference objects created from that object by invoking its createCallableReference() method.

The following example code snippet illustrates the simple case where the same invocation identifier is passed on every invocation:

@Remotable
@Callback(OrderConfirm.class)
public interface FruitStore {

  void orderFruit(String type, int quantity);

}

@Remotable
public interface OrderConfirm {
  void confirmOrder(boolean accepted);
}

@Reference
private FruitStore store;

private int confirmed;

public void placeOrder() {

  store.orderFruit("apples", 12);  // passes the invocation identifier for the CallableReference object associated with the "store" proxy

  store.orderFruit("apples", 24);  // passes the same invocation identifier

}

public void confirmOrder(int available) {

  confirmed += available;
}

The following example code snippet illustrates the ability to pass a different invocation identifier on every invocation for correlation purposes:

@Reference
private CallableReference<FruitStore> store;

private CallableReference<FruitStore> appleOrder;
private CallableReference<FruitStore> plumOrder;
private int confirmedApples;
private int confirmedPlums;

public void placeOrders() {

  appleOrder = store.createCallableReference();  // creates a new CallableReference object with its own invocation identifier

  appleOrder.getService().orderFruit("apples", 12);  // passes the invocation identifier for appleOrder

  appleOrder.getService().orderFruit("apples", 24);  // passes the same invocation identifier

  plumOrder = store.createCallableReference();  // creates a new CallableReference object with its own invocation identifier

  plumOrder.getService().orderFruit("plums", 12);  // passes the invocation identifier for plumOrder

}

@Context
ComponentContext context;

public void confirmOrder(int available) {

  CallableReference<FruitStore> ref = context.getRequestContext().getServiceReference();

  if ref.equals(appleOrder) {
      confirmedApples += available;

  } else if ref.equals(plumOrder) {

      confirmedPlums += available;
  } else {
      // should not happen
  }
}

For a Java bidirectional service, the invocation identifier for a callback made by that service is determined by the CallableReference object that was used for the callback invocation.  This is the CallableReference object that would be obtained by invoking the ComponentContext.cast() API on the type-safe proxy through which the callback invocation was made.  When the SCA runtime injects a proxy or a CallableReference object for a callback, or returns a CallableReference object from the RequestContext.getServiceReference() API, the CallableReference object MUST be associated with the invocation identifier from the service call, and the SCA runtime MUST use this invocation identifier for all callback invocations made though any proxy for which the ComponentContext.cast() API would return this CallableReference object.

The following example code snippet illustrates the use of an injected proxy to obtain the callback reference.  This coding style is useful for stateless-scoped service implementations.

@Callback

OrderConfirm confirm;  // captures the invocation identifier passed on this call

public void orderFruit(String fruit, int quantity) {

  confirm.confirmOrder(quantity);  // passes back the invocation identifier

}

The following example code snippet illustrates the use of the RequestContext object to obtain the callback reference.  This coding style is useful for composite-scoped or conversation-scoped service implementations.

@Context
ComponentContext context;

public void orderFruit(String fruit, int quantity) {

  CallableReference<FruitStore> ref = context.getRequestContext().getServiceReference();  // captures the invocation identifier passed on this call

  OrderConfirm cbRef = ref.getCallback();

  cbRef.confirmOrder(quantity);  // passes back the invocation identifier

}

- - - - - - - - - - - - - - - - -

The above proposed Java API also requires the following spec changes or clarifications to the JavaCAA spec:

1. Object identity round-tripping and state sharing for ComponentContext.cast() <--> CallableReference.getService().  This would become the resolution for JAVA-10.

2. Addition of a getCallback() method to CallableReference.

3. Changing the semantics of RequestContext.getServiceReference() when called within a callback method, so that this API returns a CallableReference object for the service method that made the callback invocation.

  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