DOF Glossary – Common Terms
DOF Technology uses many terms that are derived from Object Oriented Programming and some that are used, primarily, in reference only to The Technology. Understanding how we use these terms, in relation to our Technology, simplifies the learning process. We provide this Glossary to help you gain a better understanding as you learn.
TOC – Security
Terms
OAL
An Object Access Library (OAL) written in a specific programming language that is used to access data which meets the standards of DOF technology.
DOF Object
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. Learn more about the DOF Object Model
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.
DOF Interface
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). You can see the DOF Interface Repository at: https://interface.opendof.org
Interface Identifier (IID)
An interface identifier (IID) is a globally unique identifier for interfaces.
Node
A physical or logical networking device that communicates with other nodes. In OpenDOF, a node can be a provider, requestor, or proxy.
Provider
A provider is a node on a DOF network that provides functionality defined in one or more DOF interfaces.
Requestor
A requestor is a node on a DOF network that requests functionality from a provider.
Proxy
In DOF topology, a proxy is a node that acts as intermediary between two endpoints (a requestor and a provider). These endpoints desire to communicate, often across different networks. The proxy is capable of routing operations between the endpoints without being “visible” to either.
Example of a Proxy node communicating across two networks.
Binding
The combination of an OID and an IID that identifies a provider on the network as well as the functionality it is providing. These are also referred to as Binding Permissions.
- For an overview of bindings and permissions, try the OpenDOF Permissions Matrix
Learn more about Bindings and Binding Permissions.
Interface Property
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.
Interface Method
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.
Interface Event
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.
Interface Exception
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.
Provider Exception
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.
Error Exception
An error exception is an exception in the API generated by the internal library.
Synchronous Operations
A requestor initiates an operation and the provider executes the operation and responds. Synchronous operations are:
- A calling operation
- Blocking
- First In/First Out
- Messages are sent and received using the same connection
- Only one response is received
More information is available here.
Asynchronous Operations
A requestor initiates an operation and the provider executes the operation and responds. Asynchronous operations are:
- Callback operations
- Nonblocking
- Multiple results are received
- Messages are sent in form and can be delivered in another
More information is available here.
Get Operation
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.
asynchronous get operation
Set Operation
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.
synchronous set operation
Asynchronous Set Operation
Invoke Operation
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.
Synchronous Invoke Operation
Asynchronous Invoke Operation
Subscription Operation
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.
Subscription Operation
Register Operation
A register operation is initiated by the requestor to recieve notifications when an event is triggered.
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.
Register Operation
Interest Operation
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.
Provide Operation
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.
Advertise Operation
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.
Query Operation
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. It finds only provide operations that the requestor is storing in state on its local system. Because the system will not store provide operations without a matching interest operation, queries are useful only in conjunction with interest.
Watch-Level Interest
In a watch-level interest operation, a requestor finds only providers that have already performed a provide operation. It also causes direct routes to be set up between providers and interested requestors.
Activate-Level Interest
An activate-level interest operation causes providers capable of providing an interface to perform a provide operation in response.
Connect-Level Interest
This level of interest includes all the functionality of the ACTIVATE level. In additions, it causes streaming connections to be established between all nodes between the requestor and the provider, if those nodes are capable of establishing streaming connections.
Domain
DOF Technology uses the term “Domain” as follows:
- The domain is the container of all permissions granted to a node.
- A domain allows communication between all objects within the domain, based on the permissions granted to an object.
- It is not possible (unless both are a security bridge) for one remote domain to communicate with another remote domain, regardless of permissions.
Authentication Server (AS)
A database used to authenticate the credentials of users, services, devices, applications, etc. In the case of DOF Technology and operations in the Cloud, an AS can centralize security information, creating a shared trust environment without exposing credentials.
Service
Utilizing OpenDOF, a service is an application that provides functionality over the network that is intended to always be available. A service will maintain a persistent connection to its IoT Platform and will automatically reconnect if that connection is lost.
Permissions
Permissions determine the operations that a provider or requestor can perform.
- For an overview of permissions, try the OpenDOF Permissions Matrix
- See the Permission Type Registry
Binding Permissions
The binding permission controls the types of operations (defined by the interface) that a node can perform. Actions are added to this permission to control each operation. These actions are as follows:
- For an overview of permissions, try the OpenDOF Permissions Matrix
- Provide. Allows a provider to provide an interface.
- Read. Allows a requestor to perform get, subscribe, and register operations.
- Write. Allows a requestor to perform set operations.
- Execute. Allows a requestor to perform invoke operations.
- Session. Allows a requestor to open sessions.
See also: Binding
ActAsAny Permission
The ActAsAny permission allows a proxy node to forward operations for other nodes. This permission is instantiated by calling its constructor, DOFPermission.ActAsAny.
IAm Permission
The IAM permissions allows a node to originate an operation. This permission is automatically granted if the credentials have any other permissions. This permission is instantiated by calling its constructor, DOFPermission.IAm.