Creating and Deploying to WebLogic Server Clusters

Tutorial 3: Setting Up Cluster Resources for MedRec

This tutorial describes how to set up the WebLogic Server resources required to deploy and run the MedRec applications. These resources include:

- Java Database Connectivity (JDBC) connection pools and data sources for the PointBase database management system

- Java Message Service (JMS) persistent store, JMS server, queue, and connection factory

- JavaMail mail sessions

The tutorial includes the following sections:

- Prerequisites

- Procedure

- Best Practices

- The Big Picture

- Related Reading

Prerequisites

Before starting this tutorial:

- Create the MedRecClusterDomain as described in Tutorial 1: Creating a WebLogic Server Cluster.

- Start the PointBase Database, Administration Server, and Cluster using the instructions in Tutorial 2: Starting the Cluster.

- Make sure you have the Administration Console opened in a browser window and that all servers in the cluster are running. See Tutorial 2: Starting the Cluster for information on starting the Administration Console.

Procedure

Follow these steps to configure WebLogic Server resources for the MedRec Server:

- Step 1: Create a JDBC connection pool.

- Step 2: Create a JDBC DataSource.

- Step 3: Create a JMS Connection Factory.

- Step 4: Create a JMS JDBC store.

- Step 5: Create a JMS server.

- Step 6: Create the JMS queues.

- Step 7: Add email capabilities to the MedRec application.

- Step 8: Configure the MedRec Sample Authenticator.

Step 1: Create a JDBC connection pool.

This JDBC connection pool uses a JDBC driver that does not support distributed transactions (non-XA).

1. In the left pane of the Administration Console, open Services-> JDBC.

2. Right-click Connection Pools and choose Configure a new JDBCConnectionPool.

3. Choose Pointbase for the Database Type.

4. Choose Pointbase's Driver (Type 4) Versions:4.X for the Database Driver.

5. Click Continue.

6. Enter:

   - pb/MedRecPool in the Name field.

   - demo in the Database Name field.

   - 127.0.0.1 in the Host Name field.

   - 9092 in the Port field.

   - MedRec in the Database User Name field.

   - MedRec in the Password field.

   - MedRec in the Confirm Password field.

7. Click Continue.

8. Ensure that the information to test the connection to the Pointbase database is correct, then click Test Driver Configuration.

   Note: Be sure you have started PointBase, or the test of its driver configuration will fail.

9. After verifying that the connection succeeded, the Administration Console display the Create and Deploy page. To deploy to the new cluster:

   - Select medreccluster in the list of clusters.

   - Select All servers in the cluster is selected.

10. Click Create and Deploy to deploy the new pool.

11. Verify that the pool deployed by examining its entry in the JDBC Connection Pools table. pb/MedRecPool should appear in the table, and its Deployed status should be "True."

Step 2: 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.

1. In the left pane of the Administration Console, open Services-> JDBC.

2. Right-click Data Sources and choose Configure a new JDBCTXDataSource.

3. Enter pb/MedRecTxDataSource in the Name field and MedRecTxDataSource in the JNDI Name field.

4. Ensure that Honor Global Transactions is checked.

5. Click Continue.

6. Choose pb/MedRecPool in the Pool Name list box.

7. Click Continue.

8. Ensure that medreccluster is checked as the cluster on which you want to deploy this data source. Also ensure that the All servers in the cluster option is selected.

9. Click Create.

10. To verify that the DataSource was deployed:

    - Open the Clusters->medreccluster node in the left pane.

    - Select one of the servers in the cluster.

    - In the right pane, select the View JNDI tree link.

    - In the resulting window, verify that MedRecTxDataSource appears in the left column. This indicates that it has been bound to the cluster JNDI tree.

Step 3: Create a JMS Connection Factory.

1. In the left pane of the Administration Console, open Services-> JMS.

2. Right-click Connection Factories and choose Configure a new JMSConnectionFactory.

3. Enter jms/MedRecQueueConnectionFactory in the Name field and jms/MedRecQueueConnectionFactory in the JNDI Name field.

4. Click the Create button.

5. Select medreccluster in the Targets list.

6. Ensure that the All servers in the cluster option is selected.

7. Click Apply to target the connection factory to the cluster.

8. Select the Configuration tab.

9. Select the Transactions tab.

10. Select the XA Connection Factory Enabled check box.

11. Click Apply.

12. To verify that the factory was deployed:

    - Open the Clusters->medreccluster node in the left pane.

    - Select one of the servers in the cluster.

    - In the right pane, select the View JNDI tree link.

    - In the resulting window, open the jms node in the left pane.

    - Verify that MedRecQueueConnectionFactory appears in the left column under the jms node. This indicates that the factory has been bound to the cluster JNDI tree.

Step 4: Create a JMS JDBC store.

A JMS JDBC store consists of a JDBC database that can be used for persistent messaging.

1. In the left pane of the Administration Console, open Services-> JMS.

2. Slect Stores in the left pane.

3. In the right pane, choose Configure a new JMS JDBC Store.

4. Enter MedRecJMSJDBCStore in the Name field.

5. Choose pb/MedRecPool in the Connection Pool list box.

6. Enter MedRec in the Prefix Name field.

7. Click Create.

Step 5: Create a JMS server.

A JMS server manages connections and message requests on behalf of JMS clients.

1. In the left pane of the Administration Console, open Services-> JMS.

2. Right-click Servers and choose Configure a new JMSServer.

3. Enter MedRecJMSServer in the Name field.

4. Choose MedRecJMSJDBCStore in the Store list box.

5. Click Create.

6. Choose one of the available servers in the cluster—MedRec1, MedRec2, or MedRec3—from the target list. Do not select the migratable servers listed. That is, do not select MedRec1 (migratable), MedRec2 (migratable), or MedRec3 (migratable).

7. Click Apply.

8. To verify that the server was targeted:

   - Click the Monitoring tab.

   - Select the Monitor Active JMS Servers... link.

   - Verify the MedRecJMSServer appears in the table.

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 the three JMS queues used by message-driven beans for registering new users of the MedRec application, handling email, and uploading XML files.

1. In the left pane of the Administration Console, select Services-> JMS->Servers->MedRecJMSSserver.

2. Right-click Destinations and choose Configure a new JMSQueue.

3. In the right pane, enter jms/REGISTRATION_MDB_QUEUE in the Name field.

4. Enter jms/REGISTRATION_MDB_QUEUE in the JNDI Name field.

5. Click Create.

6. In the left pane, right-click Destinations and choose Configure a new JMSQueue.

7. In the right pane, enter jms/MAIL_MDB_QUEUE in the Name field.

8. Enter jms/MAIL_MDB_QUEUE in the JNDI Name field.

9. Click Create.

10. In the left pane, right-click Destinations and choose Configure a new JMSQueue.

11. In the right pane, enter jms/XML_UPLOAD_MDB_QUEUE in the Name field.

12. Enter jms/XML_UPLOAD_MDB_QUEUE in the JNDI Name field.

13. Click Create.

14. To verify that the queues were created:

    - Click the Destinations node in the left pane.

    - Verify that all three queues appear in the right-hand table.

Step 7: 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 you preconfigure for them.

1. In the left pane of the Administration Console, open Services.

2. Right-click the Mail node and choose Configure a new MailSession.

3. Enter:

   - mail/MedRecMailSession in the Name field.

   - mail/MedRecMailSession in the JNDIName field.

   - mail.user=joe;mail.host=mail.mycompany.com in the Properties text field.

4. Click Create.

5. Select medreccluster in the Targets box.

6. Ensure that the All servers in the cluster option is selected.

7. Click Apply.

8. To verify that the factory was deployed:

   - Open the Clusters->medreccluster node in the left pane.

   - Select one of the servers in the cluster.

   - In the right pane, select the View JNDI tree link.

   - In the resulting window, open the mail node in the left pane.

   - Verify that MedRecMailSession appears in the left column under the mail node. This indicates that the session has been bound to the cluster JNDI tree.

Step 8: 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.

1. In the left pane of the Administration Console, expand the Security—>Realms—>myrealm—>Providers node.

2. Select the Authentication node under the Providers node.

3. In the right pane, select Configure a New MedRec Sample Authenticator.

4. In the General tab in the right pane:

   - Enter MedRecSampleAuthenticator in the Name field.

   - Select SUFFICIENT from the Control Flag menu.

   - Click Create to create the new authenticator.

   The SUFFICIENT control flag indicates that the LoginModule does not need to succeed. If it does succeed, control is returned to the application. However, if it does not succeed, the server tries other configured authentication providers.

5. In the left pane of the Administration Console, expand the Security—>Realms—>myrealm—>Providers—>Authentication node.

6. Select the DefaultAuthenticator in the left pane of the Administration Console.

7. In the General tab in the right pane, select SUFFICIENT from the Control Flag menu.

8. Click Apply.

9. Because WebLogic Server cycles through available Authentication providers, reorder the provider list so that the PointBase database is not queried each time a login is attempted (for example, each time you log into the Administration Console in subsequent tutorials.

   Select the Security—>Realms—>myrealm—>Providers—>Authentication node in the left pane of the Administration Console.

10. In the right pane of the Console, select Re-Order the Configured Authentication Providers.

11. Use the arrows in the Configured Providers list to define the following order of authentication providers:

    1. DefaultAuthenticator

    2. MedRec Samples Authenticator

    3. DefaultIdentityAsserter

12. Click Apply.

Best Practices

- Only the JMS Server is pinned to a single server in the cluster. Target all other services to all servers in the cluster.

- When you create a JDBC DataSource, be sure you enable global transaction support (by checking the Honor Global Transactions box) so that your application can support transaction services.

The MedRec application uses a DataSource with transactions enabled (a TxDataSource object) when persisting application data to the database using entity beans.

- Consider using a persistent JMS store to ensure that your JMS messages are not lost if a problem occurs before the message-driven beans process the messages on the JMS queue.

- You cannot, however, configure a transaction (XA) JDBC connection pool to be used with a JMS JDBC store. JMS must use a JDBC connection pool that uses a non-XA resource driver. JMS does the XA support in the layer above the JDBC driver.

This is because WebLogic JMS is its own resource manager. That is, JMS itself implements the XAResource and handles the transactions without depending on the database (even when the messages are stored in the database). This means that whenever you are using JMS and a database (even if it is the same database where the JMS messages are stored), then it is two-phase commit transaction.

- When configuring the persistent JMS store, you can persist JMS messages to a directory on the file system (called JMS file store) or to a database using JDBC (called JMS JDBC database store). If you want better performance and do not need the reliability of a database, BEA recommends you persist JMS messages to the file system.

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.

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 update the JMS tables in the Pointbase database.

Related Reading

- Introduction to WebLogic JDBC

- Managing JDBC Connectivity

- WebLogic JMS Fundamentals

- JMS: Configuring

- Using JavaMail with WebLogic Server Applications