Mediate Service Requests & Responses

Service Mediation is an abstraction layer in between the service consumer and the service provider. What is the need for mediation and what benefits does it provide? There are several benefits:

1. Apply cross cutting concerns such as authentication, encryption, logging, metrics across all service requests. The mediation layer can have hooks in place to perform these concerns so individual service capabilities don’t have to invoke them each time.

2. Provides the service provider the flexibility to change implementations or service fulfillment strategy. For example, you can migrate a service capability from one programming language to another or get off a legacy system. You can also switch technologies fundamentally – instead of looking up data from a database to fulfill a service request you can read from an in-memory cache or introduce an indexed search engine.

3. Mediation can also be used to translate physical transports to fulfill a service request. For example, you might have a capability that is available over HTTP and the consumer might need the capability to be accessed via a Java Messaging Service (JMS) queue. The mediation layer can intercept the request via a JMS input queue and turn around and invoke the underlying HTTP service.

4. Services may not always expose the right input/output contracts. There might be legacy syntax/semantics exposed, or inconsistent error codes or too many parameters being exposed etc. More importantly service contracts need to align with your firm’s logical data models. This provides consistent business names, data structures, and decoupling from physical data.

Metrics are very useful to understand service usage, volume trends (growth/decline) – leading to improving performance/capacity planning, diversity of user base, etc.

A service mediation layer can initialize and persist metrics and can help efforts to mine that data to generate reports using the data. What specific metrics can be captured? Here are a few attributes:

incoming time, outgoing time (or publication time) , transport (whether service was invoked via HTTP, JMS, or some other transport), requesting host name/queue name etc. Additionally, if a request processing resulted in an error – error details including stack trace can be captured. Finally, service/operation-specific metrics can be captured – if you don’t have demanding reporting requirements, these attributes can be stored as a set of name/value pairs.