[ Team LiB ] Previous Section Next Section

Advanced WebLogic JMS Configuration

Thus far in this chapter we've learned about enterprise messaging, the JMS APIs, and how to configure BEA WebLogic Server as a JMS provider. Although the default configurations offered by WebLogic for JMS messaging are fine for many applications, WebLogic also offers a variety of other configuration options that allow for more sophisticated enterprise messaging applications. This section describes those additional features and how to configure WebLogic to use them. In addition to the features described in this section, WebLogic also provides support for clustered JMS services and message bridging between applications. Chapter 36, "Installing, Configuring, and Deploying WebLogic Server Clusters," discusses these more advanced features as other prerequisite features and concepts are introduced.

JMS Persistent Stores

The BEA WebLogic Server enables you to configure a persistent store for messages managed by a WebLogic JMS server. Such persistence increases the reliability of your messaging applications because message data will be persisted to a store, allowing for the recovery of messages even in the event of server and application failures. Durable topic subscribers and paging of messages can also leverage use of a persistent store. First you must open the Administration Console. By clicking on JMSStores in the left browser pane, you can opt to create a JDBC-based or file-based persistent store, as shown in Figure 12.30.

Figure 12.30. Administering JMS stores.


As an example, if you select Configure a New JMS JDBC Store, you are presented with the screen depicted in Figure 12.31. After entering a name for your JMS store, selecting a valid JDBC connection pool, and establishing any table prefixes, you then must click the Create button to establish the JMS store.

Figure 12.31. Configuring JMS stores.


As exemplified in Figure 12.32, you can then associate JMS servers with a particular JMS store such as the one we just created. By default, destinations within a particular JMS server use the default persistent store associated with the JMS server. Figure 12.32 illustrates the screen associated with configuring JMS destinations, whereby this default association can be overridden via the Enable Store option.

Figure 12.32. Associating JMS servers with JMS stores.


Messages are persisted for topics after the persistent store is configured. A subscriber can retrieve such messages if it has been created using the method TopicSession.createDurableSubscriber().

Destination Keys

Although messaging is an asynchronous mechanism, a certain level of control might be desired for how messages are handled by WebLogic Server. In this consideration, WebLogic enables you to specify how messages are sorted within a particular JMS destination. This can be achieved by applying a destination key to a destination. Let's see how this is done. Figure 12.33 shows the screen that you are presented when you select JMSDestination Keys in the left browser pane.

Figure 12.33. Administering JMS destination keys.


After selecting Configure a New JMS Destination Key, you are presented with the screen shown in Figure 12.34. The name of the key, message field by which sorting should occur, key type, and the direction of sort are all configured via this screen.

Figure 12.34. Configuring JMS destination keys.


After you select Create, the key will be available as an option for sorting via the destinations configuration screen as depicted in Figure 12.35.

Figure 12.35. Associating JMS destination keys with destinations.


Foreign JMS Servers

There might be times when your WebLogic applications will want to tap the resources of a third-party messaging service. Those external messaging services are referred to as foreign JMS servers. WebLogic provides a rather straightforward means to achieve this integration. Although any Java program can access a JMS server directly by accessing the JMS connection factory and destinations in the remote JNDI server, WebLogic Server provides an easier way of doing this for applications running inside of the server. In such a way, the foreign JMS provider's connection factories and destinations can be accessed by WebLogic applications as local JMS objects. Figure 12.36 depicts the initial screen presented to you when you select JMSForeign JMS Servers in the left browser pane.

Figure 12.36. Administering foreign JMS servers.


After selecting Configure a New Foreign JMS Server, you are presented with a screen akin to Figure 12.37. Here you must enter a reference name for your foreign server, the JNDI factory class name, the JNDI URL, and any other JNDI properties to be passed to your foreign JMS service provider. After configuring your foreign service provider, you must select the Target and Deploy tab in the center pane for the foreign service provider and select a WebLogic Server or cluster to which you will deploy the provider.

Figure 12.37. Configuring foreign JMS servers.


After deploying the foreign provider, connection factories and destinations associated with the service can be configured from within WebLogic. Figure 12.38 depicts a case in which a connection factory is being configured for a foreign JMS provider after selecting Foreign JMSConnection Factories beneath your foreign JMS provider listed in the left browser pane and then selecting Configure a New Foreign JMSConnection Factory in the center pane.

Figure 12.38. Configuring foreign JMS connection factories.


Figure 12.39 depicts the case in which a destination is being configured for a foreign JMS provider after selecting Foreign JMSDestinations beneath your foreign JMS provider listed in the left browser pane and then selecting Configure a New Foreign JMSDestination in the center pane.

Figure 12.39. Configuring foreign JMS destination.


After configuring your foreign JMS provider with your WebLogic Server, your WebLogic applications can then send and receive messages through such a provider just as they would with the WebLogic JMS provider. WebLogic applications acting as message producers can use the same JMS APIs that they use to interact with the WebLogic JMS provider as they would use to interact with a foreign JMS provider. Message-driven EJBs can also act as message consumers for messages received by foreign JMS providers as they would for messages received by a WebLogic JMS provider.

JMS Templates

Throughout this chapter, we have examined various parameters that are entered into WebLogic's Administration Console and used to configure JMS applications. As you can probably imagine, when managing multiple JMS servers and destinations, the large number of parameters involved with such configuration may yield errors or affect repeatability of configuration. WebLogic Server enables you to create JMS configuration templates that contain common configuration values that can be applied to multiple JMS configurations. When you select JMS->Templates in the left browser pane, an initial template configuration screen is presented as illustrated in Figure 12.40.

Figure 12.40. Administering JMS templates.


After selecting Configure a New JMS Template, you are presented with the basic configuration screen as illustrated in Figure 12.41. Tabs for basic configuration, thresholds and quotas, overrides, redelivery policies, and message expiration policies are all available for configuration.

Figure 12.41. Configuring JMS templates.


After creating a JMS template, it may be associated with a JMS server (as depicted in Figure 12.42) or with a destination within a server (as depicted in Figure 12.43). Although such associations can be made with servers and destinations after they are created, such templates are most handy when initially configuring new servers and destinations.

Figure 12.42. Associating JMS templates with JMS servers.


Figure 12.43. Associating JMS templates with JMS destinations.


    [ Team LiB ] Previous Section Next Section