© 1998 Singh & Huhns1 Legacy Systems. © 1998 Singh & Huhns2 Legacy Systems: Negative A pejorative...

© 1998 Singh & Huhns 1

Legacy Systems


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!


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


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


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?


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?


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


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


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


Communications

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.)

Legacy HW & SW

Glue S/W

• • •New,

Open System(s)


Messages

• 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

Clients ServersMiddleware

Legacy HW & SW

Glue S/W

• • •Open Systems


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


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


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


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


AutonomyDesign 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


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


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


Old-to-New Converters

• Example: hierarchical to relational converters, which generate SQL from hierarchical (e.g., IMS) programs

Convert OldInterface to New

IMSCode

Legacy HW & SW

SQL

New System


New-to-Old Converters

• Example: relational to hierarchical converters, which generate hierarchical (e.g., IMS) programs from SQL

Convert NewInterface to Old

IMSCode

Legacy HW & SW

SQL

New System


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


A Better Picture

• 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

Convert Any Newor Old Interface

Legacy HW & SW

New Systems

Application

Applicationsand

Interfaces

Convert Any Newor Old Interface


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


One Approach

• The glue software does all the work

• Is such a glue possible?

• How might it be constructed?

Clients ServersMiddleware

Legacy HW & SW

Glue S/W

• • •Open Systems

Distributed UNIX Systems

© 1998 Singh & Huhns1 Legacy Systems. © 1998 Singh & Huhns2 Legacy Systems: Negative A pejorative...

Documents

Transcript of © 1998 Singh & Huhns1 Legacy Systems. © 1998 Singh & Huhns2 Legacy Systems: Negative A pejorative...