AFM-Client Server Arch

makeshiftklipInternet and Web Development

Oct 31, 2013 (3 years and 9 months ago)

115 views

Mainframe architecture:


With mainframe software architectures all intelligence is within the central host
computer. Users interact with the host through a terminal that captures keystrokes and
sends that information to the host. Mainframe software archite
ctures are not tied to a
hardware platform. User interaction can be done using PCs and UNIX workstations.
A limitation of mainframe software architectures is that they do not easily support
graphical user interfaces or access to multiple databases from geo
graphically
dispersed sites. In the last few years, mainframes have found a new use as a server in
distributed client/server architectures.


File sharing architecture:


The original PC networks were based on file sharing architectures, where the server
dow
nloads files from the shared location to the desktop environment. The requested
user job is then run (including logic and d
ata) in the desktop environment

File sharing architectures work if shared usage is low, update contention is low, and
the volume of
d
ata to be transferred is low.

In the 1990s, PC LAN (local area network) computing changed because the capacity
of the file sharing was strained as the number of online user grew (it can only satisfy
about 12 users simultaneously) and graphical user interfa
ces (GUIs) became popular
(making mainframe and terminal displays appear out of date). PCs are now being used
in client/server architectures.


Client
-
Server Architecture
:


The term client/server was first used in the 1980s in reference to personal computer
s
(PCs) on a network. The actual client/server model started gaining acceptance in the
late 1980s. The client/server software architecture is a versatile, message
-
based and
modular infrastructure that is intended to improve usability, flexibility,
interope
rability, and scalability as compared to centralized, mainframe, time sharing
computing.


A client is defined as a requester of services and a server is defined as the provider of
services. A single machine can be both a client and a server depending on t
he
software configuration.


Although it began as a fairly precise description of one style of distributed processing,
the

term client/server has now acquired many meanings, some more technical, others
more

related to business reengineering. For a few years

in the early 1990s, the DBMS
vendors

hijacked the term, equating it with
a two
-
tier database server architecture. It
is a tribute to

the success of their marketing efforts that many people still think of
client/server

computing in that way.


Client/serve
r computing is simply a powerful extension of the fundamental idea of
modular programming. It extends the concept of modular programming to the
distributed environment by recognizing that those modules do not have to be executed
on a single platform. This
extension leads to the following fundamental characteristics
of a

client/server architecture:



Systems are created by assembling independent components, each of which

contributes unique, specialized functions to the system as a whole. In the
simplest arrang
ement, client components interact with users and with servers
that manage various computing resources. In more sophisticated arrangements,
some servers can also be clients of other servers.



Clients and servers can use hardware and software uniquely suited
to the
required functions. In particular, front
-
end and back
-
end systems normally
require computing resources that differ in type and power. Database
management systems can employ hardware specifically designed for queries,
while graphics functions can emp
loy memory and computing resources that
can generate and display intricate diagrams.



As a result of the limitations of file sharing architectures, the client/server architecture
emerged. This approach introduced a database server to replace the file serv
er. Using
a relational database management system (DBMS), user queries could be answered
directly. The client/server architecture reduced network traffic by providing a query
response rather than total file transfer. It improves multi
-
user updating through

a GUI
front end to a shared database. In client/server architectures, Remote Procedure Calls
(RPCs) or standard query language (SQL) s
tatements are typically used to
communicate between the client and server



Examples of client/server Architecture:


Two
tier architecture:


With two tier c
lient/server architectures,
the user system interface is usually located in
the user's desktop environment and the database management services are usually in a
server that is a more powerful machine that services many cl
ients. Processing
management is split between the user system interface environment and the database
management server environment. The database management server provides stored
procedures and triggers. There are a number of software vendors that provide
tools to
simplify development of applications for the two t
ier client/server architecture
.


The two tier client/server architecture is a good solution for distributed computing
when work groups are defined as a dozen to 100 people interacting on a LAN
simu
ltaneously. It does have a number of limitations. When the number of users
exceeds 100, performance begins to deteriorate. This limitation is a result of the
server maintaining a connection via "keep
-
alive" messages with each client, even
when no work is b
eing done. A second limitation of the two tier architecture is that
implementation of processing management services using vendor proprietary database
procedures restricts flexibility and choice of DBMS for applications. Finally, current
implementations of

the two tier architecture provide limited flexibility in moving
(repartitioning) program functionality from one server to another without manually
regenerating procedural code.


Two tier architectures consist of three components distributed in two layers:

client
(requester of services) and server (provider of services). The three components are

1.

User System Interface (such as session, text input, dialog, and display
management services)

2.

Processing Management (such as process development, process enactment,

process monitoring, and process resource services)

3.

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 proces
sing management
between client and server, creating two layers.


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 en
vironment. 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 sh
ould 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 impr
oves 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 poss
ible 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.



Three tier architectures
:


T
he three tier architecture

(also referred to as the multi
-
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 va
riety of ways of
implementing this middle tier, such as transaction processing monitors, message
servers, or application servers. The middle tier can perform queuing, application
execution, and database staging. For example, if the middle tier provides que
uing, 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 tie
r 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. Flexibility in partitioning can be a simple as "dragging and drop
ping"
application code modules onto different computers in some three tier architectures. 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
. Recently, mainframes have found a new use as servers in three
tier
architectures.


A three tier distributed client/server architecture

includes a user system interface top
tier where user services (such as session, text input, dialog, and dis
play management)
reside.


The third tier provides database management functionality and is dedicated to data
and file services that can be optimized without using any proprietary database
management system languages. The data management component ensures t
hat the
data is consistent throughout the distributed environment through the use of features
such as data locking, consistency, and replication. It should be noted that connectivity
between tiers can be dynamically changed depending upon the user's reques
t for data
and services.


The middle tier provides process management services (such as process development,
process enactment, process monitoring, and process resourcing) that are shared by
multiple applications.


The middle tier server (also referred to
as the application server) improves
performance, flexibility, maintainability, reusability, and scalability by centralizing
process logic. Centralized process logic makes administration and change
management easier by localizing system functionality so tha
t changes must only be
written once and placed on the middle tier server to be available throughout the
systems. With other architectural designs, a change to a function (service) would need
to be written into every application.


In addition, the middle pr
ocess management tier controls transactions and
asynchronous queuing to ensure reliable completion of transactions. The middle tier
manages distributed database integrity by the two phase commit process. It provides
access to resources based on names inste
ad of locations, and thereby improves
scalability and flexibility as system components are added or moved.


Sometimes, the middle tier is divided in two or more un
it with different functions, in
these cases the architecture is often referred as multi layer
. This is the case, for
example, of some Internet applications. These applications typically have light clients
written in HTML and application servers written in C++ or Java, the gap between
these two layers is too big to link them together. Instead, ther
e is an intermediate layer
(web server) implemented in a scripting language. This layer receives requests from
the Internet clients and generates html using the services provided by the business
layer. This additional layer provides further isolation betwe
en the application layout
and the application logic.


It should be noted that recently, mainframes have been combined as servers in
distributed architectures to provide massive storage and improve security.









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 prioritizati
on 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 t
he 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




connectivity to a variety of data sources including flat files, n
on
-
rel
ational
DBMS, and the mainframe



the ability to attach priorities to transactions



robust security



Using a three tier client/server architecture with TP m
onitor technology results in an
environment that is considerably more scalable than a tw
o tier

architecture with direct
client to server connection. For systems with

thousands of users, TP monitor
technology (not embedded in the DBMS) has b
een reported as one of the most
effective solutions. A limitation to TP monitor techno
logy is that the impleme
ntation
code is usually written in a lower level langua
ge (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
prioritiz
ed 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 technolo
gy 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. Messaging systems are
good solutions for wi
reless infrastructures.


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 installa
tion 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 considerations.



Links and refs:



High
-
Performance Client/Server

Chris Loosley

Fra
nk Douglas

Publisher: Robert Ipsen

Editor: Robert M. Elliott

Managing Editor: Brian Snapp

Text Design & Composition: Impressions Book and Journal Services, Inc.

Copyright ©1998 by Chris Loosley. All rights reserved.

Published by John Wiley & Sons, Inc.



http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

(3
-
Feb
-
08)



http://www.sei.cmu.edu/str/desc
riptions/twotier_body.html

(3
-
Feb
-
08)



http://www.sei.cmu.edu/str/descriptions/threetier.html#34492

(3
-
Feb
-
08)



Flash
Com Server Architecture
:


FlashCom is a server
-
side applica
tion that is installed on a host machine much like a
web server; however, FlashCom works very differently than a web server. Instead of
accepting many brief connections from browsers requesting a web page or other
resource, FlashCom accepts persistent conn
ections from Flash movies running in a
Flash Player. Each Flash movie can share data with other Flash movies via the server
using Macromedia's proprietary Real
-
Time Messaging Protocol (RTMP). Unlike the
HTTP request/response model used by browsers to commu
nicate with web servers,
the Flash Player's RTMP connection to the FlashCom Server is persistent, so no
special steps are needed to maintain session information. Once the server accepts a
client connection, the connection can be used to exchange audio, vid
eo, and
ActionScript data until either the client or server disconnects.


The Flash Player may be running within the Standalone Player or within a web
browser. The Flash Player (and any movie playing within it) is considered the client.
FlashCom cannot ini
tiate a connection to a movie; the connection must be initiated
from the Flash Player running on the client. The client/server architecture for
FlashCom applications is shown in
Figure 1
-
1
.


Web browsers load Flash movie files (.swf files), load
the Flash Player, and pass the
.swf file to the Player to execute. The Flash movie provides the user interface and can
attempt to connect via the Player to any FlashCom Server. Once connected, the Flash
movie can communicate with the server. Furthermore, i
t can communicate

via the
server

with movies playing on other Flash clients. A Flash movie can stream audio
and video to the FlashCom Server so that other Flash clients with access to the same
server can play recorded streams stored on the server and live
streams from other
clients.


A live stream is usually one that is published to the server by one client so that other
clients can receive it. As the client's data arrives at the server, the server duplicates it
and forwards it to each client, where it is s
een and heard. In contrast, recorded streams
are stored on the server and can be played from any point within the stream, paused,
and restarted. It is also possible to stop a recorded stream, seek to any point within it,
and begin playing again.


If multip
le FlashCom Servers are connected to one another, clients connected to one
server may be able to communicate with clients connected to another server. The
ability to communicate between servers and the clients connected to them makes
possible large
-
scale a
pplications, such as live event streaming to many thousands of
viewers.

Figure 1
-
1. Client/server architecture for FlashCom applications






FlashCom can host many different applications. More than one instance of an
application can be run at the same ti
me. Each instance is given its own unique name.
When a client connects to the server, it always connects to an instance of an
application by name. For example, many separate instances of an application named
chatRoom

may be available. Each instance has its

own unique name and may provide
unique resources for the client.
Figure 1
-
2

illustrates three clients connected to the
same instance of the
chatR
oom application.


Figure 1
-
2. Three Flash movies connected to a FlashCom application
instance via th
e Flash Player










Links and refs:




Flash Communication Server

By Giacomo

Guilizzoni, Brian

Lesser, Joey

Lott, Robert

Reinhardt,
Justin

Watkins

Publisher
: O'Reilly

Pub Date
:
: February 2005

ISBN
: : 0
-
596
-
00504
-
0

Pages
: 854



Action
Script

Message For
mat (
AMF
):


AMF is a binary message format modeled after
Simple Object Access Protocol

(SOAP), a protocol designed to exchange structured data in a distributed environment.
SOAP uses XML tags to describe and package data and was designed to be abstract
and

versatile, which unfortunately resulted in the schema being complex and verbose.
AMF was designed to be an efficient, compact format to pass ActionScript datatypes
over the network. AMF uses binary flags to describe and package data. An AMF
packet will al
ways be smaller than an equivalent SOAP packet, which translates to
faster response times and faster processing times when creating and processing AMF
packets instead of SOAP.


Action Message Format (AMF) is a compact binary format that is used to serializ
e
ActionScript object graphs. Once serialized an AMF encoded object graph may be
used to persist and retrieve the public state of an application across sessions or allow
two endpoints to communicate through the exchange of strongly typed data. The first
ve
rsion of AMF, referred to as AMF 0, supports sending complex objects by
reference which helps to avoid sending redundant instances in an object graph. It also
allows endpoints to restore object relationships and support circular references while
avoiding p
roblems such as infinite recursion during serialization. A new version of
AMF, referred to as AMF 3 to coincide with the release of ActionScript 3.0, improves
on AMF 0 by sending object traits and strings by reference in addition to object
instances. AMF 3

also supports some new data types introduced in ActionScript 3.0.



Links and refs:




Flash Communication Server

By Giacomo

Guilizzoni, Brian

Lesser, Joey

Lott, Robert

Reinhardt,
Justin

Watkins

Publisher
: O'Reilly

Pub Date
:
: February 2005

ISBN
: : 0
-
596
-
0
0504
-
0

Pages
: 854