[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified
I agree with Peter that we would have to answer these tricky questions if we allow redirection of callbacks. I also agree with Mike that it is better (for many reasons) to outlaw this redirection and adopt a simple resolution to this issue. If we agree to do this, the simplest possible resolution seems to be what Mike proposed: - - - - start Mike's proposal - - - - 1. I think it is simpler if the callbackID is ALWAYS present on both reference proxies and also on ServiceReference objects from the moment they are created. so getCallbackID() always returns a valid callbackID 2. Regarding the case where the communication protocol forces the use of some specific form of the ID that can only be known at the time of first invocation, then I would suggest that a mapping is done from the application-level callbackID to a protocol specific ID, this mapping being done somewhere in the binding code (for both outward bound and return mesages) - - - - end Mike's proposal - - - - Peter proposed a slight change to this, to not create the callbackID until a local callbackObject is set in the cases where this is necessary. - - - - start Peter's proposal - - - - If we say that callbackId should be coupled to the callback as its name suggests, maybe we can say that the getCallbackId becomes available as soon as the callback can be determined. I.e. if a component doesn't implement the callback interface, than a ServiceReference.getCallbackId() should return null, until the callback is properly set. After it is set then serviceReferenceComponentA.getCallbackId() should return the id of the set callback. - - - - end Peter's proposal - - - - My opinion is that we should go with Mike's proposal because it is simpler to explain and understand, and equivalent for all practical puposes. I would like to handle the discussion about unifying the callbackId and conversationID separately. I am working on a proposal to simplify callbacks and conversations (a follow-on to the Assembly TC F2F discussion on this) and I think this question should be handled as part of that discussion. Simon Simon C. Nash, IBM Distinguished Engineer Member of the IBM Academy of Technologack Mike Edwards/UK/IBM@IBMGB 21/01/2008 17:41 To "OASIS Java" <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified Peter, You ask good questions. I'm not sure that I ever understood the reason for providing the capability to redirect the callback to another component. It looks complex to me - and your questions are directed right at the complexity it causes. I'd vote for removing this capability. If someone thinks that this complex capability is of sufficient use, perhaps they would help us all by providing a comprehensive write up of how it is all supposed to work, including the answers to the questions below. 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 "Peshev, Peter" <peter.peshev@sap.com> 17/01/2008 12:02 To Mike Edwards/UK/IBM@IBMGB, "OASIS Java" <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified Hi Mike, Good points for conversation / callbackId, I have raised new issue for that on the binding TC I agree that the callbackId need to be somehow available before the forward call, otherwise its main use (data correlation) becomes useless. The question is whether we want to tie it to ServiceReference and its lifecycle or to the Callback representation. Normally the component that will do the forward call will receive the callback, however it is possible to redirect the callback at runtime to another component. (not a feature that I like, but that's another issue) So, imagine the following sequence of invocations : 1) serviceReferenceComponentA.getCallbackId(); // that is returned as X 2) serviceReferenceComponentB.getCallbackId(); // that is returned as Y 3) serviceReferenceComponentA.setCallback(serviceReferenceComponentB)) // now all the callback calls made as a result of the forward call from component A will go back to B 4) serviceReferenceComponentA.getCallbackId(); // what should be returned here ?? If we say that callbackId should be coupled to the callback as its name suggests, maybe we can say that the getCallbackId becomes available as soon as the callback can be determined. I.e. if a component doesn't implement the callback interface, than a ServiceReference.getCallbackId() should return null, until the callback is properly set. After it is set then serviceReferenceComponentA.getCallbackId() should return the id of the set callback. Best Regards Peter From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Wednesday, 16. January 2008 14:45 To: OASIS Java Subject: RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified Folks, Here is my pennyworth: 1. I think it is simpler if the callbackID is ALWAYS present on both reference proxies and also on ServiceReference objects from the moment they are created. so getCallbackID() always returns a valid callbackID 2. Regarding the case where the communication protocol forces the use of some specific form of the ID that can only be known at the time of first invocation, then I would suggest that a mapping is done from the application-level callbackID to a protocol specific ID, this mapping being done somewhere in the binding code (for both outward bound and return mesages) 3. For the question as to whether we need both a callbackID and a conversationID. I note that the usage of these two IDs is very similar. - callbackID is used to relate one or more messages received on the callback interface to a previous message sent out through a reference invocation - conversationID is used to relate subsequent messages received by a service provider and also the subsequent responses received by the client The two IDs may interact since a conversation may be conducted through a callback style asynchronous interaction pattern. Is it possible to combine these two IDs into one? I'm not sure that they can. My concern is over the potentially different lifetimes of these IDs: a) callbackID logically can get changed for EACH invocation of a forward call on a reference - if this isn't done, then it is impossible to differentiate the responses received as a consequence of successive invocations on the reference b) conversationID gets a new value whenever a new conversation starts. This point is vague - a conversation may be started by any one of the forward invocations on a reference. It is also be terminated by some other invocation on the reference. Logically, the conversationID can live across a whole series of requests, If asynchronous callbacks are used between client and provider there is also still the question of associating a given callback message with a particular request message - multiple requests may be part of the same conversation but the callback messages still may require some differentiation (I'm making the assumption that a given callback message may result from more than one request). It's this last case that seems to demand that conversationID is separate from callbackID. 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 "Peshev, Peter" <peter.peshev@sap.com> 16/01/2008 10:22 To Simon Nash/UK/IBM@IBMGB, <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified Hi Simon, Some loud thinking on that issue: In order for that scenario to work, the callbackId must be transported by the binding together with the parameters for the forward / backwards calls. Some binding offer extensibility (JMS message properties) however some other binding must try to map SCA system data (including callbackId) to its own concept and header fields. (Unless an implementation would wish to alter the interface and add the id as parameters). So far so good, but potentially some bindings/transport protocols may be able to generate such ID only after the first message sending (i.e. the forward call) , and not accept a general one generated before the invocation. Although when having only 3 official bindings I don't think such situation is present at the moment. Not directly relevant to the issue, but when looking at that scenario and speaking for data correlation and emulating conversation by the client managing its own state, I admit I am not that sure whether callbackId and conversationId should be the same and should map to one and the same field in the underlying binding (if present). The spec says : " .... the client may like to use a feature such as the conversationID to keep track of any state data relating to the conversation. " If we say yes they are the same, as a consequence for bidirectional interfaces annotated with @conversational, the runtime is responsible for managing the state of the conversations as well as ensuring that ServiceReference.getConversationID () and ServiceReference.getCallbackID () is one and the same. If we say those two can be different, I guess we will need to think of two placeholders for that. (An issue for the binding tc, the JMS spec for example only defines scaConversationId, no callbackId ) Your thoughts ? Best Regards Peter -----Original Message----- From: Simon Nash [mailto:NASH@uk.ibm.com] Sent: Tuesday, 15. January 2008 23:45 To: sca-j@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified I recently had to write a component implementation that does this, and it turns out that returning null at point 4 and non-null at point 6 doesn't work. Suppose I am going to use the callback ID to correlate some state within my component. After I make the forward call at point 5, the callback can arrive at any time (including before point 6), so I must have saved the callback ID (together with its associated state) corresponding to the call at point 5 before making the call (i.e., before point 5). This implies that the call at point 4 must return non-null. Now consider the following sequence of events: 7) A type-safe reference (proxy) is created by injection. 8) A ServiceReference is created from the type-safe reference by ComponentContext.cast(). 9) getCallbackID() is called on the ServiceReference. 10) A service call is made through the type-safe reference. For the same reason as above, the call at point 9 must return non-null. In this case, this call is made immediately after creating the ServiceReference. This seems to imply that a newly created ServiceReference should return a non-null callback ID from the first call to getCallbackID() that is made. Having consistent rules for the two scenarios is desirable. This would mean that the call at point 2 in the original scenario would also return non-null. Putting all this together, getCallbackID() would never return null. Simon Simon C. Nash, IBM Distinguished Engineer Member of the IBM Academy of Technology Tel. +44-1962-815156 Fax +44-1962-818999 "Michael Rowley" <mrowley@bea.com> 05/10/2007 14:23 To "Peshev, Peter" <peter.peshev@sap.com>, <sca-j@lists.oasis-open.org> cc Subject RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified I was thinking that some bindings may have the client-side choose the ID, while others (where there is a synchronous exchange with the first message) may have the service provider provide the id. But looking at it more carefully, I see that both scenarios would result in the same client-visible behavior (null at 4, and non-null at 6). Michael -----Original Message----- From: Peshev, Peter [mailto:peter.peshev@sap.com] Sent: Friday, October 05, 2007 2:30 AM To: sca-j@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified Hi, I fully agree with the proposal, but I am not sure I understand the concern of Michael raised during the meeting that different bindings may behave differently. I would expect that the only interraction with the binding will happen at point 5 when the proxy will invoke it, and before that everything should be one and the same and there is no problem to specify the semantics. @Michael - is there something that I am missing ? Best Regards Peter -----Original Message----- From: Barack, Ron [mailto:ron.barack@sap.com] Sent: Thursday, 4. October 2007 21:03 To: sca-j@lists.oasis-open.org Subject: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified http://www.osoa.org/jira/browse/JAVA-11 -----Ursprüngliche Nachricht----- Von: Simon Nash [mailto:NASH@uk.ibm.com] Gesendet: Mittwoch, 26. September 2007 15:43 An: sca-j@lists.oasis-open.org Betreff: [sca-j] NEW ISSUE: Semantics of getCallbackID() are underspecified TARGET: Java Common Annotations and APIs specification, section "Java API" / {"CallableReference"} DESCRIPTION: The getCallbackID() method description doesn't specify the initial state of the returned value and the events that cause this value to change. Consider the following sequence of events: 1) A ServiceReference is created, either by injection or by ComponentContext.getServiceReference(). 2) getCallbackID() is called on the ServiceReference. 3) A type-safe reference (proxy) is created from the ServiceReference by CallableReference.getService(). 4) getCallbackID() is called on the ServiceReference. 5) A service call is made through the type-safe reference. 6) getCallbackID() is called on the ServiceReference. It seems reasonably intuitive that call 2) will return null and call 6) will return the system-generated callback ID that was used for the service call. It's less clear what call 4) will return. Does the system-generated callback ID get created and set into the ServiceReference as part of event 3) or as part of event 5)? The description of the getCallbackID() method should describe a "state model" for how the value returned would change based on other actions. PROPOSAL: At point 2) the value returned will be null. At point 4, it will still be null, At point 6), it will be the system-generated callback ID that was used for the service call 5). This information should be stated explicitly in the description of getCallbackID(). 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 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]