SSDL in “Architectural Styles for Web Services”

This short article on “Architectural Styles for Web Services” mentions SSDL and MEST. Jim Alateras demonstrates how a simple Web Service could be described using WSDL, implemented using HTTP, and described using SSDL.The problem at hand makes SSDL look remarkably similar to WSDL. Indeed, the equivalent SSDL would be something like this (using the MEP SSDL Protocol Framework):

<?xml version="1.0" encoding="utf-8" ?>
<ssdl:contract xmlns:ssdl="urn:ssdl:v1" targetNamespace="urn:WorkManagerWebService:contract">
   <ssdl:schemas>
      <!- ->
   </ssdl:schemas>

   <!- Define the messages ->
   <ssdl:messages targetNamespace="urn:WorkManagerWebService:messages">
      <ssdl:message name="WorkItemCreateRequestMsg">
         <ssdl:body ref="s:WorkItemCreateRequestBody"/>
      </ssdl:message>

      <ssdl:message name="WorkItemMsg">
         <ssdl:body ref="s:WorkItemBody" />
      </ssdl:message>

      <ssdl:message name="WorkListRequestMsg">
         <ssdl:body ref="s:WorkListRequestBody"/>
      </ssdl:message>

      <ssdl:message name="WorkListMsg">
         <ssdl:body ref="s:WorkListBody" />
      </ssdl:message>

      <!- ->
   </ssdl:messages>

   <ssdl:protocols>
      <!- Define the MEPs ->
      <ssdl:protocol targetNamespace="urn:WorkManagerWebService:protocol"
                     xmlns:mep="urn:ssdl:mep:v1"
                     xmlns:msg="urn:WorkManagerWebService:messages">
         <mep:in-out>
            <ssdl:msgref ref="msg:WorkItemCreateRequestMsg" direction="in" />
            <ssdl:msgref ref="msg:WorkItemMsg" direction="out" />
         </mep:in-out>

         <mep:in-out>
            <ssdl:msgref ref="msg:MyWorkListRequestMsg" direction="in" />
            <ssdl:msgref ref="msg:MyWorkListMsg" direction="out" />
         </mep:in-out>
         <!- ->
      </ssdl:protocol>
   </ssdl:protocols>
</ssdl:contract>

This is a classic example of a Web Service implementing a request-response pattern or classic RPC-style. Both WSDL and REST/HTTP services can easily cope with this. However, the great value of SSDL is shown when we want to do more than RPC-style Web Services. For example, let’s say that we wanted to let the consumers of the “Work Manager” Web Service know about our messaging behaviour, the relationship between the interactions.

<?xml version="1.0" encoding="utf-8" ?>
<ssdl:contract xmlns:ssdl="urn:ssdl:v1"
               targetNamespace="urn:WorkManagerWebService:contract">
   <!- ->
   <ssdl:protocols>
      <!- Define the MEPs ->
      <ssdl:protocol targetNamespace="urn:WorkManagerWebService:protocol"
                     xmlns:csp="urn:ssdl:csp:v1"
                     xmlns:msg="urn:WorkManagerWebService:messages">
         <csp:process>
            <csp:sequence>
               <ssdl:msgref ref="msg:WorkItemCreateRequestMsg"
                            direction="in" />
               <ssdl:msgref ref="msg:WorkItemMsg" direction="out" />

               <csp:d-choice>
                  <csp:sequence>
                     <ssdl:msgref ref="msg:MyWorkListRequestMsg"
                                  direction="in" />
                     <ssdl:msgref ref="msg:MyWorkListMsg"
                                  direction="out" />
                  </csp:sequence>

                  <csp:sequence>
                     <ssdl:msgref ref="msg:ParticipantWorkListRequestMsg"
      direction="in" />
                     <ssdl:msgref ref="msg:ParticipantWorkListMsg"
      direction="out" />
                  </csp:sequence>
               </csp:d-choice>
            </csp:sequence>
         </csp:process>
         <!- ->
      </ssdl:protocol>
   </ssdl:protocols>
</ssdl:contract>

What the above says (using the CSP SSDL protocol framework) is that our Web Service supports the following sequence of interactions: A consumer of this service (within a particular interaction context) has to first send WorkItemCreateRequestMsg and only then can choose to send a MyWorkListRequestMsg or a ParticipantWorkListRequestMsg. There is no point in trying to send a MyWorkListRequestMsg first. We think that this is a cool way of capturing the semantics of a Web Service’s messaging behaviour.

At the moment there are 4 protocol frameworks available but more can be defined to meet different needs.