One of the classic scenarios I encounter frequently when discussing Service-Oriented Architectures (SOAs) is agreeing on what is meant by the term. Everyone has their own personal definition of what a SOA is, and they all too often aren't very similar. Inevitably, this makes the discussion fruitless because there's no shared understanding and the conversation quickly digresses into a debate on defining SOA. This immediate mental short circuit hampers a lot of useful discussions and I've attended way too many meetings where folks talk past each other because they have very different implicit assumptions around the term. This seems tragic to me because there's so much about SOAs that are important to the industry, even momentous. We as an industry can no longer afford vague, sloppy, or overly general definitions of the concept. But SOA definitions have been a
tough nut to crack, and
rampant hype and overuse of the term hasn't helped.
Now for the good news. If you take a careful look around, some really good work has been done recently on SOA definition, and a surprisingly coherent new picture can be assembled. General noise and bluriness have been drowning out SOA basics due to the scale and scope of the concepts, especially in the presence of SOA marketectures from vendors with views of SOA that benefit their particular product's strengths. So too the big picture aspects of SOA at the organization level are notoriously hard to grapple with intellectually and sort out. Finally, SOA itself is a seemingly vast umbrella for related architectural constraints that can be assembled a lot of different ways. This makes depictions frequently seem jumbled, overwrought, and confused. Yet I am beginning to believe that order indeed can be brought to the chaos that seems endemic in SOA architecture thinking.
It appears now that focus could at last be achieved by simply deriving clean, straightforward principles on what service-orientation is. Having a compelling set of architectural constraints that sum up the driving forces in SOAs would be tremendously useful to the IT community, and its frequently fumbling or stalled SOA efforts. If we only had these easy-to-manage-from drivers then a lot of ongoing SOA architecture issues could be directed towards resolution. We could figure out how deep our WS-* stacks should be, understand if Ajax is important to SOAs, if BPEL is as important as it looks, and so many other bugaboos that that plague SOA builders daily. Would that such a set of SOA principles actually existed!
Figure 1: Service-Oriented (SO) principles can orient and focus SOA efforts on ground truth
Fortunately, but not yet widely known, is that formal, recognized, and eminently useful service-oriented principles do exist today. The founders of ServiceOrientation.org are one group in particular that are doing the industry a huge service and providing effective research and promotion of the principles of service-orientation. Founded by the widely-regarded SOA luminary and thinker, Thomas Erl, ServiceOrientation.org distills the major technical constraints of SOAs into eight basic principles: reusability, contracts, loose coupling, abstraction, composability, autonomy, statelessness, and discoverability.
Currently, the main ingredients of most SOAs revolve not only around service-orientation but also adopt many architectural elements from the distributed systems world, component-based design, and even WWW architecure. Since service-orientation is in an active state of evolution it's also increasingly flirting with the outskirts of the Web 2.0, the Semantic Web, and even SOA 2.0, as the world-wide web increasingly becomes its own computing platform. This is something that SOAs will help enable as they are likely to form the glue between the edge of the Internet and organizations that plug their service-oriented IT systems into the global web fabric to collaborate.
But back to basics. Deriving the cleanest and clearest definitions for SOA that aren't too general is the goal here. Can we go a level above the eight SO principles? A few people have tackled this head on and some have been fairly successful. As always in architecture, the challenge is to ensure that only the essential details are described and everything else is elided. It's here that John Reynolds' well-known SOA Elevator pitch comes tantalizingly close to capturing the essence:
SOA is an architectural style that encourages the creation of loosely coupled business services. Loosely coupled services that are interoperable and technology-agnostic enable business flexibility. An SOA solution consists of a composite set of business services that realize an end-to-end business process. Each service provides an interface-based service description to support flexible and dynamically re-configurable processes.
This business view is right on, and doesn't mean business in a traditional, white-collar way. In this context, "business" means the actual functionality of the system, apart from technical details. John's definition is well-aligned with ServiceOrientation.org's eight basic principles and if you look around most others will too The eight principles seem about right to have actionable meaning yet be within the conceptual grasp of most practitioners. Give it a try, you'll see what I mean.
Service-Orientation Principles Can Quickly Resolve Many SOA Questions
OK, seems straightforward so far, right? But how does this explain my recent misunderstanding with Nick Malik about my assertion that Ajax will likely be a major driver for SOAs next year? I still stand by this point since it seems pretty obvious. But the discussion immediately got off onto the wrong foot. Nick has a clear view of SOAs for himself and it's a fairly corporate, WS-* version of affairs. But in reality, while WS-* does a lot of nice things for heavy-weight SOAs in a somewhat standard way, it's exclusionary and I've written numerous times how loose-coupling is likely to be badly broken by WS-* services. WS-* service stacks often tightly couple functionality together at several levels including schema, protocol, and even the transport layer.
Interestingly, Service-Orientation.org's eight principles do NOT include interoperability, only loose-coupling. Assuming for a moment, that these eight principles are right (and in my opinion, they're pretty close to the money), loose-coupling is actually a superset of interoperability. In this way, we can quickly make a determination that WS-* services may or may not be appropriate for a SOA. And in this view, they may not based on whether or not service-orientation is important.
My personal take is that the information barriers between departments, organizations, and their customers and clients will continue to blur and become indistinct by an ever increasing level of integration including instant availability and synchronization of changes to clients and suppliers. Good service-orientation makes this not only possible, but extremely likely, and locking up services behind a WS-* wall of mustUnderstand SOAP attributes will probably be fatal to many of the greater goals of service-oriented architectures. I currently caution people to very, very careful when they add another web service standard to their services stack, since each one reduces composability, reusability, and loose-coupling. But again, evaluating these against the basic principles can make this a fairly simple, painless decision point.
Getting back to the original argument, technologies like Ajax are a lever that can move the world and will certainly have an impact on whether a SOA succeeds or fails on its own merits. Not dealing with service stack size, security, load, performance and other matters, issues which Ajax applications all force into the foreground, can be a deal breaker. And thinking of Ajax as purely a user interface technology is a grave mistake. Ajax is a major agent of service composability in its own right (remember that composability is one of the eight SO principles), but Ajax is also an agent of reuse and wants to consume services voraciously to boot. In reality, Ajax is the enabler of many of the SO principles and so it's on my radar in a big way. Again, making this determination if fairly easy if you have simple way to check yourself.
Focusing on a particular view of SOA, whether it's for heavy-weight application integration, or fine-grained web friendly XML services on the edge of your architecture, is the mistake. Services without architecture in other words, is bad. Taking a higher level, more comprehensive view of services is where it's success lies. You will have many aspects to your SOA in your organization, from 1) simple WS-I web services stood up by smaller development groups, 2) large federated Enterprise Service Buses carefully snaking around entrenched legacy systems, and 3) business reengineering groups installing workflow, orchestration, and choreography tools that weave together business process out of these services. All of these developments and others, like Ajax applications sprouting up and using this infrastructure and their services (directly, or through proxy services that add WS-* adapters) are facilitated if you stick to the eight basic principles of service-orientation. These are tenets that can be internalized, readily understood by most audiences, and effectively evangelized by SOA architects.
In practice, I also use some world-class resources for SOA patterns and practices in addition to the eight SO principles. One of them in particular is the practically ignored, but absolutely fabulous IBM Redbook on Patterns for Service-Oriented Architectures and Web Services. This underappreciated -- and free -- 370 page tome (with virtually no links in del.icio.us at the time of this writing) is a must read for SOA architects and describes everything from the internal structure of good SOA services up to how to engineer a comprehensive enterprise SOA architecture. It also includes useful details on how to deploy and manage SOA services as components and much more, all with consistent examples throughout.
The danger of this type of material though, as good as it is, is that it fails to keep the ground rules in sight throughout. And that's the point of this blog article. One or two sentence SOA definitions are certainly great cocktail party fare, but that's all. As a SOA evangelist, going one more level deep, and staying there, is the key to success. This gives your service builders crystal clear guidance yet free rein to use their local tools, products, technologies, and whatever else. And as long as they stay service-oriented that is. Then, no matter what, the promise and possibilities remain open to build stunning composite business processes, integrate with anyone and everyone, and all the other benefits that properly architectured service-oriented systems give you. The key take away is that service-orientation, unlike SOAs, is not complex and keeps you directed, and is the definition we needed all along to maintain focus and direction. But you do have to be principled and stick to the rules.
Must-Have Service-Oriented Architecture Reading:
Thomas Erl's Service-Oriented Architecture : Concepts, Technology, and Design (August, 2005)
David Chappell's Enterprise Service Bus (June, 2004)
Doug Kay's Loosely Coupled: The Missing Pieces of Web Services (April, 2003)
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services, SOA