cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: SOAP encoded support
Date Wed, 12 Dec 2007 17:29:49 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Axis 2 does have experimental support for rpc-encoding. JAX-RPC support
is a negative though.<br>
<br>
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.<br>
<br>
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. <br>
<br>
- Dan<br>
<br>
Glen Mazza wrote:
<blockquote cite="mid:1197467988.6928.9.camel@gmazza-desktop"
 type="cite">
  <pre wrap="">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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 (<a class="moz-txt-link-freetext" href="https://issues.apache.org/jira/browse/">https://issues.apache.org/jira/browse/</a>

CXF-1281). Next, I'm going to write Type class for SOAP encoded arrays.

WDYT?

-dain
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Dan Diephouse
MuleSource
<a class="moz-txt-link-freetext" href="http://mulesource.com">http://mulesource.com</a>
| <a class="moz-txt-link-freetext" href="http://netzooid.com/blog">http://netzooid.com/blog</a></pre>
</body>
</html>

Mime
View raw message