Conclusions

A proof of concept implementation shows that it is indeed feasible to provide efficient object oriented communication by inserting a lean middleware layer. It delivers performance close to the underlying communication infrastructure of the application program. This is achieved by moving the majority of the protocol to precompiled stubs and skeletons and having an efficient dispatching mechanism that fits the nature of the problem domain. Taking into consideration that an application that uses ordinary message passing still has to parse and interpret the received command, we gain consistency and ease of higher level programming by using a thin object oriented layer. In order to provide fair comparison between different software components that are involved in building software for DAQ systems, we presented a performance model based on the $O$ notation. It supports the application designer in taking choices for building blocks of communication middleware. Such a heuristic approach alone will in most cases not be sufficient to describe the actual efficiency of a component. Measurements and graphical representations have to complete the picture. To improve the communication between processes on the same machine, we were able to demonstrate that a user-level component is effective. Performance gains up to a factor six can be delivered. The abstract IPC stream component allows to operate independently of specific messaging layers. The custom-made object invocation solution based on FIFOs performs about 30 times better than a state of the art CORBA implementation that necessitates presentation layer processing and communication based on the TCP/IP protocol. A direct comparison using TCP/IP as transport layer still results in 10 times improved upcall rate. Such an approach becomes even more important when moving to high speed network technologies like Myrinet [PLC95] where the lowest message passing layers already provide communication with latencies of about $11 \mu sec$ [CPL$^$97]. With ordinary object communication tools the bottleneck is therefore shifted to the receiver. Middleware software must be stripped down in order to exploit the benefits of channel performance. We are of the opinion that in the presence of strong requirements and a closed problem domain it is quite justifiable to use such non standard means. The object oriented programming paradigm should not be violated. It provides more flexibility then traditional library approaches and leads to an intuitive way of distributed programming. A light weight implementation of a client-dispatcher-server pattern[SS96] can meet all these needs.

Now, that we are equipped with the necessary tools for writing efficient data acquisition components, we have to focus our mind on the management of these programs. Only if all pieces collaborate we will be able to exploit the benefits of a large distributed system. The problems that go along with configuring, running and monitoring a set of heterogeneous processing nodes are sometimes non-trivial. We will learn about this in the next chapter by having a look at what tools are on the market to support this task. Following this market survey that is matched agains our system requirements, we will present a novel scheme for controlling applications in distributed systems, to show that the task is feasibile if we obey a single key idea: configurable policy objects.