Middleware products for distributed computing offer the application designer transparent access to objects, regardless of their physical location. The middleware has to choose the appropriate communication means to delegate the clientīs messages to the servant object. These objects do not necessarily reside on different physical CPUs. Sometimes they are mere different processes on the same machine. In that case the software component that undertakes the actual task of performing the communication must provide good performance. Replacing the IIOP strategy found in many ORB implementations by some other IPC mechanism already improves performance a little (see also section 4.3.5). Data movement across user-kernel boundary, synchronisation and context switching have however major impacts on interprocess communication speed[SS99]. Although it is such a basic concept, included in many commercial-off-the-shelf operating systems, no real efficiency advances can be seen when regarding the development of IPC mechanisms over time[Lie93]. By approaching this problem using software components we are able to shield the programmer from low level details and still allow fully transparent optimization. Adopting the idea that drove the development of multithreaded architectures, i.e. light weight access to common data structures, we can implement a message queue outside the scope of the operating system[BALL91,EKJ95]. Again the goal is to provide a byte stream data transfer component with first-in-first-out semantics. Messages can be sent and received whole or in pieces. If the channelīs capacity is exceeded, the message may or may not be handled by the component. For the concrete implementation, we let the sender perform a busy wait operation until the IPC component has enough space free to take the message. The receiver is only blocked if there are not enough data in the queue to be read. As we will see later, these two cases are the only ones in which an operating system call for process synchronisation has to be involved. The light weight component is compared to System V message queues in order to give an impression of the overhead introduced by extensively using operating system services (see figure 47 for an architectural comparison).
