Best practices: Changing an external service without interruption

When you are designing a system or developing modules, you sometimes gain advantages by placing an intermediary module between a module and an external service that it is invoking. You can only use the approach described here if you are using SCA bindings.

One advantage of using an intermediary module is that you can then change the external service or application that your application is invoking without interruption. This example uses a Web service import to illustrate the concept.

The first figure below shows module A with an import that invokes a remote service through a direct connection. If you wanted module A to invoke a different remote service, you would need to update the logic. You would then need to stop the old version of the module and uninstall it from the server. The new version of the module could then be installed and started. During this process, there is an interruption of service for module A.


The figure shows a module connected directly to a Web service.

If you use an intermediary module in your application and connect it to module A with an SCA binding, you have more flexibility. The figure below shows that configuration. Module A has an import that is wired to the export of an intermediary module or mediation module, module B. The modules must have matching interfaces. In the scenario described in this topic, they must have an SCA binding. Module B invokes the service. Module B is a facade; module A contains the real business logic.

The diagram also shows another service, remote Web service 2. In preparation for using that service, module C and its Web service import have been built and tested using the WebSphere® Test Environment.


The second figure shows module A connected to a service through an intermediary module, module B.

When that new module is ready to be deployed, you can use the WebSphere Process Server administrative console to point the SCA import in module A from the old target module (module B) to the SCA export in the new one (module C), creating a seamless transition to the updated service. The figure below shows the new deployment. This method allows you to update an application without causing any interruption in service.


The third figure shows the new module now connected to a new service through a new intermediary module.

The above pattern could also be used for external exports. For example, a module can expose a service through a Web service export. Typically, if the logic of the module needs to be updated, there would be an interruption in service. However, if a facade module is used for the Web service export, the business logic can be updated without a break in service.

This design principle is more fully explained in documentation for WebSphere Process Server; see the instructions for isolating modules and targets and for changing targets.

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.