Java and OO COBOL Interoperability Options

Visual COBOL offers a number of different ways in which you can integrate COBOL and Java. Certain methods may require changes to your existing application and some methods may be more suited to certain types of application than others. This topic outlines each method then summarizes the different factors that will influence the method that you choose.

Enterprise Server support for EJBs and Java Beans

Enterprise Server is an application server for COBOL applications. Enterprise Server provides high-performance and also provides mainframe subsystem emulation.

You use the Interface Mapping Toolkit functionality (IMTK) in Visual COBOL to generate an EJB or a J2SE bean which accesses the COBOL application running in Enterprise Server. The bean, in turn, uses a JCA resource adapter deployed into a Java application server.

Restriction:

It is not possible to access Java classes directly from the COBOL application.

For more information, see Tutorial: Interface Mapping Toolkit.

Compiling COBOL application directly to Java byte code

This scenario is suitable for applications that do not require Enterprise Server or any transaction support and when the best possible integration with Java is required.

JVM COBOL compiles to Java byte code which runs directly inside the JVM, providing full integration of COBOL with Java. With this method, Java classes can call existing COBOL applications using a variety of techniques and COBOL applications can also call Java classes or routines provided by the Java SDK.

You must build the JVM COBOL applications on the platform they are deployed to.

Due to the nature of the JVM, COBOL applications are likely to see some reduction in performance in comparison to COBOL applications running outside of the JVM in a regular native environment. The reduction in performance varies from application to application. Heavily intensive batch applications may experience lower performance whereas an interactive application may have no appreciable difference in responsiveness.

It is recommended you conduct some performance testing against your existing application to determine if performance levels will be satisfactory.

For more information, see JVM COBOL Interoperability and the JVM COBOL Tutorials.

Using the COBOL Java Domain and the Java Native Interface (JNI)

The following scenarios are most suitable for desktop applications where you require the highest performance. COBOL runs as native code in the COBOL Server run-time system. To use COBOL and Java together, you code the calls using the supplied support libraries.

These are the approaches for integrating COBOL with Java 2 Standard Edition (J2SE):

Calling procedural COBOL from Java - you use the support provided in the com.microfocus.cobol.RuntimeSystem class. This class is extended to provide the CobolBean class. This RuntimeSystem class support also enables you to call Java from procedural COBOL, through the Java Native Interface (JNI).
Calling Java from native OO COBOL - you use the Java object domain for native OO COBOL via the INVOKE verb.
Calling native OO COBOL from Java - you create a Java wrapper class that provides a function for each method in the native OO COBOL class. See The Wrapper Class.

For more information, see Related Information.

The following is a summary of the technologies supported in each scenario and the mechanisms to integrate your applications with Java:

Table 1. COBOL and Java integration options
	Enterprise Server	Java Byte Code	COBOL Java Domain
Java application server support	Yes, support is available for all popular application servers. See Additional Software Requirements.	Yes. See Additional Software Requirements.	Not available. It is not recommended to use JNI in Java application servers as this is not compliant with the EJB standard.
Database support	ODBC or a supported database vendor precompiler.	JDBC using OpenESQL.	ODBC or a supported database vendor precompiler.
Debug experience	There are different debuggers for Java and COBOL in Eclipse.	It is possible to step between Java and COBOL in Eclipse.	There are different debuggers for Java and COBOL in Eclipse. It is not possible to debug both languages at the same time. You can debug Java independently of COBOL and COBOL independently of Java.
Desktop Java applications	Not a typical usage.	Yes	Yes
EJB support	Yes	Yes	No
File IO transactions	Yes, through Fileshare.	Not available as Fileshare is not supported in a Java application server. Note: Fileshare is supported on the desktop^*.	Yes, through Fileshare.
Fileshare support	Yes	No	Yes
Interoperability mechanism and performance	The COBOL application runs as native code in Enterprise Server. You use the IMTK to generate an EJB or a J2SE bean which accesses the COBOL code and which in turn uses a JCA resource adapter deployed into the Java application server.	The COBOL application is compiled to Java byte code which is directly accessed by Java.	The COBOL application runs as native code and Java is accessed using JNI.
Mainframe subsystem support	Yes	No	No
JEE container managed transaction support	Yes. There is a separate database connection but a coordinated transaction between the application server and Java.	Application-managed transaction support only.	Application-managed transaction support only.
Java SDK access from COBOL	No	Yes, fully supported.	All Java types are supported using the INVOKE verb. If using a native call through the JNI interface, you need to add some extra code. You can use the Micro Focus class library to create user-defined types and mappings.
Web Service endpoint	Yes	Not directly. Java must act as the endpoint and call COBOL.	No