Isect Middleware How-To - Introduction

Go to the first, previous, next, last section, table of contents.

# Introduction

Long before the buzzwords "client-server" and "middleware" were ever coined, programmers used middleware to build client-server systems. They programmed using character or block IO directly to the network devices which may have been proprietary, like Data General's MCA cards, or standard like UARTs for serial communications.

Over TCP/IP networks, regardless whether the network interface is token-ring, ethernet, or PPP, the socket library developed at the University of Berkeley became the standard way for programs running on different computers (or even the same computer) to communicate with each other.

But writing servers is more complicated than just read()ing requests from a client. What if there are multiple clients? What if the client dies while you're still processing? What if the server dies? How does the client find the server? Should or must the server be multitasking? How should semaphores be used? These issues all concern network programming and have little (read: nothing) to do with what the programmer really needs the server to do. In fact, for simple server programs the overhead of the network programming may make it not worth it to create the server in the first place.

To understand how isectd works, it is important to understand two new concepts: services and workers.

A worker is what most programmers would recognize as a server. It is the program that actually does the application's heavy lifting. For banking applications it may be the transaction processor accepting deposit, withdrawal, payment, and advance transactions, and updating account balances in the database. It may be also be a receipt printer, a job scheduler, or an interface into a real-time market data system like Reuters for price quotes or news.

A service is a collection of workers that all do the same thing. Each worker is single-threaded, it has only to deal with the transaction it's working on and won't be interrupted by another request until its done. By being single-threaded the code is more portable, but more importantly it is scalable. Multithreaded, or multitasking, programs can scale only to the capacity of the machine they're running on. They can run no faster than local RAM and CPU allow. Single-threaded programs that are not tightly bound to each other can easily be replicated on other machines on the network. Limited only by the aggregate capacity of memory and processing power on all the participating computers.

When a client connects to isectd it specifies the service it is interested in. Isectd takes each client requests and sends it to the next available worker providing the identical service. Since clients may make asynchronous requests (not waiting for an answer for one transaction before sending the next) isectd effectively multiplexes their transactions across however many workers it has available providing the service the client's requesting.

The service name is completely arbitrary and functions only as a commonality between like-workers and the clients requesting the service those workers provide. In our banking application above the transaction processor may be named `tpworker` and isectd may be configured to start 12 of them on three different computers. Collectively they may be configured to provide a service called "TPSERVICE". When the client programs login to isect they will specify that the transactions they'll be sending are for "TPSERVICE". Isectd will dutifully and equitably dole them out to any available TPSERVICE worker.

Go to the first, previous, next, last section, table of contents.