|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
A ConnectionFactory encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a Connection with a JMS provider.
ConnectionFactory objects support concurrent use.
A ConnectionFactory is a JMS administered object.
JMS administered objects are objects containing JMS configuration information that are created by a JMS administrator and later used by JMS clients. They make it practical to administer JMS in the enterprise.
Although the interfaces for administered objects do not explicitly depend on JNDI, JMS establishes the convention that JMS clients find them by looking them up in a JNDI namespace.
An administrator can place an administered object anywhere in a namespace. JMS does not define a naming policy.
It is expected that JMS providers will provide the tools an
administrator needs to create and configure administered objects in a
JNDI namespace. JMS provider implementations of administered objects
should be both javax.jndi.Referenceable
and
java.io.Serializable
so that they can be stored in all
JNDI naming contexts. In addition, it is recommended that these
implementations follow the JavaBeans(TM) design patterns.
This strategy provides several benefits:
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by JNDI itself.
Clients should think of administered objects as local Java objects. Looking them up should not have any hidden side affects or use surprising amounts of local resources.
QueueConnectionFactory
,
TopicConnectionFactory
|
|||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |