Today, InfoQ publishes an excerpt from Thomas Erl’s newest book (~30MB PDF), SOA Design Patterns, and used the opportunity to interview the author. Topics covered include the role of a patterns catalog, differences between service-orientation, SOA, and Web services, and the current state of the SOA world.
InfoQ: What do you see as the main benefits of having a pattern catalog for the SOA community?
Thomas Erl (TE): Design patterns can be useful to anyone interested in learning about how a given design problem has been successfully solved in the past. This catalog consists of a collection of design solutions specifically related to the realization of service-orientation.
The patterns community has done a great job of turning design patterns into its own field of expertise and I was fortunate to have received a lot of help from previously published patterns authors.
InfoQ: How much do you see your “SOA patterns” as being equivalent to “Web services patterns”?
TE: Well, I should first say that these are not "my" SOA patterns. This catalog was the result of a very large community effort spanning three years and involving dozens of contributors and over 200 reviewers. The previous books about SOA and service-orientation also benefited a great deal from community involvement and validation, but not at this scale.
With regards to your question, the patterns in this catalog have one specific context in common and that is service-orientation. Each pattern attempts to answer the question: "For this problem, what is a recommended design solution that will support the realization of service-orientation?" as opposed to: "How can this problem be solved with this specific technology?"
In other words, the patterns are not equivalent to or targeted at Web service technologies or any other specific technologies. It’s actually the other way around in that a subset of the patterns represent design solutions that were inspired or influenced by successful technology advancements. Some of those advancements came from Web services and Web-based technologies, whereas others came from EAI frameworks and middleware, enterprise service bus platforms, grid computing, transaction management systems, messaging queues, event-driven messaging frameworks, broker and mediation technologies, and several others. We also had planned to include about 20 pages of content related to a set of REST-inspired SOA design patterns, but these patterns didn’t survive the review cycles and were placed on the soapatterns.org candidate list instead. They are now being further developed in support of the SOA with REST book.
What might confuse some people is the fact that many of the examples provided in the book demonstrate the application of patterns using Web service technologies. Because this book is part of a larger library that is the Prentice Hall Service-Oriented Computing Series, we decided early on to limit the majority of examples to non-vendor-specific technologies. For this purpose, the available industry standards in the Web services space were a natural choice. The book makes a clear distinction between “service” and “Web service” in order to retain a separation of abstract content and examples based on Web services. Upcoming titles in the series will demonstrate the application of patterns using other technologies. So, you can view this book as the first publication of a greater body of work that will be explored across several other publications. Let me also state again that this all relates to a subset of the catalog. Most of the patterns were not specifically inspired by technology advancements but instead represent proven design techniques that were inspired by practitioners.
InfoQ: Do you see them as being applicable outside an SOA context?
TE: Yes, they certainly can be, the same way patterns from other catalogs may be suitable for solving other SOA-related design problems. Similarly, any of the technologies commonly associated with SOA (including Web services) can be used outside of the SOA context. The purpose of this catalog is to provide a set of design solutions that support the realization of service-orientation. So if you are planning to use a pattern for a different purpose, it’s a good idea to keep in mind that in this catalog they are only documented in relation to that specific context.
InfoQ: What’s your overall take on the current state of SOA? Where do you think we have a good and solid understanding, where do we need new research?
TE: I’ve been happy to see more people talk about service-orientation, which is what truly lies at the heart of anything legitimately labeled with “SOA”. I think that as the service-orientation paradigm becomes a greater part of the IT mainstream, there will be more wide-spread understanding as to how organizations can achieve the strategic benefits that have been historically attributed to SOA. Focusing on the paradigm also helps overcome the ambiguities and misperceptions that have led to disappointment in those that have attempted the adoption of SOA without having actually applied service-orientation. With regards to where we need new research, I can provide you with a pretty big wish list, ranging from service modeling notation and complex service composition to governance and organizational transformation practices.
InfoQ: This is the second time you have explicitly made a distinction between “SOA” and “service-orientation”. Can you quickly summarize your definition of service-orientation and its difference to SOA?
TE: Even though the SOA acronym often gets used by vendors and media as a general label or brand for all that’s related to services, when you get into the actual delivery life cycles you need to have a clear understanding of what makes a technology architecture service-oriented. This is what leads to the need to delineate the relationship and distinction between service-orientation and service-oriented technology architecture. Here’s one way of breaking it down:
Service-orientation is a paradigm that forms the basis of an approach to building software programs that collectively support the realization of a specific target state.
This target state is represented by a set of strategic goals associated with service-oriented computing. The application of service-orientation to a meaningful extent results in software programs that are considered units of service-oriented logic (referred to as services).
A service-oriented technology architecture has distinct characteristics in support of services and solutions comprised of one or more services (referred to as service-oriented solutions) and their enablement of service-orientation.
So, the “quick” answer is: Service-orientation is a distinct paradigm that you apply to achieve a specific target state and a technology architecture is considered service-oriented if it has the characteristics necessary to support the application of this paradigm.
I know that this is a pretty abstract definition, but it’s important to start at this level and make the fundamental associations before addressing related questions, like: “What is the target state realized by service-orientation?”, “What are the strategic goals of service-oriented computing?”, “What does the service-orientation paradigm consist of?”, “What are the required characteristics of a service-oriented technology architecture?” and so on. Much of what we’ve been writing about in this book series so far has been dedicated to answering these questions.
I think that if you’re new to service-orientation, an understanding of the aforementioned target state (and what is required to achieve this state) is key because that is what helps you determine whether service-orientation is supportive of your business goals and priorities and to what extent it makes sense to invest in its adoption. An understanding of service-orientation itself then becomes one of the core requirements for successfully realizing this target state to whatever extent you choose to adopt it.
InfoQ: How do you see a patterns catalog’s role in SOA adoption?
TE: One way of thinking of patterns is as bits of advice from experienced practitioners, except that they happen to be documented in a formal publication.
So, if you are in the midst of an adoption and find yourself facing certain challenges, a patterns catalog can be a helpful resource. Maybe you’ll find an exact solution to a problem or maybe you’ll find some related techniques and practices that inspire you to come up with a unique solution of your own. You might even be able to assemble a design solution by combining certain patterns together into an application sequence. On the other hand, you might be dealing with a problem for which no solution has yet been documented as a pattern or the problem has been addressed by a pattern but you may not like the proposed solution (just because a pattern offers advice doesn’t mean you should always follow it).
Another situation in which patterns can be useful is if you are planning an SOA project and want to get a better understanding of some of the more common challenges others have dealt with. In fact, some patterns can actually help you define your adoption plan. For example, Domain Inventory is a pattern that provides a common alternative to large-scale SOA projects by suggesting an approach whereby the adoption effort is segmented or phased into manageable, independent domains.
I also find that patterns can be useful learning tools, especially the more foundational ones. Because these patterns are specific to realizing service-orientation, you can gain some real insights into the unique dynamics and qualities of the service-orientation paradigm by studying their proposed design solutions. This level of understanding can reveal not just how SOA patterns solve problems, but also why they solve problems the way they do.
InfoQ: Thank you for your time!
TE: Thank you. I’d like to conclude by inviting people to visit and contribute to the soapatterns.org site that was recently launched. This site allows you to submit and review candidate patterns that can be further developed with community participation so that the master SOA patterns catalog can continue to evolve and grow over time.
Check out the sample chapter from Thomas Erl’s book, SOA Design Patterns, which has been created in collaboration with David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Copyright notice: This is an excerpt from the book, SOA Design Patterns, authored by Thomas Erl, with additional contributors, published by Prentice Hall, Jan. 2009, as part of The Prentice Hall Service-Oriented Computing Series from Thomas Erl, ISBN 0136135161. For more info on the book and the overall patterns catalog, please visit www.soapatterns.org