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 Tue, 11 Dec 2007 19:47:08 GMT

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

Mime
View raw message