|
|
Administration tools |
|
Authentication |
Authenticate users seeking a connection to
the broker. The Message Queue service allows users to connect to the broker
by validating their name and password against values stored in a user repository.
The repository can be a flat-file repository shipped with Message Queue or an
LDAP repository (LDAP v2 or v3 protocol). To Use
Create a user repository or use the default instance.
Use the imqusermgr tool to populate the repository.
JAAS-Based Authentication Application clients can also use authentication services
based on the Java Authentication and Authorization Service (JAAS), which allows you to plug
in a variety of services into the broker to authenticate Message Queue clients.
The JAAS API is a core API in J2SE and therefore it
is an integral part of Message Queue's runtime environment. To Use
The JAAS provider supplies a login module class that implements the authentication service.
Obtain JAAS configuration file and specify its location using a system property.
Configure broker properties that relate to JAAS support.
Reference Authentication and Authorization Chapter 9, Configuring and Managing Security Services, in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Authorization |
|
Automatic reconnect |
|
Broker clusters |
The administrator
can balance client connections and message delivery across a number of broker instances
by grouping those instances into a broker cluster. The Message Queue service supports
two kinds of clusters: conventional clusters and high availability clusters To Use Conventional Clusters
Specify cluster configuration properties for each broker in the cluster. Specify properties that are the same for all brokers using a cluster configuration file.
If there is a master broker, start the master broker
Start the other brokers in the cluster.
To Use Enhanced Clusters
Specify cluster configuration properties for each broker in the cluster (including JDBC-related properties). Specify properties that are the same for all brokers using a cluster configuration file.
Install your JDBC driver's .jar file in the appropriate directory location.
Use the imqdbmgr tool to create the database schema for the highly available data store.
Start the brokers in the cluster.
Reference Chapter 4, Broker Clusters Chapter 10, Configuring and Managing Broker Clusters, in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Broker configuration |
|
C client support, including support for
distributed transactions. |
C clients can use Message Queue messaging services to send and
receive messages. The C API enables legacy C applications and C++ applications to participate
in JMS-based messaging. Message Queue’s C API is supported by a C client
runtime that supports most of the standard JMS functionality, with the exception of
the following: the use of administered objects; map, stream, or object message body types;
distributed transactions; and queue browsers. The C client runtime also does not support
most of Message Queue’s enterprise features.The Message Queue C-API supports the XA interface
(between a distributed transaction manager and Message Queue as a XA-compliant resource manager),
allowing Message Queue C-API clients running in a distributed transaction processing environment (such
as BEA Tuxedo) to participate in distributed transactions. Reference Java and C Clients Oracle GlassFish Server Message Queue 4.5 Developer’s Guide for C Clients |
Client runtime logging |
Java clients can
use all the J2SE 1.4 logging facilities to configure how the Message Queue
client runtime outputs its logging information. Clients can choose to log the following
events: changes in connection state and miscellaneous connection activities, session-related events, the creation
of producers, consumers, and destinations, and the consumption and production of messages. Java
clients can configure logging programmatically or by using configuration files. Reference Client Runtime Logging in Oracle GlassFish Server Message Queue 4.5 Developer’s Guide for Java Clients |
Compressed messages |
|
Configurable persistence |
|
Configurable physical destinations |
The administrator can define some messaging behavior by
setting physical destination properties when creating destinations. The following behavior can be configured for
any destination: the maximum number of unconsumed messages or the maximum amount of
memory allowed for such messages, which messages the broker should reject when memory
limits are reached, the maximum number of producers and consumers, the maximum message
size, the maximum number of messages delivered in a single batch, whether the
destination can deliver only to local consumers, and whether dead messages on the
destination can be moved to the dead message queue. Reference Message Delivery Services Configuring and Managing Physical Destinations in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Connection event notification |
|
Connection ping |
|
Dead message queue |
|
HTTP connections |
Java clients can create HTTP connections to the broker. HTTP
transport allows messages to be delivered through firewalls. Message Queue implements HTTP support
using an HTTP tunnel servlet that runs in a web server environment. Messages
produced by a client are wrapped by the client runtime as HTTP
requests and delivered over HTTP through a firewall to the tunnel servlet. The
tunnel servlet extracts the JMS message from the HTTP request and delivers the
message over TCP/IP to the broker. To Use
Deploy HTTP tunnel servlet on a web server.
Configure broker’s httpjms connection service and start the broker.
Configure HTTP connection.
Obtain an HTTP connection to the broker. (Java clients only.)
Reference Connection Services Appendix C, HTTP/HTTPS Support, in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Interactive monitoring |
|
Java EE resource
adapters |
|
Java ES Monitoring Framework support |
The Java ES Monitoring Framework allows administrators
to use the same interface to manage any and all Java ES components.
If you are using Message Queue with other Java ES components, it might
be more convenient to manage these from a single console. Administrators can use
the Sun Java System Monitoring Console to view performance statistics, create rules to
monitor automatically, and acknowledge alarms. To enable Java ES monitoring, you must do
the following:
Install and configure the components in your deployment; for example, Message Queue and the application server.
Enable and configure the Monitoring Framework for all your monitored components.
Install the Monitoring Console on a separate host, start the master agent, and then start the web server.
For information, see the Sun Java Enterprise System Monitoring Guide. |
JMS Bridge Service |
The JMS bridge service enables
a Message Queue broker to map its destinations to destinations in external JMS
providers, effectively allowing the Message Queue broker to communicate with clients of the
external JMS provider. The JMS bridge service supports any number of uniquely named
JMS bridges in a broker. Each bridge consists of two primary components:
One or more links that each map a destination in the Message Queue broker to a destination in an external JMS provider or in another Message Queue broker. To provide destination mapping, each link consists of a source that specifies the destination from which the JMS bridge receives messages and a target that specifies the destination to which the JMS bridge forwards messages received from the source.
A built-in Dead Message Queue where undeliverable messages are sent. Additional, special-purpose DMQs can also be specified.
Reference Configuring and Managing JMS Bridge Services in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
JMX-Based Administration |
Java
clients can use the JMX API to monitor and manage broker resources: the
broker, services, connections, destinations, consumers, producers, and so on. You can use JMX-based
administration in different ways to monitor application performance, to configure and monitor broker
services, to automate tasks, or to write custom tools. Reference JMX-Based Administration Appendix D, JMX Support, in Oracle GlassFish Server Message Queue 4.5 Administration Guide Oracle GlassFish Server Message Queue 4.5 Developer’s Guide for JMX Clients |
JNDI service provider support |
|
LDAP Server support |
An administrator can use an LDAP server as a
Message Queue administered object store and as a user repository (needed for authentication).
By default Message Queue provides file-based storage for this data. To Use as an Administered Object Store
Use the tools provided by the LDAP vendor to set up the LDAP server.
Set the LDAP-related broker properties to define the initial context and the location of the object store.
Set the LDAP-related broker properties that relate to securing the LDAP server operations.
Reference Chapter 9, Configuring and Managing Security Services, in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Memory resource management |
The administrator
can configure the following behavior:
Set properties on a destination to specify the maximum number of producers, the maximum number of messages, and the maximum size of any one message.
Set properties on a destination to control message flow.
Set properties on a destination to manage message flow for each destination.
Set properties on the broker to specify message limits on all destinations for that broker.
Set properties on the broker to specify thresholds of available system memory at which the broker takes action to prevent memory overload. The action taken depends on the state of memory resources.
Reference Message Delivery Services Chapter 4, Configuring a Broker, in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Message compression |
|
Message flow control to clients |
|
Message-based monitoring API |
|
Multiple destinations for publishers and
subscribers |
Publishers can publish messages to multiple topic destinations and subscribers can consume messages
from multiple topic destinations by using a destination name that includes wildcard characters,
representing multiple destinations. Using such symbolic names allows administrators to create additional topic destinations,
as needed, consistent with the wildcard naming scheme. Publishers and subscribers automatically publish
to and consume from the added destinations. (Wildcard destination consumers are more common
than publishers.) Reference Supported Topic Destination Names in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Queue delivery to multiple consumers |
|
Reliable data persistence |
To obtain absolute reliability you can require that the operating
system write the data synchronously to the persistent store by setting the imq.persist.file.sync.enabled
property to true. This eliminates possible data loss due to system crashes, but
at the expense of performance. Note that although the data is not lost,
it is not available to any other broker (in a cluster) because
data is not currently shared by clustered brokers. When the system comes back
up, the broker can reliably resume operations. Reference Persistence Services Persistence Properties in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Schema validation of XML messages |
Enables validation of
the content of a text (not object) XML message against an XML schema
at the point the message is sent to the broker. The location of
the XML schema (XSD) is specified as a property of a Message
Queue destination. If no XSD location is specified, the DTD declaration within the XML
document is used to perform DTD validation. (XSD validation, which includes data type
and value range validation, is more rigorous than DTD validation.) Reference Physical Destination Properties in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Secure connections |
|
Simple Object Access Protocol (SOAP) support |
|
STOMP Bridge Service |
The STOMP bridge service enables
a Message Queue broker to communicate with clients that use the Streaming Text
Oriented Messaging Protocol defined by the http://stomp.codehaus.org open source project. The STOMP bridge service provides
the features need to fully integrate STOMP messaging into the JMS messaging environment
of Message Queue:
Registration with the Message Queue Port Mapper service so that STOMP clients can discover the service dynamically
Support for TCP and SSL/TLS connections, including those requiring client authentication
Automatic conversion of STOMP frame messages to and from JMS BytesMessage and TextMessage types
Support for the full STOMP protocol, including the STOMP JMS bindings
Reference Configuring and Managing STOMP Bridge Services in Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Thread management |
|
Tunable performance |
|
Universal Message Service (UMS) |
Message Queue includes a universal
messaging service (UMS) and messaging API that provides access to Message Queue from
any http-enabled device. As a result, almost any application can communicate with any
other application and benefit from the reliability and guaranteed delivery of JMS messaging. In
addition, the UMS provides enhanced scalability for JMS messaging, allowing the number of
messaging clients to reach internet-scale proportions. The simple, language-independent, protocol-based UMS API
supports both web-based and non-web-based applications, and can be used with both scripting and
programming languages. The API is offered in two styles: a simple messaging API
that uses a Representational State Transfer (REST)-style protocol, and an XML messaging API
that embeds the protocol in a SOAP message header. In both cases, however,
the API requires only a single http request to send or receive a
message. Reference Universal Message Service (UMS) in Oracle GlassFish Server Message Queue 4.5 Release Notes Documentation of UMS on Open MQ web site: https://mq.dev.java.net/4.3-content/ums/umsIntro.html |