What is DOF? Building blocks and elements
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.
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.
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.)
- 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"
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.)