J2EE Based Web-Interface Development Framework for Clinical Imaging Databases
Total Page:16
File Type:pdf, Size:1020Kb
J2EE based Web-Interface Development Framework for Clinical Imaging Databases I. Burak Ozyurt November 20, 2003 Contents 1 Overall Architecture 3 2 Presentation Layer 5 2.1 Struts Overview . 5 2.2 Struts Controller and Form Validation Interactions . 5 2.3 Struts Application Initialization . 6 3 Session Facade Layer 9 3.1 Data Maintenance Example - Subject/Visit Management . 9 4 Data Access Layer 14 4.1 Object-to-Relational Mapping . 14 4.1.1 Data Access Objects . 14 4.2 Code Generation . 15 5 Assessment Query Builder 16 6 SRB-Database interaction 18 A Getting and Building J2EE based web interface for local clinical imaging databases 23 A.1 Prerequisites . 23 A.2 Getting the code . 23 A.3 Preparation for build . 23 A.4 Build and Deploy . 24 A.5 Running web user interface . 24 B Struts configuration file 25 C Simple O/R Mapping Tool Help 30 C.1 Main Screen . 30 C.2 Schema Extraction . 30 C.3 Custom Code in Generated Java Code and Code Regeneration . 33 D Database Security 34 D.1 Virtual Private Database . 34 D.2 Oracle Label Security . 34 1 List of Figures 1.1 High level architecture of UCSD Human Imaging Database User Interface . 3 1.2 High level class diagram for server side service framework . 4 2.1 User-Struts-Application Interactions for web-tier side form validation and action pro- cessing............................................ 6 2.2 Struts actions for UCSD web interface . 7 2.3 Servlet container-Struts initialization sequence diagram . 8 3.1 Class Diagram for Session Facade Layer interfaces and their implementations . 10 3.2 Selecting a score Struts action sequence diagram . 11 3.3 Get matching subjects sequence diagram . 12 3.4 Adding a visit for a subject sequence diagram . 13 5.1 High level sequence diagram for assessment query building use case . 17 6.1 SRB-JARGON based image data retrieval and on-the-fly image conversion sequence diagram . 19 6.2 SRB Scommand based image series download and AFNI conversion sequence diagram 19 6.3 Clinical Assessment Selection Screen . 20 6.4 Assessment score Selection Screen . 20 6.5 Assessment Query Criteria selection . 21 6.6 Assessment score Selection Screen . 21 6.7 Subject Visit Info Screen . 22 C.1 Database connection parameters dialog . 31 C.2 Database connection parameters dialog . 31 C.3 Code Generator user interface look after code generation . 32 2 Chapter 1 Overall Architecture The UCSD morphometric human imaging database user interface is a three tier J2EE (Java 2 Platform Enterprise Edition) application. The overall architecture is shown in Figure 1.1. It has a (thin) client tier, a middle tier (servlet/JSP based) using Jakarta Struts web framework [Cav02] and an enterprise information source (EIS) tier. The client tier consists of a web browser. The EIS tier is the Oracle database instance and the collection of stored procedures/functions and packages for low level data access functions and optimizing hot spot queries. The middle tier currently consists of a web tier tier only. For large applications a server com- ponent framework like enterprise Java Beans (EJB) provides scalability, however foreseeable scope does not justify an EJB container. The underlying web application framework used for user interface is Jakarta Struts [Cav02] which is a Model 2 architecture based on model-view-controller (MVC) design pattern [GHJV94]. Struts uses a controller servlet (see front controller design pattern [ACM01] and command design pattern [GHJV94]) to intercept a web request and determine what to display next. It also provides tag libraries for JSPs, validation, internationalization and error handling support. Figure 1.1: High level architecture of UCSD Human Imaging Database User Interface. The MVC design pattern allows decoupling of presentation logic from the business logic. Here, the business logic is defined as the code manipulating business data (e.g. clinical assessments) relevant to the application. The presentation logic is the code preparing the data provided by 3 the business logic for display to the user of the application. The decoupling provides flexibility in presentation layer selection and development responsibility separation. In the UCSD human imaging database, the business logic is further decoupled by the use of code-generated data access objects (DAO) [ACM01]. The DAOs can be seen as an object-relational mapping, since they map database tables to objects. They provide a data access layer, which is not directly accessed by the presentation layer to reduce inter-layer dependency. The DAOs provide CRUD (create, read update and delete) operations on database table level and are fine grained. The presentation layer communicates with the data access layer through session facades [ACM01], which coordinate operations between multiple DAOs in a workflow and provide a coarse grained simpler interface hiding the internals of the business logic from the presentation layer. The data transfer between presentation and data access layer is via coarse grained transfer objects (value objects) [ACM01]. The business logic layer also serves data import/export and conditioning clients which map subject data to the Oracle tables by doing necessary data cleaning, combining and transformation, which are not part of web user interface. Currently clinical assessment and visit data upload is supported. Besides the business logic, application level authentication, authorization and database connec- tion pooling services are needed. In order to be able to easily replace these services with different mechanisms, the abstract factory design pattern [GHJV94] is used. In Figure 1.2, the high level class diagram for the server side service framework for UCSD human imaging database in unified modeling language (UML) format [BRJ97] is shown. Here the ServiceFactory class creates the classes implementing the security and database connection pooling interfaces. However it returns only the interface to the service requesting client. The interfaces are the only means by which the layers communicate with each other. Even when the implementation of the interfaces change drastically over time, if the interfaces remain same, the layers can talk with each other. To support label security, a non-traditional connection pool is developed allowing named user support. Figure 1.2: High level class diagram for server side service framework. 4 Chapter 2 Presentation Layer 2.1 Struts Overview Struts is a presentation framework for building web application using Java Servlets and JSPs. Struts uses the JSP Model 2 architecture which is based upon Model-View-Controller (MVC) design pattern (also known as Observer) [GHJV94]. In the model 2 architecture, the client request is first intercepted by a controller servlet which handles the initial processing of the request and determines which JSP page to display next. 2.2 Struts Controller and Form Validation Interactions In Struts there is one controller servlet ActionServlet, which acts like a command dispatcher. ActionServlet delegates the request processing to the corresponding command, an Action class which is extendended from org.apache.struts.action.Action which has an execute() method that needs to be implemented to process the user request and depending on the outcome of the user request processing, needs to determine the next action. The ActionServlet determines which action to pick, by reading it from a XML-based configuration file ( struts-config.xml ). The Struts config file used for UCSD Morph BIRN web interface is shown in Appendix B). The actions are declared in the <action-mappings> section of the struts-config.xml file. Struts passes the submitted HTML form parameters to the execute() method via an ActionForm which it populates from the received HTTP request. Below is an action declaration from struts-config.xml file. <action path="/selectscores" type="clinical.web.actions.SelectScoresAction" name="asSelectForm" scope="session" input="/pages/SelScore_full.jsp"> <forward name="success" path="/pages/SelectDerived_full.jsp" /> </action> Here path is the name of the action, type is the fully qualified Java class name for the class that extends org.apache.struts.action.Action. The attribute name is the name of the form bean associated with this action. The form beans extend org.apache.struts.action.ActionForm and are declared in the <form-beans> section of the struts-config.xml. The attribute scope is used to identify the scope in which the form bean is placed. It can be request or session. The attribute input is the application-relative path to the input form to which control should be returned if a validation error is encountered. The forward elements are used to declare the possible next pages 5 Figure 2.1: User-Struts-Application Interactions for web-tier side form validation and action pro- cessing. this action will return to the user. Here name is a unique identifier used to reference this forward in the application. In the execute() of the Struts action, this name is used to select and return the ActionForward class. The path attribute is an application relative URI to which the control should be forwarded or redirected. The org.apache.struts.action.ActionForm provides form data validation support using Tem- plate Method Design pattern [GHJV94]. A class extending the ActionForm can provide implemen- tation of validate() method which can check the fields to be set by the user. If any requires data is missing or the user has entered incorrect data, the validate() method returns an ActionErrors class containing validation errors, which results in forwarding back to the same input form with validation errors shown, so that the user can correct them and resubmit the HTML form. Only after all validation errors are corrected, the execute() method on the corresponding Action class is called. (See Figure 2.1). The currently available Struts actions for UCSD Morph-BIRN web interface is shown in Fig- ure 2.2. 2.3 Struts Application Initialization Struts allows application plugins for application life cycle management support.