In-Depth

Re-energizing COBOL with Java

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?

Most   Popular