A few years ago, I wrote a book with a colleague about open source ESBs (Enterprise Service Buses), Open Source ESBs in Action (Manning, 2008). In that book we wrote about using open source tools to integrate applications and expose legacy systems as services. In the years that followed, ESBs were seen as one of the cornerstones of developing Service Oriented Architectures (SOAs). In 2008, when people talked about SOA, especially in the enterprise world, they meant the traditional SOAP-over-HTTP-based services. Everyone was doing this, the big vendors promoted it, and it finally looked like we had a way to create services that could be used by other departments and multiple users.

Over the next couple of years I wrote many services myself and was part of many projects that tried to use SOA concepts to create reusable services. What I noticed was that every company and every department had their own standards, tools, technologies, and a set of principles they used to determine how a service should be written. For one project we created a RESTful service using Scala without writing any documentation; for another project, we meticulously documented each element and operation of a SOAP/HTTP-based service. But the goals for both projects were the same: we wanted to create a service that would have a long life, would be used by many consumers, and was easy to maintain and possibly extend.

One thing I know is that developers and architects want to create good services, but what is almost always missing is a solid set of rules and standards to follow when developing a service. In our projects we often create a set of coding standards that are enforced through an IDE plugin, as well as some coding guidelines and dos and don’ts. While that assures the quality of the code, it isn’t enough to create an easy-to-use service. For this you also need a set of rules, a set of principles that determines how your client interacts with your service. In other words, it is good to have a set of policies that help you define the contract of your service.

And what happens after a service is in production? I know from experience that measuring who is using a service and garnering insight into the business processes using your service can give you valuable information. This information can help you determine where to focus your development, where to add resources, and much more.

What I needed was a form of SOA governance. I wanted a set of policies we could use while creating the service (design-time governance) and a way to measure how our services were being used (runtime governance). Most books on SOA governance focus on the process, which is also very important, but they often lack practical examples. This book tries to provide you both with a set of guidelines for and practical examples of how to apply SOA governance.

I hope this book will show you that getting started with SOA governance isn’t that hard and that it provides many advantages—and that there are plenty of open source tools that can help you take the first steps.