Component Framework
From MARIEWiki
Contents |
Component-based Development Philosophy
According to Software Component field of study in software engineering, a component is defines as a system element encapsulating services and exchanging data with other components or softwares.
Here's the general view of a component in MARIE :
- Ports are communication interfaces between components and other softwares elements of a system.
- Arrows indicates that Ports allows duplex communication.
- Ports are dashed to illustrate that component can have a variable number of ports according to the services and functionnalities it offers.
Component Management
In order to support components deployment and control, a unified management interface is included in the component framework. Two mandatory component elements and their corresponding ports are required : Director and Configurator. Those ports will be used by Application Manager (AM) and Communication Manager (CM) to exchange data with Director and Configurator.
Here's a view of a component with Director and Configurator :
- D port stands for Director port
- C port stands for Configurator port
- Director port receives commands and forwards it to the Director component element to control the component (init, start, stop, abort, suspend, resume, restart and quit).
- Configurator port receives commands and forwards it to the Configurator component element to configure the component.
Component Services and Functionnalities
The services and functionnalities offered by a component are all encapsulates in a component element called Handler. The Handler is the core element of each component defining :
- which ports are instanciated
- how the data coming from ports are handled
- how Director and Configurator's requests are handled
- how required functionnalities and services are implemented
Execution flow
Component's execution flow is based on a multithread execution model. In the component framework, threads are called Tasks. Components typically use following main tasks : the Component Task, the Control Task, the Handler Task and at least one Communication Task.
IMPORTANT NOTE : depending on the implementation/configuration scenario, it's possible to have multiple tasks trying to access the same ressources concurrently. It's important to be aware of such possibilities to avoid deadlocks and incoherent/destructive concurrent access.
Component Task
The Component Task activates and executes the component. It can also do some monitoring to check for execution problems.
Control Task
The Control Task activates and executes the Director and Configurator elements. This task assures that Director and Configurator are always able to receive requests and execute them by calling their corresponding implementation in the Handler. To do so, there's a small proxy mechanism called Request Agent which is responsible to handle intertask communications to executes request correctly.
Handler Task
Each Handler must choose an execution mode appropriate to its computing requirements (iterate, event-based, finite state machine, etc.). Execution modes are implemented and executed by Handler Tasks. The Handler is possibly to component element the more exposed to multithreading access. Other than the Handler Task, other tasks such as Communication Task and Control Task are to access it concurently.
Communication Task
A Communication Task typically runs the communication loop required to send and receive data for a specific communication library. Depending on implementation and communication library requirements, it might not be necessary to have a separate and independant task, but it's usually the case. It is important to be aware that using a separate tasks to handle communications usually imply multithreaded access, and requires to be careful to avoid deadlocks and incoherent/destructive concurrent access. The typical multithread access occurs when new data is received by the Communication Task and needs to be forwarded to a component's element running in another task. Each component's element is responsible to make sure that communication entry points (callbacks) are thread safe and non-blocking (if the callback blocks on any condition, it can creates big latencies or even complete communication stoppage). Usually, callbacks should be programmed to give control back as fast as possible to the Communication Task and leave data computing to another task.
For example, lets consider the case of an iterative Handler running a computing loop to update its internal states and services. This Handler uses a Port to offer service, and this Port depends on an independant Communication Task to send or receive communications (which is the case with many Communication Strategies instanciated by Port). The Handler implements Port's callbacks functions executed by the Communication Task when new data is available for this Port. In this condition, it's almost certain that new data will arrive in the middle of an iteration execution, leading to possible concurrent access that needs to be taken care of appropriately.
Builder
As presented before, Components are composed of many parts that needs to be assembled together. This is the role of another component element, called Builder.
