Post on 21-Dec-2015
transcript
© 1998 Singh & Huhns 1
Legacy Systems
© 1998 Singh & Huhns 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
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 10
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)
© 1998 Singh & Huhns 11
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
© 1998 Singh & Huhns 12
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 13
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 14
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 15
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 16
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
© 1998 Singh & Huhns 17
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 18
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 19
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
© 1998 Singh & Huhns 20
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
© 1998 Singh & Huhns 21
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 22
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
© 1998 Singh & Huhns 23
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 24
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