Since our recent IEEE Internet Computing article on SSDL, there's been renewed
interest from the community in the ideas. One thing that I've found helps folks to understand SSDL is to couch it in terms of things with which they're already familiar,
which in this case is the contract metadata stack of the familiar WS-* standards from W3C and OASIS: WSDL, WS-BPEL, and WS-CDL. The following diagram
illustrates (somewhat crudely) where the various SSDL components are aligned with the technologies from the
OASIS/W3C initiatives.
The bottom-most layer of the stack is the same for both SSDL and the W3C/OASIS stack - typically
TCP/IP, queues and so forth. SSDL is unconcerned about such details providing there is a SOAP and WS-
Addressing binding to the chosen transport. Things change the next layer up the stack however. While WSDL is
agnostic about the application protocols it can describe (providing there is a WSDL binding for a given
application protocol over a given transport such as SOAP over HTTP), SSDL unashamedly exclusively meant for
SOAP (on the sound assumption that SOAP is the defining characteristic of any Web Service).
The Core
SSDL layer is where SSDL describes schemas, messages, and endpoints which is broadly similar to the WSDL
types, message, (SOAP) bindings, and service abstractions. If we consider the MEP framework (which is one of
the four possible frameworks that has been created so far for SSDL) as well, then the result is a SOAP-only
equivalent of WSDL since that framework mirrors the operation and MEP abstractions from WSDL
2.0.
However SSDL doesn't necessarily stop at being a simpler, SOAP-centric replacement for WSDL. One
of the things that WSDL doesn't do is describe the protocol state machine that a Web Service supports. That
is, WSDL doesn't provide any metadata for the ordering of operations (leaving aside for the moment that the
operation abstraction is deeply flawed in our message-oriented view of service interaction). Instead that role is left to
higher-level specifications like the (deprecated) WS-Conversation Language and (abstract) WS-BPEL, where the higher-level framework can be used
to show ordering between operations, decision points in the protocol state machine, optional exchanges and so
forth. Therefore (abstract) WS-BPEL can be used to describe how a particular interaction must proceed from
the point of view of an individual service.
Correspondingly, SSDL provides two equivalent mechanisms
for describing Web Service orchestration: Rules Framework and CSP Framework. The Rules Framework is based on
the notion of preconditions which guard the sending and receiving of messages by a Web Service. That is, the
orchestration is defined in terms of what a Web Service must have sent and/or received before it can legally
send/receive a given message. The CSP Framework defines a Web Service in terms of one or more sequential
processes which may communicate with each other. Messages which are sent or received represent the events in
CSP processes which can be ordered by choice, sequence, parallel, etc operators which is very much akin to
the WS-BPEL model, but based on the message rather than operation abstraction.
The uppermost layer is
probably the most interesting of the entire stack. It shows WS-CDL on the W3C/OASIS side and the Sequential
Constraints (SC) Framework on the SSDL side. Choreography is concerned with multi-party protocols, and both
WS-CDL and SSDL-SC are no exceptions. What this means is they are able to describe not only the interactions
that a single Web Service supports, but the interactions that are expected for all Web Services in a
composite application - that is, a complete multiparty description of the end-to-end protocol that supports a
given process. The key differentiator between the two approaches is simply that WS-CDL builds on WSDL 1.1 and
2.0 whereas SSDL-SC builds on core SSDL.
So, given that tooling could well abstract out the complexity
in the W3C/OASIS stack - a key point in favour of the simpler SSDL model - it begs the question why would one
bother with SSDL at all? The reasons, I believe, are threefold:
- Simplicity - SSDL is arguably far
simpler and more cohesive than the W3C/OASIS stack;
- Extensibility - SSDL can be extended to create
arbitrary protocol framework descriptions to suit a given domain. For instance WS-BPEL and WS-CDL could both
be easily re-codified as SSDL Protocol Frameworks;
- Provability - CSP, Rules, and SC are abstractions
of underlying formal methods. That is, a contract described in any of these frameworks can be reduced to a
formal model and checked for undesirable properties like deadlock and starvation. The Pi-Calculus based SC
framework is worthy of a special mention here since it makes entire business processes amenable to formal
verification - a critical point where value transactions are to be processed!
Of course the
practicalities of the situation with huge existing investments in the W3C/OASIS stack means that SSDL will
most likely remain nothing more than a toolkit for academics and geeks. Nonetheless SSDL has shown that it
is possible to derive additional value from the contract metadata stack without having to add complexity. If
future version of the orthodox contract metadata languages espouse at least some of those same values, then
our work will not have been in vain.
Thanks to Josh and Dilip for the
feedback
Update: Steve Ross-Talbot pitches in with some useful commentary from
the WS-CDL perspective on the comments page.