SQL Server

Distributed Databases with Client Server Architectures Part – 7

An Outline of Client – Server (CS) Architecture

As it was mentioned in the article introduction, full scale Distributed Database Management Systems (DDBMS) have not been advanced to support every category of functionalities which was discussed so far. As an alternative, distributed database applications are being established in the background of the client – server (CS) architectures. It is at the present more common to practice a three – tier architecture, particular in Web applications. This architecture is illustrated in Figure 9.4. In the three-tier (3) client – server (CS) architecture, the subsequent three (3) layers is present:

1. Presentation layer (Client): This delivers the user interface (UI) as well as act together with the end user. The software package at this particular layer presents Web Interfaces (Web – Forms) or Windows – Forms to the end users in order to interface with the system. Web browsers are frequently make use of, in addition to the languages castoff include Hypertext Markup Language (HTML), JAVA, ASP.NET, JavaScript, AJAX, PHP, PERL, Visual Basic, and so on. This particular layer manages the user input, output, as well as navigation by means of accepting end user instructions plus representing the desired information, generally in the form of static (fixed) or dynamic (live) Web pages. The latter are used when the communication includes database access. At the time when a Web interface is made use of, this layer naturally interconnects with the application layer by means of the Hypertext Transfer Protocol (HTTP).

2. Application layer (business logic): This layer includes the programs which specify the application logic. For an instance, queries can be expressed based on end user input from the client, or query results can be planned as well as sent to the client for demonstration. Supplementary application functionality can be managed at this layer, such as safety checks, uniqueness confirmation, as well as other functions. The application layer can act together with one (1) or more (N) databases or else data sources as required by means of linking to the database by means of Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), Structured Query Language / Command Line (SQL/CLI) or another database right to use methods.

3. Database server: These particular layers manage the query as well as modify the requests from the application layer, handle the requests, as well as send the results. Generally Structured Query Language (SQL) is castoff to access the database when it is relational or else object – relational as well as database stored procedures may possibly be invoked. Query outcomes (in addition to queries) may possibly be configured into Extensible Markup Language (XML) when transmitted among the application server and the database server.

Precisely in what manner to segregate the Database Management System (DBMS) functionality among Presentation Layer (client), Application Layer (business logic), and Database Server may perhaps vary. The commonly used method is to take in the functionality of a centralized Database Management System (DBMS) at the database server level. A number of relational Database Management System (DBMS) products have used this method, where a Structured Query Language (SQL) server is offered. The application layer (business logic) should then frame the suitable Structured Query Language (SQL) queries as well as join to the database server as and when required. The presentation layer (client) offers the processing for the end user interface interactions. As Structured Query Language (SQL) is a relational standard, numerous Structured Query Language (SQL) servers, probably offered by means of various vendors, can agree to take Structured Query Language (SQL) commands through standards such as Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), Structured Query Language / Command Line (SQL/CLI). In this structural design, the application layer (business logic) may perhaps refer to a data dictionary which is consisting of data on the distribution of data among the several Structured Query Language (SQL) servers, as well as units for decomposing a global query into a number of local queries which can be implemented at the several sites. Interaction among application layer (client) as well as database server may continue as follows in the course of the processing of a Structured Query Language (SQL) query:

1. The application layer (client) frames an end user query based on input from the application layer (client) as well as decomposes it into several independent site queries. Every single site query is directed to the suitable database server site.

2. Every single database server processes the local query as well as directs the results to the application layer (client) server site. Gradually more, Extensible Markup Language (XML) is being hyped as the norm for data exchange as a result the database server may possibly format the query result into Extensible Markup Language (XML) before directing it to the application layer (client) server.

3. The application layer (client) server associates the results of the sub – queries to create the result of the originally requisite query, formats it into Hypertext Markup Language (HTML) or a number of other forms accepted by the client, as well as directs it to the client site for display.

The application layer (client) server is accountable for producing a dispersed implementation plan for a multi-site query or transaction plus for administering disseminated execution by means of directing commands to servers. These instructions consist of local queries as well as transactions to be implemented, and commands to convey data to another clients or servers. An additional function measured by means of the application layer (client) server or coordinator is that of confirming constancy of simulated replicas of a data item by means of using distributed or global concurrency control methods. The application layer (client) server should also confirm the atomicity of global transactions by means of carrying out global recovery when assured sites fail.

When the Distributed Database Management System (DDBMS) has the ability to hide the information of data dissemination from the application layer (client) server, then it permits the application layer (client) server to implement global queries as well as transactions as although the database were centralized, without having to identify the sites at which the information is referenced in the query or where the transaction be present in. This things is known as distribution transparency. A number of Distributed Database Management System (DDBMS) do not offer distribution transparency, as an alternative necessitating that applications be conscious of the facts of information distribution.

This is the last part of this particular series, hope the reader is benefited with this series.