What is Web Programming? What is Web Programming? Programming is the intricate art of telling a computer what to do.

"You mean when I say, 'Give me back my research paper you stupid machine', that I'm programming. Programming is giving written instructions in a logical manner that the computer can understand. Essentially, you give the computer small steps of instructions, and the computer goes down the list, executing each one in order. Programming allows you to make new software and have the computer do new things. Web site programming is the same except you write applications or web pages that are used by a web browser. Client-side and server-side scripting There are two main ways to customise Web pages and make them more interactive. The two are often used together because they do very different things. Scripts A script is a set of instructions. For Web pages they are instructions either to the Web browser (client-side scripting) or to the server (server-side scripting). These are explained more below. Scripts provide change to a Web page. Think of some Web pages you have visited. Any page which changes each time you visit it (or during a visit) probably uses scripting. All log on systems, some menus, almost all photograph slideshows and many other pages use scripts. Google uses scripts to fill in your search term for you, to place advertisements, to find the thing you are searching for and so on. Amazon uses scripting to list products and record what you have bought. Client-side The client is the system on which the Web browser is running. JavaScript is the main client-side scripting language for the Web. Client-side scripts are interpreted by the browser. The process with client-side scripting is: 1. the user requests a Web page from the server 2. the server finds the page and sends it to the user 3. the page is displayed on the browser with any scripts running during or after display So client-side scripting is used to make Web pages change after they arrive at the browser. It is useful for making pages a bit more interesting and user-friendly. It can also provide useful gadgets such as calculators, clocks etc. but on the whole is used for appearance and interaction. Client-side scripts rely on the user's computer. If that computer is slow they may run slowly. They may not run at all if the browser does not understand the scripting language. As they have

to run on the user's system the code which makes up the script is there in the HTML for the user to look at (and copy or change). Server-side The server is where the Web page and other content lives. The server sends pages to the user/client on request. The process is: 1. the user requests a Web page from the server 2. the script in the page is interpreted by the server creating or changing the page content to suit the user and the occasion and/or passing data around 3. the page in its final form is sent to the user and then cannot be changed using server-side scripting The use of HTML forms or clever links allow data to be sent to the server and processed. The results may come back as a second Web page. Server-side scripting tends to be used for allowing users to have individual accounts and providing data from databases. It allows a level of privacy, personalisation and provision of information that is very powerful. E-commerce, MMORPGs and social networking sites all rely heavily on server-side scripting. PHP and ASP.net are the two main technologies for server-side scripting. The script is interpreted by the server meaning that it will always work the same way. Serverside scripts are never seen by the user (so they can't copy your code). They run on the server and generate results which are sent to the user. Running all these scripts puts a lot of load onto a server but none on the user's system. Introduction to Server Side Programming All of us (or most of us) would have started programming in Java with the ever famous ?Hello World!? program. If you can recollect, we saved this file with a .java extension and later compiled the program using javac and then executed the class file with java. Apart from introducing you to the language basics, the point to be noted about this program is that ? ?It is a client side program?. This means that you write, compile and also execute the program on a client machine (e.g. Your PC). No doubt, this is the easiest and fastest way to write, compile and execute programs. But, it has little practical significance when it comes to real world programming. 1. Why Server Side Programming? Though it is technically feasible to implement almost any business logic using client side programs, logically or functionally it carries no ground when it comes to enterprise applications (e.g. banking, air ticketing, e-shopping etc.). To further explain, going by the client side programming logic; a bank having 10,000 customers would mean that each

customer should have a copy of the program(s) in his or her PC which translates to 10,000 programs! In addition, there are issues like security, resource pooling, concurrent access and manipulations to the database which simply cannot be handled by client side programs. The answer to most of the issues cited above is ? ?Server Side Programming?. Figure-1 illustrates Server side architecture in the simplest terms.

2. Advantages of Server Side Programs The list below highlights some of the important advantages of Server Side programs. i. All programs reside in one machine called the Server. Any number of remote machines (called clients) can access the server programs. ii. New functionalities to existing programs can be added at the server side which the clients? can advantage without having to change anything from their side. iii. Migrating to newer versions, architectures, design patterns, adding patches, switching to new databases can be done at the server side without having to bother about clients? hardware or software capabilities. iv. Issues relating to enterprise applications like resource management, concurrency, session management, security and performance are managed by service side applications. v. They are portable and possess the capability to generate dynamic and user-based content (e.g. displaying transaction information of credit card or debit card depending on user?s choice). vi. 3. Types of Server Side Programs i. Active Server Pages (ASP) ii. Java Servlets iii. Java Server Pages (JSPs) iv. Enterprise Java Beans (EJBs) v. PHP

Server-side Development Server-side development is the process of creating applications which run principally on a 'server', rather than on the end-users 'client' computer. Perhaps the easiest way of understanding this concept is to view the following diagram and considering some examples:

Client-side Examples

Executables - These .exe files (assuming Windows) run entirely on the user's own PC, whether they are Word Processors, windows applications, games or small programs. While they may have been previously downloaded from the internet they are run on the client side, using the PC as a host for processing, memory and storage. Applets - Java applets are small programs designed to run within another program. They prove very useful in the contex of the web for the reason that the moment that their bytecode is downloaded, they can be executed quickly within the web browser. Again, while they may have been downloaded, or indeed may have continuous communication with other clients/servers (ie. synchronous chat servers) they are still executed on the client side using the client computer's resources. Javascript - JavaScript is an object oriented-based interpreted scripting language that is embedded into HTML pages. With it you can control and program elements of your own web pages on the client-side without depending on server-side scripts etc. Using JavaScript you can design your own windows, create forms, perform mathematical calculations, and connect to existing applets and plug-ins. JavaScript is an interpreted language, which means that all that is needed is a JavaScript-enabled browser, which interprets and executes and JavaScript code as the HTML file is loaded. Again, this is a

client-side technology since the code is executed from within your browser, which is running on the local machine. Server-side Examples

CGI Scripts - The Common Gateway Interface, normally referred to as CGI, was the first server-side scripting language to be developed. These CGI applications are executed remotely, on the server and the resulting output is returned to the client through a browser. Virtually all processing (with the exception of the client browser, rendering the output into a viewable form) occurs on the server side and simply the output is returned to the client. Even though a CGI program can be written in almost any language, the Perl programming language has become the predominant choice. Many web servers such as Apache enable CGI through dynamically loaded modules. PHP - Hypertext Preprocessor (PHP) is an open source, cross-platform and free scripting language which has a fairly large developer base. It has been around for quite some time now and like CGI has a number of disadvantages when compared to the servlet/JSP architectures, which will be dealt with in the next Chapter. Servlets/JSPs - A considerable section of this course centers around the concept of Java servlets and JSPs which are written entirely in Java and provide arguably the best solution for server-side scripting today. They run entirely on the server-side on a servlet or JSP container, embedded in a web server or application server. These are dealt with in detail in the following chapter.

Client-side Advantages

Server Resources - Each client uses its own resources to execute the code on the webpage, hence saving resources for the provider. This is inherently the disadvantage with server-side scripting, where the server must use valuable resources to parse each page it sends out, possibly slowing down the web site.

Server-side Advantages

Code Protection - Because the server side code is executed before the HTML is sent to the browser, your code is hidden. Browser Independent - Server-side code is browser independent. Because the HTML code returned by your browser is simple HTML, you do not need to worry about the version of browser, javascript etc. that the client is using. Local Access - Server-side code is the only choice if you want to access files and directories on the server machine. Client-side languages such as JavaScript are unable to provide this functionality for security reasons. Application Updates - By operating on the server-side updating to new versions, fixing bugs, implementing code patches become a simple process of updating the server machine. Consider in opposition to this, a windows application running on the client - in order to update or make fixes, the client must download the latest version each time.

Working Together Web sites can be designed to take advantage of the strengths and weaknesses of both client-side and server-side. For example: Company A might wish to register users before they can access their site and provides an online form for this purpose. The obvious server-side element occurs after the information is submitted, where the customer details are processed into a file or saved in a database. However, client-side scripting such as JavaScript might be useful to validate the form before the details are submitted and this is performed from within the user's browser. This can be freqently seen throughout the web, where phone numbers, valid credit card numbers, dates of birth etc. are validated at the form stage before submission. Many developers in the past would have argued against the use of any significant level of client processing. For example, JavaScript can be disabled in browsers; does this cause your web-site to cease to function? Is the client using a mobile phone? does their phone browser even have JavaScript capability? JavaScript was also known for its cross-browser incompatibility problems; would your web application function correctly on every brand and version of client browser? Server-Side Introduction: Client/Server Systems Client/Server is not just a buzzword. It's two buzzwords. Two buzzwords which, if you seek any future in computing, you cannot afford to ignore - Dr. Robert Metcalfe, Founder of 3Com and Publisher/CEO of Infoworld As companies sought a competitive advantage in the down-turned economy of the early 1990s, information became increasingly recognised as a growing currency. More precisely, the harnessing of that information in the right format, to the right people at the right time. It was during this period, that client/server began to come to the forefront, replacing more traditional mainframe based computing (more on this later!). Client/server computing has become an irrestible movement which has reshaped the way computers have been used. The key to understanding client/server concepts is in realising that they describe a logical relationship between an entity that requests a service (ie. a client) from another entity (ie. a server) that provides a shared service as requested. The client and server parts may or may not exist on distinct physical machines. A client can have a relationship with different servers and a server can satisfy requests from multiple clients. The relationship between a client and a server is conducted by means of transactions consisting of well-defined requests and responses. One of the features of client/server relationships is that the client and the server share the workload between them. As a result, client/server relationships are often referred to as cooperative processing. Client/Server Systems have the following distinguishing characteristics:

Service - The Client/Server relationship exists between processes running (mostly) on seperate machines. The server process is a provider of services, while the client process is a consumer of these services.

Shared Resources - Because multiple clients can simultaneously connect to the same server, effectively the resources are shared. In using a server in this way, the effect is to more efficiently utilise the server resources. Hardware/OS Independence - Generally, assuming wise decisions are made regarding during the development phase (ie. using Java!) the ideal client/server software is independent of hardware or operating system software platforms. For example, it sould be possible for the client to use an alternative OS or client software, while it should also be possible to move the entire server end from Solaris to Windows to Linux transparently. Asymmetrical Protocols - There is a many-to-one relationship between clients and servers. Clients always initiate the dialog by requesting a service from the server. Servers are passively awaiting requests from the clients. Message Based - Clients and servers are loosely coupled systems that interact through a message-based mechanism. This message passing is the delivery mechanism for service requests and responses. Transparency of Location - As stated previously, clients and servers generally exist on seperate machines. However, once a request is made by the client, the server can transparently redirect service calls when needed, communicating with other tiers (such as a database), other servers and Information Systems. Scalability - Client/server systems can be scaled horizontally or vertically. Horizontal scaling means adding or removing client workstations with only a slight performance impact. Vertical scaling means either migrating to a more powerful machine or distributing the processing load across multiple servers, as is frequently done by eCommerce Systems with large numbers (Amazon doesn't run off 1 machine!!) Data/Source Protection - Because the server code and information are maintained centrally it means that there is one source, which needs to be guarded from a security point of view. Additionally, since most of the application code is kept on the server, it can not be downloaded and "de-compiled" using applications such as Jad (with which you can obtain .java files from .class files) System Updates - The server is the "specialist" which determines what to do with client requests and what to return as a response. Hence, in order to perform large system updates, or even quick patches these need only be applied on to the server (or array of servers if load-balancing used). Client Processing - Client/Server systems allow the server to in turn allow the Client to perform certain elements of processing. For example, considering a browser used as a client: the client performs the displaying of the server-generated HTML and JavaScript might be used for FORM validation.

As can be seen, this list of characteristics, encapsulates the advantages detailed in the list of the previous section (Client-side and Server-Side Advantages). Naturally, Client/Server Systems should harness the best of both worlds! While, this list of characteristics is certainly very impressive from a technical point of view, the implications on business aspects must also be addressed. Bearing in mind, that before the early 1990s, businesses had traditionally used mainframe-based systems, we can address the benefits of server/client systems for businesses in comparison to these preceeding systems.

Reduced Costs - it has been found that large reductions in cost are possible using Client/Server Frameworks over mainframe systems. This is primarily due to the significant reduction in staff required (not good news for us!) Information Flexibility - Information is more accessible, available to a wider audience and display formats are far more flexible thanks to the client/server architecture. Support and Response to Business Environment Changes - As the requirements of systems change there is a considerably reduced development time associated with new or modified solutions. Faster Information - Distributed processing allows combined power of client PC and server PC to increase processing speed by as much as a factor of 10 over mainframebased solutions. Open Architecture - The typical PC-based client/server architecture offers unlimited potential for multivendor solutions to information systems. Traditionally, mainframe solutions required a company to "lock" themselves to a rigid structure and hence remove the element of competition. Empowered Users - Customers have a much greater influence in the design of the clientside interfaces to server-side systems, increasing flexibility and useability.

Obviously, at some point around the mid-90s the majority of Businesses began to consider the benefits of Client/Server systems as outweighing the negatives (retraining, switch-over cost, reliability concerns etc.). The explosion of the Internet naturally accelerated this process greatly, where customers began to demand anytime-anywhere access to Information Systems. Client Attributes In any client/server relationship, the client process can be seen as being proactive, issuing requests to the server. It typically is dedicated to it's user's session and begins and ends with the session. (Note: A session means that encapsulated timespan spent by a user each time they use a system, for example until they close their application or browser connection times out). A client may interact with a minimum of one single server or with multiple servers to accomplish it's task. At the application level, the client is responsible for maintaining and processing the entire dialog with the user. This would typically involved the following:

Screen Handling Menu or Command Interpretation Data Entry and Validation Help Processing Error Recovery

In graphical applications, this also includes:

window handling mouse and keyboard entry dialog box control sound and video management in multimedia apps

One of the more important and common client tasks is that of data validation, as is frequently handled by JavaScript in web-based applications. In practice, it is not always possible for the client to handle all data-validation: some data checks need to be performed by communicating with the server. For example, consider a web-based system where users need to login, and upon registration they are asked for a unique username, which they wish to be known in the system. In this scenario, communication with the server would be required to see which usernames had already been allocated (unless all usernames were passed to the client on each form, which would be an incredible inefficient way of doing things). However, the client is often capable of handling all data preparation activities. A fat client also implements the business logic associated with an application, while a thin client supports only the the presentation element and minimal data validation. Typical examples of business logic are the rules required to cross-check data against other data and ensuring that business rules are followed by imposing a specific sequence on events (eg. a balance is verified to be nonzero before a withdrawal is processed). As the client manages all of the users visible interaction, the server-side is made effectively invisible to the user. The user gets the effective illusion that the entire application runs on their local machine, whereas in reality there's a lot more going on! Server Attributes In the client/server relationship, similarly the server process can be seen as being reactive, triggered by the arrival of requests from its clients. A server process typically runs constantly, regardless of whether clients are actively connecting to the process. For this reason, reliability of server hardware is obviously very important for mission-critical server applications - if the server hardware goes down, so do the server applications, taking down all of the clients with it! Server services may be provided either directly by the server process itself or by slave processes spawned for each client request (Check out the section on servlets and their life cycle for an example). In these systems, when a request arrives, the server spawns a slave process dedicated to handling that request, allowing the master process to receive other requests immediately. Figure 1.2. Master/Slave Server Processes

A server is function-specific, which means that it performs a set of predefined transactions. The server takes the request, works out what is being asked of it and performs the required logic to process the request. Usually the request is treated as a transaction , which can be viewed as an indivisible unit of work. Consider for example, a standard e-Commerce process where a user (customer) wishes to purchase an item and adds the item to their shopping cart. At the client end, the user selects to add 'The Godfather II' DVD to their shopping cart. At the server end: Figure 1.3. Example e-Commerce Process

The above example only provides a very basic structure of what might occur at the server end in reality much more would likely occur. For example, if the items is in stock the process might be: 1. 2. 3. 4. 5. 6. 7. 8. 9. Log the transaction Decrease the stock levels of this item by 1 Check if the stock levels have dropped below a certain level If stock has dropped below this level, email notify an employee or automatically place an order with the wholesaler Log this stock shortage Update database information on this customer, so that the "system" knows that the customer is interested in this genre of film Add the item to the users cart Perform checks on the users cart to check for 2 for 1 or reduced price combinations Generate the web page to return to the client

Figure 1.4. More Detailed Example

Again, these are just samples of what might occur in such a system, but all these processes occur on the server-side of the relationship. It should be taken into account, that due to the fact that a server can be simultaneously servicing numerous (in some cases vast numbers) of clients, the server must resolve any mutual exclusion issues to prevent corruption of results. Often in any single transaction multiple database updates are required and it is the servers' responsibility to ensure that either all of these updates occur or none. The server must also ensure that that updates required to satisfy one request are isolated from, and do not interfere with, updates required to satisfy a concurrent request. To give a basic idea of how a problem could occur with simultaneous accesses, consider the situation where Customer 1 (John in Dublin) attempts to buy "GodFather II" with 1 copy remaining in stock. The server (which has no built in concurrent protections) does a check to see if a copy exists, discovers that it does and proceeds to log the transaction (everything is going so well! Must give IT specialists a pay-rise for such a fantastic system!). Unfortunately, virtually

instantaneously, Customer 2 (Mary from Sydney) has a craving for the same copy of the DVD and adds it to her shopping cart (unlikely you might say - but with millions of customers not that unlikely!). While John's server process is at the logging stage, Mary's server process passes the stock check, which says that a copy still is in stock. Figure 1.5. Shopping Example with Concurrent Purchase

Click to enlarge

The diagram describes some of the possible issues which may arise: others might include (if we pass the end stage) delivery issues, theft investigation, customer billed but not supplied, customer service calls, major overstocking or an entire server crash! Obviously the effective monetary and customer service implications could be dire to a company running a poorly designed server structure. One solution to such a mutual exclusion issue is to perform locking to prevent the corruption. For example, the entire 'Adding to Shopping Cart' procedure could be "locked" (ie. only one process can add any item to any cart at any time). This would certainly prevent the situation above from occurring but could severely limit server resources. If it takes an average of 100 milliseconds to perform the entire operation on the server, only a maximum of 10 items could be added per second on the server worldwide! (let's assume just one server for now!) If we average 100 customer purchases per second - we're in serious trouble! Another more effective solution would be to only "lock" the part of the process where the mutual exclusion problem could occur. In the diagram below, we move the logging to after the stock decreasing and we "lock" just the Stock Check and the stock decrease. This part of the process might only take 5ms, allowing us to handle 200 shopping cart additions per second, allowing us to service our entire customerbase. Figure 1.6. Using Locking to Protect from Concurrency

The server is responsible for all processing associated with accessing, storing and organising shared data, updating previously stored data and any management of other shared resources. Shared resources can be data, CPU power, disk or tape storage, print capability, communications, display and memory management. Servers are responsible for load-balancing, which is the process of dividing requests between numerous servers to allow the use of the resources of multiple server machines. Client/Server Examples The concept behind splitting an application across a client and a server has been around for many years, and in many different formats for many years. Some examples of which are:

File Servers Typically a file server processes requests for certain file records stored on a remote server. The client, typically a PC sends these requests across the network to the server, which contains a shared repository of documents, images and other large data objects. One example of a file server is an FTP server which runs on default port 21 on a server, which sits awaiting connections from clients. Once the client connects, it can send a series of messages to the server which facilitate the finding and retrieval/placement of files on the server. In the case of FTP a specific standard protcol is used, the client uses some sort of FTP client application and the server has some sort of FTP server application in place. Figure 1.7. Client/Server with File Servers

Database Servers With a database server, the client passes SQL requests as messages to the database server, and the results are returned over the network. The name "SQL" is an abbreviation for Structured Query Language, pronounced "sequel" or "S.Q.L". SQL is a computer language which is used to interact with a database, used for obtaining, updating or creating new information. At this point in the module, this is all that you need to know regarding SQL, but there is an entire section to look forward to later in the course! Horray! The code that processes the SQL request and the data reside on the same machine, and the server uses its own processing power to find the requested data and to return it to the client. The server only returns back the data that the client requests, rather than letting the client find its required data, as is the case with File Servers. More on databases later! Figure 1.8. Client/Server with Database Servers

Transaction Servers With transaction servers, the client invokes remote procedures that reside on a server with an SQL database engine. These remote procedures consist of groups of SQL statements, which define a transaction. Typically, only one request and response occur for the entire transaction, which is different to database servers, where each seperate SQL statement is executed in a seperate request, with a response returned for each. The SQL statements either all succeed or fail as a combined unit. The client component typically includes a Graphical User Interface (GUI) and the server component consists of SQL transactions against a database. These applications are called Online Transaction Processing (OLTP). OLTP applications tend to be mission-critical, requiring a fast response time, with tight controls over security, access and integrity of the data. The major databases all offer this mechanism for executing functions that are stored in their databases. This mechanism is sometimes referred to as "TP-Lite" or "stored procedures". A stored procedure is a named collection of SQL statements and procedural logic that is compiled, verified and stored in the server database, with access controlled through the server's security mechanisms. Figure 1.9. Client/Server with Transaction Servers

Stored procedures and transactions are both dealt with in more detail later in the module. Leaving the topic for now, we can suggest that, while stored procedures do have their application in certain situations, procedural extensions should be left primarily to middle-tier applications servers. Essentially, if you don't understand this at this early stage, it means that we should use our self-written application code to perform groups of SQL calls rather than writing SQL "programs" to perform procedures! Web Application Servers This model consists of thin, portable, universal clients which talk to superfat servers. Traditionally, this model began with the basic Web Server which was simply a server, which returned HTML pages when a request was received from a client. The clients and server

communicate using an RPC-like (Remote Procedure Call) protocol called HTTP. Certainly the fastest growing client/server model, the Web Application Server has grown significantly since the Web Server stage. While traditional Web Servers have vast amounts of extra functionality compared to their predecessors, such as CGI, Perl, HTML Security, SSL, Servlets, Java Server Pages, PHP, Lightweight Directory Access Protocol, for full scale web applications most developers are turning towards utilising one of many Web Application Servers. Both the Web and distributed objects have been converging together over the past few years to provide a very interactive form of client/server computing, which is commonly known as the Object Web. Functionally, Web Application servers are very similar to object servers. For a list of available Web Application Servers and some comparison of features, follow this link. Some of the more popular examples include BEA WebLogic, IBM WebSphere, Orion, JBoss, Iona Orbix, Oracle Application Server and Apache Tomcat. Figure 1.10. Client/Server with Web Application Servers

Client/Server System Tiers Client/Server physical architectures are often categorized in terms of tiers. The term tiers refers to the relationship between the logical sublayers of the application process of the P-A-D logical architecture and the physical architecture in which those sublayer processes are delivered. Before we delve into 2-tier, 3-tier and n-tier systems we should have an understanding of P-A-D.

P-A-D Architecture The most fundamental logical model of client/server information systems examines what it takes to deliver information effectively to end-users. This model is know as the P-A-D architecture, or Presentation-Application-Data, and relies on the interaction of three fundamental processes:

Presentation - also known as the user interface Application - also known as application logic or processing Data - also know as data management or data manipulation

Some logical models of client/server information system divide the application layer into three sublayers, representing the application layer's interfaces with the presentation and data layers:

Presentation Logic - The part of the application responsible for interfacing to the user interface Business Logic - the core part of the application, responsible for executing the application and enforcing business rules Data Logic - the part of the application responsible for interfacing to the database management system

Figure 1.11. Presentation-Application-Data (PAD) Logical Model

Click to enlarge

Considering the P-A-D architecture, we now consider three alternative possibilities for client/server systems: 1. The system is performed totally on the client (Client-Side System) 2. The system is cooperatively split between the client and server (Client/Server System) 3. The function is performed totally on the server (Server-Side System) 2-Tier vs 3-Tier Architectures 2-tier architectures deliver the presentation logic on the client and the database logic on the server. The business logic is buried either inside the user interface on the client or on the database server.

If the business/application logic is on the client, we use the term fat client. If the business/application logic is on the server, we use the term fat server.

Examples of 2-tier client/server systems are file servers and database servers with stored procedures. Figure 1.12. Structure of a 2-Tier Client/Server

One of the biggest driving factors of 2-tier client/server systems is simplicity. Typically, 2-tier systems are used primarily in departmental applications, such as decision support or small scale groupware. However, as systems become more advanced, requirements increase and are expected to globalise, the 2-tier systems begin to break down. Used in a departmental LAN 2-tier systems are viable, since the IS Department typically owns the local desktops. However, to deploy these fat clients on a global net is a logistical nightmare. If the Internet were to rely on fat clients for all systems, users would need to download the latest version of site-specific software at every visit to individual sites. To overcome to globalisation problem, something drastic needed to occurr and finally the development community came up with a "Gillette-like" concept - three blades are better than two! 3-tier client/server systems are the new growth area for client/server computing because it meets the requirements of large-scale Internet and intranet client/server applications. These systems are more scalable, robust, flexible and can integrate data from multiple sources. Presentation logic is delivered on the client, the business logic on one or more dedicated servers, and the database logic on one or more powerful database servers. Applications are easier to manage and deploy on the network, since the business logic is handled by the dedicated servers. Figure 1.13. Structure of a 3-Tier Client/Server

As stated, in these systems, the business (or application) logic lives in the middle tier; it is seperated from the data and user interface. 3-tier applications minimize network interchanges by creating abstract levels of service. Instead of interacting with the database directly, the client calls business logic on the server. The business logic then access the database on the client's behalf. The client need only make a call for a service on the application tier, which in turn will generate the multiple SQL calls required to complete the database transaction. One of the obvious benefits of this (over a 2-tier database server) is that it provides better data security, since authorization is performed between the second and third tiers. Addtionally, the database schema (ie. the way the data is structured in tables etc.) is not exposed to the client user. Considering the P-A-D architecture, the following diagram of 2-tier Vs 3-tier client/server systems, shows how the 3-tier presentation logic, business logic and database logic layers have been clearly seperated into individual tiers. Figure 1.14. 2-Tier vs 3-Tier Architecture

Click to enlarge

Consider now the features of the 2-tier and 3-tier architectures: 2-Tier Architecture Features

System Administration: Far more complex, since individual client machines need to be updated and maintained Security: Low Security, often database schemas and logins are visible Encapsulation of Data: Poor, since similar to security, data tables are exposed Performance: Poor, since multiple SQL requests are often made (unless transactions used) and large amounts of data is often downloaded for analysis by the client Scale: Poor, very limited management of client communications, typically only suitable for LAN based applications Application Reuse: Poor, typically deployed for one specific use Legacy Application Integration: None Internet Support: Poor. Fat clients are particularly unsuitable for low bandwidth downloads across the Internet Multiple Database Support: Limited to the use of database links - not full multiple database support Hardware Flexibility: Limted to a client and a server. Server-to-Server Infrastructure: No Ease of Development: High Communication Choices: Limited to synchronous, connection-oriented RPC-like calls

3-Tier Architecture Features

System Administration: Less complex, since the application exists primarily on the server, all administration can be performed on the server machines Security: High, clients are simply making calls to methods, functions or object-types, making data retrieval transparent Encapsulation of Data: Good, since mostly methods or services are called, direct data requests should not be made Performance: Good, only services and requests are sent between the client and server only the exact pre-processed data is received by the client. Scale: Good, can easily spread load over numerous seperate servers, manages users through potentially unlimited numbers of client sessions Application Reuse: Excellent, objects and services can be reused efficiently, platform changes easy Legacy Application Integration: Yes, gateways can be created to traditional legacy/mainframe systems Internet Support: Excellent. Standard thin clients typically exist on user systems, or require a short download time. Multiple Database Support: Yes - 3-tier applications can use multiple database systems within the same business transaction

Hardware Flexibility: Excellent - all three tiers can reside on different machines or the second/third tiers can reside on the same server. Multiple database servers may be used. The second tier can be load-balanced across multiple hardware servers. Server-to-Server Infrastructure: Yes, using server-side middleware Ease of Development: Improving - standard GUI based application development packages have become available, increasing the ease of development Communication Choices: RPC-type calls also supported but also, connectionless messaging, queued delivery, broadcast, etc

Figure 1.15. 2-Tier vs 3-Tier - Development vs Complexity

N-Tier Architecture 3-tiered client/server architectures are sometimes referred to as n-tiered client/server architectures. Typically, the middle tier in most 3-tier applications is not implemented as a single application - rather a collection of components are used. Each component automates a relatively small business function. When the client makes a single business transaction, the server response is actually the combination of the results of several seperate middle-tier components. In the following example, we can see the number of middle-tier services as seperate components: Figure 1.16. Components in an N-tier Architecture

Writing middle-tier applications in a component-based manner allows large applications to be written in a number of smaller stages. Large mission-critical projects can be written in smaller projects, with the possibility of making early releases (with less functionality), until the "final" application is written. Indeed, no version need to be considered "final" since it is possible to add new components at a later date. The components can be reused or combined in different ways to provide extra functionality. Each programmer or team of programmers can work on individual components and simply provide each other with the required interfaces to each others componenents. Individual components can be reused for new applications. This can be achieved in two seperate ways: firstly if the components are written in an object-oriented language (such as Java) the source code can be easily reused; secondly, compiled binary components can also be used as "binary black boxes", recombining them in different ways for new applications. Componentbases systems can grow beyond a single application to become the basis for new suites of applications. It is possible to assemble applications very quickly by adding a few new middle-tier components and reusing a number of existing components. Clients are able to access data and functions easily and safely, since they send requests to components to execute functions on their behalf. The server components encapsulate the details of the application logic and thus raise the level of abstraction. Similarly, clients do not need to know the details of the database schemas or database security. The entire process is kept hidden from the client, apart from the request sent and the response received. The component

architecture provides consistent, secure access to data and eliminates random, uncontrolled updates coming from many applications at once. For example, consider the following diagram: Figure 1.17. Example Component Architecture

In this example, we show four components, three of which are likely to be called directly by the client. The UserManager component sits behind the other three and performs all database and data access on their behalf. In this way, we can keep one centralised component which performs all database access (creation and retrieval). As we discussed earlier in the P-A-D architecture, we saw that the Application process can be split into three subsections: Presentation Logic Interface, Business Logic and Database Logic Interface. In this example, the first three components deal with the presentation interface and some business logic - they would not make any SQL data interactions with the database. The UserManager component would contain the remaining business logic and would deal with the Database Interface, handling all of the SQL calls to the DBMS. It would not be involved in any way with the presentation of the resulting data to the client. Additionally, using component-based architectures, it is possible to incorporate "off-the-shelf" components. Rather, than necessarily developing every component it is possible to purchase/avail of existing components which perform standard processes. For example, a company might decide that rather than writing their own database connection pool, they might

use a pre-written, pre-tested component and integrate it with their own existing components. Similarly, they might decide to use a "Logging" component, which, while simple to write, might be a case of reinventing the wheel.