Java and COBOL Interoperability Options

Enterprise Developer 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 Enterprise Developer 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.

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 Enterprise 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.
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