Sure, we can move the code into trunk.
As you pointed out, with JAX-WS, we now have two sets of "pipeline": the
Tuscany invocation chain and JAX-WS handler chain. I assume some of the
binding specific processing with go into the JAX-WS handler. But there is a
possibility that we configure JAX-WS with a generic Tuscany handler that can
delegates processing to our binding invocation chain.
FYI: I found a good article which describes the JAX-WS handlers.
http://www.javaworld.com/javaworld/jw-02-2007/jw-02-handler.html
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Friday, March 12, 2010 9:28 AM
To: <[email protected]>
Subject: Re: [2.x] binding.ws as a JAX-WS provider/client
On Tue, Mar 9, 2010 at 1:00 PM, Simon Laws <[email protected]>
wrote:
On Mon, Mar 8, 2010 at 6:01 PM, Raymond Feng <[email protected]> wrote:
Hi,
+1 to explore the idea further. IMO, it will allows any JAX-WS compliant
stack to be plugged into Tuscany for binding.ws. We can support the
JAX-WS
from JDK6, CXF, Axis2 without too much tweaks between the different
implementations.
I reactivated the work to use JAX-WS APIs to implement binding.ws in my
sandbox [1] recently. The reference binding is working for a basic
sample. I
recently added some code on the service binding side, but I didn't have
chance to bring it up yet.
[1]
http://svn.apache.org/repos/asf/tuscany/sandbox/rfeng/binding-ws-jaxws/
Just took a look at the code in your sandbox. On the service side
there is a JAX-WS provider similar to the one a referenced earlier in
the thread. You've taken it further and registered the provider as a
JAX-WS endpoint. I'd like to try this in trunk by adding a new service
binding provider to effect this registration.
I'm particularly interested in whether this approach presents any
restrictions on our ability to configure the binding in terms of
transports or policy. Only way to really find out is to try it;-)
Haven't looked at the client side yet.
Regards
Simon
Hi
Have been playing with JAXWS support in the JVM and in Axis2 today to
improve my understanding. I'd certainly like to get your code into
trunk. Maybe we should take it as is as it's nicely encapsulated. Or
would you rather I played with it in your sandbox (or even took a copy
of it).
I'm particularly interested in the various layers involved here. This
it motivated by thinking about how to get policy working with this
kind of integration. On the service side a message arrives and passes
through various pieces.
Axis (or CxF, or JVM etc)
======>
Jaxws Provider
===========>
Tuscany operation chain
=================>
If we are to use JAXWS only then I guess we have to push policy in
through the service WSDL. However reading the mail lists it seems
that, if we want to use Axis, there are various limitations in relying
on this approach.
Some of our processing for ws has, to date, relied on variously
- conditionally configuring the Axis2 configuration context - for
example, turning on the security modules/configuration
- manipulating the axis transport configuration - for example, to get
at HTTP security credentials
- processing messages in the binding wire - copying out callback IDs
Message processing sits nicely on the Tuscany side of the Jaxws
provider but it's difficult to tell what Axis specific processing or
Jaxws handlers we need, if any, without trying to implement some of
this.
Simon
