Message Queue 4.2 was a minor release that included a number of new features, some feature enhancements, and bug fixes. This section describes the new features in the 4.2 release and provides further references for your use:
With Message Queue 4.2, a publisher can publish messages to multiple topic destinations and a subscriber can consume messages from multiple topic destinations. This capability is achieved by using a topic 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 topic subscribers are more common than publishers.)
This feature does not apply to queue destinations.
The format of symbolic topic destination names and examples of their use is described in Supported Topic Destination Names in Sun Java System Message Queue 4.3 Administration Guide.
This feature, introduced in Message Queue 4.2, 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.)
For information on the use of this feature, see Schema Validation of XML Payload Messages.
According to the X/Open distributed transaction model, support for distributed transactions relies upon a distributed transaction manager which tracks and manages operations performed by one or more resource managers. With Message Queue 4.2, 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.
This distributed transaction support consists of the following new C-API functions (and new parameters and error codes) used to implement the XA interface specification:
If a C-client application is to be used in the context of a distributed transaction, then it must obtain a connection by using MQGetXAConnection() and create a session for producing and consuming messages by using MQCreateXASession(). The start, commit, and rollback, of any distributed transaction is managed through APIs provided by the distributed transaction manager.
For details of using the distributed transaction functions, see Working With Distributed Transactions in Sun Java System Message Queue 4.3 Developer’s Guide for C Clients.
Message Queue 4.2 provides programming examples based on the Tuxedo transaction manager. For information on the use of these sample programs, see Distributed Transaction Sample Programs in Sun Java System Message Queue 4.3 Developer’s Guide for C Clients.
The distributed transaction functionality is supported on Solaris, Linux, and Windows platforms, however, to date it has only been certified on the Solaris platform.
The Message Queue installer has been enhanced to allow for registration of Message Queue with Sun Connection, a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software.
As part of Message Queue installation, you can choose to register Message Queue with Sun Connection. Information about the installed Message Queue, such as the release version, host name, operating system, installation date, and other such basic information is securely transmitted to the Sun Connection database. The Sun Connection inventory service can help you organize your Sun hardware and software, while the update service can inform you of the latest available security fixes, recommended updates, and feature enhancements.
For details of registering Message Queue with Sun Connection, see Sun Java System Message Queue 4.3 Installation Guide.
Message Queue 4.2 introduced support for MySQL database as a JDBC-based data store. MySQL Cluster Edition can be used as a JDBC database for a standalone broker, and MySQL Cluster Edition can be used as the highly-available shared data store needed for an enhanced broker cluster. For information on configuring Message Queue to use MySQL, see Configuring a JDBC-Based Data Store in Sun Java System Message Queue 4.3 Administration Guide and also High-Availability Cluster Properties in Sun Java System Message Queue 4.3 Administration Guide.
In addition to the features described above, Message Queue 4.2 included the following enhancements:
Remotely Produced Message Metrics
Message Queue 4.2 introduced new destination metrics that can be useful in monitoring destinations in a broker cluster. In a broker cluster, the messages stored in a given destination on a given broker in the cluster, consist of messages produced directly to the destination as well as messages sent to the destination from remote brokers in the cluster. In analyzing message routing and delivery in a broker cluster, it is sometimes helpful to know how many messages in a destination are local (locally produced) and how many are remote (remotely produced).
Two new physical destination metric quantities are included in Message Queue 4.2: Num messages remote and Total Message bytes remote. The new metric quantities are available through the imqcmd list dst and imqcmd query dst commands (see Viewing Physical Destination Information in Sun Java System Message Queue 4.3 Administration Guide) and through new JMX attributes (see Destination Monitor in Sun Java System Message Queue 4.3 Developer’s Guide for JMX Clients).
Wildcard Producer and Wildcard Consumer Information
Information to support the use of wildcard characters in destination names (see Multiple Destinations for a Publisher or Subscriber) is provided through new monitoring data. For example, the number of wildcard producers or consumers associated with a destination are available through the imqcmd query dst command (see Viewing Physical Destination Information in Sun Java System Message Queue 4.3 Administration Guide) and through new JMX attributes (see Destination Monitor in Sun Java System Message Queue 4.3 Developer’s Guide for JMX Clients). Also, wildcard information is available through the ConsumerManager Monitor and ProducerManager Monitor MBeans.
Support for DN Username Format for Client Authentication
Message Queue 4.2 introduced support for DN username format in client connection authentication against an LDAP user repository. The support involves the following new broker property (and value):
This property lets the broker authenticate a client user against an entry in an LDAP user repository by extracting from the DN username format the value of the attribute specified by the following property:
The broker uses the value of the above attribute as the name of the user in access control operations.
For example, if imq.user_repository.ldap.uidattr=udi and a client authentication username is in the format udi=mquser,ou=People,dc=red,dc=sun,dc=com, then “mquser” would be extracted for performing access control.
JAAS Authentication Enhancement
Message Queue 4.2 introduced JAAS authentication by IP address as well as by username.