![]() ![]() ![]() ![]() ![]() ![]() |
This tutorial describes how to configure the WebLogic Server resources required to deploy and run the MedRec application on the MedRec server. These resources include:
The tutorial includes the following sections:
Before starting this tutorial:
Follow these steps to configure WebLogic Server resources for the MedRec server:
You use the Administration Console to create the WebLogic Server resources used by the MedRec application suite.
http://
host
:7101/console
where host
refers to the computer on which MedRecServer
is running. If your browser is on the same computer as MedRecServer, then you can use the URL http://localhost:7101/console
.
weblogic
for both the username and password and click Log In.You can also open the Administration Console from the Windows Start menu:
StartAll Programs
BEA Products
User Projects
MedRecDomain
Admin Server Console
In WebLogic Server, you configure database connectivity by adding JDBC data sources to your WebLogic domain. A data source is a J2EE standard method of configuring connectivity to a database. A data source can be deployed by itself as a stand-alone module, or deployed as part of an Enterprise application as a packaged module.
Each WebLogic data source contains a pool of database connections. Applications look up the data source in the JNDI tree or in the local application context and then reserve a database connection with the getConnection
method. Data sources and their connection pools provide connection management processes that help keep your system running and performing well.
This procedure describes how to create two stand-alone JDBC data sources: the first uses an XA JDBC driver and the second one does not. Typically you always use an XA JDBC driver when creating a data source. However, because JMS JDBC stores do not support XA resource drivers (WebLogic JMS implements its own XA resource), a second non-XA data source is needed. A later procedure shows how to associate the non-XA data source to a JMS JDBC store.
This JDBC data source will be used to create a JDBC store, which requires that the data source not support global transactions.
Text field values are based on information you have already provided as well as default PointBase values (such as the Pointbase driver class name of com.pointbase.jdbc.jdbcUniversalDriver
).
Click Test Configuration to test the connection; the message Connection test succeeded
appears in the Messages pane if you have configured the data source correctly.
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. |
The new data source is listed in the Data Sources table.
The values of the text fields are based on information you have already provided as well as default Pointbase values (such as the Pointbase XA driver class name of com.pointbase.xa.xaDataSource
).
Click Test Configuration to test the connection; the message Connection test succeeded
appears in the Messages pane if you have configured the data source correctly.
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. |
The new data source is listed in the Data Sources table.
The Web Services reliable messaging feature uses a persistent store to store its messages. The MedRec tutorials describe how to use a file store to store the messages; you can also use a JDBC store as described in the next step.
Note: | WebLogic Web Services reliable messaging is a service-to-service feature, which means that one client Web Service invokes another Web Service reliably. Typically each Web Service is deployed to two different WebLogic Server instances; each server instance in turn has its own store-and-forward (SAF) agent and persistent store. However, because these tutorials assume a single-server domain for ease of development, both Web Services are deployed to the same server, and thus use the same SAF agent and persistent store. |
MedRecWseeFileStore
.MedRecServer
.medrecWseeFileStore
.Persistent stores are used to store persistent messages. This JMS JDBC store uses the non-XA data source you created in Step 2: Create the stand-alone JDBC data sources.
MedRecJMSJDBCStore
.MedRecServer
.MedRecGlobalDataSource
.MedRec
.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.
MedRecJMSServer
.MedRecJMSJDBCStore
.MedRecServer
. MedRecWseeJMSServer
.MedRecWseeFileStore
.MedRecServer
.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.
You configure JMS queues by first creating a stand-alone JMS module and then configuring it with a JMS queue, as described in the following procedure.
In addition to the queue that is part of the stand-alone JMS module, the medrecEar
application uses the following JMS queues configured as part of a packaged JMS module,
These application-scoped JMS queues are first registered in the weblogic-application.xml
deployment descriptor of the medrecEar
application, and then described in XML files.
MedRecServer
.MedRecWseeJMSServer
. MedRecWseeJMSServer
.The Store-and-Forward (SAF) service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. In the MedRec application, the SAF service is used internally by the Web Services that have been configured with reliable messaging.
Note: | WebLogic Web Services reliable messaging is a service-to-service feature, which means that one client Web Service invokes another Web Service reliably. Typically each Web Service is deployed to two different WebLogic Server instances; each server instance in turn has its own SAF agent and persistent store. However, because these tutorials assume a single-server domain for ease of development, both Web Services are deployed to the same server, and thus use the same SAF agent. |
MedRecServer
.WebLogic Server includes the JavaMail API version 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 pre-configure.
mail/MedRecMailSession
.mail/MedRecMailSession
.mail/MedRecMailSession
.mail.user
and mail.host
properties.
For example, if you want 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
MedRecServer
.The MedRec Custom DBMS 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.
myrealm
entry of the Realms table.MedRecSampleAuthenticator
.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.
MedRecGlobalDataSourceXA
.com.bea.medrec.security.MedRecDBMSPlugin
.
This plug-in class is physically located in the MedRecDBMSPlugin.jar
file that you added to WebLogic Server's CLASSPATH
in Tutorial 1: Creating a WebLogic Domain and Server Instance for Development.
myrealm
entry of the Realms table.DefaultAuthenticator
.myrealm
entry of the Realms table.Because WebLogic Server cycles through available Authentication providers, this step reorders 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).
You must restart the MedRecServer for these changes to take full effect. For details, see the next tutorial, Tutorial 4: Using WebLogic Server Development Mode.
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 that you use a JDBC JMS store.
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
application-scoped 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 data source 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.
The medrecEar
application has two flavors of Web Services that the physicianEar
application invokes: reliable and non-reliable. The reliable Web Service uses the store-and-forward agent and filestore internally to ensure that the messages are delivered reliably.
The WebLogic Server security framework cycles through the three configured providers (DefaultAuthenticator
, MedRecSamplesAuthenticator
, and DefaultIdentityAsserter
) during patient authentication.
![]() ![]() ![]() |