The following diagram shows the components used by the Java RFC Class Library when using the JNI middleware.

The arrows show the flow of communication from your application all the way to the R/3 Application server and back.

Notes on the above illustration:

• Your Java Client or Server Application represents the program that uses the Java RFC to communicate with R/3. It can be an RFC client application (meaning that it issues RFC function calls to an R/3 application) or it can be an RFC server application (meaning that it can accept RFC function calls from an R/3 application).

• The Java RFC Class Library layer represents the exposed interfaces and their implementation classes of the Java RFC packages.
• The Java RFC packages encapsulate the RFC API and the RFC C++ Class Library. The RFC C++ Class Library is bundled with Java RFC. The RFC API is part of the SAP Presentation CD.
• The Java RFC Native DLL component is the SAP middleware implementation of JNI. It is also bundled with the Java RFC.

As you can see from the above illustration, all the components that participate in providing the Java RFC interfaces when using the JNI middleware implementation reside on the same computer.

Therefore, the JNI middleware implementation does not allow for distributed computing. You cannot distribute your RFC application to different computers, and you cannot use it to implement Java applets that make RFC calls.

On the other hand, the JNI middleware is easier to use.

Because less communications needs to take place between various internal components (as with the arrangement of the Orbix client and server components), the JNI middleware implementation is more efficient to use if you do not need to distribute your application.

The JNI implementation is appropriate for creating Web server-side applications that make RFC calls to R/3. In this scenario you install all the Java RFC components on the Web server computer.