Consultor Eletrônico



Kbase 20155: SonicMQ and JMS Administered Objects
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   7/5/2001
SUMMARY:

This solution applies to Progress SonicMQ Versions 2000.x and 3.x, and
discusses how and why to use JMS administered objects.

EXPLANATION:

JMS administered objects are objects containing JMS configuration information that are created by a JMS administrator and later used by JMS clients. JMS administered objects are stored in a JMS administered object store. This object store can be a file system, or a Java Naming and Directory Interface (JNDI) name space. The API used by the client depends upon the type of object store used.

If you use a file system as your object store, each object is stored as a separate file named <object name>.sjo, where "sjo" connotes "serialized Java object".

For information on JNDI service providers, see:

http://java.sun.com/products/jndi/serviceproviders.html

JMS defines two administered objects, Destination and
ConnectionFactory. In the Publish and Subscribe domain (Pub/Sub), a Destination is a Topic and a ConnectionFactory is a TopicConnectionFactory. In the Point-to-Point domain (PTP), a Destination is a Queue and a ConnectionFactory is a QueueConnectionFactory.

A ConnectionFactory encapsulates a set of connection configuration parameters under a symbolic object name:

- Host
- Port
- Protocol
- User name
- Password
- Connection ID

A client using a JMS administered ConnectionFactory looks up the Connection in the object store via its object name, and does not need to know the values of these parameters.

This has two advantages:

1) Transparency

If the connection information must change, it can be
done in the object store once for all clients that need
to use this information; the client application is not
affected.

2) Portability

If the client application is deployed to a system
that requires a different connection configuration, the
connection can be configured in the object store; as in
the case above, the client application need not be
changed.


When a JMS client uses a Queue stored as a JMS administered
Destination object, it is important to remember that any Queue created on the client must also be created on the broker, regardless of whether the client uses a JMS administered Queue or creates one directly using the JMS API.

You can create JMS administered objects using SonicMQ Explorer, or the SonicMQ Admin tool. To use a JMS administered object store, you must first connect to it. You can only connect to one object store at a time.

Step by step details on how to connect to a JMS administered object store, and to create and store JMS administered objects in that object store, are provided in the SonicMQ Installation and Administration
Guide (see references below).

References to Written Documentation:

SonicMQ Installation and Administration Guide