Simon,
I think it great that you're trying to tackle this problem and it seems like
You're on the right track. My only suggestion (at this point) is to first
get the runtime back to where it was before .90 from the perspective
of the SCA app, if that's possible.
Only one comment embedded below.
Dave
----- Original Message -----
From: "Matthew Sykes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, June 19, 2007 8:44 AM
Subject: Re: Supporting callbacks across Web Services
I did notice that the code that is responsible for creating the callback
wires / invocation chains out of createWires on the service side is
currently commented out in the CompositeActivatorImpl. When that code is
uncommented I found that the callback proxy was injected as there were
callback wires associated with the service. Even when the proxy is
injected, the rest of the issues you've raised still come into play.
I'm interested in the progress you make here as I'm also trying to figure
out how to make callbacks work when the callback target is not local to
the composite containing the service. Right now it seems that callbacks
only work when the reference and service are associated with components in
the same composite as the callback target. I think some of this is due to
how Tuscany treats the concept of the default binding and extends it to
hold a direct reference to the target component associated with the
binding.
In particular, within the CompositeActivatorImpl, the createWires method
that deals with the reference side will create the callback wires with
endpoint references that hold pointers to the runtime components on both
sides of the wire. With the target service in hand, you can add the
callback wire to the service side as is done at the end of createWires.
Since the wire deals with RuntimeComonent instances on the source and
target, everything works fine with an implementation interceptor.
When the implementation interceptors are not added and only the binding
interceptors exist on the wire, I'm not sure how to connect up the two.
Simon Nash wrote:
In my investigations into TUSCANY-1341, I'have fixed a few minor
blocking defects (see my updates to the JIRA) and I'm now getting
to the heart of the problem. I think the right approach is to do
this in a similar way to callbacks over direct local wires, with
the forward call proceeding as normal and a callback proxy being
injected on the service side to make a reverse call back to the
client instance using the same Web services connection thar was
used for the forward call from client to server. This isn't the
approach used by the current code.
So far I have got this path working as far as the attempt to call
back using the service's proxy. The code to inject this proxy
isn't working properly yet.
I'm not yet sure how callbacks should be mapped to the protocol
used by the Web services connection. There need to be standard
mappings for this, or SCA callbacks won't interoperate with
non-SCA Web service endpoints.
The SCA specs intentionally avoided starying into WS-* spec space.
In order to get to interoperability, the industry would need a
WS-Callback spec. You'll find the same thing to be true of
conversations (when you get there in the scope of callbacks). I know
this doesn't help you implement it, but I thought the background
would be helpful.
I'm hoping Axis2 provides a way
to call back from a server to a client over an already established
connection, but I haven't looked into this in detail yet.
I'm hoping my fix will support callback from both two-way methods
and one-way methods. (The spec seems to imply that both of these
are valid.) The two-way case seems harder because the callback
invocation will be sent back on the wire before the forward
invocation has returned its response message.
This will be hard when using an HTTP transport. Getting back
to simply supporting oneways will be a challenge.
If it's too hard
to do this, I may back off and only support callbacks from
one-way methods for now. This seems to present challenges as well,
because I'm not sure whether the connection is guaranteed to
remain active after the one-way call has been made and the server
method is running.
Before I go further down this path, I would welcome any comments
on the above issues and whether my basic approach is sound.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Matthew Sykes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
