Chapter2

Client Server Architecture

Syllabus
Two tiered client/server architecture
Three tiered client/server architecture
Stored Procedure architecture

Two tiered client/server architecture Purpose
Two tier software architectures were developed in the year 1980.
The two tier architecture is intended to improve usability by supporting a forms-based, user-friendly interface.
The two tier architecture improves scalability by accommodating up to 100 users, and improves flexibility by allowing data to be shared, usually within a homogeneous environment.

Technical Detail
Two tier architectures consist of three components distributed in two layers: client and server. The three components are
User System Interface (such as text input, dialog, and display management services)
Processing Management (such as process development, process enactment, process monitoring, and process resource services)
Database Management (such as data and file services)
The two tier design allocates the user system interface exclusively to the client.
It places database management on the server and splits the processing management between client and server, creating two layers.

Two Tier Architecture

In general, the user system interface client invokes services from the database management server.
In many two tier designs, most of the application portion of processing is in the client environment.
The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures).
Clients commonly communicate with the server through SQL statements or a call-level interface.

It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.
As compared to the file server software architecture (that also supports distributed systems), the two tier architecture improves flexibility and scalability by allocating the two tiers over the computer network.
The two tier improves usability (compared to the file sever software architecture) because it makes it easier to provide a customized user system interface.
It is possible for a server to function as a client to a different server- in a hierarchical client/server architecture. This is known as a chained two tier architecture design.

Two Tier Architecture Usage Considerations
Two tier software architectures are used extensively in non-critical information processing where management and operations of the system are not complex.
Two tier software architectures require minimal operator involvement.
The two tier architecture works well in relatively homogeneous environments with processing rules (business rules) that do not change very often and when workgroup size is expected to be fewer than 100 users, such as in small businesses.

Two Tier Architecture Maturity
Two tier client/server architectures have been built and fielded since the middle to late 1980s.
The design is well known and used throughout industry.
Two tier architecture development was enhanced by fourth generation languages.

Two Tier Architecture Costs and Limitations
Scalability. The two tier design will scale-up to service 100 users on a network.
It appears that beyond this number of users, the performance capacity is exceeded.
This is because the client and server exchange "keep alive" messages continuously, even when no work is being done, thereby saturating the network.

Interoperability.
The two tier architecture limits interoperability by using stored procedures to implement complex processing logic.
This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten.

System administration and configuration .
Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client.
The typical lack of uniformity in the client configurations and lack of control over configuration changes increase administrative workload.

Three Tier Architecture
The three tier architecture emerged to overcome the limitations of the two tier architecture.
In the three tier architecture, a middle tier was added between the user system interface client environment and the database management server environment.
There are a variety of ways of implementing this middle tier, such as transaction processing monitors, message servers, or application servers.

Three Tier Architecture
The middle tier can perform queuing, application execution. For example, if the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client.
In addition the middle layer adds scheduling and prioritization for work in progress.
The three tier client/server architecture has been shown to improve performance for groups with a large number of users (in the thousands) and improves flexibility when compared to the two tier approach.

Limitation
A limitation with three tier architectures is that the development environment is reportedly more difficult to use than the visually-oriented development of two tier applications

Three tier architecture with transaction processing monitor technology.
The most basic type of three tier architecture has a middle layer consisting of Transaction Processing (TP) monitor technology
The TP monitor technology is a type of message queuing, transaction scheduling, and prioritization service where the client connects to the TP monitor (middle tier) instead of the database server.
The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client.

When the capability is provided by third party middleware vendors it is referred to as "TP Heavy" because it can service thousands of users. When it is embedded in the DBMS (and could be considered a two tier architecture), it is referred to as "TP Lite" because experience has shown performance degradation when over 100 clients are connected .

TP monitor technology also provides the ability to update multiple different DBMSs in a single transaction.
Provides connectivity to a variety of data sources including flat files, non-relational DBMS, and the mainframe
Provides the ability to attach priorities to transactions
robust security

Using a three tier client/server architecture with TP monitor technology results in an environment that is considerably more scalable than a two tier architecture with direct client to server connection.
For systems with thousands of users, TP monitor technology (not embedded in the DBMS) has been reported as one of the most effective solutions.
A limitation to TP monitor technology is that the implementation code is usually written in a lower level language (such as COBOL), and not yet widely available in the popular visual toolsets.

Three tier with message server
Messaging is another way to implement three tier architectures.
Messages are prioritized and processed asynchronously.
Messages consist of headers that contain priority information, and the address and identification number.
The message server connects to the relational DBMS and other data sources.
The difference between TP monitor technology and message server is that the message server architecture focuses on intelligent messages, whereas the TP Monitor environment has the intelligence in the monitor, and treats transactions as dumb data packets.

Three tier with an application server
The three tier application server architecture allocates the main body of an application to run on a shared host rather than in the user system interface client environment.
The application server does not drive the GUIs; rather it shares business logic, computations, and a data retrieval engine.
Advantages are that with less software on the client there is less security to worry about, applications are more scalable, and support and installation costs are less on a single server than maintaining each on a desktop client.
The application server design should be used when security, scalability, and cost are major consideration.

Three tier with an ORB architecture
Currently industry is working on developing standards to improve interoperability
Developing client/server systems using technologies that support distributed objects holds great promise, as these technologies support interoperability across languages and platforms, as well as enhancing maintainability and adaptability of the system.
There are currently two prominent distributed object technologies:
Common Object Request Broker Architecture (CORBA)
COM/DCOM (Component Object Model (COM), DCOM, and Related Capabilities) .
Industry is working on standards to improve interoperability between CORBA and COM/DCOM. The Object Management Group (OMG) has developed a mapping between CORBA and COM/DCOM that is supported by several products.

Three tier architecture…
Three-tier applications are much more difficult to build than two-tier apps.
The biggest obstacle is that the software tools’ integrated development environments are not aware of the three-tier model.
As a result, much more hand-coding is required to write a three-tier application.
Three-tier apps are also harder to design, because they are somewhat abstract compared with their more direct two-tier counterparts.
Software tool vendors are starting to release new versions for three-tier or n-tier development support, but it's not mature development technology just yet.

Stored Procedure Concept
Stored procedures are user-written structured query language (SQL) programs that are stored at the data base server and can be invoked by client applications.
A stored procedure can contain most statements that an application program usually contains.
Stored procedures can execute SQL statements at the server as well as application logic for a specific function.

A stored procedure can be written in many different languages, such as COBOL, OOCOBOL, C, C++, FORTRAN etc.
The language in which stored procedures are written depends on the platform where the data base server is installed.

Local client applications, remote Distributed Relational Database Architecture (DRDA), or remote data services can invoke the stored procedure by issuing the SQL CALL statement
The client program can pass parameters to the stored procedure and receive parameters from the stored procedure.
The client program and the stored procedure do not have to be written in the same programming language. For example, a C client program can invoke a COBOL stored procedure .

why use Stored Procedure?
In previous releases of DRDA, the client system performed all application logic. The server was responsible only for SQL processing on behalf of the client.
In such an environment, all database accesses must go across the network, resulting in poor performance in some cases.

This is a relatively simple model, which makes the application program easy to design and implement.
Because all application code resides at the client, a single application programmer can take responsibility for the entire application.
However, there are some disadvantages to using this approach.

Because the application logic runs only on the client workstations, additional network input/output (I/O) operations are required for most SQL requests.
These additional operations can result in poor performance.
This approach also requires the client program to have detailed knowledge of the server's database design.
Thus, every change in the database design at the server requires a corresponding change in all client programs accessing the database.
Also, because the programs run at the client workstations, it is often complicated to manage and maintain the copies there.

Stored procedures enable you to encapsulate many of your application's SQL statements into a program that is stored at the data base server.
The client can invoke the stored procedure by using only one SQL statement, thus reducing the network traffic to a single send and receive operation for a series of SQL statements.
It is also easier to manage and maintain programs that run at the server than it is to manage and maintain many copies at the client machines.

Stored procedures enable you to split the application logic between the client and the server. You can use this technique to prevent the client application from manipulating the contents of sensitive server data

Processing with Stored Procedures

The stored procedure can issue static or dynamic SQL statements.
Data definition language (DDL), most data manipulation language (DML), and data control language (DCL) statements can be coded in a stored procedure.

Chapter2

by suks_87

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 83

Statistics

Chapter2 Presentation Transcript

http://www.ustudy.in	80
http://ustudy.in	3

Chapter2

by suks_87

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 83

Statistics

Chapter2 Presentation Transcript

Let LinkedIn power your SlideShare experience

Let LinkedIn power your SlideShare experience

Customize SlideShare content based on your interests

Keep up to date when your LinkedIn contacts post on SlideShare