TangledWebs

From SPA Wiki

Jump to: navigation, search

Contents

WS5 Tangled Webs - Finding Patterns for Web Services

An OT2003 workshop run by Andy Longshaw and Eoin Woods.

The aim of the workshop was to review a number of widely used and well understood design patterns in distributed systems and to decide how those patterns applied to systems built using web services.

The concept of building a system with web services was broken into two separate pieces:

  • Web Services Technology - XML, HTTP, SOAP, UDDI, WS-... and all the rest of it. Does using this technology (as opposed to CORBA, RMI, DCOM, ...) change anything?
  • Service Based Style - using the technology implies a service oriented architectural style. What does this mean for the patterns we know and love?

The results of the workshop are summarised in the sections below.

Similarities and Differences

Building a system with web services (WS) is similar to using existing distributed systems technology in the following ways:

  • It is important to use coarse grained system elements (components) in order to achieve a well structured, performant system.
  • Interfaces are still hard to design well and the design considerations for interfaces haven't really changed.
  • The system's qualities are only as good as the weakest link in both cases.

Building a system with WS is different to using existing technology in the following ways:

  • Highly asynchronous processing is possible (via SMTP transport for example). This is less easily available in previous distributed development environments (some form of messaging needed to be separately integrated).
  • Web services are stateless (at least if you stick to the specs). This means that certain design patterns simply don't work.
  • Where conversational state is needed, this needs maintained at the application level (so application developers are back to building infra-structure just like the bad old days).
  • Inherent inefficiencies in the protocols and the likelihood of wide distribution in web services systems mean that the "remote" constraints that have always existed are now even more important to consider (latency, reliability and so on).
  • The current design approach of all web services being peers could easily lead to "service based spaghetti" if careful design principles aren't identified and followed, notably in the flow of dependencies.
  • Using the service based approach gives a clearer focus to reuse (as there are demonstrable tradeoffs between build vs buy/reuse).
  • Third party services are out of your control (and as we said that the system is only as good as the weakest link, this has serious implications if these services are involved in critical processing).

Good Web Service Patterns

Patterns which the group considered for use in WS systems that appeared to be good candidates for such systems were:

  • Facade to hide the details of existing systems behind WS interfaces
  • Data Transfer "Object" (although no encapsulation is possible) to allow data transfer back from services without needing object references and to improve efficiency by tailoring the data transferred
  • Broker to allow services to be located

Principles identified that suggest a pattern is well suited to WS systems include:

  • Patterns aimed at facilitating cross-platform operation
  • Patterns that reduce or eliminate conversational state
  • Patterns that reduce the amount of communication between system elements

Poor Web Service Patterns

Patterns which the group considered for use in WS systems that appeared to be poor candidates for such systems were:

  • Factory as it relies upon encapsulation and object references which aren't available
  • Iterator as it encourages a lot of interaction between system elements

Principles identified that suggest a pattern is poorly suited to WS systems include:

  • Patterns that require extensive "conversation" between elements
  • Patterns that require any form of encapsulation to exist between client and server


Andy and Eoin would like to thank all of the participants for their enthusiastic participation and valuable contributions to the workshop.