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

["Peshev, Peter" <peter.peshev@sap.com>]

Hi Mike,

 

After some thinking I would support that resolution as well, mainly because it's much simpler.

 

Recently we have been discussing quite a lot of  callbacks on assembly, java, even bindings.  The fact that even the TC members can not understand each other and there is need for long clarifications  seems like a red flag to me for the overall complexity. Just my two cents.

 

Best Regards

Peter

 

 

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Friday, 1. February 2008 13:03
To: OASIS Java
Subject: RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified

Folks, 

Perhaps unsurprisingly, I support Simon's proposal to use 
my resolution to this issue! 

I think 
it IS simpler.  I understand the point that Peter is trying to cover, but 
my view of the 
case where the client 
code supplies a different callback object is that this is only a matter 
of convenience.  The client HAS to support 
the callback in some way, otherwise it is an 
error - not allocating the callback ID until the callback object is set 
does not really help 
in any way that I 
can see.  The callback object MUST be set before first invocation of 
the forward interface.  Equally if the 
client wants to set the callbackID itself, that can be 
done at any time before first invocation. 


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

Simon Nash/UK/IBM@IBMGB

31/01/2008 16:00

To	"OASIS Java" <sca-j@lists.oasis-open.org>
cc
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







---------------------------------------------------------------------
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