Chapter 1. Solving SOA pains with patterns
In this chapter
- What is software architecture
- What SOA is and isn’t
- Pattern structure
How do you write a book on service-oriented architecture (SOA) patterns? As I pondered this question, it led to many others. Should I explain the context for SOA, or explain the background that’s needed to understand what SOA is? Should I mention distributed systems? Should I discuss when an SOA is needed, and when it isn’t? After much thought, it became apparent to me: a book on SOA patterns should be a practitioner’s book. If you’re faced with the challenge of designing and building an SOA-based system, this book is for you.
You might not even agree with an SOA-based approach, but are forced into using it based on someone else’s decision. Alternatively, you may think that SOA is the greatest thing since sliced bread. Either way, the fact that you’re here, reading this, means you recognize that building an enterprise-class SOA-based system is challenging. There are indeed challenges, and they cut across many areas, such as security, availability, service composition, reporting, business intelligence, and performance.
There are many opinions as to what software architecture is. One of the more accepted ones is IEEE’s description of software architecture as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (IEEE 42010). My definition agrees with this one, but is a bit more descriptive:
Software architecture is the collection of fundamental decisions about a software product or solution designed to meet the project’s quality attributes (the architectural requirements). The architecture includes the main components, their main attributes, and their collaborations (their interactions and behavior) to meet the quality attributes. Architecture can, and usually should, be expressed in several levels of abstraction, where the number of levels depends on the project’s size and complexity.
The term SOA was first used in 1996 when Roy Schulte and Yeffim V. Natiz from Gartner defined it as “a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.”[1] Now, SOA is finally at the forefront of IT architectures and systems. But on the uphill and rocky road to stardom, SOA has become a loaded term filled with misconceptions and hype. As in the game of “telephone,” the definition of SOA has morphed as it was passed along in informal conversations. For the purposes of this book (and my view of SOA), we’ll use the following definition:
Service-oriented architecture (SOA) is an architectural style for building systems based on interactions of loosely coupled, coarse-grained, and autonomous components called services. Each service exposes processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. A service’s behavior is governed by policies that are external to the service itself. The contracts and messages are used by external components called service consumers.
One set of problems is the quality attributes not inherently addressed by SOA, like availability, security, scalability, performance, and so on. Real projects have to deal with requirements like five-nines availability (99.999 percent uptime), which is no more than about five minutes of downtime per year.
It would be nice if there were a few best practices already defined that could tell us how to cope with all of these issues. The truth is that there are no silver bullets in software design and development. Every system has its own set of prerequisites, hidden costs, one-off requirements, and special case exceptions. This is exactly why the use of patterns is so appealing as a medium to convey solutions. Patterns aren’t defined to be perfect solutions. Instead, they give the context for where the solution works. To achieve this, patterns describe both the solution and the problem they solve, and any caveats associated with that solution.
We’ve now laid the foundation you need to understand the SOA patterns in this book and their overall context. We began with a definition of SOA and patterns in general, and we considered how patterns can be used to provide solutions to SOA challenges. We also looked at the technical and business benefits of SOA. The second part of this chapter explained what patterns are, the structure of the patterns as they’ll be discussed in this book, and how to locate the patterns discussed in the book.
This chapter covered a lot of issues very briefly in order to create a common vocabulary for our discussion of SOA patterns. If you’re interested in learning more about the issues discussed in this chapter, look at one or more of the resources listed in the further reading section.
Arnon Rotem-Gal-Oz, “Fallacies of Distributed Computing Explained,” www.rgoarchitects.com/Files/fallacies.pdf. SOA is an architectural style for distributed systems. Most other styles don’t have a distributed mindshare and so, unlike SOA, they disagree with the fallacies. This paper, which I wrote, explains how the fallacies are still relevant today.
Dirk Krafzig, Karl Banke, and Dirk Slama, Enterprise SOA: Service-Oriented Architecture Best Practices (Prentice Hall, 2004). This is one of the best books on SOA, and it provides a very good introduction to the subject.