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.