RU2237275C2 - Server and method (variants) for determining software surroundings of client node in a network having client/server architecture - Google Patents

Abstract

FIELD: client/server architecture networks engineering.

SUBSTANCE: One of method variants includes following operations: host-server receives information about applications, which matches applications, which are placed on given plurality of servers and which are executed on one server from said plurality, when programs are launched for execution; from client system authorization data is received for authentication of user, for each application level of access from client system is determined; and from host-server to client system information is sent, which directs client system to each application from number of placed on servers, to which client system user has access for execution on server.

EFFECT: possible receiving of information about applications accessible on network servers by user of client system.

3 cl, 13 dwg, 2 tbl

Description

FIELD OF THE INVENTION

The present invention generally relates to networks with a client / server architecture. More specifically, the present invention relates to a server and to a method for informing a client system about application programs (applications) installed in server systems that are available for execution by a client system using it.

State of the art

Modern computer networks consist of a number of computer systems, called nodes, that communicate with other computer systems through communication channels (see, for example, US Patents Nos. 5666501, 5689708, 5729734, 5737592, 5794207 and 5826027). Typically, some of these nodes are client nodes, and other nodes are server nodes (hereinafter also referred to as servers). The client node formulates and sends requests to the server node. A client node user enters requests through a user interface running on the client node. The server node evaluates these requests and sends responses to the client node to display on the user interface of the client node.

Typically, a number of application programs are installed on server nodes, access to which can be obtained and which can be executed through client nodes. When the client node starts the application program, the execution of this application can occur either on the client or server node, depending on the calculation model adopted in the computer network. In the server model of calculations, the application is executed by the server node, and only control information for the user interface of the client node is transmitted over the network to the client node for display. In the client model of calculations, the server node transfers the application program to the client node, so that the client node can work with the program using its own resources.

One of the drawbacks of modern computer networks is that client nodes may not be aware of applications that are available on server nodes and which can be used. In fact, client nodes may not even be aware of all server nodes that are available on the network. To find available applications on a specific server node, a client node user may need to find and access this server node and list the files that exist on that server node. Even in this case, the list may not show the user those applications with which the user is allowed to work.

In addition, often after the user finds out what application programs are available on the server node, he must establish a connection with these applications. Programs have been released to help establish this connection. For example, the Remote Application Manager program manufactured by Citrix Systems, Inc., (USA) is an application that is installed on a client node. This application program prompts the administrator of the client node to enter information that will establish a connection with the application open for public use (published) on a specific server node. The administrator transmits information such as the name of the session, the protocol for accessing the server node, the server name or IP address or the name of the published application. This type of approach requires the administrator to have this information and detailed protocol and domain information to establish such a connection.

SUMMARY OF THE INVENTION

The present invention enables the user of the client system to be informed about the application programs available on the network servers, it is not required that the user knows where to find such applications and that he enters the technical information necessary to communicate with such applications.

On the one hand, the present invention relates to a method for presenting application programs for a client system in a network including the client system itself and a plurality of servers. Any of a variety of these servers that is capable of receiving application information corresponding to application programs hosted on a plurality of network servers can function as a host server collecting the specified application information. User credentials are received from the client system. The ability of the client system to access each of the applications for its execution is determined on the basis of user credentials and received information about the applications. Information is transmitted from the host server to the client system, indicating all applications hosted on the servers that are available to the client system for execution. In some embodiments, the host server generates an output file containing information related to the application, such as a hypertext markup language (HTML) file, an extended markup language (XML) file, or another standard general markup language (SGML) file.

The host server can verify the access right of the client system based on the received user credentials. When the client system selects one of the available applications for execution, this application can be executed without the need for additional input of credentials by the user of the client system, even if this application is located on a server other than the host server.

In one embodiment, the connection between the client system and the host server is established using an independent computing system architecture (1CA) protocol. The 1CA protocol can establish a virtual channel for transmitting information to the client system, indicating each application from the number hosted on the servers, which is available to the client system.

With this connection, a request can be made to execute one of the applications hosted on the servers. In response to this request, a second connection may be established between the client system and the host server to exchange information regarding the execution of the requested application. In another embodiment, in response to the request, a connection may be established between the host server and the second server on which the requested application is located. The exchange of information regarding the execution of the requested application can be carried out between the second server and the client system through the host server.

When connecting the host server to the client system, a second request may be received to execute another (second) available application. In response to this second request, another connection may be established between the host server and the third server on which the requested application is located. Information regarding the execution of this second requested application may be exchanged between the third server and the client system through the host server. For transmission to the client system, information received from the second and third servers can be combined.

In yet another embodiment of the invention, in response to a first request, the host server may transmit application information to the client system. In response to the application information provided, a second connection may be established between the client system and the second server on which the requested application is located.

The host server can transmit information about available applications in response to a request from the client system. The transmitted information can create a graphical user interface in the client system that has icons (shortcuts) representing available applications. The transmitted information can also show all applications hosted on servers, the use of which is prohibited for the client system.

The host server can communicate with each of the other servers to determine the applications that are hosted on these servers in order to create a database for storing application information. Each of these other servers can access this database, or each of these other servers can maintain its own database for storing application information.

In another aspect, the present invention relates to a presentation method for a client system of each application that is hosted on a server and that is accessible to the client system. The user credentials are received from the client system. Application information is supported by the server. The availability of each of the applications that are hosted on the server for execution by the client system is determined on the basis of user credentials and application information. Information indicating each application that is available to the client system is transmitted from the server to the client system.

In another aspect, the present invention relates to a server comprising a utility module that collects information related to applications and corresponding to applications that are hosted on a plurality of servers. A database stores collected information about applications. The receiver receives user credentials from the client system. For each of the applications hosted on the specified set of servers, the service module, on the basis of user credentials and application information stored in the database, determines whether this application is available for use by the client system. The transmitter transmits information to the client system.

The service module can transmit a datagram to other servers from this set in order to collect application information corresponding to the applications hosted on these servers. The transmitted information shows the user of the client system each available application program that is available for use by the client system. The transmitter can transmit information about available applications using the exchange protocol over a virtual channel.

List of drawings

The present invention is described in detail in the attached claims. The advantages of the invention can be better understood by considering the following description in conjunction with the accompanying drawings, where:

figure 1 is a diagram of client nodes that exchange information with a group of server nodes through a network in which, in accordance with the principles of the present invention, the software environment of the client node can be determined;

2A is a flowchart illustrating an example of a process by which one of the server nodes can initiate an application to determine the software environment of the client node;

2B is a flowchart illustrating an example of a process by which a client node can initiate execution of an application to determine the software environment of this client node;

2C is a flowchart illustrating an example of a process by which a client node uses a web browser to determine its own software environment;

3A, 3B and 3C are flowcharts illustrating examples of processes by which a client node can start an application from the “Software Environment” window that is displayed on this client node;

3D is a flowchart illustrating an example of a process by which a client node can launch an application from the “Software Environment” web page that is displayed on this client node;

4 is a flowchart of computing based on a client node, in which the client node, having an installed application defining a software environment in accordance with the present invention, exchanges data with one of the server nodes;

5 is a flowchart of computing based on a server node in which a client node communicates with a server node having, in accordance with the present invention, an installed application defining a software environment;

6A is an example of a screen shot of a display of a client node after executing an application defining a software environment in accordance with the present invention;

FIG. 6B is another example of a screen shot of a display of a client node after executing an application defining a software environment in accordance with the present invention; FIG.

FIG. 7 is a flowchart of a process by which a client node is informed of the availability of use of applications hosted on servers.

Information confirming the possibility of carrying out the invention

Figure 1 shows the first computing system (client node) 10 and the second computing system (client node) 20, which through a network 40 are connected to computing systems (application servers) 30, 32, 34 and 36. Network 40 may be a local network (LAN) or wide area network (WAN) such as the Internet or the World Wide Web. Users of client nodes 10, 20 can be connected to network 40 through various types of communication lines, including standard telephone lines, LAN or WAN lines (for example, T1, T3, 56 kb, X.25), broadband lines (ISDN, Frame Relay , ATM) and wireless links. A connection can be established using a variety of communication protocols (for example, TCP / IP, IPX, SPX, NetBIOS, Ethernet, RS232 and direct asynchronous communication).

Client node 10 can be any personal computer (for example, 286, 386, 486, Pentium, Pentium II, Macintosh), a terminal running in Windows, an Internet computer, a wireless device, an information device, RISC Power PC, an X computer , a workstation, a minicomputer, a mainframe or other computing device having a Windows screen environment and a memory for storing information of sufficient volume to run application programs downloaded via network 40 from servers 30, 32, 34. Windows platforms supported by client node 10 can on Windows 3.x, Windows 95, Windows 98, Windows NT 3.51, Windows NT 4.0, Windows CE, Macintosh, Java, and Unix. The client node 10 may include a display screen 12, a keyboard 14, a memory 16 for storing downloaded applications, a processor 17 and a mouse 18. Memory 16 may provide permanent or volatile storage. The processor 17 can execute applications locally, on the client node 10, and display the Windows on-screen environment on the display screen 12. Such local processing of information on the client node is carried out in accordance with the above-described client model of calculations.

In another embodiment, the client node 20 may be any terminal (working in a Windows environment or not) or a low-power client device operating in accordance with the server model of calculations. In the server model of computing, the execution of application programs takes place entirely on the application servers 30, 32, 34, and the user interface, keystrokes, and mouse movements are transmitted to the client node 20 through the network 40. The user interface can be activated using text (such as in DOS) or graphically (as, for example, in Windows). The platforms that client node 20 can support include DOS and Windows CE for Windows-oriented terminals. The client node 20 includes a display screen 22, a keyboard 24, a mouse 28, a processor (not shown), and long-term storage memory (not shown).

Application servers 30, 32, 34, and 36 can be any computing device that controls access to other parts of the network (for example, workstations, printers). It should be understood that more or fewer application servers may be connected to network 40. Servers 30, 32, 34, and 36 may operate in accordance with either the client or server model of computing, as described above.

Each application server 30, 32, 34, and 36 has one or more application programs that can be accessed by client nodes 10 and 20. Applications that are allowed to access client nodes are called published applications. Such applications include, for example, word processors such as MICROSOFT WORD® and spreadsheets such as MICROSOFT EXCEL® from Microsoft Corporation (USA), financial reporting programs, customer registration programs, technical support information programs, databases client or application installation management programs.

Servers 30, 32, and 34 may belong to the same domain 38. In network 40, the domain is a network fragment containing a group of application servers and client nodes that are managed by a single security system database. A domain may include one or more “server farms”. (A server farm is a group of servers that are linked together to act as a single server system and provide centralized administration.) Conversely, a server farm can include one or more domains. In order for servers from two different domains to belong to the same server farm, you may need to trust between these domains. A trust relationship is such a relationship between different domains that enables the user to access resources associated with each of the domains through a one-time verification of access rights (authentication) at the beginning of the session.

In one of the embodiments of the present invention, the application server 36 is not located in the domain 38, but in another domain. In another embodiment, the application server 36 is located in the same domain as the servers 30, 32, and 34. In any of these embodiments, the application servers 30, 32, and 34 may belong to the same server farm, while the server 36 may belong to to another farm, or all of the servers 30, 32, 34, and 36 may belong to the same server farm. When a new server connects to network 40, it either joins an existing server farm or forms a new farm.

Network 40 may include a main server node for performing load balancing between application servers 30, 32, 34, and 36. The main server node may be one of the application servers 30, 32, 34, and 36. The main server node has a list of server addresses and download information corresponding to each of the other application servers. The main server node, based on the list of available servers and the corresponding load levels, can direct the client node to the specific server node on which the application will run. Alternatively, application servers 30, 32, 34, and 36 can cooperate on an equal footing with a view to exchanging administration information, such as load levels, allowing any server 30, 32, 34, 36 to respond to a request made by client node 10, 20.

Software environment

In accordance with the principles of the present invention, a user of any client node 10, 20 can find out which application programs installed on application servers 30, 32, 34 and 36 in network 40 are available to him. In this case, the user does not need to know where to find these applications, and is not required to enter the technical information necessary to communicate with such applications. These available applications make up the “software environment” of the user. The system for determining the software environment of the client node includes a certain application program (hereinafter: the “Software Environment” application), a memory for storing components of this application program, and a processor for executing this application program.

The software environment application can be installed in the memory of client node 10 and / or on application servers 30, 32, 34 and 36, as described below. The “Software Environment” application is a combination of utilities, interface application programs (APIs) and user interface (UI) programs that show users of client nodes 10, 20 those applications located on application servers whose right to use them (for example, to implement them execution) has each client node.

The application server, operating in accordance with the application program “Software Environment”, collects information about applications from each of the application servers inside the server farm. Information about the applications for each of the applications hosted on the servers can be various information, including, for example, the address of the server that hosts the application, the name of the application, information about users or user groups that are allowed to use this application, and functional The minimum client node that you must have before you establish a connection and run the program. For example, an application can transmit a video data stream, and therefore, the client node must at least support video data. Another example is the ability of a client node to support audio data or the ability to process encrypted data. Information about applications can be stored in a database, as described below.

When a client node registers in the network 40, its user reports his credentials. User authority data typically includes the user name of the client node, the user password, and the domain name that the user is allowed to work with. User credentials can be obtained from microprocessor credit cards, from time-controlled hardware keys, social security cards, user passwords, personal identification numbers (PINs), from digital certificates based on encryption algorithms with a symmetric key and an elliptic curve, from biometric user characteristics or any other means by which data identifying the user of the client node can be obtained and presented to au entifikatsii. The server responding to the client node can authenticate based on user credentials. User credentials can be saved where the Software Environment application is running. When the client node 10 executes the software environment application, user credentials can be stored on the client node 10. When the application server executes the software environment application, user credentials can be stored on this server.

Based on the user credentials and application information, the server can also determine which applications installed on the application servers are available to the user of the client node. The server sends information about available applications to the client node. This process eliminates the need for a client node user to configure communication with applications. Also, the server administrator can control access to applications of users of various client nodes.

Authentication of the user performed by the server may be sufficient to allow each application program presented to the client node to be used, despite the fact that these programs can be located on another server. Accordingly, when the client node starts one of the applications (i.e., initiates its execution), additional input of user credentials may not be necessary to allow the use of this application. Thus, a one-time input of user credentials can serve as a means for determining available applications and for allowing the launch of such applications without additional manual authentication procedures performed by the user of the client node.

As follows from the description of FIGS. 2A-2C, the “Software Environment” application can be launched either by the client node 10, 20, or by the application server. The results are displayed on the display screen 12, 22 of the client node 10, 20. In the graphical embodiment, with the Windows on-screen environment, the results can be displayed in the graphics window “Software Environment”, and each allowed application can be represented in this window by a graphic icon.

In one embodiment of the invention, the “Software Environment” application filters out applications for which the client node 10, 20 does not have permission to use, and displays only allowed (i.e. available) programs. In other embodiments, the software environment application may display allowed and unresolved programs. When there is no filtering of unauthorized applications, a warning may be displayed indicating that such applications are not available. Alternatively, the “Software Environment” application can inform the client node of all application programs that are hosted on application servers 30, 32, 34, 36, without indicating which programs are allowed for execution by client nodes 10, 20 and which are prohibited. Permissions can be determined after the client node 10, 20 attempts to start one of these applications.

On figa shows an example of the process by which the server launches the application "Software environment" and presents the results of this application to the client node 10. The server can run this program in response to a request 42 of the client node 10 of a particular application. This request goes to the main server node, in this example, to the server 30. The main server node 30, taking into account the load distribution and the availability of applications, informs (arrow 43) the client node 10 that the desired application is available on the server 32. Client node 10 and server 32 establish a connection (arrows 45 and 46). Through this connection, the server 32 can transfer the executable code of a particular application to the client node 10 when the client node 10 and the server 32 operate in accordance with the client computing model. Alternatively, server 32 may execute a particular application and transmit a graphical user interface when client node 10 and server 32 operate in accordance with a server computing model. In addition, either the main server node 30 or server 32 can execute the application 41 “Software environment”, sending the results (arrows 43 or 46) back to the client node 10, so that when the client node 10 requests the application “Software environment”, the results This program is already available for the client node.

FIG. 2B shows another example of the process by which the client node 10 initiates the execution of the “Software Environment” application, and the server presents the results of this program to the client node 10. The client node 10 launches the “Software Environment” application (i.e., click the mouse on the icon 41 “Software environment” representing this application). The request 50 of the application “Software environment” is sent to the main server node, in this example - to the server 30. The main server node 30 can execute the application “Software environment”, if this application is located on the main server node 30, and return the results to the client node 10. In another embodiment, the main server node 30 may indicate (arrow 51) to the client node 10 that the software environment application 41 is available on another server, in this example, on the server 32. Client node 10 and server 32 are installed the compound (arrows 53 and 54) by which the client node 10 requests execution of the application 41 "Programming Environment". Server 32 may execute application 41 and transmit the results (i.e., a graphical user interface) to client node 10.

FIG. 2C shows another example of the process by which the client node 20 initiates the execution of the software environment application, in this example, through the Internet (World Wide Web). Client node 20 launches a web browser program 80, such as NETSCAPE NAVIGATOR from Netscape Communications, Inc. (USA) or MICROSOFT INTERNET EXPLORER from Microsoft Corporation (USA).

The client node 20 through a web browser 80 transmits a request 82 to access the address of the unified resource locator (URL) corresponding to the HTML page hosted on the server 30. In some embodiments, the first HTML page 84 returned to the client node 20 by the server 30 is a page an authorization check that attempts to identify the client node 20.

The access check page allows the client node 20 to transmit user credentials via a web browser 80 to the server 30 for authentication. The transferred user credentials are checked either by server 30 or by another farm server. This makes it possible to project the security domain to server 30. For example, if server 30 is running under WINDOWS NT operating system from Microsoft Corporation (USA), and the server performing authentication under UNIX operating system, then we can say that the UNIX security domain is projected onto the server 30. The user credentials may be transmitted “in the clear” or be encrypted. For example, user credentials can be transmitted using a secure connection protocol (SSL), which encrypts data using the RC3 algorithm developed by RSA Data Security, Inc. (USA).

Server 30 may verify user credentials received from client node 20. In another embodiment, server 30 may transfer user credentials to another server for authentication. In this embodiment, the authentication server may be in a different domain than the server 30. The user credentials of the client node 20 that have passed the authorization check can be stored on the client node 20 in the cookies history files or in areas that they are not displayed by web browser 80 or by any other means adopted to support web pages. In some embodiments, the server farm, which includes server 30, can provide guest users, i.e. users who do not have assigned credentials, the ability to access applications that are hosted on the servers of this farm. In such embodiments, the access control page may provide a mechanism, such as a button, or a menu selection that allows client node 20 to indicate that he is a guest user. In other embodiments, server 30 may completely omit the authorization page.

In accordance with FIG. 2C, as soon as the client node 20 successfully authenticates with the server 30, this server prepares and transmits to the client node 20 an HTML page 88, which includes the window 58 “Software environment” in which graphic icons 57, 57 appear 'representing applications to which the client node 20 has access. The user of the client node 20 requests the execution of the application represented by the icon 57 by clicking on this icon.

FIG. 3A shows an example of a data exchange process between the client node 10, the main server node, in this example, the server 30, and the server 32. The client node 10 has an active connection 72 with the server 32. The client node 10 and the server 32 can use an active connection 72 for exchanging information regarding the execution of the first application program. The user authority data of the client node 10 is stored on the client node. Such storage of user credentials can be done in long-term storage memory or in cache memory.

In this embodiment, the “Software Environment” application runs on the client node 10. The display of the client node has a window “Software Environment” 58 in which a graphic icon 57 representing the second application program appears. The user of the client node 10 can start the second application program by double-clicking on the icon 57. The request goes to the main server node 30 through connection 59. The main server node 30, through connection 59, indicates to the client node 10 that the desired application is available on server 32 Node 10 sends a signal to server 32 to establish a second connection 70. Server 32 requests user credentials from client node 10 to check access rights to the second application. Upon successful authentication, the client node 10 and server 32 establish a second connection 70 and exchange information regarding the execution of the second application program. Accordingly, the client node 10 and the server 32 communicate with each other through multiple connections.

FIG. 3B shows an example of a data exchange process between the client node 20, the main server node, in this example, the server 30, and the servers 32, 34 and 36. The client node 20 has an active connection 73 to the server 32. The client node 20 and the server 32 may use active connection 73 to exchange information regarding the execution of the first application program. The user credentials of the client node 20 are stored on the server 32 in the cache or in long-term storage memory.

In this embodiment, the “Software Environment” application runs on server 32. Server 32 has software that forms a client device 62 based on the server, allowing server 32 to act as client node 20. The display of client node 20 has window 58 “Software environment ”, in which graphic icons 57, 57 'appear, representing, respectively, the second and third application programs. The user of the client node 20 can launch the second application program by double-clicking on the icon 57. The request to start the second application program passes to the server 32 via the active connection 73, and the server 32 forwards this request to the main server node 30 (arrow 65).

The main server node 30 indicates (arrow 65) to the server 32 that the desired application is available on the server 34. The server 32 communicates with the server 34 to establish a connection 66. To verify the access rights to the application, the server 34 receives the user credentials of the client node 20 from server 32. Server 32 and server 34 establish a connection (arrow 66), through which server 32 requests the execution of the second application program, and server 34 returns to server 32 the resulting graphical user interface. The server 32 sends the resulting graphical user interface to the client node 20, where it is displayed. Accordingly, the exchange of information between the client node 20 and the server 34 passes through the server 32.

Similarly, the client node 20 can launch the third application by double-clicking on the icon 57 '. The request to start the third application program passes to the server 32. Server 32 forwards this request to the main server node 30, which, taking into account the load of the servers and the availability of the application program, determines which server can process this request. In this example, the main server node indicates that server 36 can start the third application.

Server 32 and server 36 establish a connection (arrow 74), through which server 32 requests the execution of a third application program, and server 36 returns a resulting graphical user interface to server 32. To enable execution of the third application program, the server 36 can authenticate the user credentials of the client node 20, which are received from the server 32. The server 32 sends the resulting graphical user interface to the client node 20, where it is displayed. Accordingly, the results of the execution of the third application program pass from the server 36 to the client node 20 through the server 32.

It follows from this explanation that the client node can run many applications through a single connection to server 32, while server 32 supports many connections (in this example, one connection to server 34 and the second to server 36). In addition, server 32 combines information received from server 34 with information received from server 36 into a single data stream for transmission to client node 20.

FIG. 3C shows an example of a process for exchanging information between a client node 20, a main server node, in this example, a server 30, and servers 32 and 34. Client node 20 has an active connection 76 to server 32. Client node 20 and server 32 can use active connection 76 for exchanging information regarding the execution of the first application program. Client node 20 may store user credential data in cache or long-term memory.

In this embodiment, the “Software Environment” application is launched for execution on the server 32. On the display of the client node 20 there is a window “Software Environment” 58 in which a graphic icon 57 representing the second application program appears. The user of the client node 20 can start the second application program by double-clicking on the icon 57. The request to launch the second application program is sent to the server 32. The server 32 responds (ie, “calls back”) to the client node 20 by returning application information, such as the name of the application and the functional minimum of the client node 20, necessary for working with the second application.

Having information from the server 32, the client node 20 then, through connection 77, communicates with the main server node 30 to determine which server can execute the second application program. In this example, such a server is the server 34. Then, the client node 20 establishes a connection 78 with the server 34. The server 34 requests the user credentials from the client node 20 to determine the access rights of the user of the client node 20. The second application program runs on the server 34, and the server 34 returns the graphical user interface to the client node 20 through an established connection 78. Accordingly, the client node 20 may have many active connections to many servers.

3D illustrates an example of data exchange between client node 20, server 30, which in this example acts as a web server, and server 32. Client node 20 confirms its access rights to server 30, as described above, with respect to FIG. . In one embodiment, the server 30 accesses the screen template 90 in the form of an SGML, HTML, or XML file to use it as a basis for constructing the Software Environment window and transfer it to the client node 20. This template can be saved in volatile memory or long-term storage memory associated with the server 30, or it can be stored in a large-capacity memory 92, such as a disk storage device or optical storage device, as shown in FIG. 3D.

In this embodiment, template 90 is a standard SGML, HTML, or XML document containing specific “software environment” tags that are replaced by dynamic information. These tags indicate to the server 30 where on the screen to insert information relevant to available applications, such as icon images. In particular, in one embodiment, program environment tags are embedded in comments within a file, allowing the file to remain compatible with standard interpreting programs. In another embodiment, software environment tags are extensions of the markup language used as the basis for the template.

Examples of HTML tags that can be used in a template in accordance with the present invention are shown below in table 1. 1

Other tags can be entered to configure control fields and to provide conditional processing related to the Software Environment application.

In one embodiment, the template is built dynamically using, for example, COLD FUSION from Allaire Corp. (USA) or ACTIVE SERVER PAGES from Microsoft Corporation (USA). Alternatively, the template may be static. The software environment application analyzes the template, replacing the specific tags of the software environment, as noted above. Tags that do not belong to special tags of the “software environment” are left in a file that is analyzed by the browser program 80 executed on the client node 20.

In one embodiment, a template analyzer object is created that captures the template, interprets the specific “software environment” tags present in the template, and outputs a source template in which all the “software environment” tags are replaced with the corresponding text. The template analyzer object can be transmitted in the form of a cookie, URL query string or control field from the web server interface to provide information that should be used to replace specific tags of the “software environment”.

In another embodiment, the Software Environment application provides scripts with the ability to collect information through the application software interface. Scripts can be written, for example, in VBScript or Jscript. In this embodiment, the scripting language is used to dynamically generate the final image based on the information that the application returns in response to script requests. When the final image is formed, it is transmitted to the client node 20 for display by the browser program 80.

The user of the client node 20 can start the application by double-clicking on the icon 57, 57 'displayed on the web-page "Environment". In some embodiments, each icon is an encoded URL that indicates: the location of the application (i.e., on which servers it is hosted or, in another embodiment, the address of the main server); launch command associated with the application; and a template that defines how the result of the application should be presented (i.e., in a window “embedded” in a browser, or in a separate window). In some embodiments, the implementation of the URL includes a file or a link to a file that contains information necessary for the client to communicate with the server hosting the application. This file can be created dynamically by the Application Environment program. The client node 20 establishes a connection (arrow 94) with the server, which was defined as the server hosting the requested application (in this example, it is server 32), and exchanges information regarding the execution of the desired application. In some embodiments, connection 94 is made using the Independent Computing System Architecture (1CA) protocol available from Citrix Systems. Thus, the client node 20 can display the result of the application in a window separate from the web browser 60, or the result of the application can be “embedded” in the web browser.

Figure 4 illustrates an example of the organization of software components for implementing the application "Software environment" based on the client node. Implementation of the software environment application on the basis of the client node can be used either in networks with the server computing model in which the servers execute the software environment, or in networks with the client computing model in which the client node 10 runs the software environment locally. The Software Environment application includes the service component of the Software Environment application (PNSVC) (component 44), the application database (component 48), the software environment application program interface (PNAPI) (component 52), the application user interface “ Software Environment ”(component 56) and local cache 60.

The application server 30, for example, includes a service component 44 (PNSVC) and an application database 48. Client node 10, being a typical example of a client node on the basis of which you can implement the application “Software environment”, includes application programming interface 52 (PNAPI), user interface 56 and local cache memory 60. PNSVC 44 communicates with base 48 application data and with PNAPI 52 on the client node 10 through the communication channel 62.

Communication channel 62 may be established, for example, via the ICA protocol. ICA is a general purpose data presentation protocol designed to work in conjunction with industry standard protocols such as TCP / IP, IPX / SPX, NetBEUI, using industry standard transport protocols such as ISDN, Frame Relay, and asynchronous data transfer mode ( ATM). The ICA protocol creates virtual channels, which are session transmission channels and can be used by application level code to issue data exchange commands. Virtual channel teams are designed for tight integration with client node functions. One type of virtual connection that is supported by the ICA protocol is the virtual circuit of the “software environment”.

The virtual channel protocol of the “software environment” may include four groups of commands:

(1) commands related to initialization;

(2) commands related to one-time authentication, which can be supported by each client node wishing to receive a copy of the user credentials;

(3) commands associated with these applications to implement the user interface of the software environment; and

(4) commands related to callback when starting applications for the user interface to work on the application server.

Application database

Application database 48 is a cache of information intended for authorized users or groups of users about all open (i.e. published) applications in a server farm or in a group of trusted domains. Each server in the server farm can maintain its own application information in long-term storage and build a database of 48 data in volatile memory. In another embodiment, all application information collected in database 48 can be stored in long-term storage memory and made available for every other farm server. Database 48 can be implemented in a unique format (for example, in the form of a linked list in memory) or using the Novell directory service (NDS) or any directory service that complies with the X.500 standard established by the International Telecommunication Union (ITU) for distributed electronic directories.

The application database 48 includes a list of application servers. Each server in this list has an associated set of applications. Each application is associated with information about the application, which may include the name of the application, a list of servers and clients that are allowed to use this application. Table 2 below provides a highly simplified example of application information supported by a database. Users A and B are users of client nodes 10, 20, “n / a” means that the application is hosted on the server but not accessible to users of client nodes, and “-” means that the application is not on the server.

Table 2 shows a list of servers 30, 32, 34; applications hosted on these servers (spreadsheet, client database, word processor, and calculator), and those users who are allowed to use these applications. For example, server 30 hosts a spreadsheet program, a client database, and a word processor. User A is allowed to use the spreadsheet, user B is allowed to use the client database, and no user is allowed to use the word processor. It should be understood that other techniques can be applied to indicate who is allowed to use a particular application. For example, user information stored in a database can be used to indicate those customers who are prohibited from using a particular application, and not those who are allowed to.

To obtain information that is stored in database 48, server 30 receives from each server in the farm information about applications that are hosted on these servers, including management information that indicates which clients and servers are allowed access to each specific application. This application information, which is maintained in the database, can either be saved or disappear when the server 30 is restarted.

Application database 48 can be a central database that is stored on application servers 30, 32, and 34 and can be accessed by all servers included in the server farm. Accordingly, application information may be available for use by other servers, such as those that authenticate published applications at the beginning of the session and launch applications. In another embodiment, the application database 48 may be maintained in each of the application servers 30, 32, 34 based on the information that each server receives when exchanging data with other servers in the farm.

Utility component of the software environment application (PNSVC)

Each server 30, 32, 34, and 36 on which the Software Environment application is installed executes PNSVC program 44. PNSVC program 44, running on each server 30, 32, 34, and 36, establishes a communication channel (i.e., a named pipe) with each other server. Servers 30, 32, 34 and 36 no to these named pipes exchange information about applications. In another embodiment, the PNSVC program 44 collects application information from other servers in the farm by remotely invoking registries (for example, the service component 44 passes the datagram to other servers of the plurality of servers that request application information corresponding to the application programs hosted on these servers). The PNSVC program 44 also maintains the relationship of groups and users with published applications in the database 48 of the application data and gains access to information during user authentication of the client node. Server 30 administrator can configure PNSVC component 44 using the user interface.

Other functions of the PNSVC program 44 include performing service operations and functions requested by the PNAPI 52, and exchanging data with the PNAPI 52 on the client node 10, using the software environment virtual device driver (VDPN). The VDPN driver acts in accordance with the “software environment” virtual channel protocol described above to establish and maintain an ICA connection.

Software Environment Application Program Interface (PNAPI)

PNAPI 52 is a set of software functions or services that the Software Environment application uses to perform various operations (for example, to open windows on a screen, open files and message windows). PNAPI 52 provides a general processing mechanism for application launch objects (for example, icons) that are formed when the “Software Environment” application is running, and for processing application objects in the user interface of old clients (that is, existing for some time or their predecessors). When the client node 10 starts any available application, the start mechanism can launch the application on the server 30 if necessary (i.e., when the client node 10 does not have the resources to execute the application program locally).

PNAPI 52 provides the user interface component 56 with all the information on the published application for displaying the client node 10 on the screen 12 (FIG. 1). Also, for implementing the one-time authentication function, PNAPI 52 manages the server farm entrance to the local registration authority database ( i.e., passwords) for users of the client node 10. Authorization data may or may not be saved when the client node 10 is rebooted (i.e., when the power is turned off and then back on).

PNAPI 52 provides automatic and manual control of software environment objects stored in the local cache 60. The contents of the local cache 60 can be updated by the user of the client node 10 either manually or at a frequency determined by the user or the server, at any time during the connection. When implemented in a Windows environment, PNAPI 52 can establish connections with remote application files and manage the Start menu and desktop screen icons to quickly call application objects.

Software User Interface

The user interface module 56 communicates with PNAPI 52 and may be an extended version of an existing client-user interface (eg, remote application management programs, Remote Application Manager). The user interface module 56 through PNAPI 52 gains access to information stored in the local cache and visually presents this information to the user on the display screen 12 (Fig. 1) of the client node 10. The displayed information is a mixture of information created by the user of the client node 10, and information obtained by the application “Software Environment”. The user interface module 56 can also show the user all applications that the user is working with at a given time, and all active and terminated sessions.

When implemented in a Windows environment, the user interface module 56 may represent many different graphical components, such as windows or drop-down menus, which should be displayed on the display screen 12 (FIG. 1). Displaying a combination of these components of the graphical user interface is usually called the “desktop” screen. The desktop generated by the user interface module 56 may include a “Software Environment” window showing neighboring applications available to the user of the client node 10. These applications are a filtered set of published applications hosted on a server farm on a network. The user interface module 56 can create its own software environment window for each server farm or combine applications from various server farms in one software environment window.

At the top level of directories, the “Environment” window contains a folder for each server farm. Clicking 18 (Fig. 1) on one of the folders brings up a window containing images (i.e., icons) of all applications located on this farm and accessible to the user (see, for example, Figs. 6A and 6B). The “Software Environment” window becomes the active window for launching published applications, and the user interface module 56 can be used to launch applications through PNAPI 52. For example, the user of the client node 10 can use the mouse 18 to select one of the displayed icons and launch the application associated with it .

A characteristic feature of the implementation of the “Software Environment” application based on the client node is that the user can view the objects displayed in the program environment window even when the client node is disconnected from the line (offline), that is, when the ICA connection 62 is not active. In addition, the user of the client node 10 can drag and drop application objects and folders from the “Software Environment” window into other graphic components (for example, into other windows, folders, etc.) of the desktop screen.

Figure 5 shows an example of the organization of software components for implementing the application "software environment" based on the server node. Components include service component 44 '(PNSVC), application database component 48', application program interface component 52 '(PNAPI), user interface component 56', and local cache 60 '. Each software component 44 ', 48', 52 ', 56' and 60 'is installed on the application server 30'. Software components when implementing an application based on a server node correspond to software components when implementing it on the basis of a client node (see Fig. 4). The operation of each software component based on the server node is similar to the operation of the same component based on the client node, with differences or additional features, which are described below. Component 44 'PNSVC communicates with the application data base 48' and with PNAPI 52 'using a local procedure call. PNAPI 52 'also communicates with the user interface module 56' and the local cache 60 '.

Similar to that shown in FIG. 4 for client node 10, client node 20 registers with network 40 (FIG. 1); the server 30 'creates and maintains a database containing application information collected from other servers 32, 34 of the server farm, and a communication channel is established between the server 30' and the client node 20. Application server 30 'communicates with client node 20 via ICA link 62'. Communication channel 62 'may be established by means of an ICA virtual channel protocol (e.g., Thinwire). The Thinwire protocol can be used to transfer presentation commands from Windows applications running on the server 30 'to the client node 20. It will appear to the user of the client node 20 that the applications are running on the client node 20. The client node 20 may include an application program 64 Remote Application Management (Remote Application Manager), which communicates with the server 30 'applications through the channel 62' ICA communication.

In order to launch the “Software Environment” application when it is implemented on the basis of the server node, the user of the client node 20 goes to the original desktop screen (on the server 30 ') and launches the “Software Environment” application from the desktop environment. Exit to the original desktop can occur automatically, i.e. through the script to register client node 20, through the program specified in the StartUp group in Windows 95, or through another, special centralized server-side management mechanism. All remote control of applications and their launch is carried out through the original desktop screen.

Similar to that shown in FIG. 4 for server 30, server 30 ′ uses the user credentials to determine which applications are allowed for the user of client node 20. The graphical window “Software Environment” returns to client node 20 and is displayed on the screen 22 of the client node (figure 1). This window may contain icons representing permitted, and possibly unresolved applications, which comprise the software environment of client node 20.

The user of the client node 20 can select and run one of the application programs presented in the "Software Environment" window. When starting the application program, the application “Environment” can, if appropriate, execute the application program on the same server 30 ', taking into account the requirements for load distribution between servers and the availability of this application program on the server 30'. PNAPI 52 'may include a mechanism for starting a remote application locally on the server 30' when it is announced that the application should be launched by the server 30 '. When it is necessary that the application program runs on another server, the “Software Environment” application can launch this application program through server 30 '(ie, a server-based client device) using windows to present this program on the desktop screen of the client node 20, as described above for figv.

In one embodiment, the “Software Environment” application, implemented on the basis of a web server, includes a group of objects that control various aspects of the application. In one embodiment, the application includes three main classes of objects that connect to the web server: the class of the gateway object, the class of the authorization data object, the class of the application object. In some specific embodiments, object classes are created as a Java beans model. Three main classes of objects provide: verification of user authority data for access to the server farm; creating lists of published applications that specific users can access; providing detailed information on specific published applications; and converting information on published applications into an ICA compatible format.

If objects are created as Java beans, they can be accessed in a number of different ways. For example, they can be compiled as COM objects and made available through a web server as ActiveX components. In another embodiment, Java beans can be used in their natural form, such as when the server uses Java Server Pages technology. In yet another embodiment, Java beans can be implemented and used directly in the Java servlet. In yet another embodiment, server 30 may implement Java beans directly as COM objects.

The authorization data object class manages the information necessary to verify user access rights to the desired server farm. The authority data object transfers stored user authority data to other “software environment” objects. In some embodiments, the authority data object is an abstract class that cannot be implemented and represents user authority data. Various class extensions can be created to enable the use of various authentication mechanisms, including biometrics, microprocessor credit cards, hardware-based authentication mechanisms, such as authentication with request and confirmation, the formation of time-dependent passwords, and other methods. For example, an extension such as “clear text authority data” can be created that saves the username, domain, and password as plain text.

The gateway object class controls the exchange of data with the desired server farm. In one embodiment, the gateway object class is created as an abstract Java class that cannot be implemented. A specific gateway entity can retrieve application information by communicating with a server farm using a specific protocol, reading cached application information, using a combination of the two, and various other methods.

As noted above, the gateway object class caches information to reduce the time it takes to exchange data with the desired server farm. The gateway object can be equipped with an extension to exchange data with the server farm using special protocols, such as HTTP. In one embodiment, an extension class is created that allows the gateway entity to communicate with the server farm through the WINDOWS NT named pipes. The gateway object can create a special application program interface procedure that allows other objects of the “software environment” to make requests addressed to this object regarding application information.

The application object class contains information about published applications and returns information about applications hosted on the server farm to create a web page for the software environment. The application object class creates objects representing application programs by retrieving information related to these programs either from the object created by the gateway object or directly from the farm servers. The application object acts as a container for certain properties of the application program, both custom and non-custom, such as: application name (cannot be configured); the percentage of the desktop screen area that can be occupied by the client window (can be customized); the width of the client window in pixels for this application (can be customized); the height of the client window in pixels for this application (can be customized); the number of colors that should be used when communicating with the application (can be customized); allowable bandwidth of the audio channel (can be configured); level of coding, which should be used when communicating with the application (can be configured); level of video that should be used when communicating with the application (can be configured); whether the application should be placed in the start menu of the client (can be customized); whether the application should be placed on the desktop of the client screen (can be customized); name of the folder of the software environment to which this application belongs (can be configured); application description (can be customized); the source of the icon graphic file for this application (can be customized); the type of window that should be used when communicating with the application (cannot be configured); and whether to change the default parameters for this object.

The application base class contains information about published applications and is used by the gateway base class to return information about applications hosted on the server farm in order to create the “Software Environment” web page.

6A is an example of a screen shot of the window 120 “Software environment”, which can be displayed on the screen 12, 22 (FIG. 1) of any client node 10, 20 after completion of the execution of the application “Software environment”. Window 120 includes graphical icons 122. Each icon represents some kind of application program that is located on one of the servers 30, 32, 34, and 36 of the network 40 (FIG. 1). Each submitted application is available for execution by the user of the client node. The user can select and run one of the applications using the mouse 18, 28 or the keyboard 14, 24.

FIG. 6B is an example screen shot of another window 124 “Software Environment”, which can be displayed on the screen 12, 22 (FIG. 1) of any client node 10, 20 after completion of the execution of the application “Software Environment”. Window 124 includes graphic icons 126, 128. Each icon 126, 128 represents an application program that is located on one of the servers 30, 32, 34 and 36 of network 40. Each application represented by one of the icons 126 is available for the user executing the client node 10, 20. The user can select and start one of the applications using the mouse 18, 28 or the keyboard 14, 24. When showing the software environment in a web environment, screenshots are similar to those shown in Figs. 6A and 6B, except that the icons 122, 126, 128 are displayed in a browser window.

Each application program represented by one of the icons 128 is not accessible to the user of the client node 10, 20, although these applications are present on the server farm. The inaccessibility of these applications may be indicated on the display screen (for example, icons 128 may be crossed out). Attempting to launch such an application should trigger a message indicating that the user is not allowed to use this application.

7 shows an example of a process by which a user of any client node 10, 20 can be informed about the availability of applications hosted on application servers 30, 32, 34, and 36 in network 40. At step 80, client node 10, 20 requests registration from one of the servers, for example, server 32. To establish a connection, server 32 will require valid user credentials. Server 32 receives user credentials from client node 10 (step 82) and authenticates the user to register at the start of the session (step 84). The desktop is displayed on the client node 10, 20 (step 85). The desktop may include a graphic icon representing the software environment application.

At step 86, the application server 32 establishes a connection with each of the other servers 30, 34, and 36 for exchanging, as described above, application information corresponding to the application programs hosted on these servers (step 88). At 90, the application server 32 creates and maintains a database of collected application information. Each other server 30, 34, 36 in the server farm can create a database equivalent to the server 32 database, in the same way as the server 32. In another embodiment, the server 32 database can be a centralized database that is accessible to each another server 30, 34, 36 applications in the server farm. The collection of information about the applications can occur independently or can be initiated by the request of the client node 10, 20 to start a session sent to the server of the farm 38.

At step 92, the client node 10, 20 may request the execution of the application program from the desktop screen. The main server node can process this request and, evaluating the distribution of server load and the availability of this application program, as described above, determine the application server that should serve the request of the client node 10, 20 (step 94). For example, an application server 32 may be selected to serve a request from a client node 10, 20. At step 96, the client node 10, 20 establishes a communication channel with the server 32. The server 32 and the client node 10, 20 can exchange data in accordance with the ICA protocol, which is suitable for the client node, as described above.

In addition, in response to a request to run the application program, the main server node 30 or server 32 can run the application (step 93) and send the results to the client node 10, 20, although the client node 10, 20 might not request the application “Software Environment” (PN). When executing the PN application, the main server node 30 or server 32 filters application information in the database based on user credentials (step 100). The result of filtering the database determines those applications that make up the software environment of the client node 10, 20. This software environment in the form of information about available applications is sent to the client node 10, 20 (step 102) and displayed on the screen 12, 22 of the client node in a graphical the “Software Environment” window (step 104).

In other embodiments, the “Software Environment” window may include applications that are present on the server farm but are not available for use by the client node 10, 20. When implemented in a Windows environment, available (and inaccessible) applications can be represented by icons. The user of the client node 10, 20 can select and run one of the applications shown in the "Environment" window.

All information necessary for the practical implementation of the present invention can be represented in the form of one or more programs that can be read by a computer and which can be implemented as one or more industrial products. An industrial product may be a floppy disk, hard disk, CD ROM, flash memory card, PROM, RAM, ROM or magnetic tape. In general, programs that can be executed on an appropriate computer when performing certain operations of the method of the present invention can be implemented in any programming language. Examples of languages that can be used include C, C ++, or JAVA. These programs can be recorded on / in one or more industrial products in the form of object code.

Although the present invention has been described by way of examples of preferred options, it will be understood by those skilled in the art that changes may be made to the form and details of the invention without departing from the spirit and scope of the invention.

Claims (44)

1. A method of showing the client system applications that are available for use on a network including a client system and a plurality of servers, among which there is at least one host server and a plurality of servers that host applications, which includes the following steps: ( a) on the host server receive information about applications that correspond to applications that are hosted on the specified set of servers and that run on the same server from this set when the programs run on you olnenie; (b) accept credentials from the client system certifying its user; (c) for each application hosted on multiple servers, based on user credentials and application information, it is determined whether the program is available for use by the client system, and (d) information indicating the client is transmitted from the host server to the client system the system, each application program from the number hosted on the servers to which the user of the client system has the right to execute it on the server on which this program is hosted. 2. The method according to claim 1, characterized in that it includes the step of establishing a connection between the client system and the host server using the protocol of an independent computing system architecture (ICA). 3. The method according to claim 2, characterized in that the ICA protocol establishes a virtual channel for transmitting information to the client system, indicating each application program available on the servers that is available to the client system. 4. The method according to claim 1, characterized in that it comprises the following steps: establish a connection between the client system and the host server; receive a request to execute one of the available application programs hosted on the servers, and in response to the request, establish a second connection between the client system and the host server to exchange information regarding the execution of the requested application program. 5. The method according to claim 1, characterized in that it comprises the following steps: establish a first connection between the client system and the host server; accept a request to execute one of the available application programs hosted on servers; in response to the request, a second connection is established between the host server and the second server on which the requested application is located, and information regarding the execution of the requested application is exchanged between the second server and the client system through the host server. 6. The method according to claim 5, characterized in that it contains the following steps: accept the second request for execution of the second of the available application programs hosted on the servers; in response to the second request, a third connection is established between the host server and the third server hosting the second requested application program, and information is exchanged regarding the execution of the second requested application program between the third server and the client system through the host server. 7. The method according to claim 6, characterized in that it includes the step of combining information received from the second and third servers for transmission to the client system via the first connection. 8. The method according to claim 1, characterized in that it comprises the following steps: establish a first connection between the client system and the host server; receive a request to execute one of the available application programs hosted on the servers, and transmit information to the client system in response to a request to execute the application program. 9. The method according to claim 1, characterized in that the transmitted information is displayed in the client system in the form of icons representing available applications in a graphical user interface window. 10. The method according to claim 1, characterized in that it includes the step of exchanging data between the host server and each of the plurality of other servers in order to determine which applications are hosted on said other servers. 11. The method according to claim 1, characterized in that it includes the step of establishing a communication channel between the host server and the client system, the communication channel including at least one virtual channel. 12. The method according to claim 1, characterized in that the server on which the running application is running is one of many servers other than the host server, the method further comprising the following steps: on the host server, based received user credentials, authenticate the user of the client system and execute the launched application program, without requiring the user of the client system to enter additional credentials. 13. The method according to claim 1, characterized in that the host server transmits information about available applications in response to a request for such information from the client system. 14. The method according to claim 1, characterized in that it includes a stage on which the host server maintains a database for storing information about application programs, wherein said database is available for each of a variety of other servers. 15. The method according to claim 1, characterized in that it includes a stage in which each of the many servers support a database for storing information about application programs. 16. The method according to claim 1, characterized in that the transmitted information further shows the user of the client system each of the application programs hosted on the servers, which he is allowed to use. 17. The method according to claim 1, characterized in that in step (d): (da) form a final screen frame indicating each application program hosted on the servers, which is available to the client system for execution, and (db) transmit the generated final frame screen to the client system. 18. The method according to 17, characterized in that at step (a) through the web server receive information about application programs corresponding to programs hosted by at least one of the plurality of servers. 19. The method according to p. 18, characterized in that it includes the steps in which (e) analyze the SGML document; (f) as a result of the analysis of the SGML document, information about application programs corresponding to programs located on at least one of the plurality of servers is extracted. 20. The method according to 17, characterized in that at step (b) through the host system, biometric user credentials are received from the client system. 21. The method according to 17, characterized in that at step (b) through the host system, encrypted user credentials are received from the client system. 22. The method according to 17, characterized in that in step (d-a): (a) through the host system, user credentials are received from the client system; (b) on the host server, based on the received credentials, authenticate the user of the client system and (c) execute the application program selected from among the application programs and hosted on one of the plurality of servers without requiring additional user credentials from the client system. 23. The method according to 17, characterized in that at step (d-a) they form the final screen frame in the form of an SGML file indicating each application program from the number hosted on the servers, which is available to the client system for execution. 24. The method according to p. 17, characterized in that at step (d-a) form the final screen frame in the form of an HTML file indicating each application program from the number hosted on the servers, which is available to the client system for execution. 25. The method according to 17, characterized in that at step (d-a) form a final screen frame representing the available application programs in the form of icons in a window of a graphical user interface. 26. The method according to 17, characterized in that at step (d-b) transmit the generated final screen frame to the client system using HTTP. 27. The method according to 17, characterized in that it includes the following steps: (e) receive a request to execute one of the available application programs hosted on the servers, and (f) execute the requested application program. 28. The method according to item 27, wherein in step (f) execute the requested application program in the window that is contained on the page of the final frame of the screen. 29. The method according to item 27, wherein the step includes establishing a connection between the client system and the server on which the requested application is located. 30. The method according to 17, characterized in that it includes the step of exchanging data between the host server and the specified set of servers in order to determine the application programs hosted on this set of servers. 31. The method according to claim 8, characterized in that in response to receiving a request to execute one of the available applications located on the servers, a second connection is established between the client system and the server on which the requested application is located. 32. The method according to claim 1, characterized in that the host server uses the user credentials to determine whether the user of the client system is allowed access to the host server, and determine those applications whose execution is allowed to the user of the client system. 33. The method according to claim 1, characterized in that each server transmits information about application programs relating to each application located on this server to a centralized database. 34. The method according to claim 1, characterized in that each server transmits information about application programs related to each application program hosted on this server to each other server. 35. A method of displaying each application program available for use by a client system in a network including a plurality of servers hosting application programs, comprising the following steps: (a) receiving credential data identifying a user of the client system; (b) maintain application information corresponding to each application hosted on each of the servers; (c) based on the user's credentials, it is determined whether the user of the client system is allowed to use each application program from among those hosted on the servers; (d) in response to the information about the application programs, information is transmitted to the client system, while the transmitted information shows each application program that the user of the client system is allowed to use. 36. The method according to clause 35, wherein in step (d): (da) the final screen frame indicating each application program from the number located on the servers that is available to the client system for execution is formed from the results of determination and (db ) transmit the generated final screen frame to the client system. 37. A server in a network including a client system and a plurality of servers hosting application programs, comprising a utility module that collects information about application programs corresponding to application programs that are hosted on a specified set of servers and that run on one server from that set when they are launched; a receiver receiving authority data identifying a user of the client system; a database that accumulates the collected information about the application programs, and the service module, based on user credentials and information on the application programs stored in the database, determines for each application program located on the specified set of servers whether this application program is available to the client system execution, and a transmitter that transmits to the client system information indicating to the client system each application program from the number hosted on the servers, access to which th user is allowed to execute it on the server on which the application will be located. 38. The server according to clause 37, wherein said service module transmits a datagram to other servers from the specified set in order to collect information about application programs corresponding to application programs hosted on these servers. 39. The server according to clause 37, wherein the database includes information about clients. 40. The server according to clause 37, wherein said transmitter transmits information about available applications using a communication protocol via a virtual channel. 41. The server according to clause 37, characterized in that it contains a device for the formation of the final screen frame, which creates the final frames, indicating each program from the number hosted on the servers, which is available to the client system for execution, and a transmitter that transmits the generated final screen frames to the client the system. 42. The server according to paragraph 41, wherein said service module is configured to transmit a datagram to multiple servers in order to collect information about application programs corresponding to programs hosted on these servers. 43. The server according to paragraph 41, wherein the specified device for the formation of the final frame of the screen is configured to analyze templates of SGML documents. 44. The server according to item 43, wherein the specified transmitter transmits information about available applications using HTTP.

Images