Your choice of SOAP toolkit may be the most important decision you make in implementing a Service Oriented Architecture (SOA) based on Web Services.

This wasn’t always the case.

For example, First-Generation Web Services (WS-1G) typically depicted SOAP, WSDL and UDDI as more-or-less equal players.

In reality, however, UDDI was and remains (e.g., Erl, Chapter 3) a bit of a non-starter.

WSDL remains key, and continues to evolve with version 2 well on its way to becoming a bona fide standard.

So, what about SOAP?

In learning more about Second-Generation Web Services (WS-2G), I continue to be struck by how much value is being driven through SOAP. In turn then, WS-2G are being driven through XML, as SOAP makes use of XML. It is for reasons like this that SOA-guru Thomas Erl states that SOAs are ultimately all about XML and not Web Services (Erl, Chapter 3, Section 3.5.4).

And this returns us to the point made at the outset.

Because so much value is being driven through SOAP, you must choose your SOAP toolkit wisely. More specifically, toolkit choice will determine, for exanple, which WS-2G specifications are supported via implementations. Even more specifically, as a third-generation SOAP toolkit, Apache Axis2 includes core (e.g., WS-Addressing) and extended (e.g., WS-Coordination, WS-ReliableMessaging, WS-Security, etc.) implementations of a number of WS-2G standards.

SOAP toolkits may also reflect vendor bias. For example, IBM has championed WS-Notification, whereas Microsoft’s emphasis has been on WS-Eventing. These vendor biases at the standards level are quite likely reflected at the SOAP toolkit level. For example, it is reasonable to expect that an IBM SOAP toolkit would include an implementation of WS-Notification, whereas a Microsoft SOAP toolkit would offer one of WS-Eventing instead.

Even though working with SOAP may initially appear a low-level detail at the outset of conceptualizing a SOA, it turns to be a very important consideration that is amplified as SOA adoption proceeds.