A Model for Modular DesignA DACIA application can be seen as a directed graph of connected components. The links between components indicate the direction of the data flow within the application. The graph may have cycles and multiple paths may exist in the graph between two components.
The same application can be built in multiple ways, either by configuring differently the same set of components or by using different sets of components. The figure below shows two different graphs corresponding to the same application. Ovals represent components. Light grey rectangles represent hosts. Components are connected through directed links, indicating the direction of the data flow within the application.
The application graph
PROCsIn DACIA, a component is a PROC (Processing and ROuting Component). A PROC can apply some transformations to one or multiple input data streams. It can synchronize input data streams; it can split the items in an input data stream and send them alternately to multiple destinations.
PROCs are mobile software components and they represent the unit of relocation. They are executable entities that may hold state, may be interrupted and restarted, and they are involved in communications with other entities. They are routing elements that dictate the structure of an application and the data paths.
PROCs communicate by exchanging messages through ports. An output port of a PROC is connected to an input port of another PROC. The communication can be either synchronous or asynchronous. For synchronous communication, the PROCs must be located on the same host and the thread that executes the output() method of the source PROC will also execute the input() method of the connected PROC and thus the action associated with that PROC. In the asynchronous case, the messages received by a PROC are inserted into the PROC's message queue. Every PROC has a thread that handles the messages in the queue, usually in FIFO order.
The EngineThe engine is the most important part of DACIA. It decouples the application and component-specific code and functionality from the general administrative tasks such as maintaining the list of PROCs and their connections, migrating PROCs, establishing and maintaining connections between hosts and communicating between hosts.
A DACIA distributed application
A minimal application consists of an engine and a few PROCs, connected in some configuration. A distributed application is created by connecting engines running on multiple hosts and eventually connecting PROCs running on different hosts. An engine has global knowledge about all the PROCs in the system and the configuration of the application. When two engines connect to each other, they exchange information about each other's local views, so that they establish a consistent view of the system.
The MonitorThe engine works in conjunction with a monitor. The monitor represents the part of an application responsible for performance monitoring and making reconfiguration decisions. The monitor instructs the engine about the reconfigurations to be made. The engine is responsible for creating and destroying PROCs, establishing and removing connections between PROCs, and for moving PROCs between hosts.
The monitor is usually specific to a particular application or class of applications and it incorporates relocation and reconfiguration policies applicable only to those applications. An application can use simultaneously multiple monitors, implementing different adaptations.
ConnectivityThe engine maps virtual connections between PROCs to either local or remote physical connections, and handles data transfers accordingly. Multiple virtual remote connections between pairs of PROCs are multiplexed over a single network connection between two engines. The connectivity between remote PROCs is maintained as long as the corresponding engines are connected. Sharing physical connections reduces the cost of establishing network connections in a highly dynamic application, where PROCs often connect to each other or they are disconnected.
Component MobilityPROCs can move between hosts while maintaining seamless connectivity with other PROCs. The structure of the application does not change and the flow of data in the system is not interrupted. The movement of a PROC is usually transparent to other PROCs.
The mobility of PROCs provides an additional benefit. A PROC can be written to be hardware-dependent. In this case, when a PROC moves from one host to another, it can be made to exhibit different capabilities, depending on the host. For example, on a high-end host, a PROC can have a full-fledged graphical representation and it can present a GUI interface to the user. On a PDA, the same PROC only displays information in text format and it eventually sends visual or sound alerts to inform the user about important changes in the events monitored by the PROC. The user is able to move the PROC from one device to another without having to re-instantiate it or to connect again to other PROCs.
Adaptation through Runtime Reconfiguration of the ApplicationIn many cases, an application can adapt to dynamic changes in load and the specific execution environment by reconfiguring itself at runtime. A more efficient execution can be achieved through better usage of the available resources and optimized inter-PROC communication. The reconfiguration consists of either reordering or relocating some components or replacing a set of components with a different set of components, possibly connected in a different configuration.
With DACIA, we attempt to minimize the effort for building customized adaptive applications, by putting as much complexity as possible in the infrastructure and as little as possible in the application itself. General-purpose adaptive policies can be embedded in the infrastructure. For example, filters that reduce the amount of data should be placed as early as possible in the data path. Also, a pair of Compress/Decompress components can be introduced at the ends of a slow network link. Additionally, application-specific adaptive policies can be implemented in the monitor.
ImplementationTo date, we have fully implemented a DACIA prototype in Java.