You need to have the current production version of Java, with version 1.4.1 being the preferred version at this time. After unpacking the distribution (or checking it out of CVS), two parameters need to be set in the sethome.bat (or sethome.sh) files in OpenEMed/config. The first is JAVA_HOME which is the home directory of the JVM being used. The second is TM_HOME which is the directory that OpenEMed is in. Once those two are set, you should be able to run the base applications from the dist/servers and dist/clients directories. Check question #7 for issues on Win95/98/ME. The default ORB is OpenORB and it should use this without further configuration.
OpenEMed is a multi-tier application suite. The servers need to register to the NamingService (and the TradingService, in some cases) in order to be accessible from other applications. That is the clients need to "lookup" the location of the server they want to connect to. Thus minimally you would need to run 3 applications to run OpenEMed, the NamingService, the Pids Server, and the Pids client. The full application also needs a COAS server and a COAS client. In the case of the Java Server Pages webapps, the clients reside as applications under the web server. The PIDS server and COAS server are distinct because they have different functions that are important to separate for performance reasons as well as security reasons. (The TradingService is currently not functional with OpenORB)
The NameService is required for the various servers to be accessible through their names to the other servers. It runs on a particular port (typically 5002). If that port is in use by another application, it will fail with the following message:
org.omg.CORBA.COMM_FAILURE: Unable to listen on /0.0.0.0:5002 (java.net.BindException: Address already in use: JVM_Bind) vmcid: 0x0 minor code: 0 completed: No
at org.openorb.orb.iiop.IIOPTransportServerInitializer.open_port(IIOPTransportServerInitializer.java:197)
at org.openorb.orb.iiop.IIOPTransportServerInitializer.open(IIOPTransportServerInitializer.java:183)
at org.openorb.orb.iiop.IIOPProtocolInitializer.init(IIOPProtocolInitializer.java:258)
at org.openorb.orb.pi.OpenORBInitInfo.post_init(OpenORBInitInfo.java:166)
at org.openorb.orb.config.OpenORBLoader.init(OpenORBLoader.java:231)
at org.openorb.orb.core.ORB.set_parameters(ORB.java:984)
at org.omg.CORBA.ORB.init(ORB.java:337)
at org.openorb.tns.Server$ORBRunner.<init>(Server.java:179)
at org.openorb.tns.Server.main(Server.java:76)
Caused by: java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
at java.net.ServerSocket.bind(ServerSocket.java:309)
at java.net.ServerSocket.<init>(ServerSocket.java:183)
at org.openorb.orb.iiop.IIOPTransportServerInitializer.open_port(IIOPTransportServerInitializer.java:191)
You need to change the argument -ORBiiop.port=5002 to a port that is not in use. This should also be changed in the OpenORB.xml file in the config directlry so that the various servers and clients will know where the NamingService is located. Change the localhost variable to your machine's name that is running the NamingService so that external clients can access it correctly. For more information on this topic read the OpenORB documentation. If you use the Orbacus ORB, you need to read the Orbacus ORB manual for configuring the NamingService.
The OpenORB NamingService application is a transient service that does not preserve the object references beyond the duration of the application. OpenORB supports a persistent namingservice, but we are not using it. If you use the Orbacus ORB, it supports persistent object references in a database:: OrbacusNameService.db. If the machine name or the port number is changed the server will need to reinitialize the database. This is done with the startnamingservice.[bat,sh] file. This will remove all old object references and create a new OrbacusNameService.db. This script file simply adds the initialize argument to the starting script. You can also run the namingservice from ant by running the "nameservice" target. It will determine which ORB is being used and launch the correct application automatically.
The properties file local.properties in the base directory of OpenEMed determines which ORB you are using. The distribution has only the OpenORB, but the CVS repository also contains the relevant Orbacus libraries.
The web clients are distributed through web archive (.war) files as part of the standard Java Server Pages infrastructure. These .war files are built from the OpenEMed/src/clients directory. These .war files then are inserted in the webapps directory of your JSP server and are expanded automatically by the JSP server. The configuration files (mostly property sheets) are in the webapps//WEB-INF/classes directory and normally are edited after installing the .war file. The .war file is built from the the properties files in webapps and the specific jsp files in the webapps sub directories along with the required jar files. You can edit the properties files in the webapps directory before building the .war file, but if you want different configurations, you need to edit the files in the classes directory anyway. We use resin from http://www.caucho.com, but other JSP engines should also work, but you may need to do some minor tweaking because of variations in implementations. There is also a web.zip file that needs to be put in the base library of the JSP engine (lib directory for Resin). This contains common libraries that all the OpenEMed applications need. In the current release of OpenEMed, the war and zip files are not supplied but must be built from source.
Check to make sure that you are connecting to the server you think you should be talking to and that that server is actually running. The NamingService can report a server object reference to a server that is no longer running. You can tell that the server is running if you start up the NamingService Console application application and select the particular PIDS server and then "ping" the server. If it responds you should be able to connect to it. You also may have a secure PIDS server running and the PIDS client may be running insecurely, or vice versa. This will result in a failure to connect. The PIDS client connects through the IOR or the Trading Service. You may need to select the IOR directly and make sure it is the IOR that was written by the PIDS server that is currently running. If the pids server is on a different machine, make sure that the object reference is correct and that it has a correct reference to the remote machine's DNS address.
After running the COAS server and ensuring that it has data in it, run the SimpleCoasClient application in the dist/clients/Coas directory. If you are using the default NamingService be sure the NameService field is blank and that the name of the Coas Server is the same as you registered it into the NamingService. Then you should be able to click the Connect button and connect to the COAS server. It will tell you in the panel whether it was successful. The Info button will give you information on what COAS components are available. You can then get the supported codes and query the COAS server. Make sure that you select a "who" and time span for which the server has data. You can "wildcard" both the "who" and the "what" by giving an incomplete code ending with a "/" character. It will find all the codes that start with the string up to and including the "/". If you uncheck the box by the who, it will wildcard the "who" and ignore that in the query. .
You only need a digital certificate if you are going to run with security turned on. The KeyManager application is designed to help you create and manage your certificates in a keystore. It has full documentation on how to use it. To run with SSL in a web browser, check with your web server's installation guide for using SSL.
OpenEMed may run on this platform, but it isn't recommended because of the limited services available on those platforms. In order to run on those platforms, however, the ORBCLASS variable defined in sethome.bat must be modified because of the limitations of those platforms. In addition, lack of support in .bat files for %* requires those to be changed to explicitly list the arguments "%1 %2 %3", etc. We do not believe that these changes need to be made in the distribution, because of the limitations of that platform. Please let us know if you are able to run it on Win9X and if that really matters to you.