Vladimir Dyuzhev, author of MockMotor

Vladimir Dyuzhev
MockMotor Creator

Evaluating WSDL Change Impact

Upload the old and the updated WSDLs to WSDL Diff and see what’s impacted. Tweet This

They Updated WSDL, Now What?

You’ve just got an updated WSDL. What’s going to break because of the changes in it?

You’re Not the Only One in a Bind

This question is very common for any system that is built on top of SOA. Architects, developers, QA, load test coordinators - everyone are in the same boat.

  • Do we have to update all clients and server at the same time (that is expensive!)
  • If we do a staged deployment, what operations in the WSDL are affected (broken) if the updated client calls a non-updated service?
  • And other way around, can some clients be updated later?
  • How the XML structure changes? Does your implementation's parser tolerate those changes?
  • What responses do you need to update in MockMotor to adhere to the new structure?

In addition to schema changes, WSDL can change the way the payload is structured in body/header, encoding/qualification, SOAP Action, binding properties - any of which can cause the loss of interoperability.

The tricky part: some types of changes made in input break the “updated to old” scenario, while in the output they should be considered non-breaking. For instance, a new optional element in the request would break the old service if passed, but the same element in response will not be generated by the old service (because it doesn’t know about it), the updated client will tolerate the element lack because the element is optional.

There’s an App for That! Right?

You’d assume, since the use case is so common, that there are tools that help you.

Well, not quite. You’ll have to find a way around it on your own.

How?

Diff on WSDL Files is No Help

Can we run a diff against the old and new WSDLs?

No, we cannot. Only occasionally the old and new diff maintain the same structure. More commonly, the WSDLs are created and updated by different people, using different tools, different ways to format the WSDL documents - even different spaces convention.

The document can look entirely different to diff, and yet be semantically the same WSDL.

And even when diff shows some difference, it is often hard to figure out the impact of those changes. Say, this basic type has a changed restriction; what WSDL operations are impacted?

Comparing Generated Payload is of Little Help (and Can be Misleading)

Another popular suggestion is to generate the payloads from the old and new WSDL and compare them.

That … kinda works. Sometimes. Indeed, if you see a new element in a request, you have just spotted a difference!

But both XML Schema and SOAP are more complicated than just XML. It is possible that you do not see a difference, but it is there. You’ve put your name behind the impact analysis, and you botched it.

For a simple example, consider this schema:

<xsd:sequence>
    <xsd:element name="a" type="xsd:string"/>
    <xsd:element name="b" type="xsd:string"/>
</xsd:sequence>

It can only describe one document structure:

<a>Hello</a>
<b>World</b>

Now imagine the schema in a WSDL file got updated to have XSD:all instead of XSD:sequence:

<xsd:all>
    <xsd:element name="a" type="xsd:string"/>
    <xsd:element name="b" type="xsd:string"/>
</xsd:all>

If you try and generate a payload for the updated operation, you may get the same structure as before:

<a>Hello</a>
<b>World</b>

Does it mean that the operation is not impacted?

No. It is equally possible that the live code generates another structure that is also valid according to the updated schema, but not the original one:

<b>World</b>
<a>Hello</a>

What’s also interesting is that the code using the old WSDL can send the structure to the code using the new WSDL, but not in the opposite direction. This is because a-b is valid for both xsd:sequence and xsd:all, but b-a is only valid for xsd:all.

In other words, the structure change itself is not enough to tell if a change is breaking. You need to consider how the structure is used.

So, good try, but a risky one.

Expensive XML Tools?

Maybe.

Weird as it sounds, although I’m working with XML for many years, I wasn’t able to convince myself I have to purchase one of those $1000+ XML tools. I’m unaware if any of them support a semantic compare for WSDLs.

Let me know if you had a positive experience. I may consider buying one at last.

MockMotor WSDL Diff & Impact Tool

As usual with us geeks, when there are no tools we build our own. In this case, I’m not so much built it, but repurposed a part of MockMotor library that deals with WSDLs and added a rather basic UI on top of it.

Meet MockMotor WSDLDiff & Impact Tool.

It is a free (duh!) service that lets you upload the WSDL versions before and after the change and get an overview of what has changed semantically and what kind of impact you can expect.

The impact is evaluated in its most strict sense. The real implementations can be more permitting than WSDLDiff assumes, but when it comes to interoperability, it is better to be on the safe side.

1 Upload original and updated WSDLs.

The tool tells you if it needs more files (imported schemas and WSDLs) to complete the analysis:

2 Review the Impact Summary.

The reporting is done for “Updated client calls old server” and “Old client calls the updated server” separately:

3 Check what ports, bindings or operations are impacted and how badly:

4 Dig into breaking change details, if required:

After reviewing the reported changes, you should be pretty clear what has changed with the WSDL and, hopefully, how does it impact your systems.

Hope that helps!

Please Share

Was this post useful? Then please share! Tweet This