What is Web Programming.docx

7/29/2019 What is Web Programming.docx

1/26


2/26

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 theuser/client on request. The process is:

1. the user requests a Web page from the server2. 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 around3. 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. Theresults may come back as a second Web page.

Server-side scripting tends to be used for allowing users to have individual accounts andproviding 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. Server-

side scripts are never seen by the user (so they can't copy your code). They run on the server andgenerate 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 ?HelloWorld!? 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 aclient 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 theclient side programming logic; a bank having 10,000 customers would mean that each


3/26

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 sideprograms. 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 ProgramsThe 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 remotemachines (called clients) can access the server programs.

ii. New functionalities to existing programs can be added at the server side which theclients? 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 tobother 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 sideapplications.

v. They are portable and possess the capability to generate dynamic and user-basedcontent (e.g. displaying transaction information of credit card or debit card

depending on user?s choice).vi.

3. Types of Server Side Programsi. Active Server Pages (ASP)

ii. Java Servletsiii. Java Server Pages (JSPs)iv. Enterprise Java Beans (EJBs)v. PHP


4/26

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. Theyprove 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.

J avascript - JavaScript is an object oriented-based interpreted scripting language that isembedded into HTML pages. With it you can control and program elements of your ownweb pages on the client-side without depending on server-side scripts etc. Using

JavaScript you can design your own windows, create forms, perform mathematicalcalculations, 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


5/26

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 firstserver-side scripting language to be developed. These CGI applications are executedremotely, 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 theoutput 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 Perlprogramming language has become the predominant choice. Many web servers such asApache enable CGI through dynamically loaded modules.

PHP - Hypertext Preprocessor (PHP) is an open source, cross-platform and free scriptinglanguage 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/J SPs - 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 servletor 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 thewebpage, hence saving resources for the provider. This is inherently the disadvantage

with server-side scripting, where the server must use valuable resources to parse eachpage 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 tothe browser, your code is hidden.

Browser Independent - Server-side code is browser independent. Because the HTMLcode 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 anddirectories on the server machine. Client-side languages such as JavaScript are unable toprovide this functionality for security reasons.

Application Updates - By operating on the server-side updating to new versions, fixingbugs, 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.


6/26

Working Together

Web sites can be designed to take advantage of the strengths and weaknesses of both client-sideand 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 ina 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 ofbirth 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 clientprocessing. 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 traditionalmainframe 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. aserver) 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 isconducted by means oftransactions 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 cooperativeprocessing.

Client/Server Systems have the following distinguishing characteristics:

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

a consumer of these services.


7/26

Shared Resources - Because multiple clients can simultaneously connect to the sameserver, 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 regardingduring the development phase (ie. using Java!) the ideal client/server software is

independent of hardware or operating system software platforms. For example, it souldbe possible for the client to use an alternative OS or client software, while it should alsobe 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 andservers. 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 amessage-based mechanism. This message passing is the delivery mechanism for servicerequests and responses.

Transparency of Location - As stated previously, clients and servers generally exist onseperate machines. However, once a request is made by the client, the server cantransparently 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 orvertically. Horizontalscaling means adding or removing client workstations with only a slight performanceimpact. Vertical scaling means either migrating to a more powerful machine or

distributing the processing load across multiple servers, as is frequently done by e-

Commerce Systems with large numbers (Amazon doesn't run off 1 machine!!)

Data/Source Protection - Because the server code and information are maintainedcentrally 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 whichyou can obtain .java files from .class files)

System Updates - The server is the "specialist" which determines what to do with clientrequests and what to return as a response. Hence, in order to perform large systemupdates, 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 toperform 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 veryimpressive 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 incomparison to these preceeding systems.


8/26

Reduced Costs - it has been found that large reductions in cost are possible usingClient/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 audienceand display formats are far more flexible thanks to the client/server architecture.

Support and Response to Business Environment Changes- As the requirements ofsystems change there is a considerably reduced development time associated with new ormodified solutions.

Faster Information - Distributed processing allows combined power of client PC andserver PC to increase processing speed by as much as a factor of 10 over mainframe-based solutions.

Open Architecture- The typical PC-based client/server architecture offers unlimitedpotential for multivendor solutions to information systems. Traditionally, mainframe

solutions required a company to "lock" themselves to a rigid structure and hence removethe element of competition.

Empowered Users - Customers have a much greater influence in the design of the client-side interfaces to server-side systems, increasing flexibility and useability.

Obviously, at some point around the mid-90s the majority of Businesses began to consider thebenefits 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 beingproactive, issuingrequests 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 asystem, for example until they close their application or browser connection times out). A clientmay 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


9/26

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 communicatingwith 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 hadalready been allocated (unless all usernames were passed to the client on each form, whichwould be an incredible inefficient way of doing things). However, the client is often capable of

handling all data preparation activities. Afat clientalso implements the business logic associated

with an application, while a thin clientsupports only the the presentation element and minimaldata 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 processesspawned 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 dedicatedto handling that request, allowing the master process to receive other requests immediately.

Figure 1.2. Master/Slave Server Processes


10/26

A server isfunction-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 anindivisible unit of work.

Consider for example, a standard e-Commerce process where a user (customer) wishes topurchase 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


11/26

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. Log the transaction2. Decrease the stock levels of this item by 13. Check if the stock levels have dropped below a certain level4.

If stock has dropped below this level, email notify an employee or automatically place anorder with the wholesaler

5. Log this stock shortage6. Update database information on this customer, so that the "system" knows that the

customer is interested in this genre of film

7. Add the item to the users cart8. Perform checks on the users cart to check for 2 for 1 or reduced price combinations9. Generate the web page to return to the client


12/26

Figure 1.4. More Detailed Example

Again, these are just samples of what might occur in such a system, but all these processes occuron 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 eitherallof these updates occuror

none. The server must also ensure that that updates required to satisfy one request are isolatedfrom, 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 seeif 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


13/26

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 thestock 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 wepass 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 lockingto prevent the corruption. Forexample, the entire 'Adding to Shopping Cart' procedure could be "locked" (ie. only one processcan 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 persecond 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 usto service our entire customerbase.

Figure 1.6. Using Locking to Protect from Concurrency
http://wiki.eeng.dcu.ie/ee557/307-EE/version/default/part/ImageData/data/shopping_process_concurrent.gifhttp://wiki.eeng.dcu.ie/ee557/307-EE/version/default/part/ImageData/data/shopping_process_concurrent.gifhttp://wiki.eeng.dcu.ie/ee557/307-EE/version/default/part/ImageData/data/shopping_process_concurrent.gifhttp://wiki.eeng.dcu.ie/ee557/307-EE/version/default/part/ImageData/data/shopping_process_concurrent.gif


14/26

The server is responsible for all processing associated with accessing, storing and organisingshared 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 forload-balancing, which is theprocess 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 manyyears, and in many different formats for many years. Some examples of which are:


15/26

File Servers

Typically a file server processes requests for certain file records stored on a remote server. Theclient, 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 awaitingconnections 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 theserver 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, andthe results are returned over the network. The name "SQL" is an abbreviation forStructuredQuery 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 datareside 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 ondatabases later!

Figure 1.8. Client/Server with Database Servers


16/26

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 servercomponent 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 anamed 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


17/26

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 ofthin, portable, universal clients which talk tosuperfatservers.Traditionally, this model began with the basic Web Serverwhich was simply a server, which

returned HTML pages when a request was received from a client. The clients and server


18/26


19/26

P-A-D Architecture

The most fundamental logical model of client/server information systems examines what it takesto 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 threesublayers, representing the application layer's interfaces with the presentation and data layers:

Presentation Logic - The part of the application responsible for interfacing to the userinterface

Business Logic - the core part of the application, responsible for executing theapplication and enforcing business rules

Data Logic - the part of the application responsible for interfacing to the databasemanagement 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 forclient/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.
http://wiki.eeng.dcu.ie/ee557/313-EE/version/default/part/ImageData/data/pad.gifhttp://wiki.eeng.dcu.ie/ee557/313-EE/version/default/part/ImageData/data/pad.gifhttp://wiki.eeng.dcu.ie/ee557/313-EE/version/default/part/ImageData/data/pad.gif


20/26

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-tiersystems 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-tiersystems 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 systemsare the new growth area for client/server computing because it meetsthe 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 isdelivered 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


21/26

As stated, in these systems, the business (or application) logic lives in the middle tier; it isseperated 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'sbehalf. 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 databaseschema (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
http://wiki.eeng.dcu.ie/ee557/316-EE/version/default/part/ImageData/data/2tier_vs_3tier.gifhttp://wiki.eeng.dcu.ie/ee557/316-EE/version/default/part/ImageData/data/2tier_vs_3tier.gif


22/26

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 beupdated 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 suitablefor 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 multipledatabase 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 theserver, 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 datarequests 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 usersthrough potentially unlimited numbers of client sessions

Application Reuse: Excellent, objects and services can be reused efficiently, platformchanges easy

Legacy Application Integration: Yes, gateways can be created to traditionallegacy/mainframe systems

Internet Support: Excellent. Standard thin clients typically exist on user systems, orrequire a short download time.

Multiple Database Support: Yes - 3-tier applications can use multiple database systemswithin the same business transaction
http://wiki.eeng.dcu.ie/ee557/316-EE/version/default/part/ImageData/data/2tier_vs_3tier.gifhttp://wiki.eeng.dcu.ie/ee557/316-EE/version/default/part/ImageData/data/2tier_vs_3tier.gifhttp://wiki.eeng.dcu.ie/ee557/316-EE/version/default/part/ImageData/data/2tier_vs_3tier.gif


23/26

Hardware Flexibility: Excellent - all three tiers can reside on different machines or thesecond/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 singleapplication - 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 thefollowing example, we can see the number of middle-tier services as seperate components:

Figure 1.16. Components in an N-tier Architecture


24/26

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 smallerprojects, 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 individualcomponents 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. Component-bases 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 tocomponents 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


25/26

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 performsall 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 dealwith 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 theclient.

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


26/26

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.

What is Web Programming.docx

Documents

Transcript of What is Web Programming.docx