Why does a webservice specify all request and response types as a string?

Question

I am working with a legacy webservice, and they supplied us their WSDL to work with.

Now my problem is, that every function specifies the same argument and return type. And this type is then specified as being string!

Example:

<definitions targetNamespace="java:the.custom.namespace" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="java:the.custom.namespace" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"&gt;
 <types>
    <schema targetNamespace="java:the.custom.namespace" xmlns="http://www.w3.org/1999/XMLSchema" /> 
  </types>
  <message name="LegacySystemRequest">
    <part name="arg0" type="xsd:string" /> 
  </message>
  <message name="LegacySystemResponse">
    <part name="return" type="xsd:string" /> 
  </message>
  <portType name="LegacySystemPortType">
    <operation name="HelloWorld">
     <input message="tns:LegacySystemRequest" /> 
     <output message="tns:LegacySystemResponse" /> 
    </operation>
</types>

I am not familiar with creating webservices in Java, but is there an obvious thing they could be doing wrong since they are not exposing the structure of their DTOs? I know from examples that they are complex, so I do not want to write to hardcode them all into my code. Is there any technical hints I could give them?

Answer 1

It's impossible to say for sure from this WSDL, but I would guess that the web service is nothing more than a carrier for arbitrary data, and was probably bolted on to a legacy system.

The strings could be anything, perhaps XML in themselves, or perhaps CSV data, or something like that. Certainly not a good example of WSDL design.

You'll just have to invoke it and see what you get back....

Also, this WSDL looks like it might be from an rpc-encoded web service, which is not compatible with modern java WS stacks, which require document-encoding. Older stacks (like Axis 1) support it, though.

Answer 2

The SOAP schema does provide a bunch of other data types so there is no technical reason for them to be using String - although all parameters are transmitted as strings anyway thanks to the XML transport.

Your example looks like they're not bothering to create a complex data type to encapsulate their parameters and have simply left it as 'request string' and 'response string'...

It really depends what is being sent in those strings, weather or not it can be represented more eloquently. For me, such a situation usually comes from laziness.

Java has a pretty good set of tools for automatically generating the schema to map Classes to SOAP types. I've only ever accessed them though my IDE so I'm not familiar with doing it manually, but if you google for wsimport you should find something.

Answer 3

There are often two reasons why they would use strings when they could use more complex types instead:
1) The people who created the SOAP server don't know better and are just too inexperienced to use more complex types.
2) Some application that calls this web service can't handle more complex data types than strings.

As you said, it is a legacy service so it's likely that the people who created it were too inexperienced with SOAP to add more complexity. Considering the fact that the SOAP standard was final in 2003, it's no surprise to find services that old with similar simplicity. It was just too new back then.

This isn't uncommon for any new technology, since many people start using it before they have complete knowledge about it. Once they have the experience, the technique is becoming outdated again.

You could provide them some hints about how to improve it, but I guess they know their service isn't very good. They just might not have the resources to improve it. Or maybe they're already improving this service but the new service might still be in beta.