What is the Shape of a Service-Oriented Architecture?
Being in the analyst business, we at ZapThink see an awful lot of PowerPoint presentations. And it seems that every presentation has the one attractively drawn diagram that purports to illustrate how that vendor’s product fits into their customers’ IT environments. Such diagrams, however, rarely have any technical detail since they are not intended for consumption by developers or architects. Rather, they are typically created by marketing people to communicate to analysts, prospective customers, investors, and the press. Yes, I’m talking about marketecture.
Now, marketecture (“marketing” plus “architecture,” in case you haven’t figured that out yet) serves an important purpose. We’re talking about fairly complex concepts such as distributed computing architectures, and no matter how you cut it, such architectures have a lot of different pieces that talk to each other in numerous different ways. Every vendor must come up with effective approaches for simplifying their message so that people other than hardcore techies can understand it. So, while others may disparage marketecture, we at ZapThink understand its usefulness. The problem is, when it comes to illustrating a Service-Oriented Architecture (SOA), most marketectures fall short. Because SOAs represent a new approach to architecture, the “marketects” in various vendors’ marketing departments have a hard time coming up with how best to represent SOAs graphically in a way that conveys the essence of how an SOA is supposed to work in the context of their particular products and solutions. In other words, there is no consensus on what the shape of an SOA should be.
SOAs: Fundamental Principles
So, what are the elements of an SOA that are so hard to capture in a simple diagram? ZapThink has written extensively about SOAs over the past three years, but here are the basics. SOA is architecture that represents software functionality as discoverable Services on the network. SOAs have been around for many years, but the kind we talk about at ZapThink are those based on Web Services. Web Services are standards-based interfaces to software functionality.
The combination of Web Services and SOAs enable three key concepts we call idées fortes, or powerful ideas — loose coupling, coarse granularity, and asynchrony. ZapThink covered our idées fortes in an earlier ZapFlash, so please refer to that newsletter for more information on these key concepts. Loosely coupled, coarse grained, asynchronous SOAs provide a layer of abstraction that hides the complexity of the underlying technical implementation details from the business user who takes advantages of the Services the SOA exposes. These business-oriented Services are therefore both location independent and loosely coupled from the technology that supports them, thus enabling business agility — a primary goal for most businesses.
Marketecture #1: The Platform
Whether you favor Java 2 Enterprise Edition (J2EE), Microsoft’s .NET, legacy mainframe environments, or any other platform for that matter, the platform marketecture is a familiar, well-tested representation of the n-tier architectures that form the basis for most eBusiness solutions today. Because of this familiarity, all of the application server vendors use a platform marketecture to communicate their SOA-related concepts, like the one in Figure I below:
Figure I: BEA Systems’ Platform (courtesy of BEA)
There’s no question that SOAs can be built on top of application server platforms like BEA’s. In the platform metaphor, Web Services typically appear at the top or near the bottom: at the top when representing interfaces that various consumers can access, and near the bottom as just another way to access the interfaces of back-end systems.
Now, literally speaking, Web Services are nothing more than standards-based interfaces, so there’s nothing strictly incorrect about this representation. However, the “layer cake” platform marketecture doesn’t represent some of the key characteristics of an SOA well. First, platforms model synchronous behavior better than asynchronous — application servers have been built to reliably handle synchronous, Web-based requests, but it’s not clear that they are well-suited for the sort of coarse-grained, asynchronous, federated, process-driven Services that make up an SOA. Second, the platform marketecture doesn’t adequately represent the layer of abstraction between the business and technology an SOA represents. As Figure I shows, process integration is just one of the flavors of frosting on the layer cake — nowhere in the marketecture is there a recognition that process should be loosely coupled from the underlying technology via a Services interface. In fact, this “layer cake marketecture” implies a tightly coupled implementation — all the pieces must work together tightly in order to gain any SOA benefits.
Marketecture #2: The Bus
Enter the bus. The software world commandeered the bus metaphor from the computer hardware world, where a bus is literally a set of wires that provides a common conduit for communications among components that are connected to the bus. This idea is echoed in a software bus, where various applications can communicate using message technologies that run on the bus, so that you don’t need to integrate each application with every other application directly. The bus then handles the various messages moving along it, providing reliability, transformation, routing, and other services as necessary.
Many Enterprise Application Integration (EAI) architectures are based on buses, like TIBCO’s messaging bus, shown in Figure II:
Figure II: TIBCO’s Messaging Bus (courtesy of TIBCO)
When it comes to representing an SOA, buses have an advantage over platforms in that they are essentially asynchronous and distributed — applications put messages on the bus and take them off the bus when appropriate, and the bus handles the rest. However, when buses are intended to integrate applications, they are adapter-centric instead of Service-centric. Every application must essentially be hard-wired to the bus, limiting the flexibility of the Services interface that an SOA provides.
A messaging-based infrastructure like a bus can also be loosely coupled more easily than a platform can, since all interactions in a bus happen at the message interface, where systems interact via messages, which is an improvement over platforms that require components to exist in a runtime container. In fact, it’s not just asynchrony, but also loose coupling that makes messaging technologies a compelling basis for SOAs.
However, the bus model might work a lot better for representing SOAs if only it had Service interfaces. That’s the thinking behind Enterprise Service Buses, a relatively new kind of bus metaphor that companies like Sonic Software are espousing. An Enterprise Service Bus (ESB) has a communications backbone that’s an asynchronous bus similar to TIBCO’s, but on top of that are additional capabilities that allow the bus to expose Service interfaces, as shown in Figure III:
Figure III: Sonic Software’s Enterprise Service Bus (courtesy of Sonic Software)
The kind of ESB that Sonic and a few other vendors offer is essentially a set of distributed Service containers connected by an asynchronous, message-based communications backbone. Not only does the ESB offer a Services interface for each system that is connected to it, it also includes a distributed Services architecture that loosely couples the participants, as well as providing coarse-grained Service functionality through the support of orchestrated business processes. The question all the ESB vendors must struggle with, however, is whether the bus metaphor is really the right marketecture to illustrate this layer of abstraction.
Marketecture #3: Web Service Fabric Or Service Grid
What if you take the ESB shown in Figure III, and instead of trying to communicate an SOA from the perspective of the communications backbone that forms the bus, you instead illustrate the abstract nature in which different Services in an SOA relate to one another? What you end up with is a bunch of Services scattered around, loosely connected by an underlying technology infrastructure that is meant to be hidden under the Services layer of abstraction, without a clear description of the infrastructure that the platform and bus marketectures provide.
Whether you say “fabric” or “grid,” the essence of this particular marketecture is the layer of abstraction, separating the Services and the business processes that compose them from the underlying technology implementations of those Services. Such fabrics are hard to represent in a diagram, however, as The Mind Electric’s attempt in Figure IV shows:
Figure IV: Web Services Fabric or Service Grid (courtesy of The Mind Electric)
The problem with Figure IV is that it looks like the various systems miraculously connect to each other — completely hiding the real complexity and details that are required to make the above interaction work. In other words, this marketecture looks more like a high-level model for decentralized integration than for how a product implements an SOA. In addition, the idea of “grid” is becoming more associated with the related, but different concept of grid computing. Now, grid computing also represents a layer of abstraction, and many of today’s grid computing approaches are Service-oriented, but a marketecture for an SOA that looks too much like a grid is more likely to be confusing than clarifying. In fact, this sort of diagram leaves the reader with more questions than answers about an SOA.
So, while the concept of a Web Services fabric may represent the essential elements of an SOA, or at least represent the ideal of a well-implemented SOA, it’s still not clear that a Web Services fabric diagram like Figure IV will be able to give people the right ideas about SOAs. In fact, you could implement the fabric illustrated in Figure IV in an tightly coupled, synchronous, fine-grained fashion. The problem with the fabric marketecture, therefore, is that it doesn’t explain any of the details required for an SOA. There’s still something missing.
The ZapThink Take: The SOA Metamodel
The problem that all of the marketectures considered above share is that they all illustrate software and its functionality. In other words, they start from the nuts and bolts of the software and systems, and then illustrate the functionality of that software. SOAs then become expressed in terms of software functionality, rather than in terms of the Services themselves that comprise an SOA.
Marketing people continue to struggle with this problem, because after all, SOAs are in reality built from software functionality. The problem, you see, is not one of reality, but of perception — platforms, buses, and fabrics simply do not do a very good job at explaining what an SOA is all about. They may be accurate, but they don’t fully satisfy the requirements for a marketecture — that is, to explain an architecture in a way that people of different backgrounds can understand.
At ZapThink we’re helping to solve the marketecture problem by starting at the other end of the problem. That is, instead of thinking in terms of software and working our way up, we think in terms of models of the business, the Services, and the technology, and work our way down. ZapThink’s take is therefore a model of models, which we call the SOA Metamodel, as shown in Figure V:
Figure V: The SOA Metamodel (courtesy of ZapThink)
The Service model in the center of the SOA Metamodel is the key to understanding SOAs. This model represents the Services that are available to the business. On the left of Figure V, the Business Model represents the business users and their requirements — in other words, use cases. And on the right of the figure, there are various implementation models that represent the underlying technology that supports the Services represented in the Service model. (You can learn more about the SOA Metamodel in this article).
The SOA Metamodel works both at design time — when architects are planning the SOA — as well as at runtime, when the SOA is in production. Business users and business analysts access the Services in the Service model, and orchestrate them into processes (which can also be Services represented in the Service model). If the business needs a new Service, or new functionality from an existing Service, business analysts use the Service model to represent those new requirements. The technology team then uses the Service model both to implement new business requirements, and also to represent the software functionality that is currently available to the business.
It’s important to note that the SOA Metamodel is not itself a marketecture. Instead, it acts as a guide for understanding and building SOAs, and thus it can also act as a guide for vendors who are struggling with their own marketectures. What it does provide is a clear layer of abstraction that separates the business from the technology, and provides a representation that distills the essential elements of an SOA.
So, if the SOA Metamodel isn’t a marketecture, than how can you use it to help with your own marketectures? The answer to that question really depends on what part of the SOA puzzle you’re trying to solve. Some vendors focus on the technology implementation, others focus on Service composition and business process, while yet others center on enabling some aspects of the Service model. After all, each vendor’s marketecture must be differentiated from other vendors’, so there is no one correct answer. The important lesson to be learned from this article, however, is that SOAs provide a layer of abstraction that separates business and technology users, and any product that supports an SOA must support this layer of abstraction.