Transcript 1. INTRODUCTION - University of South Carolina

Legacy Systems
© 1998 Singh & Huhns
1
Legacy Systems: Negative
A pejorative term for computing systems that are
• Old
• Mainframe-based
• Obsolete hardware
• Terminal-based interfaces
• Arcane communication networks
• Software not maintained any more and extremely expensive to modify
• Old-technology databases—typically hierarchical or network
• Poorly documented software
Legacy systems are important to cooperative information
systems precisely because they are not cooperative!
© 1998 Singh & Huhns
2
Legacy Systems: Positive
• Fulfill crucial business functions
• Work, albeit suboptimally
– Run the world’s airline reservation systems
– Run most air traffic control programs
• Have dedicated users
• Represent huge investments in time and money
© 1998 Singh & Huhns
3
Main Problems
• Applications don’t talk to one another, even on the
same system
– Won’t share data
– Won’t necessarily share procedures
– Lead to redundancy, wasted effort, and integrity
violations
• Closed: will not operate in cooperation with or
properly interact with other systems
• Typically, use software proprietary to a single
manufacturer
© 1998 Singh & Huhns
4
Current Trends
Create open systems
• Follow industry standards
• Use advances in software engineering and databases
• Enable applications to talk to one another, even if developed by
different manufacturers
This leads to better systems, because different components
can be manufactured by specialists and the users get to
choose the ones they want to use. In practice, there are
always some difficulties
But what about the older systems?
© 1998 Singh & Huhns
5
An Approach
• Introduce new technology as needed
• Integrate the legacy systems with the new
technology
• Integrate the legacy systems with each other
• But don’t spoil existing applications
Is this even possible?
• If not, why not?
• If so, how might one achieve this?
© 1998 Singh & Huhns
6
Relevant Issues
Whether or not one can accomplish the goals of the previous
transparency depends on how much one bites off.
The relevant issues, which will determine the success of any
technique, include
• The effort per system one is willing to invest in
– modifying existing applications
– acquiring knowledge about, I.e., models of, the existing
applications
• The limits on the ranges of the new applications
• Whether improvements to legacy applications and systems
are sought
© 1998 Singh & Huhns
7
How Legacy Systems Arise
• Proprietary software
– not documented
– not supporting industry standards (vendors who hope to lock in the
market through incompatibility)
• A need to capture more details of semantics than readily
permitted by the technology
• Ad hoc changes to software in response to
– changing requirements, because of changes in laws, regulations,
competition, or other business needs
– fixing bugs
© 1998 Singh & Huhns
8
Levels of Interoperation
Respond to the various ways in which legacy
systems misbehave:
• Communication Interoperability
• Message Interoperability
• Task Coordination
• Semantic Interoperability
• Development of Applications
In addition, a means to manage change is important
© 1998 Singh & Huhns
9
Communications
Glue S/W
•••
New,
Open System(s) Legacy HW & SW
Glue s/w provides access to communication resources and maps
among communication protocols. (Often, the lower levels of such s/w
are available from the legacy system manufacturers trying to make
their systems compatible with newer ones.)
© 1998 Singh & Huhns
10
Messages
Middleware
Clients
Servers
Glue S/W
•••
Open Systems
Legacy HW & SW
• A client application can access and update databases without concern
for the message protocol for the server DBMS
• For example, a C program can use the standard SQL Access Group’s
call level interface to access Ingres, Oracle, or Sybase using the Open
Database Connectivity (ODBC) protocol
© 1998 Singh & Huhns
11
Task Coordination
• Tasks execute on multiple client, server, and
middleware systems
• A glue scheduler controls
– the ordering of the execution of the tasks
– the exchange of information among the tasks
• Tasks used for
– distributed queries
– relaxed transactions
– general workflow processing
© 1998 Singh & Huhns
12
Semantic Interoperability
• Integrate database schemas
• Generate business rules
• Generate integrity constraints on various
information resources that can be combined
to capture the proper behavior of any
application
© 1998 Singh & Huhns
13
Application Development
How to develop new applications that
• extend over multiple new and legacy systems
• respect the semantics of the various resources they
impinge upon
© 1998 Singh & Huhns
14
Managing Change
• How may one add or remove databases
dynamically without modifying applications, and
without affecting the ongoing activities in the
system
• How may new databases operate concurrently
with old databases
• There are similar requirements for applications
and user interfaces
© 1998 Singh & Huhns
15
Autonomy
Design vs. control autonomy
• Political reasons
– Ownership of resources
– Control, especially of access privileges
– Payments
• Technical reasons
–
–
–
–
Conceptual problems in integration
Fragility of integration
Difficult to guarantee behavior of integrated systems
Opacity of systems with respect to key features, e.g., precommit
• Leverage: Use agents!
– Modularity
– User control
– Negotiation among agents to resolve conflicts
© 1998 Singh & Huhns
16
Locality
• Global information (data, schemas, constraints) causes
– Inconsistencies
– Anomalies
– Difficulties in maintenance
• Relaxation of constraints works often
– Correct rather than prevent violations of constraints--often feasible
– When, where, and how of corrections must be specified, but it is
easier to make it local (recall process abstractions)
• Still need some global information, or way to obtain it
– Locations of services or agents
– Applicable business rules
– Obtain other global knowledge only when needed
© 1998 Singh & Huhns
17
Migration
• Updating technology is
– Essential
– A continual process
• All at once?
–
–
–
–
Expensive
Risky
Brittle
Frustrating for users
• Gradual change: dismantle legacy and build desired system
hand-in-hand
– Install and test piecemeal
© 1998 Singh & Huhns
18
Old-to-New Converters
IMS
Code
Legacy HW & SW
Convert Old
Interface to New
SQL
New System
• Example: hierarchical to relational converters, which generate SQL
from hierarchical (e.g., IMS) programs
© 1998 Singh & Huhns
19
New-to-Old Converters
Convert New
Interface to Old
IMS
Code
Legacy HW & SW
SQL
New System
• Example: relational to hierarchical converters, which generate
hierarchical (e.g., IMS) programs from SQL
© 1998 Singh & Huhns
20
Converters Applied to Interoperation
• Converters work well for small cases, where there
are only a small number of applications to
consider
• Converters don’t address the general problem of
operating legacy systems with each other or with
new systems
– can be applied, but expensively
– need a converter between every pair of applications,
user interfaces, and database systems
© 1998 Singh & Huhns
21
A Better Picture
Application
Convert Any New
or Old Interface
Applications
and
Interfaces
Legacy HW & SW
Convert Any New
or Old Interface
New Systems
• With enough such generic converters, we can make legacy systems
talk to one another and to new systems
• Bonus: we can handle disparities among new systems as well
© 1998 Singh & Huhns
22
Further Requirements
Assuming the generic converters are available, what else do
we require for true interoperability?
• A way to interpose converters between the systems
nondestructively
• Additional typing on the messages exchanged in the
system
• A way to ease the significant burden on the applications
– Something to keep track of the resources, i.e., applications and
databases
– A task coordinator
© 1998 Singh & Huhns
23
One Approach
Middleware
Clients
Servers
Glue S/W
•••
Open Systems
Legacy HW & SW
• The glue software does all the work
• Is such a glue possible?
• How might it be constructed?
© 1998 Singh & Huhns
Distributed UNIX Systems
24