4
The DRAMA Facade
This page is part of the ING document INS-DAS-31
Design
notes for UltraDAS
Usage
There is one object in each camera server that follows the Facade pattern:
it is an instance of the Camera-facade class. This object provides the
interface between the server and client programmes. Camera-facade follows
the Singleton pattern.
Inheritance
The Camera-facade is a concrete implementation of the abstract super-class
Facade. All the public methods of Facade are implemented in Camera-facade
(reimplemented, in fact; the C implementation of the classes prevents Camera-facade
inheriting any actual code from Facade). Camera-facade extends Facade by
adding DRAMA actions, which stand as methods that can be called from other
processes, and DRAMA parameters, which stand as public attributes accessible
by other processes. Camera-facade adds no public methods or attributes
to Facade that can be called from C.
Use of DRAMA; structural compromises
DRAMA libraries are not, in general, MT-safe, and DRAMA tends to pervert
the structure of a programme for its own ease of operation. In udas_camera,
DRAMA is explicitly and completely excluded from classes other than udas_camera.
The Camera-facade encapsulates DRAMA completely.
DRAMA only works well if a programme running DRAMA spends almost all
its time blocked while waiting for DRAMA messages. Any processing or non-DRAMA
I/O that blocks for more than a second tends to destroy the DRAMA message-net,
by overflowing message buffers throughout the system. This is a serious
problem for udas_camera. The problem is solved by splitting execution
of the Facade across more than one thread.
The main-stream DRAMA operations are done by the initial thread of the
programme. After initialisation, this thread runs just the DRAMA call-backs.
Where an action requires a blocking calls, an action thread is started,
and the DRAMA thread returns to read new DRAMA messages. When the action
thread finishes, it makes one specific DRAMA call - DitsSignalByIndex,
which is known to be MT-safe - and thus causes the initial thread to wake
up and join with the action thread. Thus, DRAMA is almost entirely confined
to one thread of the programme.
Resetting the programme
DRAMA runs a connection-oriented protocol. Tasks in the message net maintain
virtual connections, and remaking these connections if one task drops out
of the net is messy and time-consuming. Hence, udas_camera is designed
not to drop its DRAMA connections on a reset.
Executing the RESET action on udas_camera causes the Camera-facade
to stop reading DRAMA messages for the duration of the reset, but does
not cause it to log out of the message net. That is, DitsStop must
not be called during a reset.
Other topics concerning the Facade