Succeeding With SOA Through PatternsSucceeding With SOA Through Patterns

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