cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: SOAP encoded support
Date Wed, 12 Dec 2007 15:33:11 GMT
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

Mime
View raw message