Glossary
An overview of technical terms used on this website and in product documentation.
ACL
Nirvana's Access Control List (ACL) controls client connection requests and subsequent Nirvana operations. By default, a realm will always perform access control checks.
The Nirvana 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.
Learn more about ACLs:
Channel
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 Nirvana 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.
Nirvana supports multiple publishers and consumers on a single channel.
Note: the terms "channel" and "topic" are used interchangeably throughout this documentation.
Learn more about publish/subscribe with channels in:
Consumer
A consumer is a Nirvana client that receives events from a Nirvana channel, queue, peer-to-peer client/service or datagroup.
Note: the terms "consumer" and "subscriber" are used interchangeably throughout this documentation.
DataGroup
Nirvana DataGroups provide a very lightweight grouping structure that allows developers to manage user subscriptions remotely and transparently.DataGroups provide an alternative to channels/topics for publish/subscribe. DataGroups are essentially groups of consumers to which publishers can send events; more specifically, DataGroup members are either individual consumers or other (nested) DataGroups. A consumer which is a member of a DataGroup is known as a DataStream.
Messages published to a DataGroup will be sent to all members of the group. There can be multiple publishers associated with a single DataGroup, and DataGroup membership can be managed by any Nirvana client that has permissions to do so.
DataGroups are designed to support large numbers of consumers whose subscriptions are typically fluid in nature. The addition or removal of consumers from DataGroups can be entirely transparent from the consumer perspective.
An Example DataGroup Structure
Imagine a Foreign Exchange organization that provides different tiers of currency price data to users on different desks at their various customers.
Valued customer desks might be provided with gold level data, while less valued desks might receive silver or bronze tiered data:
A suitable DataGroup structure to represent this arrangement might be to create eight DataGroups:
- EURUSD_Gold
- EURUSD_Silver
- EURUSD_Bronze
- GBPUSD_Gold
- Customer_Desk_A
- Customer_Desk_B
- Customer_Desk_C
- Customer_Desk_D
Then, structure these DataGroups as follows:
- EURUSD_Gold
- Customer_Desk_A
- Customer_Desk_B
- EURUSD_Silver
- Customer_Desk_C
- Customer_Desk_D
- EURUSD_Bronze
- GBPUSD_Gold
- Customer_Desk_A
Price data would be published directly to the four DataGroups EURUSD_Gold, EURUSD_Silver, EURUSD_Bronze and GBPUSD_Gold (though, optimally, a publisher may well choose not to publish to the empty DataGroup EURUSD_Bronze). By virtue of this structure, prices published to EURUSD_Gold, for example, will be delivered to both the DataGroups Customer_Desk_A and Customer_Desk_B.
End user clients with DataStream-enabled sessions can be added to arbitrary DataGroups - and thus receive data from those DataGroups. So, for example, adding User1 and User2 as DataStream members of the DataGroup Customer_Desk_A, both users would, by virtue of the above structure, receive price data via their inherited membership of both EURUSD_Gold and GBPUSD_Gold.
Dynamic Changes
Let us now assume that our organization decides to upgrade the level of EURUSD price data sent to users on Customer_Desk_C from silver to gold.
Achieving this with DataGroups is extremely simple. All we need to do is remove the Customer_Desk_C DataGroup from the EURUSD_Silver DataGroup, and add it to the EURUSD_Gold DataGroup instead, resulting in the following new structure:
- EURUSD_Gold
- Customer_Desk_A
- Customer_Desk_B
- Customer_Desk_C
- EURUSD_Silver
- Customer_Desk_D
- EURUSD_Bronze
- GBPUSD_Gold
- Customer_Desk_A
Even More Dynamic Changes
Let's take our example a little further. Assume that the publisher of the gold EURUSD price data stops for some reason, and that the organization decides customers who were receiving this data should, for the time being, fall back to silver EURUSD level prices instead.
One way of doing this would be to move the three DataGroups Customer_Desk_A, Customer_Desk_B and Customer_Desk_C out of the EURUSD_Gold DataGroup and into the EURUSD_Silver DataGroup.
An even simpler way, however, would be to just move the EURUSD_Gold DataGroup itself into the EURUSD_Silver DataGroup, resulting in the following structure:
- EURUSD_Silver
- EURUSD_Gold
- Customer_Desk_A
- Customer_Desk_B
- Customer_Desk_C
- Customer_Desk_D
- EURUSD_Gold
- EURUSD_Bronze
- GBPUSD_Gold
- Customer_Desk_A
This structure could be used while the gold level publisher of EURUSD prices remains inactive. Once the publisher of the gold level data restarts, the EURUSD_Gold DataGroup can be removed from the EURUSD_Silver DataGroup (for if it were not removed, the users expecting gold level EURUSD prices would now receive both gold and silver level prices).
Other Notes
It is typical (though not necessary) for a process which publishes data to DataGroups to be independent of the process that manages DataGroup structures and DataGroup membership of end-user DataStreams. This allows the logic for these two very different responsibilities to be separated.
Learn more about publish/subscribe with DataGroups in:
See also: DataGroup Administration with Enterprise Manager.
DataStream
A Nirvana client (typically, but not necessarily, a simple consumer) may initialise a DataStream-enabled session, making it eligible for membership in one or more DataGroups. Such a client is considered a DataStream.
Note that DataStreams do not determine the DataGroups of which they are members; their membership is determined by clients with the appropriate permissions (see DataGroup).
Dictionary
Event Dictionaries provide an accessible and flexible way to store any number of message properties for delivery within a Nirvana 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.
Learn more about dictionaries in:
Enterprise Manager
Nirvana's Enterprise Manager is a powerful GUI management tool that allows you to control, configure and administer all aspects of any Nirvana realm or clusters of realms.
When you connect to a Nirvana 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 Nirvana realm servers from a single Enterprise Manager instance.
Enterprise Manager is completely implemented using the Nirvana Management API, so any of its features can be easily integrated into bespoke or 3rd party systems management services.
Learn more in the Enterprise Manager Guide.
Event (Message)
An event is the message object in which a publisher inserts data to be published. Events are published to either a Nirvana channel, queue, peer-to-peer service 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.
Learn more about events in:
Filtering
Nirvana 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. Nirvana 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.
Nirvana events can contain not only an event dictionary and a tag, but also a byte array payload of data. Nirvana 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.
More details on filtering may be found in the Event Filtering Guide and the Advanced Filtering Guide. You might also be interested in a blog post about location-based filtering.
Fragmentation
Although there is no specific limit to the size of events that can be published to Nirvana, from a network perspective it is usually more efficient to publish several smaller messages than one large one.
Publishers using the Nirvana Enterprise APIs can choose to transparently fragment large events into smaller chunks for publishing. The Nirvana client API will transparently reconstitute the event at delivery.
Learn more about large events and fragmentation in:
Forever IFrame
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.
Nirvana's JavaScript API provides an implementation of Forever IFrame allowing it to communicate with a server using this delivery mode.
Learn more about Forever IFrames in:
LongPolling
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.
Nirvana's JavaScript API provides an implementation of LongPolling allowing it to communicate with a server using this delivery mode.
Learn more about LongPolling in:
Peer to Peer
Peer to Peer provides a communications path between an instance of a service and the client requiring access to the service. The Nirvana realm server transparently brokers messages between the service and the client.
There are two parts to a Peer to Peer Service in Nirvana: a Server Service and a Client.
When a Server Service is running, it is visible within the Nirvana Namespace and is available to any Client wishing to connect. The Nirvana Realm Server acts as the bridge that connects Clients to Server Services. Each Server Service can support multiple Clients:
Nirvana Peer to Peer Client and Server Services
The Server Service is a process that registers itself with a Nirvana Realm so it is visible to Clients wishing to connect. Developers typically implement custom business logic in Server Services.
A Nirvana Peer to Peer Service Client is a process that connects to a Nirvana Realm, obtains a reference to a Server Service and begins communicating with it.
Note that when a Client connects to the Server Service, all communication between the Client and Server Service takes place through the Nirvana Realm; Clients do not communicate directly with Server Services.
Learn more about peer to peer services in:
Publisher
A publisher is a Nirvana client that sends data/messages as events to a Nirvana channel, queue, peer-to-peer client/service or datagroup.
Note: the terms "publisher" and "sender" are used interchangeably throughout this documentation.
Subject
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 username component of the subject is the name of the user taken from either the operating system of the machine they are connecting from, or the certificate name if they are using an SSL protocol.
The host component of the subject is either the IP address or the hostname of the machine from which they are connecting.
The subject takes the form of username@host; for example:
johnsmith@192.168.1.2
Topic
A topic is a JMS term which translates directly to a Nirvana channel. Consequently, the terms "channel" and "topic" are used interchangeably throughout this documentation.
Queue
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.
Learn more about queues in:
Realm
A Nirvana realm is the name given to a single Nirvana server. Nirvana realms can support multiple network interfaces, optionally supporting different Nirvana 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 Nirvana 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.
Nirvana also provides the ability to create clusters of realms that share common resources within the namespace.
RNAME
An RNAME is used by Nirvana Clients to specify how a connection should be made to a Nirvana realm server. The URL describes a particular interface on the Nirvana realm server.
See Nirvana Communication Protocols and RNAMEs for more information.
WebSockets
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.
Nirvana's JavaScript API currently supports WebSockets for all browsers which implement the specification.
Learn more about WebSockets in:
Something Missing?
If you think it would be helpful for any other technical terms to be described here, please tell us! Thank you.
