O'Reilly Network    


 Published on The O'Reilly Network (http://www.oreillynet.com/)
 http://www.oreillynet.com/pub/wlg/6586

Architectural Styles for Web Services

by Jim Alateras
Mar. 1, 2005

The recent release of the SSDL Specifications has further stimulated discussions on architectural styles for web services. There are plenty of definitions of software architecture but this one from Roy Fielding's Phd Dissertation resonates with me. An architecture provides a context for looking at a problem domain and identifying abstractions and their relationships for the solution space. The architectural style whether object-based, resource-based or message-based will influence the set of abstractions and to some degree effect the maintainability, readability and extensibility of the service. (I am in the process of gathering data points to prove or refute this last statement)

For the moment I want to go thorough three architectural styles using a simple example to illustrate the abstractions promoted by each style. The requirements for the Work Manager service are shown below followed by a brief analysis for the different architectural styles.

Simple Work Manager Requirements

My simple work manager service has the following requirements

Object Based Architecture

In an object based architecture the first class abstractions are classes/interfaces, data and operations. WSDL provides a platform neutral mechanism to describe the work manager service using these abstractions.

A partial WSDL document defining the web service is provided below. It define the WorkManagerService with four operations and the associated message structures. The WSDL document can be used to generate bindings to different languages (i.e. WSDL2Java for Java binding). The operations define the published interface for the service and the messages define the structure of the request and/or response. SOAP is the standard wire level protocol.


<definitions name="WorkManagerWebService">
	
  <portType name="WorkManagerPT">
    <operation name="CreateWorkItem">
      <input message="tns:CreateWorkItemRequestMsg" />
      <output message="tns:CreateWorkItemResponseMsg" />
    </operation>
    <operation name="GetMyWorkList">
      <input message="tns:GetMyWorkListRequestMsg" />
      <output message="tns:GetMyWorkListResponseMsg" />
    </operation>

    <operation name="GetWorkListForParticipant">
      <input message="tns:GetWorkListForParticipantRequestMsg" />
      <output message="tns:GetWorkListForParticipantResponseMsg" />
    </operation>

    <operation name="GetWorkListForRole">
      <input message="tns:GetWorkListForRoleRequestMsg" />
      <output message="tns:GetWorkListForRoleResponseMsg" />
    </operation>
  </portType>
</definitions>

Resource Based Architecture

REST (REpresnetational State Transfer) defines an architectural style, which is based on XML, URIs and HTTP. The REST architectural style is described in Roy Fielding Phd Dissertation and embraces the principles of the WWW that have made it the largest, most distributed and scalable application on the planet. In a REST world the fundamental abstractions are resources. Generally, all resources have a uniform interface that provides the capability to create, read, update and delete the resource. The work manager service consists of two resources, workItems and workLists. There is no widely used description language for REST but Web Resource Description Language" is a work in progress.

Using the defined resources we can

Message Based Architecture

MEST (MESsage Transfer), is another architectural style, which defines messages and services as first class abstractions. Interactions between entities are described through message exchange patterns (MEPs), which capture temporal and spacial information about the interaction. There is even a relatively new description language SOAP Service Description Language for it, which from my understanding is based on SOAP one-way messages.

I don't have the mastery to write a SSDL document but you can probably get the idea from the following, which describes each MEP for the service.

Jim Alateras is an independent consultant specializing in open source and emerging technologies.

oreillynet.com Copyright © 2006 O'Reilly Media, Inc.