Service Design Patterns

One of the inevitable truisms of enterprise applications is that they are not islands. You may be focused on solving a particular business problem, but in order to do that you won't be able to capture all the data you need yourself, or develop all the processing. Even if you had the time, that data and processing is being done elsewhere, duplication is both wasteful and leads to messy inconsistencies. As a result almost all enterprise applications need to communicate with other applications. These foreign systems are often not in the same organization, but provided by some third-party organization.

For many years, one of the hardest parts of this kind of collaboration was just to get some kind of communication path. Often these applications were written on different platforms, with different languages, on different operating systems supporting different communication protocols. But in the decade or the web has appeared as a solution to the connection problem. Almost all systems can open port 80 and talk text over it.

But that still leaves many questions around how they should talk. Should they use a RPC style API, a message oriented API, or this fashionable REST stuff? Should logic be embedded in services directly or delegated to underlying objects? How can we change services that are already in use without breaking clients?

Generally in my series, the books have featured topics that haven't been covered much elsewhere, but there's already been too many books about various aspects of web services. As a result, when a draft of Robert's book came to me across the ether, I didn't think I would be interested in it. What changed my mind was that it brings together these key questions into a single handbook, in a style that I like to see in a technical book that's worth the effort of reading.

Firstly he takes the approach of breaking up the topic area into patterns, so we have vocabulary to talk about these topics. Then he goes into each pattern explaining how each one works and how to choose between them. As a result you are able to see the various approaches to web service design and decide what will work for you in your context. He provides code examples, so you can see how these patterns might work in practice, yet the patterns are general enough to apply to many technology stacks.

The result is a book that collects together the important design decision points for using web services in a style that focuses on principles that are likely to be valuable despite changes in technology.