An Object Access Library (OAL) written in a specific programming language that is used to access data which meets the standards of DOF technology.
In the DOF Object Model, a DOF object can be anything that provides the functionality defined in a DOF interface. DOF objects are represented by the DOFObject class in the OALs. They must have object identifiers (OIDs). All DOF objects are providers.
Object Identifier (OID)
An object identifier (OID) is used to define anything in that needs a unique identifier. OIDs must be globally unique. Note that although each DOF object requires an OID, OIDs can be used to identify other programming objects in addition to DOF objects.
A DOF interface defines the items of functionality a DOF object must provide. Interface items of functionality are properties, methods, events, and exceptions. DOF interfaces must have interface identifiers (IIDs).
Interface Identifier (IID)
An interface identifier (IID) is a globally unique identifier for interfaces.
A provider is a node on a DOF network that provides functionality defined in one or more DOF interfaces.
A requestor is a node on a DOF network that requests functionality from a provider.
The combination of an OID and an IID that identifies a provider on the network as well as the functionality it is providing.
Properties are similar to fields in a Java class. They define one specific type of information about the provider. If an interface defines readable properties, a requestor can use a get operation to retrieve the current value of the property. The requestor can also potentially use a “subscribe” operation to subscribe to the value of the property and be continually updated whenever the value changes. Finally, the requestor can use a “set” operation to change the value of writeable properties.
An interface method is a function that the requestor can call remotely through an “invoke” operation and that the provider executes in a prescribed fashion (as defined by the interface). As with all functions, they may have input parameters and return types.
An interface event is a circumstance that triggers a response. Requestors can use register operations to be notified when the circumstances have occurred on the provider. Events may have output parameters.
Although the DOF API defines a number of different types of exceptions, the interface itself will define exceptions when any of its properties, methods, or events have logical exception cases. Exceptions defined in an interface are called provider exceptions in the API and are represented by the DOFProviderException class.
A provider exception is an exception in the API that represents an exception defined by the interface and that must be implemented by a provider.
An error exception is an exception in the API generated by the internal library.
In a “get” operation, a requestor can get the current value of a readable interface property from a provider. “Get” operations can be initiated by the requestor as either a synchronous operation using the DOFObject.get method, or as an asynchronous operation using DOFObject.beginGet.
In a “set” operation, a requestor can set the value of a writeable interface property for a provider. Set operations can be initiated by the requestor as a synchronous operation using the DOFObject.set method, or as an asynchronous operation using DOFObject.beginSet.
In an “invoke” operation, a requestor calls an interface method, and the provider executes it and returns results if the method has return values. Invoke operations can be initiated by the requestor as a synchronous operation using the DOFObject.invoke method, or as an asynchronous operation using DOFObject.beginInvoke.
In a “subscribe” operation, a requestor subscribes to the value of a provider’s interface property, and the provider notifies the requestor each time the value changes. Subscribe operations are always asynchronous and require interest.
In a “register” operation, a requestor registers for an interface event, and the provider notifies the requestor when circumstances trigger the event. Register operations are always asynchronous and require interest.
In an “interest” operation, a requestor broadcasts its interest in nodes with specific bindings. The requestor receives corresponding provide operations in response, which establishes a route between the requestor and matching providers. Interest is broadcast to all nodes on the network and stored in state until it is canceled. The requestor must specify an interest level: WATCH, ACTIVATE, or CONNECT. Interest is rebroadcast by the library once per hour.
An operation initiated by a provider that is broadcast to all nodes on the network, informing them which interface the provider provides. Provide operations are stored in state until canceled. If a provide operation was initiated before an interest operation, the requestor will find the provider when it performs interest. However, unless the provide is in direct response to an activate-level interest, provide operations will not find requestors that expressed interest before the provide operation was initiated until the interest is rebroadcast.
An “advertise” operation is useful for a provider to initiate at startup. It finds all interest that matches an interface that the provider is capable of providing. This helps a provider that has just come online to find interested requestors before the interest is rebroadcast.
A requestor uses a “query” operation to search internally for provides it has already received. Because this is not a network operation, it is generally ineffective for a requestor to perform a query without first performing an interest operation.
In a watch-level interest operation, a requestor finds only providers that have already performed a provide operation.
An activate-level interest operation causes providers capable of providing an interface to perform a provide operation in response.