Very few project teams have the benefit of being able to start from scratch, something often referred to as greenfield development. Instead, the cold, hard truth of the matter is that most Java project teams need to take into account existing legacy systems when they are developing new applications. Perhaps you need to access an existing inventory control system, a legacy customer database, or a mainframe-based security access control service. If so, then you have a legacy integration issue, often called Enterprise Application Integration (EAI) issue, on your hands. The advantage to your team is that if the legacy systems are reasonably well designed, then you can take advantage of significant amounts of existing functionality. However, if the legacy systems aren't well designed, or at least not designed with integration in mind, then you will find that your integration efforts are a significant portion of your project. This is particularly true when adequate documentation isn't available or when the owners of the legacy systems are unwilling to work with your team (never underestimate the effect of politics on your project).

There are four basic approaches to legacy integration as suggested by D.S. Linthicum in Enterprise Application Integration:

• Data-level integration
  From the point of view of a Java application, this type of integration focuses on the access of legacy databases or files by either session beans or entity beans. It also includes access to newly developed data feeds, produced by the legacy system, for the specific purpose of data access. XML is often used for this integration technique because XML is a platform-independent approach for sharing data. The advantages of data-level integration are that it is fairly straightforward and quick to implement. The disadvantages include increased data coupling between applications, thereby increasing your maintenance burden; the inability to access important behavior such as data validation and critical business rules; and the need to write significant data cleansing/formatting code for poorly designed data.
  
  
• Application-interface integration
  With this approach, you leverage the application programming interfaces (APIs) exposed by your applications to access both the data and the functionality encapsulated by legacy systems. The advantage of application-interface integration is that this approach is fairly standard within the industry; many packages such as SAP and PeopleSoft include C-APIs that you can access via Java Native Interface (JNI) code. The main disadvantages are that software developed within your organization rarely has a defined API; the APIs may be limited in scope and may not offer the behavior that you need (or in a manner that you need it); and APIs are often function-oriented in nature and not object-oriented.
  
  
• Method-level integration
  With this approach, business logic is shared as a collection of shared methods, or operations that your software can invoke. For example, common operations to update customer data, to validate a credit card transaction, or to deposit money into a bank account may be made available in a common repository or reusable framework that all applications have access to. The advantages of method-level integration are that it often provides fine-grained access to common business functions; a wide range of applications (including both Java and non-Java) can access the operations; and invoking the methods is straightforward. The disadvantage is that the fine-grained nature of the common methods can make it difficult to support transactions or to support common technical services, such as security access control, without significant scaffolding in each method.
  
  
• User interface-level integration
  This technique focuses on accessing existing applications through their user interfaces, a process called screen scraping, in which user keystrokes are simulated to implement the interaction with the legacy software. Screen scraping is a common technique used by Web-based aggregator sites, for example Vertical One, to present personalized views of financial or other types of information. The advantage is that this is a time-tested and common approach for legacy integration, one that is taken by many user interface testing tools such as IBM Rational Functional Tester or Mercury Interactive's WinRunner. The main disadvantage is that this approach can be slow: you need to wait for the legacy application to render the screen that you are scraping, and any changes to the legacy user interface necessitate changes to your integration code.

Luckily, simple legacy integration -- particularly when the legacy systems are designed with integration in mind -- can often be handled through middleware products such as Tibco Inc's ActiveEnterprise product line, IBM MQSeries product family, and Iona's iPortal Integration Server. However, when the integration effort proves to be more complex than what is handled by your organization's middleware infrastructure, you will find that you need to write your own integration code, often called "wrapper" code. Table 1 lists various options that you can apply in your Java code, describing how each technique can be used to integrate Java applications with legacy systems.

Resources

• Interactive's WinRunner
  
  
• Rational Corporation's SQA Suite
  
  
• Tibco Inc's ActiveEnterprise product line
  
  
• IBM MQSeries product family
  
  
• Iona's iPortal Integration Server
  
  

• Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology by Scott W. Ambler. New York: Cambridge University Press, 1998.
  
  
• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2000.
  
  
• The Unified Process Elaboration Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000
  
  
• The Unified Process Construction Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• The XML Handbook 2nd Edition by Charles Goldfarb and Paul Prescod. Upper Saddle River, NJ: Prentice Hall PTR, 2000.
  
  
• The Java Native Interface: Programmer's Guide and Specification by Sheng Liang. Reading, MA: Addison Wesley Longman, 1999.
  
  
• Enterprise Application Integration by David S. Linthicum. Reading, MA: Addison Wesley Longman, 2000.
  
  
• Database Programming with JDBC and Java by George Reese. Sebastopol, CA: O'Reilly & Associates, 2000.
  
  
• Mastering Enterprise Java Beans and the Java 2 Platform, Enterprise Edition by Ed Roman. New York: John Wiley & Sons, 1999.
  
  
• The Elements of Java Style by Alan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, and Patrick Thompson. New York: Cambridge University Press, 2000.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers