ObjectQ Java Implementation – Beta Release 126.96.36.199 – Release Notes
The Java implementation of ObjectQ follows the C++ model as faithfully as possible, given the constraints of the language differences. For example, exceptions are used, rather than return codes. Users familiar with the C++ implementation will see obvious parallels, with classes and methods duplicated as far as is possible. The MIB files remain almost exactly the same, with a minor modification to the Service Name Resolution file, discussed later.
The implementation uses JMS as the underlying transport, so that any vendor that exposes a JMS interface can be used – although it has only been tested thus far on a WebSphere MQ transport.
This document provides information on the differences between the Java and C++ implementations, as well as installation and setup instructions.
The only transport currently supported is JMS.
Two models are supported: JMS client to JMS server, and JMS client to non-JMS server. In the former case, the message id is generated by JMS, and the server will reply putting the message id in the correlation id. In the latter case, the server will reply putting the invoke id in the message id. A non-JMS client cannot be supported because there is no way in JMS to alter the message id.
Encryption is not currently supported.
The transport methods forward(), back(), and replyToOrigin() are not supported – that is to say, forwarding servers are not supported, although hybrid servers are.
Continuation lines in MIB files are not supported.
Message selection can only be performed on invoke id and message priority.
There is a single jar file, named ObjectQ.jar, which should be placed in the application's classpath.
Supporting jar files, which should also be placed in the classpath, are: log4j-api-X.X.X.jar and log4j-core-X.X.X.jar, and IBM WebSphere MQ's mqjms.jar.
The MIB files should be placed in a directory whose path is passed to the ObjectQ constructor. This constructor should be invoked before any other. The MIB files are identical to those used by the C++ implementation, with one exception: the START LOCATION stanza in SNR file has one additional field, with tag server:. It should be set either to JMS, indicating that the server is another Java implementation, or MQS, indicating that the server is NON-JMS C++ implementation. Currently only WebSphere MQ is supported, since the mechanism for transporting queue information between applications is vendor-dependent.
Queues should be set up in JNDI. Within ObjectQ, queue aliases are used to refer to queues – these are identical to JNDI entries.
The name of the log4j logger used by ObjectQ is ObjectQ – it can be configured using log4j's configuration file. If a logger is passed to the ObjectQ constructor, it is used instead.
Properties are read from a
file named ObjectQ.properties, which should again be in the
Here is an example of its contents:
# The name of the Queue Connection Factory used
# to obtain QueueConnections
# The URL for JNDI, defaulting to file:.
The location of the regdomain
# defaulting to ./regdomain
# The Initial Context Factory
# The maximum message size, defaulting to 32000
The library is fully documented in its man pages.
Sample code implements the trivial client/server discussed on IDI's web page: http://idi-middleware.com/index.php?nav=objectq_overview. Also implemented is the more complex sample code that exercises many of ObjectQ's features.