FAQ – DOF Connectivity

FAQs by topic:

What are the API components of DOF Connectivity?

The API components that enable DOF connectivity are

  • DOF: The basic naming prefix used throughout the libraries. The DOF class represents a DOF network node.
  • DOFSystem: The instance that contains the application logic that initiates or responds to operations. The DOFSystem instance sends operations and responses to the DOF.
  • DOFConnection/DOFServer: The DOFConnection instance is used to connect to a DOFServer instance on another node.
What is ''transport independence''?

One of the advantages of DOF technology is that it is transport-independent. This is made possible by isolating DOF protocols from transport protocols, relying on two basic abstractions: Network Address abstraction and Connection Type abstraction.

Do OpenDOF protocols rely on TCP or UDP?

No. OpenDOF libraries expose an abstraction called a “transport.” In the Java API this is an interface that can be provided by any class – even one provided by the end user. The transport API provides the necessary functionality for the DOF libraries to send and receive messages over any transport.

The project includes an implementation of the transport API for Internet Protocols (TCP and UDP). The protocols have been used over a variety of wireless protocols (802.15.4 native, 6LoWPAN) and several proprietary transports.

What is a ''proxy node''?
In DOF topology, a proxy node is an intermediate node between two endpoints that desire to communicate. The proxy is capable of routing operations between the endpoints.
How do OpenDOF libraries communicate with legacy systems?

The OpenDOF libraries allow for the dynamic creation of objects as well as dynamic creation of object interfaces. Communicating with legacy systems requires a protocol bridge, which is a program that uses the OpenDOF APIs as well as the API or protocol for the legacy system.

Depending on the complexity of the legacy system’s API or protocol this can be a simple task or more complex. However, the OpenDOF API is built to be friendly to these types of bridges. For example:

  • As mentioned above, the libraries allow the dynamic creation of objects and object interfaces. As the bridge discovers changes in the legacy objects it can easily reflect these changes (addition or removal) in the DOF.
  • Callbacks from the libraries are handled by a threadpool and responses can be easily deferred. This means that the bridge can easily begin a process (using the legacy API or sending a protocol PDU) and then formulate the response to the callback later when the legacy operation completes.

People have written numerous bridges using the OpenDOF libraries and the API has been tailored to make bridging as easy as possible.