Download Legacy Connectivity

Legacy Connectivity Notes
Author: RAMU MEDA
Date: 01/sep/03
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 messageoriented 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 SQLcompatible 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).
Connectivity
RMI Client
RMI Server
OK
RMI-IIOP Server
OK
CORBA Server
Not possible
RMI-IIOP Client
CORBA Client
OK
Not possible
OK
OK
Restrictions apply
OK
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.
o Interface repositories and
o 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)
o Naming,
o Object Transaction Service (OTS),
o Security
o Event (asynchronous messages),
o 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
App level Integ
Method Level Integ
OK
OK
OK
OK
OK
JDBC
RMI-IIOP
JMS
JNI
Data-Level
OK
User-Interface Lev Integ
OK
OK
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.