JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Remote Administration Daemon Developer Guide     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Concepts

Interface

Name

Derived Types

Features

Methods

Attributes

Events

Versioning

Numbering

Commitment

Clients and Versioning

rad Namespace

Naming

Equality

Patterns

Operations

Data Typing

Base Types

Derived Types

Optional Data

3.  Abstract Data Representation

4.  libadr

5.  Client Libraries

6.  Module Development

7.  rad Best Practices

A.  rad Binary Protocol

rad Namespace

The namespace acts as rad's gatekeeper, associating a name with each object, dispatching requests to the proper object, and providing meta-operations that enable the client make queries about what objects are available and what interfaces they implement.

A rad server may provide access to several objects that in turn expose a variety of different components of the system or even third-party software. A client merely knowing that interfaces exist, or even that a specific interface exists, is not sufficient. A simple, special-purpose client needs some way to identify the object implementing the correct interface with the correct behavior, and an adaptive or general-purpose client needs some way to determine what functionality the rad server has made available to it.

rad organizes the server objects it exposes in a namespace. Much like files in a file system, objects in the rad namespace have names that enable clients to identify them, can be acted upon or inspected using that name, and can be discovered by browsing the namespace. Depending on the point of view, the namespace either is the place one goes to find objects or the intermediary that sits between the client and the objects it accesses. Either way, it is central to interactions between a client and the rad server.

Naming

Unlike a file system, which is a hierarchical arrangement of simple filenames, rad adopts the model used by JMX and maintains a flat namespace of structured names. An object's name consists of a mandatory reverse-dotted domain combined with a non-empty set of key-value pairs. There aren't any restrictions on what a key or value can contain, which can make representing them as a string difficult. For the sake of simplicity, this document does not attempt to establish a canonical form, but uses a form similar to the serialized form of JMX ObjectNames:

domain:key1=value1[,key2=value2[,...]]

See Naming Guidelines for guidance on object naming. For more information about JMX, see the Java Management Extensions (JMX) technology home page .

Equality

Two names are considered equal if they have the same domain and the same set of keys, and each key has been assigned the same value.

Patterns

Some situations call for referring to groups of objects. In these contexts, a name can be used as a pattern. Another object name matches a pattern if all components present in the pattern are present and equal in the name. In these contexts, name used as patterns are permitted to have an unspecified domain or an empty set of key-value pairs. For example, the pattern :product=fruit (that is, no domain, and only the key “product” with the value “fruit” specified) would match the names grocery.bob:product=fruit,type=banana and grocery.jim:product=fruit,type=apple, but not grocery.bob:product=animal,type=fish or grocery.bob:person=shelver.

Operations

Just as names are essential to a client's interaction with the rad server, so are the actions the client performs. While the exact nature of the requests a client performs are a function of the protocol used and might be hidden from the developer by the client implementation itself, defining the set of abstract operations supported by the rad namespace is still useful.

LIST
Requests that the objects of the namespace be enumerated. Returns a list of object names.
DESCRIBE
Requests a description of a specific object by name. Returns an interface description.
INVOKE
Invokes a method on the specified object with the specified arguments. Returns the result of that method invocation, if any.
GET
Reads the value of an attribute of the specified object.
SET
Writes a value to an attribute of the specified object.
SUBSCRIBE
Subscribes to the specified event source of the specified object.
UNSUBSCRIBE
Unsubscribes from the specified event source of the specified object.

LIST and DESCRIBE are analogous to the VFS operations READDIR and LOOKUP, respectively. As is the case with VFS, it might be possible to call DESCRIBE on objects that are not enumerated by LIST. The usual reason for this arrangement applies here as well: enumerating the available objects might be prohibitively expensive, either for algorithmic reasons or due to their sheer quantity. The bandwidth required for a large response (and the corresponding latency induced in every client application) can also be a consideration. Additionally, the server objects that rad provides might represent underlying objects that themselves subject their consumers (of which rad is one) to such a restriction.

This type of arrangement also enables renaming of objects. The server can respond to requests against an old name to maintain compatibility with legacy clients without needing to broadcast the existence of those old names.


Note - These operations represent the most basic set of operations related to discussing communication with a rad server. For efficiency, the rad protocol further divides DESCRIBE into separate LOOKUP and DEFINE operations.