WrappedService

PublicReengineering Wiki

Context There are a number of legacy applications which each rely on their own implementations of the same functionality. For example, various military systems need to display maps. These implementations may be written in different languages, have varying levels of sophistication and their hosts may be geographically dispersed. Each instance of this functionality requires maintenance. There may even be commercially available products that can supply the functionality.

Having one instance of the service would reduce maintenance costs, but the change would have associated risks and costs. By moving to this single instance, there is an opportunity to provide standard system interfaces and so take advantage of standard commercial applications. However, standardisation may loose some of the useful idiosyncrasies of particular implementations of the service.

Problem How can duplicated functionality be made into a common service?
Solution Wrap the functionality to provide a common interface to a common service for all the applications to use. First, consider the costs and benefits of providing some functionality as a common service - taking account of current and future maintenance costs, as well as the costs of the migration. Prioritise the applications which will be affected, by the benefits that can be achieved. Choose configuration tools to help manage version control. Extract and reengineer the functionality from one of the applications and provide it with an interface in the form of an object wrapper. Reengineer each application in turn to use the common service by invoking a distributed ORB, such as those complient with the CORBA standard. Remove the now redundant functionality from the application. Now test and deploy, before moving onto the next application in the list of priorities.
Consequences By considering the costs and benefits of providing a common service, the project is properly justified. As such, the project has a greater chance of being successful and being supported through to completion. The risks to the project are further reduced by working on one application at a time. If the project ceases you are left with stable working systems and will have tackled the most important areas first.

Eventually only one instance of the service is left which will reduce maintenance costs and reliance on the legacies. However, if this service goes down - for whatever reason - all of the applications will be adversely affected.

Since the applications rely on a standard ORB interface, the opportunity exists to replace the service with a commercial product which can provide the same interface. Bear in mind, however, that the standard may become less popular in the future and be replaced by a new generation of interfaces.

Inevitably, the wrapped code will need to be changed to interface with the wrapper. Indeed, the code may not be readily decomposable from the legacy. Whatever the case, such adjustments provide an opportunity to make the code easier to maintain ( FantaRajlich98 claim that even small restructuring steps can have a positive effect on the code's comprehensibility and maintainability). However, to retain the idiosyncrasies present in the original applications may prove too costly and some compromises may have to be reached.

To make the legacy applications easier to understand and maintain, the now redundant functionality should be removed, but time and cost constraints may not allow this.

There are multiple applications being worked on; perhaps at different times, in different places and by different people. The proliferation and tracking of the effects of even a simple change can become complex. Configuration management tools help manage the different and changing versions of the various applications involved in the project.

It is time consuming to test distributed systems, however testing will contribute to the success of the project.

Related Patterns Distribute and Middleware
Known Uses HughesEtAl97 and SneedMajnar98


Related pages: ReengineeringPatterns

This page last edited on 5 January 2000
 
 
  • Search for: