Client-server computing or networking is a distributed application architecture that partitions tasks or work loads between service providers (servers) and service requesters, called clients. Often clients and servers operate over a computer network on separate hardware. A server machine is a high-performance host that is running one or more server programs which share its resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await (listen to) incoming requests.
Description :
Client-server describes the relationship between two computer programs in which one program, the client program, makes a service request to another, the server program. Standard networked functions such as email exchange, web access and database access, are based on the client-server model. For example, a web browser is a client program at the user computer that may access information at any web server in the world. To check your bank account from your computer, a web browser client program in your computer forwards your request to a web server program at the bank. That program may in turn forward the request to its own database client program that sends a request to a database server at another bank computer to retrieve your account balance. The balance is returned to the bank database client, which in turn serves it back to the web browser client in your personal computer, which displays the information for you.
The client-server model has become one of the central ideas of network computing. Many business applications being written today use the client-server model. So do the Internet's main application protocols, such as HTTP, SMTP, Telnet, DNS. In marketing, the term has been used to distinguish distributed computing by smaller dispersed computers from the "monolithic" centralized computing of mainframe computers. But this distinction has largely disappeared as mainframes and their applications have also turned to the client-server model and become part of network computing.
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.
The most basic type of client-server architecture employs only two types of hosts: clients and servers. This type of architecture is sometimes referred to as two-tier. It allows devices to share files and resources. The two tier architecture means that the client acts as one tier and application in combination with server acts as another tier.
The interaction between client and server is often described using sequence diagrams. Sequence diagrams are standardized in the Unified Modeling Language.
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, name servers, mail servers, file servers, print servers, and terminal servers. Most web services are also types of servers.
Comparison to peer-to-peer architecture :
In peer-to-peer[disambiguation needed] architectures, each host or instance of the program can simultaneously act as both a client and a server, and each has equivalent responsibilities and status.
Both client-server and peer-to-peer architectures are in wide usage today. Details may be found in Comparison of Centralized (Client-Server) and Decentralized (Peer-to-Peer) Networking.
Comparison to client-queue-client architecture :
While classic client-server architecture requires one of the communication endpoints to act as a server, which is much harder to implement,[citation needed] Client-Queue-Client allows all endpoints to be simple clients, while the server consists of some external software, 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 the Client-Queue-Client concept.
Advantages :
* In most cases, a client-server architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers that are known to each other only through a network. This creates an additional advantage to this architecture: greater ease of maintenance. For example, it is possible to replace, repair, upgrade, or even relocate a server while its clients remain both unaware and unaffected by that change.
* All the data is stored on the servers, which generally have far greater security controls than most clients. Servers can better control access and resources, to guarantee that only those clients with the appropriate permissions may access and change data.
* Since data storage is centralized, updates to that data are far easier to administer than what would be possible under a P2P paradigm. Under a P2P architecture, data updates may need to be distributed and applied to each peer in the network, which is both time-consuming and error-prone, as there can be thousands or even millions of peers.
* Many mature client-server technologies are already available which were designed to ensure security, friendliness of the user interface, and ease of use.
* It functions with multiple different clients of different capabilities.
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 overloaded. Contrast that to a P2P network, where its aggregated bandwidth actually increases as nodes 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.
Tuesday, July 21, 2009
Application Server
Definition:
An application server, in an n-tier software architecture, serves an API to expose business logic and business processes for use by third-party applications.
The term can refer to:
1. the services that a server makes available
2. the computer hardware on which the services run
3. the software framework used to host the services (such as JBoss application server or Oracle Application Server)
Java application servers :
Following the success of the Java platform, the term application server sometimes refers to a J2EE or Java EE 5 application server. Some of the better-known Java Enterprise Edition application servers include:
* WebSphere Application Server and WebSphere Application Server Community Edition (IBM)
* Sybase Enterprise Application Server (Sybase Inc)
* WebLogic Server (Oracle)
* JBoss (Red Hat)
* JRun (Adobe Systems)
* Apache Geronimo (Apache Software Foundation)
* Oracle OC4J (Oracle)
* Sun Java System Application Server (based on GlassFish Application Server)(Sun Microsystems)
* SAP Netweaver AS (ABAP/Java) (SAP)
* Glassfish Application Server (open source)
The web modules include servlets and JavaServer Pages. Business logic resides in Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss application server. Tomcat from Apache and JOnAS from ObjectWeb exemplify typical containers which can store these modules.
A Java Server Page (JSP) (a servlet from Java) executes in a web container — the Java equivalent of CGI scripts. JSPs provide a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.
The application servers mentioned above mainly serve web applications. Some application servers target networks other than web-based ones: Session Initiation Protocol servers, for instance, target telephony networks.
Microsoft platform :
Microsoft has contributed the .NET Framework to the world of application servers. .NET technology includes the Windows Communication Foundation, .NET Remoting, ADO.NET, and ASP.NET among several other components. It works with (or depends upon) other Microsoft products, such as Microsoft Message Queuing and Internet Information Services.
Zend platform :
Zend offers an application server called Zend Server — used for running and managing PHP applications.
Other platforms :
Open-source application servers also come from other vendors. Examples include Appaserver, Base4, Zope and Spring Framework.
Non-Java offerings have no formal interoperability specifications on a par with the Java Specification Request. As a result, interoperability between non-Java products is poor compared to that of Java EE based products. To address these shortcomings, specifications for enterprise application integration and service-oriented architecture were designed[by whom?] to connect the many different products. These specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture.
Advantages of application servers :
Data and code integrity
By centralizing business logic on an individual server or on a small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner.
Centralized configuration
Changes to the application configuration, such as a move of database server, or system settings, can take place centrally.
Security
A central point through which service-providers can manage access to data and portions of the application itself counts as a security benefit, devolving responsibility for authentication away from the potentially insecure client layer without exposing the database layer.
Performance
By limiting the network traffic to performance-tier traffic the client-server model improves the performance of large applications in heavy usage environments.[citation needed]
Total Cost of Ownership (TCO)
In combination, the benefits above may result in cost savings to an organization developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm, combined with the need for software distribution to distribute client code, somewhat negate these benefits.
Transaction Support
A transaction represents a unit of activity in which many updates to resources (on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End-users can benefit from a system-wide standard behaviour, from reduced time to develop, and from reduced costs. As the server does a lot of the tedious code-generation, developers can focus on business logic.
An application server, in an n-tier software architecture, serves an API to expose business logic and business processes for use by third-party applications.
The term can refer to:
1. the services that a server makes available
2. the computer hardware on which the services run
3. the software framework used to host the services (such as JBoss application server or Oracle Application Server)
Java application servers :
Following the success of the Java platform, the term application server sometimes refers to a J2EE or Java EE 5 application server. Some of the better-known Java Enterprise Edition application servers include:
* WebSphere Application Server and WebSphere Application Server Community Edition (IBM)
* Sybase Enterprise Application Server (Sybase Inc)
* WebLogic Server (Oracle)
* JBoss (Red Hat)
* JRun (Adobe Systems)
* Apache Geronimo (Apache Software Foundation)
* Oracle OC4J (Oracle)
* Sun Java System Application Server (based on GlassFish Application Server)(Sun Microsystems)
* SAP Netweaver AS (ABAP/Java) (SAP)
* Glassfish Application Server (open source)
The web modules include servlets and JavaServer Pages. Business logic resides in Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss application server. Tomcat from Apache and JOnAS from ObjectWeb exemplify typical containers which can store these modules.
A Java Server Page (JSP) (a servlet from Java) executes in a web container — the Java equivalent of CGI scripts. JSPs provide a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.
The application servers mentioned above mainly serve web applications. Some application servers target networks other than web-based ones: Session Initiation Protocol servers, for instance, target telephony networks.
Microsoft platform :
Microsoft has contributed the .NET Framework to the world of application servers. .NET technology includes the Windows Communication Foundation, .NET Remoting, ADO.NET, and ASP.NET among several other components. It works with (or depends upon) other Microsoft products, such as Microsoft Message Queuing and Internet Information Services.
Zend platform :
Zend offers an application server called Zend Server — used for running and managing PHP applications.
Other platforms :
Open-source application servers also come from other vendors. Examples include Appaserver, Base4, Zope and Spring Framework.
Non-Java offerings have no formal interoperability specifications on a par with the Java Specification Request. As a result, interoperability between non-Java products is poor compared to that of Java EE based products. To address these shortcomings, specifications for enterprise application integration and service-oriented architecture were designed[by whom?] to connect the many different products. These specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture.
Advantages of application servers :
Data and code integrity
By centralizing business logic on an individual server or on a small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner.
Centralized configuration
Changes to the application configuration, such as a move of database server, or system settings, can take place centrally.
Security
A central point through which service-providers can manage access to data and portions of the application itself counts as a security benefit, devolving responsibility for authentication away from the potentially insecure client layer without exposing the database layer.
Performance
By limiting the network traffic to performance-tier traffic the client-server model improves the performance of large applications in heavy usage environments.[citation needed]
Total Cost of Ownership (TCO)
In combination, the benefits above may result in cost savings to an organization developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm, combined with the need for software distribution to distribute client code, somewhat negate these benefits.
Transaction Support
A transaction represents a unit of activity in which many updates to resources (on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End-users can benefit from a system-wide standard behaviour, from reduced time to develop, and from reduced costs. As the server does a lot of the tedious code-generation, developers can focus on business logic.
Thursday, July 2, 2009
Web Server
Definition:
The term web server or webserver can mean one of two things:
1. A computer program that is responsible for accepting HTTP requests from clients (user agents such as web browsers), and serving them HTTP responses along with optional data contents, which usually are web pages such as HTML documents and linked objects (images, etc.).
2. A computer that runs a computer program as described above.
Common features:
Although web server programs differ in detail, they all share some basic common features.
1. HTTP: every web server program operates by accepting HTTP requests from the client, and providing an HTTP response to the client. The HTTP response usually consists of an HTML or XHTML document, but can also be a raw file, an image, or some other type of document (defined by MIME-types). If some error is found in client request or while trying to serve it, a web server has to send an error response which may include some custom HTML or text messages to better explain the problem to end users.
2. Logging: usually web servers have also the capability of logging some detailed information, about client requests and server responses, to log files; this allows the webmaster to collect statistics by running log analyzers on these files.
In practice many web servers also implement the following features:
1. Authentication, optional authorization request (request of user name and password) before allowing access to some or all kind of resources.
2. Handling of static content (file content recorded in server's filesystem(s)) and dynamic content by supporting one or more related interfaces (SSI, CGI, SCGI, FastCGI, JSP,ColdFusion, PHP, ASP, ASP.NET, Server API such as NSAPI, ISAPI, etc.).
3. HTTPS support (by SSL or TLS) to allow secure (encrypted) connections to the server on the standard port 443 instead of usual port 80.
4. Content compression (i.e. by gzip encoding) to reduce the size of the responses (to lower bandwidth usage, etc.).
5. Virtual hosting to serve many web sites using one IP address.
6. Large file support to be able to serve files whose size is greater than 2 GB on 32 bit OS.
7. Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients.
Origin of returned content:
The origin of the content sent by server is called:
•static if it comes from an existing file lying on a filesystem;
•dynamic if it is dynamically generated by some other program or script or application programming interface (API) called by the web server.
Serving static content is usually much faster (from 2 to 100 times) than serving dynamic content, especially if the latter involves data pulled from a database.
Path translation:
Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
• a local file system resource (for static requests);
• an internal or external program name (for dynamic requests).
For a static request the URL path specified by the client is relative to the Web server's root directory.
Consider the following URL as it would be requested by a client:
---------------------------------------------------------------
http://www.example.com/path/file.html
---------------------------------------------------------------
The client's web browser will translate it into a connection to www.example.com with the following HTTP 1.1 request:
-----------------------------------------
GET /path/file.html HTTP/1.1
Host: www.example.com
-----------------------------------------
The web server on www.example.com will append the given path to the path of its root directory. On Unix machines, this is commonly /var/www. The result is the local file system resource:
-----------------------------------------
/var/www/path/file.html
-----------------------------------------
The web server will then read the file, if it exists, and send a response to the client's web browser. The response will describe the content of the file and contain the file itself.
Load limits:
A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 60,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
• its own settings;
• the HTTP request type;
• content origin (static or dynamic);
• the fact that the served content is or is not cached;
• the hardware and software limits of the OS where it is working.
When a web server is near to or over its limits, it becomes overloaded and thus unresponsive.
Overload causes:
At any time web servers can be overloaded because of:
• Too much legitimate web traffic (i.e. thousands or even millions of clients hitting the web site in a short interval of time. e.g. Slashdot effect);
• DDoS (Distributed Denial of Service) attacks;
• Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
• XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
• Internet web robots traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
• Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
• Web servers (computers) partial unavailability, this can happen because of required or urgent maintenance or upgrade, HW or SW failures, back-end (i.e. DB) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.
Overload symptoms:
The symptoms of an overloaded web server are:
• requests are served with (possibly long) delays (from 1 second to a few hundred seconds);
• 500, 502, 503, 504 HTTP errors are returned to clients (sometimes also unrelated 404 error or even 408 error may be returned);
• TCP connections are refused or reset (interrupted) before any content is sent to clients;
• in very rare cases, only partial contents are sent (but this behavior may well be considered a bug, even if it usually depends on unavailable system resources).
Anti-overload techniques:
To partially overcome above load limits and to prevent overload, most popular web sites use common techniques like:
• managing network traffic, by using:
o Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
o HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
o Bandwidth management and traffic shaping, in order to smooth down peaks in network usage;
• deploying web cache techniques;
• using different domain names to serve different (static and dynamic) content by separate Web servers, i.e.:
http://images.example.com
http://www.example.com
• using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings;
• using many Web servers (programs) per computer, each one bound to its own network card and IP address;
• using many Web servers (computers) that are grouped together so that they act or are seen as one big Web server, see also: Load balancer;
• adding more hardware resources (i.e. RAM, disks) to each computer;
• tuning OS parameters for hardware capabilities and usage;
• using more efficient computer programs for web servers, etc.;
• using other workarounds, especially if dynamic content is involved.
The term web server or webserver can mean one of two things:
1. A computer program that is responsible for accepting HTTP requests from clients (user agents such as web browsers), and serving them HTTP responses along with optional data contents, which usually are web pages such as HTML documents and linked objects (images, etc.).
2. A computer that runs a computer program as described above.
Common features:
Although web server programs differ in detail, they all share some basic common features.
1. HTTP: every web server program operates by accepting HTTP requests from the client, and providing an HTTP response to the client. The HTTP response usually consists of an HTML or XHTML document, but can also be a raw file, an image, or some other type of document (defined by MIME-types). If some error is found in client request or while trying to serve it, a web server has to send an error response which may include some custom HTML or text messages to better explain the problem to end users.
2. Logging: usually web servers have also the capability of logging some detailed information, about client requests and server responses, to log files; this allows the webmaster to collect statistics by running log analyzers on these files.
In practice many web servers also implement the following features:
1. Authentication, optional authorization request (request of user name and password) before allowing access to some or all kind of resources.
2. Handling of static content (file content recorded in server's filesystem(s)) and dynamic content by supporting one or more related interfaces (SSI, CGI, SCGI, FastCGI, JSP,ColdFusion, PHP, ASP, ASP.NET, Server API such as NSAPI, ISAPI, etc.).
3. HTTPS support (by SSL or TLS) to allow secure (encrypted) connections to the server on the standard port 443 instead of usual port 80.
4. Content compression (i.e. by gzip encoding) to reduce the size of the responses (to lower bandwidth usage, etc.).
5. Virtual hosting to serve many web sites using one IP address.
6. Large file support to be able to serve files whose size is greater than 2 GB on 32 bit OS.
7. Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients.
Origin of returned content:
The origin of the content sent by server is called:
•static if it comes from an existing file lying on a filesystem;
•dynamic if it is dynamically generated by some other program or script or application programming interface (API) called by the web server.
Serving static content is usually much faster (from 2 to 100 times) than serving dynamic content, especially if the latter involves data pulled from a database.
Path translation:
Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
• a local file system resource (for static requests);
• an internal or external program name (for dynamic requests).
For a static request the URL path specified by the client is relative to the Web server's root directory.
Consider the following URL as it would be requested by a client:
---------------------------------------------------------------
http://www.example.com/path/file.html
---------------------------------------------------------------
The client's web browser will translate it into a connection to www.example.com with the following HTTP 1.1 request:
-----------------------------------------
GET /path/file.html HTTP/1.1
Host: www.example.com
-----------------------------------------
The web server on www.example.com will append the given path to the path of its root directory. On Unix machines, this is commonly /var/www. The result is the local file system resource:
-----------------------------------------
/var/www/path/file.html
-----------------------------------------
The web server will then read the file, if it exists, and send a response to the client's web browser. The response will describe the content of the file and contain the file itself.
Load limits:
A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 60,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
• its own settings;
• the HTTP request type;
• content origin (static or dynamic);
• the fact that the served content is or is not cached;
• the hardware and software limits of the OS where it is working.
When a web server is near to or over its limits, it becomes overloaded and thus unresponsive.
Overload causes:
At any time web servers can be overloaded because of:
• Too much legitimate web traffic (i.e. thousands or even millions of clients hitting the web site in a short interval of time. e.g. Slashdot effect);
• DDoS (Distributed Denial of Service) attacks;
• Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
• XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
• Internet web robots traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
• Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
• Web servers (computers) partial unavailability, this can happen because of required or urgent maintenance or upgrade, HW or SW failures, back-end (i.e. DB) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.
Overload symptoms:
The symptoms of an overloaded web server are:
• requests are served with (possibly long) delays (from 1 second to a few hundred seconds);
• 500, 502, 503, 504 HTTP errors are returned to clients (sometimes also unrelated 404 error or even 408 error may be returned);
• TCP connections are refused or reset (interrupted) before any content is sent to clients;
• in very rare cases, only partial contents are sent (but this behavior may well be considered a bug, even if it usually depends on unavailable system resources).
Anti-overload techniques:
To partially overcome above load limits and to prevent overload, most popular web sites use common techniques like:
• managing network traffic, by using:
o Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
o HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
o Bandwidth management and traffic shaping, in order to smooth down peaks in network usage;
• deploying web cache techniques;
• using different domain names to serve different (static and dynamic) content by separate Web servers, i.e.:
http://images.example.com
http://www.example.com
• using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings;
• using many Web servers (programs) per computer, each one bound to its own network card and IP address;
• using many Web servers (computers) that are grouped together so that they act or are seen as one big Web server, see also: Load balancer;
• adding more hardware resources (i.e. RAM, disks) to each computer;
• tuning OS parameters for hardware capabilities and usage;
• using more efficient computer programs for web servers, etc.;
• using other workarounds, especially if dynamic content is involved.
Subscribe to:
Posts (Atom)
