Defintions

Object

An object is defined as a container holding different many (or just one) value of potentially different datatypes. Objects always have methods which are invoked on them in order to cause an operation associated with the contained data to occur.

Objects must not be considered immutable.

Immutable

An immutable value is one whose value cannot change. Usually these are called scalar values, where they contain only a single data element of only a single data type. A good example of an immutable value is the number 4, or the string "Hello, world!". It is possible to assign a new value to the variable which contains the number or string, but it is not possible to change the number 4.

Object instances themselves must not be considered immutable.

Process

A process is only defined as an application instance handling one or more Request Encoding as Objects connections at a time. This process may be implemented by one or more host processes, eg through fork() on Unix. However, they are coordinated such that a connection to one host process is the same as a connection to another host process.

For most Request Encoding as Objects implementations and uses, a one to one mapping between host processes and Request Encoding as Objects processes may be done. A one to many mapping may be done between a Request Encoding as Objects process and host processes. However, a many to one mapping must not be done between Request Encoding as Objects processes and a host process.

ServerID

Every process utilizing Request Encoding as Objects must create a unique server id to present to other processes which it communicates with. This server id must be unique over time and space. The Casbah Project recommnds using the uuid scheme layed out by Leach and Salz in UUIDs and GUIDs. A copy is available at http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt.

Both sides of a Request Encoding as Objects connection must generate and present to the other side a server id. Server id's are process specific, not connection specific and therefore must be the same value for all connections handled by a single process.

Server id's are used to ensure that a process has established a connection with the intended remote process.

ObjectID

Request Encoding as Objects requires that all objects be assigned a unique ID, thereby allowing objects to be located in the overall distributed system. All object id's must be unique over time and space. The Casbah Project again recommends using the uuid scheme layed out by Leach and Salz in UUIDs and GUIDs. A copy is available at http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt.

Note that object id's should only considered unique when the server id has been prepended to it.

Invoker

The side of the Lightweight Distributed Objects (LDO) connection which places a method call structure onto the wire in an attempt to perform a method call action inside of a connected peer. The invoker should only have a proxy to the remote object, it should not have the actual contents of the object.

Invokee

The side of the Lightweight Distributed Objects (LDO) connection which receives the method call structure and actually performs the necessary computations and data changes. The invokee must always have the real contents of an object.

Proxy

Dummy object existing only on the client side of an Lightweight Distributed Objects (LDO) connection. It exists at the language level to make access to the remote object transparent for the programmer and his/her programming language.

Client

Side of the Lightweight Distributed Objects (LDO) connection which holds only a proxy to the object. Invokers are generally always clients, however they may also be the server itself (in the case of a loopback Lightweight Distributed Objects (LDO) connection). Note that clients and servers constantly switch roles, depending on the specific object reference which is in question.

Server

Side of the Lightweight Distributed Objects (LDO) connection which maintains the current state of an object. Invokees are always servers. Note that clients and servers constantly switch roles, depending on the specific object reference which is in question.

Method Signature

Each method in a class has a method signature: this signature includes the method name, result type and argument types for each and every argument that the method takes as input. Argument names must not be included as part of the signature, as they are typically not used during compilation of method calls.

Interface

An interface is the sum total of all method signatures in a class, including both class methods (aka static methods) and instance methods.