See Figure 1 on page for a diagram on DADL development.
The customer programs a distributed architecture in the DADL language. The DADL compiler emits stub code for each dagent and for the conversation.
The dagent stub code contains the necessary components to communicate with the conversation. In addition, the dagent stub code includes function templates. These templates only include the call interface as defined by the services in the architecture. These templates are then completed by the customer programmer to provide the runtime content. The remaining dagent code is provided by the writer of the dagent. To aid the dagent programmer is a run time dagent library.
The conversation code contains the necessary components to materialize the conversation including the connection interfaces to the dagent. The conversation code manages the conversation, monitors the behavior, and enforces the contracts. A run time conversation library aids the conversation.
See Figure 2 on page for diagram on DADL development.
The environment must contain two major services: namely the conversation manager and the dagent manager.
The conversation manager creates, destroys, and initializes conversations as well as managing the dagents entering and leaving the conversation. Special properties of the conversation such as persistence and reliability are enforced.
The dagent manager creates, destroys, initializes, migrates, pauses, and restarts dagents. Special properties of the dagents such as replication are enforced.
The DADL support environment is assumed to be robust. This includes services for authentication, authorization, data privacy, data integrity, marshaling, persistence management, replication, and service groups. Transaction processing, distributed lock management, databases, and GUI systems are assumed present.