RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified

[Simon Nash <NASH@uk.ibm.com>]

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