WSDL versioning considerations

Link changes to requirement messages

You import some WSDL documents and create tests from them. Then, you are given new versions of the WSDL documents. How do you then update your tests to use the new format messages. What happens to added fields, removed fields, moved fields and altered structure. Can you continue to use the old version of the WSDL documents.

The easiest way that you can propagate changes to tests are by linking them to requirement messages. A good practice is to create your requirement messages by using the WSDL document and drag the message onto your message action in the test. When the WSDL document changes, for example, you overwrite the old WSDL document with the new one, you can change the requirement messages, which then propagate to the test artifacts. This approach handles the added fields, removed fields, moved fields and altered structure, but you might have to change the test based on the function of the test. A good practice is to run your regression tests again to make sure that nothing breaks the test.

If you are importing a new version of the WSDL documents, but do not want to delete the old one, you can treat the new versions of the WSDL documents as a new artifact and link them to new tests. Cases where you might not want to delete the old versions are want to keep different versions of tests for different releases or drops. When you treat the new versions as new artifacts, you can copy the old tests and rename them into a different folder structure, for example, V2 and then use the process that is mentioned earlier to link the requirement messages to the test.

You must determine from the WSDL documents what changed and therefore if that change breaks your test. For example, if namespaces changed then this change breaks the test, since running the tests on the old format cannot work as the message signature is different. The same result applies if mandatory fields are added. However, adding new optional fields in the WSDL document is not a change that breaks the test. You can continue to run the old version of the WSDL documents.

Resources

Some of these resources can help you manage changing WSDL versions.

Designing and versioning compatible Web services

Designing and versioning compatible Web services provides guidelines for versioning based on real-world experiences, and describes a strategy for evolving Web services that use WebSphere® software, including WebSphere® Services Registry and Repository, Process Server, and WebSphere® Integration Developer.

Best practices for Web services versioning

Best practices for Web services versioning outlines the scope of the versioning difficulties facing web services developers, provides some template solutions, and discusses architectures and best practices for addressing the problem.

Develop and Deploy Web Services as OSGi Bundles

Develop and Deploy Web Services as OSGi Bundles describes a step-by-step approach to developing and deploying web service components as OSGi bundles. Apache CXF's distributed OSGi framework, cxf-dosgi, is used with Eclipse's Equinox OSGi framework for developing and deploying the service bundles. A simple web application client is developed to access the distributed service bundles. A web service provider often faces the challenge of supporting multiple versions of a service at the same time. The article also demonstrates how OSGi provides a clean and uncluttered environment to facilitate just such a need.

Service versioning in SOA

Using service-oriented architectures as a way of enabling flexible and resilient enterprises is becoming widespread. Success with initial SOA deployments let architects and developers focus on things that are common to all business and IT systems. One such constant in any system is change. Service versioning in SOA discusses the challenge of change in SOA and describes a model that helps address the challenge.

Web Services Management and Governance Best Practices

Web Services Management and Governance Best Practices provides recommended practices for service versioning, service contract management, and service monitoring. Additional considerations for effective service management and governance are also provided.

Enhance UDDI to manage Web services

Enhance UDDI to manage Web services presents a potential enterprise solution for configuring security and versioning in an enterprise architecture that spans various partners. It aims to increase interoperability, scalability, and quality of enterprise services. Ultimately, you can enhance a distributed business model and improve the process performance by portraying Universal Description, Discovery and Integration (UDDI) as a comfortable and powerful enabler in the web service invocation process. The article illustrates how to use UDDI as an XML-based registry and as a security and configuration management solution. The authors look into the UDDI intricacies, providing easy and simple mapping with the WSDL (Web Services Description Language) to build the UDDI registry effortlessly. They also discuss in detail the logical architecture for using the IBM® WebSphere® UDDI.

Introduction to SOA governance

Introduction to SOA governance explores how IBM® defines service-oriented architecture (SOA) governance. The article explains what it is and why it's critical to the success of your SOA project.