Service Mediation - An important factor in SOA
In general mediation is a practice used in law to settle conflicts between two parties by a third party called the mediator.
In SOA where service contracts are created between a plethora of producers and consumers, there arises a need for mediation to provide sanity to the objective of of the overall concept of Enterprise Service Bus.
What could be the principles and prospective candidates for Mediation? Let’s look at them…
One of the google searches on service mediation leads to this link in soamag. This page has a good prescription on use cases for service mediation in general. Taking forward from here, any SOA implementation should look at the following principles and cases:
1) Service virtualization is the primary driver for implementing an ESB, and most other use cases are variations of it. Mediation thus is one such case to ensure virtualization.
2) SOA works best when there are clear logical layers separating the different types of services. One rule most of the implementations miss is ensuring only top level business services are exposed on your Enterprise Service Bus (ESB). This means that if a service registry’s taxonomy is in place then in that hierarchy these services would be in top and they should be course-grained business objects. For e.g. for a banker approving a loan the business process “credit approval” is the coarse grained process should be available on ESB. What credit approval does to get the required data such as customer details, account details, etc are fine grained or a mix of coarse grained and fine grained that need not be exposed on ESB. Out of the box mediation in ESB will ensure the interaction between the top level service and other services are configuration based and not required to be coded in either of the services.
3) The previous rule doesn’t translate as “ESB should be one” and all other services should not be hosted on a bus. The layered SOA structure should have the ESB that is truly enterprise wide cutting across business units and thus having only the critical and common (reusable) cross grained business services. Down this layer there could be other service buses performing their own hosting of services and thus even requiring mediation in each of these service buses. As previously posted there is no one size fit all SOA architecture. Each organization, enterprise would need to find out what best suits them and grow upon it.
4) Having this rule in place, any BPM implementation or writing a BPEL becomes easier and directly translates to solving a business problem or redefining a business process. The objective is to cut the deficit between business and IT.
5) Obviously the ESB would now require “mediation” to translate the exposed business services to depend on the underlying technical services which could be composite service of multiple EJBs, a service that is in based on REST or wrapped service on legacy program and so on.
6) The non functional aspect about these service assemblies performing these tasks of mediation would need to be logically categorized in an IT specific way to ensure maintenance is easy; availability of critical components are in a separate infrastructure, performance and single point of failure are avoided etc. are taken into account.
The above points and the referenced pages are just an indicative list to bounce off ideas for an Enterprise Architecture Evangelist or Business sponsor looking for an Service Mediation in a new or existing implementation. There are detailed mechanisms to come to the right fit and pattern including positioning of BPM, EAI and SOA product vendors.
