RU2313824C2 - Information client-server system and method for providing graphical user interface - Google Patents

Abstract

FIELD: data transmission in computer networks.

SUBSTANCE: in accordance to the invention, expandable, usable with various client-server informational systems, system of dynamically created program objects is used, wherein program objects are divided onto a fixed number of categories, which are matched with predetermined program interfaces, where creation of request to server and processing of response from server represent predetermined chains of program object method calls.

EFFECT: reduced load on communication line in client-server system.

2 cl, 6 dwg

Description

FIELD OF THE INVENTION

The invention relates to data transmission in computer networks and can be used in distributed information systems.

Common Terms

Client-server information system - a distributed information system consisting of a server computer and one or more client computers, in which each client is connected to the server by a communication line. Currently, the Internet environment is most commonly used as communication lines. The main work in the client-server system is performed by the computer-server. The user of the information system interacts with the client computer.

Request - a sequence of signals sent over a communication line from a client computer to a server computer. Request signals determine exactly what actions the server should perform, as well as the nature of the data that the client expects from the server.

A response is a sequence of signals sent over a communication line from a server computer to a client computer. The response contains data for the client.

Software object - in a certain way organized set of signals in the computer's memory. Software objects are created and used in the process of computer operation in accordance with the algorithms of object-oriented programming. Each program object has a specific set of methods and is characterized by a set of object properties. Software objects interact with each other, calling each other's methods. Typically, interaction occurs through event handlers.

An object method is in a certain way an organized collection of signals in the computer's memory. A method call drives these signals. A method can return data resulting from the execution of a method.

Property of an object is a characteristic of an object that contains data from one of the predefined types. Writing and reading properties are carried out through calls to the corresponding methods of the object.

Events - user actions or any other changes in a computer system.

The configuration of a software object is a specific set of property values for this object.

Description of a software object - data transmitting the configuration of a software object. Various binary or text formats can be used to describe program objects.

Version of the description of the program object - additional data related to the description of the program object, allowing to distinguish between the configuration options of the object.

An interface (software) is a specific set of methods and properties. To support a software interface, an object must have all the methods and properties related to this interface.

The behavior of an object is the reaction of an object to events in the system, depending on its configuration. Software objects initially have some behavior, that is, depending on the configuration of the object with a predefined reaction to events in the system.

Event handler - a certain way organized set of signals in the computer's memory, executed in response to the onset of a specific event in a computer system. Event handlers largely determine the behavior of software objects. They modify the initial behavior of objects, are a means of individualizing this behavior, and usually provide interactions between objects.

A script is text containing a program in one of the programming languages embedded in a web page or other document. Event handlers can be implemented by dynamically converting (interpreting) script text into a set of signals corresponding to an event handler.

Web application - a client-server information system that uses a web browser as a client program. The behavior of program objects in the client part of a web application is specified using scripts embedded in web pages.

Thin client architecture - in accordance with this concept, the client program (the so-called “thin client”) only displays user interface elements, and all user interface events are processed on the server. This creates an additional (in addition to the usual requests and responses in the client-server system) load on the communication line.

Caching - saving web pages and other documents on a computer-readable storage medium of a client computer with the aim of reusing them and reducing due to this the load on the communication line. In web applications, the web browser caching mechanism usually has to be disabled, as it can prevent data from being updated (leading to erroneous use of outdated stored data).

Hashing is a type of encryption without the possibility of decryption (unidirectional encryption).

User authentication - a procedure that is performed when a user connects to the system, when the user verifies his user rights using a conditional name and password.

User authorization - the procedure for confirming the user's authority in the process of the information system.

Terms coined by the inventor

A self-contained object is a software object that does not require any event handlers for its functioning. Self-contained software objects are able to function adequately only as part of a particular system.

A system of self-contained objects is a certain way organized system of software objects, in which the relationship between them is determined solely by the configuration of these objects. The relationships between self-contained software objects established in a certain way allow the system to function adequately without the use of event handlers in any form, including without the use of scripts. The mechanism of functioning of the system of self-contained software objects is described below.

State of the art

Currently, client-server information systems are widely used. A person, a user of the client-server information system, interacts directly with the client computer. In response to user actions (for example, keystrokes or mouse clicks), the client computer running the client program sends request signals to the server computer via the communication line. The client program provides a user interface on the client computer and converts user actions into request signals to the server.

The computer server is running a server program. Upon receipt of the request signals, the server, in accordance with the request, performs some transformations of data stored on computer-readable media, selects data from the same or other computer-readable media, and sends these data over the communication line in the form of corresponding signals to the client computer. Upon receipt of the response signals, the client computer presents the data received from the server to the user in a convenient form and, if necessary, writes part or all of the received data to the computer-readable storage medium of the client computer. The exchange of request signals and response signals in the system continues as long as it is necessary for the user to solve a specific problem. In addition to the computer, the role of the client can be played by a mobile phone or other communication device that is running a client program.

Thus, for the functioning of the client-server information system, two programs are needed - server and client. Typically, the server program has access to information resources in the form of databases and performs the main work in the client-server system. The client program does a small part of the work, providing a user interface and querying the server.

Many information systems use web browsers as a client program, such as Microsoft Internet Explorer, Mozilla or Opera, that is, these information systems are web applications. Unlike websites that provide the user with a predefined set of web pages, the web application is interactive and provides web pages created dynamically according to the user's request. The strength of web applications is the versatility of the client program. The web browser is installed on the client computer once, often during the installation of the operating system. It can then be used as a client program in a wide variety of web applications. This eliminates the need to install specialized client programs for each individual web application. In a web application, the logic of the information system and the way information is presented to the client is entirely determined by the server side. Therefore, quite frequent changes in this logic and methods of presenting information do not require any changes in the client program.

However, web application capabilities are limited. This is due to the rather poor user interface features provided by the web browser. Recently, attempts have been made to improve the user interface of web applications based on the XForms [XForms 1.0 (W3C Recommendation) http://www.w3.org/TR/xforms/] and WebForms 2.0 [WebForms 2.0 (Working Draft) specifications http: / /whatwg.org/specs/web-forms/current-work/]. Nevertheless, the new specifications do not allow us to bridge the gap separating the user interface of web applications from the much more advanced graphical user interface provided by Windows, MacOS, XWindow, Java, etc. Therefore, in cases where a distributed information system needs a developed graphical user interface interface, developers are forced to create specialized client programs that are "native" to this client platform, that is, based on programmer interfaces applications of a specific client platform. In this case, each information system requires its own client program, each change in the logic of the information system or the methods for presenting information to the user requires updating the client program (reinstalling it on the client computer). Sending and reinstalling new versions by the client of the program causes an additional load on the communication line, creates significant inconvenience for users, leads to additional financial costs.

The objective of this invention is to create a technology (system and method) for developing client-server information systems with a developed graphical user interface in which business logic and methods for presenting information are entirely on the server side, and the client part is represented by a universal program that does not require reinstallation for each individual applications. At the same time, the functioning of the graphical user interface, that is, the adequate interaction of the user interface objects with the user and with each other, should occur exclusively on the client computer without accessing the server. The technical result of the invention should be the elimination of additional load on the communication line, which creates the transfer of installation packages and updated versions of client programs.

Known methods for providing a developed graphical user interface of a web application by introducing ActiveX or Java applets into web pages [X. Deitel, P. Daytel, T. Nieto. How to program for the Internet & WWW. M. Binom, 2002, 1184 pp.]. However, these methods do not solve the problem, since the corresponding implemented components are not universal (specialized components are required for each web application) and require updating when changing the logic of the information system or changing the way information is presented. The same applies to the new Java Web Start Technology [Java Web Start Technology, http://java.sun.com/products/javawebstart/], which is designed to improve Java applets.

Known implementation options for the client-server information system in the architecture of the "thin client" [US 2002130900; US2003135825]. According to [US 2002130900; US 2003135825] user interface objects are created dynamically, according to descriptions in the XML structural markup language, received from the server. This allows you to reduce the load on the communication line due to the universal nature of the client program. However, the additional load on the communication line due to the processing of client events on the server negates this advantage.

The closest analogue of the present invention is [WO 2004019160]. In [WO 2004019160] it is proposed to create user interface program objects on a client computer dynamically based on descriptions received from the server in any structural markup language (XML, XSL, DHTML, XHTML, HTML). Individualization of the behavior of program objects of the user interface is achieved using scripts in the JavaScript language. It is believed that such systems can have the property of extensibility, that is, objects of new types can be added to the system as necessary. However, for a script to work, it is usually necessary to specify an object model - a set of predefined object types (classes, in the terminology of object-oriented programming), which contradicts the principle of extensibility. These proposals have not yet received distribution, possibly because of this contradiction and the complexity of implementing a universal script support mechanism.

Disclosure of invention

In the invention, the problem is solved by using on the client side a universal system of dynamically created, self-contained software objects and organizing the operation of the client-server information system in accordance with a certain algorithm. Same as in [US 2002130900; US2003135825; WO 2004019160] in this invention, program objects on a client computer are created dynamically from their descriptions received from the server, but in this invention, user interface objects are not embedded in a web browser, but function as part of a universal client program. In contrast to [US 2002130900; US 2003135825] in this invention, the server is not required to function as a user interface. Unlike [WO 2004019160], the present invention does not require the support of a scripting mechanism for the operation of the system. The use of a system of self-contained software objects in this invention eliminates the complexity of implementing a universal script support mechanism. For the implementation of the present invention, the format used to describe self-contained objects is not of fundamental importance.

Unlike commonly used program objects, whose behavior is largely determined by event handlers, the behavior of a self-contained program object is entirely determined by its configuration, that is, by a set of property values for this object. The reaction of a self-contained program object to events in the system depends on the configuration of the object, but with each specific configuration it is predetermined and cannot be modified using event handlers.

How can an adequate interaction of a wide variety of objects be ensured if a modification of their behavior is not expected? For this, in the invention, objects on the client side are combined into a system of self-contained software objects, the operation of which takes into account the unified nature of the interactions of objects within the client-server system.

Brief Description of the Drawings

Figure 1 explains the functioning of the system of self-sufficient objects in the case of a request for modification and receipt of data.

Figure 2 presents the block diagram of the algorithm when requesting modification and receipt of data.

Figure 3 explains the functioning of the system of self-contained objects when requesting a new container. For simplicity, the caching mechanism is not shown in this diagram.

Figure 4 presents the block diagram of the algorithm when requesting a new container without a caching mechanism.

5 illustrates a caching mechanism when requesting a new container.

Figure 6 presents a block diagram of the caching algorithm when requesting a new container.

7 illustrates an example of a window form for credit card payments.

On Fig presents a block diagram of the algorithm when making payments on credit cards.

Figure 9 presents the block diagram of the algorithm for full or selective encryption of the request.

Figure 10 presents the block diagram of the algorithm for full or selective decryption of the response.

Figure 11 presents a block diagram of the algorithm for launching a universal client program.

The implementation of the invention

All self-contained objects in the system are divided into several categories. The belonging of an object to one or another category determines its role and behavior in the system. In the system of self-sufficient objects, the following categories of objects are provided:

- Containers - designed to combine self-contained objects into groups. In the user interface, these objects are presented in the form of window forms and various grouping panels. The purpose of the container object is to have access to all self-contained objects that it combines in order to transmit data received from the server to them or to receive data from them to form a request to the server. The container description includes descriptions of all objects related to it, including other containers. Any self-contained object (with the exception of window forms) is part of a container. Window forms exist independently, being top-level containers.

- Initiators - buttons, menu items and other objects that can initiate a request to the server based on user actions (keystrokes or mouse clicks).

- Recipients - labels, input lines, text areas, lists, tables, charts, and other objects that can receive and possibly display data received from the server.

- Interrogators - input lines, text areas, lists, tables and other objects capable of providing the data contained in them to form a request to the server.

- Decorators - pictures and other graphic design elements that are not able to interact with the user. Decorators do not affect the operation of the information system, their presence or absence determines exclusively the appearance of window forms.

- Intermediaries - special self-sufficient objects, which are a link between objects of other categories.

Some self-contained objects can belong to several categories at once, for example, at the same time be interrogators and recipients.

The belonging of an object to a certain category requires the presence of attributes mandatory for this category, that is, support for the corresponding interface.

We list the minimum sufficient set of methods and properties of the interfaces of the corresponding listed categories of self-sufficient objects.

Initiator Interface:

- the Reseller property - determines which intermediary will be activated with the help of this initiator.

Intermediary Interface:

- the Container property - defines the container that will participate in the formation of the request;

- RequestType property - determines the nature of the request. The minimum set sufficient for the system to work includes the following types of requests: request for a new container; request data for an existing container; a request modifying the data on the server with the subsequent receipt of data from the server; a request that modifies data on the server without subsequently receiving any data from the server; several query options for user authentication;

- the ContainerName property - determines which container is required (if a new one is requested) or for which container the data is requested;

- property ServerAddress - contains the network address of the server that implements the information system;

- the Go method - brings the intermediary into action.

Interrogator Interface:

- the method GetRequest - returns the part of the request that corresponds to this requestor.

Recipient Interface:

- SetData method - transfers the corresponding data to a specific recipient.

Container Interface:

- the method Generate Request - returns a full request to the server. When this method is called, the container iterates over all related requestor objects and calls the Get Request method for each requestor, forming a complete request from the received parts.

- the Distribute Data method - iterates over all recipient objects related to the container, calls the Set Data method for each, and thus transfers the corresponding data to each specific recipient.

Decorator interface is not required.

All self-contained objects must have the Name property, the value of which identifies them.

When requesting new containers, a special caching mechanism can be used, which provides an additional reduction in the load on the communication line. The listed set of methods and properties of interfaces does not include the properties necessary to protect data by fully or selectively encrypting requests and responses and storing cached object descriptions in encrypted form (see below).

Let us follow in figure 1 the interaction of the client and server in the case of a request for modification and receipt of data (block diagram of figure 2).

Legend: 1 - server, 2 - client, 3 - client program, 4 - request generation stage, 5 - response processing stage.

Sequencing:

- User 6 activates the Initiator 7 (button, menu item, etc.) (block 21).

- Initiator 7 calls the Go method for Intermediary 8 (block 22).

- The broker 8 for Container 9 calls the Create Request method (block 23).

- The container 9 interrogates the self-contained requestor objects related to it (cycle, blocks 24-26), calling the Get Request method (block 24) for each of them, forms a request from the parts corresponding to the requestors (block 25), and returns the generated request to Intermediary 8 (block 27). (Block 26 checks the condition - are all interrogators processed?)

- The intermediary 8 forwards the request to the Server Program 10 at the address Server Address (block 28).

- Server Program 10 modifies data in Database 12 (block 29), requests and receives data from Database 12 (block 30).

- Server Program 10 converts the data to the desired format (block 31) and sends them to the Intermediary 8 (block 32).

- The intermediary 8 transfers the received data to the already existing Container 13, calling the Distribute Data method (container 13 may coincide with the original container 9) (block 33).

- The container 13 distributes the received data between related self-sufficient recipient objects (cycle, blocks 34-35), calling the Set Data method for each recipient (block 34). (Block 35 checks the condition - are all recipients processed?)

In Fig.3 we will trace the interaction of the client and the server when requesting a new container (without caching) (block diagram of Fig.4).

Sequencing:

- User 6 activates the Initiator 7 (button, menu item, etc.) (block 41).

- Initiator 7 calls the Go method for Intermediary 8 (block 42).

- Broker 8 for Container 9 calls the Create Request method (block 43).

- The container 9 polls the related self-contained requestor objects (cycle, blocks 44-46) related to it, calls the Get Request method (block 44) for each of them, forming a request from the parts corresponding to the requestors (block 45), and returns the generated request to Intermediary 8 (block 47). (Block 46 checks the condition that all requestors are processed)

- The intermediary 8 forwards the request to the Server Program 10 at the address Server Address (block 48).

- Server Program 10 finds and reads the description of the new container located on the Server Machine-readable Storage Media 11 (block 49).

- The server program 10 sends the description of the new container to the Broker 8 (block 50).

- The intermediary 8 on the received description creates a New Container 14 (block 51).

- The broker 8 sends a second request to the server, now to receive data for the New Container 14 (block 52).

- Server Program 10 requests and receives data from Database 12 (block 53).

- Server Program 10 brings the data to the desired format and sends it to the Intermediary 8 (block 54).

- The broker 8 transfers the received data to the existing New Container 14, calling the Distribute Data method (block 55).

- The container 14 distributes the received data between the related self-sufficient recipient objects (cycle, blocks 56-57), calling the SetData method for each recipient (block 56). (Block 57 checks the condition - are all recipients processed?)

Let us follow in FIG. 5 the operation of the caching mechanism when a new container is requested (block diagram of FIG. 6).

Initially, until the Intermediary 8 receives from the Container 9 the generated request, the actions are performed in accordance with figure 3 (blocks 41-47 of figure 4). The following actions are performed:

- Intermediary 8 searches on the Client Machine-readable Storage Media 15 for a description of the new container and a version of this description (block 61). If the description and its version are present on the client computer (block 62), the intermediary 8 includes in the request a version of the description (block 63).

- The intermediary 8 forwards the request to the Server Program 10 at the address Server Address (block 64).

- Server Program 10 finds and reads the description of the new container and the version of the description located on the Server Machine-readable Storage Media 11 (block 65).

- Server Program 10 compares the versions of descriptions from client 15 and server 11 machine-readable storage media (block 66). If the versions of the descriptions match, then the Server Program includes the corresponding attribute in the response (block 67). In this case, the description and its version are not sent to the client computer. If the versions do not match or the description version is not in the request, the Server Program includes the description and its version in the response (block 68).

- The server program 10 forwards the response to the Intermediary 8 (block 69).

- Intermediary 8 analyzes the response. If there is no sign of version coincidence (block 70), then the Intermediary saves the received description and its version on the client Machine-readable Data Carrier 15, replacing the existing description and its version if necessary (block 71). Otherwise, the existing description is used (block 72).

- The intermediary 8, according to the description (possibly just received), creates a New Container 14 (block 73).

- Next, the actions are performed in accordance with figure 3 to obtain data for a new container (blocks 52-57 of figure 4).

If there is no change in the logic of the information system or the way of presenting data for the next session, the container descriptions will be read from the client computer-readable data carrier. Only versions of container descriptions and signs that descriptions have not changed will be transmitted over communication lines. If it is necessary to make changes in the logic of the information system or in the way of presenting information, in addition to changes in the operation of the server program, it is enough to make changes to the descriptions of the respective containers stored on the server computer-readable medium and change the versions of these descriptions. In this case, the descriptions of the respective containers stored on the client machine-readable medium will be updated in a subsequent work session. Thus, the caching mechanism, on the one hand, allows you to quickly update the logic of the information system and how to present information, and on the other hand, reduces the load on the communication line due to the fact that the description of each container is updated only if necessary.

The possibility and necessity of using the caching mechanism for container descriptions is related to the fact that these descriptions can remain unchanged for many work sessions. For data coming from the server to self-contained recipient objects, caching is not used, since this data can change even during one working session.

As indicated above, for the web applications to work properly, you usually have to disable the caching mechanism that exists in web browsers. This is because the HTTP protocol and the HTML markup language used in web applications do not distinguish between data that changes frequently and data that does not change often. Therefore, the caching mechanism of the web browser can prevent data from being updated and lead to the erroneous use of obsolete stored data. Disabling the caching mechanism in web applications leads to a complete reload of web pages with each request. This creates an additional (significant and unreasonable) load on the communication line when running web applications.

1-6 illustrate interactions within a system of self-contained objects. We examined two types of queries. Algorithms for executing requests of other types do not have fundamental differences from the considered algorithms. The functioning of the system makes full use of the request-response mode, which is characteristic of any client-server system. It is the functioning of the information system in this mode that allows us to build universal sequences of actions. It is important to note that the considered sequence of actions can be performed without involving any event handlers, including those based on scripts.

To successfully participate in the execution of the request and receive the response, it is enough to correctly configure the system of self-sufficient objects, that is, correctly set the values of their properties. In particular, in the case of the query shown in FIG. 1, a number of properties must be correctly set for objects:

- at Initiator 7, the Mediator property must indicate the Mediator 8 participating in the request;

- in the Intermediary 8, the Container property should point to the Container 9 that forms the request; the RequestType property must match the type of request; the ContainerName property must match the name of Container 14 for which data is requested; the ServerAddress property must contain the relevant data;

- The container 9 should include all the objects necessary for the formation of the request, with correctly installed configurations.

All the data necessary for configuration can be contained in the description of Container 9 (in this case, both Initiator 7 and Intermediary 8 are contained in Container 9). The configuration of objects is performed by the intermediary who created them, immediately after their creation based on the description of the container containing them.

To participate in the system, a self-sufficient object is necessary and sufficient to maintain an interface corresponding to its category. Due to this circumstance, the proposed system can easily be replenished with new self-sufficient objects, that is, it is expandable. Self-contained objects supplementing the system can be placed in files of dynamically loaded libraries on a computer-readable storage medium of a client computer. After writing a dynamically loaded library to a computer-readable storage medium of a client computer, the self-contained objects contained in it can be used in a wide variety of information systems. Thus, the expansion of the system of self-sufficient objects requires only a single transfer via communication lines of small dynamically loaded libraries in volume.

Let us now consider the interaction of the system of self-sufficient objects with the user. The nature of this interaction, as well as their interaction within the system, is completely determined by the configuration of self-contained objects. Self-contained objects are perceived by the user of the information system as elements of a graphical user interface. At their core, they must provide an advanced graphical user interface that is specific to the Windows, MacOS, XWindow, or Java client platforms. Therefore, they are created on the basis of application programming interfaces of a specific client platform. Adequate behavior of user interface objects involves:

- a set of restrictions on the input of information corresponding to the current use of objects;

- warning the user about his inappropriate actions;

- mutual consistency of objects.

We show how all these functions can be implemented without the use of event handlers, solely by configuring the configuration of self-contained objects. Consider an example. Fig. 7 schematically shows a window form 101 for credit card payments (not all required fields are shown for simplicity). Drop-down list 102 is a specialized object containing a list of supported credit cards, for example: VISA, American Express, Golden Crown, etc. Input fields 103-107 are intended for entering the corresponding digital and alphabetic data: 103 - credit card numbers, 104 and 105 - months and expiration dates of the credit card, 106 - payment amounts and 107 - name of the card holder. Objects 102-107 are interrogators. Buttons 108 and 109 initiate the operation of sending a request to the server and closing the window form, respectively. The figure does not show an intermediary that is present in the container 101, but is invisible to the user. For the reseller, the Container property should point to the window form 101. At the button 108, the Reseller property should point to the existing intermediary.

We show how restrictions on inputting information can be implemented. For input fields, restrictions can be associated with the ContentType and MaximumLength properties. The MaximumLength property determines the maximum possible number of characters entered. The ContentType property determines which characters can be entered in a string. So for input lines 103-105, the ContentType property should be set to Integer. This type of content only accepts numeric characters. For input line 106, the ContentType property must be set to Cash. This type of content allows only numeric and decimal separator characters (periods or semicolons, depending on regional settings). Other input fields are configured similarly. In the process of entering characters, the input line object checks that the entered characters match the value of the ContentType property and ignores invalid characters. It is important that input control is performed by the object itself, and not by an event handler external to the object.

We show how user warnings about his inadequate actions can be implemented (block diagram of Fig. 8). In this case, typical inadequate user actions are blank input fields or an unselected type of credit card. When the user presses the button 108, the actions are performed in the following order:

- Button 108 activates the intermediary (calls the Forward method for the intermediary) (block 81).

- The intermediary calls for the container 101 (indicated by the Container property) the Create Request method (block 82).

- The container 101 iterates over related self-contained requestor objects 102-107 (cycle, blocks 83-86), calling the Get Request method (block 83) for each of them. (Block 86 checks to see if all requestors are processed.)

- When you call the Get Request method for the drop-down list 102, the user actions are checked for adequacy (block 84). In this case, did the user choose the type of credit card. If the user has not selected the type of credit card, which is an inadequate action, the program is interrupted, the drop-down list opens a message box for the user (block 85) with the text “No type of credit card selected”.

- When calling the Get Request method for each of the input lines 103-107, each line independently checks the adequacy of user actions (block 84). For input lines, this means checking if this field is filled. If the user does not fill in the input line 103, which is an inadequate action, the program is interrupted, the input line 103 opens a message box for the user (block 85) with the text “The field“ Credit card number ”is not filled. (The text "Credit card number" should be contained in the Name field property of input line 103.)

- If all the fields are completed, then the steps are taken to obtain a new container - a window form with the results of the payment (blocks 47-57).

Each time the program stops, the user must make the necessary adjustments and press the button 108 again. It is important that the control of inadequate user actions and a message about this are performed by the object itself, and not by an event handler external to the object.

We show how mutually consistent behavior of self-contained objects can be realized. In this example (Fig. 7), the number of digits in the credit card number (input line 103) depends on the type of credit card selected in the drop-down list 102. For example, a VISA credit card number can consist of 13 or 16 digits, a credit card number American Express 15 digits, Dinners Club card number 14 digits, etc. In addition, the correct credit card numbers are subject to rules specific to each particular type of card. Therefore, it is precisely the objects 102 and 103 that must act in concert. To solve this problem, the credit card number entry line must have the List of Credit Cards property pointing to list 102. In this case, during the input process, the acceptable number of entered digits can be consistent with the type of credit card selected in list 102, and when you call the Get Request method for input lines 103, you can check the correspondence of the entered number to the type of credit card using the appropriate algorithm. If the entered number does not match the type of credit card, the user can be warned with a corresponding message. It is important that this work is performed by the input line object itself, and not by the event handler.

Thus, we have shown how, without the use of event handlers, adequate behavior of user interface objects can be ensured.

The sequences of actions considered above form, in essence, the basis for the original protocol of the client-server information system, which can be formulated after they are formalized. This protocol can be run on top of well-known network protocols such as TCP / IP, HTTP, HTTPS, SOAP [X. Deitel, P. Daytel, T. Nieto. How to program for the Internet & WWW. M. "Binom", 2002, 1184 pp.] And others, for example, data transfer protocols in mobile networks. The choice of a basic network protocol is not critical and affects only the implementation features. Choosing a higher level protocol (for example, HTTP compared to TCP / IP or SOAP compared to HTTP) simplifies the implementation process. On the contrary, the choice of a low-level protocol will make the transmitted data packets more compact and reduce the amount of data sent over communication lines.

Let us dwell briefly on issues related to authentication and user authorization. We will distinguish three levels of authentication:

- The simplest case, when the information system provides open access to everyone and authentication is not required, refers to the zero level. In this case, the login request does not contain any user information.

- If the client and server communicate over a secure connection (for example, HTTPS is selected as the base protocol), then the username and password can be transferred via the communication lines to the server directly in the authentication request. In this case, a single request is sufficient for authentication (first level).

- If an insecure connection is used, it is impossible to transmit the password over the communication line in the open or even hashed form. In this case, authentication will require two requests (second level) and can be carried out in two stages, such as digest authentication or Kerberos protocol [Joel Skambrej, Mike Shema Secrets of hackers. Web application security - ready-made solutions, M. "William", 2003, 383 pp.].

In any case, successful authentication means allocating a unique session identifier to the user. At the zero authentication level, the session identifier is allocated to the user without checking the name and password. In the process of further work of the information system, the session identifier can be included in all requests for data and containers, thus, at each request, user authorization is performed.

If a protocol without data encryption, such as TCP / IP or HTTP, is used as the basic network protocol, then data protection, in the form of full or selective encryption of requests and responses, can be built directly into the system in question. For this, it is necessary that the Interrogator, Recipient, and Container interfaces include the following properties:

Interrogator Interface:

- the encrypt property Request is set if the part of the request corresponding to this requestor should be encrypted.

Recipient Interface:

- the DecryptResponse flag property is set if the part of the response corresponding to this recipient should be decrypted.

Container Interface:

- the flag property Encrypt Full Request is set if the entire request should be encrypted

- the decrypt All Response flag property is set if the entire response should be decrypted.

Encryption algorithms can be implemented as dynamically loaded libraries. Various algorithms can be used to fully and / or partially encrypt requests and decrypt responses. Thus, up to 4 different encryption algorithms can be used simultaneously.

We will show how it is possible to perform full and / or partial encryption when generating a request (block diagram of Fig. 9). When calling the Generate Request method (block 121), the container polls the self-contained requestor objects related to it (cycle 122-126), calling the Get Request method (block 122) for each of them. If the requestor has the EncryptQuery property set (block 123), the container encrypts this part of the request (block 124) using a dynamically loaded library and includes it in the full request (block 125) in encrypted form. Block 126 checks whether all interrogators have been processed. If the Encrypt Full Request property is set on the container (block 127), then the generated request is additionally encrypted (block 128) before being sent to the server (block 129).

We show how you can perform full and / or partial decryption when receiving a response from the server (block diagram of figure 10). When calling the Distribute Data method (block 141), if the container has the Decrypt All Response property set (block 142), the container decrypts the response received from the server (block 143) using a dynamically loaded library. The container distributes the received data between the self-contained recipient objects related to it (cycle, blocks 144-148), calling the Set Data method for each recipient (block 144). If the Decrypt Response property is set for a specific recipient (block 145), the container decrypts the data (block 146) using the dynamically loaded library intended for this recipient before calling the SetData method (block 147). Block 148 checks to see if all recipients are processed.

Encryption keys can be obtained from the server during user authentication using the Kerberos protocol [Joel Skambray, Mike Shema, Secrets of hackers. Web application security - ready-made solutions, M. "William", 2003, 383 pp.]. These keys are valid for one working session.

Similarly, encryption of data containing container descriptions can be arranged. In this case, the container descriptions should be transmitted over the communication line and stored in an encrypted form on a client computer-readable storage medium. Responsibility for decrypting descriptions may be assigned to the intermediary. The need for decryption can be indicated by setting the broker property DecryptContainerDescription. The session key cannot be used to decrypt the description of the container, since this description can be read from the client machine-readable storage medium repeatedly, during several working sessions. The user password can be used directly or in the hashed form as a key for decrypting the container description.

Let us now consider the operation of a client computer running a universal client program based on a system of self-contained software objects.

A universal client program should include a rich set of self-contained objects that can satisfy the needs of most business information systems. The inclusion of an object in the system means that objects of this type can be created and configured based on their descriptions. Those few information systems for which a standard set of self-sufficient objects will not be enough can be replenished with additional objects contained in dynamically loaded libraries.

To start a specific application, the client program needs to have the following data:

- network address of the application server;

- The method of user authentication adopted in this application;

- name of the first container, that is, the container requested immediately after user authentication;

- a list of dynamically loaded libraries with self-contained objects that complement the system (if necessary);

- A list of dynamically loaded libraries with algorithms for full or partial encryption of requests and responses (if necessary).

This data may be stored in an application initialization file on a client computer-readable medium. Consider the sequence of actions at the beginning of a client computer session running a universal client program (flowchart of Fig. 11):

- data on the application server address, authentication method, name of the first requested container and file names of dynamically loaded libraries are read from the initialization file on a computer-readable storage medium of the client computer (block 161);

- if the list of file names of dynamically loaded libraries is not empty (block 162), then dynamic libraries with additional self-contained objects and libraries with encryption algorithms are loaded (block 163);

- to perform authentication requests, an intermediary object is created and configured (block 164);

- if the user authentication method requires the introduction of a username and password (first and second levels) (block 165), then a special window form is created and then displayed on the monitor screen containing the name and password input lines and the system enter button (block 166) ;

- if zero level authentication is used, then the login request is executed without any user actions (block 167);

- if authentication of the first or second level is used, then authentication is performed after the user enters the username and password and presses the login button using, respectively, one or two requests (block 168);

- in case of successful authentication (block 169), the existing intermediary requests, by a known name, the first created container (first window form) (block 170);

- the intermediary creates and configures the first window form according to the received description (block 171);

- Further work of the information system follows a path that is determined by the contents of the first window form. This form must contain intermediaries requesting other window forms. Thus, the logic of the further operation of the information system is completely determined by the server (in particular, through the description of the first window form received from the server) (block 172);

- the user’s work with the information system ends after he closes the first window form (block 173).

Thus, we showed how a client computer running a universal client program based on a system of self-contained software objects can perform work whose logic is completely determined by the server. Due to the universality of the client program, it can control the operation of the client computer in a wide variety of information systems, providing an advanced graphical user interface. You do not need to reinstall the client program to work in other information systems, as well as when changing the logic of work and methods of presenting data. This leads to the achievement of the necessary technical result - to reduce the load on the communication line due to the exclusion of the additional load created by sending installation packages and updated versions of client programs. The load on communication lines specific for client-server systems in the thin client architecture is also excluded.

Although the present invention is described by way of examples of its implementation, the scope of the present invention is not limited to these examples, but is determined only by the claims taking into account possible equivalents.

Claims (12)

1. An information system consisting of a server and one or more clients connected to the server by a communication line in which the server performs the modification and selection of data, and the clients perform requests to the server for modification and selection of data and provide a developed graphical user interface that differs using on each client an expandable, suitable for a variety of information systems, client - server system of dynamically created program objects, in which program objects are divided They are assigned to a fixed number of categories, and they are assigned predefined program interfaces, and the formation of a request to the server and the processing of the response from the server are predefined chains of calls to methods of program objects. 2. The information system according to claim 1, characterized in using TCP / IP as the base network protocol. 3. The information system according to claim 1, characterized in that it uses HTTP and HTTPS as the basic network protocols. 4. The information system according to claim 1, characterized in that it uses the SOAP protocol over the HTTP and HTTPS network protocols as the base one. 5. The information system according to claim 1, characterized in support on the server side of the session protocol with authorization by session identifier. 6. The information system according to claim 1, characterized in the application of user authentication according to the type of digest authentication. 7. The information system according to claim 1, characterized in the application of user authentication via the Kerberos protocol. 8. The information system according to claim 1, characterized in using a caching mechanism for descriptions of self-contained objects. 9. The information system according to claim 1, characterized in using full and / or selective encryption of requests and responses using session keys. 10. The information system according to claim 1, characterized in using descriptions of self-contained objects transmitted over communication lines and cached on a client computer-readable storage medium in encrypted form. 11. The information system according to claim 1, characterized in that the radio and mobile networks are used as communication lines, and cell phones are used as clients. 12. The method of providing a graphical user interface on a client computer in a client-server information system in which, using an initiator object to indicate an intermediary object, initiates the formation of a request to the server by an intermediary object designed to communicate between objects, determine a container object intended for combining requestor objects into groups participating in the formation of a request; in a container object, polling of requestor objects is carried out, including the control of data entry, which determines whether the data contained in the requestor objects matches the maximum length that determines the maximum possible amount of data entered, and the type of content that determines which characters can be entered, while the data does not correspond to those mentioned the maximum length and type of data are ignored, and if the requestor object does not contain any data, the program is interrupted and the user is given a message that he did not enter the necessary data e, the requestor objects represent the data on the basis of which they form a request to the server, which is returned to the intermediary object, with the help of which it forwards the request to the server, on the basis of which the data is received from the server database, with the help of which they are converted to the desired format and sent to the intermediary object, by means of which the data received from the server is transferred to another container object, which distributes the data between the recipient objects related to it, intended for receiving and displaying data in de GUI.

Images