[go: up one dir, main page]

WO2007001206A1 - Client-server information system and method for presentation of a graphical user's interface - Google Patents

Client-server information system and method for presentation of a graphical user's interface Download PDF

Info

Publication number
WO2007001206A1
WO2007001206A1 PCT/RU2005/000394 RU2005000394W WO2007001206A1 WO 2007001206 A1 WO2007001206 A1 WO 2007001206A1 RU 2005000394 W RU2005000394 W RU 2005000394W WO 2007001206 A1 WO2007001206 A1 WO 2007001206A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
client
information system
objects
self
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/RU2005/000394
Other languages
English (en)
French (fr)
Inventor
Mikhail Vasilyevich Belyaev
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to EP05851084A priority Critical patent/EP1914636A4/en
Priority to US11/996,860 priority patent/US20080208964A1/en
Priority to PCT/RU2005/000394 priority patent/WO2007001206A1/ru
Priority to JP2008523837A priority patent/JP2009508184A/ja
Publication of WO2007001206A1 publication Critical patent/WO2007001206A1/ru
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Definitions

  • the invention relates to data transmission in computer networks and can be used in distributed information systems.
  • Client-server information system is 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.
  • client-server system 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.
  • the configuration of a software object is a specific set of property values for this object.
  • 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.
  • “Keyword” 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.
  • 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.
  • 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 using scripting.
  • the mechanism of functioning of the system of self-contained software objects is described below.
  • client-server information systems are widely used.
  • a person a user of the client-server information system, directly interacts with the client computer.
  • the client computer running the client program sends request signals to the server computer via the communication line.
  • the client program provides the user interface on the client computer and converts user actions into request signals to the server.
  • the computer server is running a server program.
  • the server Upon receipt of the request signals, the server, in accordance with the request, performs some transformations of the 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.
  • 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 for as long as it is necessary for the user to solve a specific problem.
  • the role of the client can be played by a mobile phone or other communication device that is running a client program.
  • 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.
  • web browser programs are used, such as Microsoft Excel Internet Explorer, Mozilla or Orera, that is, these information systems are web applications.
  • the web application is interactive and provides web pages created dynamically in accordance with 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.
  • 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.
  • 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.
  • 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 implementing the components of ActiveX or Java applets in web pages [X. Daytel, P.
  • 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.
  • 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.
  • the server is not required to function as a user interface.
  • the present invention does not require the support of a scripting mechanism for the operation of the system.
  • a system of self-contained software objects in this invention eliminates the complexity of implementing a universal script support mechanism.
  • the format used to describe self-contained objects is not of fundamental importance.
  • 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.
  • objects on the client side are combined into a system of self-contained software objects, the functioning of which takes into account the unified nature of the interactions of objects within the client-server system.
  • FIG. 1 illustrates the functioning of the system of self-sufficient objects in the case of a request for modification and receipt of data.
  • FIG. 2 is a flowchart of a request for modification and data acquisition.
  • FIG. 3 illustrates the functioning of the system of self-contained objects when a new container is requested.
  • the caching mechanism is not shown in this diagram.
  • FIG. 4 is a flowchart for requesting a new container without a caching mechanism.
  • FIG. 5 illustrates the caching mechanism when requesting a new container.
  • FIG. 6 is a flow chart of a caching algorithm when a new container is requested.
  • FIG. 7 illustrates an example of a window form for credit card payments.
  • FIG. 8 is a flowchart of credit card payments.
  • FIG. Figure 9 shows a block diagram of the algorithm for full or selective encryption of a request.
  • FIG. 10 shows a block diagram of the algorithm for full or selective decryption of the response.
  • FIG. 11 is a flowchart of an algorithm. launch a universal client program.
  • the implementation of the invention is a flowchart of an algorithm. launch a universal client program.
  • 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.
  • the following categories of objects are provided in the system of self-sufficient objects: o Containers - are intended for combining self-sufficient 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 transfer 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.
  • o Initiators buttons, menu items and other objects capable of initiating a request to the server based on user actions (keystrokes or mouse clicks).
  • Recipients - labels, input lines, text areas, lists, tables, diagrams and other objects capable of receiving and possibly displaying data received from the server.
  • o Requestors 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. o Intermediaries - special self-sufficient objects that 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.
  • Initiator interface o Mediator property - defines which mediator will be activated using this initiator.
  • Intermediary interface o property Container - defines the container that will participate in the formation of the request; o 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; o the property ContainerName - determines which container is required (if a new one is requested) or for which container the data is requested; o ServerAddress property - contains the network address of the server that implements the information system; o Gone method - brings the intermediary into action.
  • Interface Requestor o method Receive Request - returns the part of the request corresponding to the given requestor.
  • Recipient interface o SetData method - transfers the corresponding data to a specific recipient.
  • the Container interface about the Generate Request method - returns a full request to the server.
  • the container iterates over all the requestors related to it and calls the GetQuery method for each requestor, forming a complete request from the received parts; about the DistributeData method - iterates over all recipient objects related to the container, calls for each method
  • 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).
  • Container 9 interrogates the related requestors related to it (loop, blocks 24 - 26), calling for each of
  • o Server Program 10 modifies the data in Database 12 (block 29), requests, and receives data from Database 12 (block 30). o Server Program 10 converts the data to the desired format
  • the broker 8 transfers the received data to the existing Container 13, calling the Rapre method of dividing the Data (the container 13 may coincide with the original container 9) (block 33). o The container 13 distributes the received data between related to it, self-sufficient objects recipients
  • Container 9 polls the requestors related to it (the 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 if all the requestors are processed.) o Reseller 8 forwards the request to Server Program 10 at
  • Intermediary 8 (block 50). o Reseller 8 creates a new container based on the description received.
  • o Broker 8 sends a second request to the server, now to receive data for New Container 14 (block 52).
  • o Server Program 10 requests and receives data from the Database
  • o Container 14 distributes the received data between the recipient related self-contained objects
  • Intermediary 8 includes a description version in the request (block 63). o Reseller 8 forwards the request to Server Program 10 at
  • Machine-readable Storage Media 11 (block 65). o Server Program 10 compares version descriptions with client
  • 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). o Server program 10 forwards the response to Intermediary 8 (block 69). o 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 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 necessary, make changes to the logic of the information system or to the way of presenting information, in addition to changes in the operation of the server program, it is enough make changes to the descriptions of the respective containers stored on the server-machine readable medium and change the versions of these descriptions. In this case, the descriptions of the respective containers stored on the client machine-readable storage medium will be updated in a subsequent session.
  • 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.
  • 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 objects recipients, caching is not used, since this data can change even during one working session.
  • FIG. 1-6 illustrate interactions within a system of self-contained objects.
  • 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.
  • a number of properties should be correctly set for objects: schreib for the Initiator 7, the property of the intermediary should point to
  • Container property should point to Container 9 forming 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; o Container 9 should include all the objects necessary to form a request, with 'correctly installed configurations.
  • 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.
  • a self-sufficient object For 1 participation in the system, a self-sufficient object, it 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.
  • 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.
  • 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 Wi-Fi client platforms,
  • MacOS, Wi-Fi or Java Therefore, they are created on the basis of application programming interfaces of a specific client platform.
  • Adequate behavior of user interface objects implies: o a set of restrictions on entering information corresponding to the current use of objects; about warning the user about his inappropriate actions; about mutual consistency of objects.
  • Input fields 103 - 107 are intended for entering the corresponding digital and alphanumeric data: 103 - credit card numbers, 104 and 105 - the month and year of validity of a credit card, 106 - the amount of payment and 107 - the name of the card holder.
  • Objects 102 through 107 are interrogators. Buttons 108 and 109 initiate the operation of sending the 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.
  • the Container property should point to the window form 101.
  • the Reseller property should point to the existing intermediary.
  • 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.
  • Block 86 checks whether all the requestors are processed.
  • a check is made on the adequacy of user actions (block 84). In this case, whether the user has selected 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 “He selected the type of credit card”.
  • each line independently checks the adequacy of user actions (block 84). For input lines, this means checking if this field is filled.
  • the input line 103 opens a message box for the user (block 85) with the text “He filled in the field 'Credit card number'”. (The text 'Credit card number' should be contained in the Name field property of the input line 103.) o If all the fields are completed, then the steps are taken to get a new container - a window form with the results of the payment (blocks 47-57).
  • the number of digits in the credit card number depends on the type of credit card selected in the drop-down list 102. So, for example, a VISA credit card number can consist of 13 or 16 digits, number credit card Américap Express of 15 digits, card number Dificientines Club of . 14 digits, etc.
  • the correct credit card numbers are subject to the 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.
  • 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 may be warned appropriate message. It is important that this work is performed by the input line object itself, and not by the event handler.
  • 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. Daytel, P. Daytel, T. Nieto. How to program for internet & www. M. "Binom", 2002, 1184 s] and others, for example, data transfer protocols in mobile communication 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.
  • successful authentication means allocating a unique session identifier to the user.
  • the session identifier is allocated to the user without checking the name and password.
  • the session identifier can be included in all requests for data and containers, thus, with each request, user authorization is performed.
  • Interrogator interface about the encrypt property-flag. The request is set if the part of the request corresponding to this requestor should be encrypted.
  • Interface Recipient about the property-flag Decrypt The response is set if the part of the response corresponding to this recipient should be decrypted.
  • Interface Container about the property-flag Encrypt Full Request is set if the whole request should be encrypted, about the property-flag Decrypt All Response is set if the whole 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. So manner, can be simultaneously applied to 4 different algorithms' encryption.
  • the container polls the related requestors related objects (cycle 122 - 126) related to it, 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).
  • Block 141 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 related recipient self-contained objects (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 via Kerbos protocol [Joel Skembray, Mike Shema Secrets of hackers. Web application security - ready-made solutions, M. "Williams", 2003, 383 s]. These keys are valid for one working session.
  • encryption of data containing container descriptions can be arranged.
  • the container descriptions should be transmitted over the communication line and stored on a client machine-readable storage medium in encrypted form.
  • 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 computer-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.
  • a universal client program should include a rich set of self-contained objects, one 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 supplemented with additional objects contained in dynamically loaded libraries.
  • the client program needs to have the following data: o the network address of the application server; o the user authentication method adopted in this application; o the name of the first container, that is, the container requested immediately after user authentication; o a list of dynamically loaded libraries with self-contained objects that complement the system (if necessary); o 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.
  • a client computer running a universal client program (flowchart of Fig. 11): about 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); o 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 the implementation of encryption algorithms are loaded (block 163); schreib to execute authentication requests, an intermediary object is created and configured (block 164); o if the user authentication method requires entering 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) ; Occasionally if zero level authentication is used, then the login request is executed without any user actions
  • 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); schreib the user’s work with the information system ends after the first window form is closed (block 173).
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Description

Информационная система клиент-сервер и способ предоставления графического пользовательского интерфейса
Область техники, к которой относится изобретение
Изобретение относится к передаче данных в компьютерных сетях и может быть использовано в распределенных информационных системах.
Общепринятые термины Информационная система клиент-сервер - распределенная информационная система, состоящая из компьютера-сервера и одного или нескольких компьютеров-клиентов, в которой каждый клиент соединен с сервером линией связи. В настоящее время в качестве линий связи наиболее часто используется среда Интернет. Основная работа в системе клиент-сервер выполняется компьютером-сервером. Пользователь информационной системы взаимодействует с компьютером-клиентом.
Запрос - последовательность сигналов, пересылаемая по линии связи с клиентского компьютера на серверный компьютер. Сигналы запроса определяют, какие именно действия должен выполнить сервер, а также характер данных, которые ожидает клиент от сервера.
Отклик - последовательность сигналов, пересылаемая по линии связи с серверного компьютера на клиентский компьютер. В отклике содержатся данные для клиента.
Программный объект - определенным образом организованная совокупность сигналов в памяти компьютера. Программные объекты создаются и используются в процессе работы компьютера в соответствие с алгоритмами объектно-ориентированного программирования. Каждый программный объект обладает специфическим набором методов и характеризуется набором значений свойств объекта. Программные объекты взаимодействуют между собой, вызывая методы друг друга. Обычно взаимодействие происходит посредством обработчиков событий.
Метод объекта - определенным образом организованная совокупность сигналов в памяти компьютера. Вызов метода приводит эти сигналы в действие. Метод может возвращать данные, являющиеся результатом выполнения метода. Свойство объекта - характеристика объекта, содержащая данные одного из заранее преопределенных типов. Запись и чтение свойства осуществляются через вызовы соответствующих методов объекта.
События - действия пользователя или какие-либо иные изменения в компьютерной системе.
Конфигурация программного объекта - конкретный набор значений свойств этого объекта.
Описание программного объекта - данные, передающие конфигурацию программного объекта. Для описаний программных объектов могут использоваться различные двоичные или текстовые форматы.
Версия описания программного объекта - дополнительные данные, относящиеся к описанию программного объекта, позволяющие различать варианты конфигураций объекта.
Интерфейс (программный) - определенный набор методов .и свойств. Для поддержки программного интерфейса объект должен обладать всеми методами и свойствами, относящимися к данному интерфейсу.
Поведение объекта - реакция объекта на события в системе, зависящая от его конфигурации. Программные объекты изначально обладают некоторым поведением, то есть зависящей от конфигурации объекта заранее предопределенной реакцией на события в системе.
Обработчик события - определенным образом организованная совокупность сигналов в памяти компьютера, выполняющаяся в ответ на наступление конкретного события в компьютерной системе. Обработчики событий в значительной мере определяют поведение программных объектов. Они модифицируют изначальное поведение объектов, являются средством индивидуализации этого поведения и обычно обеспечивают взаимодействия между объектами.
Сценарий - текст, содержащий программу на одном из языков программирования, внедренный в веб-страницу или другой документ. Обработчики событий могут реализовываться путем динамического преобразования (интерпретации) текста сценария в совокупность сигналов соответствующих обработчику события. Веб-приложение - информационная система клиент-сервер, использующая в качестве клиентской программы веб-браузер. Поведение программных объектов клиентской части веб-приложения задается с помощью сценариев, внедренных в веб-страницы. Архитектура «moнкuй клueнm» - в соответствие с этой концепцией клиентская программа (так называемый «тoнкий клиeнт») только отображает элементы пользовательского интерфейса, а все события пользовательского интерфейса обрабатываются на сервере. Это создает дополнительную (помимо обычных в системе клиент-сервер запросов и откликов) нагрузку на линии связи. Кэширование - сохранение веб-страниц и других документов на машиночитаемом носителе данных клиентского компьютера с целью их повторного использования и уменьшения, за счет этого, нагрузки на линии связи. В веб-приложениях механизм кэширования веб-браузера обычно приходиться отключать, так как он может препятствовать обновлению данных (приводить к ошибочному использованию устаревших сохраненных данных).
Хеширование - разновидность шифрования без возможности расшифровки (однонаправленное шифрование).
Аутентификация пользователя - процедура, выполняемая при подключении пользователя к системе, когда пользователь с помощью условного имени и пароля удостоверяет свои пользовательские права.
Авторизация пользователя - процедура подтверждения полномочий пользователя в процессе работы информационной системы.
Термины, введенные автором изобретения
Самодостаточный объект - программный объект, не требующий для своего функционирования каких-либо обработчиков событий. Самодостаточные программные объекты способны адекватно функционировать лишь в составе определенной системы.
Система самодостаточных объектов - определенным образом организованная система программных объектов, в которой взаимосвязи между ними определяются исключительно конфигурацией этих объектов. Установленные определенным образом взаимосвязи между самодостаточными программными объектами позволяют системе адекватно функционировать без использования обработчиков событий в каком-либо виде, в том числе без использования сценариев. Механизм функционирования системы самодостаточных программных объектов описан ниже.
Уровень техники
В настоящее время широкое распространение получили информационные системы клиент-сервер. Человек, пользователь информационной системы клиент- сервер, непосредственно взаимодействует с компьютером-клиентом. В ответ на действия пользователя (например, нажатия клавиш или щелчки манипулятора «мышь») компьютер-клиент, работающий под управлением клиентской программы, посылает по линии связи сигналы запроса к компьютеру-серверу. Клиентская программа предоставляет пользовательский интерфейс на компьютере- клиенте и преобразует действия пользователя в сигналы запроса к серверу.
Компьютер-сервер работает под управлением серверной программы. По получении сигналов запроса сервер в соответствие с запросом выполняет некоторые преобразования данных, хранящихся на машиночитаемых носителях, производит выборку данных с тех же или иных машиночитаемых носителей и пересылает эти данные по линии связи в виде соответствующих сигналов на компьютер-клиент. По получение сигналов отклика компьютер-клиент представляет данные, полученные с сервера, пользователю в удобном для него виде и при необходимости записывает часть или все полученные данные на машиночитаемый носитель данных компьютера-клиента. Обмен сигналами- запросами и сигналами-откликами в системе продолжается так долго, как это необходимо пользователю для решения конкретной задачи. Помимо компьютера роль клиента может выполнять мобильный телефон или другое устройство коммуникации, работающее под управлением клиентской программы. Таким образом, для функционирования информационной системы клиент- сервер необходимы две программы - серверная и клиентская. Обычно серверная программа имеет доступ к информационным ресурсам в виде баз данных и выполняет основную работу в системе клиент-сервер. Клиентская программа выполняет небольшую часть работы, обеспечивая пользовательский интерфейс и выполнение запросов к серверу.
Во многих информационных системах, в качестве клиентской программы используется программы веб-браузеры, такие как Мiсrоsоft Iпtеrпеt Ехрlоrеr, Моzillа или Ореrа, то есть эти информационные системы являются веб- приложениями. В отличие от веб-сайтов, предоставляющих пользователю заранее предопределенный набор веб-страниц, веб-приложение работает интерактивно и предоставляет веб-страницы, созданные динамически в соответствие с запросом пользователя. Сильной стороной веб-приложений является универсальность клиентской программы. Веб-браузер устанавливается на компьютере-клиенте один раз, часто при установке операционной системы. Затем он может использоваться в качестве клиентской программы в самых различных веб-приложениях. Это исключает необходимость установки специализированных клиентских программ для каждого отдельного веб-приложения. В веб-приложении логика работы информационной системы и способ представления информации клиенту целиком определяется серверной стороной. Поэтому достаточно частые изменения в этой логике и способах представления информации не требуют каких-либо изменений в клиентской программе.
Однако возможности веб-приложений ограничены. Это связано с довольно бедными возможностями пользовательского интерфейса предоставляемого веб- браузером. В последнее время предпринимаются попытки усовершенствования пользовательского интерфейса веб-приложений на основе спецификаций ХFоrms [ХFоrms 1.0 (WЗС Rесоmmепdаtiоп) http://www.w3.org/TR/xforms/] и WеbFоrтs 2.0 [WеbFоrтs 2.0 (Wоrkiпg Drаft) http://whatwg.org/specs/web-forms/current-work/]. Тем не менее, новые спецификации не позволяют преодолеть разрыв, отделяющий пользовательский интерфейс веб-приложений от значительно более совершенного графического пользовательского интерфейса предоставляемого системами Wiпdоws, МасОS, ХWiпdоw, Jаvа и др. Поэтому в случаях, когда распределенная информационная система нуждается в развитом графическом пользовательском интерфейсе, разработчики вынуждены создавать специализированные клиентские программы, «poдныe» для данной клиентской платформы, то есть базирующиеся на интерфейсах программирования приложений конкретной клиентской платформы. В этом случае для каждой информационной системы требуется своя клиентская программа, каждое изменение в логике работы информационной системы или способах представления информации пользователю требует обновления клиентской программы (ее переустановки на клиентском компьютере). Пересылка и переустановка новых версий клиенткой программы вызывает дополнительную нагрузку на линии связи, создает значительные неудобства для пользователей, приводит к дополнительным финансовым затратам.
Задачей данного изобретения является создание технологии (системы и способа) разработки информационных систем клиент-сервер с развитым пользовательским графическим интерфейсом, в которой деловая логика и способы представления информации целиком находятся на стороне сервера, а клиентская часть представлена универсальной программой, не требующей переустановки для каждого отдельного приложения. При этом функционирование графического пользовательского интерфейса, то есть адекватное взаимодействие объектов пользовательского интерфейса с пользователем и между собой, должно происходить исключительно на клиентском компьютере без обращений к серверу. Техническим результатом изобретения должно стать исключение дополнительной нагрузки на линии связи, которую создает пересылка установочных пакетов и обновленных версий клиентских программ. Известны способы предоставления развитого графического пользовательского интерфейса веб-приложения за счет внедрения в веб-страницы компонентов АсtivеХ или Jаvа апплетов [X. Дейтел, П. Дейтел, T. Нието. Как программировать для интернет & WWW. M. "Бином", 2002, 1184 с]. Однако эти способы не решают поставленной задачи, так как соответствующие внедряемые компоненты не являются универсальными (для каждого веб-приложения требуются специализированные компоненты) и требуют обновления при изменении логики работы информационной системы или изменения способа представления информации. То же самое относиться и к новой технологии Jаvа Wеb Start[Java Wеb Stаrt Тесhпоlоgу, http://java.sшi.com/products/javawebstart/], которая предназначена для усовершенствования Jаvа апплетов.
Известны варианты реализации информационной системы клиент-сервер в архитектуре «тoнкoгo клиeнтa» [US 2002130900; US 2003135825]. Согласно [US 2002130900; US 2003135825] объекты пользовательского интерфейса создаются динамически, по описаниям на языке структурной разметки XML, полученным с сервера. Это позволяет уменьшить нагрузку на линии связи за счет универсального характера клиентской программы. Однако дополнительная нагрузка на линии связи из-за обработки клиентских событий на сервере сводит на нет это преимущество. Наиболее близким аналогом данного изобретения является [WO 2004019160]. В [WO 2004019160] предлагается программные объекты пользовательского интерфейса на клиентском компьютере создавать динамически на основании полученных с сервера описаний на каком-либо языке структурной разметки (XML, XSL, DHTML, XHTML, HTML). Индивидуализация поведения программных объектов пользовательского интерфейса достигается с помощью сценариев на языке JаvаSсriрt. Считается, что такие системы могут обладать свойством расширяемости, то есть в систему по мере необходимости могут быть добавлены объекты новых типов. Однако для работы сценария обычно необходимо задание объектной модели - набора заранее предопределенных объектных типов (классов, в терминологии объектно-ориентированного программирования), что противоречит принципу расширяемости. Эти предложения пока не получили распространения, возможно, именно из-за указанного противоречия и сложности реализации универсального механизма поддержки сценариев. Раскрытие изобретения
В изобретении поставленная задача решается путем использования на клиентской стороне универсальной системы динамически создаваемых, самодостаточных программных объектов и организации работы информационной системы клиент-сервер в соответствие с определенным алгоритмом. Так же, как в [US 2002130900; US 2003135825; WO 2004019160] в данном изобретении программные объекты на клиентском компьютере создаются динамически по их описаниям, полученным с сервера, но в данном изобретении объекты пользовательского интерфейса не встраиваются в веб-браузер, а функционируют в составе универсальной клиентской программы. В отличие от [US 2002130900; US 2003135825] в данном изобретении для функционирования пользовательского интерфейса не требуется обращения к серверу. В отличие от [WO 2004019160] в данном изобретении для функционирования системы не требуется поддержки механизма сценариев. Использование в данном изобретении системы самодостаточных программных объектов исключает сложности реализации универсального механизма поддержки сценариев. Для осуществления данного изобретения не имеет принципиального значения используемый формат описаний самодостаточных объектов. В отличие от обычно используемых программных объектов, чье поведение в значительной степени определяется обработчиками событий, поведение самодостаточного программного объекта целиком определяется заданием его конфигурации, то есть набором значений свойств этого объекта. Реакция самодостаточного программного объекта на события в системе зависит от конфигурации объекта, но при каждой конкретной конфигурации она заранее предопределенна и не подлежит модификации с помощью обработчиков событий.
Каким же образом может быть обеспечено адекватное взаимодействие самых разнообразных объектов, если модификация их поведения не предполагается? Для этого в изобретении объекты на клиентской стороне объединяются в систему самодостаточных программных объектов, функционирование которой, учитывает унифицированный характер взаимодействий объектов в рамках системы клиент-сервер.
Краткое описание чертежей Фиг. 1 поясняет функционирование системы самодостаточных объектов в случае запроса на модификацию и получение данных.
На фиг. 2 представлена блок-схема алгоритма при запросе на модификацию и получение данных.
Фиг. 3 поясняет функционирование системы самодостаточных объектов при запросе нового контейнера. Для простоты на этой схеме не показан механизм кэширования.
На фиг. 4 представлена блок-схема алгоритма при запросе нового контейнера без механизма кэширования.
Фиг. 5 поясняет механизм кэширования при запросе нового контейнера. На фиг. 6 представлена блок-схема алгоритма кэширования при запросе нового контейнера.
Фиг. 7 демонстрирует пример оконной формы, предназначенной для проведения платежей по кредитным картам.
На фиг. 8 представлена блок-схема алгоритма при проведении платежей по кредитным картам.
На фиг. 9 представлена блок-схема алгоритма при полном или выборочном шифровании запроса. На фиг. 10 представлена блок-схема алгоритма при полном или выборочном рашифровывании отклика.
На фиг. 11 представлена блок-схема алгоритма . запуска универсальной клиентской программы. Осуществление изобретения
Все самодостаточные объекты в системе подразделяются на несколько категорий. Принадлежность объекта к той или иной категории определяет его роль и поведение в системе. В системе самодостаточных объектов предусмотрены следующие категории объектов: о Контейнеры - предназначены для объединения самодостаточных объектов в группы. В пользовательском интерфейсе эти объекты представлены в виде оконных форм и различных группирующих панелей. Назначение объекта контейнера - иметь доступ ко всем самодостаточным объектам, которые он объединяет, с целью передачи им данных полученных с сервера или получения от них данных для формирования запроса к серверу.
Описание контейнера включает описания всех, относящихся к нему объектов, в том числе и других контейнеров. Любой самодостаточный объект (за исключением оконных форм) входит в состав какого-либо контейнера. Оконные формы существуют независимо, являясь контейнерами верхнего уровня. о Инициаторы - кнопки, пункты меню и другие объекты способные инициировать запрос к серверу на основании действий пользователя (нажатий клавиш или щелчков мышью). о Получатели - надписи, строки ввода, текстовые области, списки, таблицы, диаграммы и другие объекты способные получать и, возможно отображать данные, полученные с сервера. о Запросчики - строки ввода, текстовые области, списки, таблицы и другие объекты способные предоставлять содержащиеся в них данные для формирования запроса к серверу. о Декораторы - картинки и другие элементы графического дизайна, не способные взаимодействовать с пользователем. Декораторы не оказывают влияния на работу информационной системы, их наличие или отсутствие определяет исключительно внешний вид оконных форм. о Посредники - специальные самодостаточные объекты, являющиеся связующим звеном между объектами других категорий. Некоторые самодостаточные объекты могут относиться сразу к нескольким категориям, например, одновременно быть запросчиками и получателями. Принадлежность объекта к некоторой категории требует наличия обязательных для этой категории атрибутов, то есть поддержки соответствующего интерфейса.
Перечислим минимальный достаточный набор методов и свойств интерфейсов соответствующих перечисленных категорий самодостаточных объектов.
Интерфейс Инициатор: о свойство Посредник - определяет, какой именно посредник будет приведен в действие с помощью данного инициатора. Интерфейс Посредник: о свойство Контейнер - определяет контейнер, который будет участвовать в формировании запроса; о свойство ТипЗапроса - определяет, характер запроса. Минимальный набор, достаточный для работы системы включает следующие типы запросов: запрос нового контейнера; запрос данных для существующего контейнера; запрос, модифицирующий данные на сервере с последующим получением данных с сервера; запрос, модифицирующий данные на сервере без последующего получения с сервера каких-либо данных; несколько вариантов запросов для аутентификации пользователей; о свойство ИмяКонтейнера - определяет, какой именно контейнер требуется (если запрашивается новый) или для какого контейнера запрашиваются данные; о свойство АдресСервера - содержит сетевой адрес сервера, реализующего информационную систему; о метод Пошел - приводит посредника в действие.
Интерфейс Запросчик: о метод ПолучитьЗапрос - возвращает часть запроса, соответствующую- данному запросчику . Интерфейс Получатель: о метод УстановитьДанные - передает соответствующие данные конкретному получателю. Интерфейс Контейнер: о метод СформироватьЗапрос - возвращает полный запрос к серверу.
При вызове этого метода контейнер перебирает все относящиеся к нему объекты запросчики и вызывает для каждого запросчика метод ПолучитьЗапрос, формируя из полученных частей полный запрос, о метод РаспределитьДанные - перебирает все относящиеся к контейнеру объекты получатели, вызывает для каждого метод
УстановитьДанные и таким образом передает соответствующие данные каждому конкретному получателю. Интерфейс Декоратор не требуется.
Все самодостаточные объекты должны иметь свойство Имя, значение которого их идентифицирует.
При запросах новых контейнеров может быть использован специальный механизм кэширования, который обеспечивает дополнительное уменьшение нагрузки на линии связи. В перечисленный набор методов и свойств интерфейсов не включены свойства, необходимые для защиты данных путем полного или выборочного шифрования запросов и откликов и хранения кэшированных описаний объектов в зашифрованном виде (см. ниже).
Проследим по фиг. 1 взаимодействие клиента и сервера в случае запроса на модификацию и получение данных (блок-схема фиг. 2).
Условные обозначения: 1 - сервер, 2 - клиент, 3 - клиентская программа, 4 - стадия формирования запроса, 5 - стадия обработки отклика. Последовательность действий: о Пользователь 6 приводит в действие Инициатор 7 (кнопку, пункт меню и т. п.) (блок 21). о Инициатор 7 вызывает для Посредника 8 метод Пошел (блок 22). о Посредник 8 для Контейнера 9 вызывает метод
СформироватьЗапрос (блок 23). о Контейнер 9 опрашивает относящиеся к нему самодостаточные объекты запросчики (цикл, блоки 24 - 26), вызывая для каждого из
И них метод ПолучитьЗапрос (блок 24), формирует запрос из частей, соответствующих запросчикам (блок 25) и возвращает сформированный запрос Посреднику 8 (блок 27). (Блок 26 проверяет условие - все ли запросчики обработаны?) о Посредник 8 пересылает запрос Серверной Программе 10 по адресу
АдресСервера (блок 28). о Серверная Программа 10 модифицирует данные в Базе Данных 12 (блок 29), запрашивает, и получат данные из Базы Данных 12 (блок 30). о Серверная Программа 10 приводит данные к нужному формату
(блок 31) и пересылает их Посреднику 8 (блок 32). о Посредник 8 передает полученные данные в уже существующий Контейнер 13, вызывая метод Рапре делить Данные (контейнер 13 может совпадать с исходным контейнером 9) (блок 33). о Контейнер 13 распределяет полученные данные между, относящимися к нему, самодостаточными объектами получателями
(цикл, блоки 34 - 35), вызывая метод УстановитьДанные для
„ каждого получателя (блок 34). (Блок 35 проверяет условие - все ли получатели обработаны?) По фиг. 3 проследим взаимодействия клиента и сервера при запросе нового контейнера (без кэширования) (блок-схема фиг. 4). Последовательность действий: о Пользователь 6 приводит в действие Инициатор 7 (кнопку, пункт меню и т. п.) (блок 41). о Инициатор 7 вызывает для Посредника 8 метод Пошел (блок 42). о Посредник 8 для Контейнера 9 вызывает метод
СформироватьЗапрос (блок 43). о Контейнер 9 опрашивает относящиеся к нему самодостаточные объекты запросчики (цикл, блоки 44 - 46), вызывает для каждого из них метод ПолучитьЗапрос (блок 44), формируя запрос из частей, соответствующих запросчикам (блок 45), и возвращает сформированный запрос Посреднику 8 (блок 47). (Блок 46 проверяет условие - все ли запросчики обработаны.) о Посредник 8 пересылает запрос Серверной Программе 10 по адресу
АдресСервера (блок 48). о Серверная Программа 10 находит и считывает описание нового контейнера, находящееся на Серверном Машиночитаемом Носителе Данных 11 (блок 49). о Серверная программа 10 пересылает описание нового контейнера
Посреднику 8 (блок 50). о Посредник 8 по полученному описанию создает Новый Контейнер
14 (блок 51). о Посредник 8 направляет повторный запрос на сервер, теперь для получения данных для Нового Контейнера 14 (блок 52). о Серверная Программа 10 запрашивает, и получает данные из Базы
Данных 12 (блок 53). о Серверная Программа 10 приводит данные к нужному формату и пересылает их Посреднику 8 (блок 54). о Посредник 8 передает полученные данные в уже существующий
Новый Контейнер 14, вызывая метод Распределить-Данные (блок
55). о Контейнер 14 распределяет полученные данные между относящимися к нему самодостаточными объектами получателями
(цикл, блоки 56 - 57), вызывая метод УстановитьДанные для каждого получателя (блок 56). (Блок 57 проверяет условие - все ли получатели обработаны?)
Проследим по фиг. 5 функционирование механизма кэширования при запросе нового контейнера (блок-схема фиг. 6).
Вначале, вплоть до получения Посредником 8 от Контейнера 9 сформированного запроса, выполняются действия в соответствие с фигурой 3 (блоки 41 - 47 фиг. 4). Далее выполняются следующие действия: о Посредник 8 ищет на Клиентском Машиночитаемом Носителе
Данных 15 описание нового контейнера и версию этого описания (блок 61). Если описание и его версия присутствуют на клиентском компьютере (блок 62), Посредник 8 включает в запрос версию описания (блок 63). о Посредник 8 пересылает запрос Серверной Программе 10 по адресу
АдресСервера (блок 64). о Серверная Программа 10 находит и считывает описание нового контейнера и версию описания, находящиеся на Серверном
Машиночитаемом Носителе Данных 11 (блок 65). о Серверная Программа 10 сравнивает версии описаний с клиентского
15 и серверного 11 машиночитаемых носителей данных (блок 66). Если версии описаний совпадают, то Серверная Программа включает в отклик соответствующий признак (блок 67). В этом случае описание и его версия на клиентский компьютер не пересылаются. Если версии не совпадают или версия описания в запросе отсутствует, Серверная Программа включает в отклик описание и его версию (блок 68). о Серверная программа 10 пересылает отклик Посреднику 8 (блок 69). о Посредник 8 анализирует отклик. Если признак совпадения версий отсутствует (блок 70), то Посредник сохраняет полученные описание и его версию на клиентском Машиночитаемом Носителе Данных 15, при необходимости, заменяя имеющиеся описание и его версию (блок 71). В противном случае используется уже имеющееся описание (блок 72). о Посредник 8 по имеющемуся описанию (возможно, только что полученному) создает Новый Контейнер 14 (блок 73). о Далее выполняются действия в соответствие с фигурой 3 для получения данных для нового контейнера (блоки 52 - 57 фиг. 4).
Если к последующему сеансу работы в логике работы информационной системы или способе представления данных не произойдет изменений, описания контейнеров будут считываться с клиентского машиночитаемого носителя данных. По линиям связи будет передаваться только версии описаний контейнеров и признаки того, что описания не изменились. При необходимости внести изменения в логику работы информационной системы или в способ представления информации, помимо изменений в работе серверной программы, достаточно внести изменения в хранящиеся на серверном машиночитаемом носителе данных описания соответствующих контейнеров и изменить версии этих описаний. В этом случае, хранящиеся на клиентском машиночитаемом носителе данных описания соответствующих контейнеров будут обновлены в последующем сеансе работы. Таким образом, механизм кэширования, с одной стороны, позволяет оперативно обновлять логику работы информационной системы и способы представления информации, а с другой - снижает нагрузку на линии связи за счет того, что описание каждого контейнера обновляется только при необходимости.
Возможность и необходимость применения механизма кэширования для описаний контейнеров связана с тем, что эти описания могут оставаться неизменными на протяжении многих сеансов работы. Для данных, поступающих с сервера в самодостаточные объекты получатели, кэширование не применяется, так как эти данные могут изменяться даже в течение одного рабочего сеанса.
Как указано выше, для правильной работы веб-приложений, обычно приходится отключать существующий в веб-браузерах механизм кэширования. Это связано с тем, что протокол HTTP и язык разметки HTML, используемые в веб-приложениях не позволяют отличать данные, изменяющиеся часто от данных, изменяющихся редко. Поэтому механизм кэширования веб-браузера может препятствовать обновлению данных и приводить к ошибочному использованию устаревших сохраненных данных. Отключение механизма кэширования в веб- приложениях приводит к полной перезагрузке веб-страниц при каждом запросе. Это создает дополнительную (значительную и необоснованную) нагрузку на линии связи при работе веб-приложений.
Фиг. 1 - 6 иллюстрируют взаимодействия внутри системы самодостаточных объектов. Мы рассмотрели два типа запросов. Алгоритмы выполнения запросов других типов не имеют принципиальных отличий от рассмотренных алгоритмов. Функционирование системы в полной мере использует режим "запрос-отклик", характерный для любой системы клиент-сервер. Именно функционирование информационной системы в этом режиме позволяет выстроить универсальные последовательности действий. Важно отметить, что рассмотренные последовательности действий могут выполняться без привлечения каких-либо обработчиков событий, в том числе основанных на сценариях. Для успешного участия в выполнении запроса и получения отклика достаточно правильно сконфигурировать систему самодостаточных объектов, то есть правильно установить значения их свойств. В частности, в случае запроса показанного на фиг. 1 у объектов должен быть правильно установлен ряд свойств: о у Инициатора 7 свойство Посредник должно указывать на
Посредника 8 участвующего в запросе; о у Посредника 8 свойство Контейнер должно указывать на Контейнер 9 формирующий запрос; свойство ТипЗапроса должно соответствовать типу запроса; свойство ИмяКонтейнера должно соответствовать имени Контейнера 14, для которого запрашиваются данные; свойство АдресСервера должно содержать соответствующие данные; о Контейнер 9 должен включать все объекты необходимые для формирования запроса, с ' правильно установленными конфигурациями.
Все необходимые для конфигурирования данные могут содержаться в описании Контейнера 9 (в этом случае и Инициатор 7, и Посредник 8 содержатся в
Контейнере 9). Конфигурирование объектов выполняется создавшим их посредником, сразу после их создания на основании описания содержащего их контейнера.
Для 1 участия в системе, самодостаточному объекту необходимо и достаточно поддерживать интерфейс, соответствующий его (объекта) категории. В силу этого обстоятельства предлагаемая система может легко пополняться новыми самодостаточными объектами, то есть является расширяемой. Самодостаточные объекты, дополняющие систему, могут быть размещены в файлах динамически загружаемых библиотек на машиночитаемом носителе данных клиентского компьютера. После записи динамически загружаемой библиотеки на машиночитаемый носитель данных клиентского компьютера, содержащиеся в ней самодостаточные объекты могут использоваться в самых различных информационных системах. Таким образом, расширение системы самодостаточных объектов требует лишь однократной передачи по линиям связи небольших по объему динамически загружаемых библиотек. Рассмотрим теперь взаимодействие системы самодостаточных объектов с пользователем. Характер этого взаимодействия так же, как их взаимодействия внутри системы, полностью определяется конфигурацией самодостаточных объектов. Самодостаточные объекты воспринимаются пользователем информационной системы как элементы графического пользовательского интерфейса. По своей сути они должны предоставлять развитый графический пользовательский интерфейс, характерный для клиентских платформ Wiпdоws,
МасОS, ХWiпdоw или Jаvа. Поэтому они создаются на базе интерфейсов программирования приложений конкретной клиентской платформы. Адекватное поведение объектов пользовательского интерфейса предполагает: о набор ограничений ввода информации, соответствующий текущему варианту использования объектов; о предупреждение пользователя о его неадекватных действиях; о взаимную согласованность объектов. Покажем, каким образом все эти функции можно реализовать без использования обработчиков событий, исключительно путем настройки конфигурации самодостаточных объектов. Рассмотрим ' пример. На фиг. 7 схематически показана оконная форма 101, предназначенная для проведения платежей по кредитным картам (для упрощения, показаны не все необходимые поля). Выпадающий список 102 представляет собой специализированный объект, содержащий список поддерживаемых кредитных карт, например: VISA, Аmеriсап Ехрrеss и Золотая Корона и т. д. Поля ввода 103 - 107 предназначены для ввода соответствующих цифровых и буквенных данных: 103 - номера кредитной карты, 104 и 105 - месяца и года годности кредитной карты, 106 - суммы платежа и 107 - имени держателя карты. Объекты 102 - 107 являются запросчиками. Кнопки 108 и 109 инициируют операции передачи запроса на сервер и закрытия оконной формы, соответственно. На фигуре не показан посредник, который присутствует в контейнере 101, но для пользователя является невидимым. У посредника свойство Контейнер должно указывать на оконную форму 101. У кнопки 108 свойство Посредник должно указывать на существующего посредника.
Покажем, как могут быть реализованы ограничения ввода информации. Для полей ввода ограничения можно связать со свойствами ТипСодержимого и МаксимальнаяДлина. Свойство МаксимальнаяДлина определяет максимально возможное количество введенных символов. Свойство ТипСодержимого определяет, какие символы могут вводиться в строку. Так для строк ввода 103 - 105 свойство ТипСодержимого должно быть установлено в значение Целый. Этот тип содержимого допускает ввод только цифровых символов. Для строки ввода 106 свойство ТипСодержимого должно быть установлено в значение Денежный. Этот тип содержимого допускает ввод только цифровых символов и символа десятичного разделителя (точки или запятой, в зависимости от региональных настроек). Аналогично настраиваются и другие поля ввода. В процессе ввода символов, объект - строка ввода проверяет соответствие вводимых символов значению свойства ТипСодержимого и игнорирует недопустимые символы. Важно, что контроль ввода выполняется самим объектом, а не внешним по отношению к объекту, обработчиком события.
Покажем, как могут быть реализованы предупреждения пользователя о его неадекватных действиях (блок-схема, фиг. 8). В рассматриваемом случае типичными неадекватными действиями пользователя являются незаполненные поля ввода или невыбранный тип кредитной карты. При нажатии пользователем кнопки 108, действия выполняются в следующем порядке: о Кнопка 108 приводит в действие посредник (вызывает для посредника метод Пошел) (блок 81). о Посредник вызывает для контейнера 101 (на которого указывает свойство Контейнер) метод СформироватьЗапрос (блок 82). о Контейнер 101 перебирает относящиеся к нему самодостаточные объекты запросчики 102 - 107 (цикл, блоки 83 - 86), вызывая для каждого из них метод ПолучитьЗапрос (блок 83). (Блок 86 проверяет все ли запросчики обработаны.) о При вызове метода ПолучитьЗапрос для выпадающего списка 102 происходит проверка, адекватности действий пользователя (блок 84). В данном случае, выбрал ли пользователь тип кредитной карты. Если пользователь не выбрал тип кредитной карты, что является неадекватным действием, работа программы прерывается, выпадающий список открывает для пользователя окно сообщения (блок 85) с текстом «He выбран тип кредитной кapты». о При вызове метода ПолучитьЗапрос для каждой из строк ввода 103 - 107, каждая строка самостоятельно проверяет, адекватность действий пользователя (блок 84). Для строк ввода это означает проверку, заполнено ли это поле. Если пользователь не заполнил строку ввода 103, что является неадекватным действием, работа программы прерывается, строка ввода 103 открывает для пользователя окно сообщения (блок 85) с текстом «He заполнено поле 'Номер кредитной карты' ». (Текст 'Номер кредитной карты' должен содержаться в свойстве ИмяПоля строки ввода 103.) о Если все поля заполнены, то выполняется действия для получения нового контейнера - оконной формы с результатами проведения платежа (блоки 47-57).
При каждой остановке работы программы пользователь должен выполнить необходимые корректировки и снова нажать кнопку 108. Важно, что контроль неадекватных действий пользователя и сообщение об этом выполняется самим объектом, а не внешним по отношению к объекту, обработчиком события.
Покажем, каким образом можно реализовать взаимно согласованное поведение самодостаточных объектов. В , рассматриваемом примере (фиг. 7) количество цифр в номере кредитной карты (строка ввода 103), зависит от типа кредитной карты, выбранного в выпадающем списке 102. Так, например, номер кредитной карты VISA может состоять из 13 или 16 цифр, номер кредитной карты Аmеriсап Ехрrеss из 15 цифр, номер карты Diшiеrs Сlub из .14 цифр и т. д. Кроме того, корректные номера кредитных карт подчиняются правилам специфичным для каждого конкретного типа карты. Поэтому именно объекты 102 и 103 должны действовать согласованно. Для решения этой задачи строка ввода номера кредитной карты должна обладать свойством СписокКредитныхКарт, указывающим на список 102. В этом случае, в процессе ввода, допустимое количество введенных цифр может быть согласованно с типом кредитной карты, выбранным в списке 102, а при вызове метода ПолучитьЗапрос для строки ввода 103 можно по соответствующему алгоритму осуществить проверку соответствия введенного номера типу кредитной карты. В случае несоответствия введенного номера типу кредитной карты пользователь может быть предупрежден соответствующим сообщением. Важно, что эта работа выполняется самим самодостаточным объектом строка ввода, а не обработчиком события.
Таким образом, мы показали, как без использования обработчиков событий может быть обеспечено адекватное поведение объектов , пользовательского интерфейса.
Рассмотренные выше последовательности действий составляют, по сути, основу для оригинального протокола работы информационной системы клиент- сервер, который может быть сформулирован после их определенной формализации. Данный протокол может выполняться поверх известных сетевых протоколов, таких как ТСР/IР, HTTP, HTTPS, SOAP [X. Дейтел, П. Дейтел, T. Нието. Как программировать для интернет & WWW. M. "Бином", 2002, 1184 с] и других, например протоколов передачи данных в сетях мобильной связи. Выбор базового сетевого протокола не имеет принципиального значения и сказывается только на особенностях реализации. Выбор протокола более высокого уровня (например, HTTP по сравнению с ТСР/IР или SOAP по сравнению с HTTP) позволяет упростить процесс реализации. Напротив выбор протокола низкого уровня позволит сделать передаваемые пакеты данных более компактными и уменьшить объем данных, пересылаемых по линиям связи.
Остановимся кратко на вопросах, связанных с аутентификацией и авторизацией пользователей. Мы будем различать три уровня аутентификации: о Простейший случай, когда информационная система предоставляет открытый доступ всем желающим и аутентификация не требуется, относится к нулевому уровню. В этом случае запрос на вход в систему не содержит каких-либо данных о пользователе. о Если связь клиента и сервера осуществляется по защищенному соединению (например, в качестве базового, выбран протокол HTTPS [3]), то имя пользователя и пароль могут быть переданы по линиям связи на сервер непосредственно в запросе на аутентификацию. В этом случае, для аутентификации достаточно одного запроса (первый уровень). о Если используется незащищенное соединение, то передавать пароль по линии связи в открытом или даже хешированном виде нельзя. В этом случае аутентификация потребует выполнения двух запросов (второй уровень) и может быть проведена в два приема по типу дайджест-аутентификации или по протоколу Кеrbеrоs [Джоел Скембрей, Майк Шема Секреты хакеров. Безопасность Wеb- приложений - готовые решения, M. «Bильямc», 2003, 383 с]. В любом случае, успешная аутентификация означает выделение пользователю уникального идентификатора сеанса. На нулевом уровне аутентификации идентификатор сеанса выделяется пользователю без проверки имени и пароля. В процессе дальнейшей работы информационной системы идентификатор сеанса может включаться во все запросы на получение данных и контейнеров, таким образом, при каждом запросе выполняется авторизация пользователя.
Если в качестве базового сетевого протокола используется протокол без шифрования данных, например ТСР/ГР или HTTP, то защита данных, в виде полного или выборочного шифрования запросов и откликов, может быть встроена непосредственно в рассматриваемую систему. Для этого необходимо чтобы интерфейсы Запросчик, Получатель и Контейнер включали следующие свойства: Интерфейс Запросчик: о свойство-флаг ШифроватьЗапрос устанавливается, если часть запроса соответствующую данному запросчику следует зашифровать.
Интерфейс Получатель: о свойство-флаг РасшифроватьОтклик устанавливается, если часть отклика соответствующую данному получателю следует расшифровать. Интерфейс Контейнер: о свойство-флаг ШифроватьПолныйЗапрос устанавливается, если весь запрос следует зашифровать, о свойство-флаг РасшифроватьВесьОтклик устанавливается, если весь отклик следует расшифровать. Алгоритмы шифрования могут быть реализованы в виде динамически загружаемых библиотек. Для полного и/или частичного шифрования запросов и расшифровывания откликов могут использоваться различные алгоритмы. Таким образом, одновременно может быть использовано до 4 различных алгоритмов 'шифрования.
Покажем, как можно выполнить полное и/или частичное шифрование при формировании запроса (блок-схема фиг. 9). При вызове метода СформироватьЗапрос (блок 121) контейнер опрашивает относящиеся к нему самодостаточные объекты запросчики (цикл 122 - 126), вызывая для каждого из них метод ПолучитьЗапрос (блок 122). Если у запросчика установлено свойство ШифроватьЗапрос (блок 123), контейнер шифрует эту часть запроса (блок 124) с помощью динамически загружаемой библиотеки и включает ее в полный запрос (блок 125) в зашифрованном виде. Блок 126 проверяет, все ли запросчики обработаны. Если у контейнера установлено свойство ШифроватьПолныйЗапрос (блок 127), то сформированный запрос дополнительно шифруется (блок 128) перед отправкой на сервер (блок 129).
Покажем, как можно выполнить полное и/или частичное расшифровывание при получении отклика с сервера (блок-схема фиг. 10). При вызове метода РапределитьДанные (блок 141), если у контейнера установлено свойство РасшифроватьВесьОтклик (блок 142), то контейнер расшифровывает отклик, полученный с сервера (блок 143) с помощью динамически загружаемой библиотеки. Контейнер распределяет полученные данные между, относящимися к нему, самодостаточными объектами получателями (цикл, блоки 144 - 148), вызывая метод УстановитьДанные для каждого получателя (блок 144). Если у конкретного получателя установлено свойство РасшифроватьОтклик (блок 145), контейнер расшифровывает данные (блок 146) с помощью динамически загружаемой библиотеки, предназначенные для этого получателя, перед вызовом метода УстановитьДанные (блок 147). Блок 148 проверяет, все ли получатели обработаны.
Ключи шифрования могут быть получены с сервера при аутентификации пользователя по протоколу Кеrbеrоs [Джоел Скембрей, Майк Шема Секреты хакеров. Безопасность Wеb-приложений - готовые решения, M. «Bильямc», 2003, 383 с]. Эти ключи действуют в течение одного рабочего сеанса.
Аналогично может быть организовано шифрование данных, содержащих описания контейнеров. В этом случае, описания контейнеров должны передаваться по линии связи и храниться на клиентском машиночитаемом носителе данных в зашифрованном виде. Ответственность за расшифровку описаний может быть возложена на посредника. Необходимость расшифровки может быть указана с помощью установки свойства посредника РасшифровыватьОписаниеКонтейнера. Сеансовый ключ не может использоваться для расшифровки описания контейнера, так как это описание может считываться с клиентского машиночитаемого носителя данных неоднократно, в течение нескольких рабочих сеансов. В качестве ключа для расшифровки описания контейнера может быть использован пароль пользователя непосредственно или в хешированном виде.
Рассмотрим теперь работу клиентского компьютера под управлением универсальной клиентской программы, основанной на системе самодостаточных программных объектов.
Универсальная клиентская программа должна включать богатый набор самодостаточных объектов, такой, который может удовлетворить потребности большинства информационных систем делового характера. Включение объекта в систему означает, что объекты такого типа могут создаваться и конфигурироваться на основе их описаний. Те немногие информационные системы, для которых стандартного набора самодостаточных объектов будет недостаточно, могут быть пополнены дополнительньми объектами, содержащимися в динамически загружаемых библиотеках. Для начала работы конкретного приложения клиентской программе достаточно иметь следующие данные: о сетевой адрес сервера приложения; о способ аутентификации пользователей, принятый в данном приложении; о имя первого контейнера, то есть контейнера, запрашиваемого непосредственно после аутентификации пользователя; о список динамически загружаемых библиотек с самодостаточными объектами, дополняющими систему (при необходимости), о список динамически загружаемых библиотек с алгоритмами для полного или частичного шифрования запросов и откликов (при необходимости).
Эти данные могут храниться в файле инициализации приложения на клиентском машиночитаемом носителе. Рассмотрим последовательность действий в начале сеанса работы клиентского компьютера под управлением универсальной клиентской программы (блок-схема фиг. 11): о из файла инициализации на машиночитаемом носителе данных клиентского компьютера считываются данные об адресе сервера приложения, способе аутентификации, имени первого запрашиваемого контейнера и именах файлов динамически загружаемых библиотек (блок 161); о если список имен файлов динамически загружаемых библиотек не пуст (блок 162), то загружаются (блок 163) динамические библиотеки с дополнительными самодостаточными объектами и библиотеки с реализацией алгоритмов шифрования; о для выполнения запросов аутентификации создается и конфигурируется объект-посредник (блок 164); о если способ аутентификации пользователя требует введения имени пользователя и пароля (первый и второй уровни) (блок 165), то создается, а затем отображается на экране монитора специальная оконная форма, содержащая строки ввода имени и пароля и кнопку ввода в систему (блок 166); о если используется аутентификация нулевого уровня, то запрос на вход в систему выполняется без каких-либо действий пользователя
(блок 167); о если используется аутентификация первого или второго уровня, то аутентификация производится после ввода пользователем имени и пароля и нажатия кнопки входа в систему с помощью, соответственно, одного или двух запросов (блок 168); о в случае успешной аутентификации (блок 169) существующий посредник запрашивает по известному имени первый создаваемый контейнер (первую оконную форму) (блок 170); о посредник создает и конфигурирует по полученному описанию первую оконную форму (блок 171); о дальнейшая работа информационной системы идет по пути, который определяется содержимым первой оконной формы. На этой форме должны находиться посредники, запрашивающие- другие оконные о формы. Таким образом, логика дальнейшей работы информационной системы полностью определяется сервером (в частности, через получаемое с сервера описание первой оконной формы) (блок 172); о работа пользователя с информационной системой завершается после закрытия им первой оконной формы (блок 173). Таким образом, мы показали, как клиентский компьютер под управлением универсальной клиентской программы, основанной на системе самодостаточных программных объектов, может выполнять работу, логика которой полностью определяется сервером. В силу универсальности клиентской программы она может управлять работой клиентского компьютера в самых различных информационных системах, предоставляя развитый графический пользовательский интерфейс. Не требуется переустановка клиентской программы для работы в других информационных системах, а также и при изменении логики работы и способов представления данных. Это приводит к достижению необходимого технического результата - снижению нагрузки на линии связи из- за исключения дополнительной нагрузки, которую создает пересылка установочных пакетов и обновленных версий клиентских программ. Исключается также нагрузка на линии связи специфичная для систем клиент- сервер в архитектуре «тoнкoгo клиeнтa».
Хотя настоящее изобретение описано посредством примеров его выполнения, объём данного изобретения не ограничивается этими примерами, но определяется лишь формулой изобретения с учётом возможных эквивалентов.

Claims

Формула изобретения
1. Информационная система, состоящая из компьютера-сервера и одного или нескольких компьютеров-клиентов соединенных с сервером линией связи, в которой работу по модификации и выборке данных выполняет компьютер-сервер, а компьютеры-клиенты выполняют запросы к серверу на модификацию и выборку данных и предоставляют развитый графический пользовательский интерфейс, отличающаяся использованием на каждом клиентском компьютере расширяемой, универсальной системы динамически создаваемых, самодостаточных объектов.
2. Информационная система по п. I5 отличающаяся использованием в качестве базового, сетевого протокола ТСР/IР.
3. Информационная система по п. 1, отличающаяся использованием в качестве базовых, сетевых протоколов HTTP и HTTPS.
4. Информационная система по п. 1, отличающаяся использованием в качестве базового, протокола SOAP поверх сетевых протоколов HTTP и HTTPS.
5. Информационная система по п. 1, отличающаяся поддержкой на серверной стороне сеансового протокола с авторизацией по идентификатору сеанса.
6. Информационная система по п. 1, отличающаяся применением аутентификации пользователей по типу дайджест-аутентификации.
7. Информационная система по п. 1, отличающаяся применением аутентификации пользователей по протоколу Кеrbеrоs.
8. Информационная система по п. 1, отличающаяся применением механизма кэширования описаний самодостаточных объектов.
9. Информационная система по п. 1, отличающаяся применением полного и/или выборочного шифрования запросов и откликов с использованием сеансовых ключей.
10. Информационная система по п. 1, отличающаяся использованием описаний самодостаточных объектов, передаваемых по линиям связи и кэшированных на клиентском машиночитаемом носителе данных в зашифрованном виде.
11. Способ предоставления развитого, динамически создаваемого графического пользовательского интерфейса на клиентском компьютере в информационной системе клиент-сервер, отличающийся использованием расширяемой системы самодостаточных объектов работающих по определенному алгоритму, то есть системы программных объектов, функционирующей без использования обработчиков событий.
PCT/RU2005/000394 2005-07-27 2005-07-27 Client-server information system and method for presentation of a graphical user's interface Ceased WO2007001206A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP05851084A EP1914636A4 (en) 2005-07-27 2005-07-27 CLIENT SERVER INFORMATION SYSTEM AND METHOD FOR PRESENTING A GRAPHIC USER INTERFACE
US11/996,860 US20080208964A1 (en) 2005-07-27 2005-07-27 Client-Server Information System and Method for Providing Graphical User Interface
PCT/RU2005/000394 WO2007001206A1 (en) 2005-07-27 2005-07-27 Client-server information system and method for presentation of a graphical user's interface
JP2008523837A JP2009508184A (ja) 2005-07-27 2005-07-27 グラフィカルユーザインターフェイスの提示のためのクライアント−サーバ情報システム及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2005/000394 WO2007001206A1 (en) 2005-07-27 2005-07-27 Client-server information system and method for presentation of a graphical user's interface

Publications (1)

Publication Number Publication Date
WO2007001206A1 true WO2007001206A1 (en) 2007-01-04

Family

ID=37595374

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2005/000394 Ceased WO2007001206A1 (en) 2005-07-27 2005-07-27 Client-server information system and method for presentation of a graphical user's interface

Country Status (4)

Country Link
US (1) US20080208964A1 (ru)
EP (1) EP1914636A4 (ru)
JP (1) JP2009508184A (ru)
WO (1) WO2007001206A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010165202A (ja) * 2009-01-16 2010-07-29 Alpine Electronics Inc 情報処理装置及びファイル高速読み出し方法
JP2011514383A (ja) * 2008-03-17 2011-05-06 リジェナークス・バイオファーマスーティカルズ・インコーポレイテッド 改良されたベータチモシンフラグメント

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070078927A1 (en) * 2005-09-12 2007-04-05 Microsoft Corporation Server-side service framework
US8875259B2 (en) * 2007-11-15 2014-10-28 Salesforce.Com, Inc. On-demand service security system and method for managing a risk of access as a condition of permitting access to the on-demand service
US9619779B2 (en) * 2011-08-26 2017-04-11 Apple Inc. Client-side policy enforcement of developer API use
US9232025B2 (en) * 2013-02-01 2016-01-05 Schweitzer Engineering Laboratories, Inc. Entry of electric power delivery system data in a web-based interface
CN104202331B (zh) * 2014-09-15 2018-01-02 北京奇虎科技有限公司 客户端功能的生成方法和装置
EP3079059A1 (en) * 2015-04-07 2016-10-12 Huawei Technologies Co., Ltd. Method and apparatus for a mobile device based cluster computing infrastructure
CN114661851B (zh) * 2022-05-23 2022-08-16 山东省国土测绘院 一种在线轻量级快速响应的自然资源空间信息处理方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020130900A1 (en) 2001-03-16 2002-09-19 Tomorrowsoft Corporation System for generating an interface for software applications in a client-server environment
US20030135825A1 (en) 2001-12-05 2003-07-17 Matthew Gertner Dynamically generated mark-up based graphical user interfaced with an extensible application framework with links to enterprise resources
US6654784B1 (en) * 2000-01-14 2003-11-25 Nexaweb Technologies, Inc Computing architecture
WO2004019160A2 (en) 2002-08-23 2004-03-04 Jway Group, Inc. Extensible user interface (xui) framework and development environment
WO2005022337A2 (en) * 2003-08-29 2005-03-10 Yahoo! Inc. Extensible user interface

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061512A (en) * 1997-04-29 2000-05-09 Global Adsi Solutions Methods and apparatus for creating automated servers for display telephones
US6061727A (en) * 1997-09-30 2000-05-09 The United States Of America As Represented By The Secretary Of The Navy Robust computer systems permitting autonomously switching between alternative/redundant components
US6469714B2 (en) * 1998-01-26 2002-10-22 International Business Machines Corporation Infocenter user interface for applets and components
US6297819B1 (en) * 1998-11-16 2001-10-02 Essential Surfing Gear, Inc. Parallel web sites
US7188240B1 (en) * 1999-07-15 2007-03-06 International Business Machines Corporation Method and system for encryption of web browser cache
US7487440B2 (en) * 2000-12-04 2009-02-03 International Business Machines Corporation Reusable voiceXML dialog components, subdialogs and beans
DE10065419B4 (de) * 2000-12-27 2011-01-20 Siemens Ag Industrielle Steuerung mit taktsynchronem Ablaufebenenmodell
JP2002207762A (ja) * 2001-01-05 2002-07-26 Ntt-X Inc 店舗情報供給システムおよび店舗情報供給プログラムが記録されたコンピュータ読み取り可能な記録媒体
ES2257583T3 (es) * 2001-12-12 2006-08-01 Koninklijke Philips Electronics N.V. Sistema de visualizacion con guiado tactil.
JP2003242111A (ja) * 2002-02-14 2003-08-29 Meidensha Corp 業務統合システム
JP2003271388A (ja) * 2002-03-14 2003-09-26 Victor Co Of Japan Ltd 通信システム
US7565537B2 (en) * 2002-06-10 2009-07-21 Microsoft Corporation Secure key exchange with mutual authentication
US20040003341A1 (en) * 2002-06-20 2004-01-01 Koninklijke Philips Electronics N.V. Method and apparatus for processing electronic forms for use with resource constrained devices
AU2002952106A0 (en) * 2002-10-15 2002-10-31 Silverbrook Research Pty Ltd Methods and systems (npw008)
EP1420337A1 (en) * 2002-11-15 2004-05-19 Hewlett-Packard Company, A Delaware Corporation System and method to provide a flexible user interface
US20040187090A1 (en) * 2003-03-21 2004-09-23 Meacham Randal P. Method and system for creating interactive software
US7552451B2 (en) * 2003-04-11 2009-06-23 Microsoft Corporation Persisting state across navigations in a navigation-based application and responding to navigation-related events throughout an application
WO2006102467A2 (en) * 2005-03-21 2006-09-28 Primitive Logic, Inc. Service-oriented architecture
US20060253773A1 (en) * 2005-05-09 2006-11-09 Hsieh Cheng H Web-based client/server interaction method and system
US9772689B2 (en) * 2008-03-04 2017-09-26 Qualcomm Incorporated Enhanced gesture-based image manipulation

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6654784B1 (en) * 2000-01-14 2003-11-25 Nexaweb Technologies, Inc Computing architecture
US20020130900A1 (en) 2001-03-16 2002-09-19 Tomorrowsoft Corporation System for generating an interface for software applications in a client-server environment
US20030135825A1 (en) 2001-12-05 2003-07-17 Matthew Gertner Dynamically generated mark-up based graphical user interfaced with an extensible application framework with links to enterprise resources
WO2004019160A2 (en) 2002-08-23 2004-03-04 Jway Group, Inc. Extensible user interface (xui) framework and development environment
WO2005022337A2 (en) * 2003-08-29 2005-03-10 Yahoo! Inc. Extensible user interface

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HARVEY M. DEITEL; PAUL J. DEITEL; ANDREW B. GOLDBERG: "Internet and World Wide Web", 24 November 2003, PRENTICE HALL, pages: 1296
JAVA WEB START TECHNOLOGY, Retrieved from the Internet <URL:http://java.sun.com/products/ javawestart>
JOEL SCAMBRAY; MILE SHEMA; CALEB SIMA: "Hacking Exposed Web Applications", 19 June 2002, MCGRAW-HILL
See also references of EP1914636A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011514383A (ja) * 2008-03-17 2011-05-06 リジェナークス・バイオファーマスーティカルズ・インコーポレイテッド 改良されたベータチモシンフラグメント
JP2010165202A (ja) * 2009-01-16 2010-07-29 Alpine Electronics Inc 情報処理装置及びファイル高速読み出し方法

Also Published As

Publication number Publication date
US20080208964A1 (en) 2008-08-28
EP1914636A4 (en) 2009-12-23
JP2009508184A (ja) 2009-02-26
EP1914636A1 (en) 2008-04-23

Similar Documents

Publication Publication Date Title
US7418665B2 (en) Portable cross platform database accessing method and system
US7269664B2 (en) Network portal system and methods
US11038855B2 (en) Encryption filter
US9183537B2 (en) Content authoring and deployment technology
US7117504B2 (en) Application program interface that enables communication for a network software platform
US6985958B2 (en) Messaging infrastructure for identity-centric data access
US20040205525A1 (en) Automatic identification of form contents
US20080208806A1 (en) Techniques for a web services data access layer
US20090100321A1 (en) Universal contextual actions menu across windows applications
WO2007127521A2 (en) System and method for presenting and inputting information on a mobile device
CA2632793A1 (en) Information server and mobile delivery system and method
KR20040068106A (ko) 분산 컴퓨팅 환경에서 집합화된 서비스의 공급
US7788315B2 (en) Infrastructure for management and communication of information
RU2313824C2 (ru) Информационная система клиент - сервер и способ предоставления графического пользовательского интерфейса
WO1998038585A1 (en) Application messaging system
WO2007111751A2 (en) Architecture for a smart enterprise framework and methods thereof
WO2007001206A1 (en) Client-server information system and method for presentation of a graphical user&#39;s interface
US7266838B2 (en) Secure resource
EP2040190A2 (en) Processing HTML extensions to enable support of information cards by relying party
US20050228982A1 (en) Data communication system control method, data communication system, and information processing apparatus
JP4944411B2 (ja) メニュー生成システム、メニュー生成方法およびメニュー生成プログラム
US11533282B1 (en) Specifying and testing open communication protocols
US20240004740A1 (en) System and method for interoperability communication using raised intents
US11271738B1 (en) Secure, reliable, and decentralized communication in cloud platform
KR20010044385A (ko) 네트워크를 이용한 개인 정보 교환 시스템, 그 시스템을이용한 정보 교환 방법 및 그 방법이 기록된 컴퓨터로읽을 수 있는 기록매체

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2008523837

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11996860

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2005851084

Country of ref document: EP