New Features in Message Queue 4.2

Sun Java System Message Queue is a full-featured message service that provides reliable, asynchronous messaging that conforms to the Java Messaging Specification (JMS) 1.1. In addition, Message Queue provides features that go beyond the JMS specification to meet the needs of large-scale enterprise deployments.

Message Queue 4.2 is a minor release that includes a number of feature enhancements and bug fixes. This section explains how to install or upgrade toMessage Queue 4.2 and describes the new features included in this release:

• Multiple Destinations for a Publisher or Subscriber

• Schema Validation of XML Payload Messages

• C-API Support for Distributed Transactions

• Installer Support for Sun Connection Registration

• Support for MySQL Database

For information about features introduced in Message Queue 4.0 and 4.1, see New Features in Message Queue 4.0 and New Features in Message Queue 4.1, respectively.

Multiple Destinations for a Publisher or Subscriber

In Message Queue 4.2, a publisher can now 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 the symbolic topic destination name consists of multiple segments, in which wildcard characters (*, **, >) can represent one or more segments of the name. For example, suppose you have a topic destination naming scheme as follows:

size.color.shape

where the topic name segments can have the following values:

• size: large, medium, small, ...

• color: red, green, blue, ...

• shape: circle, triangle, square, ...

Message Queue supports the following wildcard characters:

• * matches a single segment

• ** matches one or more segments

• > matches any number of successive segments

You can therefore indicate multiple topic destinations as follows:

large.*.circle would represent:

large.red.circle
large.green.circle
...

**.square would represent all names ending in .square, for example:

small.green.square
medium.blue.square
...

small.> would represent all destination names starting with small., for example:

small.blue.circle
small.red.square
...

To use this multiple destination feature, you create topic destinations using a naming scheme similar to that described above. Client applications can then create wildcard publishers or wildcard consumers using symbolic destination names. For example:

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);

...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

In the first example, the broker will place a copy of the message in any destination that matches the symbolic name large.*.circle. In the second example, a subscriber will be created if there is at least one destination that matches the symbolic name **.square and will receive messages from all destinations that match that symbolic name. If there are no destinations matching the symbolic name, the subscriber will not be created until such a destination exists.

If an administrator creates additional destinations that match a symbolic name, then wildcard publishers created using that symbolic name will subsequently publish to that destination and wildcard subscribers created using that symbolic name will subsequently receive messages from that destination.

In addition, Message Queue administration tools, in addition to reporting the total number of publishers (producers) and subscribers (consumers) for a topic destination, will also report the number of publishers that are wildcard publishers (including their corresponding symbolic destination names) and the number of subscribers that are wildcard subscribers (including their symbolic destination names), if any.

Schema Validation of XML Payload Messages

This new feature 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.)

Client applications using this new feature should upgrade Java SE version to JRE 1.5 or above.

To enable XML schema validation, you set the following physical destination properties:

When XML validation is enabled, the Message Queue client runtime will attempt to validate an XML message against the specified XSDs (or against the DTD, if no XSD is specified) before sending it to the broker. If the specified schema cannot be located or the message cannot be validated, the message is not sent, and an exception is thrown.

The XML validation properties can be set at destination creation or update time by using the imqcmd create dst or imqcmd update dst command, respectively. The XML validation properties should be set when a destination is inactive: that is, when it has no consumers and producers, and when there are no messages in the destination.

If an XSD is not accessible at runtime, it might be necessary to modify the XMLSchemaURIList while a destination is active.

If any of the XML validation properties are set while a destination is active (for example, if a producer is connected to the destination), the change will not take effect until the producer reconnects to the broker. Similarly, if an XSD is changed, as a result of changing application requirements, all client applications producing XML messages based on the changed XSD must reconnect to the broker.

If the reloadXMLSchemaOnFailure property is set to true and XML validation fails, then the Message Queue client runtime will attempt to reload the XSD before attempting again to validate a message. The client runtime will throw an exception if the validation fails using the reloaded SXD.

C-API Support for Distributed Transactions

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. In Message Queue 4.2, the Message Queue C-API now 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:

MQGetXAConnection()
MQCreateXASession()

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.2 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.2 Developer’s Guide for C Clients

The distributed transaction functionality is supported Solaris, Linux, and Windows platforms, however, to date it has only been certified on the Solaris platform.

Installer Support for Sun Connection Registration

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.

The following installer screen has been added to Message Queue 4.2 for Sun Connection registration:

Registration requires that you have a Sun Online account or create one. If you do not already have an account, the installer provides the following screen for creating a Sun Online account:

You can register Message Queue during installation using the above screens, or wait until after installation has been completed and run the installer in register-only mode, as follows:

# installer -r

The register-only mode requires that Message Queue 4.2 already be installed and will display only the installer screens related to registration.

Support for MySQL Database

Message Queue 4.2 supports 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 a high-availability 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.2 Administration Guide and also High-Availability Cluster Properties in Sun Java System Message Queue 4.2 Administration Guide.