Académique Documents
Professionnel Documents
Culture Documents
What is Middleware?
• Middleware does not include the software that provides the actual service
that’s in the server’s domain.
• It also does not include the user interface or the application’s logic that’s in the
client’s domain.
• It starts with the API set on the client side that is used to invoke a service, and
it covers the transmission of the request over the network and the resulting
response.
• Middleware divided into two broad classes:
(a) General Middleware (b) Service-Specific Middleware
a) General Middleware
b) Service-Specific Middleware
1
o Database-specific middleware such as ODBC, DRDA, EDA/SQL,
SAG/CLI and Oracle Glue.
o OLTP-specific middleware such as Tuxedo’s ATMI and /WS,
Encina’s Transactional RPC, and X/Open’s TxRPC and XATMI
o Groupware-specific middleware such as MAPI, VIM, VIC, SMTP
and Lotus Notes Calls
o Object-specific middleware such as OMG’s CORBA and Microsoft’s
Network OLE (or DCOM)
o Internet-specific middleware such as HTTP, S-HTTP and SSL
o System Management-specific middleware such as SNMP, CMIP and
ORBs.
Client/Server Concepts
Each instance of the client software can send data requests to one or more
connected servers. In turn, the servers can accept these requests, process them, and
return the requested information to the client. Although this concept can be applied
for a variety of reasons to many different kinds of applications, the architecture
remains fundamentally the same.
These days, clients are most often web browsers, although that has not always
been the case. Servers typically include web servers, database servers and mail
servers. Online gaming is usually client-server too. In the specific case of MMORPG,
2
the servers are typically operated by the company selling the game; for other games
one of the players will act as the host by setting his game in server mode.
The interaction between client and server is often described using sequence
diagrams. Sequence diagrams are standardized in the Unified Modeling Language.
Contents
• 1 Characteristics
o 1.1 Characteristics of a client
o 1.2 Characteristics of a server
• 2 Multi-tiered architecture
• 3 Comparison to Peer-to-Peer Architecture
• 4 Comparison to Client-Queue-Client Architecture
• 5 Advantages
• 6 Disadvantages
• 7 Examples
• 8 Notes
• 9 See also
Characteristics
Characteristics of a client
Characteristics of a server
3
• Upon receipt of requests, processes them and then serves replies
• Usually accepts connections from a large number of clients
• Typically does not interact directly with end-users
Multi-tiered architecture
Some designs are more sophisticated and consist of three different kinds of nodes:
clients, application servers which process data for the clients, and database servers
which store data for the application servers. This configuration is called a three-tier
architecture, and is the most commonly used type of client-server architecture.
Designs that contain more than two tiers are referred to as multi-tiered or n-tiered.
The advantages of n-tiered architectures is that they are far more scalable, since they
balance and distribute the processing load among multiple, often redundant,
specialized server nodes. This in turn improves overall system performance and
reliability, since more of the processing load can be accommodated simultaneously.[1]
1. More load on the network itself, due to a greater amount of network traffic.
2. More difficult to program and test than in two-tier architectures because more
devices have to communicate in order to complete a client’s request.
4
which also acts as passive queue (one software instance passes its query to another
instance to queue, e.g. database, and then this other instance pulls it from database,
makes a response, passes it to database etc.). This architecture allows greatly
simplified software implementation. Peer-to-Peer architecture was originally based on
Client-Queue-Client concept.
Advantages
Disadvantages
• Traffic congestion on the network has been an issue since the inception of the
client-server paradigm. As the number of simultaneous client requests to a
given server increases, the server can become severely overloaded. Contrast
that to a P2P network, where its bandwidth actually increases as more nodes
5
are added, since the P2P network’s overall bandwidth can be roughly
computed as the sum of the bandwidths of every node in that network.
• The client-server paradigm lacks the robustness of a good P2P network. Under
client-server, should a critical server fail, clients’ requests cannot be fulfilled.
In P2P networks, resources are usually distributed among many nodes. Even if
one or more nodes depart and abandon a downloading file, for example, the
remaining nodes should still have the data needed to complete the download.
Examples
Imagine you are visiting eCommerce web site. In this case, your computer and web
browser would be considered the client, while the computers, databases, and
applications that make up the online store would be considered the server. When your
web browser requests specific information from the online store, the server finds all of
the data in the database needed to satisfy the browser’s request, assembles that data
into a web page, and transmits that page back to your web browser for you to view.
Specific types of clients include web browsers, email clients, and online chat clients.
Specific types of servers include web servers, ftp servers, application servers,
database servers, mail servers, file servers, print servers, and terminal servers. Most
web services are also types of servers.
Notes
6
• Client/Server applications can also be differentiated by how the distributed
application is split between the client and the server.
• The fat server model places more function on the server.
• The fat client does the reverse.
• Groupware, transaction and the web servers are examples of fat servers;
database and file servers are examples of fat clients.
• Distributed objects can be either.
Fat Client
Fat Server:
• Fat Server applications are easier to manage and deploy on the network
because most of the code runs on the servers.
7
• Fat servers try to minimize network interchanges by creating more abstract
levels of service.
• Transaction and object servers, for example, encapsulate the database.
• The client in the fat server model provides the GUI and interacts with the
server through remote procedure calls (or method invocations)
• These are used for mission-critical applications, represent the new growth area
fro PC-based client/server computing.
What is Client/Server?
• The name implies that clients and servers are separated logical entities that
work together over a network to accomplish a task.
• All client/server systems have the following distinguishing characteristics.
1. Service
2. Shared Resources
3. Asymmetrical Protocols
4. Transparency of location
5. Mix – and – Match
6. Message based exchanges
7. Encapsulation of Services
8. Scalability
9. Integrity
1. Service:
8
• Client/Server is primarily a relationship between processes running on
separate machines
• The Server process is a provider of services. The client is a consumer of
services.
• The client and server is separated clearly based on the idea of service.
2. Shared Resources:
• A server can service many clients at the same time and regulate their access to
shared resources.
• Have different mechanisms in allocating files and hardware like printer,
scanner etc.
3. Asymmetrical Protocols:
4. Transparency of Location:
• The server is a process that can reside on the same machine as the client or on
a different machine across a network.
• Client/Server software usually masks the location of the server from the
clients by redirecting the service calls when needed.
• A program can be a client, a server or both.
5. Mix-and-Match:
• Clients and servers are loosely coupled systems that interact through a
message-passing mechanism.
9
• The message is the delivery mechanism for the service requests and replies.
7. Encapsulation of Services:
8. Scalability:
9. Integrity:
• The server code and data is centrally maintained, which results in cheaper
maintenance and the guarding of shared data integrity.
• The clients remain personal and independent
Server Types
1. File Server
2. Database Server
3. Transaction Server
4. Groupware Server
5. Object Server
6. Web Server
10
. File Servers
• The client passes requests for file records over a network to the file server.
• This is a very primitive form of data service.
• File Servers are useful for sharing files across a network.
• These are acting as a repository of documents, images, engineering drawings
and other large data objects.
Database Servers
11
Transaction Servers
• The client invokes remote procedures that reside on the server with an SQL
database engine.
• These remote procedures on the server execute a group of SQL statements.
• The network exchange consists of a single request/reply message.
• The SQL statements either all succeed or fail as a unit. These grouped SQL
statements are called Transactions.
• The server component usually consists of SQL transactions against a database
• These are called Online Transaction Processing or OLTP.
• OLTP applications also require tight controls over the security and integrity of
the database.
• Two forms of OLTP: based on the TP Monitors provided by the OLTP
Vendors
o TP Lite
o TP Heavy
•
4. Groupware Servers
12
• In most cases, applications are created using a scripting language and form-
based interfaces provided by the vendor.
• The communication middleware between the client and the server is vendor-
specific.
Object Servers
Web Servers
13
• This model of client/server consists of thin, portable, “universal” clients that
talk to Superfast Servers.
• The clients and servers communicate using an RPC-like protocol called
HTTP.
• This protocol defines a simple set of commands, parameters are passed as
strings.
• The collection of HTML documents are stored in the Web Server.
14
• Applications communicate over networks by simply putting messages in
queues and getting messages from queues.
• MOM hides all the nasty communications from applications and typically
provides a very simple high-level of API to its services.
• A MOM consortium was formed in mid-1993 with the goal of creating
standards for messaging middleware.
• Members are product providers including
o IBM – MQSeries
o Covia – Communications Integrator
o Peerlogic – PIPES
o Horizon Strategies – Message Express
o System Strategies – ezBridge
• MOM’s messaging and queuing allows clients and servers to communicate
across a network without being linked by a private, dedicated, logical
connection.
• The clients and servers can run at different times.
• Everybody communicates by putting messages on queues and by taking
messages from queues.
15
• Most messaging products allow the sender to specify the name of the reply
queue.
• The products also include some type of format field that tells the recipient how
to interpret the message data.
• MOM enabled programs do not talk to each other directly, so either program
can be busy, unavailable, or simply not running at the same time.
• The target program can even be started several hours later.
16
Remote Procedure Call
RPCs are not procedure calls at all, they are truly process invocations. The invoked
program runs across the wire in a different resource domain”
• A client process calls a function on a remote server and suspends itself until it
gets back the results.
• Parameters are passed like in any ordinary procedure.
• The RPC, like an ordinary procedure is synchronous.
• The process (or threads) that issue the call waits until it gets the results.
• Under the covers, the RPC run-time software collects values for the
parameters, forms a message, and sends it to the remote server.
• The server receives the request, unpacks the parameters, calls the procedure,
and sends the reply back to the client.
• While RPCs make life easier for the programmer, they pose a challenge for the
NOS designers who supply the development tools and run-time environments.
• The Common issues are:
17
• Server starts the process, when a remote invocation is received with necessary
parameters and returns the response to the client.
• What happens when multiple clients invoke the same function? Now an
environment is needed to start and stop servers, prioritize requests, perform
security checks, and provide some form of load-balancing.
• Each incoming requests invokes a thread in the server side.
• A server loop is created to manage the pool of threads waiting for work rather
than create a thread for each incoming request.
• TP Monitors are really need on the server side, which provides more functions
than a NOS.
How are parameters defined and passed between the client and the server?
18
• Both the sides of the RPC can fail separately, it is important for the software to
be able to handle all the possible failure combinations.
• If the server does not respond, the client side will normally block, timeout, and
retry the call.
• The server side must guarantee only once semantics to make sure that a
duplicate request is not re-executed.
• If the client unexpectedly dies after issuing a request, the server must be able
to undo the effects of that transition.
19
How is data representation across systems handled?
• The problem here is that different CPUs represent data structures differently
(Ex: bigendian Vs little endian)
• To maintain machine independence, the RPC must provide some level of data
format translation across systems.
• Example: Sun RPC requires that clients convert their data to a neutral
canonical format using the External Data Representation (XDR) APIs.
• In contrast, DCE’s Network Data Representation (NDR) service is
multicanonical, meaning that it supports multiple data format representations.
• The client chooses one of these formats, tags the data with chosen format, and
then leaves it up to the server to transform the data into a format it
understands.
• In other words, the server makes it right. It lets the client to do translation,
which makes the life easy for the server.
• With Sun, all clients look the same to the server: The Client makes it right.
20
• Most early client/server applications were implemented using low-level,
conversational, peer-to-peer protocols – such as sockets, TLI, CPIC/APPC,
NetBIOS and Named Pipes.
• These low-level protocols are hard to code and maintain.
• Instead now, the programmers are using RPCs, MOMs, and ORBs, which
provide high level abstraction.
• The term, “peer-to-peer” indicates that the two sides of a communication link
use the same protocol interface to conduct a networked conversation.
• The protocol is symmetrical, and it is sometimes called “program-to-
program”.
• The peer-to-peer interface not fully mask the underlying network from the
programmer.
• Programmer have to handle the transmission timeouts, race conditions, and
other network errors.
• The peer-to-peer protocols started as stack-specific APIs.
a) Sockets
• Sockets were introduced in 1981 as the UNIX BSD 4.2 generic interface that
would provide Unix-to-Unix communications over network.
• In 1985, SUN OS introduced NFS and RPC over sockets.
• Sockets are supported on virtually every OS.
• The windows socket API, known as WinSock, is a multivendor specification
that standardizes the use of TCP/IP under windows.
• In BSD Unix System, sockets are part of the Kernel and provide both a
standalone and networked IPC service.
21
• A port is an entry point to an application that resides on the host.
• It is represented by a 16-bit integer.
• Ports are commonly used to define the entry points for services provided by
the server applications.
b) TLI
c) NetBIOS:
d) Named Pipes:
22
• These are suitable for implementing server programs that require many-to-one
pipelines.
• Important benefit of named pipes are part of the base interprocess
communications service.
• Named pipes interface is identical, whether the processes are running on an
individual machine or distributed across the network.
• Named pipes run on NetBIOS, IPX/SPX, and TCP/IP stacks.
• Named pipes are built-in networking features in Windows NT, Windows for
Workgroups, Windows 95 and Warp Server.
• Unix support for Named Pipes is provided by LAN Manager/X.
e) CPI-C/APPC:
23
Inside the Building Blocks
24
• The five contending server platforms for creating the next generation of
client/server applications are SQL database severs, TP Monitors, groupware
servers, Object servers and the Web server.
• The server side depends on the OS to interface with the middleware building
block.
• The server also runs DSM component
• It may be a simple agent or a shared object database etc.
DSM
Server-to-server Middleware
25
• But most modern software follows the client/server paradigm.
1. Client
2. Middleware
3. Server
These building blocks can be rearranged to use them in the following situations:
2. Client/Server for small shops and departments - This is the classic Ethernet
client/single-server, building block implementation. It is used in small shops,
departments, and branch offices. This is the predominant form of client/server today.
26
3. Client/Server for intergalactic enterprises – This is the multiserver building-
block implementation of client/server. The servers present a single system image to
the client. They can be spread out throughout the enterprise, but they can be made to
look like they are part of the local desktop. This implementation meets the initial
needs of intergalactic client/server computing.
• It is easy to run the client and server portion of an application on the same
machine.
• Vendors can easily package single-user versions of a client/server application.
• The business critical client/server application runs on one machine and does
some occasional communications with outside servers to exchange data,
refresh a database and send or receive mail and faxes. Ex: Internet.
27
• This is the model used in small businesses.
• The single-server nature of the model tends to keep the middleware simple.
• The client only needs to look into a configuration file to find its server’s name.
• Security is implemented at the machine level and kept quite simple.
• The network is usually relatively easy to administer; it’s a part-time job for a
member of the group.
• There are no complex interactions between servers, so it is easy to identify
failures- they’re either on the client or on the local server.
28
o remote procedure calls and
o network time services.
• Middleware creates a common view of all the services on the network called a
single system image.
• Good software architecture for intergalactic enterprise client/server
implementations is all about creating system “ensembles” out of modular
building blocks.
• Intergalactic client/server is the driving force behind middleware standards as
distributed objects and the Internet.
29
Permalink Leave a Comment
Intergalactic Client/Server
This new threshold marks the beginning of a transition from Ethernet client/server to
intergalactic client/server that will result in the irrelevance of proximity.
30
The center of gravity is shifting from single-server, 2-tier, LAN-based departmental
client/server to a post-scarcity form of client/server where every machine on the
global “information highway” can be both a client and a server.
a) Rich transaction Processing – supports the nested transactions that span across
multiple servers, long-lived transactions that executes over long periods of time as
they travel from server to server, and queued transactions that can be used in secure
business-to-business dealings. Most nodes on the network participates in the secured
transaction; super-server nodes handle the massive transaction loads.
31
b) Roaming agents – the environment is populated with all types of agents. This
agent technology includes cross-platform scripting engines, workflow, and Java-like
mobile code environments that allow agents to live on any machine on the network.
2-Tier Vs 3-Tier
• Instead of Fat clients and fat servers these terms can be used.
• It is all about how you split the client/server applications into functional units.
• These functional units can be assigned to either the client or to one or more
servers.
• The most typical functional units are:
o User Interface
o Business Logic and
o the Shared Data
• In 2-tier, the application logic is either buried inside the User Interface on the
client or within the database on the server (or both)
32
• 2-tier system examples: File Servers and Database Servers with stored
procedure.
• In 3-tier, the application logic (or) process lives in the middle-tier, it is
separated from the data and the user interface.
• 3-tier systems are more scalable, robust and flexible. In addition, they can
integrate data from multiple sources.
• Examples: TP Monitors, Distributed Objects and the Web.
First:
tier 1 – Application in PC
Then:
Now:
tier 1 – Client
33