![]() |
![]() |
Configuring Domains and Servers
Tutorial 3: Setting Up WebLogic Server Resources for the MedRec Server
This tutorial describes how to set up the WebLogic Server resources required to deploy and run the MedRec application. The tutorial sets up resources for the MedRec server. These resources include:
The tutorial includes the following sections:
|
Prerequisites
Before starting this tutorial:
|
Procedure
Follow these steps to configure WebLogic Server resources for the MedRec server:
Step 1: Invoke the Administration Console for the MedRec server in your browser.
You use the Administration Console to create the WebLogic Server resources used by the MedRec application suite.
http://127.0.0.1:7101/console
Step 2: Create the JDBC connection pools.
A JDBC connection pool describes how to physically connect to a database, in this case a PointBase database. This procedure describes how to create two JDBC connection pools: the first uses an XA JDBC driver and the second one does not.
Typically you always use an XA JDBC driver when creating a connection pool. However, because JMS JDBC stores do not support XA resource drivers (WebLogic JMS implements its own XA resource), a second non-XA connection pool is needed. Later procedures show how to associate the XA connection pool to a JDBC DataSource and the non-XA connection pool to a JMS JDBC store.
Note: Be sure you have started PointBase, or the test of its driver configuration will fail. For details, see Tutorial 2: Starting the PointBase Development Database.
Step 3: Create a JDBC DataSource.
Client and server-side JDBC applications obtain a DBMS connection through a DataSource. A DataSource is an interface between an application and the JDBC connection pool. This DataSources uses the XA connection pool you created in Step 2: Create the JDBC connection pools.
Step 4: Create a JMS JDBC store.
JMS stores are used to store persistent messages. This JMS JDBC store uses the non-XA connection pool you created Step 2: Create the JDBC connection pools.
Step 5: Create a JMS server.
JMS servers host the queue and topic destinations used by JMS clients. To persistently store messages in destinations, the JMS server must be configured with a JMS store.
Step 6: Create the JMS queues.
JMS queues are based on the point-to-point (PTP) messaging model, which enables the delivery of a message to exactly one recipient. A queue sender (producer) sends a message to a specific queue. A queue receiver (consumer) receives messages from a specific queue.
The following procedure describes how to create three JMS queues, which are used by message-driven beans for registering new users of the MedRec application, handling email, and uploading XML files.
Step 7: Create a JMS connection factory.
JMS clients use JMS connection factories to create a connection to a WebLogic Server instance. JMS client messaging requests to a particular destination are routed through their connection's host WebLogic Server to the WebLogic Server hosting the JMS server destination. JMS connection factories are also used to configure the defaults for the JMS clients that use them.
Step 8: Add email capabilities to the MedRec application.
WebLogic Server includes the JavaMail API version 1.1.3 reference implementation from Sun Microsystems. Using the JavaMail API, you can add email capabilities to your WebLogic Server applications. To configure JavaMail for use in WebLogic Server, you create a Mail Session in the WebLogic Server Administration Console. A mail session allows server-side components and applications to access JavaMail services with JNDI, using Session properties that you preconfigure.
For example, if you want any email generated by the MedRec application to be sent to you, and your email address is joe@mail.mycompany.com, enter:
mail.user=joe;mail.host=mail.mycompany.com
Step 9: Configure the MedRec Sample Authenticator.
The MedRec Sample Authenticator retrieves login credentials from the configured PointBase RDBMS for a given username. Within the provider, passwords are validated, and if correct, the user's group associations are retrieved.
|
Best Practices
The MedRec application uses a DataSource with transactions enabled (a TxDataSource object) when persisting application data to the database using entity beans.
If you want better performance and simpler configuration, BEA recommends you persist JMS messages to the file system. If you want to store your persistent messages in a remote database rather than on the JMS server's host machine, BEA recommends you use a JDBC JMS store.
|
The Big Picture
The MedRec application uses JMS to create a new patient record. The asynchronous nature of JMS allows the task to be queued and completed later while the user continues with another task.
After the user clicks Create on the Web page to register a new patient, a JMS message is created and put on the REGISTRATION_MDB_QUEUE JMS queue. The RegistrationEJB message-driven bean takes the message off the queue and persists the new patient data to the database using an instance of the PatientEJB entity bean. The PatientEJB entity bean uses the JDBC DataSource to connect to the PointBase database.
The MedRec application uses other entity beans to persist additional data to the database; for details, see Patient, Physician, and Administrator Data.
The MedRec application uses persistent JMS messaging, which means that the new patient JMS messages that are put on the queue are also stored in a PointBase database so that the messages can be retrieved in case a problem occurs (such as a server crash) before the message-driven bean is able to process them. The application uses the JMS JDBC store to connect to and to update the JMS tables in the PointBase database.
|
Related Reading
![]() |
![]() |
![]() |