What is DOF? Building blocks and elements
Introduction
In any training, we often use illustrations or images to help you understand abstract concepts. The illustrations you’ll see here were created to help you understand how the DOF world works conceptually—the images are not “to scale” so to speak. It’s a little like visually representing the solar system. If you wanted to project a picture of the solar system on the wall and have the size of the planets and their orbits all in the correct proportions, the overall image would be far too large to fit on the wall and the planets way too small to see. Scale is ignored so you can understand the basic concept of the solar system, which is eight (maybe nine) planets revolving around the sun. In a like manner, the illustrations in the training are conceptual. So don’t confuse the visual representation of a concept with a physical or literal description of DOF technology. Now let’s begin.
DOF
This is the DOF. It is the core component of DOF technology. Its job is to route traffic within its specified domain (which you will learn about later). For now, just remember: it all begins with DOF.
DOFSystem
Before creating an application, you need to attach a DOFSystem to your DOF. The DOFSystem is where the application logic resides.
Adding additional elements
Adding additional elements to the DOFSystem allows you to request and provide information through your application.
- A Requestor is a node that is attached to a DOFSystem, which will be used to request information from a similar node called a Provider. (Note that you can attach as many Requestors as you need.)
- Provider. Like the Requestor, it is a node that is attached to a DOFSystem; but instead of requesting information, the Provider makes that information available—or provides that information—to the Requestor. (Here, too, you can attach as many Providers as you need.)
Domains?
- Traffic from the DOFSystem, and its associated nodes, is routed through the DOF because they are part of its domain.
- A Domain is the container of all permissions granted to the objects within that container; it allows communication between all objects within that domain, based on the permissions granted to an object.
Allowing Domains to "talk"
Now that you’ve been introduced to a DOFSystem, we’re going to talk about routing traffic between domains.
DOFServer
The DOFServer, which is also attached to the DOF, allows incoming traffic from another domain to be routed to that DOF.
- Permissions, security and bindings required to do this securely will be covered in later training.
DOFConnection
The piece that allows outgoing traffic to be routed from the DOF and its domain to another domain is the DOFConnection. The DOFConnection is attached to the DOF as well.
Here you can see how data flows through the DOFServer and DOFConnector; in from one domain, and out to another. Keep in mind that this illustration represents only the most basic configuration. In fact, you could have a variety of components in many different combinations—DOFServers, DOFSystems, DOFConnectors, Requestors, and Providers—all attached to a single DOF, and each component configured to handle traffic independently, both to and from a variety of discrete sources.
Let’s say you have an application that needs to interact with certain Requestors and Providers. As you can see in this illustration, your traffic is routed through the DOF, and data is delivered and received according to predetermined rules. (These predetermined “rules” include permissions, bindings, interfaces, and so on—all of which will be covered in future training.)
The Possibilities...
Taking what we've learned, let's start putting it into perspective. We will use a simplified illustration (above) to begin showing you the possibilities. In the Blue domain, our DOFConnection is establishing a connection with the Green domain, and Green is passing Blue's data on to the Orange domain.
Now, if you notice, the Green domain is a Proxy...it's just routing traffic between domains, that is its job. The Proxy exists because Blue and Orange may be on different networks (Blue may be a mobile application and Orange may be behind a firewall, for example).
Once the connection between Blue and Orange is established...a peer-to-peer relationship can be created. Many of our components become transparent so the Requestors and Providers can do their job (communication and transferring data).
On the application level, with a bit of planning and proper permissions, the objects begin passing data regardless of topology, domains, even the programming language does not matter. If you have 1,000 Requestors and Providers passing data around, it won't matter; these two will find each other and your information will reach its destination.
How?
OpenDOF and DOF Technology
Let's continue your DOF education with the next training. We call it the "Object Model", and it will give you more of the information you'll need to get started.
Copyright (c) 2015, OpenDOF Project, Inc. All rights reserved.