A client-server architecture model is used. Client-server architecture

The key difference between client-server architecture and file-server architecture is the abstraction from the internal data representation (the physical data schema). Client programs now manipulate data at the logical circuit level.

So, the use of client-server architecture made it possible to create reliable (in terms of data integrity) multi-user information systems with a centralized database, independent of the hardware (and often software) of the database server and supporting GUI user interface (GUI) on client stations connected by a local network. Moreover, application development costs were significantly reduced.

Main features:

The client program works with data through requests to the server software.

The basic functions of the application are divided between the client and the server.

Full multi-user support

Data integrity guarantee

The business logic of the applications remained in the client software. With any change in algorithms, it is necessary to update the user software on each client.

High requirements for bandwidth communication channels with the server, which prevents the use of client stations other than on the local network.

Weak data protection from hacking, especially from unscrupulous system users.

High complexity of administration and configuration of system user workstations.

The need to use powerful PCs at client sites.

High complexity of system development due to the need to implement business logic and provide user interface in one program.

It is easy to see that most of the shortcomings of the classical or 2-layer client-server architecture stem from the use of the client station as the executor of the IS business logic. Therefore, an obvious step in the further evolution of IS architectures was the idea of a “thin client,” that is, dividing data processing algorithms into parts related to the performance of business functions and related to displaying information in a human-friendly presentation. At the same time, only the second part is left on the client machine, associated with the primary verification and display of information, transferring all the real functionality of the system to the server part.

Transitional to three-layer architecture (2.5 layers)

Using stored procedures and server-side data calculation reduces traffic and increases security. The client still implements some of the business logic.

As you can see, this organization of the system is very reminiscent of the organization of the first unitary systems, with the only difference that at the user’s place there is not a terminal (with the notorious green screen), but personal computer, providing a GUI, for example, recently standard www browsers are often used as client programs. Of course, such a return to almost unitary systems occurred at a different technological level. The use of DBMS with all their advantages has become mandatory. Programs for the server side are written mainly in specialized languages, using the mechanism of stored procedures of the database server. Thus, at the level of logical organization, the IS in the client-server architecture with a thin client is split into three layers - a data layer, a layer of business functions (stored procedures) and a presentation layer. Unfortunately, usually, in such an IS design scheme, it is not possible to write all the business logic of the application in built-in DBMS languages not intended for this purpose. Therefore, very often part of the business functions is implemented in the client part of the systems, which inevitably “gets fatter” as a result. Partly for this reason, and partly because such ICs physically consist of two components, this architecture is often called a 2.5-layer client-server.

Unlike 2-layer architecture, 2.5-layer architecture usually does not require high-speed communication channels between the client and server parts of the system, since ready-made calculation results are transmitted over the network - almost all calculations are performed on the server side. Information security is also significantly improved - users are given rights to access the functions of the system, and not to access its data, etc. However, along with the advantages of the unitary approach, architecture 2.5 also adopts all its disadvantages, such as: limited scalability, dependence on software platform, limited use of network computing resources. In addition, programs for the server part of the system are written in stored procedure languages built into the DBMS, intended for data validation and building simple reports, and not at all for writing enterprise-scale information systems. All this reduces the performance of the system, increases the complexity of creating and modifying the IC, and has the most negative impact on the cost of the hardware necessary for its operation.

Development for iOS,

Mobile application development

Let me make a reservation right away that I am a mobile developer, and the article is intended mainly for developers on the other side of the cloud - mobile developers already know about all this. I wrote the last web application many years ago and I may be wrong in web terminology, may not know some of the latest trends in .NET, PHP or Java web services, so don't judge too harshly.

Like any front-end developer, in almost every project I have to deal with client-server protocols - I can’t do without them. And very, very often you have to work with poorly thought out architecture.

Also, very often the development of the protocol and architecture falls on the shoulders of the web developer, which is not always true - in most cases it should only be developed jointly with those who will adapt to this architecture. Unfortunately, having worked on several dozen projects over the past three years, I had the opportunity to participate in the planning of this section of the architecture only 3 or 4 times - in all other cases it was already provided in varying degrees of readiness by the customer. But how much better the world could be!

Error Handling

Most often I came across something like this:

HTTP code 200 (OK) false The username or password is incorrect. Please try again.
Those. the result of processing the request is contained in the sent XML itself, the HTTP return code is 200, i.e. ok, the data is presented as a regular RPC. For example, error handling in the SOAP protocol is implemented in a similar way in 90% of cases.

In particularly advanced cases, especially typical for Indian code, false can be located in various places in the XML, which significantly complicates parsing, leads to overcomplication and brings immense joy to a bored programmer.

But let's look at the disadvantages of this approach in principle.

First, you have to parse XML. This is extra data transferred over the network, extra CPU time spent on XML parsing, extra RAM for storing text data. All this is not so scary on modern devices in a Wi-Fi zone, but even such excesses can matter in the metro between stations in an application that sends dozens of requests simultaneously (and with this approach, empty blocks for error handling should be in every request, even successful).
Secondly, the web developer has to invent error texts himself. Very often they are completely incomprehensible to the user, because... accuracy of wording is the last thing a web developer thinks about when writing a service. The error text in 90% of cases does not agree with native speakers, and last but most importantly, a huge number of mobile applications need localization. While the error text is most likely always written only in English, therefore it is absolutely useless for a front-end programmer - he cannot simply take it and display it.

But the time needed by the web programmer to come up with the text of the message is wasted, and the channel is also loaded with unnecessary information.

How to solve the problem?

IN HTTP protocol For many years now it has been possible to add your own error codes; to do this, they simply must belong to the range from 512 to 597. I am sure that this number of errors will be enough to cover all possible errors in a medium sized application. It’s obvious what advantages this gives, but let’s summarize:

No redundancy. Only the HTTP code in the header is transmitted, there is simply no request body.
On the client side, there are only two branches of request processing code - successful execution or execution error (both callbacks are already implemented out of the box in any request library). There are no “request completed successfully, but there may be a logical error in the response body” threads.

5xx Server Error
The server failed to fulfill an apparently valid request.
Response status codes beginning with the digit “5” indicate cases in which the server is aware that it has encountered an error or is otherwise incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and indicate whether it is a temporary or permanent condition. Likewise, user agents should display any included entity to the user. These response codes are applicable to any request method.

Those. clients must show the user the message sent by the server. It is immediately clear what the Americans wrote. The Russians, by the way, translated it stupidly.

Although we won’t generalize – the idea of using HTTP codes was suggested to me by an American several years ago.

In general, the ideology is this: the client always knows better how to report an error. And the server must inform the client about the error in the fastest and most cost-effective way.

Binding to a session or cookie.

This connection most likely occurs if a website was created first, and only then the customer decided to create a mobile front-end. Although working with session variables is possible on the mobile side, it is not good practice because Often there is no normal toolkit for working with these tools.

The second, global drawback is that Safari (or any browser on Android) does not share its cookies and session variables with the application, which, of course, is correct from a security point of view, but leads to a number of problems and crutches.

Let's say your mobile application implements only 70% of the functionality of the website. The remaining 30% of the functionality is available only on the web, and your application only contains links to relevant web pages.

It is also possible that these pages are only accessible to authorized users. As a result, the user who is already logged in mobile client, you will be asked to log in again - this time in an inconvenient web form, and happiness will be if after logging in the user is redirected to the desired section of the site.

Bottom line - if you're designing a generic protocol, forget about things like session variables and cookies. A much better way would be to pass some unique token received during authorization explicitly in the body of each request. And web pages and web applications should adapt to the use of a single API. I'm sure all mobile developers have often seen two versions of the API - one for web applications, the other for mobile applications. But this is duplication of functionality, which is always more expensive both at the development stage and at the debugging stage. It is always better to allocate web services into a separate layer of the system from the very beginning, rather than embed them in other parts close to web technologies.

Return HTML

This already leads back to the design of the web servers themselves, which were initially designed only for the browser. Errors 403, 404, and sometimes even more complex ones are very often presented in the form of an HTML page, which there is often simply no way to show it in mobile application. More precisely, there are funds, but after seeing “404 page not found” with a hefty black Arial Black on a white background inside the web view, the mobile user will get scared and close the application.

Remember, the server must return XML (or JSON) for any call to web services, and only in the format that was originally agreed upon. A mobile developer cannot do anything useful with the HTML that comes from the server.

Use WSDL

On Microsoft technologies the situation is still okay - most of them modern technologies supports WSDL out of the box. The same cannot be said about PHP and Java - especially PHP developers love to manually create ordinary pages, which are essentially web services. But in order to integrate with a WSDL-compatible web service, a mobile developer only needs to use the tool to generate code, while manually compiled web service responses also need to be parsed by hand.

True, there are subtleties here too - standard WSDL implementations from MS and Sun (Oracle) still have incompatibilities, but it’s still faster to correct these incompatibilities with a file than to write everything manually.

Conclusion

I only touched on the most pressing design errors that mobile developers have to deal with every day. If the article is in demand, I will definitely write about a dozen more client-server subtleties that I would really like to see in the API of web services that you work with every day.

Client-server architecture(client-server architecture) is a concept information network, in which the bulk of its resources are concentrated in servers serving its clients. The architecture in question defines two types of components: servers and clients.

Server - is an object that provides service to other network objects upon their requests. Service is a customer service process.

Figure Client-server architecture

The server works on orders from clients and manages the execution of their tasks. After each job is completed, the server sends the results to the client that sent the job.

The service function in the client-server architecture is described by a set of application programs, in accordance with which various application processes are performed.

The process that causes service function using certain operations is called client. This could be a program or a user. Clients- these are workstations that use server resources and provide convenient user interfaces. User Interfaces These are the procedures for how a user interacts with a system or network.

Figure Client-server model

The client is the initiator and uses email or other server services. In this process, the client requests a service, establishes a session, gets the results it wants, and reports completion.

IN networks with a dedicated file server on a dedicated standalone PC a server network operating system is installed. This PC becomes server. Software ( BY), installed on workstation, allows it to exchange data with the server. The most common network operating systems are:

In addition to the network operating system, network applications are needed to take advantage of the network's benefits.

Server-based networks have best characteristics and increased reliability. The server owns the main ones network resources, to which other workstations access.

In modern client-server architecture, there are four groups of objects: clients, servers, data and network services. Clients are located in systems at user workstations. Data is mainly stored on servers. Network Services are shared servers and data. In addition, services manage data processing procedures.

Client-server architecture networks have the following advantages:

Allows you to organize networks with a large number workstations;

Provide centralized management of user accounts, security and access, which simplifies network administration;

Efficient access to network resources;

The user needs one password to log into the network and to gain access to all resources to which user rights apply.

Along with the advantages of the client-server network, there are also a number of disadvantages:

A server malfunction can make the network inoperable, or at least a loss of network resources;

Require qualified personnel for administration;

Have higher network costs and network equipment.

Client-server systems. Part 2

Client-server architecture: definition, prerequisites for application, pros and cons

What is client-server architecture? Application building options

So, let's finally talk about

What exactly is a client-server? . Strictly speaking, one should distinguish between client-server technology in a broad sense, which can be used in any computer systems from the client-server architecture itself in relation to information applications in general and automated enterprise management systems in particular.

According to online dictionary computer terms, client-server is a kind distributed system, in which there is a server that fulfills client requests, and the server and client communicate with each other using one or another protocol.

A client is a program that uses resources, and a server (in English, a servant) is a program that serves client requests for a certain type of resource. Such a broad definition includes almost any software technology that involves more than one program, the functions between which are distributed asymmetrically. Accordingly, they talk about CS technology in relation to operating systems, local and global networks etc.

Such a broad definition creates some confusion. Thus, a file-server system also uses client-server technology, but from the point of view of application program architecture, what is important is what kind of resources the server provides to clients.

The concept of client-server architecture in enterprise management systems is associated with the division of any application program into three main components or layers. These three components are

data presentation (visualization) component;

applied logic component;

database management component.

Indeed, any program that computerizes the execution of one or another applied problem, must exchange information with the user, carry out the actual processing of this information as part of the automation of a particular business process, and, finally, store the data used in the program on one or another permanent medium.

For local applications that run entirely on a PC (for example, Word or Excel), all these components are collected together and cannot be distributed between various computers. Such a program is monolithic and uses for execution only the resources of the computer on which it is executed.

In file server applications, some of the storage components are transferred to file server However, all manipulations with data structures are performed on the client machine, and the user program code also runs only on it.

The criterion that allows an application program to be classified as client-server architecture is that at least one of its three components runs entirely on another computer, and the interaction between the components on different computers carried out through a particular network environment by transmitting requests to receive a particular resource.

Since client-server architecture is a special case of client-server technology, it necessarily has a client and a server. Accordingly, the client and server sides of the application are distinguished. Client side The application operates at the user’s workplace, which in the vast majority of cases is a personal computer. Server side operates on a specialized complex that includes powerful hardware, the required set of standard software, a database management system and the data structures themselves.

The interaction between the client and server parts of the application is carried out through a network - local or global. At the same time, from the point of view of the client and server, interaction is carried out transparently, respectively network component here includes a set of necessary network equipment, a set software technologies, providing data transfer between network nodes, as well as the actual protocol or protocols for exchanging requests and the results of their execution.

The application task visualization component provides information input by the user using certain means, as well as displaying information on the screen and printing. The visualization component for the client-server architecture is always executed at the user's workstation (since he must observe any results of the program).

The applied logic component actually solves one or another problem related to data processing in one or another subject area. This component can be distributed between the client and server in different ways depending on the model used.

The database storage component performs physical operations related to storing data, reading information from the database and writing to it. In a client-server architecture, this component always runs on the server.

In terms of quantity components client-server systems are divided into two-level and three-level

. Two-level systems consist only of a client and a server. IN three-level Between the user client and the server that stores and processes the database, a third, intermediate layer appears, which is a server for the user and a client for the database management system. This architecture allows for more flexible distribution of system functions and load between components of the hardware and software complex, and can also reduce resource requirements for user workstations. The necessary price for this is that such systems are much more difficult to develop, implement and operate and require significant costs and highly qualified personnel.

The third part examines an example of a three-tier structure Baikonur Server.

In the client-server architecture, there are several different application models, depending on the distribution of application components between the client and server parts. Historically, the very first was developed remote data access server model. In this model, the server part only stores data, and all application logic is implemented by the client part. In this case, the client will send requests to the server to obtain data, and the server will return certain samples to the client. The most common means of communication between client and server in this case is SQL ( structured language queries) is a standard non-procedural language focused on data processing.

In the remote data access server model, no application part of the system is executed on the server side, which can lead to underloading of the server and overload of the client. Therefore, it was subsequently proposed and then implemented database server architecture. In it, part of the application logic is implemented on the server using a special programming language, and part - on the client. This became possible thanks to the increased productivity of modern DBMS servers. Compared to the remote data access server option, in in this case the load is slightly reduced

on the client side, the intensity of network data exchange, and in some cases the application structure is simplified. Currently, this option for building systems is the most common.

Another option for client-server architecture is application server. In this case, the client performs only visualization and data entry operations, and the server implements all application logic. The exchange between the client and the server in such systems is carried out at the level of commands for displaying data on the screen and the results of user input. The most striking example of this architecture is the well-known web browser. Most often, in the application server model, the application logic and data management components are implemented separately.

Application server architecture is often referred to as "thin" client, unlike a traditional "thick" client implemented in a database server architecture. A thin client is an option that can be used when the resources available at users' workstations are insufficient to execute application logic. In addition, this technology allows you to reduce the cost of operating client components of the system due to their strong simplification.

Prerequisites for the emergence of client-server architecture in the enterprise

Computerization of an industrial enterprise can take place for quite a long time within the framework of the previously described local workplaces or architecture file server. However, sooner or later there may come a time when the only option for further development automated enterprise management systems will become the architecture client-server. Let's try to list main reasons why this becomes necessary.

Firstly, the client-server architecture becomes vital when the number of users simultaneously actively using the same data exceeds 10-15 people. Due to the fundamental limitations inherent in file server applications, such systems are difficult to tolerate with 15 concurrent users, and often fall apart with 20 users. Thus, if an enterprise is faced with the task of building a system in which the number of places simultaneously actively working with data exceeds 20, practically the only option for it is a client-server.

To be fair, it should be noted that large computers are also capable of handling tens or even hundreds of users. However, due to the high cost of hardware, the high cost of development, and, importantly, the considerable costs of operating such equipment and programs for it, the option of using a centralized architecture when introducing new systems in our country is almost never considered.

Another critical point for the transition to a client-server architecture is the transition to solving enterprise-scale problems and managing the enterprise as a whole. Automation of individual jobs can be successfully performed even without using network technologies, a file server can handle department-scale tasks, but building an integrated automated system covering the entire enterprise or at least one of the management subsystems is only possible using client-server technologies.

Another situation where client-server is the only way to build a system is when the automated system has remote users , with whom it is necessary to exchange information in real time. By real time scale we mean seconds-minutes here. Data exchange on floppy disks in this case is not suitable in principle, and the file server architecture will require very high speeds exchange, and this can be either fundamentally impossible or very expensive. Individual examples of wealthy organizations that built city-wide file server systems (for example, the Russian Inkombank) are exceptions that prove the rule.

And finally, client-server architecture is necessary when the task of ensuring information integrity becomes critical. By critical, we here mean a situation in which the cost of a data error can be comparable to the cost of creating a client-server system. First of all, this is relevant for financial services of enterprises.

An attempt to solve any of the problems listed above as part of the computerization of an industrial enterprise will necessarily entail the emergence of a client-server system. In addition, this architecture may emerge as a natural evolution of automated manufacturing control systems, even if the limitations of previous architectures in a given enterprise have not yet become critical. This option is the most preferable because, on the one hand, the implementation receives support from within, and, on the other hand, there is time to prepare a smooth change in the architecture of information applications.

Client-server architecture: Yes, but...

We have already talked about the advantages of client-server architecture. A natural question may arise: if it is so good, then why haven’t they switched to it yet? All large users information systems. It's actually not that simple.

First of all, for domestic industrial enterprises it is critical cost factor. Unlike Western enterprises, where, as a rule, we are talking about replacing rather expensive centralized systems with client-server ones, the direct costs of which are lower, domestic enterprises almost never had enough funds to implement large centralized systems. Very often, the information systems available in an enterprise are built on outdated hardware that requires complete replacement when moving to a client-server architecture.

The next big "but" is the large volume of technological changes themselves problems that arise when trying to implement a client-server architecture. A client-server system requires a different level of technical literacy on the part of both information service employees and end users. The costs of retraining users and operating personnel, restructuring the enterprise automation structure make up a larger part of the iceberg than the clearly visible direct costs of upgrading equipment, purchasing and/or developing the required software.

And finally, the biggest pitfall on the way to creating a CS system at an enterprise is the need change the management structure and associated organizational costs

An attempt to introduce new technological solutions without changing anything in the essence of automated business processes may end in vain. In this case, the enterprise will suffer direct material losses due to the large amount of expensive hardware and software lying dead weight, as well as due to the distraction of employees from performing their main job duties. IN best case scenario will be implemented separate areas client-server system, while actually new software will be used at the old ideological level.

If, after weighing all the pros and cons, the enterprise still decides to create a client-server system, then it faces the task component selection to build this system. Anyway necessary component is this or that database server corporate level. The remaining components depend on the path chosen by the enterprise for further development automated system management.

If the enterprise has decided develop the system yourself, then he is faced, first of all, with the task of choosing development tools. If the company places order for the creation of a system a specific development company, then it faces a similar task.

In the event that a decision is made not to develop the system ourselves, but to use one of the solutions available on the market, then the main component of the choice is ready-made (to one degree or another) enterprise automation system. In fact, the word "off-the-shelf" should be used very carefully, since it is difficult to draw a clear line between customization for the needs of a specific use and adaptation of the system, which often includes modifying system modules or even developing additional software to meet the needs of the customer.

DB, on structural language SQL queries (Structured Query Language), which is an industry standard in the world of relational databases. The remote server receives the request and forwards it to the SQL database server. SQL server – special program, which manages the remote database. The SQL server provides interpretation of the request, its execution in the database, generation of the result of the request and delivery of it to the client application. In this case, the resources of the client computer are not involved in the physical execution of the request; the client computer only sends a request to the server database and receives the result, after which it interprets it as necessary and presents it to the user. Since the result of the request is sent to the client application, only the data that the client needs “travels” through the network. As a result, the load on the network is reduced. Since the request is executed in the same place where the data is stored (on the server), there is no need to send large batches of data. In addition, the SQL server, if possible, optimizes the received query so that it is executed in the minimum time with the least overhead [[3.2], [3.3]]. the system is shown in Fig. 3.3.

All this increases system performance and reduces the time it takes to wait for a request result. When queries are executed by the server, the degree of data security is significantly increased, since data integrity rules are defined in the database on the server and are the same for all applications that use this database. This eliminates the possibility of defining conflicting rules for maintaining integrity. The powerful transaction engine supported by SQL servers makes it possible to prevent simultaneous changes to the same data by different users and provides the ability to roll back to the original values when making changes to the database that ended abnormally [[3.2], [3.3]].

Rice. 3.3. Client-server architecture

Exists local network, consisting of client computers, each of which has client application for working with the database.
On each of the client computers, users have the ability to run the application. Using the user interface provided by the application, it initiates a call to the DBMS located on the server to retrieve/update information. Used for communication special language SQL queries, i.e. Only the request text is transmitted over the network from the client to the server.
The DBMS initiates calls to data located on the server, as a result of which all data processing is carried out on the server and only the result of the request is copied to the client computer. Thus, the DBMS returns the result to the application.

Let's look at what the separation of functions between the server and client looks like.

Client application functions:
- Sending requests to the server.
- Interpretation of query results received from the server.
- Presenting the results to the user in some form (user interface).
Server side functions:
- Receiving requests from client applications.
- Interpretation of requests.
- Optimization and execution of database queries.
- Sending results to the client application.
- Ensuring a security system and access control.
- Database integrity management.
- Implementation of stability of multi-user operating mode.

So-called “industrial” DBMSs operate in the client-server architecture. They are called industrial because it is the DBMS of this class that can ensure the operation of information systems on the scale of a medium and large enterprise, organization, or bank. The category of industrial DBMS includes MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase and a number of others [[3.2]].

As a rule, a SQL server is maintained by an individual employee or a group of employees (SQL server administrators). They manage the physical characteristics of databases, perform optimization, configuration and redefinition various database components, create new databases, change existing ones, etc., and also issue privileges (permissions to a certain level of access to specific databases, SQL server) to various users [[3.2]].

Let's look at the main advantages of this architecture compared to the file-server architecture:

Network traffic is significantly reduced.
The complexity of client applications is reduced (most of the load falls on the server part), and, consequently, the requirements for the hardware capacity of client computers are reduced.
Availability of special software tool– SQL server – leads to the fact that a significant part of design and programming tasks has already been solved.
The integrity and security of the database is significantly increased.

Disadvantages include higher financial costs for hardware and software, and also that large number client computers located in different places, causes certain difficulties with timely updating of client applications on all client computers. However, the client-server architecture has proven itself in practice, in present moment There are a large number of databases built in accordance with this architecture.

3.4. Three-tier (multi-tier) client-server architecture.

Three-link (in some cases multi-link) architecture(N-tier or multi- three-tier architecture? Now, when business logic changes, there is no longer a need to change client applications and update them for all users. In addition, the requirements for user equipment are reduced as much as possible.

So, as a result, the work is structured as follows:

The database in the form of a set of files is located on the hard drive of a specially dedicated computer (network server).
The DBMS is also located on the network server.
There is a specially dedicated application server on which the business analysis software (business logic) is located [[3.1]].
There are many client computers, each of which has a so-called “thin client” installed - a client application that implements the user interface.
On each of the client computers, users have the opportunity to run an application - a thin client. Using the user interface provided by the application, it initiates a call to the business intelligence software located on the application server.
The application server analyzes user requirements and generates queries to the database. For communication, a special query language SQL is used, i.e. Only the request text is transmitted over the network from the application server to the database server.
The DBMS encapsulates within itself all information about the physical structure of the database located on the server.
The DBMS initiates calls to data located on the server, as a result of which the result of the query is copied to the application server.
The application server returns the result to the client application (user).
The application, using the user interface, displays the result of the queries.