Succeeding With SOA Through Patterns

To design reusable services, focus on industry-proven patterns and practices to provide the best solution based on service-oriented architecture and the Web services framework.
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:

  1. "It's all theories; it's not necessary to worry about that in practice." As a counterargument, I'd mention that several companies have implemented the multi-layered approach, including the mediator pattern: for example, GM, Union Bank of Switzerland, and Ericsson Telecom AB. Moreover, the European Commission Information Society Directorate-General Emerging Technologies and Infrastructures group has identified the mediated services concept as the cornerstone architecture of its Next Generation Collaborative Working Environments 2005-2010 project.
  2. "All this multilayering will kill performance." Performance concerns are often overstated, since multilayering and mediators offer considerable advantages that more than compensate for any loss in performance.

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.

GM's MultiLayered, SOA-based Application Architecture

At GM, the concept of SOA is one of the cornerstones of its IT reengineering strategy for supporting new and extremely challenging business demands, including the move to new fuel sources in automobiles (hybrid, cell power, and so on), online and on-demand access to mechanical connections of control systems, and vehicle connectivity to the Internet. Enabling full life-cycle support for such business requirements requires a highly agile and flexible IT architecture with "on-demand" real-time integration capabilities. GM's IT organization developed its SOA model specifically focusing on achieving those capabilities.

SOA at GM has a two-dimensional view: one dimension is represented by a document-centric message exchange model based on the ebXML B2B standard and Web services technologies; the other dimension includes J2EE and .Net components, commercial-of-the-shelf (COTS) packages, and legacy mainframe applications — all exposed as business services. GM's deployment structure is highly multitiered. Different types of mediators and service facades are present: ebXML Mediators for business collaboration with external partners and suppliers, sharable services mediators for newly developed or migrated services, COTS mediators for "wrapping" and intelligently encapsulating COTS interfaces, and several data integration mediators that provide access to legacy databases as well as data warehouses.

There are many indicators pointing out GM's success with SOA. For example, the company has substantially increased supply chain integration; even small-to-medium partners have been integrated now into the GM network, something that was cost-prohibitive before. Also, GM's interenterprise integration with multiple Daewoo and GM-Shanghai systems, which are managing assembly lines, is ahead of schedule and below budget. — Mark Davydov


  • Fowler, M., D. Rice, M. Foemmel, E. Hieatt, R . Mee, and R. Stafford, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.
  • McGovern, J., S.W. Ambler, M.E. Stevens, J. Linn, E.K. Jo, and V. Sharan, The Practical Guide to Enterprise Architecture, Prentice Hall PTR, 2003.
  • Eriksson, H.E. and M. Penker, Business Modeling With UML: Business Patterns at Work, Wiley Publishing, 2000.
  • Hocker, R., and K. Pollari, "Leveraging Reusable Assets to Reduce Total Cost of Ownership," Presentation at the 8th Annual BEA Technology Conference, 2003.
  • Davydov, M. M. "Exposing EJB Components as Business Services: An Architect's View," Oracle Technology Network, 2004.
Editor's Choice
Samuel Greengard, Contributing Reporter
Cynthia Harvey, Freelance Journalist, InformationWeek
Carrie Pallardy, Contributing Reporter
John Edwards, Technology Journalist & Author
Astrid Gobardhan, Data Privacy Officer, VFS Global
Sara Peters, Editor-in-Chief, InformationWeek / Network Computing