Software Architectures - An OverviewTwo-tier Architecture
Typical client/server systems have fallen into the category of a two-tiered architecture. 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 clients. Processing management is being split between the user system interface environment and the database management server environment. The database management server provides stored procedures and triggers. Client/Server applications have the following unique characteristics:
A client is the initiator of one or more service requests and a server is the service provider. Clients and servers can run in different address spaces in the same machine or in different machines. Clients and servers are not peers and hence they can not swap their functionalities. Servers encapsulate their functionality and a client can request a service through many ways such as remote procedure call or remote method invocation or sending a message to the server. The service implementation details are transparent to the clients. Clients also need not know the location of the server, that is, servers can be put in the same client machine and they can be located in a remote place.
A client/server system can be scaled by distributing the processing across multiple machines. In some occasions, servers make remote calls or pass messages back to their clients. For this to happen, client has to expose a method for server callbacks. This makes it possible for servers to communicate with their clients in an asynchronous model. When the requested request gets accomplished, the server can connect back to the client through the exposed method to give the resulted result.
Client/Server Applications - This technology happens to be a very useful model and mechanism for many enterprises to store and manage resources on the network. Here comes a host of common examples of network applications for client/server architectue.
1. File Servers - This network server often stores files such as documents, excel sheets, images, power point files etc. and acts as a shared repository for many client machines associated with that network.
2. Database Servers - This server can accept SQL statements as messages from its clients and processes them and sends the answers back.
3. Print Servers - This server allows many workstations in the network to access a shared printer. Printer servers allow for remote administration of servers, such as the cancellation of print jobs.
4. E-mail Servers - This server can act as a central repository for emails and all the client workstations can connect with this server machine and fetch the emails.
5. Proxy Servers - This server is mainly for reducing external bandwidth by caching frequently requested content. Sometimes it acts as a deterrent for unauthorized Internet users of any private network.
6. Web Servers - This server stores html files and dispatch them to any client machine connected with the internal or public network such as Internet. There are some additional modules on this Web server for creating dynamic html pages to be sent to the client machines.
Thus client/server architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability and scalability as compared to its earlier 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 computing machine can both act as a server and a client.
Before going deeply into two-tier architecture, here comes a brief about the earlier computing architecture.Earlier Computing Architectures
1. Mainframe architecture - With mainframe software architectures, all intelligence has been found within the central host computer. Users interact with the host through a unintelligent terminal that captures keystrokes and sends that information to the host. Mainframe computing architectures are not tied to a hardware platform. Users can connect with the host through any sort of systems including PC or Unix workstations. The main stumbling block with this architecture is that it does not support any graphical user interface or access to multiple databases from geographically dispersed sites.
2. File Sharing architecture - The original PC networks were based on file sharing architectures, where the server downloads files from the shared location to the desktop environment. The requested user job is then run both logic and data in the desktop environment. File sharing architectures work if shared usage and content updating are very low, and the volume of data to be transferred is low. The main problem with this setup is that file sharing gets strained when the number of online users grow significantly. Also network traffic got congested as the full file has to be downloaded to the user machine each time he/she requests for a file.
3. Client/Server architecture - This approach basically introduced a database server to replace the file server. Using a relational database management system, user queries are answered directly and this primarily reduces the network traffic by supplying relevant query response to the client instead of the total file transfer. It highly improves multi-user updating through a GUI front end to a shared database. In this architecture, remote procedure calls or standard query language statements are being used by clients to communicate with servers.
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 simultaneously. The application exists entirely on the client PC while the database sits out on a server machine. In this type of architecture, the full processing load is lying onto the PC while the more powerful server machine act as a traffic controller between the application and the database.
This feature leads to very high utilization of the PC resulting in poor performance and there is a sharp increase in network traffic. This is a result of the server maintaining a connection via "keep-alive" messages with each client, even when no work is being done. When the entire application is processed on a PC, the application is forced to make multiple requests to data source for data before presenting anything to the end user. These multiple data requests can affect the precious network performance. Thus there arises a very high inhibition on scalability, availability and performance on the system. Also in a typical two-tier client-server environment, programmers write applications that are closely tied to vendor-specific software.
Another main problem with any two-tiered client/server approach is that of maintenance. If there is a small change effected in an application logic code, all the users accessing that code have to be taken off from the systems. As the days go by, this may lead some sort of confusion about which version of the software is being used and by whom. Thus performance degradation and maintenance issues are the two main bottlenecks prevailing in a two-tier architecture application apart from the issues such as lack of scalability and flexibility and a very high network traffic.Three-tier Architecture
In order to address the above-mentioned issues in an effective way, software developers community came with an evolutionary but effective and efficient solution referred to as "three-tier architecture". That is, an application can be separated into three logical layers, each with a well-defined set of interfaces. The first tier is called as the presentation layer and it normally consists of a graphical user interface. The middle tier consists of the application logic and the third tier is the data layer. The three logical layers can lie in the same machine also through smart software configuration.
Thus three-tier client/server applications employ an intermediary or middle-tier application server, which operates between client applications and the back-end databases. The middle tier composes business application logic code, which the user calls upon through the front-end graphical user interface to retrieve the desired data. The presentation layer on getting the data from the middle tier formats the data for displaying it to the user. This kind of separations brings a number of unique advantages such as flexibility and performance increment. Also multiple user interfaces can be built and deployed with out bringing any change to the application logic.
There are a variety of ways of implementing this middle tier, such as using transaction processing (TP) monitors, message servers, object request brokers (ORBs) or application servers. The middle tier can perform queuing, application execution, locating and connecting application objects and database staging. 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.
The third tier contains the data that is needed for the application.. The data can be from any source of information such an enterprise database like Oracle, MS SQL Server, a set of XML documents, a directory service like an LDAP server, or even any legacy and proprietary systems.Advantages of Three-tier Applications
This approach heavily improves those lacking points found in two-tier application. Separating business rule services from the rest of the application offers many important advantages:
There are two fundamental motivations for using a three-tier architecture over a two-tier model:
These features are being achieved through managing back-end resources in a more effective and smart manner. There are some good resource management techniques such as pooling and clustering middle-tier servers. Pooling makes three-tier systems more effective by allowing more clients to share scarce resources like database connections, which reduces the workload on back-end servers. Clustering makes three-tier systems more available and scalable because multiple servers and resources can support fail-over and balance the word loads of a growing client population.
Three-tier systems are more flexible and extensible than their two-tier systems as the business logic and services such as security, persistence, transactions etc reside on the middle-tier and transparent to the client applications. This tends to make these services being applied automatically to client requests and any changes made in the business logic code do not reflect on the clients in any way.Three-tier Technologies
Transaction Processing (TP) monitor - 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 in the middle layer instead of database server on the back-end. The transaction is accepted by the monitor, which queues it and then takes responsibility for managing it to completion, thus freeing up the client. A typical TP monitor technology provides
For systems with thousands of users, TP monitor technology has been one of the most effective solutions.
The main limitations of this technology is that the implementation code has to be written in a low-level language such as COBOL and there is no visual toolsets to interoperate with the middle tier.
Message Server - This is another viable technology to implement three-tier architecture applications. Messages from clients are being prioritized and processed asynchronously. A typical message consist of a header that contain priority information, and the address and identification number. The message server connects to the backend RDBMS and other data sources. The main difference between TP monitor technology and message server paradigm 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. Click here for an overview of Java Message Service (JMS).
Application Server = Application servers make it easier to encapsulate and reuse business logic. This methodology helps the application logic code to be deployed in a shared host machine rather than in the user system interface. There are many application servers in the market. The application server comes with a EJB container as a enterprise beans execution environment. The application server automatically takes care of all the needs such as transaction, persistence, security, and pooling of the beans deployed in that environment. The application server can host many transactional, distributed, object-oriented software components. Click here for an overview of application server.
Object Request Broker - There are a couple of distributed object computing technologies such as OMG's CORBA , Microsoft's DCOM and Sun Microsystem's Java RMI. Click here for an overview of CORBA. CORBA specifications supports the concept of object request broker (ORB) that can locate and facilitates the communication between clients and scattered server objects. There are a suite of vertical and horizontal services that can be imported and there are a host of services such as name service, time service etc. CORBA also brings language, protocol, and platform independence. That is, clients and server objects can be developed in different languages and still contact and interoperate each other. Similarly they can work in a different environment and they may use different protocol.
Still it has been found that three-tier methodology lacks some critical features such as reusability of application logic code and scalability. That is, there may arise a situation whereby a collection of application logic code results and they can not be reused and also they do not communicate with one another. Thus there came a need for a viable architecture that mainly facilitates reusability of business logic as reusability phenomena has been found that it can reduce highly the cost of software development and the time to market and its quality is assured.
Consider server-side validation for a highly interactive client form. Validating all of the fields at one time quickly becomes impractical for this 3-tier architecture. That is, each call may need a separate call to the application server and this will involve dozens of cross-network calls to an application server resulting in performance degradation.N-tier Architecture
Thus came the notion of n-tier architecture. N-tier architecture facilitates further partitioning of application services. To turn a three-tier architecture into an n-tier system, the middle tier can be allowed to have multiple application objects rather than a single application. That is, this architecture supports division of the business logic tier into two collaborating tiers - one for business logic rule processing that supports the user interface and the other for business rule processing that integrates and manipulates data. Each of these separated business application objects must have a well-defined interface which allows them to contact and communication with one another. An interface is actually brings an idea of contract. That is, each object states through its interface that it will accept certain parameters and return a specific set of results. Application objects uses their interfaces to do business processing.
Thus a multi-tier or n-tier application consists of the following tiers:
Thus the main point behind multi-tier architecture is to keep the particular services physically close to the data they work with and hence to cut down on cross-network calls. Normally UI-oriented business rule components are excellent candidates for JavaBeans. The JavaBeans API lets developers to create reusable, platform-independent components that can be combined into applets, applications, or composite components.Advantages of Multi-Tier Applications
Multi-tier applications scale well because multi-tier architecture is a component-based architecture. The performance of core business logic and data persistence can be tuned with extreme precision. Business logic services that support UI can remain physically close to the client. Remaining application services can scale as additional resources become available. We can add more processors to the application server or even we can add another server to maintain the required performance requirements.