WebLogic Server Frequently Asked Questions
The J2EE standards for JMS (messaging), JTA (transaction), and JNDI (naming) work together to provide reliable java-to-java messaging between different host machines and even different vendors. BEA WebLogic Server provides a variety of tools that leverage these APIs to aid integrating remote JMS providers into a local application.
A. A remote JMS provider is a JMS server that is hosted outside a local stand-alone WebLogic server or outside WebLogic server cluster. The remote JMS server may be a WebLogic or a non-WebLogic (foreign) JMS server.
A. JNDI (Java Naming and Directory Interface) is a J2EE lookup service that maps names to services and resources. JNDI provides a directory of advertised resources that exist on a particular stand-alone (unclustered) WebLogic server, or within a WebLogic server cluster. Examples of such resources include JMS connection factories, JMS destinations, JDBC (database) data sources, and application EJBs.
A client connecting to any WebLogic server in a WebLogic cluster can transparently reference any JNDI advertised service or resource hosted on any WebLogic server within the cluster. The client doesn't require explicit knowledge of which particular WebLogic server in the cluster hosts a desired resource.
A. A JMS connection factory is a named entity resource stored in JNDI. Applications, message driven beans (MDBs), and messaging bridges lookup a JMS connection factory in JNDI and use it to create JMS connections. JMS connections are used in turn to create JMS sessions, producers, and consumers that can send or receive messages.
A. JMS connection-ids are used to name JMS client connections. Durable subscribers require named connections, otherwise connections are typically unnamed. Note that within a clustered set of servers or stand-alone server, only one JMS client connection may use a particular named connection at a time. An attempt to create new connection with the same name as an existing connection will fail.
A. A topic subscription can be thought of as an internal queue of messages waiting to be delivered to a particular subscriber. This internal queue accumulates copies of each message published to the topic after the subscription was created. Conversely, it does not accumulate messages that were sent before the subscription was created. Subscriptions are not sharable, only one subscriber may subscribe to a particular subscription at a time.
A. A non-durable subscriber creates unnamed subscriptions that exist only for the life of the JMS client. Messages in a non-durable subscription are never persisted—even when the message's publisher specifies a persistent quality of service (QOS). Shutting down a JMS server terminates all non-durable subscriptions.
A. A durable subscriber creates named subscriptions that continue to exist even after the durable subscriber exits or the server reboots. A durable subscriber connects to its subscription by specifying topic-name, connection-id, and subscriber-id. Together, the connection-id and subscriber-id uniquely name the subscriber's subscription within a cluster. A copy of each persistent message published to a topic is persisted to each of the topic's durable subscriptions. In the event of a server crash and restart, durable subscriptions and their unconsumed persistent messages are recovered.
A. A transaction is a set of distinct application operations that must be treated as an atomic unit. To maintain consistency, all operations in a transaction must either all succeed or all fail. See "Introducing Transactions" in Programming WebLogic JTA.
A. Integration applications often use transactions to assure data consistency. For example, to assure that a message is forwarded exactly-once, a single transaction is often used to encompass the two operations of receiving the message from its source destination and sending to the target destination. Transactions are also often used to ensure atomicity of updating a database and performing a messaging operation.
A. In J2EE, the terms JTA transaction, XA transaction, user transaction, and global transaction are often used interchangeably to refer to a single global transaction. Such a transaction may include operations on multiple different XA capable resources and even different resource types. A JTA transaction is always associated with the current thread, and may be passed from server to server as one application calls another. A common example of an XA transaction is one that includes both a WebLogic JMS operation and a JDBC (database) operation.
A. A JMS local transaction is a transacion in which only a single resource or service may participate. A JMS local transaction is associated with a particular JMS session where the destinations of a single vendor participate. Unlike XA transactions, a database operation can not participate in a JMS local transaction.
A. Local transactions are enabled by a JMS specific API called
transacted sessions. For vendors other than WebLogic JMS, the scope of a transacted session is typically limited to a single JMS server. In WebLogic JMS, multiple JMS operations on multiple destinations within an entire cluster can participate in a single transacted session's transaction. In other words, it is scoped to a WebLogic cluster and no remote JMS provider to the JMS session's cluster can participate in a transaction. See the WebLogic JMS Performance Guide white-paper available on the JMS topic page.
To determine if a non-WebLogic vendor's JMS connection factory is XA capable, check the vendor documentation. Remember, support for transacted sessions (local transactions) does not imply support for global/XA transactions.
t3://hostaddress:port. If you are tunneling over HTTP, begin the URL with
t3. No URL is required for server application code that accesses a WebLogic JMS server that resides on the same WebLogic server or WebLogic cluster as the application.
weblogic.jms.ConnectionFactory—a non-XA capable factory.
weblogic.jms.XAConnectionFactory—an XA-capable factory
weblogic.jms.MessageDrivenBeanConnectionFactory—an XA-capable factory for message driven EJBs.
A. The preferred method for locating JMS provider connection factories and destinations is to use a standard J2EE JNDI lookup. Occasionally a non-WebLogic JMS provider's JNDI service is hard to use or unreliable. The solution is to create a startup class or load-on-start servlet that runs on a WebLogic server that does the following:
For sample code, see "Creating Foreign JNDI Objects in a Startup Class" in Using Foreign JMS Providers with WebLogic Server white-paper available from the JMS topic page.
A. Remote and local JMS resources, such as client connections and sessions, are often pooled to improve performance. Message driven EJBs automatically pool their internal JMS consumers. JMS consumers and producers accessed through resource-references are also automatically pooled. For more information on resource pooling, including information on writing a custom pool, see the WebLogic JMS Performance Guide white-paper available on the JMS topic page.
A. All WebLogic server releases 6.1 and higher interoperate freely between releases. For example, a WebLogic 8.1 JMS client can send messages directly to a 6.1 JMS server and vice versa. A Messaging Bridge can be used to forward WebLogic 5.1 JMS messages to and from WebLogic server releases 6.1 and higher.
A. Use a message driven EJB. Synchronous receives are not recommended because they idle a server side thread while the receiver blocks waiting for a message. See What is a Message Driven EJB (MDB)? and When should I use a MDB?
A. Use a resource reference. It provides pooling and automatic enlistment. See What are JMS resource references? and What advantages do JMS resource references provide? In limited cases where wrappers are not sufficient, you can write your own pooling code. See the WebLogic JMS Performance Guide white-paper available on the JMS topic page.
If the target destination is remote, consider adding a local destination and messaging bridge to implement a store-and-forward high availability design. See What is a messaging bridge? and When should I use a messaging bridge?.
Another best practice is to use foreign JMS server definitions. Foreign JMS server definitions allow an application's JMS resources to be administratively changed and avoid the problem of hard-coding URLs into application code. In addition, foreign JMS server definitions are required to enable resource references to reference remote JMS providers. See What are Foreign JMS Server Definitions? and When is it best to use a Foreign JMS Server Definition?.
A. If the destination is not provided by WebLogic Server, and there is a need to include operations on the destination in a global transaction, use a server proxy to encapsulate JMS operations on the foreign vendor in an EJB. Applications running on WebLogic server have facilities to enlist non-WebLogic JMS providers that are transaction (XA) capable with the current transaction. See How do I receive messages from a remote a JMS provider from within an EJB or Servlet? and How do I send messages to a remote JMS provider from within an EJB or Servlet?.
If you need store-and-forward capability, consider sending to local destinations and using messaging bridges to forward the message to the foreign destination. See What is a messaging bridge? and When should I use a messaging bridge?.
Another option is to simply use the remote vendor's JNDI and JMS API directly or configuring foreign JMS providers to avoid hard-coding references to them. You will need to add the foreign provider's class libraries to the client's class-path.
A. Foreign JMS server definitions are an administratively configured symbolic link between a JNDI object in a remote JNDI directory, such as a JMS connection factory or destination object, and a JNDI name in the JNDI name space for a stand-alone WebLogic Server or a WebLogic cluster. They can be configured using the Administration console, standard JMX MBean APIs, or programmatically using scripting. See "Simple Access to Remote or Foreign JMS Providers in the Administration Console Online Help.
A. For this release, a Foreign JMS Server definition conveniently moves JMS JNDI parameters into one central place. You can share one definition between EJBs, servlets, and messaging bridges. You can change a definition without recompiling or changing deployment descriptors. They are especially useful for:
A. Resource references are specified by servlet and EJB application developers and packaged with an application. They are easy-to-use and provide a level of indirection that lets applications reference JNDI names defined in an EJB descriptor rather than hard-coding JNDI names directly into application source code.
Inside an EJB or a servlet application code, use JMS resource references by including resource-ref elements in the deployment descriptors and then use JNDI a context to look them up using the syntax
Resource references provide no functionality outside of application code, and therefore are not useful for configuring a message driven EJB's source destination or a messaging bridge's source or target destinations.
For WebLogic documentation on JMS resource-reference pooling, see "Using JMS with EJBs and Servlets" in Programming WebLogic JMS.
A. To enable resource references to reference remote JMS providers, they must be used in conjunction with a foreign JMS definition. This is because resources references do not provide a place to specify a URL or initial context factory. See What are Foreign JMS Server Definitions?.
A. For non-transactional cases, do not use a global transaction (XA) capable connection factory. This will impact messaging performance. If you do, the resource reference will automatically begin and commit an internal transaction for each messaging operation. See What is a transaction?.
A. Messaging bridges are administratively configured services that run on a WebLogic server. They automatically forward messages from a configured source JMS destination to a configured target JMS destination. These destinations can be on different servers than the bridge and can even be foreign (non-WebLogic) destinations. Each bridge destination is configured using the four common properties of a remote provider:
A. Typically, messaging bridges are used to provide store-and-forward high availability design requirements. A messaging bridge is configured to consume from a sender's local destination and forward it to the sender's actual target remote destination. This provides high availability because the sender is still able to send messages to its local destination even when the target remote destination is unreachable. When a remote destination is not reachable, the local destination automatically begins to store messages until the bridge is able to forward them to the target destination when the target becomes available again.
A. Message Driven EJBs are EJB containers that internally use standard JMS APIs to asynchronously receive messages from local, remote, or even foreign JMS destinations and then call application code to process the messages. MDBs have the following characteristics:
For more information, see "Message-Driven EJBs" in Programming WebLogic Enterprise JavaBeans.
A. Configure MDBs to directly consume from their source destination rather than insert a messaging bridge between them. MDBs automatically retry connecting to their source destination if the source destination is inaccessible, so there is no need to insert a messaging bridge in the message path to provide higher availability. Introducing a messaging bridge may have a performance impact. See When should I avoid using a messaging bridge?.
dispatch-policydescriptor fields. WebLogic may create fewer concurrent instances than
max-beans-in-free-pooldepending on the number of available server threads in the MDB's thread pool.
Requiredand the JMS connection factory is XA enabled. Failure to follow these steps will result in the MDB being non-transactional. The default WebLogic setting for a MDB connection factory is XA enabled. The MDB automatically begins a transaction and automatically enlists the received message in the transaction.
A. For general information on WebLogic JMS see the JMS topic page.