As we bring our SOAs online using Web Services, we all know that SOAP is the standards message transfer protocol. But the interface description language for Web Services (WSDL) isn't specifically for SOAP. It's more generic. A SOAP-centric contract description language for Web Services is needed. Enter the SOAP Service Description Language or SSDL. This framework was just released in mid-February, and is now available for review. Let's take a look.

SSDL lets developers publish and share descriptions of the messages and message exchange patterns supported by Web Services. It also addresses contract and protocol description. In other words, it provides a framework for managing common abstractions such as protocols, messages, and even endpoints. An SSDL contract also acts as a placeholder that encapsulates protocol descriptions, as well as a mechanism for those protocol descriptions to reference the declared messages using a common facility. The frameworks are built very much like the WS-Policy specifications, using a base SSDL framework that offers a fundamental protocol for building and describing messages.

Under Contract

MEP defines a collection of XML infoset elements information representing commonly used exchange patterns. CSP defines a collection of XML infoset element information items for defining a multi-message exchange, leveraging sequential process semantics. Rules defines a collection of XML infoset elements information used to describe a multi-message exchange protocol using conditions. SC defines a collection of XML infoset element information for multi-party, multi-message exchange protocol using pi-calculus notions.

The goal here is to support various types of end users, letting them pick and choose protocol frameworks that match their applications best. Or, as an option, they can implement their own protocol framework (see below).

SSDL assumes that SOAP is the transport mechanism. So, you can consider SSDL bound to SOAP. SSDL also assumes that WS-Addressing is the standard mechanism for embedding addressing information inside of SOAP envelopes. SSDL focuses on messages and protocols, and as a result there's no need for articles such as 'interface,' 'inheritance,' and 'operation.' An XML infoset is assumed to be the SSDL component model, and the modularization of the contract is handled using XInclude.

As mentioned above, SSDL promotes protocol framework extensibility, allowing a different protocol description model to be integrated into the base SSDL framework, promoting protocol-based integration and letting you expose the message behavior of a service. It is key to the success of the standard, letting flexibility support protocol integration, something that's been difficult in the past.

What's the Value Prop?

SSDL is really providing the mechanisms for service architects to describe the structure of SOAP messages. Once a message has been described, one of the currently available protocol frameworks can be leveraged to combine the messages into protocols that expose the message behavior of the service. As such, architects and developers can create systems that participate in conversations, all adhering to a contract.

The SSDL contract lets those that design and build services focus on the structure of the messages, as well as the message exchange patterns, again by using a common contract for designing, building, and deploying a service. In the SSDL world there are no abstract interfaces, inheritance, or operations. The building services using SSDL define protocols by correlating messages together. That's a powerful concept, and an approach that has obvious advantages. So, how do you play with this thing now?

A tool called SSDL.EXE exists created using the .NET 2.0 platform and Web Service Enhancement 2.0 to consume SSDL contract. SSDL.EXE generates C# and VB.NET code that can be leveraged to implement Web Services for producing and consuming messages. It's extensible through plug-ins, and is only Win32-based so far.

I think we need something like SSDL as SOAs become the rule rather than the exception, providing better control and definition of information moving from point to point. This standard seems to work and play well with other standards, but I think it's a bit complex for many architects to understand. Its extensibility is very powerful, and I suspect will be leveraged in many SOA development projects. Keep an eye on this one.