Middleware

PublicReengineering Wiki

Context

A legacy system exists that is stable and successful. It is in constant use and there are no immediate plans to significantly alter or replace it. However, there are separate systems being developed which could usefully exploit the functionality of and data on the legacy.

Problem

How can new applications communicate and cooperate with the legacy and access its services?

Solution

Purchase a message oriented middleware product. Provide gateways on the legacy and other applications to allow the distributed systems to connect, interoperate and cooperate.

Consequences

The legacy has effectively been wrapped. You will have new applications separate from the legacy which can re-use the existing valuable functionality and data but will not add coupling and complexity to the legacy system (see Figure 1).

Figure 1 - Middleware Architecture

Middleware products can experience capacity problems so the volume of transactions must be anticipated. Instruct the vendors who are tendering that they should supply a basic, working prototype to your own specification and test on your systems to ensure the product can handle the volume of transactions that you have predicted. By having a prototype, you may add cost to the project but will gain a good basis for future development as well as a sound comparative metric for purchasing decisions.

Care should be taken with security and integrity so that the loose coupling between applications and legacy data does not allow data corruption or unnecessary duplication.

Known uses

A major UK financial services organisation has recently followed this strategy after an abortive start where no prototype was procured and capacity issues produced problems for the organisation.

This pattern is also being used in BT (British Telecommunications plc) as they attempt to migrate away from their monolithic customer service system by implementing existing and additional functionality and data in new systems, Harrison97. It is only one of a number of strategies being pursued, such as Divide & Modernise. The main difference here is that BT have developed their own middleware systems. In house development was necessary in 1984 when they began producing middleware due to there not being any commercially available alternatives Calladine97. However, the principle of prototyping has been followed since their middleware only had a limited application to begin with. The various forces for change in BT include: a need to provide better customer profiles and market information; and to reduce the amount of training required by operators of the system.

• Start Here in this Web
• Categories
• Index
• Recent Changes
• FAQ