This glossary provides an overview of technical terms used in the product documentation.

Universal Messaging's Access Control List (ACL) controls client connection requests and subsequent Universal Messaging operations. By default, a realm will always perform access control checks.

The Universal Messaging realm has an ACL associated with it. The ACL contains a list of subjects and the operations that each subject can perform on the realm.

Each channel, queue and service also has an associated ACLs that defines subjects and the operations the subjects can perform. Each type of acl entry has a number of flags that can be set to true or false in order to specify whether the subject can or can't perform the operation.

A channel is the distribution mechanism for an asynchronous publish/subscribe messaging model.

In this model, the publisher and consumer of an event (or "message") are decoupled, but are both connected to a common channel which exists within the Universal Messaging realm server.

The publisher publishes its data as events to the channel. As messages arrive on a channel, the server automatically sends them to all consumers subscribed to the channel.

Universal Messaging supports multiple publishers and consumers on a single channel.

Note: the terms "channel" and "topic" are used interchangeably throughout this documentation.

A consumer is a Universal Messaging client that receives events from a Universal Messaging channel, queue or datagroup.

Note: the terms "consumer" and "subscriber" are used interchangeably throughout this documentation.

Universal Messaging Data Groups provide a very lightweight grouping structure that allows developers to manage user subscriptions remotely and transparently.

Data Groups provide an alternative to channels/topics for the publish/subscribe messaging paradigm.

A Universal Messaging client (typically, but not necessarily, a simple consumer) may initialise a DataStream-enabled session, making it eligible for membership in one or more Data Groups. Such a client is considered a DataStream.

Note that Data Streams do not determine the Data Groups of which they are members; their membership is determined by clients with the appropriate permissions (see DataGroup).

Event Dictionaries provide an accessible and flexible way to store any number of message properties for delivery within a Universal Messaging event.

Event Dictionaries are quite similar to a hash table, supporting primitive types, arrays, and nested dictionaries.

Filtering allows subscribers to receive only specific subsets of a channel's events by applying the server's advanced filtering capabilities to the contents of each event's dictionary.

Universal Messaging's Enterprise Manager is a powerful GUI management tool that allows you to control, configure and administer all aspects of any Universal Messaging realm or clusters of realms.

When you connect to a Universal Messaging realm in the Enterprise Manager, all resources and services found within the realm namespace are displayed in a tree structure under the realm node itself. It is also possible to connect to and view multiple Universal Messaging realm servers from a single Enterprise Manager instance.

Enterprise Manager is completely implemented using the Universal Messaging Management API, so any of its features can be easily integrated into bespoke or 3rd party systems management services.

An event is the message object in which a publisher inserts data to be published. Events are published to either a Universal Messaging channel, queue or datagroup. From there, it is passed on to consumers. Events are language agnostic, which means that clients using different languages can interact seamlessly.

An event may be a simple byte array or contain more complex structures such as dictionaries, Google Protocol Buffers, JSON or JMS events.

Note: the terms "event" and "message" are used interchangeably throughout this documentation.

Universal Messaging provides a server side filtering engine that allows only events meeting certain criteria to be delivered to consumers.

Standard filtering, as defined by JMS, allows events to be evaluated based on the value of the dictionary keys prior to delivering the event to the consumer. Universal Messaging supports not only standard filtering, but also filtering based on arrays and nested dictionaries contained within event dictionaries. There is no limit to the depth of nested properties that can be filtered.

Universal Messaging events can contain not only an event dictionary and a tag, but also a byte array payload of data. Universal Messaging consequently supports a yet more advanced form of filtering based on the content of the byte array data itself. In addition, filtering is possible based on time and consumer location.

Although there is no specific limit to the size of events that can be published to Universal Messaging, from a network perspective it is usually more efficient to publish several smaller messages than one large one.

Publishers using the Universal Messaging Enterprise APIs can choose to transparently fragment large events into smaller chunks for publishing. The Universal Messaging client API will transparently reconstitute the event at delivery.

Forever IFrame is a technique which allows a web server to stream data into a client browser. This is done through a hidden inline frame in the page source which is declared to be infinitely long. It is one of many push technologies under the umbrella term Comet.

Universal Messaging's API for JavaScript supports Forever IFrame, allowing it to communicate with a server using this delivery mode.

LongPolling is a technique which allows a web browser running as a client to asynchronously receive updates from a server machine. It is one of many push technologies under the umbrella term Comet.

Universal Messaging's API for JavaScript supports LongPolling, allowing it to communicate with a server using this delivery mode.

A publisher is a Universal Messaging client that sends data/messages as events to a Universal Messaging channel, queue or datagroup.

Note: the terms "publisher" and "sender" are used interchangeably throughout this documentation.

A subject corresponds to the user information for a publisher or subscriber's realm connection. Subjects are used when defining ACLs.

A subject is comprised of a username and a host:

The subject takes the form of username@host; for example:

A topic is a JMS term which translates directly to a Universal Messaging channel. Consequently, the terms "channel" and "topic" are used interchangeably throughout this documentation.

A queue is much like a channel; the primary difference is that only one consumer can read any individual event from a queue. Consumed events are immediately removed from the queue, and are no longer available for consumption by any other consumer. Thus, a queue guarantees that each event is delivered only once.

If more than one consumer is subscribed to a queue, then queued events are distributed amongst consumers in a round-robin fashion.

A Universal Messaging realm is the name given to a single Universal Messaging server. Universal Messaging realms can support multiple network interfaces, optionally supporting different Universal Messaging protocols. Each such interface is represented by a URL, known as an RNAME. Thus a single realm server can have more than one RNAME.

Each Universal Messaging realm defines a namespace of its own resources (such as channels and queues), but it is possible to merge the namespaces of multiple realms into one large federated namespace for transparent client access to resources on different realms.

Universal Messaging also provides the ability to create clusters of realms that share common resources within the namespace.

An RNAME is used by Universal Messaging Clients to specify how a connection should be made to a Universal Messaging realm server. The URL describes a particular interface on the Universal Messaging realm server.

WebSocket is a technology for providing full-duplex connections over a TCP socket within the web browser. The WebSocket API is currently being developed by W3C and the protocol standardised by IETF.

Universal Messaging's API for JavaScript currently supports WebSockets for all browsers which implement the standard.