OpenWire Protocol

The OpenWire protocol is the default on-the-wire protocol for Fuse MQ Enterprise. This chapter provides a brief introduction to the protocol, illustrating how to use OpenWire with a variety of transport protocols.

Overview

The OpenWire protocol is a JMS compliant wire protocol (defining message types and message encodings) that is native to the Fuse MQ Enterprise. The protocol is designed to be fully-featured, JMS-compliant, and highly performant. It is the default protocol of the Fuse MQ Enterprise.

Transport protocols

Table 3 shows the transport protocols supported by the OpenWire wire protocol:

Table 3. Transport Protocols Supported by OpenWire

Transport Protocol	URL	Description
TCP	`tcp://Host:Port`	Endpoint URL for OpenWire over TCP/IP. The broker listens for TCP connections on the host machine, `Host`, and IP port, `Port`.
TCP	`nio://Host:Port`	Same as `tcp`, except that the New I/O (NIO) Java API is used, which provides better performance in some scenarios.
SSL	`ssl://Host:Port`	(Java clients only) Endpoint URL for OpenWire over TCP/IP, where the socket layer is secured using SSL (or TLS). For details of how to configure an SSL connection, see Security Guide.
HTTP	`http://Host:Port`	(Java clients only) Endpoint URL for OpenWire over HTTP.
HTTPS	`https://Host:Port`	(Java clients only) Endpoint URL for OpenWire over HTTP, where the socket layer is secured by SSL (or TLS). For details of how to configure a HTTPS connection, see Security Guide.

Transport options

OpenWire supports a number of transport options, which can be set as query options on the transport URL. For example, to specify that error messages should omit the stack trace, use a URL like the following:

tcp://localhost:61616?wireformat.stackTraceEnabled=false

Where the wireformat.stackTraceEnabled property is set to false to disable the inclusion of stack traces in error messages. Table 4 gives the complete list of transport options for OpenWire.

Table 4. Transport Options Supported by OpenWire Protocol

Property	Default	Description	Negotiation policy
`wireformat` `.stackTraceEnabled`	`true`	Should the stack trace of an exception occuring on the broker be sent to the client?	Set to `false` if either side is `false`.
`wireformat` `.tcpNoDelayEnabled`	`false`	Provides a hint to the peer that TCP `nodelay` should be enabled on the communications Socket.	Set to `false` if either side is `false`.
`wireformat` `.cacheEnabled`	`true`	Should commonly repeated values be cached so that less marshalling occurs?	Set to `false` if either side is `false`.
`wireformat` `.cacheSize`	`1024`	If `cacheEnabled` is `true`, this property specifies the maximum number of values to cache.	Use the smaller of the two values.
`wireformat` `.tightEncodingEnabled`	`true`	Should wire size be optimized over CPU usage?	Set to `false` if either side is `false`.
`wireformat` `.prefixPacketSize`	`true`	Should the size of the packet be prefixed before each packet is marshalled?	Set to `true` if both sides are `true`.
`wireformat` `.maxInactivityDuration`	`30000`	The maximum inactivity duration (before which the socket is considered dead) in milliseconds. On some platforms it can take a long time for a socket to appear to die, so we allow the broker to kill connections if they are inactive for a period of time. Set to a value `<= 0` to disable inactivity monitoring.	Use the smaller of the two values.
`wireformat` `.maxInactivityDurationInitalDelay`

Supported clients

Fuse MQ Enterprise currently supports the following client types for the OpenWire protocol:

Java clients—the Java API conforms fully to the JMS specification.

If you want to develop an OpenWire client using other programming languages, try one of the following client types from the Apache ActiveMQ project:

C++ clients—for C++ clients, Apache ActiveMQ provides the CMS (C++ Messaging Service) API, which is closely modelled on the JMS specification. Only the TCP transport is supported for C++ clients.

Comments powered by Disqus