Medical Records 1.0
Copyright 1999, 2000, 2001, 2002 and 2003 BEA Systems, Inc. All Rights Reserved.
Restricted Rights Legend
This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior consent, in writing, from BEA Systems, Inc.
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the
BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer
Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software--Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent.
Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING
WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.
Trademarks or Service Marks:
BEA, WebLogic, Tuxedo, and Jolt are registered trademarks, and How Business Becomes
E-Business, BEA WebLogic E-Business Platform, BEA Builder, BEA eLink, BEA WebLogic Enterprise, BEA WebLogic Express, BEA WebLogic Integration, BEA WebLogic Personalization Server, BEA WebLogic Portal, and BEA WebLogic Server are trademarks of BEA Systems, Inc.
All other product names may be trademarks of the companies
with which they are associated.
Table of Contents
The Avitek Medical Records sample application (MedRec) is designed and implemented following the traditional three tier architecture model in which the client, server and datastore are independent from one another:
The sections that follow describe each tier in more detail.
The following is a Visio document provides a high-level diagram of MedRecís application architecture:
The following table contains high-level diagrams for each application that makes up MedRec.
Table 1† High-Level Sub-system Diagrams (Requires Microsoft Visio Viewer)
Shows the interaction of components in the administration application of MedRec.
Shows the interaction of components in the patient application of MedRec.
Shows the interaction of components in the physician application of MedRec.
The Presentation Tier is responsible for gathering and displaying application data, and provides the overall user experience for the MedRec application.
This section outlines design considerations for MedRecís Presentation Tier architecture.† These objectives are the basis for all Presentation Tier design decisions:
The most important design consideration for the Presentation Tier is that it be robust enough to handle high volumes of simultaneous requests.† At the same time, the Presentation Tier must be small in size to manage resource usage.
Extendable, yet maintainable
The design of the Presentation Tier must allow for extensibility, while not compromising maintainability.† This requires that the tier be modular so that changes can be made to a particular component or set of components without having to modify other parts of the application that are irrelevant to the desired functionality.† In addition, creating new presentation features must be a pluggable exercise where new components are easily incorporated without changing the foundation or peer components.
Minimize application interdependence
The Presentation Tier must be designed so that inter-tier communication is limited only to the necessities.† Similar to the Extendable yet maintainable objective, tier partitioning is crucial so that changes to dependent tiers are contained and do not have widespread influence.
The Presentation Tier consists of several different clients, each with their unique set of users and usage scenarios.† The Presentation Tier must provide avenues to the MedRec application in order to serve these demands.
The first version of MedRec focuses on a HTML-based client.† Users make HTTP requests to, and interpret responses from, the Presentation Tier using a browser.† This type of client is commonly referred to as a Web Application or webapp.
MedRec consists of two different Web Applications: one that provides MedRec administration controls and one that provides controls for MedRecís patient users.
In order to meet the architectural design requirements, a Web Application framework is used to logically combine common Presentation Tier functionality into components.† These components are the building blocks for the application.
The following section explains proven Web Application design concepts and introduces the framework called Struts, on which all of the MedRec Web Applications are developed.
The Presentation Tier follows the Model-View-Controller (MVC) Model 2 paradigm.† The MVC paradigm organizes the applicationís presentation layer into segregated components that work together to provide interactive web functionality.† In the MVC paradigm:
∑ The Model represents the information gathered and presented to the user.† Information is encapsulated into data representations of entities and passed from component to component.†
∑ The View is responsible for presenting and capturing data to and from the user.†
∑ The Controller processes incoming requests and coordinates the flow of presentation.
For J2EE implementations, MVC is applied using JavaBeans as the Models, JavaServer Pages as the Views, and Java Servlets as the Controllers.† JavaBeans are standard Java objects with attributes representing logical aggregations of data that is captured or displayed within JavaServer Pages.† JavaServer Pages contain HyperText Markup Language (HTML) with embedded Java code.† The HTML provides the page layout, and the Java provides the processing that is required to present the data contained in JavaBeans.†
Upon submittal, the JSP dispatches the request, including JavaBeans, to a Servlet.† The Servlet processes the request inside WebLogic Server, determining what is done and what backend services are called.† The Servlet then passes control to the next JSP or Servlet.
For more information about Model-View-Controller, see Sunís Web-Tier Application Framework Design.
Struts is an open source web framework developed by Jakarta.† Struts provides a foundation on which Web Applications can be built.† The foundation includes an extensive number of classes, interfaces and protocols from which application-specific logic extends.† Struts hides the complexity a web application by abstracting component definition and interaction to an XML based configuration file.
In Struts, Controllers are called Actions and inherit from a single Action class.† This Action class processes the incoming request and redirects it to the appropriate custom Action mapped in Strutsí configuration file.† Struts defines Views as standard JavaServer Pages and Models as JavaBeans that inherit from Strutsí Form Bean.
For more information see Struts.
MedRecís Web Applications are developed using the Struts framework.† The first iteration of MedRec, MedRec 1.0 will be built upon Struts 1.0.† The following section discusses the architectural details of MedRecís Web Application framework.
MedRec Web Applications consist of the standard web components.† JavaServer Pages (JSPs) are used to gather and present information.† Standard HTML forms are used to submit information to Java Servlets, or Actions, who are responsible for a logical grouping of functionality such as:
∑ Registering a user
∑ Creating a medical record
∑ Viewing medical records
Upon submitting a form, JSP tags and Struts intelligence populate JavaBeans with the gathered information and attach the objects to the request before sending the request to the Action.†
When information is passed to the Action for processing, the Action asks the JavaBean to validate itself.† The JavaBean performs validation specific to its attributes, and, if applicable, populates error fields with the appropriate error messages.† If errors are found, the Action passes the JavaBean to the appropriate JSP where error message are rendered.
If the JavaBean is valid, the Action will handle the Service Tier interaction, the processing of the JavaBean, and the presentationís flow.†
2.4.1. ††MedRec Differences From Struts
MedRec implements MVC Model 2 using Jakartaís Struts, but diverges from the traditional approach in two key areas.
∑ MedRecís implementation of Struts maintains Web Tier to Service Tier communication in the Controller.† Model components are limited to encapsulating data structures and surface-level validation.† The traditional approach is where the Model is responsible for business service logic as well as data encapsulation.
∑ Encapsulated data returned from the Service Tier is aggregated and/or reorganized into objects that represent the information presented and/or gathered from the user.† This is different from the traditional approach where objects obtained from the Service Tier are carried to the presentation view.
These differences in approach are consistent with the goal to decouple Model components from the Service Tier and to centralize complexity in Controller components.† This approach focuses the Model on the data and its particulars rather than its flow.† Because the Controller is the natural leader in the MVC paradigm, it is logical that the component should take on the responsibility of layer communication.
The following section discusses the responsibilities of each component that makes up the Web Application.
JavaServer Pages (JSP) consist of HTML with embedded Java code.† Java code is solely responsible for creating and rendering data from and into JavaBeans.† Business logic is not implemented within JSPs.
One of the underlining goals of JSP development is to efficiently segregate logical code from presentation code.† Where appropriate, Java code (typically tag library functions) and HTML code are intermingled to provide functionality needed to logically gather and present application data.
Each JSP obtains application messages from a localized resource component.† For further information see Localization below.
JSPs are not accessed directly.† All flow in and out of JSPs is controlled by Actions.
JavaBeans or Presentation Beans are standard Java objects that encapsulate all attributes gathered from or displayed within a JSP.† These objects are also responsible for validating their data structure.
JavaBeans are specific to the Web Application.† Data structures obtained from the Service Tier, called Value Objects, are transformed into one or more JavaBeans to be presented in a JSP.† Similarly, JavaBeans containing captured user data are transformed into one or more Value Objects that aare passed to the Service Tier.† These transformations are handled within the JavaBeans themselves.
All JavaBean attributes are of type java.lang.String in order to simplify presentation in JSPs.† This is different from Value Objects where attributes are specific to their type (i.e., date is a java Date data type).† These conversions are handled within the JavaBeans.
JavaBeans that require validation contain methods that check their data values for invalid information.† Validation is limited to the existence of the value and the matching of expected data patterns.† If an attribute is deemed invalid, a localized application resource provides the appropriate error message to be stored within an error mapping class, ActionErrors.† Validation helper methods specific to the JavaBeans structure are local to the JavaBean.† Common validation helper methods are provided in the BaseBean.
All beans extend the BaseBean object containing common attributes and helper functionality.† The BaseBean extends org.apache.struts.action.ActionForm, which is used by Struts to perform callback validation.
Tag Libraries are packages of Java classes that encapsulate core functionality common to JSPs.† These classes are then used as tags within JSPs.
Tag libraries not only provide common functionality, but also are beneficial to separating Java code from HTML code.† The clear division of Java and HTML improves the maintenance of JSPs.
Table 2 outlines the tag libraries used by MedRec Web Applications.
Table 2† MedRec Tag Libraries
Struts library containing tags useful in accessing beans and their properties, as well as defining new beans that are accessible to the remainder of the page via scripting variables and page scope attributes.
Struts library containing tags used to create input forms, as well as other tags generally useful in the creation of HTML-based user interfaces.
Struts library containing tags that are useful in managing conditional generation of output text, looping over object collections for repetitive generation of output text, and application flow management.
Servlets, or Actions, are the central Controllers of the webapp.† All requests from the web server or from proxy layers are processed by Actions.† Action modules are separated by application tasks.† For example, all client registration functionality is handled by a single Action called Register.† Actions are primarily made up of controller logic that acts on JavaBeans obtained from requests.† JavaBeans are asked to validate themselves and, based on discovery, are either passed as Value Objects to the Service Tier for business logic processing or returned to the presentation view for client re-evaluation.
Each Action extends BaseAction or BaseLookupDispatchAction depending on the chosen behavior of the child Action: BaseAction is used for plain vanilla Actions, and BaseLookupDispatchAction is used for handling multiple submits from a single JSP.† Both base components encapsulate intercepting responsibilities as well as common functionality like session management, locale management, resource lookup and error handling.
The BaseAction extends org.apache.struts.action.Action. BaseLookupDispatchAction extends org.apache.struts.actions.LookupDispatchAction.† Strutsí Action class acts as the proxy between requests and the application logic executed in extended Actions.† All URL requests with the extension ď*.doĒ are mapped to this Action class as defined in each Web Applicationís web.xml descriptor.† The Action class dissects the request and determines further processing through mappings in Strutsí configuration file, struts-config.xml.† For example, a request to ďLogin.doĒ is mapped to the LoginAction where login functionality is maintained.† For more information on Actions and Struts Configuration, see the Struts User Guide.
All JSPs are serviced by Actions.† JSPs are not accessed directly.† All flow in and out of JSPs is controlled by Actions.
The ServiceLocator is responsible for looking up services available in the Service Tier.† This includes handles to EJBs, JMS queues, and JDBC connection pools.† The ServiceLocator is a single point of access to service handles.† This abstraction provides a uniform mechanism for service lookup.† The ServiceLocator may also cache services to improve performance.
See Service Locator for more information.
Actions and JavaBeans use utility classes to perform common functionality.
Table 3 outlines utility modules used in MedRecís Web Applications.
Table 3† MedRec Web Application Utilities
Provides conversion functionality for arrays and java.util.Collections of JavaBean to Value Object and vice versa.
Provides constants values for service names.
Provides various presentation functions such as date formatting and java.lang.String validation and manipulation.
Provides access to MedRec messages within localized properties files.
Properties files are simple text files containing name-value pairs.† Based on a name, values are retrieved and displayed to the user or are used to configure a resource within the application.
Table 4 outlines properties files used within MedRecís Web Applications.
Table 4† MedRec Web Application Property Files
Configuration for Log4J logging mechanism.† The property file is initialized within a preloaded Servlet, Log4Init.
Contains presentation titles, text tags and error messages.† There is an ApplicationResources properties file for each locale.
Configuration files are XML-based files used to define the behavior of resources in an application.
Table 5 summarizes configuration files used with MedRecís Web Applications.
Table 5† MedRec Web Application Utilities Configuration Files
The Servlet deployment descriptor defines components in the web application including Servlet deployment, tag libraries, context parameters, URL mapping, and login configuration.† For more information, see the XML DTD for the Servlet 2.3.
The WebLogic Web Application deployment descriptor contains WebLogic Server-specific configuration attributes that define security, and HttpSession and JSP parameters.† For more information, see weblogic.xml.
The Struts configuration file defines Web Application components and their relationships.† Components include Form beans, Action Servlets, and dispatch mapping.† See Struts Configuration File for more information on Strutsí configuration file.
MedRec Web Applications use the Struts localization framework to display internationalized content.† MedRec is initially localized for English and Japanese.
Before localizing MedRec, the content of the Web Applications is internationalized.† This is done by developing the Web Application in English and then translating the content to other languages.† Web Application content is maintained within application resource files.† There is a resource file for each supported language.
All flow in and out of the Web Applications is encoded with UTF-8 (Unicode Transformation Format, 8 bit form) character encoding.† To encode input as UTF-8, an encoding filter is employed to intercept all requests from clients and responses to a client.† The encoding filterís sole responsibility is to set the character encoding to UTF-8.
To instruct Struts to use the resource properties files (see Properties Files above), JSPs must contain <html:html locale="true">.† When Struts encounters a <bean:message> tag, based on a key value the localized text is retrieved for the locale of the user.† If the locale is unknown, then the browserís default locale is used.
The locale can be changed using a link on MedRecís start page.† When changed, the locale is stored in the userís HttpSession and also written to a cookie for future locale lookups.
For more information on Struts localization, see Internationalized Messages.
All exceptions that occur within a Web Application or that are obtained from the Service Tier are captured and re-thrown as client exceptions. Client exceptions contain the originating exception and a link for post-error navigation.† Client exceptions may also contain additional information such as details on what might have occurred or general instructions on how to recover from a problem.† Client exceptions, in addition to all other exceptions that occur in the Web Application framework, are captured within the Web Applicationís base classes and transformed into Java error classes.† The error class is then passed to the common error action class that uniformly displays the error message and link.
MedRec employs Log4j as the application-wide logging mechanism.† Logging is configured within the log4j.properties file located in the root of the MedRec WLS domain directory. This file is read in through the Log4jInit class which is loaded upon webapp startup. The logging levels are controlled by package names in log4j.properties (see "log4j.category.*").† In each class you get an instance of log4j's Logger class. From there you use log4j's logging methods to determine when and how a particular string is logged.
To change the logging levels, edit log4j.properties to set the package category to the desired logging level: FATAL, ERROR, WARN, INFO or DEBUG.† Then redeploy the Web Application.
The following are the default logging levels:
See Log4j Project for more information on Log4j.
The Service Tier is the engine of the application, responsible for MedRecís business logic.† This tier receives requests from clients such as the Presentation Tier, or from external clients such as Web Services.† The Service Tier processes requests by applying business-specific logic and interacting with the Enterprise Information System Tier to store or receive data.† The Service Tier may also return information to the calling client to complete the work cycle.† The Service Tier may also communicate with other applications by passing a request for asynchronous processing consumption.
3.1. Design Considerations
The following section outlines design considerations for MedRecís Service Tier architecture.† These objectives are the basis for all Service Tier design decisions
The Service Tierís major design consideration is that MedRec must be able to handle high volumes of simultaneous requests from numerous clients.† At the same time, the Service Tier must be small in size in order to manage resource usage.
The Service Tier is accommodating to heterogeneous clients such as Java clients, XML-based clients, proprietary handheld devices, and .NET clients.† The nature of MedRec is to interface with many types of users and many types of external systems.† Each user and each system has different needs that must be addressed.
Extensible and modular
The Service Tier is designed so that each componentís responsibilities and duties are clearly defined.† For example, business logic is contained within exclusive components called Session Facades.† Similarly, service lookups like EJB Homes and JMS Topics are contained in a common factory component.† This practice facilitates maintenance and allows for application growth.
Minimize application interdependence
The Service Tier is designed so that inter-tier communication is limited only to the necessities.† Tier partitioning is important so that changes to dependent tiers are contained and do not have widespread influence.† For example, the Service Tier is loosely tied to the Enterprise Information System Tier in the event that the data storage vendor changes.
3.2. MedRec Service Tier Architecture
MedRecís Service Tier is primarily made of Enterprise JavaBeans (EJBs) that work together to process requests from Web Applications, Web Services, workflow applications, and future client applications.† At the heart of the Service Tier are Stateless Session EJBs that encapsulate much of the MedRecís business logic.† These Stateless Session Beans are referred to as Session Facades, and they process all incoming requests.† Session Facades interact with Container Managed Entity EJBs, other Stateless Session EJBs, Java Messaging Services, and helper modules in order to complete the work.
All MedRec EJBs are based on the EJB 2.0 specification.
3.3. Components Defined
The following section discusses the responsibilities of each component involved with the Service Tier.
Value Objects (VOs) encapsulate a set of related data that is passed from one tier to another.† Value Objects are standard Java classes with attributes and getter and setter methods for each attribute.† Typically, Value Objects are mapped one-to-one to Entity Beans.
Within MedRec, Entity EJBs retrieve information from the Enterprise Information System Tier and transform themselves into Value Objects that are consumed by other components.† Similarly, data captured in the client tiers are transformed into Value Objects and passed to the Service Tier for consumption.† These conversions allow different clients to communicate with the Service Tier.† See Entity JavaBeans below for more information.
All Value Objects extend the Base Value Object class that contains common attributes and methods.
For more information, see Value Object.
Session Facades are Stateless Session EJBs containing the business logic of the Service Tier.† Business logic includes medical record-related business and system rules that are applied to requests, as well as application logic like awareness of components in the system.† In addition to applying business logic, the primary goal of Session Facades is to further separate tier responsibilities and minimize interdependence.
To process a request, Session Facades interact with other Service Tier components such as Value Objects, Entity EJBs, Messaging, and other J2EE services.† This aggregation of control is contained within Session Facades to alleviate complex transactions.† Client programs interface with one component, the Session FaÁade, rather than managing a number of contracts.
Typically Sessions Facades are mapped one-to-one with use cases. In MedRec, Sessions Facades are derived by grouping common functionality for each actor in the system.† For example, the Admin Session FaÁade contains functionality common to the duties of administering MedRec (for example, approving Patient registration requests and uploading incoming medical records).
The Service Tier uses Container Managed Persistence Entity Enterprise JavaBeans to manipulate data stored in a database located in the Enterprise Information System Tier.
All Entity EJB access is governed by Session Facades.† In other words, Entity EJBs must go through Session Facades in order to obtain application data.† This design is consistent with the principal of centralized responsibility.
The following section outlines EJB features that will be employed in order to improve overall EJB performance.
MedRec Entity EJBs implement local EJB interfaces and are deployed without exposing the JNDI tree.† Local EJBs are called by reference, thus eliminating expensive remote invocation calls.† This feature allows the Service Tier to pass Entity EJB references back to clients in the same Java Virtual Machine (JVM).
To meet MedRecís tier independence and accommodating design considerations, local EJBs are used only to a point.† The Service Tier must rarely couple itself with other tiers, and it must also be able to accommodate calling clients who may or may not be within the same JVM.†
For example, Web Applications deployed within the same WebLogic instance may use local EJBs.† However, for proprietary systems outside this WebLogic instance (such as handheld devices) local EJBs may not be used.† Because of the need to accommodate different client types, a common, standard data delivery mechanism, Value Objects, is used.† All Entity EJBs provide the capability to transform their attributes in a Value Object.
Often a client is interested only in a subset of data that an Entity EJB provides.† Field groups are used to return just the attributes that are required.† Within an Entity EJBs descriptor, field groups are defined and associated with a particular finder method.† When this finder method is called, the container understands that only a subset of attributes should be retrieved.† This is particularly beneficial when an Entity EJB has relationships that are irrelevant to a calling client.
Finder methods are defined using EJB-QL, but WebLogic-EJB-QL is used in order to utilize common SQL features not implemented in EJB 2.0.† Specifically, WebLogic-EJB-QL ORDERBY is used where data retrieved in a collection of Entity EJBs is sorted by a set of desired attributes.
For more information, see Programming WebLogic Enterprise JavaBeans.
The Service Tier employs Message-Driven EJBs (MDBs) to handle asynchronous workloads.† MDBs provide significant benefit where it is important to provide reliable processing without involving the client.
This section outlines MedRecís usage of MDBs where functionality is designed to takes advantage of MDBsí capability to provide reliable handling of large volumes of transactions.
MedRec uses MDBs to handle all email transmissions.† Mail messages are placed on a JMS queue where an MDB ensures the delivery of the email.
An MDB uploads incoming XML medical records.† Instead of having a client-driven process that is responsible for transforming XML documents, MedRecís process is divided among logical work units.† First, a client parses the XML document into Value Objects.† Then the client passes components to a queue where an MBD is responsible for storing the elements.
For more information, see Programming WebLogic Enterprise JavaBeans.
The ServiceLocator is responsible for looking up services available in the Service Tier.† This includes handles to EJBs, JMS queues, and JDBC connection pools.† The ServiceLocator is a single point of access to service handles.† This abstraction provides a uniform protocol for service lookups.† The ServiceLocator may also caches services to improve performance.
All exceptions that occur within the Service Tier are logged and thrown back to the calling client.† There are two types of business exceptions in the Service Tier.
MedRecException is the Service Tierís business exception.† This exception occurs when application data or behavior is found to be in violation of business rules embedded in the application logic.
This exception occurs when an existing users is registering.
The Service Tier uses Log4j as its logging mechanism.† The Service Tier inherits Log4j configuration from the Web Application.† See section 2.8 for more information.
The MedRec Enterprise Information System Tier is made up of a relational database management system.† This tier could also refer to legacy systems or Web Services.
MedRec application data is maintained in PointBase, a platform-independent, embedded relational database written in Java.† PointBase is shipped with WebLogic Server.
For more information on PointBase, see PointBase.
WebLogic Server ships a sample PointBase database called DEMO.† The MedRec schema exists within this database.
Because of the nature of the medical industry, MedRec must be capable of interfacing with multiple medical institutions and delivering accurate and timely information to diverse, heterogeneous clients. To satisfy this complex requirement, Web services is used as a standard mechanism for exposing MedRec functionality.
Web services are Web-based applications that dynamically interact with other Web-based applications using open standards including XML, HTTP, and SOAP.† Essentially, Service Tier components are exposed to the public via the Internet.† Through a published URL, a serviceís description and communication information (such as inputs and outputs) are defined.
For more information, see WebLogic Server: Web Services.
In order to meet the needs of MedRec users, specific MedRec functionality is exposed through a Web Service delegate.
The MedRec Web Service delegate is an EJB.† The EJB delegate provides a level of abstraction from the internals of the Service Tier.† This separation supports MedRecís design objective of modularity where, changes made to a service have minimal impact to the calling components.† In addition, the Web Service delegate can take advantage of EJB features such as security, transactions and other container-provided benefits.
The MedRec Web Service delegate EJB is assembled into a Web Service.† MedRec does so using the WebLogic Ant tasks.
See Assembling WebLogic Web Services Using Ant Tasks for more information.
To assemble the Web Service, autotype Ant task first converts non-built-in data types to equivalent XML schema data types so that Web Service runtimes can communicate structures to the client.†
The source2wsdl Ant task then generates the Web Service configuration file, web-services.xml.
Service Tier functionality is exposed in the EJB delegate based on the needs of MedRec users.
MedRec patient information must be made available to medical institution applications such as physician offices.† MedRec allows the physician application to search for patients, retrieve patient profiles and medical history, and record visit information such as diagnoses and medical prescriptions.
MedRec also exposes the ability to register new patients.† This functionality is useful to corporate human resource departments that wish to provide extra benefits to their employees.
MedRec security takes advantage of the WebLogic Server security framework.† MedRec Administrators are managed using WebLogic Serverís default security configuration.† MedRec Patients are managed using a custom Authentication provider in conjunction with WebLogic Serverís default security configuration.† Both the MedRec Administration and Patient websites are constrained using URL pattern matching.
For more information, see WebLogic Security.
There are two types of users that MedRec maintains: administrators and patients.† The following sections outline each user.
MedRec administrator users are maintained in and managed by WebLogicís default security configuration.† Usernames, groups, and roles are stored within WebLogicís embedded LDAP server, and are viewed, created, updated and deleted using the WebLogic Server Administration Console.
MedRec patient users are maintained in series of tables inside the relational database management system.† Patient login credentials, profile, and group associations are stored in a relational database.† Patient roles and their group associations are stored in WebLogic Serverís embedded LDAP server.† The two sets of data are linked by a common group name stored in both the RDBMS and LDAP.
MedRec uses two types of groups Ė MedRecAdmins and MedRecPatients.† The following sections outline each group.
MedRec Administrators are assigned to the MedRecAdmins group.† The MedRecAdmins group exists within WebLogic Serverís embedded LDAP server, and is assigned to users in WebLogicís default security configuration.
MedRec Patient users are assigned to the MedRecPatients group.† Patient group associations are maintained in the relational database.† The MedRecPatients group also exists in WebLogic Serverís embedded LDAP server.† The MedRecPatients group associates MedRec Patient information located in the RDBMS with MedRecís WebLogic Server security configuration.
MedRec uses two types of roles Ė MedRecAdmin and MedRecPatient.† The following sections outline each role.
MedRec administration resources are constrained using the MedRecAdmin role.† This role is assigned exclusively to the MedRecAdmins group.† Users associated with the MedRecAdmins group are assigned the MedRecAdmin role.
MedRec patient resources are constrained using the MedRecPatient role.† This role is assigned exclusively to the MedRecPatients group.† Users associated with the MedRecPatients group are assigned the MedRecAdmin role.
The following section outline MedRecís security configuration.
Authentication is the process whereby the identity of clients, users or system processes, is proved or verified.† The WebLogic Security Framework, together with the Java Authentication and Authorization Service (JAAS) classes, reliably and securely authenticate clients.†
Authentication providers are central to this framework.† Authentication providers are the mechanisms that remember, transport, and make that identity information available to various components of a system when needed.† MedRec uses two Authentication providers: the WebLogic Authentication provider, and a custom MedRec Sample Authentication provider.
The WebLogic Authentication provider manages MedRec Administrators, their groups, and group memberships.† The WebLogic Administration Console calls the provider (referred to as the Default Authenticator) through the WebLogic Security Framework to create, view, update and delete users and groups that are stored in the embedded LDAP server.† The framework also calls upon this provider when client authentication requests are made.† By default, the WebLogic Authentication provider is configured out-of-the-box.
The MedRec Sample Authentication provider is a custom provider that implements the Security Service Provider Interface.† This standard interface allows custom providers to be integrated with the WebLogic Security Framework.† The MedRec Sample Authentication Provider consists of a managed bean (MBean), LoginModule and database delegate.† When client authentication requests are made, these components, in conjunction with the security framework, work together to obtain, validate, and store login credentials and group memberships.
The MedRec Sample Authentication provider obtains Patient users and their group memberships stored in the relational database.† Storing Patient information outside of LDAP allows the application to take advantage of the flexibility and power of a database management system.† Maintaining a relationship between Patient relational data and Patient LDAP data (roles) allows MedRec to take advantage of WebLogicís security framework.
For more information on custom providers, see Developing Security Providers for WebLogic Server.
Authentication providers are configured through the WebLogic Administration Console by setting the Authentication Re-Ordering and the Control Flag for each provider.† Each Authentication providerís Control Flag is set to SUFFICIENT. SUFFICIENT indicates that if a provider succeeds, the authentication process is concluded.
When an authentication request is made, the Default Authentication provider is called first to validate a userís existence and login credentials.† If the user is not found, the framework next uses the MedRec Sample Authentication provider to validate a userís existence and login credentials.† If the user is not found in any of the configured providers, authentication fails.† If the user is found, the security framework does not continue to the next provider.
See JAAS Control Flags for more information about login sequence configuration.
Authorization is the process whereby the interactions between users and WebLogic resources are controlled, based on user identity or other information.† In WebLogic Server, an Authorization provider is used to manage the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability.
A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity.† A WebLogic resource can be protected from unauthorized access by using security roles and policies.† Security policies are stored in an Authorization provider's database. By default, the WebLogic Authorization provider is configured and security policies are stored in the embedded LDAP server.
When a client authentication request is made, the userís login credentials and group memberships are stored.† When a secured WebLogic resource is accessed, the security framework gathers the roles associated with the userís groups and determines authorization based on these roles.
MedRec security is applied to the Administration and Patient Web Applications using the URL resource component.† This component applies security policies to URL patterns.† All HTTP requests are evaluated for matching URL patterns.† If a pattern is secured by a policy, the framework determines if the requesting user has authorization.
For more information on WebLogic resources, see Types of WebLogic Resources.