Integrating Java EE applications and C-based implementations in WebSphere Application Server

The Java™ Native Interface (JNI) is a programming framework that enables Java code running in a Java Virtual Machine (JVM) to call and to be called by native applications and libraries written in other languages such as C, C++ and assembly. This article describes how developers can leverage this framework to integrate their J2EE™ applications deployed on IBM® WebSphere® Application Server with these C libraries. This content is part of the IBM WebSphere Developer Technical Journal.

Sharad Chandra (schandr1@in.ibm.com), Senior WebSphere Consultant, IBM

Author photoSharad Chandra is working as Senior WebSphere Consultant in IBM Software Group. He has 8 years of experience on BPM and SOA technologies and a versatile background in handling complex customer solutions related to BPM and middleware technologies.



14 March 2012

Also available in Chinese Russian

Introduction

IBM® WebSphere® Application Server is a Java® EE 6 compatible, robust, and highly available middleware environment that provides a platform for hosting and managing a variety of enterprise applications. Some users may encounter scenarios in which they will need to integrate their Java-based applications with native C/C++ based implementations. For example, applications involving defence, aerospace, weather forecasting, and other scientific applications contain certain algorithms that can only be implemented using these native languages and are either too complex, too difficult, or too risky to implement in Java.

To integrate such C-based implementations with Java programs, you need to put some sort of bridge in place between the two programming language APIs. Java Native Interface (JNI) provides this bridge to exchange data between Java and C/C++ APIs. To achieve this solution, you need to define the interface in Java with the methods you wants to expose to other Java classes, generate a header file out of the compiled code of this interface, and then import the header file in native shared library modules, such as Dynamic Link Libraries (.dll) for Windows® and Shared Object (.so) libraries for UNIX®-based systems. These modules can be created through a variety of tools provided by a number of vendors.

This article describes steps that will ease the integration of Java-based applications deployed on WebSphere Application Server with C-based implementations through Java Native Interfaces (JNI). At the end, you will be able to create, configure, and invoke shared libraries for WebSphere Application Server.

The information included here applies to IBM WebSphere Application Server V6.1, V7, and V8 and assumes familiarity with the corresponding IBM Rational® tooling. Be aware that the examples presented here are very basic to illustrate the high level development procedure involved, and do not address data validation or other good practices that would otherwise ordinarily be included in typical application development.


Creating native shared libraries

  1. Open IBM Integration Designer and create a standalone Java project (Figure 1).
    Figure 1. Create standalone project
    Figure 1. Create standalone project
  2. Create a Java class with the methods that you want to associate with native methods (Figure 2). The method declarations will be dependent on the signature of the C methods you want to invoke. In this case, the assumption is that a third party C API requires simple type and an array of data (in this case, a double array). (To invoke another native library, you need to associate it with your DLL by importing its header file during header Implementation.)
    Figure 2. Create Java class
    Figure 2. Create Java class
  3. Compile the Java interface and run the javah command on the .class file generated from the compilation in the {APPSERVER_ROOT}/Java/bin directory to generate the respective C header files (Figure 3).

    <APPSERVER_ROOT>java\bin>javah -o header_file_name.h <JAVA_CLASS_NAME>

    Figure 3. Generate C header files
    Figure 3. Generate C header files
  4. Next, you need to use the methods generated in the header file to create a native shared library. It is this library implementation that you can integrate with other C libraries during C API to C API calls (Figure 4).
    Figure 4. Java header file code
    Figure 4. Java header file code
  5. The header code shown in Figure 4 needs to be copied into a shared library project to generate a .dll or .so library . You can use any C/C++ editor to create these shared libraries. A DLL project has a header (.h file, Figure 5) and implementation (.c file, Figure 6) sections apart from other sections, depending on the editor you are using.
    Figure 5. Copying Java header file code into dll project header section
    Figure 5. Copying Java header file code into dll project header section
    Figure 6. Implementation of Java header methods in Implementation section
    Figure 6. Implementation of Java header methods in Implementation section
  6. Notice that jni.h is available in the Java runtime include directory in WebSphere Application Server at {APPSERVER_ROOT}/Java/include (Figure 7).
    Figure 7. Location of jni.h in WebSphere.
    Figure 7. Location of jni.h in WebSphere

Keeping in mind that jni.h needs to be referred to when compiling the Java header code in the DLL module, you can copy this file from the {APPSERVER_ROOT}/java/include directory to the C editor location and place it in the include path that will ensure successful compilation of DLL. When the DLL is generated, you can copy the file to the appropriate location in WebSphere Application Server.


Configuring native libraries in WebSphere Application Server

To configure a DLL with WebSphere Application Server, copy the DLL into a folder created inside the {APPSERVER_ROOT} directory (Figure 8) and configure its path in the JVM custom properties by navigating to Server > ServerTypes > WebSphere Application Server > server1 > Java and Process Management > Process Definition > Java Virtual Machine > Custom Properties (Figure 9).

Figure 8. New folder for DLL in root directory
Figure 8. New folder for DLL in root directory
Figure 9. JVM custom properties
Figure 9. JVM custom properties

If this JVM custom property is not set in WebSphere Application Server, an exception will result when the class loader tries to load the DLL (Figure 10).

Figure 10. Class loader exception
Figure 10. Class loader exception

After the DLL path is set as a JVM custom property in WebSphere Application Server, the server must be restarted.


Creating Java EE solution to invoke a native library with WebSphere Application Server

To show the invocation of methods defined in the DLL, a servlet deployed in WebSphere Application Server within an EAR file will be used. Before invoking native methods from any Java class, be it standalone or part of an EAR, you need to load it using a System.loadlibrary call in a static block. This way the DLL is loaded during the initial steps of class loading (Figure 11).

Figure 11. Class loading
Figure 11. Class loading

To invoke native methods from Java classes, you must have the native class that you used to generate the header file in the class path. In this example, this class is put in as a JAR file in the WEB-INF/lib directory to enable the servlet to resolve it during run time (Figure 12)..

Figure 12. Invocation of JNI code from Java class
Figure 12. Invocation of JNI code from Java class

After deploying the EAR, you must restart the server, as the servlet is loaded upon startup, which in turn loads the DLL. Because native libraries are loaded in WebSphere Application Server native memory, restarting the server is required; otherwise, you will get an exception saying that the library has already been loaded by another class loader when the servlet is invoked.


Testing the solution

There are two solutions here you can test, one by passing a simple data type to the native method and the other by array:

  • Simple addition test

    In this test, you enter Integer values in the data fields and get a result after the values are added together.

    Figure 13. Simple addition test data entry
    Figure 13. Simple addition test data entry
    Figure 14. Simple addition test result
    Figure 14. Simple addition test result
  • Array data test

    In this test, you enter an array of ten values in the JSP, which in turn will invoke the native method through a servlet that displays the double value of each field in the array.

    Figure 15. Double value array test data entry
    Figure 15. Double value array test data entry
    Figure 16. Double value array test result
    Figure 16. Double value array test result

Conclusion

This article illustrated simplified examples showing how you can integrate Java code running in WebSphere Application Server with C-based implementations by using the C API through JNI (Java Native Interface) by creating a bridge between them through a shared dynamic link library (DLL).


Download

DescriptionNameSize
Code sample1203_chandra_ProjectData.zip16 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Java technology
ArticleID=801044
ArticleTitle=Integrating Java EE applications and C-based implementations in WebSphere Application Server
publish-date=03142012