Threads block on i/o (that is enters the waiting state) so that other threads may execute while the i/o
Operation is performed.
which containers use a border Layout as their default layout?
The window, Frame and Dialog classes use a border layout as their default layout.
Configuring JMS Using JNDI
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".
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".
New Features in WebLogic Server 7.0
WebLogic Messaging Bridge
The WebLogic Messaging Bridge is a part of WebLogic Server that forwards messages from a "source" destination to a "target" destination. Out-of-the-box adapters are provided so that thesource and/or target may be a JMS destination. Either end can be a JMS topic or queue, and could be a server running WebLogic Server 5.1 or higher, or a foreign JMS provider. The WebLogic Messaging Bridge also provides interoperability between different versions of WebLogic Server.
Container-Managed Transactions for Message-Driven Beans
A message-driven bean (MDB) is a special type of Enterprise Java Bean (EJB) that pulls messages from a JMS queue or topic. The EJB container (WebLogic Server) is responsible for connecting to the JMS provider, receiving messages, and passing them to the MDB in the proper transaction context. This allows asynchronous events to be processed by a J2EE-based application, which was not possible in a standard way before MDBs..
WebLogic Server has supported MDBs since WebLogic Server 6.0. Version 6.0 SP1 of the server added support for foreign JMS providers. However, container-managed transactions could only be used with WebLogic JMS, so a foreign JMS provider could not participate in the WebLogic transaction.
The WebLogic Messaging Bridge is a part of WebLogic Server that forwards messages from a "source" destination to a "target" destination. Out-of-the-box adapters are provided so that thesource and/or target may be a JMS destination. Either end can be a JMS topic or queue, and could be a server running WebLogic Server 5.1 or higher, or a foreign JMS provider. The WebLogic Messaging Bridge also provides interoperability between different versions of WebLogic Server.
Container-Managed Transactions for Message-Driven Beans
A message-driven bean (MDB) is a special type of Enterprise Java Bean (EJB) that pulls messages from a JMS queue or topic. The EJB container (WebLogic Server) is responsible for connecting to the JMS provider, receiving messages, and passing them to the MDB in the proper transaction context. This allows asynchronous events to be processed by a J2EE-based application, which was not possible in a standard way before MDBs..
WebLogic Server has supported MDBs since WebLogic Server 6.0. Version 6.0 SP1 of the server added support for foreign JMS providers. However, container-managed transactions could only be used with WebLogic JMS, so a foreign JMS provider could not participate in the WebLogic transaction.
Subscribe to:
Posts (Atom)