RIP: RMI In-Process

RMI In-Process mode uses the ENOVIA Live Collaboration Server implementation classes, but instead of going through a registry and invoking a separate process, the server classes are loaded directly into the client's address space. Instead of communicating with the ENOVIA Live Collaboration Server, ENOVIA Live Collaboration actually links with it, removing the RMI marshalling/unmarshalling and the need for the additional RMI (daemon) process. Database communication is directly between the ENOVIA client and the database. This should be notably more efficient in situations that involve processing an extremely large number of transactions.

The other configuration option, RMI Gateway provides load balancing by using multiple ENOVIA Live Collaboration Server processes to handle requests. Since RIP does not use multiple ENOVIA Live Collaboration Servers, load balancing can be accomplished by running multiple Application Servers for each CPU.

The key to a successful deployment is access to the classes and properties required. For RIP RMI mode, this is easily handled by the J2EE archive file since the Application Server, the ENOVIA Live Collaboration Server, and the Live Collaboration kernel all share a JVM.

For non-RIP RMI, the correct classpath is defined at runtime by rmireg, using ComputedClassPath. Refer to the description of MX_CLASSPATH in Configuring the ENOVIA Live Collaboration Server for details. During J2EE deployment with non-RIP RMI, all of the jars in the war file are copied to SERVERHOME/PLATFORM/docs/javaserver/ (UNIX) or SERVER_INSTALL\PLATFORM\docs\javaserver\ (Windows). The framework.properties file is copied to SERVERHOME/managed/properties/ (UNIX) or SERVER_INSTALL\managed\properties\ (Windows). This is to ensure that JPOs have access to them.