Legacy Connectivity

Proprietary bridges.

·         EJB-COM bridge to connect to COM+ components.

·         Microsoft’s JVM provides (or used to provide) a bridge between Java and COM objects.

·         The disadvantage of these proprietary bridges is a loss of portability, since there is no guarantee that this code will run in other J2EE-compliant servers.

·         If the non-client tiers of the legacy system are implemented as COM objects, the applets can communicate with these objects by taking advantage of Java-to-COM bridging technologies that enable COM objects to be accessed as Java classes. RMI may be used to support communication between applets and remote Java code that supports Java to COM bridging.

The Java Native Interface (JNI).

·         JNI enables you to bridge into native code, such as C++ code.

·         The advantage of the JNI is that it's faster than the other approaches.

·         The disadvantages are that

o        it can't connect to any system (just native code),

o        the existing system needs to run in-process, and

o        JNI is platform-specific--so if your code needs to run on multiple platforms, you're multiplying the testing and maintenance effort.

·         JNI was developed as a way for Java applications to take advantage of platform-native resources; it allows the JVM to interoperate with applications and libraries written in C, C++, assembly, and several other languages.

·          With JNI, not only can Java call native code but the native code can also create and manipulate Java objects. The result is that JNI allows full language interoperability, making it an ideal candidate for legacy application integration.

The Common Object Request Broker Architecture (CORBA).

·         You can bridge into code written in almost any language by calling that legacy system via CORBA APIs from within your EJB layer.

·         This is highly appropriate for existing systems that are already CORBA-based.

·         The disadvantages of CORBA integration are that

o         it requires an out-of-process remote call, which slows performance, and

o        it requires that you learn a whole new technology if you don't already know CORBA.

Java Message Service (JMS).

·         JMS (along with message-driven beans) enables you to bridge to existing systems using message-oriented middleware. You send messages to existing systems rather than invoking them directly through API calls.

·         This is a bit slower, but

·          it also is a loosely coupled paradigm that enables you to build complex messaging workflows.

·          JMS is highly appropriate if your existing system already uses messaging.

Web services.

·         use XML to represent the data sent to existing systems, and HTTP is your transport

·         allows you to navigate firewalls easily.

·         is a nonintrusive approach because any system that is Internet-enabled can use Web services without needing a whole separate communications infrastructure, such as CORBA or JMS.

·         the disadvantage of Web services is that the XML parsing overhead may slow you down

The J2EE Connector Architecture (JCA).

·         The JCA is a specification that enables you to acquire drivers that connect with existing systems and plug them into your J2EE server to connect to a legacy system.

·         You can connect to any existing system for which drivers exist.

·         And if no driver exists (such as a proprietary internal system you've built in-house), you can write your own driver.

·          JCA-compliant resource adapters are evolving, which is analogous to JDBC drivers connecting a relational database. Examples include CICS, Tuxedo, MVS/VSAM, SAP R/3 and PeopleSoft.

Screen Scrapers

·         A screen scraper is an application that translates an existing client interface into a set of objects.

·          Screen scrapers usually function as a terminal emulator on one end and an object interface on the other.

·         The screen scraper is configured to read data from terminal fields of the legacy interface and make them available via objects.

·         Screen scrapers may be used to integrate applet (or other) interface with an existing system.

·         Particularly useful when the client interface is tightly coupled to the other tiers of the system.

·         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

·         Also used if the legacy system does not have a published interface or the documentation has been lost.

·         In applications where the client interface is tightly coupled with the business logic and data storage of the existing legacy system, providing an applet-based interface becomes more complicated. In situations like these, screen scraper technology may be used to integrate an applet interface with the existing system.

·         In cases where the client interface is loosely coupled with the other tiers, the client interface ( client tier) can probably be replaced (for eg: with applet) along the current boundary between the client interface tier and other tiers

·         The use of screen scrapers may have been the best short-term solution. However it is certainly not the best medium to long-term approach

·         Advantages of screen scrapers:

o        Provides a low-level object-based interface to the legacy app.

o        Allows you to build a new GUI over the existing client interface.

·         Disadvantages of screen scrapers:

o        Any changes to the legacy interface can break the new GUI.

o        Prone to causing errors in the new GUI because of unexpected outputs from the legacy interface.

o        Prone to causing the new GUI to “freeze” when the legacy interface is expecting input that the screen scraper in unaware of.

o        inherent inability to handle unexpected events related to the host connection behavior, like

·         keyboard lockups,

·         session disconnections, and

·         broadcast messages from hosts,

·         unexpected error messages coming from the "scraped" application.

Off-board server

·         An off-board server is a server that executes as a proxy for a legacy system.

·         It communicates with the legacy system using the custom protocols supported by the legacy system. It communicates with external applications using industry-standard protocols.

·         An off-board server is used enable secure remote access to mainframes. This is done typically done by forwarding SSL requests to the mainframes via serial connections.

·         An off-board server does not provide single sign on capabilities to a J2EE application. It is also not an application server that can take up complex business logic processing. An Off board server does not store public keys of trusted Certification Authorities (CA) or perform symmetric key encryption.

Object Mapping Tools

·         Object mapping tools can be used

§         if you choose to ignore the existing legacy interface and

§         access the underlying tiers directly.

·         These tools are used to create proxy objects that access legacy system functions and make them available in an object-oriented form.

·         Object mapping tools are usually more effective than screen scrappers because they are not dependent on the format generated by the existing legacy interface.

·         Object mapping is not limited to user-interface upgrades. It may also be used to upgrade application business logic and data storage tiers.

·         You need access to the legacy system's source code

Upgrading the Data Storage Tier

§         JDBC may be used to access relational databases in a legacy system.

§         JDBC—If portions of the current interface communicate directly with the data storage tier, this communication may be replaced by applets that use JDBC (and possibly the JDBC-ODBC) bridge to communicate with the data storage tier.

§         In many cases the legacy database will not support a pure JDBC driver. If the database provides ODBC support the JDBC-ODBC bridge can be used.

§         If the existing legacy database is hierarchical or flat-file then it may be able to be imported into an RDBMS.

§         In addition to accessing legacy databases using JDBC, other more object-oriented approaches may be used. Sun's Java Blend (object-relational mapping) product provides the capability to access SQL-compatible databases as collections of objects. OQL-compatible databases provide the capability to store objects in databases and query databases in an object-oriented manner.

§         If the database uses custom drivers, it might be possible to find database middleware that supports the custom driver and either an ODBC or JDBC interface

Securing Legacy System Components

§         One common problem found with legacy systems is that they are designed to operate using proprietary closed networks in a restricted user environment. Computer and network security measures that are designed for this environment are not sufficient to protect against Internet-based attacks

§         Retrofitting a system with security is generally more expensive and less productive than the redesigning and redeveloping the system to operate in a secure manner. However, budget constraints may prevent this.

§         Legacy systems may be isolated from threats by placing them behind a firewall.

§         Access control to legacy systems can be controlled by requiring users and external applications to authenticate themselves with the firewall before they can access the legacy system.

§         Auditing features of the legacy system should be used to determine who is accessing the legacy system and when.

§         A Virtual Private Network (VPN) may be used to secure all communications with a legacy system.

RMI

·         RMI connects to existing and legacy systems using the standard Java native method interface JNI.

·         RMI can also connect to existing relational database using the standard JDBC? package.

·         The RMI/JNI and RMI/JDBC combinations let you use RMI to communicate today with existing servers in non-Java languages, and to expand your use of Java to those servers when it makes sense for you to do so..

Java IDL

• Java IDL embeds Java into the CORBA world. It includes a new Java IDL API (org.omg.CORBA, org.omg.CosNaming) and tools including an IDL-to-Java compiler (idltojava) and an ORB.
• The ORB includes the Java-to-IDL and Objects-by-Value specs (both mandated by CORBA 2.3 and necessary for RMI-IIOP connectivity). It does not define an interface repository, however, so no dynamic lookup of parameters is possible.
• Sun recommendation: Java IDL should be used when accessing existing CORBA servers is the main purpose, whereas RMI-IIOP should be used when serving requests from CORBA clients is the main purpose.

·         Development

o        Process: Write interface in IDL, compile to Java (results in interface and several classes). Use interface in client programming. Descend server from generated ImplBase class (aka ‘implementation skeleton’).

o        IDL-to-Java also generates ‘Stub’ class (client proxy), ‘Holder’ class (for out or inout parameters) and ‘Helper’ class (for narrowing and reading/writing).

o        ORB interface (org.omg.CORBA.ORB) and implementations (e.g. com.sun.CORBA.iiop.ORB). Getting an ORB: static ORB.init.NamingContext in package org.omb.CosNaming.

o        Object references: Temporary references (through proxy) and long-lived ‘stringified’ interoperable object references (IOR).

RMI-IIOP

• Goal: Marry RMI and CORBA. Connect RMI clients to CORBA servers and vice versa.
• Benefits:

1.        Greater re-usability,

2.        legacy integration,

3.        robust firewall navigation.

4.        In the future support for transaction and security contexts can be added (new EJB/IIOP standard).

·         Specification

o        RMI-IIOP works with CORBA 2.3 ORBs. Required specs: Objects-by-value (IIOP does not traditionally support pass-by-value) and Java-to-IDL.

o        Java-to-IDL mapping defines how RMI and IIOP work together and the necessary RMI restrictions that are known as RMI/IDL. The mapping enables Java-to-IDL compilers to be written that take a Java remote interface and produce a corresponding CORBA interface specification in IDL.

o        EJB 1.1 mandates RMI-IIOP API to be present. However, there may still be two kinds of EJB servers: CORBA based and proprietary. The latter do not use CORBA, but implement communication differently (not using IIOP).

·         Development changes

·         Narrowing: Direct cast does not work on IIOP, PortableRemoteObject.narrow has to be used. In RMI direct cast works because Stub class can be loaded dynamically over the net.

·         Two new packages for RMI-IIOP: javax.rmi (PortableRemoteObject) and javax.rmi.CORBA (internal) (Normal RMI package is java.rmi).

·         No distributed garbage collection: Manually unregistering is necessary via unexportObject method.

·         RMI-IIOP clients must use JNDI. RMI registries and COS Naming can be plugged into JNDI.

·         Tools: Generation of RMI-IIOP stubs and skeletons: “rmic - iiop". IDL-to-Java compiler: “idlj”. Java-to-IDL-compiler: “rmi -idl”.

·         Note: Making object public through both JRMP and IIOP at the same time is possible.

CORBA

• CORBA is a unifying standard for distributed object systems. CORBA is managed by OMG, and can be used with many platforms and languages.
• Disadvantages: Complex standard, slow-moving.
• In a CORBA architecture, objects communicate through ORBs, using IIOP as the protocol.
• Object Adaptor: Maps object references to implementations, activates object if necessary. Portable Object Adaptor (POA) now widely used.
• Repositories: are used by ORBs.
• Interface repositories  and
• implementation repositories
• IDL: Interfaces are defined in the OMG IDL and can be compiled to a concrete language interface, e.g. Java, C, C++,COBOL, Ada, Smalltalk. IDL-to-Java Mapping defines details for Java. ( idlj compiler )
• Invocation: Static invocation uses pre-compiled stubs and skeletons for a specific language and object. Dynamic invocation does not use stubs and skeletons, but discovers object and methods dynamically using the Dynamic invocation interface (DII) at the client and dynamic skeleton interface (DSI) at the server. There are similarities between DII and using COM’s IDispatch interface.
• Corba Object Services (COS):  ( 5 services)  ( RMI-JRMP has only naming service)
• Naming,
• Object Transaction Service (OTS),
• Security
• Event (asynchronous messages),
• Concurrency control,.

RMI-IIOP   Vs JAVA-IDL For legacy integration:

• Java Objects can communicate with CORBA objects and vice versa.
• When you want a java client object to talk to a CORBA object, use JavaIDL and when you want CORBA client object to talk to Java Objects, use the ubiquitous EJB.
• Java IDL is for CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL). This is "business as usual" CORBA programming, supporting Java in exactly the same way as other languages like C++ or COBOL.
• RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) is for Java programmers who want to program to the RMI interfaces, but use IIOP as the underlying transport. RMI-IIOP provides interoperability with other CORBA objects implemented in various languages - but only if all the remote interfaces are originally defined as Java RMI interfaces. It is of particular interest to programmers using Enterprise JavaBeans (EJB), since the remote object model for EJBs is RMI-based.
• Java IDL! If you have been developing CORBA applications using IDL for some time, you will probably want to stay in this environment. Create the interfaces using IDL, and define the client and server applications using the Java programming language to take advantage of its "Write Once, Run Anywhere ^TM" portability, its highly productive implementation environment, and its very robust platform.
• RMI-JRMP! If all of your applications are written in the Java programming language, you will probably want to use Java RMI to enable communication between Java objects on different virtual machines and different physical machines. Using Java RMI without its IIOP option leverages its strengths of code portability, security, and garbage collection.
• RMI-IIOP! If you are writing most of your new applications using the Java programming language, but need to maintain legacy applications written in other programming languages as well, you will probably want to use Java RMI with its IIOP compiler option.

Levels of Integration

JDBC

• Access legacy databases.
• Supports data-level EAI.

RMI-IIOP

• Synchronous, peer-to-peer access of legacy systems and services.
• Supports method-level EAI.

JMS

• Asynchronous, message-based communication with legacy systems and services.
• Supports application-level and method-level EAI.

JNI

• Wrap C-APIs to access legacy systems and services.
• Supports application-level,method-level, and user interface-level (via screen scraping APIs) EAI.

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

o         it is fairly straightforward and

o         quick to implement.

·         The disadvantages include

o        increased data coupling between applications, thereby increasing your maintenance burden;

o        the inability to access important behavior such as data validation and critical business rules; and

o         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

o        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

o        software developed within your organization rarely has a defined API;

o        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

o        APIs are often function-oriented in nature and not object-oriented.

Method-level integration

·         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

o        it often provides fine-grained access to common business functions;

o        a wide range of applications (including both Java and non-Java) can access the operations; and

o        invoking the methods is straightforward.

·         The disadvantage is that

o         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

·         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

o        this is a time-tested and common approach for legacy integration, one that is taken by many user interface testing tools such as Mercury Interactive's WinRunner or SQA Suite from Rational Corporation.

·         The main disadvantage is that

o        this approach can be slow:

o        you need to wait for the legacy application to render the screen that you are scraping, and

o        any changes to the legacy user interface necessitate changes to your integration code.