Difference between revisions of "Geneva-The IHE Registration System"

From MircWiki
Jump to navigation Jump to search
Line 67: Line 67:
 
The embedded servlet container is located in <b><tt>Geneva/libraries/util.jar</tt></b>. The source for that library can be obtained as described above, using the module name <b><tt>Util</tt></b>.
 
The embedded servlet container is located in <b><tt>Geneva/libraries/util.jar</tt></b>. The source for that library can be obtained as described above, using the module name <b><tt>Util</tt></b>.
  
The server includes a base servlet which serves files when an HTTP request does not match a known servlet. When serving files, the base servlet first looks on the requested path under the <b><tt>Geneva/ROOT</tt></b> directory. If the file exists, it serves the file from that location. If the file does not exist, it looks on the class path for a resource in the corresponding path in a <b><tt>jar</tt></b> file. If the requested resource is found on the class path, it serves the file directly from its <b><tt>jar</tt></b>; otherwise, it returns an <tt>HTTP NOT_FOUND</tt> response code.
+
The server includes a base servlet which serves files when an HTTP request does not match a known servlet. When serving files, the base servlet first looks on the requested path under the <b><tt>Geneva/ROOT</tt></b> directory. If the file exists, it serves the file from that location. If the file does not exist, it looks on the class path for a resource in the corresponding path in a <b><tt>jar</tt></b> file. If the requested resource is found on the class path, it serves the resource directly from its <b><tt>jar</tt></b>; otherwise, it returns an <tt>HTTP NOT_FOUND</tt> response code.
  
 
If it is desired to modify an HTTP file, and the file cannot be found under the <b><tt>ROOT</tt></b> directory\, look in the <b><tt>Geneva/Geneva.jar</tt></b> file or the <b><tt>Geneva/libraries/util.jar</tt></b> file to see if it is present there. If so, take a copy of the file from the <b><tt>jar</tt></b> file and put it in the corresponding position under the <b><tt>ROOT</tt></b> directory. It can be modified in that location, and it will take precedence over the file in the <b><tt>jar</tt></b>.
 
If it is desired to modify an HTTP file, and the file cannot be found under the <b><tt>ROOT</tt></b> directory\, look in the <b><tt>Geneva/Geneva.jar</tt></b> file or the <b><tt>Geneva/libraries/util.jar</tt></b> file to see if it is present there. If so, take a copy of the file from the <b><tt>jar</tt></b> file and put it in the corresponding position under the <b><tt>ROOT</tt></b> directory. It can be modified in that location, and it will take precedence over the file in the <b><tt>jar</tt></b>.

Revision as of 01:19, 18 January 2010

This article captures information about Geneva, the registration system used in IHE Connectathons and demonstrations. The intended autience for this article is developers working on the project and demonstration participants using the system.

1 Obtaining the Geneva Installer

The Geneva installer is a Java program. Download the program from http://mirc.rsna.org/Geneva/Geneva-installer.jar.

2 Installing the Geneva

To install the program, place the installer on a computer which has the Java 1.6 JRE and run it. The result will be a folder called Geneva containing all the necessary files. (You can put the installer in the root of a drive or in any subfolder. On certain Vista machines, there may be a problem writing into the root of the C drive. If you manually create a folder called JavaPrograms, the installer will automatically find it and offer to install the program there.)

3 Running the Program

To run the program itself, it is best to run it from a command window because that allows you to provide more heap space for large images than the default provided by Java. Launch a command window and enter the command:

java -Xmx256m -jar Geneva.jar

For testing, or for situations which do not require additional heap space, the program can be running by double-clicking the Geneva.jar file.

On initial installation, the program has one user with username admin and password password. The admin user has all privileges, including the ability to create additional users.

4 Servlets and User Accounts

Geneva has an embedded servlet container which has several servlets. Access to the servlets is provided by buttons on the main page of the server. Some servlets require that the user be authenticated. The main page displays those buttons which the user is allowed to access, given the user's roles as assigned by the administrator.

The model underlying the operation of the program is that each vendor will have one user account, with the username being a reasonably short representation of the company name. User accounts can be created and modified through the User Manager servlet, which is available to users whose accounts grant the admin role. Vendor accounts must be given the company role so that they can access the servlets which allow them to create and control configuration elements for their systems.

Note: the shutdown role is not used in Geneva. It can be ignored as there are no servlets which use it.

5 Conventions

Geneva is designed to allow participating vendors to create configuration elements for their systems. To prevent vendors from modifying other vendors' configuration elements, Geneva imposes a convention which applies to the id attributes. Users are only allowed to modify the configuration elements which have id attributes which contain the user's username surrounded by underscores (for example, REP_MYCompany_3. When the Configuration Editor servlet is used to create configuration elements, it automatically creates id attributes which obey this convention. For that reason, if an administrator is creating elements on behalf of a vendor, the administrator should log into the company account, thus ensuring that ids will be created that the company can later modify and control.

The same convention applies to the Control Panel servlet. Vendors can enable or disable configuration elements which, but the convention, they own, but they can see the status of all elements.

Administrators have the capability of editing and controlling all elements.

6 Obtaining the Geneva Source Code

The software for the program is open source. It is released under the RSNA Public License. It is maintained on a CVS server at RSNA headquarters. To obtain the source code, configure a CVS client as follows:

Protocol:           Password server (:pserver)
Server:             mirc.rsna.org
Port:               2401
Repository folder:  /RSNA
User name:          cvs-reader
Password:           cvs-reader
Module:             Geneva

Together, this results in the following CVSROOT (which is constructed automatically if you use something like Tortoise-CVS on a Windows system):

:pserver:cvs-reader@mirc.rsna.org:2401/RSNA

This account has read privileges, but it cannot write into the repository, so it can check out but not commit. If you wish to be able to commit software to the CVS library, contact the project manager.

7 Building the Software

When you check out the Geneva module from CVS, you obtain a directory tree full of the sources and libraries for building the program. The top of the directory tree is Geneva. It contains several subdirectories. The source code is in the source directory, which has two child directories, one each for the Java sources and the files required by the program.

Building Geneva requires the Java 1.6 JDK.

The Ant build file for Geneva is in the Geneva directory and is called build.xml. To build the software on a Windows system, launch a command window, navigate to the Geneva directory, and enter ant all. This does a clean build. On a reasonably fast computer, a clean build takes about five seconds. The result is a file called Geneva-installer.jar in the products directory.

8 Notes

The following are random notes to help developers.

8.1 The users.xml File

The user accounts are stored in the Geneva/users.xml file.

8.2 The libraries Directory

Geneva contains a special class loader which automatically finds jar files which are located in the Geneva/libraries directory. When extending Geneva with classes in other jar files, it is not necessary to modify the class path in the Geneva.jar file. The jar files can simply be put in the libraries directory.

8.3 The Servlet Container

The embedded servlet container is located in Geneva/libraries/util.jar. The source for that library can be obtained as described above, using the module name Util.

The server includes a base servlet which serves files when an HTTP request does not match a known servlet. When serving files, the base servlet first looks on the requested path under the Geneva/ROOT directory. If the file exists, it serves the file from that location. If the file does not exist, it looks on the class path for a resource in the corresponding path in a jar file. If the requested resource is found on the class path, it serves the resource directly from its jar; otherwise, it returns an HTTP NOT_FOUND response code.

If it is desired to modify an HTTP file, and the file cannot be found under the ROOT directory\, look in the Geneva/Geneva.jar file or the Geneva/libraries/util.jar file to see if it is present there. If so, take a copy of the file from the jar file and put it in the corresponding position under the ROOT directory. It can be modified in that location, and it will take precedence over the file in the jar.

8.4 Class hierarchy

The products and data objects which appear in a demonstration are reflected in classes which are organized as in this list:

  • ConfigElement
    • Product
      • DataSystem
        • EHRSystem
          • DCMSystem
        • PDQMgr
        • PIXMgr
          • Registry
      • Repository
    • Study
    • DocSet

The apparent oddity of a Registry being a subclass of a PIXMgr is an artifact of both having the same functionality in the context of Geneva.