John,
I'm confused. I just looked at the WSDL, and it does in fact say
style="rpc". Are you saying that you changed the service to RPC style
(you're the service provider?) and now the client request works? What
did the original WSDL look like? Did it originally specify
style="document"?
"Wrapped" style isn't a new thing -- it's part of the JAX-RPC spec,
and it's been the default for .NET from the beginning. Besides,
"wrapped" is just a form of "document" style. (When using "wrapped"
style, the WSDL must specify style="document".) But it's possible that
the client system doesn't support document style. Do you know what
system was used to create the client?
When using RPC style, the SOAP engine generates a wrapper element
around the parameters specified in the <part> definitions, and that's
what the SOAP request indicates, so my assumption is that the client
was generating an RPC style request regardless of the definition
specified in the WSDL.
In any case, your current WSDL is not valid. When using "rpc" style,
the message parts must reference types rather than elements. For
example, in the first message definition:
<wsdl:message name="SubmitGeneralServiceRequestInput">
<wsdl:part name="parameters" element="wstypes:SubmitGeneralServiceRequest"/>
</wsdl:message>
the <wsdl:part> definition should reference a complex type rather than
an element, e.g.;
<wsdl:message name="SubmitGeneralServiceRequestInput">
<wsdl:part name="parameters"
type="wstypes:SubmitGeneralServiceRequestType"/>
</wsdl:message>
(Note, though, that a complexType called
wstypes:SubmitGeneralServiceRequestType has not been defined in this
wsdl.)
To correct the WSDL, you need to change style="rpc" to
style="document". You also have a number of undefined element types,
so you should add type definitions for these elements. I validated the
WSDL using the Cape Clear SOA Editor, and it produced the following
warnings:
Warning : 1005 : The element named FoodServiceRequest does not have a
type or ref attribute and therefore defaults to xsd:anyType. A custom
serializer must be added to the marshalling to handle this at runtime.
Warning : 1005 : The element named
AddComplainantsToDogServiceRequestResponse does not have a type or ref
attribute and therefore defaults to xsd:anyType. A custom serializer
must be added to the marshalling to handle this at runtime.
Warning : 1005 : The element named CloseContractServiceRequestResponse
does not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Warning : 1005 : The element named ClosePestServiceRequestResponse
does not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Warning : 1005 : The element named CancelPestServiceRequestResponse
does not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Warning : 1005 : The element named CloseGeneralServiceRequestResponse
does not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Warning : 1005 : The element named CloseFoodServiceRequestResponse
does not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Warning : 1005 : The element named CloseDogServiceRequestResponse does
not have a type or ref attribute and therefore defaults to
xsd:anyType. A custom serializer must be added to the marshalling to
handle this at runtime.
Regards,
Anne
On 7/14/05, John Baker <[EMAIL PROTECTED]> wrote:
> I'm getting good at answering my own questions! It appears that changing the
> style in the WSDL to 'rpc' fixed the problem. The author of the WSDL hadn't
> heard of 'wrapped', so perhaps this is part of a newer spec and somehow, the
> WSDL didn't conform to it in some way?
>
> Oh well, we live and learn.
>
>
> John
>
> On Wed, Jul 13, 2005 at 03:43:03PM +0100, John Baker wrote:
> > Hello,
> >
> > I know I've asked this before, and I've reviewed the remarks from last time
> > and looked for obvious errors in my WSDL, but nothing is making itself
> > obvious.
> >
> > Please consider this message arriving to an Axis server:
> >
> > <ns1:SubmitGeneralServiceRequest xmlns:ns1="http://www.caps-solutions.
> > co.uk/webservices/connectors/servicerequest/messagetypes">
> > <ns2:SubmittedGeneralServiceRequest
> > xmlns:ns2="http://www.caps-solutions
> > .co.uk/schema/uniform/72b/servicerequest/sr/srtypes">
> > <ns2:ServiceRequestIdentification>
> > <ns2:AlternativeReferences>
> >
> > <ns3:AlternativeReference xmlns:ns3="http://www.
> > caps-solutions.co.uk/schema/uniform/72b/common/uniformtypes">
> >
> > (snip)
> >
> > And this exception:
> >
> > AxisFault
> > faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
> > faultSubcode:
> > faultString: org.xml.sax.SAXException: Invalid element in
> > uk.co.caps_solutions.
> > www.schema.uniform._72b.servicerequest.sr.srtypes.SubmittedGeneralServiceRequest
> > Type - SubmittedGeneralServiceRequest
> > faultActor:
> > faultNode:
> > faultDetail:
> > {http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException:
> > Invali
> > d element in
> > uk.co.caps_solutions.www.schema.uniform._72b.servicerequest.sr.srty
> > pes.SubmittedGeneralServiceRequestType - SubmittedGeneralServiceRequest
> > at
> > org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeseri
> > alizer.java:258)
> > at
> > org.apache.axis.encoding.DeserializationContext.startElement(Deserial
> > izationContext.java:1035)
> >
> > So the problem appears to be that it doesn't like the second node
> > (SubmittedGeneralServiceRequest).
> >
> > The WSDL can be found here:
> > http://www.javasystemsolutions.com/serviceRequestConnector.wsdl
> >
> > To throw a further observation into the problem, if I make a call from some
> > Axis generated stubs (from the WSDL), it makes this request:
> >
> > <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
> > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> > <soapenv:Body>
> > <SubmitGeneralServiceRequest xmlns="">
> > <ns1:SubmittedGeneralServiceRequest
> > xmlns:ns1="http://www.caps-solutions.co.uk/schema/uniform/72b/servicerequest/sr/srtypes";><ns1:ServiceRequestIdentification><
> >
> > So Axis stubs generate something similar to the XML coming into the server.
> > So why can't Axis decode the XML coming in?
> >
> > Thanks :)
> >
> >
> > John
>
