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
- Ability to create a work item by specifying a description and a participant or role. Once the work item has been created it will be placed on the participant’s or role’s work list. (NOTE: participant work list is private and a role work list is shared)
- You can retrieve a list of work items on your work list.
- You can retrieve a list of work items on another participant’s work list.
- You can retrieve a list of work items on a role’s work list
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
- Create a work item by doing a HTTP POST to the URI /workItems
- Retrieve my work list by executing a HTTP GET on the URI /workLists/myWorkList
- Retrieve joe’s work list by executing a HTTP GET on the URI /workLists/participants/joe
- Retrieve the testers work list by executing a HTTP GET on the URI /workLists/roles/tester
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.
- Create work item requires a CreateWorkItemRequest message as input and a CreateWorkItemResponse message as output
- Get my work list requires a MyWorkListRequest message as input and a MyWorkListResponse message as output.
- Get joe’s work list requires a WorkListForParticipantRequest as input and WorkListForParticipantResponse as output
- Get the testers work list requires a WorkListForRoleRequest as input and WorkListForRoleResponse as output.