Control module architecture is inspired by the EJB model, which introduces
the distinction between component (the Java Bean) and container (the
component server). We have already adopted this solution in Prototype 3 of
Chapter 15 where we had to manage the concurrent access of remote clients
to the GIS databases.
How does the control module manage the execution of multiple concurrent
The framework offers two abstract classes to support multiple concurrent
tasks: DActivity and DProcess . A DActivity object represents an independent
sequential thread of execution belonging to a unique DProcess owner,
embeds the dynamic specification of its task, and has internal data.
The DActivity class has to be redefined for every concrete specification
that implements the logic of a control service. DProcess is the base class of
every control module. It encapsulates a collection of DActivity objects and
has to be redefined in order to encapsulate specific resources. Figure 19.2
shows the class diagram that depicts the architecture of the control module.
The right-hand side of the figure indicates the framework classes, while the
left-hand side indicates their customization for a given application.
public void run()
protected void init()
protected void step()
protected void quit()
Figure 19.2 The basic architecture of a control module