Network Computingwww.networkcomputing.com

Simply stated, an object-oriented client/server Internet (OCSI) environment provides the IT infrastructure (i.e., middleware, networks, operating systems, hardware) that supports the OCSI applications–the breed of distributed applications of particular interest to us. The purpose of this chapter is to explore this enabling infrastructure before digging deeply into the details of application engineering and reengineering in Parts II and III of this book, respectively. Specifically, we review the following three core technologies of the modern IT infrastructure:

In addition, we will attempt to answer the following questions:

The information in this chapter is intentionally high level and is an abbreviation of the companion book [Umar 1997] that discusses the infrastructure issues, in particular the middleware, in great detail.

Figure 2.1 will serve as a general framework for discussion. This framework, introduced in Chapter 1, illustrates the role of the following main building blocks of OCSI environments:

We will quickly scan these building blocks and illustrate their interrelationships in multivendor environments that are becoming common to support enterprisewide distributed applications.

Figure 2.1 Object-Oriented Client/Server Internet Environments

Client/server model is a concept for describing communications between computing processes that are classified as service consumers (clients) and service providers (servers). Figure 2.2 presents a simple C/S model. The basic features of a C/S model are:

The following additional features, although not required, are typical of a client/server model:

The implication of the last two features is that C/S service requests are real-time messages that are exchanged through network services. This feature increases the appeal of the C/S model (i.e., flexibility, scalability) but introduces several technical issues such as portability, interoperability, security, and performance.

Figure 2.2 Conceptual Client/Server Model

Client/server applications, an area of vital importance to us, employ the C/S model to deliver business aware functionalities. C/S applications provide a powerful and flexible mechanism for organizations to design applications to fit the business needs. For example, an order processing application can be implemented using the C/S model by keeping the order processing databases (customers, products) at the corporate office and developing/customizing the order processing logic and user interfaces for different stores that initiate orders. In this case, order processing clients may reside on store computers to perform initial checking and preprocessing, and the order processing servers may exist at the corporate mainframe to perform final approval and shipping. Due to the critical importance of C/S applications to business enterprises of the 1990s and beyond, we will focus on C/S applications in this book.

Figure 2.3 shows the interrelationships between distributed computing and client/server models. Conceptually, client/server model is a special case of distributed-computing model.

Figure 2.3 Interrelationships between Computing Models

A Distributed Computing System (DCS) is a collection of autonomous computers interconnected through a communication network to achieve business functions. Technically, the computers do not share main memory so that the information cannot be transferred through global variables. The information (knowledge) between the computers is exchanged only through messages over a network.

The restriction of no shared memory and information exchange through messages is of key importance because it distinguishes between DCS and shared memory multiprocessor computing systems. This definition requires that the DCS computers are connected through a network that is responsible for the information exchange between computers. The definition also requires that the computers have to work together and cooperate with each other to satisfy enterprise needs (see Umar [1993, Chapter 1] for more discussion of DCS).

Distributed computing can be achieved through one or more of the following:

File transfer model is one of the oldest models to achieve distributed computing at a very minimal level. Basically, programs at different computers communicate with each other by using file transfer. In fact, e-mail is a special case of file transfer. Although this is a very old and extremely limited model of distributed computing, it is still used to support loosely coupled distributed computers. For example, media clips, news items, and portions of corporate databases are typically exchanged between remote computers through file transfers; and e-mail is used frequently to exchange files through embeddings and attachments.

The C/S model is state of the market and state of the practice for distributed computing at the time of this writing. C/S model, as stated previously, allows application processes at different sites to interactively exchange messages and is thus a significant improvement over the file transfer model. Initial versions of C/S model utilized the remote procedure call paradigm that extends the scope of a local procedure call. At present, the C/S model is increasingly utilizing the distributed objects paradigm that extends the scope of local object paradigm (i.e., the application processes at different sites are viewed as distributed objects).

Peer-to-peer model allows the processes at different sites to invoke each other. The basic difference between C/S and peer-to-peer is that in a peer-to-peer model the interacting processes can be a client, server, or both while in a C/S model one process assumes the role of a service provider while the other assumes the role of a service consumer. Peer-to-peer middleware is used to build peer-to-peer distributed applications.

In this book, we will primarily concentrate on a C/S model. File transfer model is older and does not need additional discussion. We will also not dwell on the peer-to-peer model because peer-to-peer applications are not state of the market and state of the practice at the time of this writing.

Client/server architecture provides the fundamental framework that allows many technologies to plug in for the applications of 1990s and beyond. Clients and servers typically communicate with each other by using one of the following paradigms (see [Umar 1997, Chapter 3] for detailed discussion and analysis of these and other paradigms):

Initial implementations of client/server architecture were based on the "two-tiered" architectures shown in Figure 2.4 (a) through Figure 2.4 (e) (these architectural configurations are known as the "Gartner Group" configurations). The first two architectures (Figure 2.4 (a) and Figure 2.4 (b) are used in many presentation intensive applications (e.g., XWindow, multimedia presentations) and to provide a "face lift" to legacy applications by building a GUI interface that invokes the older text-based user interfaces of legacy applications. Figure 2.4 (c) represents the distributed application program architecture in which the application programs are split between the client and server machines, and they communicate with each other through the remote procedure call (RPC) or queued messaging middleware. Figure 2.4 (d) represents the remote data architecture in which the remote data is typically stored in a "SQL server" and is accessed through ad hoc SQL statements sent over the network. Figure 2.4 (e) represents the case where the data exist at client as well as server machines (distributed data architecture).

Figure 2.4 Traditional Client/Server Architectures

Although a given C/S application can be architected in any of these configurations, the remote data and distributed program configurations are used heavily at present. The remote data configuration at present is very popular for departmental applications and is heavily supported by numerous database vendors (as a matter of fact this configuration is used to represent typical two-tiered architectures that rely on remote SQL). Most data warehouses also use a remote data configuration because the data warehouse tools can reside on user workstations and issue remote SQL calls to the data warehouse (we will discuss data warehouses in Chapter 10). However, the distributed programs configuration is very useful for enterprisewide applications, because the application programs on both sides can exchange information through messages.

The Open Software Foundation (OSF) Distributed Computing Environment (DCE) packages and implements "open" and de facto standards into an environment for distributed client/server computing. OSF DCE, also commonly known as DCE, is currently available on a wide range of computing platforms such as UNIX, OS/2, and IBM MVS. Figure 2.5 shows a conceptual view of OSF DCE. The applications are at the highest level and the OSI transport services are at the lowest level in DCE (at present, DCE uses the TCP/IP transport services). The security and management functions are built at various levels and are applicable to all components. The distributed file access to get at remotely located data, naming services for accessing objects across the network, remote procedure calls (RPCs), and presentation services are at the core of DCE. As can be seen RPCs are at the core of DCE. Additional information about DCE can be found in Rosenberry [1993].

Figure 2.5 OSF DCE