Architecture & DesignBook Review: Web Service Patterns: Java Edition

Book Review: Web Service Patterns: Java Edition

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Web Service Patterns: Java Edition

By Paul B. Monday
ISBN 1-59059-084-8

352 pp. Price: $44.99
Published March 2003, Apress

The book under review is both thoughtful and thought provoking. It does to Web services design patterns (WSDP) what the Gang-Of-Four classic did to object–level (micro–level) design patterns (DP) and "Core J2EE patterns" did to inter–tier–level (macro–level) design patterns (DP), that is, it provides a catalog of 15 design patterns applicable to Web services. But the book is something more than a catalog. It is as much about the subtle paradigm shifts taking place in the post–dotcom era. The most important of these paradigm shifts is about Web services. So in this review we will confine ourselves to Web services paradigm only.

The author divides Web service design patterns into 5 broad categories:

  1. Patterns about Web services architecture. (3 DP)
  2. Patterns about adapting existing software to Web services.(4 DP)
  3. Patterns about notifying state changes in Web services.(3 DP)
  4. Patterns about refining the structure of Web services.(2 DP)
  5. Patterns about increasing performance of Web services.(3 DP)

The heart of the book is the first seven patterns. So now we dissect the
heart.

Every programmer from the dotcom era knows about n–tier architecture — a bunch of squares representing tiers connected by lines representing the communication between tiers. Web services introduce a new architecture called service-oriented architecture. This is represented by a triangle of client, server, and a yellow–pages directory that puts clients and servers in contact of each other. What this implies is that without the yellow–pages directory the clients and servers would have contacted each other directly in the traditional CORBA or RMI way. But now the directory allows them to contact each other more dynamically through a broadcast or multicast mechanism. This means that servers can publish their services in the directory. A client can multicast to various directories that it is looking for such and such a service. The directories will then send a bunch of server addresses that provide this service. And the client can choose whomever it wants. Now the client has a broad range of choices. It is not bound to one server. It is easy to see that this is much more dynamic way of communicating. The communication steps are called publish–find–bind.

This basic Web services mechanism is formalized into 3 design patterns:

  1. Service-Oriented Architecture design pattern.
  2. Service Directory design pattern (our yellow-pages).
  3. Architecture Adapter design pattern.

One thing to notice is that the Web services architecture is about communication — how servers publicize themselves and their products in yellow–pages and how clients hear about these servers and products from the yellow–pages. But it says nothing about how those products are created/implemented in the first place. That is still the job of traditional n–tier architecture. Thus two problems arise immediately. Create communication links between service–oriented architecture and n–tier architecture. This is taken care of by the Architecture Adapter design pattern. The other problem of creating traditional software and adapting it to
the dynamic communication mechanism of Web services is formalized into the following four patterns:

  1. Business object design pattern.
  2. Business Object Collection design pattern.
  3. Business Process design pattern.
  4. Asynchronous Business Process design pattern.

This covers the heart of the book. State change notifications in Web services use the classic Observer pattern. To increase performance the Data Transfer Object pattern from J2EE is used. All the patterns are implemented using Apache Axis.

Web services are evolving at a very fast speed. They started with the modest goal of allowing small applications to talk to one another. Now they are trying to arrange "high–level talks" between giants and superpowers like J2EE and .Net. The book makes due provisions for this fast evolution. In fact, a positive aspect of the book is that it can be (should be) generalized to other technologies like python, J2EE and .Net. This is enough to keep a few more writers employed for some time. The book can also serve as a one-semester graduate course not only to learn design patterns but also to get a feel of the directions software is moving in our post-dotcom era.

I do not know if there were some typo errors or such because I don‘t notice such things. I try to focus on fundamental issues. My tiny brain can’t absorb more than that.

Finally, a blood–curling scream from the deepest recesses of my dark soul. In the beginning there were just 23 patterns and it was perfect. Then came 17 more J2EE patterns but it was still OK. On their heels came another 10 or so theserverside.com patterns and it was not OK. Now we have another 15 Web services patterns. What is this?? How long will this continue?? How long and why??…

Rattan Mann
Oslo, Norway

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories