Web service patterns

DW Article series on SOA patterns

IBM's James Snell has a series of articles on SOA patterns. Part 1 talks about the 'asynchronous query pattern' and Part 2 covers the 'command facade pattern'.

Web Services Integration Patterns

Massimiliano Bigatti, in his article on xml.com, introduces some design patterns applicable to Web service that his team came across while developing an application for the banking industry.

]]> The patterns include the following:

Service Proxy
Proxy with Channel
Service Coordinator
Service Simulator
Configuration Driven Service
Data Logger
Flow Logger
State Logger
Input/Output Validator

In a series of two articles (here and here) Massimiliano explores these patterns. I've added links to these patterns in a SOA pattern catalog that I'm maintaining.

Facade pattern and Web services

The Facade pattern, defined by the GoF, provides a simplified/unified interface to a larger system.

The use case below explores how a Facade pattern can be implemented via a Web service interface.

]]> Use case:

An Enterprise system with a number of enterprise services. The services can be accessed via any mechanism- session EJBs, MDB, Web services, RMI, CORBA etc.

Solution 1

Develop a JavaBean Facade that invokes the services in the desired order.

Develop a Web service wrapper around the JavaBean Facade.

This approach is demonstrated in this developerWorks article.

Solution 2

Develop Web service wrappers around each of the services

Use a Web service composition language like BPEL to specify the invocation sequence. BPEL creates a 'composite service' out of discrete ones. This composite service has its own WSDL definition and endpoint. Client applications however see it as one Web service interface, and not a collection of services.

Some of the benefits of a Facade, as enumerated by the GoF, are:

Shields the client(s) from the system's subcomponents, and thus makes it easier to use
Promotes loose coupling between the client(s) and the system's subcomponents. This way you could swap out one subsystem without affecting the client(s). You might argue that Web services already do that- decouple the implementation from the interface. So if you are using Solution 2, you might not need to have a facade for loose coupling. True. However, using a facade allows you to go one step further; change the interface of a subsystem, combine two subsystems, change the sequence in which they are invoked, change the error handling logic in case calls to one subsystem fail, etc.

SOA Blueprints: Best practices for service-oriented architectures

The Middleware Company, in conjunction with other companies like BEA, recently published an example architecture utilizing SOA best practices. This architecture is available at the SOA blueprints website (registration required). The architecture demonstrates how an example HR system/Employee portal and Product services system can be designed using SOA. It also describes (briefly) the provisioning of an enterprise wide security service to provide authentication, authorization and auditing capabilities for all enterprise applications.

]]> The SOA Blueprints specifications identify the following to be common SOA patterns:

Synchronicity- Invoking services in two modes: synchronously or asynchronously.
Component Services- A simple atomic action on a simple entity that does not depend on
another service to function.
Composite (Business) Services - A composite service, also called business service, is also atomic in nature, but orchestrates the invocation of component services into a business level process. A composite service is stateless (unlike the workflow service), does not manage a long lived transaction (again, unlike workflow services), and may be invoked synchronously or asynchronously.
Conversational (Workflow) Services - A conversational service (also called workflow service) typically has state attached to it and looks like a classical finite state machine. BPEL4WS type Web service composition would be an example of a compositional web service.
Data Services - A data service provides a mechanism for querying a datasource or multiple datasources
through a message based request response mechanism.
Publish-Subscribe Services - Publish-subscribe services are ones in which interested parties (called subscribers) may request notification of certain events.
Service Brokers - An intermediary service that manages the invocation of a set of registered services based on a set of rules.
Exception Handling and Compensating Services - A compensating service (also called compensating transaction) is a mechanism for undoing some actions that were already completed that are now inconsistent because the service failed.
Interception and Extensibility - Interception is a mechanism for inserting additional functionality into a system without modifying or affecting existing components.
Interoperability - This means that the invocation mechanism, message format, data format and security
requirements of a service can be interacted with successfully by any SOA implementation.
Service Security - Set of techniques for ensuring protection of confidential resources. This includes wire level security (HTTP authentication, HTTPS) as well as message layer security (XML Signature, XML Encryption).

Personally, I'm not sure why Interoperability and Service Security are listed as patterns. Anyways, the Blueprints specifications also list common Anti-Patterns:

Overly granular business services
Remote access to local services
Overuse of XML
Use of loosely coupled services where tight coupling is required

This, I totally agree with. These anti-patterns would have a performance impact on your services. Other things to look at that relate to performance are listed in my weblog post from two weeks ago

IBM's Pattern website

IBM has a e-business Patterns website that really good. It classifies it's patterns as

Business patterns
Integration patterns
Composite patterns
Custom designs
Application patterns
Runtime patterns

Though these patterns are for Web applications, some of the runtime patterns I've looked at (and used), such as the High Availability Pattern and the High Performance Pattern are clearly applicable for Web services too.

Microsoft's Patterns and Practices

Microsoft has 'patterns & practices' websites that have catalogs of patterns. Some of them are Microsoft-centric, but many have applicability to any enterprise scenario. The websites are :

There is also a useful document on Enterprise Solution Patterns Using Microsoft .NET in the MSDN library.

A great website for Enterprise Java Patterns

I'm sure every Enterprise Java developer/architect knows of this resource, but I'm listing it here nonetheless: the patterns webpage at TheServerSide.

You should subscribe to their RSS feed, if you haven't already done so. The website also has a free book and source code download for the EJB Design Patterns book that covers many of the patterns discussed there.

Web service patterns

I've started a new weblog for exploring design patterns and their applicability to Web services. I'm armed with three good books for my journey- the classic Design Patterns book by the gang-of-four (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides), Core J2EE Patterns: Best Practices and Design Strategies, Second Edition by Deepak Alur, Dan Malks and John Crupi and Patterns of Enterprise Application Architecture by Martin Fowler. Hopefully these Web service patterns should translate into the .NET world too.

My intention is to see which of these pattens are applicable to Web services (and how) and also to explore new patterns of usage.

At first glance, there are three patterns that may apply (below), and I'll be exploring these in the months to come:

Adapter
Facade
Proxy