Next in thread →
Next in month →
RE: [sca-j] ISSUE 11: Semantics of getCallbackID() are underspecified
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:]
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:
Simon
Nash/UK/IBM@IBMGB
31/01/2008 16:00
To
"OASIS Java"
<>
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"
<>
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:
"Peshev, Peter" <>
17/01/2008 12:02
To
Mike Edwards/UK/IBM@IBMGB, "OASIS Java"
<>
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:]
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
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
Next in thread →
Next in month →