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
