A program written against the JMS API can work with any vendor's implementation of JMS, as
long as it complies with the JMS specification. This is possible when the JMS client program uses
JNDI (the Java Naming and Directory Interface) to look up the initial "Connection Factory" object. Once this object has been looked up from the directory, it is used to create the "Connection" object, then the "Session" object, and so on until all the necessary objects are created. Since all these objects implement the standard JMS interfaces, any program that uses only the standard interfaces can interoperate with any compliant JMS provider. Plus, since the connection factory is stored in JNDI by the provider itself, it provides a place for the provider to put its own configuration information, such as the location of the server, or any special options it may implement.
Destination objects – queues and topics – can also be stored in JNDI. This gives each provider a way to associate special configuration parameters with each destination that may not be a part of the standard JMS interface.
JNDI is also a standard Java interface. Therefore, a client written to this standard API can look up information from any type of directory that implements the standard Java interfaces.
WebLogic Server uses JMS and JNDI when it interfaces with JMS inside the WebLogic Messaging Bridge, or when receiving messages for a message-driven bean. Stand-alone JMS clients,session beans, and servlets can also use JNDI to get access to a JMS provider.
Since WebLogic Server uses JNDI to look up the connection factory and destination objects, it can be configured to work with any JMS provider that properly implements the JMS and JNDI specifications.
In order for WebLogic Server to look up the JMS connection factory from JNDI, four pieces of information are needed. These are described below, and examples are provided later in this document:
Initial context factory. This is the name of the JNDI class that will be created to perform the lookup. This class may be part of the JDK, it may be provided by Sun Microsystems, or it may be provided by the JMS vendor itself.
Provider URL. This URL is used to tell the initial context factory where to find the directory information. It may refer to a server using a protocol like LDAP, or it may refer to a file in the filesystem, or something else.Connection factory JNDI name. This is the name of the connection factory object that is stored in JNDI. Each JMS provider creates its own tool to create this object and store it in JNDI. Once it is stored there, any JMS client program (including WebLogic Server) can look up the object.
Destination JNDI name. This is the object that represents a JMS destination – a queue or a topic – as stored in JNDI. Like the connection factory, each JMS provider will provide its own tool to create the object and place it in JNDI.
When setting up WebLogic Server to access a foreign JMS provider, these four parameters must be specified. The remaining topics in this section of this document describe how to use various JNDI providers. After that, section 3 describes the various JMS providers. You will need information from both sections to set up a particular interaction between JMS and WebLogic Server.
In this section, there is information about a few basic types of JNDI providers. General-purpose JNDI providers. The filesystem and LDAP providers are examples of general-purpose JNDI providers. They may be used to store various types of Java objects on behalf of many different types of servers. Normally, once an object is stored in a general-purpose JNDI provider, it remains there in persistent form and may be looked up at a later time after a server restart. MQSeries and SonicMQ are examples of JMS providers that rely on a general-purpose JNDI provider in order to provide interoperability with WebLogic Server.
Vendor-specific JNDI providers. Some JMS providers, such as FioranoMQ and IBus MessageServer, provide a JNDI interface of their own. JMS connection factory and destination objects may be looked up using this provider, usually without any additional configuration
required on the client or on the server. However, these providers only allow JNDI access to their own objects, and cannot be used to store additional information.
WebLogic JNDI. A JNDI provider is built in to WebLogic Server. It combines some aspects of a general-purpose JNDI provider with those of a vendor-specific provider. Like a generalpurpose JNDI provider, it can be used to store all kinds of objects, and users can use it to store their own objects as well. And like a vendor-specific provider, it is built in to WebLogic Server and requires no additional configuration. JNDI objects that are created by the server itself, such as WebLogic Server JMS connection factory and destination objects, are automatically re-created when the server starts up. However, other objects that users store in JNDI are not automatically re-created, and must be inserted into JNDI every time the server starts up using a mechanism such as a WebLogic "startup class".
No comments:
Post a Comment