Network Computingwww.networkcomputing.com

Many organizations developed and deployed terminal-mainframe applications over private corporate networks in the 1970s and 1980s. In the 1990s, many new applications have been developed by using the C/S paradigm over the same networks. More recently, a few applications have started using distributed objects. Now, the Internet has taken off and has introduced Web browsers and servers all around us. Figure 2.17 shows the result of this evolution. Let us go through some details of this environment in terms of networks, clients, and servers.

The current corporate networks consist of private TCP/IP (Intranet) and non-TCP/IP (e.g., SNA) networks. The non-TCP/IP networks typically support the mainframes and Novell local area networks. The private TCP/IP networks are seeing most of the activities in client/server computing and support many client/server applications. These networks are now also supporting the corporate WWW activities and have thus been relabeled as the Intranets (i.e., private Internets). The private networks are connected to each other and to the public Internet through the gateways that provide protocol conversions between different networks. We are not showing security firewalls between these networks (firewalls, briefly, check the traffic between networks to make sure that only the authorized users are accessing the network).

Figure 2.17 Global View of Typical Environments

Client processes, or just clients, typically reside on desktop computers. However, a client may reside on a mainframe. For example, a client program on a mainframe may need to access a database server on a LAN. Here are some examples of clients, (only a few of these clients are shown in Figure 2.17):

A variety of servers, dispersed across a network, can be accessed from clients that may reside at different computers. Examples of some of the commonly known servers are as follows (Figure 2.17 shows a few of these examples):

These functional servers can run on a variety of hardware boxes ranging from laptops to mainframes. These hardware boxes, also called "servers," (unfortunately) must have the hardware capability and the associated operating system support to schedule and execute multiple requests.

State of the market for the OCSI environments (e.g., middleware, networks, database managers, transaction managers, operating systems, and computing hardware) is cluttered with hundreds of off-the-shelf products that are discussed regularly in trade magazines such as Web Week, Client/Server Today, Client/Server Computing, Object Magazine, Datamation, Database Programming and Design, and Data Communications. In addition, analysis of products are published regularly by consulting organizations such as the Gartner Group, Forrester Research, Seybold Group, and the Yankee Group. Let us quickly scan the state of the market for the key building blocks for application engineering/reengineering (middleware, networks, databases, and operating systems).

The middleware services have evolved, and continue to evolve, since the early 1990s. Each evolution has added more functionality and made it easier to engineer/reengineer the applications.

The growing number of commercially available middleware products should be seriously considered before undertaking in-house development. In most cases, it is better to develop applications that utilize the commercially available middleware. It is generally better to use the high level protocols and services, if available, to reduce the application complexity. The exceptions to these general guidelines are lightweight desktop applications. For these applications, it may not make sense to incorporate a heavyweight middleware that may more than double the cost of the application and impose platform restrictions (e.g., if the middleware runs on PCs only, then the application is restricted to PCs). In such cases, it may be better to use the network calls (e.g, TCP/IP sockets) for remote interactions.

In networks, TCP/IP and SNA have been state of the practice for a number of years. TCP/IP is a natural winner at present due to the popularity of Internet. Gateways and other interconnectivity devices between different networks are also commercially available from a multitude of vendors (Data Communications Magazine publishes information about these products regularly). Detailed discussion of networking issues is strongly beyond the scope of this book.

Database management systems have been state of the market since the 1970s. IMS, introduced in 1969, is still marketed and supported by IBM. However, most of the current database activity is centered around relational databases. Database vendors such as Oracle, Sybase, Informix, and IBM market and support relational database management systems for almost all platforms. OO databases, although very popular with the academic community since the mid-1980s, are not fully state of the market at the time of this writing. It is expected that the popularity of OO paradigm and distributed objects will push the OODBMSs into the main stream. We will just have to wait and see.

Operating systems, needless to say, are state of the market. MVS, introduced by IBM in the mid-1970s, is still being marketed and supported heavily by IBM. UNIX has become almost a de facto choice for mid-range computers. However, Microsoft’s Windows NT is currently competing with UNIX.

Standards are needed for portability and interoperability of distributed applications. Many standards are important in an OCSI environment (e.g., middleware standards, network standards, database standards, etc.). However, from an application engineering/reengineering point of view, middleware standards are of vital importance (middleware shields the applications from networks and operating systems). In particular:

Ideally, the APIs as well as exchange protocols should be open and based on standards. Unfortunately, many middleware APIs as well as the exchange protocols are proprietary.

A major area of growth is the object frameworks and component software to work in distributed environments. For example, frameworks at different machines can communicate with each other through the object request brokers (ORBs). In this context, we are using ORB as a generic feature which may be satisfied by CORBA or Microsoft DCOM. The melding of Web with distributed objects through object frameworks is also a natural area of growth. In essence, components can be integrated into frameworks and new components can be added to frameworks to build Web-based distributed applications. Microsoft’s ActiveX Platform, especially with the popularity of Visual Basic components, is a good example of these developments. The key point is that components, frameworks, ORBs, and Web complement each other to deliver business value–the main theme of this book.