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.
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
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
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
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.
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
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.
|