CSER Logo
Home

Links

People

Publications

Migrating relational database applications to Enterprise Java Beans environment

With the growth of the Web, web-based multi-tier software architectures have become the norm. Such architectures typically include relational databases at the backend, application and web servers in the middle, and thin clients at the front. The primary objective of our research is to develop methodologies and tools to support the reengineering of legacy systems into such web-based architectures.

More specifically, we focus on two of the new developments that are taking placing in the area of web-based software development. One is at the server side. The Enterprise JavaBean (EJB) is becoming a widely accepted server-side programming model that supports object persistency, remote object access, and transaction management. The other is at the client side and is concerned with self-contained, self-describing web services in XML format that can be published, accessed and integrated over the web. For legacy systems to be migrated, we propose to investigate the migration of both monolithic mainframe applications, and multi-tier software that are not using EJB or web service technologies.

Our first goal in this research is to enhance and productize the Websphere migration tool. The midterm goal is to develop generic tools to support the migration from relational database applications to EJB-based architectures. Our long-term goal is to study the migration from relational database applications to object oriented systems with some kind of object persistence mechanism, other than EJB.

More specifically, we will develop the following techniques to achieve our goals:

Relational database migration

Many applications will evolve over time and in many cases database schema will change. There are three levels of relational database migration, i.e., data migration, schema migration, and query transformation. It is important to develop methods and tools supporting the encoding, elicitation, enrichment and editing of the schema mapping. Based on the formalism of the schema mapping, we will develop theories and tools for migrating data from one database to another, and translating SQLs from one schema to the equivalent SQLs in another schema.

SQL-EJB mediation

Enterprise beans are wrappers of the databases and other information systems. Typically they have limited query answering capabilities. For a query in a legacy system, the SQL-EJB mediator will decompose the query, find the relevant Enterprise beans, send out sub-queries using different beans, and compose the results. Given a query in a legacy system, and a set of enterprise beans with SQLs imbedded in the finder methods in the EJB architecture, the task of SQL-EJB mediator is to identify the enterprise beans, their relevant methods, and the way to combine those methods.

Obviously, there are several questions need to be answered before we can automate the migration of the SQLs to the client Java code in the EJB architecture:

  1. For a query in the legacy system, is there a way to decide which finder method in EJB architecture is semantically equivalent to the query?
  2. When there does not exist a single corresponding finder method, is there a way to find a bunch of finders that are semantically equivalent?
  3. After we decompose the query into several sub-queries, how to combine them in the EJB client Java program?
  4. When those sub-queries (finders) do not exist, what kind of finders we need to add? More specifically, what kind of finders we need to add so that it is guaranteed every query in the legacy system can be represented in the EJB?

If we regard the finders as the view definitions in database, we can see that the first question corresponds to query containment, the second corresponds to query rewriting using views, the third corresponds to query planning and the fourth the view selection (view configuration).

Enterprise bean generation

While rewriting SQLs using EJBs, it is not always possible to find an equivalent rewriting. This is because the EJB architecture only provides partial query answering capability. One of the reasons doing so is to increase the security and modularity of the system. EJB designers design the EJBs using their experience, and it is not easy to foresee all the possible usage. The finder methods and the imbedded SQLs are added in an ad hoc way. The appropriate choice and definition of finders in entity beans should highly dependent at the set of queries we expect to be given. Our task is, given a set of legacy SQLs, how to produce the finder methods and SQLs inside the finder methods, so that all legacy SQLs have a rewriting using the finders?

Nowadays, enterprise Java beans are hand-coded, or mapped from the underlying relational database schema. We propose to generate beans from the set of legacy relational queries. EJB architecture generation will be studied in the context of the view selection problem for heterogeneous databases.

References

  • T. Lau, J. Lu, J. Mylopoulos and K. Kontogiannis. Migrating E-commerce Database Applications to an Enterprise Java Environment, Information Systems Frontiers 5 (2), Kluwer Academic Publishers, 2003. paper
  • J. Lu and J. Mylopoulos, EJB Client Code Generation Using Query Rewriting, 7th International Database Engineering and Application Symposium (IDEAS"03), Hong Kong, July 2003. paper.