Beyond the Hype: Succeeding With SOA Through PatternsBeyond the Hype: Succeeding With SOA Through Patterns

There's little doubt that component reuse and increased flexibility are major objectives flowing out of the popularity of service-oriented architecture (SOA). Companies of all kinds and sizes are focused on reducing costs as well as business risk; they're improving the delivery and management of customer service and support; and they're tightening business/IT alignment through SOA-based solutions. Such success has not only confirmed the growing ease of building, deploying, and consuming Web services, but has also revealed one of the most fundamental SOA success factors: that is, that software reusability and flexibility don't arrive "automatically" with the new technology. In other words, using Web services alone doesn't guarantee reusability and flexibility.

Indeed, as more organizations build, deploy, and orchestrate business services using Web services, it has become apparent that you need careful and comprehensive application design to ensure delivery on the promises. What are the most significant factors to ensure reusability and extensibility of services?

Critical Success Factors

The first factor is proper verification of reusability potential across business domains. The goal should be to stay away from developing services based on the functional requirements for one project, without conducting accurate cross-domain analysis. Never assume that if even if developers correctly employ service interfaces and XML standards that services will be effectively reused by other projects.

Second, pay very close attention to service structuring. Too often, services aren't easily reusable in other projects because their structure (composition of components and their relationships) tends to be overly dependent on a particular realization of Web services interfaces. Dependencies among components within a service make the service less usable in other contexts. Moreover, when new functional requirements appear, it's difficult to extend the existing interface or isolate the changes. Also, new interfaces must be put in place, especially when the service control logic is buried in the code that does Web services processing.

The third factor is scalability. A frequent reason why you can't achieve reusability is poor scalability of deployed services. If component responsibilities within a service aren't optimized among distributed processing elements, services won't scale to high-volume levels in a cost-effective fashion.

Patterns to the Rescue

Since the seminal book Design Patterns (by Gamma, Helms, Johnson, and Vlissides, often called the "Gang of Four") was published in 1995, patterns have become a widely accepted form of stimulating software reuse. However, the impact is often limited by patterns' use as merely reference tools that give guidance for handling particular design problems. They should be considered a critical constituent of the architectural requirements for SOA, serving as a starting point in influencing decisions about organizing and structuring business services.

In this article, I'll discuss identification and use of two architectural patterns important to SOA: Layering/Tiering and Mediator. I've picked these two from among many others that are important, including Message Exchange Pattern (MEP), Java 2 Enterprise Edition (J2EE) core patterns (Business Delegate, Facade, Web Broker, others), and so on, because of their direct association with the issue of service structuring.

While you can find many good articles about SOA — and I'll be assuming in this article a general familiarity — little published information exists about how to identify key elements relevant to architectural structure. The chief issue is how to properly construct a high-quality, large-scale application by separating end-to-end processing into service-oriented n tiers. How do you implement each tier in a layered manner to increase architectural flexibility and reduce management and support burden? How do you properly leverage standard components where the module functions are oriented toward business services, and in light of emerging Web services technologies? The truth is that even if we were able to precisely identify "serviceable" business functions and have all the necessary application and middleware tooling, we'd still have no answer to the main question: How do we arrange application functionality or responsibility among distributed processing elements to maximize quality features when using Web services?

Single Service Layer: Not Enough

Figure 1: The service layer. (Adapted from Patterns of Enterprise Application Architecture. See Resources.)

For many organizations moving to SOA, layering was a logical first step in their architectural philosophies. Layering is considered key to reducing the coupling between interacting software systems — and achieving the SOA goal of loose coupling. Most focus on providing a service layer that hides the underlying service implementations from the client. In other words, with a dedicated service layer the service itself becomes abstract; service requests and responses can be made independent of the location, storage, or presentation mechanics (see Figure 1).

However, in practice, especially in high-volume situations, having a single service layer isn't enough. The most common pitfall is that you'll create a service layer that directly wraps all of the exposed "methods" of different kinds of components, without providing any additional abstraction. The result is that developers circumvent the principle of encapsulation and unnecessarily duplicate features, leading to redundant code. Here's a simple example: let's say we have three components that support the following business objects: Orders, Items, and Descriptions. Both Orders and Items have descriptions. With a single service layer, we may end up with an Orders service and an Items service, where each service provides support for descriptions; that is, each service might have something like addDescription().

Layering must bring a reduction in overall complexity; however, in my example, we haven't reduced complexity. To the contrary: Wrapping each use case inside a single layer and exposing a Web services API to every method results in a large number of interfaces that exhibit similar behavior (for example, GetAccountBalance, UpdateAccountBalance, TransferFunds, ListAllAccountBalances, and so on). We end up with more complexity, not less.

Essence of SOA Layering

Figure 2: Generalized service layering pattern.

What does layering really mean in an SOA context? In the purely structural sense, the service layer that hides the underlying service implementations should be partitioned into a number of layers (or sublayers), which are placed on top of one another in such way that services of layer "n + 1" consist mostly of the services exposed by the service facade of the layer "n" (as shown in Figure 2). By not "multiplying" but instead nesting service facades, we can manage services granularity — ranging from very coarse-grained services to medium and then to fine-grained services. "Coarse-grained" means more formal, generalized interfaces; a coarse-grained service interface provides an abstract view of the subsystem (for example, Order Management, Account Management, or Pricing). The main idea is to employ a sufficient composition of multiple facades behind which hide all the details of the underlying business logic. Only this moves us significantly toward a fully SOA-compliant solution.

How do we properly identify those layers? Staying with service orientation, a crucial design decision for the structural part of the services model is the distinction between external and internal behavior of a service. The externally visible service behavior is described by the concept of use cases, where each use case represents a unit of functionality that's meaningful from the end user's point of view. Within the organization, business processes, business functions, or business interactions realize use cases. Furthermore, business processes, functions, and interactions, in turn, may depend on other services (internal to them, but external to some other smaller entity within the organization).

So, generalizing from the standpoint of use cases, we see that the SOA-driven architectural layers constitute some sort of hierarchy within an enterprise. A common way of looking at an enterprise SOA model is to start from the business processes and activities performed. These activities should be viewed as business services to this business process, rendering a specific reusable functionality to the process at hand. Business services constitute the highest level of layering (the "top" layer of service hierarchy). Moreover, business services are a mechanism for instantiating and exploiting the lower-level services (often referred to as "core" or "basic" application services, such as Accounts or Orders), which are likely to be more common to multiple business processes. Those, in turn, depend on more elementary (system-type) services, such as logging and persistence that in turn, depend on lowest-level infrastructure services (messaging, database access services, and so on). Core and elementary services are the most valuable assets; capabilities in these services are critical to executing fully conformed SOA strategy.

Figure 3: A multilayered, mediated services model.

Generally, the layering pattern has two forms: strict layering (sometimes referred to as pure or opaque) and loose layering. Strict layering enforces a hierarchy requiring that each layer can only use the layer directly below it. Loose layering is when a layer is allowed to use services of all the layers below it — not just the one just directly below. As depicted in Figure 3, a multilayered, service-oriented view is a form of loose layering because the possibility to interact with multiple layers results in greater flexibility of the architecture.

In addition to reducing dependency among components, multilayering also provides an effective foundation to institute caching of service requests and associate responses, and clustering at the infrastructure level. Both caching and clustering at different layers substantially enhances services' scalability, reliability, and availability.

Mediators in Service Hierarchies

To sum up: In the service hierarchy, each layer makes its external services available to the next higher layer that "treats" them as internal services. Also, internal services can exist within the same architectural level; for instance, an application component may use services offered by another application component at the same level.

However, is such a scheme sufficient to archive reusability and flexibility? Actually, in most cases, it isn't. By itself, multilevel layering doesn't guarantee reusability. In addition to layering, a proper design of all these service facades is necessary. More specifically, to achieve reusability, we need all-inclusive encapsulation of service interfaces. Using the "mediator" pattern helps tremendously.

Traditionally, the mediator pattern (also known as the information broker pattern) helps ensure the interoperation of systems that deal with heterogeneous data sources. Basically, the mediator is a layer that sits between the user application and data source layers; it performs the necessary transformation and data mapping between dissimilar data sources. In other words, the mediator hides the heterogeneity of those data sources from user applications.

From the standpoint of service orientation, in SOA, the mediator pattern covers a similar, but a much wider context. Because the primary goal here is all-inclusive service encapsulation (working with the object-oriented concept), mediators are service facades that delegate (or "mediate") services from one system to other systems. So, the mediator is designed to be "front end-able" to any service by using the delegation concept; that is, the mediator is a layer that receives service requests on behalf of another layer. In terms of implementation, the mediator receives XML messages on behalf of service requestors and sends XML messages to appropriate service providers. As it was also depicted in Figure 3, mediators are playing the role of "insulation" between layers in the enterprise service hierarchy model. This is where such elementary services as logging and caching are used. Also, it must be made clear that, architecturally, the concept of mediators is positioned above the messaging middleware (the pure message exchange layer) and the traditional integration brokers. Mediators deal with the underlying business processes: that is, the discrete service request-reply operations within the process.

In a nutshell, the mediator pattern is critical for reducing dependencies, and as a result, mediated services are more reusable by multiple business processes.

MultiLayering Challenges

Crossing organizational boundaries to produce multi-layered enterprise service architectures isn't easy. This is especially true without a "business process crossing map," which shows all the inter-relationships between business processes, business functions, and associated activities across the enterprise. But, more importantly, first of all, people have to believe that only architectures with the proper service structuring provide interoperability, reusability, and flexibility.

Several "inhibitors" exist related to multi-layering that IT organizations need to address for a holistic enterprise SOA solution. Any effort that's to succeed with SOA must address and overcome these issues:

Cultural. There are still people reluctant to institute a multilayered approach to services, usually stating at least one of the following two reasons:

Organizational. Achieving consensus on meaning and responsibilities for developing business, and then creating core and elementary (infrastructure) services are the most difficult challenges.

Costs. Many organizations lack budgets for a holistic SOA program to cover for activities outside individual projects, such as building core and elementary services to be shared by multiple projects.

Technical. The infrastructure to support multilayering at the service/component and middleware level often isn't in place. Standards for seamlessly sharing technical platforms for service orchestration and service compositions haven't been adopted widely across the industry. Finally, the number of legacy systems in place with their own infrastructure is a significant challenge.

What can we achieve with multilayered, mediated services architecture? First and foremost, using mediators and service nesting allows you to encapsulate the interaction complexity among services involved in the business process. It also guarantees high levels of reusability of services. Secondly, such architecture also provides for fast access to services responsible for customer interactions. Third, scalability is more achievable with multilayering.

Finally, SOA focuses on increasing best value within a business environment to reduce development time, integration resource requirements, and maintenance costs through reuse and coordination of services. The SOA advantage arises from its rigor. By adopting and following proven architectural patterns for service structuring, organizations gain pragmatic reusability as well as architectural agility to meet business objectives.

Mark M. Davydov is a vice president and senior technology delivery architect at Bank of America, where he's responsible for domain architecture definitions, software architecture life-cycle processes, and reuse. His book Corporate Portals and e-Business Integration (McGraw-Hill, 2001) introduced many ideas that influenced the progression of SOA and the Web services model.

Resources