1. © 1998 Singh & Huhns1 Legacy Systems

2. © 1998 Singh & Huhns2 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!

3. © 1998 Singh & Huhns3 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

4. © 1998 Singh & Huhns4 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

5. © 1998 Singh & Huhns5 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?

6. © 1998 Singh & Huhns6 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?

7. © 1998 Singh & Huhns7 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

8. © 1998 Singh & Huhns8 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

9. © 1998 Singh & Huhns9 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

10. © 1998 Singh & Huhns10 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)

11. © 1998 Singh & Huhns11 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 ClientsServers Middleware Legacy HW & SW Glue S/W Open Systems

12. © 1998 Singh & Huhns12 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

13. © 1998 Singh & Huhns13 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

14. © 1998 Singh & Huhns14 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

15. © 1998 Singh & Huhns15 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

16. © 1998 Singh & Huhns16 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

17. © 1998 Singh & Huhns17 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

18. © 1998 Singh & Huhns18 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

19. © 1998 Singh & Huhns19 Old-to-New Converters Example: hierarchical to relational converters, which generate SQL from hierarchical (e.g., IMS) programs Convert Old Interface to New IMS Code Legacy HW & SW SQL New System

20. © 1998 Singh & Huhns20 New-to-Old Converters Example: relational to hierarchical converters, which generate hierarchical (e.g., IMS) programs from SQL Convert New Interface to Old IMS Code Legacy HW & SW SQL New System

21. © 1998 Singh & Huhns21 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

22. © 1998 Singh & Huhns22 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 New or Old Interface Legacy HW & SW New Systems Application Applications and Interfaces Convert Any New or Old Interface

23. © 1998 Singh & Huhns23 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

24. © 1998 Singh & Huhns24 One Approach The glue software does all the work Is such a glue possible? How might it be constructed? ClientsServers Middleware Legacy HW & SW Glue S/W Open Systems Distributed UNIX Systems