users@jax-rpc.java.net

Re: SOAP encoding related problem

From: Roberto Chinnici <Roberto.Chinnici_at_Sun.COM>
Date: Thu, 23 May 2002 16:57:48 -0700

Simon Horrell wrote:

> Is there any way to control the way the RI builds SOAP messages? For
> instance, I would like to build a web service from either of the following
> definitions and have control over the array item element names in the SOAP
> message.
>
> Either build the web service from this Java service definition interface:
>
> public interface MathsIF extends Remote {
> public double[] add(double[] num1, double[] num2) throws
> RemoteException;
> }
>
> or build the web service from this WSDL:
>
> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:tns="http://develop.com/maths/simple/arrays/wsdl"
> xmlns:ns2="http://develop.com/maths/simple/arrays/schema"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" name="Maths"
> targetNamespace="http://develop.com/maths/simple/arrays/wsdl">
> <types>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> xmlns:tns="http://develop.com/maths/simple/arrays/schema"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/"
> targetNamespace="http://develop.com/maths/simple/arrays/schema">
> <complexType name="ArrayOfdouble">
> <complexContent>
> <restriction base="soap-enc:Array">
> <attribute ref="soap-enc:arrayType"
> wsdl:arrayType="double[]"/></restriction></complexContent></complexType></sc
> hema></types>
> <message name="add">
> <part name="arrayOfdouble_1" type="ns2:ArrayOfdouble"/>
> <part name="arrayOfdouble_2" type="ns2:ArrayOfdouble"/></message>
> <message name="addResponse">
> <part name="result" type="ns2:ArrayOfdouble"/></message>
> <portType name="MathsIF">
> <operation name="add">
> <input message="tns:add"/>
> <output message="tns:addResponse"/></operation></portType>
> <binding name="MathsIFBinding" type="tns:MathsIF">
> <operation name="add">
> <input>
> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
> use="encoded"
> namespace="http://develop.com/maths/simple/arrays/wsdl"/></input>
> <output>
> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
> use="encoded"
> namespace="http://develop.com/maths/simple/arrays/wsdl"/></output>
> <soap:operation soapAction=""/></operation>
> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
> style="rpc"/></binding>
> <service name="MathsService">
> <port name="MathsIFPort" binding="tns:MathsIFBinding">
> <soap:address
> location="http://localhost/MathsService/jaxrpc/MathsIFPort"/></port></servic
> e></definitions>
>
> Alternatively, given that the names of array item element names really don't
> matter for such a SOAP encoded message, is there any way to fix the RI so
> that it doesn't check for prescribed element names? This is hindering
> interop (with .NET for me in this case) because other tools, in the face of
> the above WSDL, are unlikely to choose the names that the RI is looking for.

This is a known bug in the RI and it'll be fixed in our FCS release. More explicitely,
the RI will use an array item element name of its choice when producing messages
but will not enforce it when processing incoming messages.

> On a wider note, this, in a nutshell, highlights the problem with the
> non-normative SOAP encoding style. When soap encoding style is used then the
> schema types that make up the abstract message definition are just hints in
> terms of the physical message format and so if there is nothing in the
> interface description that tells client or server how to actually build the
> message that goes on the wire (e.g. the names of array item elements in this
> case) then it is hardly surprising that the client and server choose
> different names and either stands the chance of not being able to cope with
> the other's choices. Speaks volumes for literal style.

I completely agree.

Roberto

--
Roberto Chinnici
Java and XML Software
Sun Microsystems, Inc.