WO2002101518A2

WO2002101518A2 - Technique for integrating information from one or more remotely located sources

Info

Publication number: WO2002101518A2
Application number: PCT/US2002/007565
Authority: WO
Inventors: Illan Poreh
Original assignee: Anysoft Limited Partnership
Priority date: 2001-03-05
Filing date: 2002-03-05
Publication date: 2002-12-19
Also published as: WO2002101518A3; AU2002321997A1

Abstract

A solution for integrating and exchanging information between software processes running on remote computers is provided. A Terminal Service Client component and a Terminal Service Server component are installed on the server computer allowing remote user access via a GUI. The client script creates ActiveX control to activate server script and establish communication channel for data exchange. Data exchange includes data capturing, transmitting and displaying.

Description

Technique for integrating information from one or more remotely located sources

CLAIM OF PRIORITY/CROSS REFERENCE OF RELATED APPLICATION(S)

This international application claims the benefit of priority of United States Provisional Application Number 60/273,479, filed March 5, 2001 and United States Provisional Application Number 60/xxx,xxx filed February 11, 2002, entitled "Providing programmatic access to an application's user interface elements." The entire disclosures contained in the above-mentioned applications are incorporated by reference as if set forth at length herein.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE OF AN APPENDIX The accompanying Appendix, which is part of the present disclosure and include information pertaining to embodiments of the present solution as described below, is incorporated herein by reference in its entirety.

BACKGROUND

1. Field of the Invention

The present invention relates generally to data processing and more particularly, to a technique for integrating and exchanging information between software processes running on remote computers.

2. Description of Related Art

Referring to Figure 1, Terminal Server is an operating system from Microsoft® which provides multiple users with an interactive 32-bit desktop environment. With Terminal Server, all processing is remotely performed on the server. It relies on server-based computing through the use of terminals, Windows CE devices or PCs for data input and output. The Win32 user interface is passed to the client (thin client) where it is locally displayed. As keystrokes and mouse clicks are entered, they are sent to the server for interruption and execution. The server then refreshes the local "terminal" screen.

Thin-client users have the immediate benefit of being able to utilize the Windows 2000- hosted applications while maintaining their current and familiar environment. If the server is properly sized, the response time between the keyboard or mouse click and a displayed result should be transparent to the user.

Clients maintain multiple sessions on Terminal Server. Each session mimics a desktop computer for the client. Applications and system programs of different sessions do not collide. Each session has its own input and output facilities and focus window for keyboard input. Windows in different sessions do not overlap.

Applications make API calls to the Win32 subsystem in order to draw data on the screen and get input from mouse keyboard etc. Data records describing API calls and keyboard and mouse input are transmitted through the network between server computer and thin client using the RDP protocol.

For more detail, the reader is urged to refer to the publication, Windows NT Server 4.0 Terminal Server Edition Technical Reference by Brian Craig et al, Microsoft Press, 1999. BRIEF DESCRIPTION OF THE DRAWING(S)

Referring briefly to the drawings, embodiments of the present invention will be described with reference to the accompanying drawings in which:

Figures 1-4 depict certain aspects and features of exemplary embodiments of the present solution constructed in accordance with the teachings herein.

DETAILED DESCRIPTION

Referring more specifically to the drawings and the accompanying Apeendix, for illustrative purposes the present invention is embodied in the system configuration, method of operation and product or computer-readable medium,' such as floppy disks, conventional hard disks, CD-ROMS, Flash ROMS, nonvolatile ROM, RAM and any other equivalent computer memory device, generally shown in Figures 1 -4. It will be appreciated that the system, method of operation and product may vary as to the details of its configuration and operation without departing from the basic concepts disclosed herein. Referring to Figures 2 and 3, a working scheme of an exemplary embodiment of the present solution, sometimes referred to as the Anysoft Multi-Session Server (AMSS), operates as follows: a Terminal Service (TS) Client component and a TS Server component are both installed on the server computer. The AMSS run- time enables indirect end user access to the existing application running on the server via a new GUI associated with the application. The AMSS run-time allows multiple end users on multiple workstations to use server application's functionality per application instance (however, not simultaneously).

Referring to Figure 4, attention now turns to a description of the AMSS architecture.

Session Connector control

The client script creates this ActiveX control in order to activate the server-based part of Virtual User (i.e. server script) and establish communication channel with that part for data exchange. The Session Connector allows the client script to start one server script instance running in separate terminal session or attach to existing one, if the server script is already running and has no active connection to other client. Each session provides independent data communication channel accessible via Session Connector control. Each terminal session (i.e. instance of server script) is able to communicate with one Session Connector control on the client side. If the client script wants to connect to more than one server script, it should create Session Connector control for each connection.

Web Connector

Set of ASP and XML files providing Web interface to the AMSS. This interface can be useful for platform-independent web-based clients that see server-based Virtual User application as a Web service.

Client-Server queues

These 2 one-way MSMQ queues provide transport layer for client-server scripts data exchange. One queue is for sending data from client scripts to the server scripts and another one is for sending data from server scripts to the client scripts. Separation on two queues is done for convenience and considering possible high traffic between clients and server. All client-server communication channels use the same queue pair.

Client-Manager queues These 2 one-way queues are solely dedicated for interaction between client scripts and Session Manager (SM). One queue is for sending client script requests to the SM, which is constantly listening this queue in order to fulfill every client script request. Through the second queue, the SM sends to client scripts information about client-server communication channel queues and server script status. There can be only one Client-Manager queues pair in AMSS configuration.

Session Manager

The module is responsible for running of requested server script in the separate terminal session and establishing connection between client script and server script. It gets the server script name from the client script, runs Terminal Services Client and activates server script inside the terminal session. Also, this control holds information about server script's run-time behavior. It obtains information about server script status by polling Manager-Server queue and reading messages from running server scripts. For interaction with client scripts, Session Manager uses Client-Manager queues. For interaction with server scripts, Session Manager uses Manager-Server queues. There can be only one Session Manager in the AMSS (single-server) configuration. Manager-Server queues

These 2 one-way queues are dedicated for interaction between Session Manager and server scripts running inside terminal sessions. One queue is for sending information from Session Manager to managed server script, which is constantly listening this queue via In-Session control. Through the second queue, the server script periodically sends to the Session Manager information about its run-time status. There can be only one Manager-Server queues pair in AMSS configuration.

In-Session control

The server script creates this ActiveX control in order to be able to interact with Session Manager and client script connected to the particular instance of the server script. The In-Session control has interface for data exchange between server script and connected client scripts via client-server communication channel. It also has interface allowing to periodically inform the Session Manager about the server script's run- time status. Every instance of server script has to contain In-Session control.

The following section describes an exemplary AMSS workflow. To provide a basic yet comprehensive understanding without superfluous complexity, some nonessential details are omitted.

1. Client script creates an instance of Session Connector ActiveX control.

2. This step has two possible actions on the client side:

a. "Connect" case: To start a new connection to the server script, the client script calls Connect method on the Session Connector control and passes a name of the server script as a parameter, say ServerTaskl . This name has to coincide with a name of standard Windows shortcut created with the help of Client Connection Manager program supplied with MS Terminal Services Client software. This shortcut must be created before any using of AMSS. The shortcut has to contain reference to an executable file used as a server script, i.e. program containing In-Session control and serving as a server for AMSS clients.

The Session Connector generates a GUID (ClientGUID) for its unique identification among all client scripts interacting with the Session Manager and sends to the AMSS_ClientToManager queue a "connect" message saying that it wants to connect to particular server script named ServerTaskl .

b. "Attach" case: To attach to an existing server script, the client script calls Attach method on the Session Connector control and passes a SessionID of already running server script as a parameter. This SessionID can be obtained by only previously made Connect call.

The Session Connector generates a GUID (ClientGUID) for its unique identification among all client scripts interacting with the Session Manager and sends to the AMSS_CUentToManager queue an "attach" message saying that it wants to attach to a server script running in terminal session with specified SessionID.

3. a. "Connect" case: The Session Manager gets "connect" message from the Session Connector control by reading from AMSS_ClientToManager queue. The SM executes the MS Terminal Services Client program (MSTSCEXE) passing the name of a server script (ServerTaskl in our example). MSTSCEXE treats this name as a name of terminal connection shortcut to be executed and runs the executable file specified in this shortcut in a separate terminal session. This file is an actual server script containing In-Session ActiveX control.

b. "Attach" case: If the Session Manager gets "attach" message from the Session Connector control, it searches for already running terminal session with specified SessionID in its run-time database.

. a. "Connect" case: On its start, the server script creates an instance of In- Session control, calls its Init method. The In-Session control generates unique numeric identifier SessionID and passes it in "ready" message to the AMSSjServerToManager queue saying that the server script is ready for working with clients. Thus, every server script instance has unique SessionID identifier, which is used for unique client script-server script pair association. This identifier is also used for retrieving MSMQ messages appurtenant to particular client script-server script pair.

5. a. "Connect" case: The SM gets the "ready" message from the server script and marks the server script as "busy". It means that it cannot be used for connection with another client script until it is freed by current client script. 6. a. "Connect" case: The SM sends "session created" message to the Session Connector and passes unique SessionID. From now, the session connection between client script and server script is established.

b. "Attach" case: The SM sends "session created" message to the Session Connector and passes unique SessionID retrieved from its run-time database. From now, the session connection between client script and server script is established.

7. The client and server scripts do data exchange directly using ReadData, WriteData, ServerCall methods and OnDataAvailable, OnServerCall events on Session Connector and In-Session control interfaces. Every WriteData call causes firing of OnDataAvailable event on the other side of client-server connection. Inside this event the script should use explicit call of ReadData method for data retrieving. In many cases, client script can use ServerCall method, which is a wrapper around sequential calls of WriteData and ReadData methods with specified waiting period between them. Using of ServerCall method on client side fires OnServerCall event on the server side, where the server script can perform requested action and return result inside one function call. The data exchange methods on both controls work via independent MSMQ queues pair bypassing Session Manager module. 8. When the client script decides to finish its connection to the server script, it has two choices - 1) terminate the connection completely (using Disconnect method) or 2) temporarily interrupt current connection (using Detach method). 1) On Disconnect call, the Session Connector sends "disconnect" message to SM. The SM sends "disconnect" message to the server script. The In-Session control fires OnDisconnect event, where the server script can prepare itself for shutdown. Then it sends "terminate" message to In-Session control and remove reference to this server script instance from its run-time database. 2) On Detach call, the Session Connector sends "detach" message to SM. The SM marks the server script instance as "free" and sends "detach" message to the In-Session control. The In-Session control fires OnDetach event, where the server script can prepare itself for connection with the same or new client script later (stays in intermediate state).

9. WTien the In-Session control gets "terminate" message, it fires OnTerminate event, where the server script can free its resources. Then, In-Session control logs off from the terminal session. The terminal session is closed. 10. When the server script decides to finish its job, it calls Terminate method. In- Session control sends "terminate" message to the SM and logs off the terminal session. The SM removes a reference to the server script instance from its run-time database and sends the "terminate" message to the Session Connector control. The control fires OnDisconnect event, where the client script can perform some actions needed upon connection termination.

11. During its runtime, the server script has possibilities to inform the SM about its current status by calling of SignalReadiness, SignalMessage, SignalError and SignalFatalError methods. Inside these methods, the In-Session control sends "signal" messages to the SM, which holds this information for monitoring needs .

Additional embodiments are provided for in Appendix A, the disclosure of which is set forth at length herein

Having now described a preferred embodiment of the invention, it should be apparent to those skilled in the art that the foregoing is illustrative only and not limiting, having been presented by way of example only. All the features disclosed in this specification (including any accompanying claims, abstract, and drawings) may be replaced by alternative features serving the same purpose, and equivalents or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present invention as defined by the appended claims and equivalents thereto.

Moreover, the techniques may be implemented in hardware or software, or a combination of the two. Preferably, the techniques are implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device and one or more output devices. Program code is applied to data entered using the input device to perform the functions described and to generate output information. The output information is applied to one or more output devices.

Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system, however, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Each such computer program is preferably stored on a storage medium or device (e.g., CD-ROM, hard disk or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.

APPENDIX A

Anysoft Multi-Session Server Architecture

Terminal Server Description

Terminal Server is an operating system from Microsoft intended to provide multiple users with interactive 32-bit desktop environment.

With Terminal Server, all processing is remotely performed on the server. It relies on server-based computing through the use of terminals, Windows CE devices or PCs for data input and output. The Win32 user interface is passed to the client (thin client) where it is locally displayed. As keystrokes and mouse clicks are entered, they are sent to the server for interruption and execution. The server then refreshes the local "terminal" screen.

Thin-client users have the immediate benefit of being able to utilize the Windows 2000-hosted applications while maintaining their current and familiar environment. If tire server is properly sized, the response time between the keyboard or mouse click and a displayed result should be transparent to the user.

Clients maintain multiple sessions on terminal Server. Each session mimics desktop computer for client. Applications and system programs of different sessions do not collide. Each session has its own input and output facilities and focus window for keyboard input. Windows in different sessions do not overlap.

Windows NT Teπtririal Server

©... and user

O Applications interface execute on displays here..

RDP Protocol

Applications makes API calls to Win32 subsystem of operating system in order to draw data on the screen and get input from mouse keyboard etc. Data records describing API calls and keyboard and mouse input are transmitted through the network between server computer and thin client with the help of RDP protocol.

"Any system" running in each session intercepts these API calls in order to capture data to be drawn. Therefore we are not interested how and where data is redirected to the thin client. We are not interested in thin client at all. We are opening session with minimized client window on the server and nevertheless we get data from application as if it is drawn on the entire screen. Terminal server provides us with capability to open window of session on server run application in this window and then minimize this window. There are other possibilities such as opening sessions window on so called virtual invisible desktop on server and then all the traffic of data records describing API calls and keyboard and mouse input will occur between virtual desktop and application inside server.

(Here I reproduce excerpt from my previous description with some improvements)

Virtual User (VU) Concept.

As it was disclosedin our previous applications it is possible to capture data drawn by application in GUI window on the screen. Application makes API calls to Win32 subsystem of OS Windows. These calls are intercepted by "ANY" system and drawn data associated with this calls is captured and stored in internal buffer of "ANY" system. It is possible to control any application with GUI interface with the help of software program, which emulates mouse and keyboard events.

User-written program of the present invention run cooperatively with application and control and capture data from it. Theses programs are called Virtual User applications in the present description. VU application emulates the functions of human in two-fold manner. It controls the execution of application by emulating mouse and keyboard events and it get access to and capture the data drawn on the screen by utilizing facilities of "ANY" system. Software emulation of mouse and keyboard events such as mouse clicks and moves and pushing buttons on keyboard is a well-known method to those skilled in art. VU applications control execution of application through its GUI interface by emulating user events in software. Data capturing from the windows of application is described in our previous patent application.

Thus VU application from one side forms requests to application by forcing it (application) to execute certain activities such as opening and closing windows pushing on buttons and menu items selecting parts of window text etc. From other side virtual user captures data from predetermined parts (regions) on window of application. This data also can determine control flow in VU application.

VU application usually sends captured data to some client application or other VU. Requests of VU application can be parameterized by some other client application interacting with VU application through some type of interprocess communication facility such as Remote Procedure call or Message Queue. For example if we have database with GUI window which shows name of employer and its address such as: Bush Texas

Gore Connecticut VU application is constructed so that given name of employer it must return in response its address. Then if client application sends to VU name "Bush" then VU must return to client "Texas" and "Gore" - "Connecticut".

From this point of view VU application can be considered as a database manager, which processes client requests. It is clear that form of request and form of response are fixed in this approach.

In this Fig Client application which runs on Server computer sends requests to and receives responses from VU application. The interaction between Client application and VU application is implemented through interprocess communication facilities provided by OS Windows.

Client applications can run not only on Server computer but also on other computers. These client applications must communicate with VU applications on Terminal Server in order to send requests and acquire captured data in responses. In the example demonstrated below application with data drawn in its GUI interface VU application capturing data from this application run on Server computer and Client application runs on another computer, which communicates with Server computer. Method of communication can be arbitrary. Client application sends requests to VU and acquires captured data from VU. Excessive details from the previous Fig are avoided.

Clients communicating with VU applications on Server computer(s) constitute distributed application with loosely coupled architecture. Parts of distributed application can communicate through HTTP protocol to move information. Another option is to use a remote procedure call (RPC) protocol such as Microsoft RPC or its object-oriented counterpart Distributed COM (DCOM). Distributed applications can communicate via messages sent using Microsoft Message Queue Server (MSMQ). Mixed solutions can also be used. For example, client application can communicate with intermediate agent on server computer server computer through HTTP or DCOM and this agent in turn communicates with VU applications through MSMQ.

We need to provide the possibility to process requests from multiple clients as fast as possible. Therefore it is desirable to run multiple instances (copies) of VU application together with multiple instances of application from which VU captures data as it is demonstrated on the following FIG.

Each instance processes messages from client applications and sends results to these client applications. Terminal server provides the possibility to run such configuration so that pairs VU- Application will run in different sessions without colliding with each other because each session has independent window system and input output system.

Messages which are sent from client applications into the common for all VU's input message queue, and results are stored in the output message queue. These queues may coincide.

VU application may have two states. It may be in "busy" state, while processing the request from client or in "free" state which means that it is ready and can process new request. The special component Session Manager is responsible in current architecture for managing communications between client applications and VU. It supports current list of VU applications and their current states (busy or free). If all the VU applications are busy it can start new session with new VU.

When new message appears in queue Session Manager establishes communication between client application and VU so that client and VU can exchange input and output messages.

Client applications can communicate with message queue through different facilities such as RPC,DCOM,HTTP or MSMQ.

Data captured by Virtual user from Window of application can be utilized in new GUI on the client application. Therefore we have new application on the client side, which, reproduces parts of the functionality of application on the server side.

The last picture is not exact because at the beginning client application and VU establish connection through Session Manager and after that they exchange data directly with one another.

But this data exchange proceeds through the limited (one or two) number of message queues

27

Claims

CLAIMSWhat is claimed is:

1. A system for providing a GUI on a screen of a terminal at a first location with information controls from a GUI of an application running on a server at a second remote location, said system including:

means for capturing select information from said GUI of said application running on said server;

means for capturing select controls from said GUI of said application running on said server;

means for transmitting said select information and said select controls from said second remote location to said first location; and

means for displaying said select information and said select controls on said screen of said terminal of said first location.

2. A method for providing a GUI on a screen of a terminal at a first location with information controls from a GUI of an application running on a server at a second remote location, said method including the steps of:

capturing select information from said GUI of said application running on said server;

capturing select controls from said GUI of said application running on said server;

transmitting said select information and said select controls from said second remote location to said first location; and

displaying said select information and said select controls on said screen of said terminal of said first location.