5.4 SOAP implementations

To be able to use SOAP in the real world, irrespective of whether it is for use with Web services or with non-Web services “ related software, an actual software implementation of the SOAP specification is needed. This is not going to be an impediment, given that more than 70 SOAP implementations at present cover all popular hardware and software permutations ” though many of these, as of mid-2003, were still based on the 1.1 specification rather than the full 1.2 specification. Implementations of the 1.2 specification should nonetheless be commonplace by early 2004, given that most of the major SOAP implementations (e.g., Apache Software Foundation s Axis V1.1) already have included support for 1.2 at the prerecommendation level (i.e., the so-called 1.2 candidate recommendation ). A relatively comprehensive list of current SOAP implementations can be found at http://www.xmethods.net.

In general, developers will not set out to directly generate and receive SOAP messages. Instead, when developing Web services that will use SOAP for their I/O operations, they would typically opt to use a SOAP Toolkit, an application development studio product (e.g., IBM s WebSphere Studio Application Developer, BEA WebLogic Workshop, and Microsoft s Visual Studio .NET 2003), or a Web services “specific toolkit (e.g., IBM s Web Services Toolkit [WSTK] or Microsoft s WSTK) to help them create, parse, and manage the necessary SOAP messages. Figure 5.9 shows the overview for IBM s WebSphere Studio Application Developer product, which shows as its third item that one of its primary uses is to Build new applications or enable existing assets quickly that are consistent with the WS-I Basic Profile 1.0 using open standards such as Universal Description Discovery and Integration (UDDI), Simple Object Access Protocol (SOAP), and Web Services Description Language (WSDL).

Figure 5.9: IBM s high-level description of its highly promoted, Java-oriented, WebSphere Studio Application Developer, showing the built-in support for SOAP and other Web services “ related protocols.

SOAP-based Web services (or other applications), once developed with a toolkit or a studio, will typically be deployed, at least on the server side, on top of application servers (e.g., IBM s WebSphere Application Server, BEA s WebLogic Server, Microsoft s .NET Framework, Apache Tomcat, Sun ONE, and the open-source JBoss), which in turn will support SOAP-based messaging over a variety of different transports. On the client side, SOAP support can generally be obtained in two distinct ways depending on the platform in question. Microsoft s .NET Framework, which is available for Windows XP, Windows CE .NET 4.2, and Windows Mobile 2003, as discussed in Section 3.2.1, true to its goal of being a strategic software environment for running XML Web services, includes built-in support for SOAP. To this end, Microsoft s technology overview for .NET Framework 1.1 starts off with the statement The .NET Framework 1.1 is used for building and running all kinds of software, including Web-based applications, smart client applications, and XML Web services ” components that facilitate integration by sharing data and functionality over a network through standard, platform-independent protocols such as XML (Extensible Markup Language), SOAP, and HTTP. If, instead, Java- or C++-based support is required for a client, one would typically include the necessary SOAP libraries, which would be provided by the original development tool as an overall part of the Java or C++ code that would be downloaded to the client.

Some of the best-known and most widely used SOAP implementations include:

Microsoft s SOAP Toolkit 2.0
IBM s Java-based SOAP4J, which later became the Apache SOAP project
SOAP::Lite for Perl
EasySOAP++
GLUE

Given its pioneering work on SOAP, it is not surprising that Microsoft was one of the first to offer a SOAP implementation. This was the so-called SOAP Toolkit 1.0, which was available in summer 2000, shortly after SOAP 1.1 had been formulated and submitted to the W3C. This initial toolkit did not support WSDL (which was at that juncture still being formulated) and accommodated only RPC-mode transactions over HTTP. Version 2 of this toolkit, which received widespread publicity within the software development community and as such became a de facto standard for this genre , was officially available as of April 2001. Though Microsoft came out with a Version 3 in July 2002, even today it is Toolkit 2.0 that comes to the mind of most developers when they think about SOAP-specific development options from Microsoft.

The SOAP Toolkit permits developers to easily add XML Web Service functionality to existing Microsoft COM-oriented applications and components. The Toolkit is heavily WSDL-centric. It includes a WSDL generator that will automatically generate WSDL descriptions of existing COM libraries. It can be used by itself or in conjunction with Microsoft Visual Studio .NET. The primary features of the 2.0 Toolkit include:

A client-side component, which permits applications to invoke SOAP-based Web service operations as described by the WSDL definition for that service
A server-side component, which generates SOAP message from COM object method calls per the WSDL description ”albeit only when augmented with Microsoft-specific Web Services Meta Language (WSML) files
The necessary code to transmit, read, serialize, and process SOAP messages

The 3.0 Toolkit included support for sending and receiving attachments (e.g., pictures). Remember that this type of attachment handling essentially falls into the realm of SOAP bindings (e.g., SMTP with MIME), SOAP extensibility, and SOAP encoding. Thus, it is a legitimate implementation-related option. Microsoft sets out to further extend this capability by adding support for Direct Internet Message Encapsulation (DIME) “based attachments. DIME is a new proposed standard for use with SOAP that, similar to MIME, will allow any file of an arbitrary type to be attached to a SOAP message. There is also a generic-type mapper to facilitate the mapping of complex data types to the necessary WSDL and WSML descriptions.

On the Java side, Apache Axis, from the Apache Software Foundation (http://www.apache.org), the doyen of Web-oriented open software, is now the gold standard when it comes to SOAP implementations. Apache Axis, which includes support for WSDL as well as XML-RPC, supersedes the well-known Apache SOAP project. This project, in turn, got its impetus when IBM magnanimously donated its SOAP4J implementation to Apache. Axis, which is positioned as a SOAP engine that is 1.2 compliant, can in effect be thought of as Apache SOAP 3.0. In addition to the inclusion of new features such as WSDL and XML-RPC, Axis represents a total rewrite of the original SOAP4J code as well as a move, within this code, from the display-oriented XML DOM API to the more appropriate inter-program-oriented SAX API. The Axis implementation is credited as being much faster than the Apache SOAP version, which was often criticized for being somewhat slow.

The Axis SOAP engine is available as a simple, small footprint, stand-alone server. It is also available as a plug-in, which can be seamlessly integrated into application (or servlet) servers. The Axis SOAP implementation is already in use by IBM, Apple, Borland, Macromedia, and JBoss, among others. IBM s market-leading WebSphere Application Server 5.0 has the Axis software built in. IBM s WSTK also uses the Axis software. Axis, like the Microsoft SOAP Toolkit, provides support for attachments. Whereas the Microsoft Toolkit is COM-centric, Axis understandably is JavaBean oriented. For example, it will automatically serialize JavaBeans, with the added option of customizable mapping to specific XML fields or attributes.

Interoperability, as mentioned earlier, was an issue with SOAP 1.1 implementations. Consequently there are various efforts afoot to ensure that this will not continue to be a stumbling block down the road ”particularly with 1.2-based implementations. Obviously the Assertions and Test Collection test suite is pivotal in this respect. Then there is also the Web Services Interoperability (WS-I) organization, which was founded by Accenture, BEA, H-P, IBM, Intel, Microsoft, Oracle, SAP, and Fujitsu in February 2002. Since then, Sun and Cisco, among many others, have joined WS-I in various capacities .

WS-I is an open industry organization whose goal is to promote Web services interoperability across platforms, operating systems, and programming languages. WS-I set out to work across the industry and standards organizations as an end- user -focused advocacy that would provide guidance as to best practices when it came to Web services and the standards upon which they were based. One of its explicit charters is that of creating, promoting, and supporting generic protocols for interoperable exchange of messages between Web services. Thus, SOAP comes under its purview, whichever way one looks at it. In addition to the WS-I efforts and the W3C 1.2 test suite, individual implementers such as Apache are also doing their part to foster interoperability. The Axis SOAP engine, for example, has been subjected to Java-related interoperability tests specified by the Java creator and mentor Sun.

The bottom line is that Web services development, deployment, or exploitation is in no way going to be hindered by the paucity of SOAP implementations. The fact that the SOAP specification currently does not address the needs of transaction processing scenarios could be an issue as more and more organizations opt to start exploiting Web services for production applications. These issues, however, for the time being, can be very effectively and elegantly addressed by using SOAP over a transport scheme that does offer the necessary transactional processing-oriented features (e.g., a cross-platform, message queuing scheme such as IBM s Web-Sphere MQ).

Most major toolkits and studios targeted at Web service developers offer SOAP functionality to the application servers that will be used as the execution environments for Web services. Thus, the choice of exactly which SOAP implementation an organization will use will invariably be dictated by the overall software development preferences and dictates of that organization. If it favors .NET-based software development, then it will most likely start by reviewing Microsoft s Visual Studio .NET 2003, SOAP Toolkit 3.0, and WSDK options. If, on the other hand, it happens to be a Java shop, it will most likely start with one of the popular Java studios and application servers (e.g., IBM s WebSphere or BEA s WebLogic). There are also other language-specific options for C++, Perl, and so forth.