UNIT IV- MULTI TIER COMPUTING

Transcription

1 UNIT IV- MULTI TIER COMPUTING Objective The main objective of this chapter is how to perform the N-Tier architecture and migrates from 3 tier architecture and how its works and example of N-Tier architecture. Next topic is thin client and its functionality in client server system both topic having established their own advantages and disadvantages. Introduction The canonical client/server model assumes exactly two discrete participants in the system. This is called a two-tier system ; the application logic must be in the client or the server, or shared between the two. It is also possible to have the application logic reside separately from the user interface and the data, turning the system into a three-tier system. In an idealized three-tier system, all application logic resides in a layer separate from the user interface and data. This rarely happens in actual systems; usually the bulk of the application logic is in the middle tier, but select portions of it are the responsibility of the client and/or the server. The three-tier model is more advanced and flexible than the traditional two-tier model because the separation of the application logic from the client and the server gives application logic processes a new level of autonomy. The processes become more robust since they can operate independently of the clients and servers. Furthermore, decoupling the application logic from the data allows data from multiple sources to be used in a single transaction without a breakdown in the client/server model. This advancement in client/server architecture is largely responsible for the notion of distributed data. Standard Web applications are the most common examples of three-tier systems. The first tier is the user interface, provided via interpretation of HTML by a browser. The embedded components being displayed by the browser reside in the middle tier; these could be Java applets, ActiveXs, or some other kind of entity that can provide the application logic pertinent to the system. The final tier is the data being served from a Web server. Quite often this is a database

2 style system, but it could be a data-warehousing or groupware system. Many advanced applications can benefit from the use of more than three tiers. For example, when multiple data sources are being integrated (as in a data warehousing application), four possible tiers would be the individual data repositories, a server that unifies the view of this data, an application server that performs queries based on the unified view of the data, and the front end. The development of efficient and reliable systems with more than three tiers is still an imprecise science, but research in distributed computing is continuing to increase the availability and usefulness of such systems. The basic functionalities of 3 Tier or N-Tier follows are The presentation services tier is responsible for: Gathering information from the user Sending the user information to the business services for processing Receiving the results of the business services processing Presenting those results to the user The business services tier is responsible for: Receiving input from the presentation tier. Interacting with the data services to perform the business operations. Sending the processed results to the presentation tier. The data services tier is responsible for the: Storage of data. Retrieval of data. Maintenance of data. Integrity of data. In Windows DNA applications commonly implement their business logic using one or more of three implementation options. Asp Pages COM components Stored procedures running in the DBMS

3 Writing much business logic in ASP pages is a bad idea. Since simple languages are used, such as Microsoft Visual Basic Script, and the code is interpreted each time it is executed, which hurts the performance. Code in ASP pages is also hard to maintain, largely because business logic is commonly intermixed with presentation code that creates the user interface. One recommended approach for writing middle-tier business logic is to implement that logic as COM objects. This approach is a bit more complex than writing a pure ASP application. Wrapping business logic in COM objects also cleanly separates this code from the presentation code contained in ASP pages, making the application easier to maintain. The Third option for writing business logic is to create some of that code as stored procedures running in the database management system (DBMS). Although a primary reason for using stored procedures is to isolate the details of database schema from business logic to simplify code management and security, having code in such a close proximity to data can also help optimize performance. Architecture Trends Web Services, J2EE Connectors, Message Brokers, etc Web Services A standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI A means for businesses to communicate with each other and with clients Allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall Unlike traditional client/server models, such as a Web server/web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users. Different applications from different sources can communicate with each other without time-consuming custom coding, as all communication is in XML, Web services are not

4 tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications XML Extensible Markup Language - Used to tag the data SOAP Simple Object Access Protocol - Used to transfer the data WSDL is used for describing the services available UDDI - Universal Description, Discovery and Integration - Used to list what services are available. JMS Java Message Service JMS defines the standard for reliable Enterprise Messaging Enterprise messaging, often also referred to as Messaging Oriented Middleware (MOM), universally recognized as an essential tool for building enterprise applications Provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise. Message-driven beans enable the asynchronous consumption of JMS messages. Message sends and receives can participate in Java Transaction API (JTA) transactions. J2EE Connector Architecture allows JMS implementations from different vendors to be externally plugged into a J2EE 1.4 application server. J2EE Connector Architecture The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS.

5 Resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. An EIS vendor needs to provide just one standard resource adapter, which has the capability to plug in to any application server that supports the J2EE Connector architecture. See diagram of N-Tier Architecture for an overview of all these technologies and how they fit in. Figure: Typical N-Tier Architecture using Web Services, JMS, Connectors, CORBA, XML Databases, EJB, Servlets, JSP

6 Business Process Management (BPM) Business Process Management (BPM) enables the integration of diverse applications and human participants, as well as the coordinated exchange of information between trading partners outside of the enterprise. Focuses on Business Process Documentation to Executable! Further Reference - BPMI.org Figure: Typical Business Process Model (Source: WebLogic Workshop Integrator 8.0)

7 What is Thin-Client/Server Computing? The thin-client/server computing model involves connecting thin-client software or a thin-client hardware device with the server side using a highly efficient network protocol such as Citrix's ICA. The thin-client/server architecture enables 100 percent server-based processing, management, deployment, and support for mission-critical, productivity, Web-based, or other custom applications across any type of connection to any type of client hardware, regardless of platform. The client hardware can include Windows-based terminals, PCs, NetPCs, network computers, Apple Macintosh computers, or UNIX devices. Using the thin-client/server computing model, you won't need to purchase or upgrade hardware just to run the latest software--instead, you'll be able to let it comfortably evolve, leveraging your existing hardware, operating systems, software, networks, and standards. Thin-client/server computing extends the life of your computing infrastructure considerably. How Does Thin-Client/Server Computing Work? To see how thin-client/server computing really works, you need to start with the server part of the model. To put it simply, in thin-client/server computing, all your applications and data are deployed, managed, and supported at the server. In addition, 100 percent of the application executes at the server. The application logic is separated from the user interface at the server and transported to the client. (See Figure ) This separation means that only screen updates, mouse clicks, and keystrokes travel the network to the server. FIGURE The application executes on the server, and screen updates are sent to the client device. The thin-client software accesses and takes advantage of the server system software. MultiWin, the extension to Windows NT Server, allows multiple concurrent thin-client users to log on and run applications in separate, protected Windows sessions on the server. The ICA thin-client software that works with MultiWin enables a wide variety of client devices to access the same applications--without special emulation software, changes in system configuration, or application rewrites. Figure 1-2 depicts a server running with four different computing devices that use thin-client/server software. FIGURE The Citrix WinFrame product line with the Citrix MultiWin technology enables a wide variety of devices to access your applications. With the server splitting the execution and display logic, only keystrokes, mouse clicks, and screen updates travel the network. Thus, applications consume just a fraction of the normal network bandwidth usually required. Because

8 applications require fewer resources, they can be extended from one location across any type of connection to any type of client with exceptional performance. About Citrix MultiWin Citrix created MultiWin as an authorized multiuser extension to Microsoft Windows NT Server for its WinFrame server. The MultiWin technology is currently available from Citrix Systems in WinFrame Enterprise version 1.7, built on the Windows NT Server 3.51 platform. In mid-1997, Citrix licensed the MultiWin technology to Microsoft as part of a cooperative development agreement for creating native multiuser capabilities in Windows NT Server version 4 and future versions. If you compare bandwidth requirements across shared Ethernet, wireless Ethernet, ISDN (Integrated Services Digital Network), and modem speeds, you'll find a thin-client/server protocol such as Citrix ICA extremely efficient. (See Figure 1-3.) FIGURE 1-3 Using just a fraction of network bandwidth, ICA enables robust 32-bit applications to generate consistent perfor-mance through any connection. Using a protocol such as ICA with a local area network (LAN) or a wide area network (WAN) connection, the user experience with many software applications is the same for applications running on a WinFrame server as it is for applications running on a local computer with a full complement of application and operating system software. In a thinclient/ server session, users can cut and paste between sessions, save to local storage devices, and print to local or network printers. In summary, the thin-client/server architecture includes three components sitting on top of the Microsoft Windows NT Server: MultiWin, a multiuser layer on the server that simulates local application processing ICA display services on the multiuser layer that divide the application execution from the display logic Thin-client software, such as the ICA client, on the client device that sends mouse movements and keystrokes to the server while accepting display images Separation of the application execution from the display logic reduces the amount of data that needs to be communicated across the network, allowing efficient use of available bandwidth--and in the case of ICA, very efficient use of low-bandwidth situations.

9 Thin-Client Versus Fat-Client Computing McKenna s Four Laws Definitions Fat-client computing refers to a multi-tier client server paradigm where (in the simplest model) the client part of the application (i.e., those programs used by the end-user) execute on the desktop PC and the server part of the application (i.e., those programs used to drive the relational database) reside on a single server together with the application code. Thin-client computing refers to multi-tier client server paradigm where the client (end-user) programs display in a browser (such as Internet Explorer or Netscape) but the execution of that user code takes place on a central web server, not at the desktop PC. McKenna s Four Laws 1. For identical applications, the move from a Fat-client model to a Thin-client model does not reduce the need for computing resources; instead it moves the need from the desktop PC(s) to the Web server. 2. For identical applications, the move from a Fat-client model to a Thin-client model does not reduce the need for bandwidth; instead, it moves the need from the LAN/WAN infrastructure to the Intranet infrastructure. 3. For identical applications, the processing power required to service x number of users will be identical for Fat and Thin client models. 4. For identical applications, the move from a Fat-client model to a Thin-client model will not reduce the costs of the application and it may in fact increase the cost of the application. 1. No Reduction in the Need for Computng Resources A Fat-client Application utilizes existing computing resources such as desktop PCs and LAN (network) servers. In a typical Fat-client Application the majority of the processing workload is handled by the desktop PCs. For example, in a 500 user Fat-client Application roughly ninety-percent of all daily processing (execution of coded instructions) will take place on the desktop PCs as users asynchronously run

10 the application at 500 locations. The remaining ten-percent is handled by the application/database server. Rolling out a Fat-client Application usually involves utilizing existing capacity on already installed desktop PCs. This model allows for a relatively small application/database server (there may be two servers, one for the application and one for the database). It also allows for a significant number of new users to be added to the application before a server upgrade is required. When an application is moved from a Fat to a Thin model; a Thin-client Application, the need for processing power doesn t go away. The same amount of processing capability must be provided. Because we are no longer utilizing the power of the installed desktop PCs it is necessary to install a server(s) large enough to replicate the amount of processing that would have been required in a Fat-client model. The new server must be powerful enough to do the processing previously done by a collection of desktop PCs. In summary, Fat-client computing requires a relatively low power server because the bulk of the processing is done on the desktop PCs. By contrast, Thin-client computing requires a high power server because it has to do all of the work previously done by desktop PCs. 2. No Reduction in the Need for Bandwidth It is a popular misconception that the move to Thin-client Computing (TCC) reduces the need for expensive communications infrastructure. Anyone who doubts the need of TCC for expensive infrastructure should try browsing the web during peak times or talk to any Internet service provider about the cost of the infrastructure required to support a host site. Effective TCC requires a significant investment in infrastructure in the form of servers, routers and high-speed connections to the Internet/Intranet not to mention the high cost of the backbone in the case of a private Intranet. 3. The Processing Power Involved Is Identical For identical applications, if it takes x units of processing power to service a single user on a Fat-client Application it will take the same amount of computing power to service that same user on a Thin-client Application.

11 In the case of a Fat-client Application the bulk of the processing is done by the desktop PCs. In the case of the Thin-client Application the bulk of the processing is done by the web server. 4. The Move from a Fat-Client Application to a Thin-Client Application Will Usualy Increase the Cost of the Application When we move a Fat-client Application from 500 workstations we don t strip out RAM and half a CPU and send it back to the vendor for a refund. So, there are no immediate savings in computer hardware. However, the Thin-client model requires a significant new investment to implement and this cost is on top of all existing costs. If the Fat-client Application involved loading the application on each and every workstation (a bad practice) we may reduce our workstation maintenance costs because the move to a Thinclient Application will reduce the amount of software that has to be maintained on each workstation. However, if the Fat-client Application did not require the loading of its code on each and every workstation but instead loaded its code on distributed application servers (the preferred model for Fat-client Applications) then we will realize very little savings with our move to a Thin-client Application. In reality, the moving an application from a fat-client model to a Thin-client model saves very little on workstation maintenance because the major cost is in maintaining the network, Microsoft Windows, Microsoft Office and systems such as Outlook. We still therefore need the same number of human resources to effectively manage our pool of desktop PCs. Why Does The Cost Of A Thin-Client Application Often Greatly Exceed The Cost Of An Equivalent Fat-Client Application? Once we accept McKenna s four rules we begin to realize that the problem is in: Replicating the power of a desktop PC for each on-line user; and The incremental cost of each new user. When we add users to a Fat-client Application we use exiting PCs to absorb 90% of the load and reduce the load on the application and database servers. When we add users to a Thin-client

12 Application we are required to provide new, additional capacity or suffer a degradation in service to all users. In a Fat-client Application processing power is decentralized, the environment is not single-point sensitive. In a Thin-client Application processing power is centralized and we are single point sensitive. A Thin-client Application is therefore much more likely to exhibit a sudden and exponential drop in performance than is a Fat-client Application. The realities of queuing theory cannot be ignored. As the resource nears 80% capacity more and more computing resources must be devoted to load balancing and 'swapping' and less to the actual execution of user code. With a heavily centralized system model response times tend to increase in an exponential fashion once peak loading (say 80%) is reached. In a Fat-client Application we can make do with a relatively small and unsophisticated server. In a Thin-client Application we must have a relatively large and complex server. This complex Thin-client environment often comprises multiple clustered processors to provide the power required to service a large number of on-line users. This clustered server environment is extremely expensive to install and maintain and requires significantly more environmental and human resources than the lesser powered and less complex server used to support a Fat-client Application. Diagram 1 Users Thin Processor Fat Processor Totals

13 In the above table we see a clear explanation of why large scale Thin-client implementations rarely save money. For every additional 100 users in a Thin-client Application we have to add 100 units of processing power to the central web server. This is because we are not utilizing the power of the desktop PC to absorb some of the need for additional processing capability. For every 100 additional users in a Fat-client Application we need only add 10 units of processing power to our server because we are utilizing the existing power of the desktop PC to absorb 90% of the requirement. In the table above, we have added 1,000 units of processing to support 1,000 users in our Thin-client processing model but were only required to add 100 units of processing (one tenth the cost) to support 1,000 users in a Fat-client processing model. So, Why Do Organizations Move To Thin-Client Computing? They move because they think they will: 1. Reduce the need for bandwidth and relieve the load on the WAN; 2. Reduce the maintenance costs of desktop PCs; 3. Have more control over the application; 4. Provide better (i.e., shorter) response times; 5. Make use of the latest hardware and software technologies; 6. Make the application easier to roll-out and update; and 7. Save money. Let s see what I think 1. Reduce the Need for Bandwidth and Relieve the Load on the WAN The need for bandwidth on the WAN is reduced (though we shouldn t rely on it because it is a universal rule in computing that usage will increase to the available capacity) BUT a new requirement for equivalent or greater bandwidth is generated for the Intranet infrastructure. Conclusion no savings. 2. Reduce the Maintenance Costs of Desktop PCs The maintenance cost for existing desktop PC s may be reduced if the previous application (because of poor design) required all executables to be loaded on the desktop PC. There will be

14 little saving if the previous applications utilized existing LAN servers to store application code. Because the main headaches of network managers are still present (i.e., Microsoft Windows, Office, Outlook and networking software) an organization is unlikely to reduce the number of staff assigned to desktop PC maintenance. Conclusion no savings. 3. Have More Control over the Application The manager of a Thin-client processing facility may indeed have more control over the application BUT he/she now has a much larger and significantly more complex server complex to worry about and maintain. Conclusion win some, lose some. 4. Provide Better (I.E., Shorter) Response Times Remember that Thin-client computing requires significant resources; the need for computing power and bandwidth doesn t magically disappear just because we changed our processing paradigm from fat to thin. Because it is single point sensitive and because the incremental cost of a new user to a centralized Thin-client system is ten times the incremental cost of a new user to a Fat-client system, it is more prone to sudden and exponential increase in response times. Conclusion we have just moved the problem, we have not solved it. 5. Make Use of the Latest Hardware and Software Technologies Of course the programmers get to play with the very latest and most expensive hardware and software toys and their resumes look all the better for it. Conclusion objective achieved. 6. Make the Application Easier To Roll-Out and Update The application is easier to roll-out and update when web server based. Conclusion objective achieved. 7. Save Money Highly unlikely, especially when trying to replace an existing Fat-client Application. Realistically, any organization going the Thin-client route will actually incur significant new costs. Conclusion saving money is a pipe dream.

15 The Real Question Why Is Knowledgeone Corp Developing New-Technology Thin-Client Solutions? Knowledgeone Corp is in the business of anticipating future trends and needs and then building products to service those same trends and needs. No matter what conclusions this paper arrives at, Knowledgeone Corp believes that Thin-client computing will be the dominant application-processing paradigm of the next five years. Knowledgeone Corp, unlike a Microsoft, is not big enough to affect the path of the IT industry. It therefore behooves us to provide the products our client s request. Objective Type question and answer 1. What is the role of middle tier? (a) Middleware (b) Business logic service (c) Application logic service (d) Database service 2. The parameter which is packing processed by (a)end to end Server (b) Client RPC (c) MOM (d) Middleware 3. The Example of RPC involved in (a)peer to peer protocol (b) Web service (c) TCP/IP (d) ODBC

16 4. Which one can be managed and developed separately from the GUI and database? (a) Browser (b) Application logic (c) Fat server (d) Business logic 5. The Application which presents data to the user is called (a) Business logic service (b) Data link service (c) GUI (d) Data link layer 6. The MTS supported by (a)com+ (b) Java applets, DCOM (c) CORBA, EJB (d) ActiveX 7. Which one is Object Specific Middleware? A) SMTP, Lotus Notes Calls B) HTTP, S-HTTP, SSL C) SNMP, ORB D) CORBA, DCOM 8. How to overcome 3 Tier Architecture is better than 2 tier architecture A) Server to server infrastructure B) System administrations: fewer complexes C) Security: high D) All the above Two Mark question and answer 1. Define fat server model. The fat server model places more function on the server. The examples of fat server are groupware, transaction, and web servers. 2. Define fat client model.

17 The fat client model does the reverse of fat server. The examples of fat clients are database and file servers. 3. Define fat clients. Fat clients are the most traditional form of client/server. The bulk of application runs on the client side of equation. Fat clients are used for decision support and personal software. They provide flexibility and opportunities for creating front end tools that let end users create their own applications. 4. Define fat servers. Fat servers applications are easier to manage and deploy on the network because most of the code runs on the servers. Fat servers try to minimize network interchanges by creating abstract levels of service. 5. Define 2-Tier client/server architecture. In 2- tier client/server systems, the application logic is buried inside the user interface on the client or within the database on the server(or both).examples of 2-tier client/server systems are file servers and database servers with stored procedures. 6. Define 3-Tier client/server In 3-tier client/server systems, the application logic(or process) lives in the middle-tier; it is separated from the data and user interface.3-tier client/server systems are more scalable, robust and flexible. Examples of 3 tier client/server systems are TP monitors, distributed objects and the web. 7. Define intergalactic client/server. Intergalactic client/server is a new threshold of client/server applications and this is because of, 1. The exponential increase of low-cost bandwidth on Wide Area Networks for example, the Internet and CompuServe.

18 2. A new generation of network-enabled, multi-threaded desktop operating systems - for example, OS/2 Warp Connect and Windows What are the basic building blocks of client/server based on situations? The building blocks of client and server arrangements based on situations are: Client/server for tiny shops and nomadic tribes. Client/server for small shops and departments. Client/server for intergalactic enterprises. Client/server for a post-scarcity world. 9. What are the building blocks of client/server? The building blocks of client/server are: 1. The client building block. 2. The server building block. 3. The middleware building block. 10. Define DSM. DSM-Distributed System Management. The client runs a component of the distributed system management element. This could be anything from a simple agent on a managed PC to the entire front-end of the DSM application on a managing station. 11. Define client building block. The client building block runs the client side of the application. It runs on the operating system (OS) that provides graphical user Interface(GUI) or an OOUI (Object oriented User Interface)that access distributed services, wherever they may be. 12. Define server building block.

19 The server building block runs the server side of the application. The server application typically runs on top of some shrink-wrapped server software package. The server side depends on the operating system to interface with middleware building block that brings in the requests for the service. 13. Define middleware building block. The middleware running block runs both the client and server sides of an application. It is of three categories: transport stacks, network operating systems (NOSs), and the service-specific middleware. 14. Define Internet. The Internet is a worldwide, publicly accessible series of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP). It is a network of networks that consists of millions of smaller domestic, academic, business, and government networks, which together carry various information and services, such as electronic mail, online chat, file transfer, and the interlinked web pages and other resources of the World Wide Web (WWW). 15. Define Intranet. An Intranet is a private computer network that uses internet protocols, network connectivity to securely share part of an organization s information or operations with its employees. Sometimes the term refers only to the most visible service, the internal website. 16. Define extranet. An extranet is a private network that uses Internet protocols, network connectivity, and possibly the public telecommunication system to securely share part of an organization s information or operations with suppliers, vendors, partners, customers or other businesses. An extranet can be viewed as part of a company s Intranet that is extended to users outside the company (e.g.: normally over the Internet). 17. What are the functions of server program?

20 The role of server program is to serve multiple clients who have an interest in a shared resource owned by the server. The typical server does the following functions: 1. Waits for client initiated services. 2. Executes many request at the same time. 3. Takes care of VIP clients first. 4. Initiates and runs background task activity. 5. Keeps running. 18. Name the types of OS functions on a server. The types of OS functions are as follows: 1. Base services. 2. Extended services. 19. Define base services. The base services are a part of standard operating systems. It includes all the basic operations of an operating system. 20. Define extended services. The extended services are add-on modular software components that are layered on top of the base services. Functionally equivalent extended services are provided by more than one vendor. 21. What are the types of base services? Types of base services are as follows: 1. Task preemption. 2. Task priority 3. Semaphores.

21 4. Interprocess communication (IPC) 5. Local/remote Interprocess communication. 6. Threads. 7. Intertask Protection. 8. Multiuser High performance File system. 9. Efficient Memory management. 10. Dynamically linked run-time extensions. 22. Define semaphore. An operating system must provide simple synchronization mechanisms for keeping concurrent tasks from bumping into another when accessing shared resources. These mechanisms are known as semaphores. 23. What are the types of extended services? 1. Ubiquitous communication. 2. Network Operating system extensions. 3. Binary Large Objects (Blobs) 4. Global directories and Network yellow pages. 5. Authentication and authorization services. 6. System management. 7. Network Time. 8. Database and transaction services. 9. Internet services. 10. Object oriented services.

22 24. Define thread. Threads are units of concurrency provided within the single program itself. Threads are used to create very concurrent, event driven server programs. 25. What is meant by intertask protection? The operating system must protect tasks from interfering with each other s resources. A single task must not be able to bring down the entire system. Protection also extends to the file system and calls to the operating system. 26. Define BLOBs with examples. BLOBs-Binary Large Objects. Images, video, graphics, intelligent documents, database snapshots are BLOBS. BLOBs are used to test the capabilities of OS, databases and network. Network must transport BLOBs at astronomic speeds. 27. What are the system management services? System management services include: 1. Monitoring the performance of all elements. 2. Generating alerts when things break. 3. Distributing and managing software packages on client workstations 4. Checking for viruses and intruders. 5. Metering capabilities for pay as-you use server resources. 12 Mark Question 1. What is Middleware? Briefly explain each type of Middleware? 2. Discuss about Fat Server Model and Fat Client Model. 3. Discuss about 2-tier Client/Server System versus 3-tier Client/Server System.

23 4. What is Intergalactic Client/Server? What are the key technologies are needed for Client/Server System? 5. Expalin N-Tier Architecture and example 6. Explain thin client and characteristics Summaries One benefit of separating applications into distinct pieces is that it enables parallel development of the different tiers of the application. For example, one developer (or a team of developers) can work on the user tier, while another writes the business tier, while yet another works on the data tier. This separation also provides encapsulation for the different tiers and components, which can result in a more robust application. Each tier (or layer) is treated as a black box by the other tiers. Only clearly defined inputs and outputs from each tier can be seen by any of the other tiers. Using these tiers also allows for easier maintenance and support, since it's easier to change and upgrade a single specific component than to make changes in a monolithic application. If the business rules of an n-tier application are changed, it's only necessary to change the software in the business tier on one server. In a monolithic application, a change in the business rules would mean updating the software on every computer that was running the application.

24