The growing number of SOAP implementations is concrete proof of the real boom being enjoyed, in recent months, by Web Services based on this protocol. And each of the implementations has its own objects, methods, environments, and deployment.

In an earlier article, we introduced the set of concepts and technologies that are related to Web Services:

• XML: a technology used to describe information
• UDDI: to find the necessary services
• WSDL: to describe how Web Services work
• SOAP: to remotely execute Web Services.

(Click here to read related articles )

We are now entering a much more pragmatic phase, which involves testing and checking the actual interoperability promised by the SOAP protocol. In this article, we present the results of a study that we carried out on the interoperability between the three main SOAP implementations, which are:

• SOAP Toolkit 2.0 Beta 1 (Microsoft): C#, Visual Basic and any other language of the .NET platform
• Apache SOAP (Jakarta Apache project): JAVA language
• SOAP::Lite (Paul Kulchenko): Perl language

These three implementations were tested both in SOAP Client and SOAP Server.

• By "SOAP Client" we mean the program that will create the SOAP message, send it and receive the response from the service called. It is important in this context not to confuse a SOAP Client and an Internet Client, which can call on a SOAP Client to call a Web Service.



• By "SOAP Server" we mean the component to which the SOAP messages are sent. A SOAP Server deserializes SOAP queries from a SOAP Client, provides the service and sends the message back to the SOAP Client.

The SOAP implementations that we tested provide both the SOAP Client and Server environment. The following diagram shows a traditional architecture with a SOAP Client calling Web Services on a SOAP Server.


Communication between the SOAP Client and SOAP Server

Interoperability tests
The following table details the interoperability tests carried out. Server side, we tested Web Services deployed on Internet and locally on our computers. Our SOAP messages were created using simple type parameters (string, integer). All our tests were performed in a Windows 2000 environment, for SOAP Clients and for SOAP Servers deployed locally. For Web Services (SOAP Server) hosted by XMethods, the platform used was UNIX (Solaris 8). For Web Services (SOAP Server) hosted by ITFinity, the platform used was Windows 2000.

• Tests on the TechMetrix platform for SOAP Clients, using SOAP Servers hosted by XMethods and ITFinity.

SOAP Client — TechMetrix Platform		SOAP Servers: Implementation (hosting location)
		Apache SOAP ( XMethods)	SOAP::Lite (XMethods )	Microsoft SOAP Server Toolkit 2.0 (ITFinity)
Apache SOAP	Medium API	Service: [Traffic Info California] => OK	Service: [BabelFish translation] => OK	#Datatype problem
SOAP::Lite	High API	Service: [Traffic Info California] => OK	Service: [BabelFish translation] => OK	Service: [Generation of a Globally Unique Identifier] => OK
	Medium API	Service: [Temperature of USA] => OK	Service: [BabelFish translation] => OK	Service: [Generation of a Globally Unique Identifier] => OK
MS SOAPToolkit2.0 Beta1	High API	#Datatype problem	Service: [BabelFish translation] => OK	Service: [Generation of a Globally Unique Identifier] => OK
	Low API	#Datatype problem	Service: [BabelFish translation] => OK	Service: [Generation of a Globally Unique Identifier] => OK

[A brief description of the services used is given at the end of this article]

• Tests on the TechMetrix platform (SOAP Clients and Servers, Windows 2000)

SOAP Client — TechMetrix Platform		SOAP Servers, TechMetrix Platform: Implementation
		Apache SOAP (Unit Test Application Server)	SOAP::Lite	Microsoft SOAP Server Toolkit 2.0
Apache SOAP	Medium API	WSDE example [StockQuote] => OK	Not tested	#Datatype problem
SOAP::Lite	High API	WSDE example [StockQuote] => OK	SOAP::Lite examples [Incrementation operation] => OK	Toolkit example [Algebraic operation] => OK
	Medium API	WSDE example [StockQuote] => OK	Not tested	Toolkit example [Algebraic operation] => OK
MS SOAPToolkit2.0 Beta1	High API	#Datatype problem	Not tested	Toolkit example [Algebraic operation] => OK
	Low API	#Datatype problem	Not tested	Toolkit example [Algebraic operation] => OK

[A brief description of the services used is given at the end of this article]

References:

API levels:

• High API: Interoperability checked by using high-level implementation: WSDL call to attain Web service
• Medium API: Interoperability checked by using a medium API: instantiation of key parameters of SOAP message.
• Low API: Interoperability checked by using low-level implementation: manual construction of SOAP message. § Not tested: Interoperability test not carried out
• # Datatype problem: Interoperability tested but not checked. The Apache system requires all the arguments to be typed using the xsi:type attribute, while the Microsoft system does not require this. The next version of Apache SOAP (2.1) should be able to guarantee interoperability between these two implementations.

Services hosted:

• XMethods: www.xmethods.net
• ITFinity: www.itfinity.com — Service referenced with XMethods (www.xmethods.net )

Conclusion

Overall, these tests demonstrate that interoperability between different implementations is making progress.

We can see that for the examples tested, we managed to call services using different languages for their SOAP implementation. Only the Apache SOAP and SOAP::Lite implementations here enable UNIX platforms to be equipped with the necessary SOAP modules for dialoging with this protocol.

What is more, the introduction of Web Service Description Language (WSDL) (see our January 2001 article) in the implementations seems to improve and enhance full interoperability between Web Services. WSDL describes the information required in order to call the services offered, and it is one of the best ways to guarantee interoperability of SOAP services.

These tests reveal excellent potential. Even though the Web Services actually available at the moment are few and far between and rather basic in nature, professional offerings with more complete solutions are beginning to emerge, such as that offered by Sevina Technologies which features CRM (Customer Relationship Management) services. Lastly, those wishing to look in more detail at the technical aspects can consult this month's in-depth feature on our tests on the Microsoft SOAP implementation.

Description of services used as examples

Service:Traffic Info California

Description: Information on traffic conditions on California's highways. Information source from the Web site Caltrans.
Input: Number of Californian highway.
Output: Info on traffic conditions on highway in question.
WSDL: yes
SOAP Implementation: Apache SOAP

Service: BabelFish translation

Description: Translates a text up to 5K in size. For more information, please consult the BabelFish homepage .
Inputs: Translation mode ["en_fr", "en_de", "en_it", "en_pt", "en_es", "fr_en", "de_en", "it_en", "pt_en", "ru_en", "es_en"]; string to be translated in source language.
Output: Translation in target language.
WSDL: yes
SOAP Implementation: SOAP::Lite

Service: GUID Generator (Globally Unique Identifier)

Description: Assigns a unique ID. Service delivered by ITFinity.
Input: None
Output: UID
WSDL: yes
SOAP Implementation: MS SOAP2.0

Service: StockQuote

Description: Information on stock quotes from finance.yahoo.com which draws its resources from Reuters. The example is offered by XMLToday.
Input: Symbol of listed company.
Output: Company stock quote.
WSDL: yes
SOAP Implementation: Apache SOAP

Service: Incrementation operation

Description: Adds 1 to the integer entered.
Input: Integer
Output: Integer+1
WSDL: no
SOAP Implementation: SOAP::Lite

Service: Algebraic operations

Description: Carries out algebraic operations on two algebraic numbers. Example from SOAP Toolkit 2.0.
Inputs: Method ["AddNumbers", "SubstractNumbers"]; Number1; Number2
Output: Result of operation.
WSDL: yes
SOAP Implementation: MS SOAP2.0