In-Depth
Re-energizing COBOL with Java
- By Richard Adhikari
- March 1, 2002
The death of COBOL, as reported widely back in the heady days of client/server
in the 1990s, has been greatly exaggerated. According to Gartner Inc., 80% of
the world's business runs on COBOL, there are 10 billion lines of COBOL in use
and 5 million lines of new COBOL code are written every year. But the advent
of client/server and distributed computing changed the face of computing forever,
introducing the concept of user-friendly interfaces and more input from business
users. Nobody wants to go back to COBOL's green screens and complex syntax that
requires the presence of programmers, especially in these days of fast-changing
business environments.
So, many companies are Java-enabling COBOL applications so that business users
can get at the knowledge within them and leverage it. Vendors offer various
approaches to this problem. Ultimately, a corporation must select the approach
that best suits its plans.
Approaches to Java-enable COBOL
While vendors differ in their methods of Java-enabling COBOL, they have a common
goal: to make it easy for programmers. To Java-enable COBOL, you need "people
who are very fluent in Java and new technologies, who also know and understand
the architecture of COBOL applications and mainframe databases, and can do low-level
APIs, which is a very specialized type of coding -- not regular Java or COBOL
coding -- to link the Java and COBOL systems," said Andre Den Haan, vice president
of product strategy at Seagull Software Inc., Atlanta. "To find those three
skills in any one human being is like finding a needle in a haystack."
Essentially, there are three methods of Java-enabling COBOL -- or four, depending
on how you categorize them, said Phil Murphy, a director at Giga Group Inc.,
Cambridge, Mass.
One is to incorporate PC emulation so you have a green screen inside the user's
browser. This gets rid of the need to do fat client installs and lets enterprises
centralize distribution. Murphy calls this GUI on-the-fly, and says it is similar
to "screen scraping except you go to a browser instead of a window."
When GUI on-the-fly is not enough, and organizations want to control the user
interface more, they select screen scraping tools. These provide a richer interface
than GUI on-the-fly, letting developers add radio buttons and features like
the ability to navigate through a number of screens, and combine many-to-one
(combining elements from several screens into a single browser) and one-to-many,
explained Murphy.
The next level in Murphy's view is componentization of a COBOL application.
Some vendors take just the part of a screen the customer will look up and wrap
it as some sort of component -- EJB, COM, or something else -- and make it available
for someone else to invoke, noted Murphy.
A refinement of this process is to treat every component in an application
as an object, assuming that the corporation will re-combine the different components
of an application and later get rid of some of them, said Murphy. If every component
is made into an object, the user corporation just has to redirect the application
to point to somewhere else when the components are eliminated. Tools like this
are helpful if the corporation's goal is to migrate to another platform over
the long term, he added. Many of them have a three-tier architecture and include
load balancing and failover. Some are virtual servers "so the server component
sits on the host machine and is, therefore, far more scalable than an NT box
or several dozen NT boxes," said Murphy.
Finally, according to Murphy, there is the invasive approach, where a developer
goes into the COBOL code and, using software that identifies business rules,
takes out the conditional logic from these as the business rules, wrappers them
and invokes them -- "going well beyond recompile."
Dale Vecchio, research director for application development at Gartner Inc.,
Stamford, Conn., has a different take on the methodologies. For him, there are
three approaches. One is more development-centered; the second is using an adapter
or connector; and the third is using XML, an approach that will "soon be superseded"
by Web services, he said.
The development-centered approach involves either direct Java-to-COBOL programming
to make a connection or a transformation. But that poses its own problems. "If
you're dealing with mainframe COBOL and are looking to do some development on
the mainframe to deal with that, you're dealing with language issues on the
mainframe," said Vecchio. "You cannot call COBOL from Java; you need to use
an intermediary."
The adapter/connector approach, which employs a calling mechanism that extracts
information from a legacy system, lets programmers do new development in Java
Integrated Development Environments (IDEs) or Microsoft Visual Basic, noted
Vecchio. It leaves the legacy code intact. This method can be used if the application
was designed for a machine interface, and is often used for CICS transactions
developed for use with dumb terminals, he added.
The advantage of the adapter/connector approach is that it is "easy, relatively
un-complex and it's non-invasive, so people use it, particularly if they're
building an interactive system," Vecchio said. However, there are performance
and reliability issues with adapters and screen scrapers -- connections can
be brittle in mid-transmission, so users need a good error recovery mechanism,
for instance, he added. That brittleness of the connection makes things harder
if data is being sourced from multiple legacy resources, he said.
The third approach -- using XML as a connection mechanism, generating XML messages
out of the mainframe and using those -- will be history once Web services come
into being, said Vecchio. That takes this approach out of the picture.
The players
LegacyJ Corp., San Jose, Calif., has patented a method of compiling COBOL
code in a Java virtual machine (JVM). "We just want you to do compiling without
any code change," said company president Charles Townsend. "If you were to convert
or migrate the data, you'd have major implementation costs; if you just do a
compile, the cost is relegated to basically a test function instead of re-coding."
For example, LegacyJ customer Walker Interactive Systems Inc., an e-business
solutions provider based in San Francisco, wanted to redo a mainframe-based
legacy financial package to be platform-independent and work in EJBs. The app
had 2 million lines of code and more than 1,000 modules, said Townsend. Using
LegacyJ's tools, Walker "went through all their code in about a month in the
first pass, and then it was just a matter of testing to make sure the code is
doing what it's designed to do," Townsend said.
LegacyJ's flagship tool, PERCobol, is a COBOL compiler for mission-critical
business applications. It is ANSI 1985 X3.23b standard-compliant and it supports
most vendors' flavors of COBOL. The product can be integrated with existing
COBOL applications, or it can execute independent of any COBOL compilers or
runtimes. It is 64-bit enabled, object-oriented, multithreaded and graphical
so it can create graphical screens.
PERCobol lets developers compile COBOL programs with little or no changes and
execute in the JVM. It takes business logic as expressed in COBOL and lets this
logic morph into Java applications, servlets, applets or JavaBeans. Some capabilities
require adding programmatic extensions while others are automatically generated
by the PERCobol compiler and supported through the PERCobol runtime libraries.
PERCobol also supports MQSeries, CICS clients, Network File System (NFS) and
Secure Socket Layer (SSL), which are among the functions needed for enterprise
and distributed computing.
While using PERCobol makes things much easier, a lot of work is still needed.
"There's no magic here; if you have a couple of thousand modules that need to
be recompiled, you have to go through the process," said Townsend. The latest
release -- PERCobol 2.7 -- supports parsing XML.
Java-enabling COBOL code is not really about Java, said Ian Archbell, vice
president and director of product development at Micro Focus International,
Rockville, Md. Instead, it's about minimizing the cost of development in legacy
environments, Web-enabling legacy applications without changing them on the
host, being able to take and enhance strategic applications, and being able
to interact with Java in a new technological environment, particularly application
servers and Netscape iPlanet, BEA WebLogic and IBM WebSphere, he said.
Micro Focus offers Net Express and Server Express. Net Express is a product
for the Windows platform that lets corporations automatically wrap COBOL applications
as Enterprise JavaBeans or as COM objects. Server Express is an IDE for creating
COBOL applications on various flavors of Unix. The latest version of Server
Express, v2.0.1.1, lets customers deploy new Web applications created using
wizards in Micro Focus Net Express.
Micro Focus also offers the Enterprise Link Generator. This lets users turn
CICS transactions into EJBs, either one at a time or several together. If, for
example, a customer update function consists of three separate CICS transactions,
Link Generator lets developers automate the selection of those transactions
and generate a new composite application with a new CICS transaction on the
mainframe wrappering the existing transaction, which remains unchanged.
Link Generator also generates linkages to MQSeries on the mainframe and, if
the user's system goes to a middle tier, it generates an EJB on that tier and
a JavaServer Page, which interfaces back to MQSeries. "The COBOL guys who do
this don't need to know any Java. And if you're now exposing an EJB, which you
put on your palette of EJBs in a Java development environment, the person doing
that doesn't need a knowledge of the mainframe environment," said Archbell.
That's important because "most of our customers have this cultural divide where
COBOL developers have plenty of gray hairs and business knowledge and Java guys
have plenty of technical knowledge, but in many cases do not have a massive
understanding of the business."
Seagull Software wraps Java around COBOL with its Transidiom tool. Transidiom
lets business analysts or COBOL programmers automatically generate XML, Java
and COM interfaces because it transforms mainframe and 5250 business functions
into components with callable XML, Java and/or COM interfaces that can easily
be integrated with new applications. Using Transidiom, business analysts or
COBOL programmers can record any given user task or business process they perform,
generate the interfaces, then hand these to Java developers who "can write very
cool Java applications very quickly because they have a set of JavaBeans at
their disposal that represent all sorts of core business functions," said the
company's Den Haan. This technique has "proved very efficient and successful,"
noted Den Haan, adding that Seagull has an insurance company client that has
created JavaBeans for a set of about 50 COBOL applications and built "a cool
new self-service application on JavaServers using those 50 JavaBeans."
The Java wrappers act as a shock absorption layer when the IT department performs
maintenance on the back-end COBOL code, explained Den Haan. "As long as you
can implement or keep the external interface the same, you do not need to have
any changes rippling through into your front-end applications; they can stay
the same."
"When you change your COBOL applications, you just need to make sure the connection
between the external Java interface and the COBOL application gets adjusted
accordingly" and using tools like Transidiom "makes that a five-minute effort,"
according to Den Haan. That's because the presentation logic is decoupled from
the business logic and the database when Transidiom is used to build applications.
"What remains on the mainframe is the COBOL application with business logic
and the database, and you have a reusable external interface that can be reused
for many different functions and purposes."
Although there are several methods of Java-enabling COBOL code, selecting the
right one for your organization is much easier than it looks. Just ask yourself
whether or not the approach suits your business plans and makes sense for your
business.
Related story: Plan ahead
Before implementing a solution to Java-enable your COBOL code, draw up plans
so that you know where you want to go and how you want to get there before you
even begin doing anything else. And don't fall into the common trap of looking
at the situation from the perspective of what you can do with your existing
application.
"The best approach so far, across the board, is to make a design or a model
of the new application that you need to build, so you approach it from what
the new application will do, instead of what your COBOL application can do today,"
said Andre Den Haan, vice president of product strategy at Seagull Software
Inc., Atlanta. That model will let you easily identify which modules, which
objects and which functions you will need to build the new application. Once
you have the interfaces and the requirements for the objects you need, it will
be "a fairly easy task" to map them to existing functionalities in your COBOL
application, Den Haan added.
If you approach things from the viewpoint of your existing COBOL application's
capabilities, you may find that your Java developers "may develop something
that's not quite what you need" and re-doing this will take "a lot of work,"
noted Den Haan.
After you have drawn up your model for the new application, you can select
whether you will implement objects yourself natively in Java or implement them
by wrapping COBOL code with Java. This approach gives you the ability to switch
the implementation of certain objects later, Den Haan said. "Today, certain
objects may go back to a COBOL application, and tomorrow you may replace that
object with a piece of Java code that handles that specific function all by
itself. That's another part of the power of coming at an application from the
perspective of what the new application will be, rather than what your COBOL
code can do now," said Den Haan.
Related Story: Questions to consider
While it's relatively simple to figure out which approach to Java-enabling
COBOL code works best for your corporation, selecting the solution itself requires
some careful thought.
LegacyJ Corp., San Jose, Calif., suggests that users consider the following
points: accessibility, reliability, extendibility, maintainability and security.
For accessibility, ask yourself: Does the solution provide access to my COBOL
business process? And will it require external middleware to access existing
processes?
For reliability, does the solution fit within a reliable supported infrastructure?
Will it use established technology, or does it require homegrown extensions
to fully use the functions the vendor advertises?
For extendibility, can the solution be easily extended using an industry standard
model? If the extension is Java, is it a standard Java capability? If it's a
browser plug-in, does it adhere to browser guidelines?
For maintainability, does the solution fit within a defined coding and deployment
process? Are the maintenance procedures consistent with similar processes for
deploying updates or enhancements?
For security, does the solution maintain or reduce the level of security established
for the execution environment? Does it introduce a back door or another mechanism
where security can be breached?