Service Mediation and Adaptation
written by gunther gerlach-2009
The assimilation of services through service ecosystems presents major integration development and maintenance costs. Service providers need to compose their services effectively in coordination with other services if they are to engage in oncoming market opportunities and situations. Further up the supply and distribution chain, if services are to be brokered and delivered through other intermediaries (e.g., for authentication, payment, device-specific service presentations), they will need to be interfaced with service delivery components that operate in various ways. Thus, one can expect that services will have to interact with one another in ways not necessarily foreseen during their development or deployment. A key challenge in this setting is service mediation: the act of repurposing existing services so that they can interact in unforeseen manners by intercepting, storing, transforming, and routing messages going into and out of these services.
A prominent sub-problem of service mediation is that of service interface adaptation, where the goal is to keep interfaces as generic as possible while adapting to functions peculiar to implementation or prone to change. As a basic example, consider a procurement service which, after sending a Purchase Order (PO) to a supplier’s order management service, expects to receive one and only one response. Now, consider the case where this procurement service is required to engage in a collaboration wherein the order management service may send a first response acknowledging the PO and accepting or rejecting a subset of its line items, possibly followed by one or more additional updates to accept or reject the remaining line items as their availability is determined. The mismatch between the “provided” (i.e., “as is”) and the “required” (i.e., “to be”) service interfaces is. More generally, a service may be required to participate in multiple collaborations such that in each of them, a different interface is expected from it. Implementing, testing, deploying, and maintaining adapters to deal with the multiplicity of interfaces required from a service may be costly and errorprone.
This calls for specialized tool support based on high-level concepts, as opposed to implementing adapters using programming languages extended with basic message manipulation primitives.
Service interfaces cover structural aspects, such as message types and supported transport protocols, but also behavioral aspects, such as ordering dependencies between messages as captured in, e.g., BPEL business protocols. The problem of service interface adaptation from the structural perspective has received considerable attention, leading to design-level mapping tools such as Microsoft BizTalk Schema Mapper or SAP Integration Builder’s Mapping Editor. In comparison, the problem of service interface adaptation from a behavioral perspective has received less attention. SAP’s ccBPM tool supports behavioral interface adaptation through multi-mappings and message bundling patterns, but
Published by. BPTrends November 2005
