Thursday, November 17, 2005
Web Services Mediation in SOAs
Solving the mediation challenge: The Heart of an ESB Ronan Bradley Weblog - WebServices.Org: "Mediation refers to the set of tasks that must be performed on each message or document so that multiple services (in the broadest sense of the word) can be combined to automate business processes spanning multiple applications, departments and even organizations.
Although some may regard mediation as simply the most recent addition to the SOA and Enterprise Service Bus jargon, its emergence is in fact hugely significant: it is now apparent that mediation is the fundamental issue that any viable ESB product or solution must address.
What exactly IS mediation? To make the concept more concrete, examples of mediation steps associated with a simple foreign exchange contract in financial services might be:
* Validating the message against that company standard
* Mapping of the customer name into the correct customer id format (by looking up a database) required by the FX order system
* Transforming the incoming message order format into the format expected by an FX order system – probably filtering out data not required by this system but required by audit or risk systems.
* Ensuring the sender of the order is allowed to order that value of transaction.
* Extracting the value and originator of the order and updating the financial risk engine.
* Enforcing management controls and service level agreements that might restrict particular quantities and currency being ordered."
"Why do we need mediation?
Mediation is required because differences in data models, service definitions and the granularity of software services, makes communication between applications much more complex than might be imagined at first glance. The oft-proposed ‘solution’ to these issues - the act of creating a ‘standards-based’ service - only goes part of the way towards delivering truly flexible, loosely-coupled integration architectures (which in turn deliver business agility – let’s keep this front-of-mind, it is the whole point after all).
This may seem to be heresy to some proponents of SOA, who believe that the perfect service definition should never need mediation, or alternatively that the solution to any mismatch is to create a new service definition. Based on that belief, some propose that service orchestration (usually based on the BPEL standard) alongside the ‘correct’ service definition on their own will solve any integration requirement.
To be blunt: this is optimistic and naïve nonsense. ...."
Although some may regard mediation as simply the most recent addition to the SOA and Enterprise Service Bus jargon, its emergence is in fact hugely significant: it is now apparent that mediation is the fundamental issue that any viable ESB product or solution must address.
What exactly IS mediation? To make the concept more concrete, examples of mediation steps associated with a simple foreign exchange contract in financial services might be:
* Validating the message against that company standard
* Mapping of the customer name into the correct customer id format (by looking up a database) required by the FX order system
* Transforming the incoming message order format into the format expected by an FX order system – probably filtering out data not required by this system but required by audit or risk systems.
* Ensuring the sender of the order is allowed to order that value of transaction.
* Extracting the value and originator of the order and updating the financial risk engine.
* Enforcing management controls and service level agreements that might restrict particular quantities and currency being ordered."
"Why do we need mediation?
Mediation is required because differences in data models, service definitions and the granularity of software services, makes communication between applications much more complex than might be imagined at first glance. The oft-proposed ‘solution’ to these issues - the act of creating a ‘standards-based’ service - only goes part of the way towards delivering truly flexible, loosely-coupled integration architectures (which in turn deliver business agility – let’s keep this front-of-mind, it is the whole point after all).
This may seem to be heresy to some proponents of SOA, who believe that the perfect service definition should never need mediation, or alternatively that the solution to any mismatch is to create a new service definition. Based on that belief, some propose that service orchestration (usually based on the BPEL standard) alongside the ‘correct’ service definition on their own will solve any integration requirement.
To be blunt: this is optimistic and naïve nonsense. ...."
0 Comments:
