Enterprise JavaBeans from COBOL

When determining alternatives to be used in the creation of Enterprise JavaBeans, there are several points that must be considered.  The Java 2 Enterprise Edition (J2EE) environment like the CICS subsystem places restrictions on functions that can be accomplished within the environment. EJB restrictions are aimed at maintaining performance, stability, security, and scalability.  EJBs containers are designed to verify that these restrictions are enforced. While not all EJB containers verify and report on non-compliant Enterprise JavaBeans, it is critical that any new or existing EJB adhere to these environmental restrictions.

The Challenges

A very important consideration while moving the COBOL application into the J2EE environment is that the EJB not access or use native code. The EJB specification forbids the access or use of native code[1] and states: “The enterprise bean must not attempt to load a native library”[2]. The implication is that COBOL applications cannot use the Java Native Interface (JNI) to access a native COBOL process. All I/O is delegated to the EJB container precluding any direct file access.

Access to native libraries is reserved for the EJB Container not the Enterprise JavaBean. Any usage of native code within an Enterprise JavaBean component always loads a native library and the native code can circumvent Java's security features. Native code can have stack overflows, underflows, bad pointers, etc. which can disruptively modify the Java State, voluntarily or involuntarily.  Fed bad information, native code can be hijacked into supporting viruses or other information.

When automatic verification of EJB compliance is the rule rather than the exception, these applications will cease to function.  The component which looks like an Enterprise JavaBean, but which does not follow the specification may have an adverse effect on other EJBs that have a built-in dependency.  Like any program relying upon undocumented features, it will not necessarily function in any particular environment, present or future.

In addition, loading native code prevents the Enterprise JavaBean from being used in EJB containers, which support Hot Deploy.  Hot deploy is a function where the EJB Component may be deployed into an already running container without rebooting the container.  In Java, a ClassLoader is responsible for loading the executable classes; there is a system ClassLoader and then there are custom ClassLoaders.  Only the system ClassLoader (for classes known when the Java Virtual Machine starts) may load native functions.  Custom ClassLoaders, such as those used for Hot Deploy, will not load native functionality.

An Enterprise JavaBean implemented using native functionality cannot be loaded into a public EJB container.  An EJB container provided by an outside service such as an ISP would not allow native code to be executed in their container, because of the possible security issues and restricting Hot Deploy.  Any public EJB container would need to be restarted to deploy, and reliability of the public container would be at risk with native components.

The native EJB component could abnormally terminate and cause the host EJB Container environment to terminate as well. EJB Components are implemented as threads within only a single process.  Using a single process, Java security prevents malicious or accidental tampering of data, meaning data owned by one component is not exposed to another component.  A native component could access another client's private data or other sensitive information.  No reputable public EJB container would ever knowingly accept an EJB component for deployment using native functionality.

An Enterprise JavaBean implemented in native code would not be subject to full container control.  It is allowable, for instance, for an EJB container to implement failure recovery and load balancing by shifting components from one platform to another.  An EJB container can legitimately shift an EJB component automatically from running on a Sun platform to an IBM platform to a HP platform as each machine is brought down for maintenance or when a particular platform is overloaded.  This process would fail with a native code implementation of a JavaBean; the EJB container could not move native code safely to another machine.  The scalability and fault-tolerance of the EJB specification would also be lost.

Loading native code for an EJB Component is inherently non-portable.  While this should be obvious, it should also be noted.  The portability advantage and cost savings in moving EJB Components from one platform to another would be lost by using a native compiler.

The Enterprise JavaBean framework is an extremely powerful tool for distributed objects.  However, this is a new tool for the COBOL programmer.  Both the programmer and manager should be aware of these facts when selecting a COBOL solution for creating Enterprise JavaBeans.

The Solution

LegacyJ PERCobol is unique among compilers because it compiles COBOL source code, written in a wide variety of vendor-proprietary syntax extensions, into a Java executable that is suitable to run as an EJB, with little or no change to the existing source code.  Only LegacyJ PERCobol allows Enterprise JavaBeans to be written in COBOL with no dependency on native code.  Therefore, using PERCobol to create EJBs  eliminates the need for, and risks associated with, the wrapping approach to modernizing legacy applications. 

Because PERCobol compiled programs run directly in the Java environment, and because Java code is widely portable, the need to use “connector“ technology is eliminated.  Also eliminated are the risks associated with keeping changes to legacy applications, connectors, and the “connected-to“ subsystem perfectly synchronized, protecting users and service level agreements. 

Providing an all Java, thread and session-safe code base to the Enterprise JavaBean container, PERCobol programs adhering to the Enterprise JavaBean guidelines will continue to be usable for as long as your organization uses EJB enabled application servers.