|
Wednesday February 26 2002 Testing for SOAP Interoperability Testing Web Services Clients Currently, the limitations arising because of the differences between implementations of the SOAP specifications from Apache and Microsoft are being circumvented with in-house solutions. Third party tools can be used to test SOAP messages and WSDL for interoperability and service implementation. Meanwhile, Microsoft and IBM, longtime rivals in the Web Development industry, have been working together to resolve their differences. The collaboration between IBM and Microsoft includes the establishment of a global Web Services standards group of which these last two are members. See http://www.ws-i.org/ for more details. Locating Interoperability Problems As with many problems, finding the interoperability problems between two SOAP platforms can be tricky. Broadly speaking, we can divide the location of interoperability problems into two areas: Web Services Architectures, and the behavior of Web Services Clients. Location of Interoperability Problems: Web Services Architecture To understand where in the Web Services the interoperability problems mostly occur, let's take a look at the Web Services Architecture in the following figure:
Three components comprise the architecture: service
providers, service requesters, and service brokers, each of which performs
a Web Service operation.
Each of these three operations involves three complementary yet distinct technologies:
Any single entity may represent one, two, or all of these parties. The service broker is the name given to the UDDI service provider. This may be a broker in the business sense but it is used here simply as the aggregator of service definitions. At a very basic level, the Binding operation stands out as the most important of the three. It involves the actual consumption of services, where the vast majority of interoperability problems occur. An example of such an interoperability issue is that not all Web Services platforms use the same access protocol in the WSDL bindings they generate. This isn't a problem is we specify what protocol the client should use. Interoperability Problems: Client Behavior The following table shows how clients behave when working
with a particular type of Web Service:
Means of testing Interoperability If there are problems with interoperability between different SOAP implementations, how can we find out if the one we're using will work with our clients? This is clearly an issue that needs to be sorted out while the interoperability problems are still evident. There are, fortunately, three means of testing for SOAP interoperability, which we shall look at in the following sections. Testing Mechanism 1: XMLBus You can nail down problems with interoperability by using a testing mechanism such as that provided by IONA Technologies' Orbix E2A (End to Anywhere) XMLBus Edition, bridging .NET, CORBA, and EJB servers. This product provides the framework and tools to automatically convert an existing server application into a Web Service, deploy the newly created service, and allows you to test and publish it, using SOAP, WSDL, and UDDI as standards. IONA's Web Services framework supports the automatic generation of WSDL files from CORBA IDL and vice versa, and can be used to register the WSDL files in UDDI. Testing Web Services is accomplished through an XML Web Services component called Web Services Test Client, a graphical user interface tool that is part of Orbix E2A (for details, visit http://www.iona.com/). This generic client uses the WSDL for any Web Service and works in conjunction with the SOAP Listener (an underlying XMLBus architectural component) to execute the methods of the Web Service. The WSDL file can be one generated by the Web Service Builder (another XMLBus component), or can be any valid WSDL file. The Builder component is used to create a Web Service from a working application such as a Java or EJB component. You can use the SOAP Message Spy (SMS), a third XMLBus component, to intercept and process SOAP messages in two usage scenarios of the Dynamic Test Client: when evaluating the WSDL for available operations and using the generated SOAP request as input in the SMS. Testing Mechanism 2: TCP Tunneling GUI As an alternative to IONA's XMLBus architecture, you can use the TCP tunneling GUI that comes with Apache SOAP, which allows you to see the TCP messages move between the client and server. You can also examine the SOAP on-the-wire protocol and even check that the various competing SOAP implementations are standards-compliant. What this tool does is to allow you to "sniff" SOAP messages by acting as a TCP router. To use the TCP tunneler, you have to set it up to run between the client and the server; usually, this is done by setting the tunneler to listen on one port and forward to another port, the one the server normally listens to. Of course, this means changing the client to make requests to a different port, but this is usually a simple task. Testing Mechanism 3: Interoperability Lab There are a few things you can do to help make the different toolkits supporting SOAP work together. By using RPC/encoded messages where possible, supplying WSDL documents, and sticking to SOAP bindings only, you will find that many toolkits will be able to work with your deployed Web Services. As time marches on, interoperability will get better, and many of these tips will become unnecessary. As long as SOAP implementation differences and limitations remain, there is a need to know how interoperable a given SOAP platform is. The SOAP developer's community has devised a set of tests to validate the interoperability of each SOAP platform. If you want to find a solid implementation of SOAP (and usually WSDL too), make sure that the implementation is represented on the soapbuilders mailing list - a list of products that meet the tests. To easily check for participation, go to the XMethods site (http://www.xmethods.net/ilab/) and look at the Round 1 home page and SOAPBuilders Interoperability Lab Round 2 home page. Both pages list implementations at various stages in attaining interoperability. IONA is co-hosting the SOAPBuilders Round III - Web Services interoperability testing with Microsoft. Meanwhile IONA makes an Interoperability Test Web Service available on its web site. Clients generated from this Web Service can be used to test the interoperability of other SOAP implementations. This demonstration includes a client built with Microsoft's SOAP tool kit and a client built with Microsoft's .NET platform. These clients can be used to talk to the Interoperability Test Web Service. Conclusion Many people will tell you that Web Services offer seamless interoperability between applications, regardless of implementation and platform. As we have seen, there are still problems with this, and until vendors produce standards compliant tools and platforms, there will continue to be these problems. Despite this, though, it is possible to run Web Services clients against a SOAP server on an entirely different platform, often with no alterations to be made. So long as you are aware of the interoperability issues with the SOAP implementation you are using, and the requirements of your clients, there shouldn't be any insurmountable problems. In a relatively short time it may no longer matter what language the business logic your system relies upon is implemented in, as long as it can use HTTP/SMTP and XML. The extended PDF version of this article is available now. Testing for SOAP Interoperability by Judith
M. Myerson Purchase the extended PDF version of this article from:
Adobe Acrobat format (PDF) |