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
