## Introduction to the OpenWire Protocol

### Overview

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

### Transport protocols

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

Table 2.1. 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`.
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 the FUSE Message Broker 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 the FUSE Message Broker Security Guide. [REVISIT - Insert Olink.]

### 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 2.2 gives the complete list of transport options for OpenWire.

Table 2.2. 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` `.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` `.cacheSize` | `1024` | If `cacheEnabled` is `true`, this property specifies the maximum number of values to cache. | Use the smaller of the two values.

### Supported clients

FUSE Message Broker currently supports the following client types for the OpenWire protocol:

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

For details of how to program the messaging clients, see the FUSE Message Broker Client Guide.

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.