Separation of service interface from service implementation

The pattern defined below attempts to increase an enterprise' chance of adopting SOA and insures the success of service orientation by reusing existing IT assets. These assets include leveraging existing legacy applications and well tested business logic or else could be the reuse of investments made in vendor package product installations.

________________________________________________________________________________

Separation of service interface from service implementation while leveraging existing IT assets

One of the key architecture tenants of SOA is the concept of separation of service interface from that of the service implementation. This concept although very simple is a very difficult one to put in practice. In this blog are discussed a few possible patterns that can be leveraged to loosely couple the service interface layer from the service implementation layer especially if these service interactions are within an industry vertical that are part of a business use case or interaction scenario common to that industry vertical. For instance, online auctioning and bidding interaction in the retail vertical. Loan approval based interactions in the financial services vertical.

In general, ESB vendors have tried to do this by proposing mediation flows that conform to the Service Broker and Service Gateway patterns. The Service Broker pattern leverages the ESB mediation flow to send requests to the appropriate service implementation(s) based on some type of mapping between the service interface and the service implementation. This information could either be wired into the ESB mediation flow or could be obtained from a service repository or metadata repository. On the other hand, the Service Gateway pattern leverages federated ESB mediation flows to send requests to the appropriate service implementation even when these implementations lie outside the firewalls or the enterprise boundaries. The Service Gateway pattern could be used for both extranet based service implementations and to communicate with external partners, agencies and SaaS style service providers. Both Service Broker and Service Gateway interactions may work well for an enterprise level service interaction or even for a specific extended enterprise level service interaction.

The following service pattern could fall into the category of industry vertical specific service interactions. The assumption is that both consumers and providers in a target industry are able to come to an agreement on common service interface definitions that apply to the interactions required by the industry vertical. However, the question would remain as to whether the service providers would be expected to re-architect their entire implementation layer, not to mention competitive advantage in having optimized product implementations.

An option would be to repurpose their service implementation layer by creating point to point adapters (such as the JCA style adapters). Our collective experience shows that the adapter soon becomes ridden with complex business logic such as business validation and transformation logic. An attempt is being made provide alternate options via the use of metadata and generic service patterns to deal with this predicament.

Use of industry specific schema based payload

This pattern proposes using industry-specific payload schemas that hold metadata such as a "service descriptor" and "properties descriptors" for service payloads. The “service descriptor” provides the definitions for a searchable metatag. Both the “service descriptor” and the “properties descriptors” are defined using industry-specific schemas and govern how this information is populated by service consumer.

The presence of the service descriptor metatag in the payload would allow the ESB mediation layer or a Service Router layer to generically route calls to the appropriate service implementation end-points. The service descriptor metatag can also be used to optimize Service Router specific "find" and "redirect to the service implementation layer" algorithms. Again, the “find” and “redirect” algorithms would be fine-tuned in keeping with the industry vertical specific interactions. Thus, any service implementation end-point that can map its' service semantics and service behavior to the value in the service descriptor can honor the service request even when its' own high level service facade does not conform to the "externally published" service interface.

Here the service implementation layer is expected to be able to satisfy a service request that takes the form of a business event or else would be in the form of an incoming message over a messaging pipeline. The key is that the service implementation layer call is not an RPC style API call (which would/ could require the use of a business adapter). The ESB mediator layer can at the most perform protocol translation but is not required to do more than a simple message format transformation (if needed) for interacting with a service implementation layer even though it does not map to the industry compliant service interface.

The pattern also prescribes the use of the industry-specific payload schema that has “property descriptors” that govern how the service consumer populates the payload. This schema not only provides placeholders for encapsulating service consumer business usage context but also defines the request parameter properties and the response payload properties. The property descriptors also have information on how to handle the payload semantically. The use of industry-specific payload schemas allows the transformation of the payloads to be optimized via the use of standard utilities or appliance plug-ins. These optimizations can be applied at the service mediation layer or at the service router layer. The model makes it possible to achieve processing efficiencies at the level of request and response payload creation and consumption.

In the event, the service implementation layer cannot deal with the industry-specific payload definitions then these optimized transformation algorithms could be leveraged to adapt the payload into a service implementation specific construct. This transformation can be undertaken either at the service router layer or ESB mediation layer or even at the service façade layer (i.e. at the entry-point into the service implementation layer).

Again, given that the interaction is going to be message-oriented and not an RPC based API call this pattern when leveraged would insure that the implementation of service provider does not have to be completely re-factored. This statement holds true as long as the service implementation layer honors the service behavior and is compliant with response semantics expected by the consumer.

Among the key benefits of this pattern is the fact that the industry vertical can agree to and publish service interaction semantics via the use of metadata that are embedded in the service payload. This enables all parties to interpret the service request and the service responses in an unambiguous manner.

________________________________________________________________________________
As always your feedback is invaluable.
surekha -