X hits on this document





86 / 120

IEEE floating point representation; they instead use decimal floating point [44]. Without

detailing all the differences between the COBOL, Java, and C/C++ data models, it

suffices to say that writing custom code to convert between COBOL's data model and the

language we wish to invoke it from is error-prone and tedious and there are better


The problem of mating disparate data models so that new programs, written in

modern languages, can interact with legacy software systems, is far from new. There are

many commercial tools on the market that can import a COBOL data structure and

generate Java helper classes that a programmer can use to build to meet the legacy binary

interface using familiar getters and setters. A great many of these tools, including IBM's

Rational Application Developer (RAD) [33], leverage Sun Microsystems J2EE Connector

Architecture (JCA) [34] to provide a tightly coupled integration between a Java

application running in a J2EE container (server) and an enterprise application (likely

written in COBOL or PL/I) running on a mainframe. The JCA architecture requires a

good deal of middleware to exist between a calling Java application running in the J2EE

container and the COBOL application running on a legacy software system. While this

middleware is powerful because of its capability to marshall Java data into COBOL and

PL/I data, it cannot easily be reused for a local scenario where no server runtimes are

involved. Fig. 9.3 illustrates how the JCA architecture is used by commercial products to

enable legacy business applications to be accessed from Java applications running on

distributed J2EE application servers.


Document info
Document views466
Page views467
Page last viewedThu Jan 19 07:34:16 UTC 2017