ObjectQ is an object-oriented communications platform built on top of external
vendors' message-queuing product. These underlying products must be acquired
independently of the ObjectQ software.
The ObjectQ software, together with all documentation, architecture
specifications and example code is distributed over the World Wide Web,
obtainable at URL http://www.idi-middleware.com/objectq/ This document is the ObjectQ Release Notes for release 4.2.6.
This release introduces support for the AIX version 5L platform, enhanced
support for the IBM MQSeries messaging middleware transport, support for
BEA Tuxedo version 8 and above, and several minor bug fixes and enhancements.
Each of these new features is detailed below.
2. Supported Platforms
- AIX version 5L is supported with BEA MessageQ 5 and IBM MQSeries 5.2 transports.
- HP-UX 11 is supported with BEA MessageQ 4 or higher and BEA Tuxedo version 8 or higher.
- Solaris 2.8 is supported with BEA MessageQ 4 or higher and IBM MQSeries 5 or higher.
3. Enhanced Support for IBM MQSeries Version 5
This version of ObjectQ provides MQSeries Level 2 support, which provides nearly all of the functionality as the DECMessageQ transport on other platforms. When transitioning from a BEA MessageQ environment to a IBM MQSeries environment, a few considerations must be taken into account:
Specifying MQSeries as the transport:
The .snr (Service Name Resolution file) must specify MQS as the DefaultVendor for each service, and as the vendor for each Location which represents a MQSeries queue. Thus, a typical service might look like the following:
#SNR for for DEMO_sales
START LOCATION loc1
It is important to note that the defaultVendor must be set as well as the vendor for each queue.
Specifying the Queue Manager:
The queue manager that an application attaches to, or that is a message destination, may be specified in one of two ways. Either the environment variable MQS_QUEUE_MANAGER should be set to the queue manager's name, or it should be prefixed to the queue name, using a colon separator, in the code or in the Service Name Resolution file. Thus, a message could be sent to the queue TEST on the queue manager QM in any of the following ways:
- With environment variable MQS_QUEUE_MANAGER set to "QM" and destination queue set to "TEST";
- With environment variable MQS_QUEUE_MANAGER either not set or set to anything, and destination queue set to "QM:TEST";
- With environment variable MQS_QUEUE_MANAGER either not set or set to anything, and destination service resolving, via the destName field of the Service Name Resolution file, to "QM:TEST";
- With environment variable MQS_QUEUE_MANAGER set to "QM" and destination service resolving, via the destName field of the Service Name Resolution file, to "TEST".
Note that, firstly, the values QUEUE and ALIAS in the destType field of the Service Name Resolution field are synonymous for MQSeries, since all queues (other than temporary queues) in MQSeries are named queues ; and secondly, that a queue manager name specified either in the Service Name Resolution file or prefixed to the queue name overrides the setting of the environment variable.
An application requiring an unnamed (temporary) queue on any queue manager other than the default queue manager must have the environment variable set - there is no other way to specify the queue manager. The unnamed queue will have the same characteristics as the queue SYSTEM.DEFAULT.MODEL.QUEUE.
- Delivery assurance levels of "full" and "none" behave as expected; "partial" assurance will use the default behavior specified in the queue definition.
- Only two of the available priority levels are used: 0 corresponds to normal, and 1 to high.
- The only criteria that can be used for message selection are queue (one or two, but see below), invoke id and user data, although any combination of these is allowed. Thus, priority, message type and service may not be used for selection.
- Undeliverable message action may not be specified, and an undeliverable message will always finish up in the dead letter queue.
Reading from Multiple Queues:
MQSeries has no way to simultaneously read from two queues, as does BEA MessageQ. However, ObjectQ does provide a mechanism to read from multiple queues even with MQSeries as the underlying transport. If two queues are added to a selector, the action is simulated by the following sequence:
- a non-blocking read from q1
- a non-blocking read from q2
- a blocking read from q1 for half of the specified timeout period
- a blocking read from q2 for the remainder of the timeout period
A successful read at any point will cause the message to be returned to the application. Note that the order in which queues (handles) are added to the selector is significant. If the read specifies an infinite timeout period, the above algorithm is repeated indefinitely with a timeout of 30 seconds.
Other than the above configuration issues, most applications will require no changes to compile and run in an MQSeries environment. Applications which are coded without transport-specific code will not require coding changes, recompilation, or relinking to switch between MQSeries and BEA MessageQ environments, and the same application can use both messaging transports simultaneously.
4. Bug Fix
- A bug whereby a client sending a request with an uninitialized instance ID or inscance filter parameter could cause a segmentation fault on the server has been fixed. These will now result in a "cpAttribute::restore failed: uninitialized attribute" message in the server trace and log files.
- Previously, when unflatttening a cpEnvelope, messages with impossible message versions or which were too small to be CMIP messages were silently dropped and cpFAIL returned to the application. Invalid messages which cause the envelope to be rejected will now result in explanatory messages being logged.
...... Return to "Release Notes" page ......