Programming WebLogic JMS
WebLogic JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform. It fully supports the JMS Specification and also provides numerous WebLogic JMS Extensions that go above and beyond the standard JMS APIs.
An enterprise messaging system, also referred to as message-oriented middleware (MOM), enables applications to communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.
WebLogic Server is fully compliant with version 1.0.2b of the JMS Specification, and can be used in production.
WebLogic JMS provides numerous WebLogic JMS Extension APIs that go above and beyond the standard JMS APIs specified by the JMS Specification. Moreover, it is tightly integrated into the WebLogic Server platform, allowing you to build highly-secure J2EE applications that can be easily monitored and administered through the WebLogic Server console. In addition to fully supporting XA transactions, WebLogic JMS also features high availability through its clustering and service migration features, while also providing seamless interoperability with other versions of WebLogic Server and third-party messaging providers.
The major components of the WebLogic JMS Server architecture, as illustrated in Figure 1-2, include:
The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to JMS destinations from any server in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, JMS topics and queues are still managed by WebLogic Server instances in the cluster.
For more information about configuring clustering for WebLogic JMS, see Configuring WebLogic JMS Clustering. For detailed information about WebLogic Server clustering, see Using WebLogic Server Clusters.
An administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by either enabling the default connection factories for each server instance in the cluster, or by configuring one or more connection factories and targeting them to one or more server instances in the cluster. This way, each connection factory can be deployed on multiple WebLogic Server instances.
The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. If requests for destinations are sent to a WebLogic Server instance that is hosting a connection factory, but which is not hosting a JMS server or destinations, the requests are forwarded by the connection factory to the appropriate WebLogic Server instance that is hosting the JMS server and destinations.
Connection factories are described in more detail in WebLogic JMS Fundamentals.
As an "exactly-once" service, WebLogic JMS takes advantage of the migration framework implemented in WebLogic Server for clustered environments. This allows WebLogic JMS to respond properly to migration requests and to bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. For more information, see Configuring Migratable Targets for JMS Servers.
When configured for the cluster, load balancing algorithms (round-robin-affinity, weight-based-affinity, or random-affinity), provide server affinity for JMS client connections. If a JMS application has a connection to a given server instance, JMS attempts to establish new JMS connections to the same server instance. For more information on server affinity, see "Load Balancing in a Cluster" in Using WebLogic Server Clusters.
Note: Automatic failover is not supported by WebLogic JMS for this release. For information about performing a manual failover, refer to Recovering from a WebLogic Server Failure.
In addition to the API specified by the Sun Microsystems JMS Specification, WebLogic JMS provides a public API, weblogic.jms.extensions, which includes classes and methods for the extensions described in the following table.
Dynamically create and delete a distributed destination (DD). These methods will also create or delete the DD queue or topic members on each specified JMS server instance, as well as a JMS template that will be used for all the member destinations.
"JMS Helper" Javadoc.
At approximately 400KB, the JMS thin application client (
wljmsclient.jar) file provides full WebLogic JMS functionality, yet greatly reduces the client-side WebLogic footprint by using a smaller library that contains only the set of supporting files required by client-side programs. The JMS thin client also requires using the standard WebLogic thin application client JAR (
wlclient.jar), around 300KB, which contains the base client support for clustering, security, and transactions, and failover. See WebLogic JMS Thin Client.
Using the Foreign JMS Server node on the Administration Console, you can quickly map a foreign (non-WebLogic Server) JMS provider so that its connection factories and destinations appear in the WebLogic JNDI tree as local JMS objects. A Foreign JMS Server configuration can also be used to reference remote instances of WebLogic Server in another cluster or domain in the local WebLogic JNDI tree. See "Simple Access to Remote or Foreign JMS Providers" in the Administration Console Online Help.
WebLogic Server now uses JMS wrappers that make it easier to use WebLogic JMS inside a J2EE component, such as an EJB or a servlet, while also providing a number of enhanced usability and performance features: automatic pooling of JMS connection and session objects (and some pooling of message producer objects as well); automatic transaction enlistment for WebLogic JMS implementations and for third-party JMS providers that support two-phase commit transactions (XA protocol); testing of the JMS connection, as well as re-establishment after a failure; and security credentials that are managed by the container. See Using JMS with EJBs and Servlets.
Active message expiration ensures that expired messages are cleaned up immediately. Moreover, expired message auditing gives you the option of tracking expired messages, either by logging when a message expires or by redirecting expired messages to a special destination. For more information, see "Handling Expired Messages" in the Administration Console Online Help.
The "Blocking Send" features help you avoid receiving message quota errors by temporarily blocking message producers from sending messages to a destination (queue or topic) when the destination has exceeded its specified maximum message quota. See "Avoiding Quota Exceptions by Blocking Message Producers" in the Administration Console Online Help.
As per the JMS Specification, all messages initially delivered to a consumer from a given producer are guaranteed to arrive at the consumer in the order in which they were produced. WebLogic JMS goes above and beyond this requirement by guaranteeing the correct ordering of redelivered messages as well. For more information, see Ordered Redelivery of Messages.
New JMS Helper extension methods enable you to dynamically delete JMS destinations. The JMS server removes the deleted destination in real time; therefore, it is unnecessary to redeploy the JMS server for the deletion to take effect. See Deleting Destinations Dynamically.
The Configuration Wizard is a Java application that creates WebLogic Server administration domain and server configurations. You can use the Configuration Wizard to configure such resources as JMS, database connectivity (JDBC), and security groups, security roles, and user accounts. You can also use the Configuration Wizard to modify existing domains. See "Configuring WebLogic Platform."
ServerSessionPoolFactory class in the
weblogic.jms package is deprecated in WebLogic Server 8.1 and is replaced by the
ServerSessionPoolFactory class in the
weblogic.jms.extensions package. Although BEA recommends using the new version in the
weblogic.jms.extensions package when binding a S
erverSessionPoolFactory into JNDI. However, for release 8.1 you can still perform the JNDI lookup with either version. For more information about server session pool factories, see Defining Server Session Pools or the weblogic.jms.extensions.ServerSessionPoolFactory Javadoc.
Instead, use JMS -> Stores node on the Administration Console or JMX to configure the JMS file store Synchronous Write Policy attribute. For more information about configuring the Synchronous Write Policy, see "Improving JMS File Store Performance" in the Administration Console Online Help.
The "User Transactions Enabled" and "Server Side XA Enabled" attributes are deprecated in WebLogic Server 8.1 for user-defined JMS connection factories. Therefore, to enable an XA connection factory for JTA user-transactions, you need only set the "XA Connection Factory Enabled" attribute. An XA factory is not required for transacted sessions. For more information about configuring a connection factory, see "Configuring a JMS Connection Factory" in the Administration Console Online Help.