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:]
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:
"Peshev, Peter"
<>
16/01/2008 10:22
To
Simon Nash/UK/IBM@IBMGB,
<>
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:]
Sent: Tuesday, 15. January 2008 23:45
To:
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" <>
05/10/2007 14:23
To
"Peshev, Peter" <>,
<>
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:]
Sent: Friday, October 05, 2007 2:30 AM
To:
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:]
Sent: Thursday, 4. October 2007 21:03
To:
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:]
Gesendet: Mittwoch, 26. September 2007 15:43
An:
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
