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.