In 1996, I led development in a small startup. I had worked on multiuser systems before, but this was the first big distributed system I wrote. I found out the hard way that it isn’t a simple task—a lot can and does go wrong, and simplified assumptions you make at the onset will come back to haunt you.

I learned my lesson, and I’ve been developing distributed systems ever since. Over the years, I discovered service-oriented architecture (SOA), and I found that, with its emphasis on interfaces and flexibility, it’s a really good way to build distributed systems and it brings a lot of benefits. As I spent a few years working on many projects, I saw that a lot of people misuse SOA, that a lot don’t understand it, and that good advice is hard to find. I decided to write a book—the year was 2006.

It is now 2012 and the book is finally finished. Any author will tell you that writing a book is hard, and it takes more time than initially thought. This is all true, but that’s not my excuse. I finished the first third of the book reasonably on schedule, but then I joined another startup, which consumed every shred of free time I had for almost four years. On the upside, I gained more experience and I went over what I had written and updated the technology mapping sections, so you’re essentially getting a second edition now. Also, the startup that prevented me from completing this book stars as the case study for chapter 9, so it did contribute something to the book as well.

Why patterns? That has to do with the first startup where I worked. As we worked on the development of the user interface (UI), I had this innovative idea—we should separate the UI logic from the UI controls and from the data-access code. This would give us more flexibility and better testability. It was only later that I learned that my “innovation” had been developed in the 1970s. It also had a name, and it was also more refined and solved the problem better—it was the Model-View-Controller (MVC) pattern. This discovery of documented architectural solutions and the time they can save in development sparked my interest in software patterns.

I really like the fact that patterns present a problem in context and don’t presume the solution is always correct. I think that’s a great way to present a topic, and it also let me break the book into independent bits, which makes the book usable as a reference and not something you need to read cover to cover.

One point about this book that’s relatively unique is that I wrote about architectural patterns and not design patterns. I think it is beneficial to provide guidance at the architectural level and to understand the impact it has on the system as a whole, and not focus solely on the local effect as design patterns do. This is especially important when we’re talking about SOA, because SOA is about the overall system more than it is about individual components. Another important benefit of focusing on architecture is that architecture transcends technology. The technology mapping section for each pattern shows just some examples of where each pattern can be used; you can apply the ideas using the technology of your choice.

This book summarizes my experience writing distributed systems in general, and SOA systems specifically. I hope you find it useful.