1 / 28

Wrapper-Based Evolution of Legacy Information Systems

Wrapper-Based Evolution of Legacy Information Systems. From the article by P. Thiran, J. Hainaut, G. Houben and D Benslimane Presentation by: Alex Saville, Espen Skogen and Sharon Stanley. Introduction. Overview Why do we need wrappers? Meeting The Challenge How do they work?

brie
Download Presentation

Wrapper-Based Evolution of Legacy Information Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wrapper-Based Evolution of Legacy Information Systems From the article by P. Thiran, J. Hainaut, G. Houben and D Benslimane Presentation by: Alex Saville, Espen Skogen and Sharon Stanley

  2. Introduction • Overview • Why do we need wrappers? • Meeting The Challenge • How do they work? • The Solution • Schemas and Mapping • The Methodology • Conclusion

  3. Overview

  4. Why do we need wrappers? RBS DBMS NatWest DBMS RBS Data NatWest Data

  5. The Tale of Mr Ludd and Mr Moddy(An Analogy for Wrappers)

  6. Magic Sunglasses Mr Ludd Oldie = manual transmission Newby = automatic transmission

  7. Mr Moddy Oldie = manual transmission Newby = automatic transmission

  8. The Challenge

  9. Legacy application Application logic Data integrity checks, validation etc The Challenge Legacy System Many implicit constraints (i.e. not built into DBMS setup) Legacy DBMS (limited data integrity, limited validation) Few explicit constraints (i.e. built into DBMS setup) Legacy Data We start with a legacy system reading from and writing to a legacy database management system (DBMS).

  10. The Challenge Legacy application New application Existing Modern application Application logic Application logic Application logic Data integrity checks, validation etc KABOOM!!! Legacy System Modern System No implicit constraints Legacy DBMS (limited data integrity, limited validation) Modern DBMS (includes data integrity, includes validation) Legacy Data Modern Data We will try to put the new application into a modern system, accessing the legacy DBMS. The new application is designed using modern techniques, but again, is unsuitable for the legacy DBMS because it does not include data integrity checks, validation – i.e. the implicit constraints that accessing the legacy DBMS calls for.

  11. The Challenge Legacy application New application New application Existing Modern application Application logic Application logic Application logic Application logic Data integrity checks, validation etc Legacy System Modern System Data integrity checks, validation etc Data integrity checks, validation etc Legacy DBMS (limited data integrity, limited validation) Modern DBMS (includes data integrity, includes validation) Legacy Data Modern Data So we put data integrity checks and validation into the new application too. This will work fine as long as the new application accesses the legacy DBMS, although it is still using legacy-style techniques.

  12. The Challenge Legacy application New application New application Existing Modern application Application logic Application logic Application logic Application logic Data integrity checks, validation etc Legacy System Modern System Data integrity checks, validation etc Data integrity checks, validation etc Legacy DBMS (limited data integrity, limited validation) Modern DBMS (includes data integrity, includes validation) Legacy Data Modern Data If we later wanted to migrate the new application to use the modern DBMS, we would have extra processing which would be redundant at best, and at worst, incompatible data structures (bringing the risk of data corruption), which would mean extra work to ensure compatibility.

  13. The Proposed Solution:The Wrapper

  14. Legacy application New application Application logic Application logic Data integrity checks, validation etc Legacy System R/W Wrapper 1 Model Conversion Data integrity checks, validation etc Legacy DBMS (limited data integrity, limited validation) Legacy Data We will build our new application with a separate wrapper. It is used when reading from and writing to the legacy DBMS. Because it is used for reading and writing, it is termed a R/W wrapper (read/write)

  15. Legacy application New application New application Existing Modern application Application logic Application logic Application logic Application logic Data integrity checks, validation etc Legacy System Modern System R/W Wrapper 1 R/W Wrapper 1 Model Conversion Model Conversion Data integrity checks, validation etc Data integrity checks, validation etc Modern DBMS (includes data integrity, includes validation) Legacy DBMS (limited data integrity, limited validation) Legacy Data Modern Data If we want to read from or write to the legacy DBMS from the new application in our modern system as well, we can reuse the wrapper from our legacy system.

  16. Legacy application New application New application Existing Modern application Application logic Application logic Application logic Application logic Data integrity checks, validation etc R/W Wrapper 2 Model Conversion Legacy System Modern System Modern DBMS (includes data integrity, includes validation) Legacy DBMS (limited data integrity, limited validation) Legacy Data Modern Data

  17. The Wrapper Interface • How does a application communicate with the wrapper? • How does the wrapper communicate with the legacy DBMS?

  18. R/W Wrapper for Accessing Legacy DBMS A communication with the wrapper schema The communication protocol for communication with the wrapper Wrapper queries / updates Wrapper Schema R/W Wrapper The communication protocol for communication with the legacy DBMS Database queries / updates A communication with the legacy schema Legacy Schema Legacy DBMS (limited data integrity, limited validation)

  19. Schemas(diagrams taken from article) Physical Schema The Physical Schema can be determined by analysing the SQLDDL. Note that the Physical Schema only contains explicit constraints (e.g. uniqueness due to indexes). Customer Order Reference Name Address Account Number Customer Account Date Amount Product In this database, there are two tables: Customer and Order. Acc: Reference Customer is indexed on the column Reference. Acc: Customer Order is indexed on the column Customer.

  20. Physical Schema Customer Order Reference Name Address Account Number Customer Account Date Amount Product Acc: Reference Acc: Customer Schemas(diagrams and examples taken from article) The next stage is to determine the logical schema. This is derived through analysis of the code and data. For example, the code might check that Customer Number exists on Customer, prior to inserting an Order. This tells us that Customer Number is an implicit foreign key. Data analysis might hint at Customer being functionally dependent on Account due to the otherwise seemingly redundant attribute. Logical Schema Customer Order Reference Name[0-1] Address Account Number Customer Account Date Amount Product Street Zip City id: Reference id: Number ref: Customer fd: Customer Account

  21. Physical Schema Customer Order Reference Name Address Account Number Customer Account Date Amount Product Acc: Reference Acc: Customer Schemas(diagrams taken from article) Wrapper Schema • Finally, we must create the wrapper schema from the logical schema. • The logical schema must comply with how the wrapper needs to see its data • Any redundant data must be hidden from the wrapper schema, while still being managed. • e.g. Account occurred both tables, so one occurrence is redundant. Therefore it has been grouped with Customer, not Order. Customer Order Reference Name[0-1] Address Street Zip City Account Number Customer Date Amount Product id: Number ref: Customer id: Reference Logical Schema Customer Order Reference Name[0-1] Address Account Number Customer Account Date Amount Product Street Zip City id: Reference id: Number ref: Customer fd: Customer Account

  22. Physical Schema Wrapper Schema Customer Order Customer Order Reference Name[0-1] Address Account Number Customer Account Date Amount Product Reference Name[0-1] Address Street Zip City Account Number Customer Date Amount Product Acc: Reference id: Number ref: Customer Acc: Customer id: Reference Mapping (diagrams taken from article) Wrapper Update INSERT INTO Order (Number, Customer, Date, Amount, Product) VALUES (: Number, :Customer, :Date, :Amount, :Product); Database Query/Update If exists (SELECT * FROM Order WHERE Number = :Number) or not exists (SELECT * FROM Customer WHERE Reference = :Customer) then return error; else SELECT Account INTO :Account FROM Customer WHERE Reference = :Customer INSERT INTO Order (Number, Customer, Date, Amount, Product) VALUES (: Number, :Customer, :Date, :Amount, :Product); endif;

  23. Physical Schema 1. Implicit Constraint Management (the wrapper checks the constraints implied by the implicit identifier (exists) and implicit foreign keys (not exists)). 3. Redundancy Management (the wrapper assigns the values for redundant data from the source data (Account) Customer Order Reference Name[0-1] Address Account Number Customer Account Date Amount Product 2. Data Error Management (the wrapper reports on violation of implicit constraints). 4. Query translation – of the wrapper update against its schema to updates on the physical schema Acc: Reference Acc: Customer Mapping (diagrams taken from article) We will now examine the database query/update that has resulted. Database Query/Update If exists (SELECT * FROM Order WHERE Number = :Number) or not exists (SELECT * FROM Customer WHERE Reference = :Customer) then return error; else SELECT Account INTO :Account FROM Customer WHERE Reference = :Customer INSERT INTO Order (Number, Customer, Date, Amount, Product) VALUES (: Number, :Customer, :Date, :Amount, :Product); endif;

  24. Wrapping Up – A Summary of the Basic Architecture of a R/W Wrapper • Query / update analysis • Error reporting • Query / update and data translation • Implicit constraint control • Security* • Concurrency and transaction management* * Out of scope for the article, and therefore for this presentation.

  25. Generic Methodology • Database reverse engineering • No up to date documentation • Wrapper generation • Mapping to functions

  26. Conclusion • Relatively smooth transition • Only one area of coding • Allows any program to read and update • Controls the integrity of data • Relatively time and cost effective

  27. References • P. Thiran, J. Hainaut, G. Houben and D Benslimane (2006), ‘Wrapper-Based Evolution of Legacy Information Systems’, ACM Transactions on Software Engineering and Methodology, Vol 15, No 4, Pages 329-359 • Dr. David Corman, The Boeing Company (2001), The IULS Approach to Software Wrapper Technology for Upgrading Legacy Systemshttp://www.stsc.hill.af.mil/crosstalk/2001/12/corman.html, accessed October 2007 • Dean, J., Li, L. (2002), Issues in Developing Security Wrapper Technology for COTS Software Products http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-44924_e.html, accessed October 2007 • Kelly, R., Fritsch, M., (2003), Improved effectiveness with information consolidation - Creating information transparency and consistency http://download.oracle.com/owparis_2003/40266.doc , accessed October 2007

  28. Questions?

More Related