Doctor of Philosophy, Computer Science

Submitted to:

Figure 1. --- H/C Architecture

This Architecture relied on a single General Purpose Programmable Computer that performed all the processing. Initially this Architecture provided Batch Processing on a local basis. Transactions were grouped into batches and delivered to the Computer Room were they were translated into "computer readable" form (Keyed to Punch Cards, Magnetic Tape, or Magnetic Disk).

The Batches were then input to the Single Computer H/C Architecture. As advances in Hardware, Software, and Network Technologies occurred, Local Batch Processing progressed to Remote Batch Processing. Dumb Terminals "hard wired" to the single H/C General Purpose Computer obviated the need to send the Batches to the Computer Room.

In 1977 I remember attending a Association Of Systems Managers (ASM) meeting in Hartford , CT where I had the privilege of listening to Commodore Grace Hopper. The first Cobol Programmer had the distinct insight to make the point that regardless of the exponential improvement in Hardware Technology there still were limits to problems that could be solved by a Single H/C Computer Architecture. She mentioned we did not have the "single computer" power to solve Weather Forecasting Models. The only way we could solve these complex problems is to divide the problem into component pieces. As such we must find a way for multiple processors to work in parallel on components of the problem. Although Massive Parallel Processing (MPP), Distributive Processing (DP), and Client/Server (C/S) Architectures were never mentioned, I often think of Ms. Hopper's prediction when working with these Architectures years later.

Figure 2. --- C/S Architecture Universal Model

Regardless of whether the C/S Architecture is 2-Tier, 3-Tier, or N-Tier, a Universal Model accommodates all situations. Unlike H/C Architecture, the C/S Architecture is scalable, flexible, and adaptable to many diverse Enterprises. The C/S Architecture accommodates Small Local Businesses as well as the Global Enterprise. Three major building blocks form the Architecture: Client(s); Middleware(s); and Server(s). The key feature of the C/S Architecture is that the three components can be used in a variety of combinations to support processing functions distributed across the Client, Middleware, and Server Processors.

The Client Building Block provides the Graphical User Interface (GUI) to allow Users to access Services provided by the Server Building Block. The Server Building Block distributes Services to Client(s). The Middleware Building Block is the 'Nervous System" of the C/S Architecture. The Middleware Building Block coordinates the Client and Server Building Blocks. It is the Central Processing Unit (CPU) of the C/S Architecture.

Commodore Hopper knew we had to develop a Computer Architecture to "divide and conquer the problem". She knew the current H/C Architecture had its limitations. She knew we had to distribute the processing. The missing piece was the C/S Architecture consisting of three major components ---- Client(s), Middleware(s), and Server(s) that would distribute the Processes to accommodate a diverse set of processing environments.

In the good old days of H/C Architecture decisions regarding the Architecture were single dimensional. The decision was confined to picking the best Computer Vendor. Once the single Vendor was chosen additional complementary Hardware, Software, Network, and People Resources were provided automatically.

Although the C/S Architecture Revolution provided an improved scalable, flexible, and adaptive solution, the solution required many a la carte decisions that requires system integration expertise. As such the final destination is clear, but the road to get there is unclear requiring multi-decisions focused on achieving the single goal.

Figure 4. --- C/S Vision

C/S means different things to different people. There is no consensus. However, the most common definition of C/S is --- "Clients and Servers as separate logical entities that work over a network to accomplish a task". This sounds like Distributive Processing (D/P). As such a clearer definition must be made based on the following distinguishing characteristics.

• Service --- Relationship between discrete Processes running on separate but networked coordinated Computers. Server Processes provide Services. Client Processes consume Services.
• Shared Resources --- Servers share System Resources with Clients
• C/S Relationship --- Clients request a Service. Servers await Client requests and provide Service to the Client.
• Transparency of Location --- Client and /or Server Processes are logical entities and thus independent of physical location. The Network determines the communication and coordination of the logical entities.
• Platform Independence --- Open Systems Architecture allows mix-and-match of multi-vendor hardware and software platforms.
• Message-Based Communication --- Clients and Servers communicate via a message-passing mechanism.
• Service Encapsulation --- Servers provide Services requested by Clients. Clients do not have to know how the Service is provided --- Only how to request the Service. As such Servers can be upgraded and scaled without affecting the Client(s) as long as the message interface which exposes the Service is preserved.
• Scalability --- Both Clients and Servers can be scaled upward or downward.
• Integrity --- Services are centrally managed, modified, and deployed. This reduces the Total Cost of Ownership (TOC) of the many Clients while allowing for Client personalization and independence.

Figure 2. --- C/S Architecture Universal Model

Adding to the confusion concerning C/S Architecture is that C/S has evolved through progressively sophisticated models since its inception in the middle 1980s with the advent of Local Area Networks (LANs). All these progressively sophisticated iterations comply with the C/S Architecture Universal Model.

Figure 5. --- C/S with File Servers

One of the early C/S Architectures allowed for sharing of files across a network. This was a primitive form of resource sharing that required a high level of message activity to share the file data among the Client(s). File Calls were requested by the Client(s) and serviced by the File Server(s).

Figure 6. --- C/S with Database Servers

The next progressive improvement of the C/S File Server was the C/S Database Server. This C/S Architecture substitutes SQL Calls for File Calls. As such Relational Database Management Systems (RDBMS) Service is shared throughout the Architecture.

Figure 7. --- C/S with Transaction Servers

With C/S Transaction Server the Client invokes Remote Services processed on the Server(s). File Calls and/or SQL Calls are no longer required. This is much more efficient because the message traffic between Client(s) and Server(s) is dramatically reduced.

Figure 8. --- C/S with Groupware Servers

C/S Groupware allows People to collaborate on text, image, mail, bulletin boards, and other work flow information. Many Groupware Products use email as the standard message-passing mechanism. Lotus Notes and Microsoft Exchange are examples of Groupware Applications that operate on this C/S Architecture.

Figure 9. --- C/S with Distributed Objects

With the C/S Distributed Object Architecture Client Object(s) communicate with Server Object(s) using Object Request Broker (ORB) Technology. This Architecture applies Object Oriented Component Technology (OOCT) to C/S. The Client(s) through the ORB locates the appropriate instance of the Server(s) Object Class, invokes the requested method of the Server(s) Object, and returns the results to the Client(s) Object. This remote invocation approach is called Remote Method Invocation (RMI). RMI is similar to the remote invocation of Stored Procedures (i.e. C/S Transaction Server Architecture), but utilizes Distributed Objects Technology (DOT).

As such without the appropriate C/S Architecture, there would not be an environment to support DOT. ORBs which provide the glue to support DOT come in two commercial flavors. The Object Management Group established the Common Object Request Broker Architecture (CORBA) standard for ORBs. IBM, SUN, Iona, BEA, and others Enterprise DOTs support CORBA. Microsoft has its own ORB called Distributed Component Object Model (DCOM).

Not surprisingly, there is the typical Unix and Windows split on employing DOT.

However, there are bridges between the two ORBs that allow mix-and-match of ORBs as well as Object Components from a number of Vendors.

This evolution of the C/S Architecture is a significant milestone because it provides an Architecture for realizing the dramatic benefits of DOT. I participated with a Healthcare Systems Integration Standards Organization called the Andover Work Group (AWG) which developed a product to provide "plug and play" interoperability between diverse Healthcare Applications. This Product called the Enterprise Integrator (EI) depended upon DOT and a C/S Architecture that would support DOT. EI components were plugged into sending and/or receiving Applications residing on Server(s). The Applications communicated through Middleware using ORBs and RMI. The Applications did not require modification. The EI components provided the plug and play interoperability using the C/S Architecture infrastructure.

Figure 10. --- C/S with Web Servers

The scalability, flexibility, and adaptability properties of the C/S Architecture Universal Model are demonstrated with its support of Internet Technologies. The C/S Web Server Architecture employs Web Server(s) and Browser Client(s) to extend the Model to the World Wide Web (WWW). This is not a new C/S Architecture but an evolution of the Universal Model that takes advantage of the progressive improvements in Hardware, Software, and Network Technologies.

The Internet Technologies for the most part are based on DOTs. Client(s) and Servers(s) communicate using the Hyper Text Transfer Protocol (HTTP) to transfer Hyper Text Mark-up Language (HTML) Documents over a Public Wide Area Network (WAN) called the Internet. The basic Building Blocks --- Client(s), Middleware, and Server(s) of the C/S Universal Architecture Model are required. The distinguishing characteristics of C/S continue to apply. Although the Technologies supporting the three Logical Building Blocks have progressed and will continue to progress, the C/S Universal Architecture Model persists and extends itself to assimilate the Technical Advances.

As the C/S Universal Architectural Model has evolved from the C/S File Server to the C/S Web Server Architecture the Client(s) have lost weight and the Server(s) have gained weight. Advances in Hardware, Software, and Network Technologies have re-distributed the Application Load to the Server(s) while reducing the load on the Client(s). This Centralized Application Management Strategy has reduced the Total Cost of Ownership (TCO) of the Client(s) as well as the TOC of the C/S System.

Moreover, the C/S Universal Model lends itself to "load balancing" of the Application across multiple Server(s) to improve scalability, responsiveness, and security. As Hardware, Software, and Network Technologies continue to advance, "load balancing" options will continue to proliferate, as C/S Applications become more sophisticated and enterprise-wide in scope.

Figure 12. --- 2-Tier vs 3-Tier C/S Architectures

The C/S Universal Architectural Model has also evolved from the 2-Tier Architecture to the 3-Tier Architecture. As Applications become more sophisticated the C/S Architecture requires more Server(s) to support the Application. With 2-Tier C/S Architecture the major Application Services are executed on the Client(s). This is fine for C/S File Server Architectures or C/S Database Server Architectures for a Small Business operating over a LAN. However, 2-Tier will not scale properly for a C/S Web Server Architecture for a Large Global Enterprise.

The TCO for a 2-Tier C/S Web Server Architecture alone would be prohibitive. Moreover, the C/S Web Server Architecture would be almost impossible to manage and maintain if Application Services were executed on the myriad of Clients distributed to a variety of different physical locations. As such a 3-Tier C/S Web Server Architecture is required to offload Application Services from the Clients. Client Services should be confined to the GUI or Presentation Services under this scenario.

Figure 13 --- Comparison of 2-Tier and 3-Tier C/S

Thus the evolution of the C/S Universal Architecture Model from a 2-Tier to a 3-Tier C/S Architecture has been positive for many reasons. The only reason to stay with the 2-Tier Architecture is Ease of Development given the Application is non mission-critical and operates on a LAN for a Small Business. Furthermore, as the C/S Universal Architecture continues to evolve toward 3-Tier and N-Tier C/S Architectures ---- Server-side development tools are becoming as prolific as Client-side development tools. Object Components will permeate both sides of the C/S Architecture.

Figure 14. --- Object Components in C/S N-Tier Architecture

The C/S Universal Architectural Model consists of three principal Building Blocks. Client Tier(s), Middleware Tier(s), and Server Tier(s) provide the foundation for the traditional 3-Tier Architecture. However, because each Tier includes multiple Logical Units the 3-Tier Framework is really N-Tier. The incorporation of DOT into the C/S Architecture has produced an Object Component N-Tier Architecture (OCNTA). As such in today's world of multiple Clients, Middleware, and Server Logical Units 3-Tier is N-Tier.

The Middleware Logical Unit is the place to deploy multiple Object Components working in consort to provide Services requested by multiple Clients deployed throughout the C/S System. These Object Components not only provide Services to Clients, but also interact with other Servers throughout the C/S System. For example a Middleware Object Component might interact with a Legacy Server to extract information from a Data Store and map the reply back to a Client using a Browser to display the result. Object Components have elevated the Middleware Logical Unit to play a critical role in the C/S Architecture.

As such, the use of Object Components has dramatically improved our capability for building C/S N-Tier Systems as well as extending obsolete Legacy System H/C Architectures to the new C/S N-Tier Architecture. A short list of advantages associated with deploying Object Components on the Middleware Logical Unit to establish a C/S 3-Tier Architecture include:

• Modular Development of Large Applications in small incremental steps;
• Reuse of Object Components;
• Capability to extend obsolete Legacy System Architectures;
• And upgrading the Client Tier to "best of breed" GUI while preserving the Functionality and Data Store of the Legacy Server(s) Tier.

Figure 15. --- 3-Tier (N-Tier) C/S Architecture Dominance

As new Systems become more sophisticated, mission-critical, and Enterprise-wide in their reach, N-Tier C/S Systems have begun to dominate. Furthermore, Legacy Systems are being extended or re-architected. The use of Middleware to extend these Legacy Systems requires a N-Tier C/S Architecture. A 2-Tier C/S Architecture will not suffice.

Figure 16. --- Web C/S vs LAN C/S

The commercial application of the Internet and it's complimentary Technologies have had a major impact on the evolution of the C/S Universal Architectural Model to transition from the 2-Tier Infrastructure to the N-Tier Infrastructure. The Internet advanced the Network Resource so critical in Today's Global Society in which virtually all Enterprises operate. The Internet provides the "Universal Connectivity" required to connect the multiple Client(s), Middleware(s), and Server(s) that predominate the N-Tier C/S Architecture.

However, the Internet had some help in precipitating this C/S Architectural Revolution. Object Component deployment provided a major impetus for the Revolution to take hold. The Internet provided the Universal Access and Connectivity that facilitated DOT.

The break-through in the evolution of the C/S Universal Architectural Model was the N-Tier Web C/S Architecture fueled by the deployment of DOT over the Architecture. OOCT finally had an Architectural Platform to provide viable Benefit to Enterprises of all sizes.

"The big insight for the next ten years is this: What if digital communications were free? The answer is that the way we learn, buy, socialize, do business, and entertain ourselves will be very different."

Bill Gates, Chairman

Microsoft

The above quote from Bill Gates provides some insight in what we might expect for C/S Architecture in the Future. This Intergalactic Vision of C/S Architecture is based on the promise of high bandwidth at very low cost. Assuming this holds true, virtual Enterprises will proliferate and immediately engage in e-commerce across the ubiquitous reaches of the Intergalactic C/S Architecture. Low cost universally accessible Network Infrastructures will give way to the next generation of Internet Technology called the Object Web. The next evolution of the C/S Universal Architectural Model will accommodate the Object Web.

DOT now will have an ubiquitous reach across the Intergalactic C/S Architecture of the Future. DOT will provide the means for virtual Enterprises to transact Business anywhere at anytime.

2.) Encyclopedia of Computer Science, Anthony Ralston, Petrocelli/Charter, 1976

3.) Client/Server Survival Guide, Third Edition, Robert Orfali, Dan Harkey, and Jeri Edwards, John Wiley & Sons, Inc., 1999

4.) Client/Server Architecture, Alex Berson, McGraw-Hill Computer Communications Series, 1996

5.) Client/Server Computing: Architecture, Applications, and Distributed Systems Management, Bruce R. Elbert, Artech House Telecommunications Library, 1994

6.) Data Modeling and Design for Today's Architectures, Angelo R. Bobak, Artech House Computer Science Library, 1997

7.) Client/Server Information Systems: A Business-Oriented Approach, James E. Goldman, John Wiley & Sons, Inc., 1998