You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/12/11 04:45:35 UTC
SOAP encoded support
A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
support, and it went so well that it got me thinking that it would be
great to use CXF for JaxRPC support as well. When I met Dan Kulp at
ApacheCon, I mentioned this idea and he figured the biggest road
block for implementing JaxRPC is supporting RPC/Encoded. So, last
weekend I had some free time and decided to try to hack SOAP encoded
support into CXF, and to my surprise it wasn't to difficult add Aegis
Types to support the SOAP strut and reference classes.
SOAP encoded struct support is provided by the StructType subclass of
BeanType. I did have to extract a few methods from the writeObject
method to hook element writing. I also had to make a couple of
methods more public.
As for how it works, the best place to start is the StructTypeTest.
Basically, read and write follow the same pattern:
1) read/write message parts with the SoapRefType
2) read/write trailing serialized blocks with TrailingBlocks
As each object is read we check if it contains a SOAP id attribute,
and if it does we register it with the SoapRefRegistry in the
context. If an element contains a SOAP ref attribute we register a
ref that is "set" when the reference is resolved (which my be
immediately or later).
When writing, every complex object is given a SOAP id and every
reference to another complex object is written as a reference. The
actual referenced object registered with the MarshalRegistry in the
context and is written by the TrailingBlocks class.
I've attached my patch to (https://issues.apache.org/jira/browse/
CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
WDYT?
-dain
Re: SOAP encoded support
Posted by Daniel Kulp <dk...@apache.org>.
Dain and I had several really good chats at ApacheCon. One of the most
exciting things about attending events like ApacheCon is the
brainstorming that goes on when you get a bunch of really smart people
in a room together. (and adding some alcohol usually helps :-)
One of the things I've heard from several people is that if you need
JAX-RPC support (like the EJB spec requires) or you need RPC/Encoded
support, and you want open source, you really only have one choice for
Java: Axis1. Thus, if you have mixed requirements, you end up using two
soap stacks. Axis1 for some stuff and something like CXF for the newer
stuff. That's obviously not ideal.
I really am glad that Dain has started to try and address some of this.
This is really great stuff and I look forward to helping him flush some
more of the JAX-RPC stuff out. We may need to push some stuff up from
JAX-WS into the simple frontend (like the SwA interceptors) and possibly
copy some stuff almost verbatim into JAX-RPC (like the Holder
interceptors), but that's all very managable.
That all said, more thoughts on what would need to be done:
1) JAX-RPC frontend - probably a lot of code that is fairly similar to
the JAX-WS frontend code.
2) encoded support - Dain seems to have a good grasp on this already.
3) Tooling (java2ws and wsdl2java) - java2ws shouldn't be too hard. The
frontend has to setup the service model anyway and Aegis supports
generating schema, so that shouldn't be too hard. The wsdl2java could
be a bit harder. The SEI stuff should be fairly easy and similar to
jaxws. The types could be harder since we don't have a code generator
for Aegis. That said, the "Required" types for JAX-RPC are very
limited so it shouldn't be huge. (lots of complex things like choices
and enums and stuff aren't required)
Dan
On Monday 10 December 2007, Dain Sundstrom wrote:
> A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> support, and it went so well that it got me thinking that it would be
> great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> ApacheCon, I mentioned this idea and he figured the biggest road
> block for implementing JaxRPC is supporting RPC/Encoded. So, last
> weekend I had some free time and decided to try to hack SOAP encoded
> support into CXF, and to my surprise it wasn't to difficult add Aegis
> Types to support the SOAP strut and reference classes.
>
> SOAP encoded struct support is provided by the StructType subclass of
> BeanType. I did have to extract a few methods from the writeObject
> method to hook element writing. I also had to make a couple of
> methods more public.
>
> As for how it works, the best place to start is the StructTypeTest.
> Basically, read and write follow the same pattern:
>
> 1) read/write message parts with the SoapRefType
> 2) read/write trailing serialized blocks with TrailingBlocks
>
> As each object is read we check if it contains a SOAP id attribute,
> and if it does we register it with the SoapRefRegistry in the
> context. If an element contains a SOAP ref attribute we register a
> ref that is "set" when the reference is resolved (which my be
> immediately or later).
>
> When writing, every complex object is given a SOAP id and every
> reference to another complex object is written as a reference. The
> actual referenced object registered with the MarshalRegistry in the
> context and is written by the TrailingBlocks class.
>
> I've attached my patch to (https://issues.apache.org/jira/browse/
> CXF-1281). Next, I'm going to write Type class for SOAP encoded
> arrays.
>
> WDYT?
>
> -dain
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: SOAP encoded support
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 12 December 2007, Glen Mazza wrote:
> That's what Axis1 is for. Besides, can't they also use XFire? Or
> SAAJ? Or Dispatch objects? It can be done[1].
Not XFire. XFire never supported encoded. The only real option is
Axis1 if you don't want to deal with XML yourself and want it mapped
onto an object model.
> The Axis dev's have always been quite unyielding on this. If you say
> you need RPC/encoded on the axis-user ML, you're politely referred to
> Axis1 and that's that.
And they used to be very unyielding about not supporting JAX-WS.
They've recently changed their tune on that.
That said, using two very different stacks to talk to different services
is definitely not ideal. For example, if you write a
Handler/Interceptor for CXF that does some custom validation/logging or
something and you need to talk to both doc/lit and rpc/encoded services,
you would need to re-write all of that for Axis1.
Also, Axis1 is definitely not known for it's performance characteristics.
In many cases, it's pathetically slow. It's a very different
programming and configuration API which developers would need to learn
as well. For example, many CXF devs are Spring folks. Getting Axis1
stuff to play nicely with Spring configuration is not exactly fun.
Basically, you end up telling developers that they need to learn and use
two very different toolkits. Some are not too happy about that.
The other nice thing about this is that is can provide a migration path
to migrate from JAX-RPC to JAX-WS/CXF. If a developer has a JAX-RPC
application, if we supported at least a large chunk of JAX-RPC, we may
be able to get their application migrated fairly quickly so they can
keep it running as they work on updating it for JAX-WS. This is
actually a powerful statement. I know from experience with talking to
IONA's customers that such a migration path is very desirable. Doing a
JAX-RPC frontend for CXF is an idea that IONA has tossed around
internally for a while. We just haven't had the resources to do it.
IMO: This is a very real and very valuable need.
I actually agree with Bensons statement of:
'We build what you need, not what we think you need.'
Dan
> I don't know the severity of the changes involved, or any long-term
> consequences of supporting this. My instinct is, though, that if you
> need to play a record, you have to get a phonograph machine. Asking
> CD sound systems to retrofit seems unrealistic.
>
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20071102
>
> Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> > Because there are, apparently, plenty of production systems that use
> > it that folks want to talk to. And asking them to use Axis1 is in
> > the category of 'putting out a stumbling block for the blind'.
> >
> > On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> > > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I
> > > BP compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting
> > > it for multiple years now--they refer their users to Axis1 for it.
> > > (Also, don't users who need this functionality rely on Axis1
> > > xFire instead?) I can understand needing to retain obsolete
> > > technologies for backwards compatibility issues, but to retrofit
> > > CXF and have it now support an obsolete standard where it didn't
> > > before seems questionable.
> > >
> > > I'm not sure we should be supporting this deprecated technology,
> > > or providing an avenue for users to be working with it.
> > >
> > > Glen
> > >
> > > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > > support, and it went so well that it got me thinking that it
> > > > would be
> > > > great to use CXF for JaxRPC support as well. When I met Dan
> > > > Kulp at ApacheCon, I mentioned this idea and he figured the
> > > > biggest road block for implementing JaxRPC is supporting
> > > > RPC/Encoded. So, last weekend I had some free time and decided
> > > > to try to hack SOAP encoded support into CXF, and to my surprise
> > > > it wasn't to difficult add Aegis
> > > > Types to support the SOAP strut and reference classes.
> > > > SOAP encoded struct support is provided by the StructType
> > > > subclass of
> > > > BeanType. I did have to extract a few methods from the
> > > > writeObject method to hook element writing. I also had to make
> > > > a couple of methods more public.
> > > >
> > > > As for how it works, the best place to start is the
> > > > StructTypeTest. Basically, read and write follow the same
> > > > pattern:
> > > >
> > > > 1) read/write message parts with the SoapRefType
> > > > 2) read/write trailing serialized blocks with TrailingBlocks
> > > >
> > > > As each object is read we check if it contains a SOAP id
> > > > attribute, and if it does we register it with the
> > > > SoapRefRegistry in the context. If an element contains a SOAP
> > > > ref attribute we register a ref that is "set" when the reference
> > > > is resolved (which my be immediately or later).
> > > >
> > > > When writing, every complex object is given a SOAP id and every
> > > > reference to another complex object is written as a reference.
> > > > The actual referenced object registered with the MarshalRegistry
> > > > in the context and is written by the TrailingBlocks class.
> > > >
> > > > I've attached my patch to
> > > > (https://issues.apache.org/jira/browse/ CXF-1281). Next, I'm
> > > > going to write Type class for SOAP encoded arrays.
> > > >
> > > > WDYT?
> > > >
> > > > -dain
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: SOAP encoded support
Posted by Benson Margulies <bi...@gmail.com>.
I'm new to the process here. I'm happy to start a vote.
On Wed, 2007-12-12 at 10:32 -0500, Glen Mazza wrote:
> Benson, I think there should be a vote first to support RPC/Encoded in
> CXF. I won't veto it, but I fear you're opening up a can of worms, as
> we are not really a JAX-RPC implementation, and an attempt to do so will
> only require more changes and maintenance headaches downstream.
>
> Also, from what I believe Dan Kulp had said earlier, RPC/encoded was
> specifically tossed out from WS-I BP because it is not a safe/secure
> coding style. So this may not be a situation where some people say
> "autumn" while others say "fall", so why not allow both? Rather, it is
> more akin to building codes no longer allowing asbestos in the
> ceilings.
>
> I think that's why the Axis and Metro teams just refer readers needing
> this to legacy products, and just wash their hands of the matter.
>
> That said, I have a net total of six months experience with web
> services. The vast majority of the team who has been working with them
> for years I will happily defer to.
>
> Just my $0.02.
>
> Glen
>
>
> Am Mittwoch, den 12.12.2007, 09:58 -0500 schrieb Benson Margulies:
> > Hmm. Well, I committed Dain's patch without predicting that there might
> > be some negative opinion.
> >
> > I like the idea of CXF being a comprehensive tool. I reviewed Dain's
> > patches, and the negative impact of adding 'encoding' is far smaller
> > than the positive aspect of Dain's modularity improvements.
> >
> > CXF's claim to fame to some significant extent is 'We build what you
> > need, not what we think you need.'
> >
> > Someone could, by the way, take a similiar attitude toward my JavaScript
> > project. Is JavaScript client generation a core function? Is it a good
> > idea, in part, because it gets us another committer and another smart
> > person working on whatever?
> >
> >
> >
> > On Wed, 2007-12-12 at 09:31 -0500, Glen Mazza wrote:
> > > That's what Axis1 is for. Besides, can't they also use XFire? Or SAAJ?
> > > Or Dispatch objects? It can be done[1].
> > >
> > > The Axis dev's have always been quite unyielding on this. If you say
> > > you need RPC/encoded on the axis-user ML, you're politely referred to
> > > Axis1 and that's that.
> > >
> > > I don't know the severity of the changes involved, or any long-term
> > > consequences of supporting this. My instinct is, though, that if you
> > > need to play a record, you have to get a phonograph machine. Asking CD
> > > sound systems to retrofit seems unrealistic.
> > >
> > > Glen
> > >
> > > [1] http://www.jroller.com/gmazza/date/20071102
> > >
> > > Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> > > > Because there are, apparently, plenty of production systems that use it
> > > > that folks want to talk to. And asking them to use Axis1 is in the
> > > > category of 'putting out a stumbling block for the blind'.
> > > >
> > > >
> > > > On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> > > > > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> > > > > compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> > > > > multiple years now--they refer their users to Axis1 for it. (Also,
> > > > > don't users who need this functionality rely on Axis1 xFire instead?) I
> > > > > can understand needing to retain obsolete technologies for backwards
> > > > > compatibility issues, but to retrofit CXF and have it now support an
> > > > > obsolete standard where it didn't before seems questionable.
> > > > >
> > > > > I'm not sure we should be supporting this deprecated technology, or
> > > > > providing an avenue for users to be working with it.
> > > > >
> > > > > Glen
> > > > >
> > > > >
> > > > > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > > > > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > > > > support, and it went so well that it got me thinking that it would
> > > > > > be
> > > > > > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > > > > > ApacheCon, I mentioned this idea and he figured the biggest road
> > > > > > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > > > > > weekend I had some free time and decided to try to hack SOAP encoded
> > > > > > support into CXF, and to my surprise it wasn't to difficult add
> > > > > > Aegis
> > > > > > Types to support the SOAP strut and reference classes.
> > > > > > SOAP encoded struct support is provided by the StructType subclass
> > > > > > of
> > > > > > BeanType. I did have to extract a few methods from the writeObject
> > > > > > method to hook element writing. I also had to make a couple of
> > > > > > methods more public.
> > > > > >
> > > > > > As for how it works, the best place to start is the StructTypeTest.
> > > > > > Basically, read and write follow the same pattern:
> > > > > >
> > > > > > 1) read/write message parts with the SoapRefType
> > > > > > 2) read/write trailing serialized blocks with TrailingBlocks
> > > > > >
> > > > > > As each object is read we check if it contains a SOAP id attribute,
> > > > > > and if it does we register it with the SoapRefRegistry in the
> > > > > > context. If an element contains a SOAP ref attribute we register a
> > > > > > ref that is "set" when the reference is resolved (which my be
> > > > > > immediately or later).
> > > > > >
> > > > > > When writing, every complex object is given a SOAP id and every
> > > > > > reference to another complex object is written as a reference. The
> > > > > > actual referenced object registered with the MarshalRegistry in the
> > > > > > context and is written by the TrailingBlocks class.
> > > > > >
> > > > > > I've attached my patch to (https://issues.apache.org/jira/browse/
> > > > > > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > -dain
> > > > >
> > > >
> > >
> >
>
Re: SOAP encoded support
Posted by Glen Mazza <gl...@verizon.net>.
Benson, I think there should be a vote first to support RPC/Encoded in
CXF. I won't veto it, but I fear you're opening up a can of worms, as
we are not really a JAX-RPC implementation, and an attempt to do so will
only require more changes and maintenance headaches downstream.
Also, from what I believe Dan Kulp had said earlier, RPC/encoded was
specifically tossed out from WS-I BP because it is not a safe/secure
coding style. So this may not be a situation where some people say
"autumn" while others say "fall", so why not allow both? Rather, it is
more akin to building codes no longer allowing asbestos in the
ceilings.
I think that's why the Axis and Metro teams just refer readers needing
this to legacy products, and just wash their hands of the matter.
That said, I have a net total of six months experience with web
services. The vast majority of the team who has been working with them
for years I will happily defer to.
Just my $0.02.
Glen
Am Mittwoch, den 12.12.2007, 09:58 -0500 schrieb Benson Margulies:
> Hmm. Well, I committed Dain's patch without predicting that there might
> be some negative opinion.
>
> I like the idea of CXF being a comprehensive tool. I reviewed Dain's
> patches, and the negative impact of adding 'encoding' is far smaller
> than the positive aspect of Dain's modularity improvements.
>
> CXF's claim to fame to some significant extent is 'We build what you
> need, not what we think you need.'
>
> Someone could, by the way, take a similiar attitude toward my JavaScript
> project. Is JavaScript client generation a core function? Is it a good
> idea, in part, because it gets us another committer and another smart
> person working on whatever?
>
>
>
> On Wed, 2007-12-12 at 09:31 -0500, Glen Mazza wrote:
> > That's what Axis1 is for. Besides, can't they also use XFire? Or SAAJ?
> > Or Dispatch objects? It can be done[1].
> >
> > The Axis dev's have always been quite unyielding on this. If you say
> > you need RPC/encoded on the axis-user ML, you're politely referred to
> > Axis1 and that's that.
> >
> > I don't know the severity of the changes involved, or any long-term
> > consequences of supporting this. My instinct is, though, that if you
> > need to play a record, you have to get a phonograph machine. Asking CD
> > sound systems to retrofit seems unrealistic.
> >
> > Glen
> >
> > [1] http://www.jroller.com/gmazza/date/20071102
> >
> > Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> > > Because there are, apparently, plenty of production systems that use it
> > > that folks want to talk to. And asking them to use Axis1 is in the
> > > category of 'putting out a stumbling block for the blind'.
> > >
> > >
> > > On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> > > > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> > > > compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> > > > multiple years now--they refer their users to Axis1 for it. (Also,
> > > > don't users who need this functionality rely on Axis1 xFire instead?) I
> > > > can understand needing to retain obsolete technologies for backwards
> > > > compatibility issues, but to retrofit CXF and have it now support an
> > > > obsolete standard where it didn't before seems questionable.
> > > >
> > > > I'm not sure we should be supporting this deprecated technology, or
> > > > providing an avenue for users to be working with it.
> > > >
> > > > Glen
> > > >
> > > >
> > > > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > > > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > > > support, and it went so well that it got me thinking that it would
> > > > > be
> > > > > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > > > > ApacheCon, I mentioned this idea and he figured the biggest road
> > > > > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > > > > weekend I had some free time and decided to try to hack SOAP encoded
> > > > > support into CXF, and to my surprise it wasn't to difficult add
> > > > > Aegis
> > > > > Types to support the SOAP strut and reference classes.
> > > > > SOAP encoded struct support is provided by the StructType subclass
> > > > > of
> > > > > BeanType. I did have to extract a few methods from the writeObject
> > > > > method to hook element writing. I also had to make a couple of
> > > > > methods more public.
> > > > >
> > > > > As for how it works, the best place to start is the StructTypeTest.
> > > > > Basically, read and write follow the same pattern:
> > > > >
> > > > > 1) read/write message parts with the SoapRefType
> > > > > 2) read/write trailing serialized blocks with TrailingBlocks
> > > > >
> > > > > As each object is read we check if it contains a SOAP id attribute,
> > > > > and if it does we register it with the SoapRefRegistry in the
> > > > > context. If an element contains a SOAP ref attribute we register a
> > > > > ref that is "set" when the reference is resolved (which my be
> > > > > immediately or later).
> > > > >
> > > > > When writing, every complex object is given a SOAP id and every
> > > > > reference to another complex object is written as a reference. The
> > > > > actual referenced object registered with the MarshalRegistry in the
> > > > > context and is written by the TrailingBlocks class.
> > > > >
> > > > > I've attached my patch to (https://issues.apache.org/jira/browse/
> > > > > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > -dain
> > > >
> > >
> >
>
Re: SOAP encoded support
Posted by Benson Margulies <bi...@gmail.com>.
Hmm. Well, I committed Dain's patch without predicting that there might
be some negative opinion.
I like the idea of CXF being a comprehensive tool. I reviewed Dain's
patches, and the negative impact of adding 'encoding' is far smaller
than the positive aspect of Dain's modularity improvements.
CXF's claim to fame to some significant extent is 'We build what you
need, not what we think you need.'
Someone could, by the way, take a similiar attitude toward my JavaScript
project. Is JavaScript client generation a core function? Is it a good
idea, in part, because it gets us another committer and another smart
person working on whatever?
On Wed, 2007-12-12 at 09:31 -0500, Glen Mazza wrote:
> That's what Axis1 is for. Besides, can't they also use XFire? Or SAAJ?
> Or Dispatch objects? It can be done[1].
>
> The Axis dev's have always been quite unyielding on this. If you say
> you need RPC/encoded on the axis-user ML, you're politely referred to
> Axis1 and that's that.
>
> I don't know the severity of the changes involved, or any long-term
> consequences of supporting this. My instinct is, though, that if you
> need to play a record, you have to get a phonograph machine. Asking CD
> sound systems to retrofit seems unrealistic.
>
> Glen
>
> [1] http://www.jroller.com/gmazza/date/20071102
>
> Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> > Because there are, apparently, plenty of production systems that use it
> > that folks want to talk to. And asking them to use Axis1 is in the
> > category of 'putting out a stumbling block for the blind'.
> >
> >
> > On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> > > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> > > compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> > > multiple years now--they refer their users to Axis1 for it. (Also,
> > > don't users who need this functionality rely on Axis1 xFire instead?) I
> > > can understand needing to retain obsolete technologies for backwards
> > > compatibility issues, but to retrofit CXF and have it now support an
> > > obsolete standard where it didn't before seems questionable.
> > >
> > > I'm not sure we should be supporting this deprecated technology, or
> > > providing an avenue for users to be working with it.
> > >
> > > Glen
> > >
> > >
> > > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > > support, and it went so well that it got me thinking that it would
> > > > be
> > > > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > > > ApacheCon, I mentioned this idea and he figured the biggest road
> > > > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > > > weekend I had some free time and decided to try to hack SOAP encoded
> > > > support into CXF, and to my surprise it wasn't to difficult add
> > > > Aegis
> > > > Types to support the SOAP strut and reference classes.
> > > > SOAP encoded struct support is provided by the StructType subclass
> > > > of
> > > > BeanType. I did have to extract a few methods from the writeObject
> > > > method to hook element writing. I also had to make a couple of
> > > > methods more public.
> > > >
> > > > As for how it works, the best place to start is the StructTypeTest.
> > > > Basically, read and write follow the same pattern:
> > > >
> > > > 1) read/write message parts with the SoapRefType
> > > > 2) read/write trailing serialized blocks with TrailingBlocks
> > > >
> > > > As each object is read we check if it contains a SOAP id attribute,
> > > > and if it does we register it with the SoapRefRegistry in the
> > > > context. If an element contains a SOAP ref attribute we register a
> > > > ref that is "set" when the reference is resolved (which my be
> > > > immediately or later).
> > > >
> > > > When writing, every complex object is given a SOAP id and every
> > > > reference to another complex object is written as a reference. The
> > > > actual referenced object registered with the MarshalRegistry in the
> > > > context and is written by the TrailingBlocks class.
> > > >
> > > > I've attached my patch to (https://issues.apache.org/jira/browse/
> > > > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> > > >
> > > > WDYT?
> > > >
> > > > -dain
> > >
> >
>
Re: SOAP encoded support
Posted by Glen Mazza <gl...@verizon.net>.
That's what Axis1 is for. Besides, can't they also use XFire? Or SAAJ?
Or Dispatch objects? It can be done[1].
The Axis dev's have always been quite unyielding on this. If you say
you need RPC/encoded on the axis-user ML, you're politely referred to
Axis1 and that's that.
I don't know the severity of the changes involved, or any long-term
consequences of supporting this. My instinct is, though, that if you
need to play a record, you have to get a phonograph machine. Asking CD
sound systems to retrofit seems unrealistic.
Glen
[1] http://www.jroller.com/gmazza/date/20071102
Am Mittwoch, den 12.12.2007, 09:08 -0500 schrieb Benson Margulies:
> Because there are, apparently, plenty of production systems that use it
> that folks want to talk to. And asking them to use Axis1 is in the
> category of 'putting out a stumbling block for the blind'.
>
>
> On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> > compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> > multiple years now--they refer their users to Axis1 for it. (Also,
> > don't users who need this functionality rely on Axis1 xFire instead?) I
> > can understand needing to retain obsolete technologies for backwards
> > compatibility issues, but to retrofit CXF and have it now support an
> > obsolete standard where it didn't before seems questionable.
> >
> > I'm not sure we should be supporting this deprecated technology, or
> > providing an avenue for users to be working with it.
> >
> > Glen
> >
> >
> > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > support, and it went so well that it got me thinking that it would
> > > be
> > > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > > ApacheCon, I mentioned this idea and he figured the biggest road
> > > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > > weekend I had some free time and decided to try to hack SOAP encoded
> > > support into CXF, and to my surprise it wasn't to difficult add
> > > Aegis
> > > Types to support the SOAP strut and reference classes.
> > > SOAP encoded struct support is provided by the StructType subclass
> > > of
> > > BeanType. I did have to extract a few methods from the writeObject
> > > method to hook element writing. I also had to make a couple of
> > > methods more public.
> > >
> > > As for how it works, the best place to start is the StructTypeTest.
> > > Basically, read and write follow the same pattern:
> > >
> > > 1) read/write message parts with the SoapRefType
> > > 2) read/write trailing serialized blocks with TrailingBlocks
> > >
> > > As each object is read we check if it contains a SOAP id attribute,
> > > and if it does we register it with the SoapRefRegistry in the
> > > context. If an element contains a SOAP ref attribute we register a
> > > ref that is "set" when the reference is resolved (which my be
> > > immediately or later).
> > >
> > > When writing, every complex object is given a SOAP id and every
> > > reference to another complex object is written as a reference. The
> > > actual referenced object registered with the MarshalRegistry in the
> > > context and is written by the TrailingBlocks class.
> > >
> > > I've attached my patch to (https://issues.apache.org/jira/browse/
> > > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> > >
> > > WDYT?
> > >
> > > -dain
> >
>
Re: SOAP encoded support
Posted by Benson Margulies <bi...@gmail.com>.
Because there are, apparently, plenty of production systems that use it
that folks want to talk to. And asking them to use Axis1 is in the
category of 'putting out a stumbling block for the blind'.
On Wed, 2007-12-12 at 08:59 -0500, Glen Mazza wrote:
> I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> multiple years now--they refer their users to Axis1 for it. (Also,
> don't users who need this functionality rely on Axis1 xFire instead?) I
> can understand needing to retain obsolete technologies for backwards
> compatibility issues, but to retrofit CXF and have it now support an
> obsolete standard where it didn't before seems questionable.
>
> I'm not sure we should be supporting this deprecated technology, or
> providing an avenue for users to be working with it.
>
> Glen
>
>
> Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > support, and it went so well that it got me thinking that it would
> > be
> > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > ApacheCon, I mentioned this idea and he figured the biggest road
> > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > weekend I had some free time and decided to try to hack SOAP encoded
> > support into CXF, and to my surprise it wasn't to difficult add
> > Aegis
> > Types to support the SOAP strut and reference classes.
> > SOAP encoded struct support is provided by the StructType subclass
> > of
> > BeanType. I did have to extract a few methods from the writeObject
> > method to hook element writing. I also had to make a couple of
> > methods more public.
> >
> > As for how it works, the best place to start is the StructTypeTest.
> > Basically, read and write follow the same pattern:
> >
> > 1) read/write message parts with the SoapRefType
> > 2) read/write trailing serialized blocks with TrailingBlocks
> >
> > As each object is read we check if it contains a SOAP id attribute,
> > and if it does we register it with the SoapRefRegistry in the
> > context. If an element contains a SOAP ref attribute we register a
> > ref that is "set" when the reference is resolved (which my be
> > immediately or later).
> >
> > When writing, every complex object is given a SOAP id and every
> > reference to another complex object is written as a reference. The
> > actual referenced object registered with the MarshalRegistry in the
> > context and is written by the TrailingBlocks class.
> >
> > I've attached my patch to (https://issues.apache.org/jira/browse/
> > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> >
> > WDYT?
> >
> > -dain
>
Re: SOAP encoded support
Posted by Glen Mazza <gl...@verizon.net>.
Thank you both Dan and Dan for weighing in on this--my concerns about
this have been greatly alleviated. Especially considering the business
use cases/needs you both have referenced.
Glen
Am Mittwoch, den 12.12.2007, 12:29 -0500 schrieb Dan Diephouse:
> Axis 2 does have experimental support for rpc-encoding. JAX-RPC
> support is a negative though.
>
> There really is no negative affect here - rpc-encoding is off by
> default. If anything this will improve the code because someone is
> actually looking at it and improving it.
>
> Also, there is a definite need for this. I've talked to several
> companies who have avoided using CXF because they can't also get their
> legacy services using it. Its a stumbling block for a lot of people
> who can't change their wsdls and want one framework to migrate them
> all.
>
> - Dan
>
> Glen Mazza wrote:
> > I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
> > compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
> > multiple years now--they refer their users to Axis1 for it. (Also,
> > don't users who need this functionality rely on Axis1 xFire instead?) I
> > can understand needing to retain obsolete technologies for backwards
> > compatibility issues, but to retrofit CXF and have it now support an
> > obsolete standard where it didn't before seems questionable.
> >
> > I'm not sure we should be supporting this deprecated technology, or
> > providing an avenue for users to be working with it.
> >
> > Glen
> >
> >
> > Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> >
> > > A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> > > support, and it went so well that it got me thinking that it would
> > > be
> > > great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> > > ApacheCon, I mentioned this idea and he figured the biggest road
> > > block for implementing JaxRPC is supporting RPC/Encoded. So, last
> > > weekend I had some free time and decided to try to hack SOAP encoded
> > > support into CXF, and to my surprise it wasn't to difficult add
> > > Aegis
> > > Types to support the SOAP strut and reference classes.
> > > SOAP encoded struct support is provided by the StructType subclass
> > > of
> > > BeanType. I did have to extract a few methods from the writeObject
> > > method to hook element writing. I also had to make a couple of
> > > methods more public.
> > >
> > > As for how it works, the best place to start is the StructTypeTest.
> > > Basically, read and write follow the same pattern:
> > >
> > > 1) read/write message parts with the SoapRefType
> > > 2) read/write trailing serialized blocks with TrailingBlocks
> > >
> > > As each object is read we check if it contains a SOAP id attribute,
> > > and if it does we register it with the SoapRefRegistry in the
> > > context. If an element contains a SOAP ref attribute we register a
> > > ref that is "set" when the reference is resolved (which my be
> > > immediately or later).
> > >
> > > When writing, every complex object is given a SOAP id and every
> > > reference to another complex object is written as a reference. The
> > > actual referenced object registered with the MarshalRegistry in the
> > > context and is written by the TrailingBlocks class.
> > >
> > > I've attached my patch to (https://issues.apache.org/jira/browse/
> > > CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
> > >
> > > WDYT?
> > >
> > > -dain
> > >
> >
> >
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
Re: SOAP encoded support
Posted by Glen Mazza <gl...@verizon.net>.
I'm hardly an expert here, but isn't RPC/encoded obsolete/not WS-I BP
compliant? (JAX-RPC, likewise?) Axis2 has resisted supporting it for
multiple years now--they refer their users to Axis1 for it. (Also,
don't users who need this functionality rely on Axis1 xFire instead?) I
can understand needing to retain obsolete technologies for backwards
compatibility issues, but to retrofit CXF and have it now support an
obsolete standard where it didn't before seems questionable.
I'm not sure we should be supporting this deprecated technology, or
providing an avenue for users to be working with it.
Glen
Am Montag, den 10.12.2007, 19:45 -0800 schrieb Dain Sundstrom:
> A couple of weeks ago I integrated CXF into OpenEJB for JaxWS
> support, and it went so well that it got me thinking that it would
> be
> great to use CXF for JaxRPC support as well. When I met Dan Kulp at
> ApacheCon, I mentioned this idea and he figured the biggest road
> block for implementing JaxRPC is supporting RPC/Encoded. So, last
> weekend I had some free time and decided to try to hack SOAP encoded
> support into CXF, and to my surprise it wasn't to difficult add
> Aegis
> Types to support the SOAP strut and reference classes.
> SOAP encoded struct support is provided by the StructType subclass
> of
> BeanType. I did have to extract a few methods from the writeObject
> method to hook element writing. I also had to make a couple of
> methods more public.
>
> As for how it works, the best place to start is the StructTypeTest.
> Basically, read and write follow the same pattern:
>
> 1) read/write message parts with the SoapRefType
> 2) read/write trailing serialized blocks with TrailingBlocks
>
> As each object is read we check if it contains a SOAP id attribute,
> and if it does we register it with the SoapRefRegistry in the
> context. If an element contains a SOAP ref attribute we register a
> ref that is "set" when the reference is resolved (which my be
> immediately or later).
>
> When writing, every complex object is given a SOAP id and every
> reference to another complex object is written as a reference. The
> actual referenced object registered with the MarshalRegistry in the
> context and is written by the TrailingBlocks class.
>
> I've attached my patch to (https://issues.apache.org/jira/browse/
> CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.
>
> WDYT?
>
> -dain
Re: SOAP encoded support
Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 10, 2007, at 8:50 PM, Dan Diephouse wrote:
> Cool. I only skimmed the patch, but I think such a feature would be
> quite welcome. The way you're going about it is exactly the way I'd
> do do it - i.e. using Aegis. It was developed with soap encoding
> somewhat in mind, so I'm glad to hear it wasn't too hard to add
> some basic support.
That explains why the code seemed to naturally fit.
> The critical issue is of course interop. An avenue worth exploring
> might be to set up a series of unit tests which made CXF/Axis 1.x
> talk to each other.
I plan on. I have been collecting example messages for the different
rpc/encoded systems from blogs and docs, so we should be able to at
least read most interpretations of SOAP encoded. As for writing, I
think we will be able to write in a format that most systems should
be able to read, but for some really wacky systems, we may have to
have a dialect flag on the port.
> Thats about all the intelligent things I have to say on the issue.
> I will apologize for the parts of aegis that have become a complete
> mess. It needs a little cleanup and could stand to support XML
> schema a bit better too. I heartily encourage you to continue your
> efforts though and I think I'd probably welcome such patches into
> the code base.
That's good to hear. There are a few sections of code that left me
scratching my head, so it's good to know that there is a good
possibility it is a bug as opposed to an obscure undocumented feature :)
-dain
Re: SOAP encoded support
Posted by Dan Diephouse <da...@mulesource.com>.
Dain Sundstrom wrote:
> A couple of weeks ago I integrated CXF into OpenEJB for JaxWS support,
> and it went so well that it got me thinking that it would be great to
> use CXF for JaxRPC support as well. When I met Dan Kulp at ApacheCon,
> I mentioned this idea and he figured the biggest road block for
> implementing JaxRPC is supporting RPC/Encoded. So, last weekend I had
> some free time and decided to try to hack SOAP encoded support into
> CXF, and to my surprise it wasn't to difficult add Aegis Types to
> support the SOAP strut and reference classes.
>
> SOAP encoded struct support is provided by the StructType subclass of
> BeanType. I did have to extract a few methods from the writeObject
> method to hook element writing. I also had to make a couple of
> methods more public.
>
> As for how it works, the best place to start is the StructTypeTest.
> Basically, read and write follow the same pattern:
>
> 1) read/write message parts with the SoapRefType
> 2) read/write trailing serialized blocks with TrailingBlocks
>
> As each object is read we check if it contains a SOAP id attribute,
> and if it does we register it with the SoapRefRegistry in the
> context. If an element contains a SOAP ref attribute we register a
> ref that is "set" when the reference is resolved (which my be
> immediately or later).
>
> When writing, every complex object is given a SOAP id and every
> reference to another complex object is written as a reference. The
> actual referenced object registered with the MarshalRegistry in the
> context and is written by the TrailingBlocks class.
>
> I've attached my patch to
> (https://issues.apache.org/jira/browse/CXF-1281). Next, I'm going to
> write Type class for SOAP encoded arrays.
>
> WDYT?
>
> -dain
Cool. I only skimmed the patch, but I think such a feature would be
quite welcome. The way you're going about it is exactly the way I'd do
do it - i.e. using Aegis. It was developed with soap encoding somewhat
in mind, so I'm glad to hear it wasn't too hard to add some basic support.
The critical issue is of course interop. An avenue worth exploring might
be to set up a series of unit tests which made CXF/Axis 1.x talk to each
other.
Thats about all the intelligent things I have to say on the issue. I
will apologize for the parts of aegis that have become a complete mess.
It needs a little cleanup and could stand to support XML schema a bit
better too. I heartily encourage you to continue your efforts though and
I think I'd probably welcome such patches into the code base.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog