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 and
Deploying a Java Service Interface and Using Resource Adapters
.
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
Managed 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 runtime. 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 OO COBOL - you use the Java object domain for OO COBOL via the INVOKE verb.
- Calling OO COBOL from Java - you create a Java wrapper class that provides a function for each method in the 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
|
* On the desktop, file handling uses the "native" file handler which supports Fileshare. In a server environment such as Java EE, however,
Visual COBOL uses the managed file handler which has no support for Fileshare, ACU, or RM files.
