Learning DCOM

Client/Server Computing

This client/server technology seen in Figure 1-2 is what is now called the two-tier client/server environment. The client typically has a graphical user interface that talks to the server using various communications protocols, including netbios, named pipes, and sockets. Servers typically manage the back-end persistent data.

Figure 1-2. Client/server technology

Now the client had become even smarter; for example, it used the CPU productively to perform business logic and complex calculations. In fact, client applications became increasingly sophisticated. At the same time, the communication between the client and the server became more complex. With a client/server environment, the communications layer, or marshaling software, must be developed to handle client/server interaction. This kind of software was later called a middleware—a mediator for client/server interactions.

Here’s an explanation of marshaling. A process understands intelligible data, but it doesn’t understand a raw network stream. An example of intelligible data is a function argument, which has a size and a type. On the other hand, a raw network stream is broken into the bits that paddle across the network. Because there are different representations of data, network communication needs a translation mechanism called a marshaler. A marshaler is simply a piece of code that performs marshaling. Marshaling is the packaging of intelligible data into a raw stream. The client communications layer sends this raw stream to the server, via the network layer. Once the server communication layer receives the raw stream, it needs to unmarshal the raw stream into an intelligible format for the server, so that the server can correctly service the client request. Unmarshaling is thus the reverse of marshaling. For brevity, software developers use the term marshaling to describe both the packaging and unpackaging of communication data.

Figure 1-3. Marshaling

Figure 1-3 shows an example of the marshaling process, which can be divided into the following steps:

1. A client calls SetPage, passing in a document identifier, a page number, and page information.

2. The marshaler packages the data in a marshaled representation and sends the raw stream to the target server.

3. The raw stream turns into raw bits, and the bits swim across the network.

4. The marshaler on the server side unmarshals the data.

5. The server then invokes the target SetPage function. The process is practically the same upon return.

Back to the discussion of client/server architecture, the marshaling layer is usually written to take advantage of a single, specific protocol. To use another network protocol, a separate marshaling software has to be developed. Definitely not a pretty sight. This isn’t the only problem with client/server computing though. Listed below are other apparent problems exhibited by the client/server technology:

• Business logic and complex calculations are too expensive on client computers.

• Clients suffer dramatically from performance impacts, since clients run on “puny” machines.

• Software developers spend too much time writing protocol specifications and code to handle client/server communication.

• Each client/server system must utilize some form of security to prevent potential attacks.

• Security software is usually home grown, conforming to no standard.

Taking these problems into account, a better method had to be found. The search for a better method started the notion of three-tier client/server computing, or more generally distributed computing.