Introduction

The ESB is a core architectural pattern in a Service-Oriented Architecture (SOA). The role of the ESB is to provide connectivity between potentially heterogeneous service requesters (consumers) and service providers.

Due to the legacy environment that most organizations have to deal with, applications often use proprietary models and metamodels (syntax) to describe information (semantics) in the messages they send or receive. Even if all participants use the same metamodel, for example, XML Schema Definition Language (XSD), they can still use a different message model, such as a different schema. Challenges arise when there are multiple proprietary message models and metamodels from different applications describing the same information, such as customer. Even if they have the exact same metamodel, such as XSD, you might still need to exert great effort to align and map these models.

To give a specific example, one application might provide the name of a person in a single attribute, while another application might structure it in two attributes: one attribute for first name and another for the last name. Potentially different semantics in messages further complicate the problem: A marketing campaign application may define a customer differently (for example, including potential customers) than a call center application (where a customer is a person that has purchased a product).

SOA is about aligning business and IT needs and maximizing service reuse. By identifying and specifying its business services, an enterprise now has the flexibility to choose best-of-breed applications to provision those services. However, these applications usually have their own message model that's often at odds with the message model of the service consumers. Thus as an enterprise matures in terms of its SOA adoption, this heterogeneous environment needs to be managed. The role of the ESB is to establish loosely coupled connectivity between services; part of that role includes transformation between the different message models and metamodels. However, as the number of interacting applications with proprietary message models increases, the challenges of managing the necessary transformations to enable service interaction increase exponentially. This is one of the key drivers for the CMM.

Note: The term message metamodel is used for consistency with the previous articles in this series; however the information management references use the term message format instead (see the sidebar).

Back to top

The CMM pattern

The key challenge introduced above, which this paper focuses on, is how to reduce the complexity of connectivity in an ESB in which service providers and consumers exchange syntactically incompatible messages. The context in which we examine this problem further is an SOA where service requesters invoke services from providers that use different message models (and perhaps different metamodels), as illustrated in Figure 1.

Figure 1 illustrates the problem of performing direct transformation between service requesters and providers. In this example, n service requesters interact with the m service providers. Each service (requester/provider) uses its proprietary message model for communication. Note that the message model is generally a reflection of the application's internal data model. For the requesters to invoke the providers, the message models from the requesters need to be transformed into the message models of the providers.

As demonstrated in Figure 1, the ESB must understand all the proprietary message models, and the ESB maps, or transforms, between the message models. In this scenario, the ESB must provide transformations for each possible interaction. For each requester (n in this scenario), a separate transformation has to be specified to each provider (m in this scenario). That means m transformations for the first requester, m transformations for the second, and so on. Because there are requesters, the total number of transformations is n * m . If one new provider is added and all requesters need to interact with it, n new transformations need to be added. If one new requester is added and needs to interact with all m providers, then m transformations need to be added. As a consequence, extending the scope of such an architected integration solution is very costly.

The recommended solution to this problem is to use a CMM. To better understand the idea behind a CMM, consider the following analogy of the United Nations (UN). For the UN to function in a multilingual world, it needs to employ interpreters to interpret from one language to another. Take the example of an interpreter working for the French ambassador. This interpreter needs to be able to interpret from Chinese to French, from English to French, or from whatever the native language of the person the ambassador is talking with. Now let's pretend that the UN has decreed that from now on the common international language will be Irish. In that case, the interpreter only needs to know how to convert from Irish to French and back again. In this simple analogy, Irish is the CMM.

Back to our enterprise, Figure 2 illustrates the CMM approach, where each requester (n of them) needs a transformation to the CMM, and each provider (m of them) needs a transformation to the CMM (assuming that they all have different models). Therefore, the total number of transformations is n + m. If a new service, as a service requester or provider, is being introduced and this service uses a proprietary message model, only transformation between the CMM and the application-specific message model needs to be created, regardless of the number of applications that already participate (see the article "The information perspective of SOA design, Part 4: The value of applying the canonical modeling pattern in SOA" [developerWorks, Mar 2008] for more information). This reduction in the number of transformations illustrates the core benefit of using the CMM pattern and helps to reduce the number of required transformation in this heterogeneous environment from n * m to n + m (for n requesters invoking services from m providers).

A CMM standardizes the message models between service requesters and providers, mandating message consistency and improving message maintainability. From a technical perspective, a CMM comprises:

• A defined set of semantics representing the business entities and their business attributes used in all messages.
• A defined set of messages with a specific syntax representing the business entities, each including a related set of the defined types, elements, and attributes structured to provide a business document with a specific semantic meaning and context (see Part 1 of this series for more information). It's important to understand that this doesn't mean that every requester or provider adopts the exact same message set, but that the messages are consistent and all based on the same types.

The aim of this article is to convince you that a CMM can add significant value to an SOA, in particular the more heterogeneous requesters and providers you have. But there are some remaining questions: How—and where—are the transformations between the CMM and the proprietary message models implemented. Figure 2 indicates that the ESB translates (labeled as map). Although this is an obvious approach, it's not the only one. The remainder of this article examines various approaches for implementing a CMM in an ESB and explains the advantages and disadvantages of each approach.

Back to top

Approach 1: The intermediary (ESB) translates

In this approach, shown in Figure 2, the service providers and requesters retain their own proprietary message models. This is a typical scenario when integrating legacy applications or in a business-to-business (B2B) integration. In this case, the ESB needs to:

1. Translate from the proprietary message model of the requester to the CMM.
2. Translate from the CMM to the proprietary message model of the provider.

As you can see in Figure 2, there's a transformation between each requester and the CMM (assuming that the models are different) and between the CMM and each provider (assuming that those models are also different).

Essential characteristics

The essential characteristics of this approach are:

• The individual services or applications retain their proprietary message models.
• The ESB adopts a proprietary external message model for each service requester and provider.
• The ESB adopts an internal CMM (that is, the CMM is used inside of the ESB):
  • For each requester, there must be a transformation from the requester proprietary message model to the CMM (a second transformation is also mandated on the return to transform the CMM back to the requester proprietary message model).
  • For each provider, there's a transformation from the CMM to the provider proprietary model (a second transformation is also mandated on the return to transform provider proprietary model back to the CMM).

Advantages

Advantages of this approach are:

• Existing services don't have to change, making it easier to reach agreement among different groups who have conflicting interests on services. Sometimes this is the only way for legacy and packaged applications that are connected to the ESB. B2B integration also typically follows this approach
• This approach is fairly typical in an SOA and ESB environment. A certain number of mediations have to be created. Expanding them by some model transformations doesn't require additional tools or skills.
• This approach limits the number of transformations that must be developed and managed to n + m (see above).
• The ESB provides an enforcement point for centralized management and governance of all the transformations.
• It's easier to introduce reusable mediation logic, because that logic can use the CMM instead of service-specific message models.

Disadvantages

Disadvantages of this approach are:

• This results in a double transformation between interacting applications or services, thus increasing the processing overhead. For complex message models (like those of ACORD), or for ESB products with transformation performance constraints, this processing overhead can be significant. In particular, processing is concentrated in the ESB, which can quickly become a choke point.
• The use of a CMM can often suggest a "free lunch" for applications, allowing them to maintain their proprietary message models and, thus, needlessly exacerbate the processing overhead problem inherent in double transformations.

Back to top

Approach 2: The services translate

In this approach, the service requesters and providers, or some agent acting in their environment on their behalf, have to translate their original proprietary models into the CMM. Explicitly, in this case you leave the original message model as is and transform to or from the CMM external to the original service or application. The ESB is not responsible for the transformation of message models.

1. The service requester's infrastructure translates its proprietary message model into the CMM.
2. The ESB is responsible only for routing and possibly protocol conversion.
3. The provider's infrastructure translates its proprietary model into the CMM.

Essential characteristics

Figure 3 illustrates this approach, which has the following characteristics:

• The ESB adopts the CMM internally and externally and simply connects requesters and providers.
• Requesters transform from the proprietary model to the CMM (and vice versa for the response). This transformation runs in the requester's environment. Providers retain their proprietary message models internally but translate them into the CMM when a service invocation is received (and when the response is provided). This transformation runs in the provider's environment.

Advantages

Advantages of this approach are:

• This delegates the task of transformation from the ESB to the services, in that they must develop, deploy, and manage the transformation. This eliminates the management and operational load on the ESB.
• Organizations or environments where there's sufficient development staff for an application but only very limited support at the ESB can benefit. This is true for some B2B networks without a central hub or decentralized organizations.
• In cases where the model of the requesters and providers already match, no additional transformations—essentially overhead—need to take place.

Disadvantages

Disadvantages of this approach are that transformations must be implemented within the service's infrastructure. This is sometimes cost-prohibitive, for example, when a legacy application needs to be changed and no documentation is available. Sometimes it's even impossible to change an application, such as in a Software as a Service (SaaS) scenario where the service provider is not willing to make the necessary change.

Back to top

Approach 3: Ideal scenario

In this approach, the messages used by the service requesters and the service providers have all been defined using the CMM. Because all applications use the CMM, no transformations are required—not in the applications and not in the ESB.

Essential characteristics

Figure 4 illustrates the characteristics of this approach:

• The individual services requesters and providers use the CMM externally. This is different from previous approaches in which providers and requesters each use their unique message model.
• As with approach 2, the responsibility of the ESB is not to translate but to route the service invocations.

Advantages

Advantages of this approach are:

• This is ideal for new applications, because they can adopt the CMM as their internal data model and, therefore, reduce the effort of developing transformations that might have to take place to map between an internal data model and external message model.
• It allows the ESB to focus on the aspect-oriented connectivity (such as security and auditing) and other forms of connectivity, like service versioning.
• This distributes the responsibility such that the requesters and providers must ensure CMM conformation; this reduces the management and operational load on the ESB.
• This approach eliminates transformation costs, thus reducing complexity and increasing performance.

Disadvantages

Disadvantages of this approach are:

• This approach is unrealistic, or at least very expensive, when connecting existing legacy applications. They are heterogeneous in nature; they can't be simply plugged in because they don't use the CMM as their internal or external model. Changing their internal model to become the CMM is in many cases very expensive, which significantly impacts the overall ROI in a negative way.
• The more existing applications need to be connected, the more unrealistic, or expensive, this approach becomes for the same reasons as mentioned in the previous point.
• It's harder to reach consensus in existing service provider's and requester's environments for various reasons, such as project funding.

Back to top

Approach 4: Hybrid (and most likely) CMM scenario

It's most likely that different service interactions have different requirements and constraints. That means that none of the CMM approaches mentioned above are ideal for all service interactions in the solution. One approach might be best for one interaction, while another approach is better for another. In fact, in some cases it's best to use none of the approaches, that is, no CMM. Therefore, it's possible and likely to combine the previous scenarios in a hybrid approach, as shown in Figure 5.

We've described the characteristics of various approaches above. This hybrid approach combines the characteristics and applies each where it's most effective. So this approach can combine the advantages of the previous approaches.

The main disadvantage in this approach is the potential complexity that results: For every new service, a decision has to be made on how it's connected, which can lead to longer development cycles and increased complexity for governance and management.

Back to top

Conclusion

In this article, you learned that a CMM pattern reduces the complexity of connectivity in which service providers and consumers exchange heterogeneous messages. You examined four different topologies and solution approaches—including determining whether they are necessary at all—that differ in how the transformations between the CMM and proprietary models are implemented.

Resources

Learn

• Read the other articles in this series:
  • "Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution" (developerWorks, Apr 2007)
  • "Exploring the Enterprise Service Bus, Part 2: Why the ESB is a fundamental part of SOA" (developerWorks, Sep 2007)
  
  
• Read "The information perspective of SOA design, Part 4: The value of applying the canonical modeling pattern in SOA" (developerWorks, Mar 2008).
  
  
• Read the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions By Gregor Hohpe and Bobby Woolf.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
  
• Get the basics on architecture disciplines from enterprise and application to infrastructure and operations in Exploring IT architecture disciplines.
  
  
• Start with Enterprise architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the enterprise level.
  
  
• Start with Application architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the application level.
  
  
• Start with Information architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the information level.
  
  
• Discover the advantages of using modeling tools from IBM Rational in Implement model-driven development to increase the business value of your IT system (developerWorks, Jan 2006).
  
  

Get products and technologies

• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out Eoin Lane's blog Engineering SOA.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
  
  

About the authors

Mei Selvage is a SOA data architect with extensive hands-on experience in various information management areas and Service-Oriented Architecture (SOA). Her mission is to bridge the gap between SOA and information management. Her research interests include information management and integration patterns (both structured and unstructured data), data modeling, metadata, faceted search, human collaboration and SOA.

Greg Flurry is a senior technical staff member in the IBM Enterprise Integration Solutions group. His responsibilities include working with customers on service-oriented solutions and advancing the IBM service-oriented products.

Dr. Guenter Sauter is an architect in the Information Platform and Solutions segment within IBM Software Group. He is driving architectural patterns and usage scenarios across IBM's master data management and information platform technologies. Until recently, he was the head of an architect team developing the architecture approach, patterns, and best practices for Information as a Service. He is the technical co-lead for IBM's SOA Scenario on Information as a Service.

Dr. Eoin Lane, senior solution engineer, is the lead for harvesting and developing an application pattern from key IBM SOA engagements and driving those patterns through IBM pattern governance process to accelerate adoption. Eoin also specializes in Model-Driven Development (MDD), asset-based development, and Reusable Asset Specification (RAS) to facilitate SOA development.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• The CMM pattern
• Approach 1: The intermediary (ESB) translates
• Approach 2: The services translate
• Approach 3: Ideal scenario
• Approach 4: Hybrid (and most likely) CMM scenario
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers