|
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.
|
|