Concept: Service Mediation
This concept describes ways in which communication between incompatible consumers and services is enabled through mediation, transforming consumer requests or protocols into forms that service providers can understand.
Relationships
Main Description

Introduction

Mediation is the act of intervention between conflicting parties to promote reconciliation or compromise. In particular, three common forms of reconciliation are required in distributed systems in general and service-oriented solutions in particular.

  • Interface mediation; in object- or component-based systems interface, mediation is the change between operation definitions between sender and receiver. In a service-oriented solution, this is seen as a mismatch in message content/schema between sender and receiver.
  • Protocol mediation; most common object- or component-based solutions tend to be based around a common protocol or set of protocols for communication. In service-oriented solutions, a mix of protocols across the entire solution is common and it is one of the advantages of the architecture. To communicate between services, messages will have to span different protocols between sender and receiver.
  • Operation mediation; this form of mediation might also look familiar to developers. It is related to the common strategy pattern. A component is able to select between one of a set of implementations of a particular service or operation based on runtime parameters or content of the request. This is also known as content-based routing.

An increasing number of middleware platforms enable developers to implement advanced mediation without having to develop explicit mediation components. In this case, as the middleware detects mismatches in data structure or communications protocols, it can perform the mediation in its runtime. It is also possible for these platforms to provide mediators that act as switches based on message content and business rules to select the correct implementation of a given consumer request.

Data Mediation in Activities

In terms of connecting services where the definitions of messages do not match or the messages require transformation between sender and receiver, it is possible to use a capability provided by UML 2.0 Activities to denote the transformation between the sender and receiver. This capability, the association of a UML 2.0 Behavior to an ObjectFlow between two Actions, allows for the identification of a reusable transformation behavior that can turn one message into another (specifically from the UML 2.0 specification Changes or replaces data tokens flowing along edge).

The transformation is a reusable element. It can be identified to transform one message type to another and then be used wherever needed in mediating messages between a sending and receiving service. Although the UML does provide a set of actions for navigating, reading, and updating a structure, these are relatively complex and might prove too hard to use in defining transforms. It is expected that the transform either will link to a more compact representation (consider the XSL/T language) or a new way of expressing UML actions needs to be provided.

Data mediation also can be treated as a concrete pattern of service iteration. For example, there is an explicit mediation service responsible for the implementation of one or more data transformations. In this case, the mediator has to respond to messages sent by the consumer, transform the message, and pass it on to the service, as shown below.

Figure 1.  Data mediation using an explicit mediation service

Diagram is described in the textual content.

Protocol Mediation on Service Gateways

Mediation of protocol is well understood and supported explicitly in the service model. As the protocol information is specified as the binding for a service channel, it is possible to introduce additional <<ServicePoint>> model elements that alter the protocol specification. For example, in the following composite structure diagram you see two partitions, one for Web-facing services and one for internal services, and there is a service channel between the partitions with a binding of "HTTP-SOAP", something that is common for Web-facing services.

Figure 2.  Mediation of protocol between service partitions

Diagram is described in the textual content.

The issue is that, to support the required level of performance and other non-functional requirements, all communication within the internal partition takes place over platform-specific protocols. The following diagram shows how a service is connected to the ServicePoint (or service gateway) "Port : ISvcTwo" using the Java RMI protocol, but how is it then that the Web partition connects to the same service gateway using HTTP-SOAP?

Figure 3.  Details of the internal partition, using high-performance transport protocol

 Diagram is described in the textual content.

The answer is that the service gateway itself can mediate the protocol by converting message structures and invocations from one format to another. This is common functionality usually provided by middleware such as Object Request Brokers (ORBs), Message Brokers, or Enterprise Service Buses. In fact, it would be possible to generate from the model above to such middleware if required, or to reify "Port : ISvcTwo" as a service in its own right which takes calls from the Web partition and resends them to the enclosed services.

Again, it is possible for the mediation to be modeled explicitly as a service that exposes the correct interface with the consumer-side binding and delegates implementation to the provider service with a different binding.

Invocation Mediation using Service Composition

It is common to define a structure where one service depends on another service for some operation. However, the actual service which will be called for any particular request is dependent on details embedded in the request, who the requester is, and business rules applied using this information. The commonly given example for this is a customer request, where the receiving service might choose one of two implementations based on the level of the customer. For example, customers who are known to spend more money might get preferential treatment.

Figure 4.  Mediation using rules-driven service composition

Diagram is described in the textual content.

As we described earlier, it is important in this kind of mediation to try to externalize the rules used to choose between one or more providers of the actual operation implementation. In the diagram above, we show this as a rule component attached to the mediating service. Obviously it is possible to build the solution as a set of services where the mediator, rules, and all implementers are separate services. This can be seen below. 

Figure 5.  Implementation of mediation solution using separate mediator, rules, and implementer service providers

Here we have a CustomerMediation "wrapper" Participant which assembles the service provider, rules, and requesting Participants (see Example: Participant (SoaML) for an example of this usage).  The collaboration between the three assembled Participants is shown below. 

Figure 6.  Collaboration between services in the service composition mediation solution

Again, it is possible that this kind of content-based or rule-based routing of messages can be accomplished by the middleware platform chosen as part of the solution architecture.

More Information