HughesEtAl97 |
PublicReengineering Wiki |
|
| The authors report on their experiences of reengineering US Air force planning systems. Their goal is to extract common services that may be duplicated in various
disparate legacies and allow the legacies to use these services by invoking a distributed request broker such as CORBA. There are difficulties of course, eg the
generic functionality that would benefit from encapsulation (wrapping) is often entwined in the legacy code and difficult to extract. The benefits are that there is only
one instance of the common service and it does not need to be maintained in various legacies. Also, some dependence on the legacy is removed. Since the
distributed object management conforms to a standard, there may be the opportunity to use a commercial product to supply the service to the legacy application.
there is also platform and language independence, network transparency, potential for reuse and consistent interface documentation.
They distinguish between course grained encapsulation, ie wrap the whole legacy and fine grained where some functionality of the legacy is extracted and made
into a common service.
They have used Iona Technologies Orbix middleware ORB (CORBA compliant).
They adopted a 10 step methodology on a pilot project. This included: identifying the application and services for reengineering by considering costs and benefits as
well as the impact of the new architecture (the ORB must be compatible with the systems and languages); identify the tools needed, eg reverse engineering tools
and decide on the reengineering environment (the original, reengineering and deployment environments may all be very different); build the new service which may
be newly developed, from a third party or a wrapped portion of the legacy; reengineer the legacy code to make it use the new service; test and document.
They found configuration management tools important to reconcile the various legacy and service modules. They found original makefiles very complex and had to
reverse engineer. They reckon it is sensible to work in small steps. Since the legacy and new services are likely to represent information differently, they propose
the use of a mediator. The mediator contains a repository of the representations and assumptions of each part. For each call, the mediator automatically inserts the
necessary translation expression. Ideally the redundant code in the legacy should be removed, but this may be too expensive. User interface functionality is difficult
to migrate because windows and menus can be platform specific.
They emphasise the importance of standards to wrapping. Standards allow future migration from the wrapped to an off the shelf product.
Related pages: Bibliography |
| This page last edited on 29 October 1999 |