« Student scientific so… | Главная |

  D.O.Sazonov

PROCESSING OF DISTRIBUTED DATA

One of the main features of designing the modern information systems – is distributed nature. The branches of Company can cover a lot of points in the whole world. The main problem of such systems is the organization of processing distributed data. All data located in computers of different models and producers, functioning under different operation systems. The Computers are territorialy removed from each other and locate in other geographical points of planet.
As an answer can be technology of distributed database. The distributed database looks with standpoint of users and applied programs as usual local base.
In this sense a word "distributed" reflects way of organization a database, but not its external description ("state of distribution" must’nt be seen from outside to users)
This technology is complex in realization and requires big capital investments. As a second possible variant is to choose CGI technologies. In this case, database is located on the main server of company and all branches of company look-up to database using browser (like they usually do working in internet). Using in realization CGI technologies satisfies all cardinal principles of distributed database, such as:
- Transparency of location;
- Transparency of network;
- Automatic transformation of data formats;
- Automatic translation of codes.
Mechanism is realized with availability of presence two more standartized facilities: including forms in the document and made with the use of hyper text markup language - HTML, and the possibility of use external to server Web programs, which interaction occurs through specified protocol CGI or embedded API functions. At realization based on CGI general scheme of gain access to database on side Web-server looks as follows:
1) when viewing the document a client meets link to the page, containing one or several forms, assigned for requests from database;

2) client requires the page; aside from blank forms a page can contain general information about database and about purpose of proposed forms;

3) if client really interests in information from database, which possible get after offering forms, he fills one of the forms and sends data to server;

4) got filled form, server starts corresponding external program, sending to her parameters and getting results based of protocol CGI;

5) external program will convert the request denominated by filled form, in query language, comprehensible to server database (usually it’s SQL language).

6) external program cooperates with database server; cooperation can be direct if external program attached to concrete SQL-server, for instance, with protocols and corresponding driver ODBC if distinct attach is absent;

7) After receiving results of request external program forms corresponding virtual or real HTML-page, and send it to server, when terminates its execution;

8) Server will send formed HTML-page to client, and on this procedure of access to database is terminated (as usually, server close connection with client).

Presence CGI-scripts on Web-server side allows, in particular, carry out part of logic from client in server. CGI-gateways present itself facility for organization three-tier model (in general, multi-tier architecture) of architecture client-server.
As you see, when use CGI whole interpreting the user request is produced by CGI-script. Script can be dependent on platform, orientated on performing the request to fixed table of database, or comparatively flexible capable to execute free request to one or several tables in database, identified in parameters of client. However in real life database server must service simultaneously great number of requests from clients - consequently, at one moment of time can be several requests. As a result working load to operating system increases, accordingly increasing total number of its processes, spending system facility. Therefore, for modern distributed DBMS important to have multithreaded communication server, which to take upon itself all problems of network support of clients who are working with server at the same time.

On each node of network server supports a set of connection pair "client-server" and allows to exist simultaneously multitudes of independent sessions of work with database. As optimum decision it is reasonable offer - technology ASP. ASP - ambience of functioning the scenarioes on side of server. ASP allow to combine HTML, scenario and architecture for making the dynamic content Web or powerful Web-exhibits. Technology ASP gives essential advantages since allows to create on-line databases and business-exhibits, rather then simply publish information in internet. Information exchange with database from ASP-file usually carried out layer ActiveX-objects for data processing (ActiveX Data Objects, ADO).
ADO is "superstructures" on new API database, madden of corporation Microsoft, - OLE DB, which (in existing variant) interacts with available databases ODBC through kernel ODBC.
New version of OLE DB will be equipped with the facilities of supply data suitable to work with concrete DBMS, such, as Microsoft SQL Server and so on. So no need of sending the requests through processor ODBC. However at present unique solution of supply data, which there is in kit IIS, - ODBC-supplier.
From program, running in Web-browser, can be possible to change information with remoted databases, using service of remote access to data (Remote Data Service, RDS). RDS-components process enterring on protocol HTTP requests to database and send their corresponding to DB, using layer OLE DB. Then RDS takes results of execution of these requests, forms incoherent sets of data and will send them on protocol HTTP Web-browser to a client.
For connection ASP pages to SQL Server database server ADO can use the supplier OLE DB both for ODBC, and for SQL Server. The Supplier OLE DB for ODBC allows to use the structure of object ADO with the most existing drivers ODBC. But supplier OLE DB for SQL Server enable to connect only to SQL Server. However with objects ADO Join, Command and Set of record possible to use any one of the mentioned suppliers. The Listings 1 shows, how to use the supplier OLE DB for ODBC in purposes of determination of join with SQL Server.
The first action conducted in listings 1, declaration of three variables, which will contain the name of computer, on which installed SQL Server, and information for authentification SQL Server. Then, scenario declare variable cn, which it in consequence will use for object ADO Join. After update of workers variables in scenario method “to form”(Form) of object ASP Request (Request) assigns value all this variable.
The following step - is the method “Create object” (CreateObject) of object ASP Server (Server) creates new object ADO Join (Connection), which is then assigned earlier variable cn. The method “to Create” the object (CreateObject) capable to generate the copies of objects COM . Given example illustrates making the copy of object “a Join” ADODB (ADODB.Connection), but its also can use for other structures of objects a COM for instance, for SQL-DMO or Active Directory.
After scenario assigns value to line of connection OLE DB property, (ConnectionString) of object a Join, keeping in variable cn. This allows to set connection without set of name of source data, DSN (Data Source Name). Because of that specification of supplier OLE DB was conducted without keyword PROVIDER, by default rs the supplier OLE DB for ODBC. The keyword DRIVER identifies that driver, which is expected use in future. For keyword SERVER is indicated the name of computer, containing SQL Server with which intended to set connection. For keywords UID and PWD are kept information required for entering in system.
The keyword DATABASE defines that the database, used by default, will emerge the database “pubs”. After value is assigned to variable of connection of object “a Join” (Connection), its method “to Open” (Open) will set connection with SQL Server satisfying all importance parameters, given in scenario.

Listing 1. Apply object ADO “connection” to our program
<%
Dim sServer
Dim sLoginID
Dim sPassword

Dim cn

‘ Get info from server about login parameters
sServer = "myServer"
sLogin = "myID"
sPassword = "myPassword"

‘Create object “connection”
Set cn = Server.CreateObject("ADODB.Connection")

‘ open connection
cn.ConnectionString = "DRIVER=SQL Server" & _
";SERVER=" & sServer & _
";UID=" & sLoginID & _
";PWD=" & sPassword & _
";DATABASE=pubs"

cn.Open%>

MSDASQL is the default value for Provider so if you want to, you can simply leave the parameter off altogether. In fact, you'll notice that almost all the sample code you run across doesn’t leave it off. Included it in the samples above for illustration and because the Provider is a relatively central point to get in order to really understand how all these parameters fit together to allow these connection strings to actually get you connected.

0 рейтинг 0 голосов

Нет комментариев