Is it possible to have multiple xsd mappings in a webservice?

Question

I'm new to web services and I'm facing a design issue where we want to create a web service (preferably SOAP based) which will receive 2 parameters:

• a string variable (Client Name);
• XML data.

There are currently 2 different consumers of this web service but their number will increase. All consumers have separate XSD data that they will be sending, for example:

Consumer1:

<ConData>
    <Customer>
        <FirstName>FirName</FirstName>
        <LastName>LasName</LastName>
    </Customer>
    <Acocunt>
        <Number>112971</Number>
    </Account>
    <Order>
        <OrderNum>0092123</OrderNum>
    </Order>
<ConData>

Consumer2:

<ConData>
    <SysData>
        <CustomerFirstName>Name</CustomerFirstName>
        <CustomerLastName>Name</CustomerLastName>
        <AccountNumber>Au1o2n</AccountNumber>
        <OrderNum>koo912</OrderNum>
    </SysData>
<ConData>

This web service is supposed to take the XML data from these clients and store it into the database based on the consumer name. There is no processing required on our end for validating the XML as such, we just take it and store it in the database.

As a good design though, I'd like to define my web service with explicit parameters. The problem is that since their XML data format is different I'm not able to use a single XSD schema as a parameter in my WSDL. I can think of 2 options to address this:

1. Let them pass XML data as String in my web service instead of XSD mapping parameter. Though this is a valid approach, it seems like a bad design based on what I've read so far on the forums as it voids validation and needs lots of manual marshaling and unmarshaling and other problems. Plus my WSDL will not be able to define to my clients what format is expected etc.

2. Create 2 separate web services which will handle different individual consumers with their own XSD's. This again seems less viable since in future if we add more consumers we will have to add new web services with duplicate code for the same operation etc.

I was looking to see if there is a way to define multiple XSD's in a single web service WSDL or maybe a better way of solving this problem.

On a side note, I'd prefer to have a SOAP based web service but if this problem gets resolved using a RESTful web service in a better way then I can consider that as well.

Answer 1

You don't need to have a different web service or skeleton for each client, you just need a different WSDL.

Forget about sending this XML parameter as string, it has disadvantages that I won't repeat here since you already read about it too. So you need to send it as XML.

To keep it into one web service, you create the web service so that it accept any XML as input (type <xsd:any> for the parameter). Type <xsd:any> will mean any kind of XML, but at least it would be XML that you can validate for structure, for starters.

This simplifies versioning of your web service as you don't need to change the code when adding another XML type of input but unfortunately you lose strong typing for your web service and the WSDL generated for the web service will not state anything about the structure of the XML it's expecting (any XML is too vague). Your web service skeleton will be created with a type like Object, XmlElement, XmlDocument or whatever in your code. And the same will happen with all your client stubs.

But for your clients this can be fixed from the WSDL by providing each client with a different WSDL.

For that you create a WSDL of your web service with common content for all clients, except the <types> section, and then merge this common WSDL for each client with their own XML Schema. You will then expose each WSDL on different URLs for each client.

Now the clients will be able to generate strong typed stubs based on their own particular WSDL.

When a client makes a call to your web service, you identify the client XML Schema and use it to validate the XML parameter and see if it's the expected content.

And if the above seem to much, then you can always choose a loosely typed RESTful web service. Whatever solution you choose though, just make sure that you validate the incoming XML using the schema of the client that's sending it.