World Wide Webber


My Books
REST in Practice: Hypermedia and Systems Architecture
Amazon:
US, UK
Developing Enterprise Web Services by Sandeep Chatterjee and Jim Webber
Amazon:
US, UK,
Now available: Korean Edition

My Bookshelf
Programming Clojure by Stuart Halloway

RESTful Web Services by Leonard Richardson and Sam Ruby
Announcing SSDL - The SOAP Service Description Language
Posted: 15 February 2005 @ 12:03 UT from Sydney, Australia

After some months of relatively head-down, nose-to-the-grindstone kind of work, the fruits of our collective labours are ready for public consumption. The SSDL suite of specifications are ready for consumption by a largely unsuspecting public. Today we are officially announcing the SOAP Service Description Language or SSDL.

SSDL is a SOAP-centric contract language for Web Services. SSDL takes a different approach to WSDL by assuming that SOAP and WS-Addressing will underpin Web Services development and integration and is optimised and simplified for those cases. The major benefit of SSDL is not that it is easy to read and write (or at least as easy as XML ever is), but that it is truly focussed on supporting SOAP messaging. The fundamental abstractions in SSDL are messages and endpoints, which are then used to describe anything from simple request-response MEPs through to multi-message conversations and beyond.

The "magic" that allows this happen is SSDL extensibility. Like WS-Policy, SSDL is factored into a base specification which provides the common vocabulary for other specs which plug into it. Four such specs (MEP, CSP, Rules, SC) are provided with the first release of SSDL, which capture the whole range of messaging options from WSDL-like operations through to multi-party protocols. Things get even more interesting here, since the some of the protocol plugins all have formal underpinnings which allow us to reason about the protocols (i.e. groups of message exchanges) that a service supports - will the protocol deadlock? Will this protocol finish in a consistent manner? Powerful stuff. Of course, if none of the existing protocol plugins are suitable for your situation, you're free to create your own plugin framework too - and our experience in developing the existing plugins shows it's a pretty low barrier to entry.

At the moment we have tooling that supports the basic framework and some of the protocol plugins, which provides sensible message-focussed APIs (a la MEST best practice). Like SSDL, the tooling is also extensible by 3rd parties, providing you're happy with .Net 2.0 and WSE 2.0.

So congratulations to everybody involved in developing these ideas, and a big thank you to all of you out there that reviewed, fed back, and otherwise encouraged. Now everyone, go join the mailing list.

Author Name:
Email:
Author URL:
Comment:
Antispam:
Please type the following string (note that if the strings don't match, your comment will be lost... sorry!): 'FNFEM'.
 
Recent entries

Recent comments

Feeds:
RSS 2.0 Atom