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 [EMAIL PROTECTED] http://www.dankulp.com/blog
