KR19980086684A - Systems, methods, and apparatus for interactive internet access to host computer application programs - Google Patents

Abstract

A variant of the host based data processing application, which is made interactively run and available through the Internet functionality. The improved server provides interactive communication management capabilities that facilitate the exchange and transfer of requests and data between remote clients and remote host application programs in a manner that is transparent to client and host applications. The server has a computer executable program step that enables assigning a unique identification token to the client workstation requester of the host-based application program response. Tokens are used by servers and host applications to identify clients to properly facilitate and pass data and requests between communicating entities. In addition, the client or workstation browser or operating system facilitates access and sends requests to the server to initiate and maintain a conversation with a remotely located application program whose actual location may not be known to the requesting client. Executable program steps.

Description

Systems, methods, and apparatus for interactive internet access to host computer application programs

Field of invention

FIELD OF THE INVENTION The present invention generally relates to computer systems, and more particularly to application programs in host computer systems attached to the Internet or computer networks, such that remote computer users at workstations can interactively access host computer-based data processing applications over the Internet. A system, apparatus, and method for running interactively.

Background of the Invention-Conventional Technology

Recently, there has been an explosive growth on the Internet, especially the growth of the World Wide Web (WWW), one of the major functions provided for accessing and using the Internet. WWW includes a large number of files or pages distributed over a network on different servers. Each page or file is identified by a universal resource locator (URL). The URL indicates the identification and location of the server machine on which the particular page or file is mounted, and the specific file or page mounted on the server machine. Many pages or URLs can exist on a single server.

To use the World Wide Web, a client or user runs a piece of software that includes an executable search engine, often called a web browser. Web browsers, such as IBM's WebExplorer or Netscape Communication's Navigator (trade name), are browser programs that can be used on most personal computer or workstation operating systems. The user interacts with his browser program running on his workstation to specify and select a particular URL to be accessed. Thus, the browser program sends a request to the Internet system to locate a particular URL or page. This request is forwarded to the specific server identified by the URL.

In general, the server will respond to receipt of such a request by retrieving the requested page and sending the data for that page back to the requesting client or user. In this situation, the user's workstation communicates in a server-client relationship. The flow of data and control information between them is carried in accordance with the Hypertext Transport Protocol (HTTP). The data or page of retrieved information is displayed on the user's workstation display screen. Operation at the client workstation can also cause the server to launch an application on the server (eg, invoke execution of the application). For example, a search program may be called to search the world wide web for a particular topic.

Most commonly, WWW pages of information or data are formatted according to a language known as Hypertext Markup Language (HTML). A typical HTML page is used to control other display controls such as font size, font style, page layout formatting, highlighting, and the like, and includes text along with embedded formatting commands, referred to as tags. The web station of the client station will parse the HTML script to display the text contained therein according to the HTML specific format. In addition, the HTML encoded page of data may contain, for example, a reference to another URL identifying another server and, for the sake of naming, one multi-media data such as, for example, an image, video segment or audio file. Contains pages for. The web browser responds to such embedded references by retrieving and displaying or demonstrating data when the embedded reference is selected or activated by the user. On the other hand, such multi-media data can form its own WWW page without any surrounding HTML text and can be retrieved as a multi-media display in itself.

Most WWW pages also contain one or more references to other pages and they do not have to be on the same server as the original page. Such a reference can generally be activated as mentioned above by the user selecting a particular position on the screen (usually by clicking or double-clicking a mouse control button or by making a certain selection instruction). These references or locations are known as hyperlinks and are generally flagged by the browser in a particular way (ie, the browser may, for example, highlight text associated with the hyperlink in a different color or brightness). When the user selects a hyperlink, a reference page is retrieved and used to replace the currently displayed page of data.

Although a great deal of information is published on the topic, specific information about the HTML language and the World Wide Web is named World Wide Web at HTML by Douglas McArthur, pages 18-26 of the Doctor's Dobs Journal, December 1994, December. And the HTML Source Book by lan Graham, published in 1995 by John Wiley, New York.

Broadly speaking, as described so far and currently being implemented, the World Wide Web has the disadvantage that pages downloaded from a server to a client workstation are inherently passive and typically do not contain code that runs on the client machine. This means that the server cannot normally offload any processing associated with the conversation between the client and the server on the client station. Thus, if the client completes a form with, for example, a user's telephone number, some formal check (such as the number of digits in the telephone number) must be performed in the data processing application running on the server. This results in, firstly, an excessive processing burden on the server, and secondly, time-consuming additional communication between the server and the client if there is any mistake in the data entry that needs to be corrected. Moreover, since the server cannot download code for execution of the client, the type of application that can be created to take advantage of the features of the World Wide Web is limited. Fortunately, this problem has some potential solution.

In particular, recent advances based on Sun Microsystems' Java ™ programming language and technology have been made to overcome these difficulties. This technique first includes a new language, similar in content to C and C ^++, and secondly, a virtual machine that runs programs written in that language. Programs written in the Java programming language can be compiled in bytecode form and then interpreted at runtime on the Java virtual machine itself. The Java virtual machine translates bytecode into instructions for execution by an underlying physical computer processor (ie, the processor on which a given Java program is executed).

Programs written using the Java language can be downloaded via the WWW in bytecode for execution on a Java virtual machine on the client. Such programs have been known as applets. The use of Java technology to download applets over the World Wide Web has two advantages. First, an applet may be independent of the platform to be executed because it will be translated by the Java virtual machine, which is typically incorporated into the operating system itself or executable code of a web browser located at a client station. Each client machine will normally have a copy of the Java virtual machine present in one way or another for this purpose. As a result, the server does not need to have different versions of the code for download to the client depending on each operating system and machine requirement. Therefore, only a single version of the relevant code needs to be written and maintained. This simplifies the development and maintenance of applications for software developers. Second, because the application runs on the virtual machine rather than on the physical machine, the security of the physical system is greatly improved. For example, when downloading code over a network, there is always a risk that a malicious person may accidentally include harmful code or otherwise corrupt the user's data or programs on a client workstation. The virtual machine can monitor the behavior of the applet. If harmful code or activity is detected in the virtual machine, their actual execution on the physical machine can be easily stopped.

It should be noted, for example, that the concept of downloading software from a server to a client in the form of bytecode for execution of a virtual machine, as shown by US Pat. No. 5,437,632, is known earlier than the Java technology itself.

To invoke the execution of a Java applet, the web page of HTML text will include the tag applet in the HTML tag language standard, which identifies the URL containing the applet. The browser at the user's workstation will respond to this tag by retrieving and running the applet from the specified URL. It can also be defined in the HTML format as a param tag contained within a pair of corresponding applets and / applets, which can be used to specify parameters that are passed to the applet at runtime or execution. Note that applets and param tags are not formally incorporated into the HTML standard, but are never less recognized and used less by many web browsers. Additional information about Java technology and the applet itself can be found, for example, in Teach Yourself Java in Twenty One Days by Laura Lemay and Charles Perkins, published by Sams.Net Publishing, Indianapolis, Indiana, USA, 1996. have.

However, the process of downloading an applet to run on the client's workstation is not without difficulty. One of the difficulties of this approach is to limit the amount of information that can be included in applet tags. This can cause a problem that requires the user to decide whether to download a particular applet referenced in an HTML page. For example, you may not want to download an applet that is particularly large and slow to send over the network, or you do not care whether your application requires a more recent version of the Java virtual machine than is installed on the client's workstation. Can be. A second disadvantage associated with applets is that host-based applications, which are common in many users' networks and are now commonly accessed by workstations directly connected through routers and other communication switching and message handling functions, normally It is not included.

Network access from host workstations to host-based application programs for execution on mainframe computers is a process that has long been familiar to those skilled in the art but has not been available over the Internet and the World Wide Web. There are many reasons for this. First, general access to the public is available through the World Wide Web by simply specifying the URL of the desired resource. Host-based computer applications, however, are generally licensed-only programs and are generally only available to authorized users, not public. Within the context of a carefully controlled communication network between a user workstation and a host computer, authorized access programs, time-based lease or lease charge programs, and safe and non-privileged usage detection programs are commonly used, but they are all common publicly granted. Inadequate for access, it is planned to take the lead in the Internet domain. Second, the interface with a host-based computer application program by a user at a remote location generally requires the establishment of a logical and physical connection link, the concept of session, i. Introduces a history of exchanges between the user and the application program in the period in which it must be maintained or vice versa. The Internet domain does not normally provide a fixed, continuous connection, but may be further operated on the request and response format, once the request is made and no communication takes place until the request is received by the intended responder.

The asynchronous nature of requests and responses and the lack of unique connection paths (paths to and from a given location can vary widely from communication to communication to two entities on the Internet) can be attributed to remote user and host-based applications on client workstations. It further exacerbates the problem of maintaining a session to record historian conversations historically and accurately. Indeed, the identity of the actual user may not be entirely known in the host-based application. For example, if a browser or server indicates the browser's application needs for host-based applications, there is only a request or inquiry followed by a response or download, not a continuous conversation. There is no continuity of logical or perhaps physical connections and the link will have to be recreated for some other response and request scenario. Such a conversation mode, in particular a conversation mode with a plurality of potential clients or users of an application program, may be used to maintain the execution of an interactive request response scenario and also to download the entire host program and data in order to monitor historical activity. Or, in fact, the client does not normally have permission to do so, and because the host usually does not know the identity of the client it is requesting, it must maintain uniqueness and historical session records at either the host location or the workstation. This represents an extremely complex problem.

Finally, in order to block non-privileged access or to protect a user from unwanted accessibility, many users and systems have full bi-directional communication communications between users and the Internet, or between users and application programs. Install what is called a fire wall between the Internet and resources such as host computers that prevent initial configuration. Since the actual physical location and identity of the user and / or application program may not be known to the parties at each end of such exchange, it is impossible to address the message directly with another.

These problems are aggravated given the possibility that clients do not want to download application programs from the server but may want to access them interactively on host-based resources. In addition, such host computers are typically extremely large application programs, such as other multi-media processing functions such as Central Data Bases, High Speed, Image Intensive Editing, 3-D graphics, and the like. It provides processing load capability and very large capacity data processing that requires the execution of. In addition, such host-based applications may be physically too large to be downloadable or not downloadable due to license use restrictions. Continuous use has a legacy of a variety of host-based businesses and data processing applications, and uses the Internet and the World Wide Web to connect remote users without compromising physical safety and the access and license restrictions normally applicable to host-based programs. It would be most desirable to facilitate them for interactive access and execution.

In view of the above known difficulties in the prior art, an object of the present invention is to provide an improved method, system, apparatus for enabling interactive use between a user at a remote workstation and a central or host computer running an application program. will be.

Another object of the present invention is to provide an improved server that manages the exchange of interactive processing information between a host-based application program and a remote client in a manner that maintains the security of a firewall communication barrier and the like.

It is yet another object of the present invention to provide an improved host application with the ability to communicate and communicate with servers in the world wide web and internet environment.

It is yet another object of the present invention to provide an improved client computer system that interactively communicates with a remote host computer-based application through the functionality of an Internet server.

1 illustrates an applet or client implementation to facilitate a connection to a server to present a user's request to access, use, and interact with a remote host-based computer application program (remote). Diagrammatic representation of the process flow of a viable process.

FIG. 2 is a schematic diagram illustrating a process flow of steps executed on an Internet server computer for managing a request from a client or user computer received over the Internet for access to a host based computer application.

FIG. 3 schematically illustrates process flow steps executable in an Internet server processor for receiving client requests over the Internet and initiating and managing invocations of host-based computer applications over the Internet at some other remote location.

4 schematically illustrates process steps executable in a processor of an Internet server for managing the flow of communication from and to a remote host-based application program over the Internet.

5 schematically illustrates process steps executable in an internet server processor for managing a conversation with a remote host-based application over the Internet.

6A and 6B schematically illustrate process steps executable in an Internet server processor to manage communication from a remote host-based application program for a requesting client through the Internet function.

7 schematically illustrates process steps and flows executable in a host processor for managing communication between an application program and an Internet server processed in the host processor.

8 is a schematic representation of an exemplary workstation or personal computer hardware environment in which the present invention may be practiced, implemented in computer executable process steps.

9 is a schematic representation of a data processing network in which there may be internet or world wide web functionality in a preferred embodiment of the present invention and responsive to a user;

The above and still other purposes not specifically listed are improved servers with interactive communication management capabilities that facilitate the exchange and transfer of requests and data between remote clients and remote host application programs in a manner transparent to the client and host applications. Along with providing a modification of the host-based data processing application to be executed and used interactively through the functionality of the Internet is achieved by the present invention. The server has a computer executable program step that can assign a unique identification token to the client workstation requester of the host-based application program response. The token is used by the server and the host application to identify the client for proper use and passing of data and requests between entities in communication. In addition, the computer execution of the client or workstation browser or operating system to send requests to the server and facilitate access to initiate and maintain conversations with remotely located application programs that may not be known to the client whose actual location is required. Possible program steps are provided.

In a preferred embodiment, an applet may be provided to the client workstation to cause the browser or operating system at the client workstation to present the request to the server. In addition, the server itself initiates a request for a remote host-based application and initiates a computer executable program step for responding to a request from a client user and assigning a unique token to identify a communication session with a particular client user. Providing the token with a request to call the computer executable program step, receiving the response from the application, and providing them using, for example, a shared pointer to memory to the identified client or user. An improved computer executable program step is provided. Thus, the server may include (1) a program step serving a client in a server communication process, (2) a program step serving a communication from a client designated for a host application, (3) handling communication between a host application and a server, ( 4) A set of executable programs is provided that consists of handling communications from an application on a host designated as a client.

The implementation and usefulness of the preferred embodiments within the context of the physical environment, which will first be described briefly with reference to FIGS. 8 and 9, illustrate the invention with reference to the drawings showing the preferred embodiments in FIGS. 1 to 7. Let's do it.

Referring to FIG. 8, there is schematically illustrated a representative workstation or personal computer hardware environment in which the present invention may be practiced. As shown in FIG. 8, such an environment may include, for example, a personal computer, workstation, network, including associated peripherals and memory, including a communication adapter or modem for access to the Internet, LAN, or other extended environment. A representative single user workstation 10 such as a computer is included. Network computer or workstation 10 is generally associated with microprocessor 12, which is adapted to connect and enable communication between microprocessor 12 and memory and other components of a workstation system in accordance with well known techniques. And a bus 14. Workstation, network computer or personal computer 10 generally includes a user interface adapter 16 for connecting microprocessor 12 to one or more various interface devices, by bus 14. Such devices are well known and include a keyboard 18, a mouse or other selected cursor device 20 and / or a touch-sensitive screen, a digitized entry pad, a speech recognition device having a speech recognition program code appropriate for the memory of the processor, and the like. And other types of interface devices 22 to include. The bus 14 also connects a display device 24, such as an LCD screen or CRT monitor, to the microprocessor 12 via the display adapter 26. In addition, bus adapter 14 couples the microprocessor to memory 28 and permanent storage device 30, which may include a hard drive, tape, disk, CD ROM, and the like. The workstation 10 communicates via a communication adapter or modem 32 to a communication network and is logically or switched through another computer or distributed communication network facility having a variable interconnect link that varies independently over time. It communicates with a network of computers that can be physically accessed by connection and direct cable. Such environments are common on the Internet and the World Wide Web, where multiple computers, workstations, and servers can communicate with each other. The workstation 10 may be associated with such other computers in a local area network (LAN) or wide area network (WAN), or the workstation 10 may be connected to many other computers in the network to enable communication with other computers. It may be a client in a typical client server arrangement present in a WWW configuration. Likewise, as already mentioned, workstation 10 may be a network computer and does not require a full operating system or permanent storage device or its own hard drive, commonly found in most normal computer workstations and personal computers. You may not.

With reference to FIG. 9, a schematic configuration of a typical data processing network that may represent a portion of an internet network or the like is shown as network 40. Data processing network 40 may include a plurality of individual networks that may asynchronously communicate with others, including LANs 42 and 44, each comprising a plurality of individual workstations 10. On the other hand, as will be appreciated by those skilled in the art, it may include a number of intelligent workstations, personal computers, or network computers coupled to a host processor that may have a host processor resident application program. A plurality of mainframe computers, such as computer 46, may be connected to the LAN by physical or logical (ie, Internet or World Wide Web) communication links 48 as shown in FIG. 9.

Mainframe computer 46 may be implemented in any of a variety of configurations well known in the art, and may include a large number of host resident application programs. The mainframe computer can also be coupled to a storage device 50 that can be provided as a database accessible from a LAN or as a remote central storage device for a LAN, and other local or remote areas in the Internet or WWW environment. The LAN itself may be coupled to the physical or logical Internet or world wide web communication link 52 through subsystem control such as controller 54 and communication link 56 to the gateway server for final access to the network and workstation. Can be. Gateway server 58 is preferably an individual computer or intelligent workstation, which serves to link LAN 42 in FIG. 9 to LAN 44.

Those skilled in the art will readily appreciate that the mainframe computer 46 may be located geographically much away from the LAN 44 and thus located substantially away from the LAN 42. LAN 44 may be located in Texas, while mainframe computer 46, including for example a central database such as a data mining engine and an application program, is located in New York, for example. LAN 42 may be located in Southern Carolina. Both of these facilities can be interconnectable or physical networks using logical addressing to be independent of any particular physical communication link technology that may be employed. That is, these elements are the Internet or world posed today that many computers, servers, and workstations are all freely accessible to each other, usually by telephone access links, using modems and access control computers operated by access providers. It can be used in the same way as the wide web.

The present invention is generally embodied as software programming code executable on a processor operating as a server in such a network. The computer executable code may be stored in some form of permanent storage, such as permanent storage 30 of workstation 10. In a client / server environment, however, the software program code will generally be stored in a storage device associated with the server computer, such as storage device 50 associated therewith when the computer 46 operates as a server in FIG. 9. The programming software or programming code of the executable program stage in which the present invention is embodied may be itself any arbitrary media known for use in data processing systems such as floppy diskettes, cassette tapes, hard drives, CD ROMs, programmable ROMs, and the like. Can be implemented. Code may, in fact, be distributed on such media to a user from storage or memory of one computer system via any of various forms of communication networks, to other computer systems for downloading and use by users of such systems, or Distributed to users. Techniques and methods for employing software program code in machine executable form on physical media and for distributing or embodying the code locally by a network are all well known and will not be discussed further herein.

As a typical situation for the present invention, a final host computer, such as computer 46, generally operating as a host application computer system as shown in FIG. 9, which may include a telephone network, a gateway server and communication link, a controller and a LAN. By using a facility of the Internet that includes a web browser running on a client's workstation that accesses a network server such as server 46 in FIG. 9 through communication facilities, as shown in FIGS. An individual user at 10 may wish to communicate with an existing, host-based, data processing application. Gateway server 58, as shown in FIG. 9, includes data or files or programs whose users at workstation 10 and local area network 42 are accessed by non-privileged users from outside of local area network 42. FIG. You can implement a firewall protection program or routine that prevents you from having it. Similarly, host computer 46 may be configured to prevent unauthorized access to a remote central storage device for a LAN or server as represented by storage device 50 in FIG. 9 or from access by an unauthorized user, Firewall protection can be implemented to protect files and applications.

For various reasons already found in the context of the present invention, the physical system may be as shown in FIG. 9, but passes through existing firewall protection to the host application running on the host computer from the workstation 10 via an Internet facility. The actual ease of access of has never been possible in interactive mode. In this interactive mode, a user at a workstation (who could not have permission to access an existing application on the host system 46 and even did not know its location) would nevertheless be on the host computer 46. It is serviced by a server, such as gateway server 58, in accordance with a preferred embodiment of the present invention to perform interactive data processing tasks with the application program mounted thereon.

Previous workstations 10 could not use their browsers to establish interactive sessions with host applications running on MVS or other computer systems, unless the MVS host computer was also running a web server as in the Internet environment. The MVS system in the prior art has enabled communication and the establishment of a processing session between a remote user and a given application program only if the application program and the MVS system are run on the same computer. Such an arrangement, as well as the cost of providing a large number of network servers, essentially one for each host computer function for the host application on which it is built, is nearly compliant with the needs of a distributed Internet WWW accessing environment. Can not. In addition, even if such an environment is provided, complex access for every host function to protect the application programs that are embedded there from various potential users using them from a workstation to access and access the Internet over the Internet. Authorization facilities are required. All that a user should have is the URL of the desired application so that any browser can access an application on the host computer that also runs on the same computer as a network server if the server recognizes the request for a given URL in a typical Internet environment. would. The server typically only knows the physical location of the requestor in the network, not the actual user's identity or the actual level of authorization for access and use of their application program.

In order to be truly useful, the present invention is intended to facilitate access from any path through any browser or the Internet to a server having knowledge of where to access the required URL for an application program requiring interactive use. Will want. This means that the location of the computer on which the desired program runs is located behind the Internet firewall, where the appropriate access parameters for accessing the application program behind the firewall are provided in a secure form to the network server and protected from individual network workstation users and their browsers. You can do that. For example, a given network user with knowledge of the desired URL (eg, from browsing the network for a facility with the desired host-based application available) may use the URL identified from the workstation browser to request it. To present. The network server can receive the URL request, identify the identity of the desired application program from it, and invoke the request for additional parameters, such as the appropriate authorization suggested by the user at the workstation in question before the invocation of the host-based application begins. have. On the other hand, the network server processor, upon receiving a request for the URL, before the user is granted access to the requested URL of the application program, in the browser prompting the user to provide an authorization code, a charge code, or the like. Pass an applet that requires execution.

A typical example is that a user at a given workstation as shown in FIG. 9 is typically run in a complex screen panel presentation and MVS operating system on a mainframe computer or host, such as computer 46 in FIG. 9. You might be in an Internet environment where you may want to talk to a typical host-based application program, such as the Interactive System Productivity Facility (ISPF) provided by the editor IBM. It will be assumed that gateway server 58 in FIG. 9 is operated and programmed as a network server in the present invention. The various functional processes implemented in conjunction with the application programs thereof at the workstation 10, the network server 58, and the host computer 46 will then be described in sufficient detail as indicated in the preferred embodiments of the present invention. .

The overall operation of the present invention is in the process 12 of the user's workstation 10 to indicate, within the Internet environment, a location that does not need to be known to the user, a known URL for access to a given application running somewhere. It is to connect a user at a given workstation 10 to a network server 58 using a browser running. In response, the server 58 executing its executable process in accordance with the present invention, in response to receiving the URL, sends an authorization security request or applet for the authorization parameter to the user, or It is possible to generate and assign a unique identity token to the client 10 with the specified service. As another example, the applet may prompt the user to supply the necessary authorization or fee codes to the network server 58 as parameters for inspection and use. When this type of conversation is complete, the server 58 passes the token of the user assigned as one of the launch parameters to the desired application as soon as it is invoked, thereby requiring (i.e. presumably being required on the host's MVS system at a location known to the server). Will launch an application (protected from user at workstation 10). In response, the desired application will be launched and reconnected to server 58 which requires a logical connection with the client known by its token that was received by server 58. The memory of server 58 then executes an MVS or other host operating environment with a client using a shared logical communication port number as a way to match incoming data from an application with a request from a given client. It will be used to pass data between applications or vice versa.

In the context of the preferred embodiment, assume that the applet runs in the browser of the client's workstation 10 and is independent of whether the applet is always present or delivered in response to a request from the user at the workstation to the server 58. . Once the applet is invoked, the initial process as executed on the client workstation is shown in FIG.

In FIG. 1, the client applet starts execution at block 101 and obtains the necessary parameters from a web browser running at processor 12 of workstation 10 as shown in FIG. 8 at block 102. The parameters may include the user's identity, an appropriate authorization code or fee code, or other parameters needed to send a valid request to the server 58 of FIG. 9. In general, HTML data including applets and their parameters will be passed from the server to the browser. In block 103 the client applet is generally allowed for automatic connection by parameters for the desired application obtained from the applet received from the network server by the browser, or because the application is for non-limiting use on the Internet. Decide if you can. If the automatic connection query in box 103 is YES, then the client applet sends a connection request to the server as shown in box 104. However, if the automatic connection parameter does not appear as tested in box 103, an additional prompt will be generated at box 106 and will require input from the user. For example, an authorization code, fee code, and the like may be required at box 106 and then transmitted by a process step at box 104 as a connection request from box 105 to a network server. Wait for a response from the network server as shown in block 107, including additional prompts for the desired communication authorization token or parameters for the expected information. Box 109 examines the response received at box 107 to see if the connection was accepted at the server and if the answer is no, and the user is notified of an error at box 112 and block 110. Asks the user if a reconnection attempt is required, and if so, at block 112 the user provides input to reconnection test block 113. If the answer to whether reconnection is required is no, the application exits at block 114, if no, then any additional information is obtained from the user to generate a connection request and block 106 to block 104. Is delivered again.

However, if the connection is received at block 107 and accepted by a response as tested at block 109, the application data is received from the network server at block 108 and processing of that data is terminated at the end of the routine or As shown in block 108 until the operation is stopped by the user, at which point the user is prompted again to determine if reconnection is required as shown in block 110, and at block 112 The user at may respond with block 113 as indicated with the input.

All previous functions are preferably executed in a machine executable program process step that is provided to the client workstation 10 with the user as well as can be performed by the network server 58 as shown in FIG. 9 if required. do. Normally, for use with a typical browser program at the Internet client workstation 10, these are shown in FIG. 1 for execution at the workstation to prevent unnecessary and time consuming communication traffic between the workstation and the server. Providing a function would be more effective.

Referring to FIG. 2, a general and schematic flow of operations executed in network server 58 in its processor by executing machine executable program steps is shown. The server begins at block 115 and includes a configuration file in storage 117 to provide configuration data for setting up operations to the server as shown in block 116. Read configuration data from configuration file. In block 118, the client thread or process is at the server to manage the teachings from the incoming client to connect to various available host application programs or the like according to the configuration data from the file 117. Begins. In block 119, the server starts an application processing thread or process, shown in greater detail in FIG. 5, as shown in greater detail in FIG. 3 to manage communication between the server and the required host application. In block 120, the network server displays the system state and is ready to process the request or user conversation until it is stopped at some point in the future, as shown in block 121.

As shown in Figure 2, the main thread of the network server process performs the following specific functions. First, general server information is obtained from its configuration file 117. The configuration file includes an application port for receiving an application request; Application call maximum wait timeout parameter for any application waiting for a client; The application maximum waiting time default number for an application of a default number for a particular application name that can wait for a client at one time, and an application file that is the location of application-specific information required for the application invocation. ; It includes the system file, which is the location of system specific information that runs the network server, and the workstation maximum timeout parameter for the maximum timeout for clients waiting for a connection to the application, as well as the identification of the workstation port for client requests. It can also get specific information for each application that the server supports access to. Application-specific application information includes any application default, the system default to run the application (if it needs to be started), and the maximum number of waits for a connection to the application with a given name that can wait for client input at any one time. do. The main thread can also obtain system specific information for each system, including the system address for the system being requested if the system names are different.

In FIG. 3, the operations or subprocesses that the network server processor executes to establish and manage incoming requests from client workstations are shown. The client thread or operational process begins at block 122 by invoking wait for a client connection request at block 123. When a connection request is received from a client applet, it is checked at block 124 to extract information about the application being requested, and at block 125 the contents of the application awaiting connection table 126. A test is made to determine if the currently requested application is connected by checking. If the answer is that the application is currently connected, then the client communication thread starts at block 127 and the client thread at the server returns to block 123 to wait for further client connection requests, as shown in FIG. If the application is not currently available as determined at block 125 from the contents of the application wait connection table at block 126, then the application is started or not as shown at block 126. If the application is not started at this time as it was not required to be started by the user, block 126 indicates the start of a client communication thread at block 127 and waits for further client communication at block 123. If the requested application was required to be started as determined in block 126, a job control language for the requested mainframe or host application is obtained from the job control language file 128 on the server and the user identification, token, main Responses from the frame application are customized to the server port number to be given, and the job control language load is submitted to the job execution system mounted on the host at block 130 and requested there as shown in block 131. The host starts processing the loaded application.

The server client thread as shown in Figure 3 waits for the client to connect to the client port, and a unique connection (which can be generated in any arbitration manner, such as assigning sequential numbers, generating CRC remainders in the client's application request, etc.). Provides the ability to assign tokens to clients. It also contains the name of the desired application, the maximum time to wait for the application to start, a flag indicating that the application should be started if it is not already connected, the address of the system where the application is to be started, the user ID and password, If necessary, connection information is obtained from a client that includes optional information such as any application-request information including them. It will also determine if the flag indicates that the application is unavailable and the application is being started, and will send a request to the particular system to start the application.

In FIG. 4, a subprocess in a network server for managing communication with a client workstation is schematically illustrated. The client communication process thread starts at block 132 and determines in box 133 as to whether the application being requested is currently available by examining the contents of the application wait connection table 126. If the application is not currently available, a check is made at block 124 to see if the timeout has ended, and if not available, an increase in wait time is set at block 135, where there is a check for availability. The process loops back to block 133 until the timeout ends or becomes available, so the output of block 134 notifies the client that the application is unavailable as shown in box 138, The client applet is notified at block 140 and the disconnection at block 139 and termination of this operation of this thread is performed. This subprocess is repeated at the server for each separate active client.

However, if the application is available as determined at block 133, it is established on the server as indicated at block 136 by forwarding the connection notification to the application communication thread at block 144 and to the client applet at block 140. The established connection is notified to the client and the application, so the server starts reading data from the client as it is received to determine if a disconnection is required, as shown in block 141. If the answer is no, the data received from the client is sent to the application at block 145 as data from the host computer to block 146 for the application in a continuous looping process as shown by returning to block 137. . When a disconnection is finally requested by the client applet and a disconnection is detected at block 141, a test is made as to block 142 to see if the application is still connected, and if the answer is yes, As shown in FIG. 6, a notification to the application communication thread running on the server is generated as shown in blocks 143 and 144, and the thread of operation for communication with the client ends at block 139. If a test occurs at block 142 where the application is not yet connected, the thread simply terminates at block 139 and the application need not be notified.

Referring to FIG. 5, a subprocess or thread of operation at a server is shown to manage communication with an application. The application thread of the server begins at block 147 and waits for a connection from the application and host system at block 148. An incoming connection request from application block 149 is detected, and information in the connection request from the application is extracted at block 150 to update the application table at block 126. The request is passed to block 151 to determine if the maximum number of connections allowed in accordance with the configuration data for this application has been reached, and if the answer is yes, then the application may terminate the connection as indicated in block 153. It should be noticed, but if the answer is no, add the application to the application wait connection table in file 126, and the application communication thread (FIG. 6) is started as indicated by the operation of block 152. In this way, available applications that have already been started are added to the application standby connection table, as long as they still have the functionality for additional connections for the service, and the server for the client communication management thread and the server for the client's communication thread or subprocess. This information is used as shown in 3 and 4.

Referring to FIG. 6, there is shown a communication subprocess or thread for communication from an application to a client through a server. This process also begins at block 154 where it runs on the server and the communication thread begins. In block 155 the server determines from the notification received from the box 136 whether the client is connected, and if the answer is yes, notifies the application of the connection and one for the application identified from the application connection waiting table. By removing the position holder, one by one reduces the number of connections available for that application. The client's connection is notified to the application by passing the token as indicated in the notification provided from block 156 to the application at block 158. This is followed by reading any data coming from the application at block 157, which is checked at block 159 to determine if the connection is indicated by the application. If the disconnect has never been instructed by the application, any data received is sent to the client at block 164 as the data is passed to block 165 in a continuous manner. When a disconnect command from the application at the host is finally detected at block 159, a determination is made at block 160 as to whether the client is still connected. If the answer is yes, disconnection from the host application at block 161 is notified to the client communication thread of FIG. 4 as shown in block 163, and execution of the communication thread ends at block 162. If the client is still not connected when the test is performed at block 160, the thread simply terminates and no notification is needed to the client.

Returning to block 155, if it is not detected that the client is connected, an increase in time waiting for the client connection notification is executed in block 166 until the timeout end is reached or a client connection notification is received. If the timeout termination is achieved, as indicated by block 167, the application on the host is notified of the disconnection, and the location holder is removed from the table of application standby connections in table 126 because this connection is not taken or used. Should be.

Referring to FIG. 7, an operation executed as a subprocessor in the host application itself is shown. If the application is started as shown in block 169, the application may be transformed into a JCL executed in block 129 of FIG. 3 to start and obtain parameters and tokens from the server as shown in block 170. Receive instructions. If the token and the parameters meet the application's request, send a connection request to the server as shown in block 171 with a request to pass to the server 172 with the token received from the server, and respond in block 173. Wait. If the connection was accepted at the server as shown in the test at block 174, then as shown at block 175 until no more requests from the client are detected as indicated by the test at block 176. The application begins to process data, after which a final cleanup, i.e. storage of parameters and final data preferences, is executed at block 177 and the application terminates processing of this task at block 178.

The present invention is not limited to the above embodiments, and many variations are possible by those skilled in the art within the spirit of the present invention.

Listed are subprocesses established on client workstations, various process threads and subprocesses installed on network servers, subprocesses or threads authorized to any application installed on or hosted on a host computer or that can be called into. It is observed that it requires a call of. Those skilled in the art, although these subprocessors at the host and at the client, can each run equally well at the server, they create additional communication flows between the client and server and between the host and server. Thus, the preferred embodiment distributes these processing tasks as described to reduce unnecessary flows and delays in conveying the prepared information back and forth over the Internet. It also requires proper authorization of the client and / or application on the host via a firewall that can be installed on either or both of the client and the application, as appropriate authorization parameters or data are required at the server for access to the identified application. As can be seen in the embodiments of the present invention, the physical location is known only to the server and the application is only known to communicate with the server on a given port with the client known only by the token that does not represent the physical location. It should also be noted that the identity for the client's location from the application is protected by use.

Therefore, the matters described in connection with the present invention and its preferred embodiments, as we believe for the first time, provide a necessary subprocess to handle access to the identified URL location of a given application program residing on the host computer system. Of the Internet-based and world wide web interactive host-based application communication and access methods, where only the appropriate server equipped is achieved a truly universally applicable method and system for facilitating access from any Internet workstation or user. It will be appreciated by those skilled in the art that this represents a truly beneficial improvement in the art.

For that reason, what is desired to be protected by a patent is shown by the claims that follow, by way of example only, and not by way of limitation.

Claims (38)

A method comprising: computer executable program steps performed on an Internet server processor that invokes a host computer system resident application program from a remote browser with a client processor through a server with an Internet communication facility, the method comprising: Receiving a client workstation request for access, determining if the host application is available, the server receives client data from the client workstation and provides it to the host application and an application from the host application Initiating a client-host communication process that receives data and provides it to the client workstation; How to call a computer system resident application program. The server of claim 1, wherein when the determining indicates that the host application is currently unavailable, the server determines if the application should be started on the host computer and if the application should be started, the server's identifier and server at the server. And executing at the server processor to customize an application call file for the application by a port number. 3. The host computer system resident application program of claim 2, further comprising the step performed at the server processor to access the application execution control language file of the host processor application and modify the file for invocation at the server processor. How to call it. 2. The method of claim 1, wherein the initiating comprises informing the host application and the client that a logical connection is made to the server between the host processor application and the client. . 3. The method of claim 2, wherein the initiating comprises informing the host application and the client that a logical connection is made to the server between the host processor application and the client. . 4. The method of claim 3, wherein the initiating comprises informing the host application and the client that a logical connection is made to the server between the host processor application and the client. . 7. A host computer system resident application program according to any preceding claim, wherein said notifying comprises identifying the client to the host through a unique token provided by the server processor. How to call it. 7. The host of any preceding claim, further comprising detecting a disconnect command in the data from the client and notifying the host application and terminating communication between the client and the host application. How to call a computer system resident application program. 8. The method of claim 7, further comprising detecting a disconnect command in the data from the client and notifying the host application and terminating communication between the client and the host application. Way. 7. The host computer system of any preceding claim, wherein the client for the host application comprises a client to server communication subprocess and an application to server communication subprocess, both of which run on the server processor. How to call a resident application program. 7. The method of any one of claims 1 to 6, further comprising the step of executing at said host application processor to obtain a call parameter and a network identification from said server and send a connection request to said server using said token as an identifier. A method of invoking a host computer system resident application program comprising a. 8. The host computer system resident application program of claim 7, further comprising the step of executing in said host application processor to obtain a call parameter and a network identification from said server and to send a connection request to said server using said token as an identifier. How to call it. 9. The host computer system resident application program of claim 8, further comprising the step of executing in said host application processor to obtain a call parameter and a network identification from said server and send a connection request to said server using said token as an identifier. How to call it. 10. The host computer system resident application program of claim 9, further comprising the step of executing in said host application processor to obtain a call parameter and a network identification from said server and to send a connection request to said server using said token as an identifier. How to call it. 12. The host computer system resident application program of claim 10, further comprising the step of executing in said host application processor to obtain a call parameter and a network identification from said server and send a connection request to said server using said token as an identifier. How to call it. 16. The method according to any one of claims 1 to 6 and 10 to 15, wherein the desired host application parameters are obtained from the web browser of the client together with some information requested from the user and a connection request is made to the server. Transmitting a host computer system resident application program further comprising executing at a client processor. 8. The host computer system of claim 7, further comprising executing at a client processor, obtaining desired host application parameters from the web browser of the client with any information requested by the user and sending a connection request to the server. How to call a resident application program. 9. The host computer system of claim 8, further comprising executing at a client processor, obtaining desired host application parameters from the web browser of the client with any information requested by the user and sending a connection request to the server. How to call a resident application program. 10. The host computer system of claim 9, further comprising executing at a client processor, obtaining desired host application parameters from the web browser of the client with any information requested by the user and sending a connection request to the server. How to call a resident application program. An apparatus for invoking a host computer resident application program from a remote browser with a client processor via a server with an internet communication facility, the apparatus comprising: receiving a client workstation request to access the host application; Determining whether the host application is available, and wherein the server receives client data from the client workstation and provides it to the host application and receives application data from the host application and provides it to the client workstation Initiating a two-host communication process, wherein said steps are machine-readable program steps recorded on a medium and executable in an internet server processor. 21. The method of claim 20, wherein when the determining indicates that the host application is currently unavailable, determine whether the application should be started on the host computer, and if the application should be started, the server's identifier and And a machine-readable program step executable on the server processor for customizing an application call file for the application with a server port number. 22. The method of claim 21, further comprising a machine-readable program step executable on the server processor to access the application execution control language file of the host processor application and modify the file for invocation by the server processor. A device that invokes a host computer system resident application program. 21. The host of claim 20, wherein initiating the machine-readable further comprises executable steps, in the server, notifying the host application and the client that a logical connection between the host processor application and the client has been created. A device that calls a computer system resident application program. 22. The host of claim 21, wherein initiating the machine-readable further comprises executable steps of informing the host application and the client that a logical connection between the host processor application and the client has been created at the server. A device that calls a computer system resident application program. 23. The host of claim 22, wherein initiating the machine-readable further comprises executable steps at the server, notifying the host application and the client that a logical connection between the host processor application and the client has been created. A device that calls a computer system resident application program. 26. The host computer of any one of claims 20 to 25, wherein the executable notifying further comprises executable steps of identifying the client to the host through a unique token provided by the server processor. A device that calls a system-resident application program. 26. The machine-readable step of any of claims 20-25, wherein a disconnect command is detected in the data from the client and notifies the host application and terminates communication between the client and the host application. Apparatus for calling the host computer system resident application program further comprising. 27. The host computer system resident of claim 26, further comprising a machine-readable step of detecting a disconnect command in the data from the client and notifying the host application and terminating communication between the client and the host application. Device that calls the application program. 26. The client to server communication of any of claims 20 to 25, wherein the client to server communication comprises computer-executable steps for both a client-to-server communication subprocess and an application-to-server communication subprocess executed in the server processor. And invoking a host computer system resident application program comprising a machine-readable step for supporting a computer. 26. The computer-implemented execution of any one of claims 20 to 25, wherein the computer-execution is to be executed in the host application processor to obtain a network identification and calling parameter from the server and to send a connection request to the server using the token as an identifier. And the medium further comprises a possible step. 27. The medium of claim 26, wherein the medium further comprises computer-executable steps to be executed in the host application processor to obtain a network identification and calling parameter from the server and to use the token as an identifier to send a connection request to the server. And calling the host computer system resident application program. 28. The medium of claim 27, wherein the medium further comprises computer-executable steps to be executed in the host application processor to obtain a network identification and calling parameter from the server and use the token as an identifier to send a connection request to the server. And calling the host computer system resident application program. 29. The medium of claim 28, wherein the medium further comprises computer-executable steps to be executed in the host application processor to obtain a network identification and calling parameter from the server and use the token as an identifier to send a connection request to the server. And calling the host computer system resident application program. 30. The medium of claim 29, wherein the medium further comprises computer-executable steps to be executed in the host application processor to obtain a network identification and calling parameter from the server and to use the token as an identifier to send a connection request to the server. And calling the host computer system resident application program. 26. The method of any of claims 20-25, wherein the client processor obtains a desired host application parameter from the web browser of the client with some information requested from the user and sends a connection request to the server. And a machine-readable step for executing said host computer system resident application program. 27. The machine-readable step of claim 26, comprising obtaining desired host application parameters from the web browser of the client with any information requested from the user and sending a connection request to the server. And the medium further comprises calling a host computer system resident application program. 28. The machine-readable step of claim 27, further comprising obtaining desired host application parameters from the web browser of the client with any information requested from the user and sending a connection request to the server. And the medium further comprises calling a host computer system resident application program. 29. The machine-readable step of claim 28, further comprising obtaining desired host application parameters from the web browser of the client with any information requested from the user and sending a connection request to the server. And the medium further comprises calling a host computer system resident application program.