topical media & game development
Migrating from legacy applications
With IT becoming the spine of business processes,
many companies are urged to move away from their
legacy applications and jump right into the new technologies,
to take advantage of the rich GUI capabilities of
current desktops, client/server computing and the Web.
However, most companies are still tied to their (mainframe)
legacy systems, and the cost of (re)development is in general
slide: Three-tier architecture
As phrased by [Legacy], what they need is an unobtrusive
method of integrating terminal-based (legacy) software
with newer technologies, to provide
the existing information and services with some
new (GUI and Web-based) clothing.
[legacy], it is depicted how such an integration might
be achieved with a three-tier architecture
employing a terminal emulation or screen-scraping API
for encapsulating the legacy objects,
and a HTTP server to deliver the functionality to
a (thin) Web client.
(Information about the Legacy Object Framework
can be found at www.yrrid.com .)
The advantage of a three-tier solution is
the decoupling of the legacy application from both
GUI functionality and (middleware) business logic.
The legacy object modeling, which reflects the business logic,
is taken care of in a middleware layer, to allow for thin
or ignorant clients.
In [Legacy], alternative solutions are discussed as well,
including CORBA-based three-tier solutions as well as
a variety of two-tier architectures with fat clients
that carry all the knowledge about the business logic
underlying the legacy application themselves.
In comparison, three-tier solutions are to be
preferred, since they allow for better maintenance.
Nevertheless, according to [Legacy], the development
effort is significantly higher.
the IT section of a large social security organization
in the Netherlands, students of the Vrije Universiteit
have been involved in projects aimed at developing
a new information infrastructure.
There we studied intensively the three tiers
and in particular the boundaries between these tiers,
notably the GUI/Business Objects boundary
and the Business Objects/Database boundary,
using Java, CORBA, (D)COM and proprietary middleware.
Generalizing, our conclusions thus far are that
decoupling is much harder to achieve than we expected.
For example, defining transactions using
business objects seems to require more knowledge
of the database backend than is desirable.
Also, it seemed necessary to replicate much of the
business logic inherent in the database.
And, defining user interaction with business
objects in a purely abstract fashion,
that is independent of an actual interface technology,
proved to be difficult as well.
For an organization such as ASZ/GAK, migration is necessary,
simply because the risk of an abrupt transition is too high.
This may also explain why the IT staff of ASZ/GAK
responsible for maintaining the system were at first not too
eager to experiment with the new technologies.
Our experiments, however, convinced them
that there is hope for the future.
You may not copy or print any of this material without explicit permission of the author or the publisher.
In case of other copyright issues, contact the author.