I thought of a slightly different approach that would be closer
to the current code.
reference myService
interface contract
forward binding interface
callback binding interface
forward binding.ws
binding interface contract
forward binding interface
null callback binding interface
(other forward bindings)
callback binding.ws
binding interface contract
null forward binding interface
callback binding interface
(other callback bindings)
I'll see how I get on with this.
Simon
Simon Nash wrote:
I am making good progress with getting callbacks working across the
Web Service binding. In the process of doing this I have learned a lot
about SCA callbacks and the Tuscany runtime. So far the code changes
I have made are all fairly minor, and working out what is needed has
been a good learning experience.
My changes are divided into two categories:
1. fixing some bugs in the core runtime framework for supporting
callbacks when bindings are involved
2. reinstating the code in the Web Service binding that handles
callbacks.
I see the latter as a temporary solution only and I intend to look
into how to make callbacks using WS-Addressing which would be the
correct way to fully support SCA callback semantics.
I have now run into an architecture/design issue and I'd like to
explain it and get some reactions.
My frst attempt to find the binding interface information for a
callback was to use a naming convention that the callback interface
PortType name must be <interfacename>Callback, where <interfacename>
is the name of the PortType for the regular interface. I did this
because I thought the Web Service binding spec did not provide enough
information to obtain the callback interface from the SCDL. It turns
out that the spec does have a way to provide this information.
A reference that uses a bidirectional interface can be defined as:
<reference name="myService" target="MyServiceComponent">
<interface.java interface="simplecallback.MyService"
callbackInterface="simplecallback.MyServiceCallback"/>
<binding.ws
wsdlElement="http://simplecallback#wsdl.port(MyServiceSoapService/MyServiceSoapPort)"/>
<callback>
<binding.ws
wsdlElement="http://simplecallback#wsdl.binding(MyServiceCallbackSoapBinding)"/>
</callback>
</reference>
where the callback binding interface is specified in the <binding>
element within the <callback> element.
Now we come to the issue that I mentioned earlier. The forward binding
and the callback binding in the above SCDL are different bindings.
In the model, they would be represented as:
reference myService
interface contract
forward binding interface
callback binding interface
forward binding.ws
binding interface
(other forward bindings)
callback
callback binding.ws
binding interface
(other callback bindings)
Now contrast this with the model we currently have in Tuscany. We would
need to represent the above as:
reference myService
interface contract
forward binding interface
callback binding interface
binding.ws
binding interface contract
forward binding interface
callback binding interface
(other bindings)
The problem with the latter is that there's no place to put the callback
binding. In the example above, they are both Web Service bindings, but
they don't have to be. The forward and callback binding types could be
different (e.g., Web Service for forward calls and JMS for callbacks),
and the Tuscany core runtime should support this. Of course, having this
kind of a mixture would require suitable enablement in the binding
providers as well. But even if the forward and callback bindings are
both Web Service bindings, we will need to have two distinct bindings
for these when we move to the correct WS-Addressing implementation.
At the moment I'm proceeding under the assumption that Tuscany should
implement the spec in this area, so in my testbed I'm changing the
model from the latter to the former. This will have some minor impact
in various parts of the code (and probably one or two SPIs) so I'd welcome
comments and opinions on whether this is the correct path to follow.
Simon
scabooz wrote:
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]
