Integrated development environment for high speed transaction processing WWW applications on heterogeneous computer systems

[0002] The present invention generally relates to data processing systems, and more specifically to software development systems for developing World Wide Web (WWW) applications.

[0003] Software development traditionally required that the developer first edit his source code. He would then compile the code into an object module, and link-edit one or more object modules into an executable. The executable would then be placed into a library for execution. In the case of transaction processing, this would require either that the transaction processing routine (TPR) library be deallocated by the Transaction Processing (TP) monitor long enough to move the executable into the TPR library, or to force the TP monitor to reload its own high speed copy of the TPR library from the common TPR library. The program would then be tested. The process would then repeat until the software development was complete.

[0004] This process was simplified for a great extent for instances where the development and ultimate execution were on the same computer system by the introduction of Integrated Development Environments (IDEs). These are typically special purpose text editors executing on personal computers or workstations that provide compiling, linking, loading, and testing in one program. These single system IDEs have become extremely sophisticated. They have been extended to provide development environments for World Wide Web page development and Java Applet development.

[0005] One problem with current IDE technology is that these IDE systems operate on a single computer system. At best, they can be used to develop and test program code, WWW pages, and applets for one computer system, then the program executables, WWW pages, and applets can be transferred to a homogeneous computer system for ultimate production. This is the standard mode of Web development in operation today.

[0006] Another problem is that using the same type of computer systems for both Web development and Web server execution has serious limitations today. The Integrated Development Environments (IDEs) today operate on Microsoft Windows or Apple MacIntosh based personal computes or Unix based workstations. Extremely user friendly systems have been developed. Unfortunately, these types of system do not lend themselves well to high performance transactional processing. Legacy mainframe computers with high performance transaction processing (TP) monitors are still the best systems for servers that are capable of providing high speed simultaneous access to large shared databases to hundreds, if not thousands, of client systems. Unfortunately, developing and testing programs, web pages, and applets that are to run on these large transaction systems is much more complex than it is on the workstations or personal computers that support typical Integrated Development Environments.

[0007] For example, Job Control Language (JCL) is typically required to compile and link-edit transaction processing routines (TPR) on these high performance TP systems. The TPR executables then have to be made available to the TP monitor for high speed access. Similarly, Web pages and Java Applets need to be established so that they can be accessed very quickly, such as being loaded as records into a database. None of these features is provided by the typical state-of-the-art IDE running on a personal computer or workstation.

[0008] A method or system that provides the user friendly benefits found in personal computer or workstation based Integrated Development Environments (IDEs) for developing Web based transactional processing routines (TPRs), Web pages, and applets for execution and testing on high performance transactional systems would thus be advantageous.

[0009] The features and advantages of the present invention will be more clearly understood from the following detailed description taken in conjunction with the accompanying FIGURES where like numerals refer to like and corresponding parts and in which:

[0010] FIG. 1 illustrates a general purpose computer system in accordance with the present invention;

[0011] FIG. 2 illustrates a data processing system comprising a server system and a client system for WWW application development;

[0012] FIG. 3 is a flowchart illustrating operation of the Publish TP Application process, in accordance with a preferred embodiment of the present invention;

[0013] FIG. 4 is a flowchart illustrating operation of the Publish Web Page process, in accordance with a preferred embodiment of the present invention;

[0014] FIG. 5 is a flowchart illustrating operation of the Publish Applet process, in accordance with a preferred embodiment of the present invention; and

[0015] FIG. 6 is a diagram illustrating sample graphical user interface windows from execution of the Publish TP Routine process shown in FIG. 3.

[0016] An Integrated Development Environment (IDE) on a client provides for developing transaction programs, web pages, and applets for execution on a high performance transactional based World Wide Web server. The transaction programs are developed on the client, then automatically transferred to the server, where they are automatically compiled, linked, loaded into a TP library, registered with a TP monitor for execution, and tested. Similarly, the web pages and applets are developed on the client, then automatically transferred to the server, loaded into a database, and tested.

[0017] In the preferred embodiment, the Integrated Development Environment (IDE) includes a Transaction Processing Routine (TPR) Wizard that provides for easy TPR application development. The IDE executes as a Microsoft Windows application program. After source code has been developed on the client system utilizing the IDE, at the touch of a software button or with a single menu selection the TPR application source code, Web page, and/or Applet is transferred to a GCOS 8 mainframe server system. Also automatically generated and transferred is the Job Control Language (JCL) required to either compile and link the source code, or load the Web page and/or Applet into a transaction forms database. Executables are loaded into a TPR library. Then, a Universal Resource Locator (URL) is generated to test the transaction programs, Web pages, and/or applets. The URL is transmitted to the GCOS 8 TP monitor (TP8) for execution. Output from the testing is then returned to the client for display by a Web browser.

[0018] In the following description, numerous specific details are set forth such as specific word or byte lengths, etc. to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details concerning timing considerations and the like have been omitted inasmuch as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art.

[0019] FIG. 1 is a block diagram illustrating a General Purpose Computer 20. The General Purpose Computer 20 has a Computer Processor 22, and Memory 24, connected by a Bus 26. Memory 24 is a relatively high speed machine readable medium and includes Volatile Memories such as DRAM, and SRAM, and Non-Volatile Memories such as, ROM, FLASH, EPROM, EEPROM, and bubble memory. Also connected to the Bus are Secondary Storage 30, External Storage 32, output devices such as a monitor 34, input devices such as a keyboard (with mouse) 36, and printers 38. Secondary Storage 30 includes machine-readable media such as hard disk drives, magnetic drum, and bubble memory. External Storage 32 includes machine-readable media such as floppy disks, removable hard drives, magnetic tape, CD-ROM, and even other computers, possibly connected via a communications line 28. The distinction drawn here between Secondary Storage 30 and External Storage 32 is primarily for convenience in describing the invention. As such, it should be appreciated that there is substantial functional overlap between these elements. Computer software such transaction processing programs, operating systems, and other user programs can be stored in a Computer Software Storage Medium, such as memory 24, Secondary Storage 30, and External Storage 32. Executable versions of computer software 33, can be read from a Non-Volatile Storage Medium such as External Storage 32, Secondary Storage 30, and Non-Volatile Memory and loaded for execution directly into Volatile Memory, executed directly out of Non-Volatile Memory, or stored on the Secondary Storage 30 prior to loading into Volatile Memory for execution.

[0020] FIG. 2 is a block diagram illustrating a data processing system comprising a server computer system 40 and a client computer system 42. World Wide Web (WWW) transaction processing routine (TPR) application programs, World Wide Web pages, and Java Applets are developed on the client computer system 42 typically utilizing standard tools such as text editors. The WWW TPR source code 52, and Web page and Java Applet documents 54 are then transferred over a communications link 41 to the server system 40 and stored on disk 44 or other Computer Software Storage Medium. In the preferred embodiment, FTP protocol executing over TCP/IP protocol is utilized for ASCII or text data and HTTP protocol over TCP/IP protocol is utilized for binary data such as graphics, with the client acting as a Web server. A command or interactive connection is then made from the client computer system 42 over the communications link 41 to the server computer 40. In the case of a WWW transactional processing program (TPR), the TPR source code 52′ is compiled and linked into TPR executable modules 56 and stored in transactional libraries located on a TP library disk volume 44. The TPR program 56 is then registered, if necessary, with the transaction processing (TP) monitor. WWW Web pages 54′, Java Applets, and graphical images are loaded as records 58 into a Web page database 46. A standard WWW web browser such as Netscape Navigator or Microsoft Internet Explorer can then be invoked on the client 42 with an appropriate Universal Reference Locator (URL) to access and test the newly loaded WWW transaction processing Routine (TPR) 56, World Wide Web (WWW) page 58, Java Applet, and/or graphical images on the server system 40.

[0021] FIG. 3 is a flowchart illustrating operation of the Publish TPR Application process. In the preferred embodiment, this is a function of an Integrated Development Environment (IDE) program that provides integrated word processing and browser capabilities. The word processing capabilities are similar to those provided by Microsoft WordPad. However, in alternate embodiments, this functionality can be implemented as a “plug-in” to a text editor such as Microsoft Word or Corel WordPerfect with an interface to a standard Web browser such as Netscape Navigator or Microsoft Internet Explorer. A TPR Wizard within the IDE also provides functionality to allow a developer to select the type of TPR he wants to build and then automatically generates the required source code. The same Publish TPR functionality is provided to publish user written TPRs.

[0022] The Publish TPR Routine process is invoked in the (IDE) by selecting a “Publish” menu item or pressing a “Publish” “button”. First, a file transfer link is setup between the client system 42 executing the publication software, and the server system 40 on which the transactional program (TPR) software being developed will ultimately execute, step 102. In the preferred embodiment, this is a File Transfer Protocol (FTP) session over TCP/IP protocol over the communications link 41 between the client system 42 and the server system 40. The TP application program (TPR) source code 52 is then transferred to the server computer 40 utilizing this protocol, step 104. Similarly, the Job Control Language (JCL) required to compile and link the TPR is transferred to the server 40. An interactive command link is then setup across the communications link 41 between the client system 42 and the server system 40, step 106. In the preferred embodiment, this is a GTEA ActiveX control session to GCOS. In an alternative embodiment, such as for an IBM S/390 server, this may be a Telnet 3270 session to TSO, or in other embodiments a Telnet session to other operating systems. Commands to compile and link edit the TP program (TPR) 52′ are transferred over to the server computer system 40 and submitted for execution. In the preferred embodiment, this includes commands to execute the JCL previously transmitted utilizing FTP. Results of the compilation are then returned to the TP registration program and logged on the client computer system 42.

[0023] A test is made whether to modify a currently active TPR module library, step 110. This selection is typically maintained as an application “preference”. If it is determined to modify a currently active TPR module library, step 110, the appropriate TPR library is acquired, step 112. In the preferred embodiment, this involves deallocating the TPR library from the TP monitor and allocating it to a job dedicated to the compilation. The TP application program is then compiled and link edited into an executable module and this executable module 56 is added to the TPR library, step 114. The TPR library is then released by the registration job and reallocated to the TP monitor, step 116. The TP monitor is then notified, if necessary, of the new TP application program, step 118.

[0024] Alternatively, if it is determined not to modify a currently active TP module library, step 110, the TPR application program 56 is compiled and link edited into a TPR library, step 120. A test is then made whether an immediate TP library load is required, step 122. If an immediate TPR library load is required, step 122, the TP monitor is notified on the server computer system 40, step 124. In response to this notification, the TP monitor reloads its temporary copy of one or more TP module libraries from their permanent counterparts.

[0025] In all cases, a test is then made whether or not to test the TPR program 56, step 126. This selection is typically either an application preference, or through use of a selection box presented to the developer after successful compilation and link-editing. If the decision is made to test the TPR application 56, step 126, an appropriate URL is submitted to a Web browser executing on the client system 42, step 128. The Web browser in turn transmits the URL to the server computer system 40. The TP monitor on the server system 40 is then invoked to execute the designated TPR application program 56. Results of that execution are then transmitted back over the communications link 41 to the web browser executing on the client computer system 42. In all cases, the WWW Application Registration process is then complete, step 129.

[0026] FIG. 4 is a flowchart illustrating operation of the Publish Web Page process. In the preferred embodiment, this is a function of the IDE program that provides integrated word processing and browser capabilities. However, in alternate embodiments, this functionality can be implemented as a “plug-in” to a text editor such as Microsoft Word or Corel WordPerfect. First, a file transfer link is setup between the client system 42 executing the registration software, and the server system 40 on which the Web page being developed will ultimately be stored, step 132. In the preferred embodiment, this is a File Transfer Protocol (FTP) session over TCP/IP protocol over the communications link 41 between the client system 42 and the server system 40. The Web page 54 is then transferred to the server computer 40 utilizing this protocol, step 134. Any required Job Control Language (JCL) is also transferred to the server system 42 (none is required in the preferred embodiment). An interactive or command link is then setup between the client system 42 and the server system 40, step 136. In the preferred embodiment, this is a GTEA ActiveX control session to GCOS. In an alternative embodiment, such as for an IBM S/390 server, this may be a Telnet 3270 session to TSO. Commands to register the Web page are transferred over to the server computer system 40 and submitted for execution, step 138. In the preferred embodiment, this involves execution of a database program that loads the Web page as a record 58 into the Web database 48.

[0027] A test is made whether to test the Web page 58, step 140. This is typically implemented either as a “preference” or as an option that can be “checked” or enabled. If it is determined to test the Web page 58, step 140, the appropriate Universal Resource Locator (URL) is submitted to the Web browser on the client 42, step 142. The URL is transmitted over the communications link 41 to the server 40. The server responds by retrieving the Web page 58 from the Web database 48 and transmitting it back to the Web browser on the server system 42, where it is then displayed. In all cases, the WWW Web Page Registration process is then complete, step 144.

[0028] FIG. 5 is a flowchart illustrating operation of the Publish Applet process. In the preferred embodiment, this involves registration of Java Applets and graphical images. However, in other embodiments, other downloadable programs may be published. In the preferred embodiment, this Publish Applet process is a function of the IDE program that provides integrated word processing and browser capabilities. However, in alternate embodiments, this functionality can be implemented as a “plug-in” to a text editor such as Microsoft Word. First, a file transfer link is setup between the client system 42 executing the registration software, and the server system 40 on which the applet being developed will ultimately be stored, step 152. In the preferred embodiment, this is a File Transfer Protocol (FTP) session over TCP/IP protocol over the communications link 41 for text such as ASCII between the client system 42 and the server system 40. In the case of binary data, such as graphical images, the IDE on the client system 42 acts as a Web server and opens a TCP/IP socket and sends the server system 40 acting as a workstation a publish command with the client IP and socket address. The server system 40 responds with a “GET” request, and the IDE transmits the binary file 54 to be published to the server 40. The applet or graphical image 54 is then transferred to the server computer 40 utilizing the appropriate protocol, step 154. Any required Job Control Language (JCL) is also transferred to the server system 42 (none is required in the preferred embodiment). JCL, being ASCII text, is transferred utilizing FTP. An interactive or command link is then setup between the client system 42 and the server system 40, step 156. In the preferred embodiment, this is a GTEA ActiveX command session to GCOS. In an alternative embodiment, such as for an IBM S/390 server, this may be a Telnet 3270 session to TSO. Commands to publish or register the applet or graphical image are transferred over to the server computer system 40 and submitted for execution, step 158. In the preferred embodiment, this involves execution of a database program that loads the applet into the Web database 48.

[0029] A test is made whether to test the applet or graphical image 58 stored in the database 48, step 160. This is typically implemented either as a “preference” or as an option that can be “checked” or enabled. If it is determined to test the applet, step 160, the appropriate Universal Resource Locator (URL) is submitted to the Web browser on the client 42, step 162. The URL is transmitted over the communications link 41 to the server 40. The server responds by retrieving the applet from the Web database 48 and transmitting it back to the Web browser on the server system 42, where it is then executed. In all cases, the Applet Registration process is then complete, step 164. While publication of applets and graphical images are disclosed herein, it should be understood that publication of other types of downloadable data, images, sound, and video to a Web server 40 are also within the scope of this invention.

[0030] FIG. 6 is a diagram illustrating sample graphical user interface windows from execution of the Publish TP Routine (TPR) process shown in FIG. 3. In the preferred embodiment, the Publish TP Routine (FIG. 3), Publish Web Page (FIG. 4), and Publish Applet (FIG. 5) execute as functions within the IDE. However, they can also execute as plug-ins to either a text editor or Web browser on a client system 42 executing a Microsoft Windows 95/98/NT/2000 operating system. Other alternate environments within the scope of this invention include other graphical user interfaces (GUIs) such as the Apple MacIntosh, and X-Windows in a Unix or Linux environment. FIG. 6 shows execution of the IDE on a Microsoft Windows 95/98/NT/2000 system. A Microsoft Windows desktop 62 is shown with two visible windows 64, 66. A first window 64 shows Cobol source code for the TP routine to be published and tested. In this case, the first window 64 shows the text editor being utilized to develop the TP routine (TPR). In the preferred embodiment, this text editor is a function of the IDE. However in other embodiments, it can be a word processing program such as Microsoft Windows or Corel WordPerfect. A second window 66 overlaying the first window 64 graphically shows the execution of the Publish TP Routine process shown in FIG. 3. Seven steps are shown in the second window 66, with check () marks indicating completion of each of the steps. Table T-1 shows the correspondence between the steps shown in this window and the steps in FIG. 3.

[0031] Two buttons are shown at the bottom of the second window 66. The second button is marked “Break” and it is the default button. If “pressed”, the Publish TPR process will be terminated. Alternatively, when the steps in the second window 66 complete successfully (all being marked with a “”), and the new TP routine is loaded into the TP library, the “OK” button is replaced by a “Test” button, and the “Break” button is replaced by a “Close” button. If the “Test” button is selected and “depressed” (see step 126 in FIG. 3), a URL is submitted to the Web browser on the client system 42. The Web browser transmits the URL to the server system 40, which executes the corresponding TP routine in response to the URL. The response, which is typically a Web page, is transmitted back to the Web browser on the client system 42, where it is displayed to the developer. In any case, regardless of whether or not testing of the TPR was selected, and regardless of whether the “Close” or “Test” button was “depressed”, the Publish TP Routine process (FIG. 3) is complete, step 129.

[0032] An integrated development environment (IDE) on a client system 42 has been disclosed herein that provides for developing and testing transaction programs, web pages, applets, and graphical images for execution on a high performance transactional based World Wide Web server 40. This IDE provides for file transfer of TP routine source code 52 to the server 40, compiling and link editing of the source code 52′ into an executable TPR 56, loading the executable TPR into a TPR library, and testing of the TPR on the server from the client system 42, all with a single menu selection or “click”. Similarly one menu selection or “click” provides for transferring web pages and/or Java applets 54 to the server 40, loading the web page and/or applets 54′ into a transactional forms database 48 on the server 40, and then testing the display of the web pages and/or execution of the applets 58.

[0033] Those skilled in the art will recognize that modifications and variations can be made without departing from the spirit of the invention. Therefore, it is intended that this invention encompass all such variations and modifications as fall within the scope of the appended claims.

[0034] Claim elements and steps herein have been numbered and/or lettered solely as an aid in readability and understanding. As such, the numbering and/or lettering in itself is not intended to and should not be taken to indicate the ordering of elements and/or steps in the claims.