Jerry Waldorf's Blog

Adapters, Gateways, Agents, and Native

In the pursuit of SOA in existing enterprises, developers will undoubtedly come across legacy application services that they would like to include. These services are hidden from the other applications behind legacy proprietary protocols. The legacy protocols make it difficult to include the "services" in the new business processes and composite services that the nimble SOA environment enables because they require proprietary client libraries and other heavy encumbrances.

We need some way to bring these legacy application services into the SOA environment. There are a number of ways to get this to happen:

Adapters -- allow the Integration Platform/BPMS to connect to these legacy applications by plugging in directly to the platform an adapter that can speak the proprietary protocol to the legacy application

Gateways -- create a separate Gateway that speaks standard Web Services over HTTP on one side and the proprietary protocol on the other, basically a proxy for the legacy service.

Agent -- a plug in that runs in the legacy application, providing a local translation of the legacy service to a modern protocol of Web Services over HTTP.

Native -- upgrade the legacy application to the latest version that has a native way to expose the legacy application's services as Web Services over HTTP.

A graphic of the above:

So which is the best approach. They each have their pros and cons.

Adapters -- Adapters plug directly into the Integration Platform/BPMS which makes them easier to deploy and manage. But they lock the Business Processes to a new proprietary platform. If a new BPMS system is desired to replace an existing one, all of the connectivity is locked into the existing BPMS making it hard to replace. We have just moved the problem around without solving it.

Gateways -- This approach has the downside of introducing another moving part. An additional process to keep track of. The benefit is that it allows the BPMS to be decoupled from the connectivity. Thus when the application eventually supports native Web Services over HTTP the Gateway can just be dropped without changing the Business Processes. Also if a new BPMS platform is desired to replace the existing one it can easily be done. Another benefit is that the Gateway exposes this legacy application service to not only this BPMS platform but any other consumer that can be created in the enterprise. Another benefit is that the traffic between the BPMS and the Gateway can be monitored and managed from the large collection of HTTP intermediaries out there.

Agent -- a plug in has many of the benefits of a Gateway, but has the down side of being hard to maintain because they often need to use non public APIS. The Gateway uses proprietary protocols, but supported ones. An agent often needs to use local non public APIs that may change from release to release. Also they have the downside of needing to be installed into the legacy application, potentially breaking existing functionality in the legacy application and requiring special administrator supervision that a Gateway does not require.

Native -- for obvious reasons native support of Web Services over HTTP is the best option, but often times upgrading to newer versions of the legacy application is not possible right away, although recommended in the long term.

So what is the best approach. If possible move to Native support. When this cannot be done, go with a Gateway. It provides the best practical migration strategy to get to SOA without locking you into a another proprietary BPMS solution.

Posted at 10:43PM Jun 02, 2008 by Jerry Waldorf in Sun  |  Comments[2]