EJB programming & troubleshooting: Invoking J2EE from Standalone JVM

  1. Invoking J2EE from Standalone JVM (3 messages)

    We are having the application which consists of EJBs that are running under IBM Webspher Application Server and components that are as a standalone Java appliucations running as CORBA servers. Can som one recomend the good way to communicate to EJBs from Standalone Java applications not using WebServices.
  2. Invoking J2EE from Standalone JVM[ Go to top ]

    It should be easy to invoke them as a CORBA service.

    Why not ?
  3. Invoking J2EE from Standalone JVM[ Go to top ]

    It is not actually that easy. It is probably easy when invoking client is C++ application - apply java2iiop, get IDLSs, generate C++ from those idls. Compile and use it.

    But it is not possible to use those IDLs for JAVA client becuase java2iiop generates them in a funny way - so that after you apply idl2java generated Java files are not compiled. I looked inside those IDLs and I noticed that there was a bunch of structures generated for java.lang package. I did not find the right way to generate IDLs without those java.lang classes.

    To solve that problem I invoked that EJB using CORBA Dynamic invokation interface. This solution is not the best because the code to locate InitialContext is specific for WebSphere Application server - no gurantee that the same code will work for other app server. If some method that we invoke will change in EJB Remote Interface we will need to change the code.

    Tha is why I am searching for the better solution.
  4. I was facing a similar problem recently - we are forced to use 4-tier architecture, where presentation and business logic are hosted in different containers from different vendors (SAP Enterprise Portal on SAP Web AS and IBM WebSphere, respectively).

       There are several ways to call EJBs from standalone Java clients (that are also applicable to calling EJBs from presentation logic residing in a different container). Some of them are:

    1. Over RMI, if your CORBA implementation classes are compatible on both calling and server sides. This can be done from a standalone client running in a J2EE application client environment provided by your EJB container vendor.
       If you don't have a luxury of running your client code in a J2EE application client environment (we didn't), you might be able to achieve interoperability using recent versions of JDK on client and server sides. In our case, a J2SE application working on top of Sun JDK 1.4 (not 1.3!) was able to call EJBs hosted in WebSphere 5.1 using standard Sun RMI/CORBA implementation classes (com.sun.jndi.cosnaming.CNCtxFactory).
       Performance-wise, of course, RMI is better than HTTP - if you can use it (we couldn't, since SAP Enterprise Portal uses its own CORBA implementation classes that do not interop with those of IBM).

    2. CORBA is definitely possible, but I don't think it is a very natural approach to communicate between client and server side when both are Java-based.

    3. Over HTTP, Web Services (possibly with JAX-RPC) will obviously work, but present a certain overhead. I believe you have rejected this solution.

    4. Another way to call EJBs over HTTP is a servlet bridge. It works nicely, especially if you use dynamic proxies on the client side (clients can call remote services and get application exceptions transparently) and dynamic EJB invocation (via reflection) on the server side - this allows you to have a single "gateway" to any EJB in your application that you never have to recompile. Also, unlike with RMI, you don't have to have any EJB-specific stubs on the client side, just the remote interface.

       The full solution for a generic servlet bridge is given in the "Bitter EJB" book by Bruce Tate, Mike Clark, Bob Lee and Patric Linskey: See it on Amazon.com
       There is also a relevant thread on TSS discussing EJB dynamic invocation: Strategy: Using reflection to invoke EJB

       Note, however, that if you are not running your stand-alone client in a J2EE application client environment, you are not going to be able to keep transactional and security contexts initiated on the client. This might not be a concern for you, otherwise there are always design walkarounds.