Legacy systems are old software systems that are used by an organization. Usually, they rely on obsolete technology but are still essential to the business. It may not be cost-effective to rewrite or replace these systems and many organizations would like to use them in conjunction with more modern systems. One of the most important uses of services is to implement ‘wrappers’ for legacy systems that provide access to a system’s functions and data. These systems can then be accessed over the web and integrated with other applications.
To illustrate this, imagine that a large company maintains an inventory of its equipment and an associated database that keeps track of equipment maintenance and repairs. This keeps track of what maintenance requests have been made for different pieces of equipment, what regular maintenance is scheduled, when maintenance was carried out, how much time was spent on maintenance, etc. This legacy system was originally used to generate daily job lists for maintenance staff but, over time, new facilities have been added. These provide data about how much has been spent on maintenance for each piece of equipment and information to help to cost maintenance work to be carried out by external contractors. The system runs as a client-server system with special-purpose client software running on a PC.
The company now wishes to provide real time access to this system from portable terminals used by maintenance staff. They will update the system directly with the time and resources spent on maintenance and will query the system to find their next maintenance job. In addition, call centre staff require access to the system to log maintenance requests and to check their status.
It is practically impossible to enhance the system to support these requirements so the company decides to provide new applications for maintenance and call centre staff. These applications rely on the legacy system, which is to be used as a basis for implementing a number of services. This is illustrated in Figure 1, where I have used a UML stereotype to indicate a service. New applications exchange messages with these services to access the legacy system functionality.
Some of the services provided are:
- A maintenance service This includes operations to retrieve a maintenance job according to its job number, priority and geographical location, and to upload details of maintenance that has been carried out to the maintenance database. The service also provides operations that allow a maintenance job that has started but is incomplete to be suspended and restarted.
- A facilities service This includes operations to add and delete new equipment and to modify the information associated with equipment in the database.
- A logging service This includes operations to add a new request for service, delete maintenance requests and query the status of outstanding requests.
Notice that the existing legacy system is not simply represented as a single service. Rather, the services that are developed to access the legacy system are coherent and support a single area of functionality. This reduces their complexity and makes them easier to understand and reuse in other applications.