[0001] This application is a continuation-in-part of U.S. patent application Ser. No. 09/120,575, filed on Jul. 22, 1998, entitled “Streaming Modules.”
[0002] In a client-server environment, a client computers can communicate with a server to remotely access information stored at the server. The transfer of information between the server and client computer may be provided using standard protocols and software applications. For example, a hypertext markup language (HTML) browser application at a client computer can communicate over the public Internet using TCP/IP and hypertext transfer protocols (HTTP) to receive web pages from a HTTP server. Web pages may include formatted text as well as multimedia elements, such as embedded graphics and sounds. The multimedia elements may be downloaded by the client and presented to a user by a browser application or a “plug in” browser component. Example browser applications include Netscape Navigator 4.0® and Microsoft Internet Explorer 4.0™.
[0003] Browser applications used at client computers can use plug-in software to receive audio and video information using a streaming data transmission protocol. A streaming protocol allows information to be presented by a client computer as it is being received. For example, full-motion video can be sent from a server to a client as a linear stream of frames. As each frame arrives at the client, it can be displayed to create a real-time full-motion video display. Audio and video streaming allows the client to present information without waiting for the entire stream to arrive at the client application. Audio and video streaming are provided by, for example, the RealAudio® and RealVideo™ applications from RealNetworks, Inc.
[0004] Browser applications may also make use of executable software applets to enhance the appearance of HTML-based web pages. Applets are software programs that are sent from the server to the client in response to a request from the client. In a typical applet use, HTML-based web pages include HTTP commands that cause a browser application to request an applet from a server and to begin execution of the applet. The applet may thereafter interact with a user to gather and process data, may communicate data across a network, and may display results on a computer output device. Applets may be constructed from a programming language which executes in a run-time environment provided by the browser application at the client computer. For example, the Java® programming language from Sun Microsystems, Inc., allows Java applets to be stored at a web server and attached to web pages for execution by a Java interpreter. Java Applets, may be formed from multiple Java Classes. Java Classes include executable Java code that can be downloaded from a server in response to a dynamically generated request to execute the class (a module execution request). If a Java Class is not available to a Java interpreter when an executing applet attempts to access functionality provided by the Class, the Java interpreter may dynamically retrieve the Class from a server. Other programming languages, such as Microsoft Visual Basic® or Microsoft Visual C++®, may also be used to create applet-like software modules, such as Microsoft ActiveX™ controls.
[0005] The Java programming environment may be configured for a variety of different platforms. Desktop and server computers, having relatively abundant processing and memory resources, may implementation a “full” Java architecture, such as the Java 2 Enterprise Edition, while resource limited devices may implement a more narrowly focused architecture, such as the Java 2 Micro Edition (J2ME) architecture. J2ME is a modular and scalable Java architecture that supports a minimal configuration of a Java virtual machine and Java Application Programming Interfaces (APIs). J2ME can be further targeted to particular applications and device types. J2ME defines device configuration and profile to address different market segments. A profile addresses demands of a certain market segment or device family and functions, primarily, to guarantee interoperability within a certain device family. The Mobile Information Device Profile (MIDP) is one such profile. The MIDP is designed for cell phones and related services. Additional information on the MIDP profile can be obtained from Sun Microsystems, Inc. A J2ME application is written “for” a particular profile, and a profile is based upon, or extends, a particular configuration. Thus, all the features of a configuration are included in a profile and may be used by applications written for that profile. The Connected, Limited Device Configuration (CLDC) is a configuration defined for the J2ME environment. The CLDC is targeted to personal, mobile, connected information devices. The CLDC includes a number of classes designed to server the needs of small-footprint (i.e., limited-resource) devices.
[0006] Java applets and class files can be stored in Java Archive (“JAR”) files. A JAR file may be requested by a web browser using an APPLET tag embedded in a HTML page. To request the JAR file, the APPLET tag includes a ‘archive’ parameter identifying the JAR files that are needed by an applet. Once an archive file is identified, it is downloaded and separated into its components. During the execution of the applet, when a new class, image, or audio clip is requested by the applet, it is searched for first in the archives associated with the applet. If the file is not found amongst the archives that were downloaded, it is searched for on the applet's server, relative to the Java applet's Codebase. A different mechanism is defined by the CLDC to enable downloading of JAR files used in a CLDC device.
[0007] To enable dynamic downloading of 3rd party applications and content, the J2ME CLDC requires that an implementation support the distribution of Java applications via JAR files. Whenever a Java application intended for a CLDC device is publicly distributed over a network, it must be formatted in a compressed JAR file and classfiles within the JAR file must contain the stackmap attribute.
[0008] Downloadable applets can also be used to develop large and complex programs. For example, a complex financial program may be constructed from a collection of applets. In such a financial program, separate applets may be used to gather information from a user, compute payments, compute interest, and generate printed reports. As particular program functions are required by a user, the applets associated with the required functions can be retrieved from the server. However, as the size of a software application increases, delays associated with retrieving is modules over a network likewise increase and may be unacceptable to end-users. Consequently, an improvement in the transmission of software modules between computers is desirable.
[0009] In general, in one aspect, the invention features a method of streaming an archive file (such as a Java Archive file) from a server to a client device. The method includes extracting files from a Java Archive and streaming the extracted files from a server to a client device, receiving the streamed files and storing the received files for access by a Java application. The stored files may then be provided to a Java application
[0010] Implementations may include one or more of the following features. The client device may be a resource-limited device that includes a Java Platform Micro Edition execution environment. The received streamed files can be stored at the client device in a Java Archive format. This may help to conserve resources at the client device. Streamed files can include both executable files (e.g., Java class files) and non-executable files (e.g., image files, sound files, and other data). The files can be streamed in accordance with predictive critiera (i.e., predetermined criteria predicting an order of utilization of the files at the client device.) Meta-information in the Java archive (i.e., the Java Archive manifest and signature files) can also be streamed to the client device and used to validate other ones of the streamed files. The validation may, in a simple case, be a confirmation of file name and path. In a more complex case, digital signature information may be checked.
[0011] In general, extracting of the files occurs independent of a request by the Java application for the particular files. When the Java application does request the archive (or files in the archive), the Java execution environment at the client device will attempt to satisfy this request using the streamed files stored at the client device. If it is unable to do so, control data can be sent to the streaming server to obtain the required archive and/or required files. The control data may cause the streaming server to interrupt a file currently being streamed or to change the order of files being transmitted so that transmission of the requested file may begin.
[0012] The invention may be applied to other program execution environments and archive formats to enable streaming of files stored within different archive types. The invention may also be applied to the streaming of non-executable data.
[0013] In general, in another aspect, the invention includes methods and systems for streaming data modules between a first and a second computer. The modules may be streamed regardless of the existence of a “natural” order among the modules. For example, unlike streaming applications that rely on a natural linear ordering of data to determine the data stream contents, the disclosed streaming mechanism is not constrained to operate according to a linear data ordering. Instead, streamed data modules are selected using predetermined criteria that can be independent of the particular data content.
[0014] In an exemplary application, the disclosed streaming mechanism can provide user-dependent streaming of software modules. For example, a home banking application may include modules #1 through #5. A first banking application user may, based on the user's input choices at a menu screen, access the modules in the order 1-3-4-5 while a second user may access the modules in the order 2-4-1. For such a banking application, the predetermined criteria used to determine a streaming sequence may detail each user's module usage pattern. Predetermined criteria associated with the application's users may indicate a preferred streaming sequence 1-3-4-5 when the first user is accessing the banking application but may indicate the preferred sequence 2-4-1 when the second user is accessing the application. The streamed sequence may therefore conform to a historical user-dependent access pattern. Other types of predetermined criteria may also be used. The disclosed streaming mechanism may also be use to stream non-executable data such as hypertext markup language data, binary graphics, and text.
[0015] In general, in one aspect, the invention features a computer-implemented method of transmitting modules from a first computer to a second computer. At the first computer, a module set is formed by selecting a sequence of modules from a collection of available modules. Each of the selected modules are associated with an application executing at the second computer. The selected modules may be transparently streamed from the first computer to the second computer. The selection of modules is made in accordance with predetermined selection criteria and is independent of the second computer's execution environment.
[0016] Implementations of the invention may include one or more of the following features. A module may include non-executable data, such as hypertext markup language data, and/or program code. The selection criteria may be stored in a streaming control database. The streaming control database may include transition records associating weighted values with transitions between selected modules in the collection. Processing of transition record information, such as by using a path determination algorithm, may be used to determine the sequence of modules. The streaming control database may include list records each of which identifies a predetermined sequences of modules. Selection of modules may be made by selecting a list record. Selecting a sequence of modules may include sending data from the second computer to the first computer to identify each module in the sequence or to identify the status of the executing application. For example, data identifying the status may include a series of user input values.
[0017] Implementations may also include one or more of the following features. Streaming of the module set may be interrupted, a second sequence determined, and streaming of the second sequence may occur. The streaming of the module set may be interrupted by a request for a particular module that is sent from the second computer to the first computer. For example, a Java Applet may interrupt a stream of Java Classes by attempting to access a Java Class that has not already been streamed to the second computer. A sequence of modules may be streamed and stored at the second computer independent of the executing application. That is, the executing application need not initiate streaming and need not be aware of the streaming process. Streamed modules may be subsequently integrated with the application at the second computer by interconnecting logic in a streamed module with logic in the application.
[0018] Implementations may also include one or more of the following features. The application may include an interrupt statement. Execution of the interrupt statement may transfer control to an executor program. The executor program functions in the manner of a program code debugger by responding to the interrupt statement and preventing the permanent cessation (termination) of the executing application process. The executor program may thereafter integrate logic in a streamed module with the application's logic by replacing the interrupt statement (generally, as part of a block of replacement logic) with replacement logic from the streamed module. The application may thereafter continue executing, generally by executing replacement logic that has been substituted for the interrupt statement. The application may also include a stub procedure that can be replaced by logic in a streamed module. Replacement of the stub procedure may be direct, such as by removing the stub procedure code and replacing it with logic from a streamed module, or replacement may be operative, such as by creating a link to logic in a streamed module.
[0019] In general, in another aspect, the invention features a computer program residing on a computer-readable medium. The computer program includes instructions for causing a computer to access a collection of modules associated with an application, to access a database storing module selection criteria, to form a module set by selecting a sequence of modules from the collection in accordance with the module selection criteria, and to transparently stream the module set to a second computer. Implementations of program may also include instructions for causing the computer to retrieve a first module from the collection and to send the first module to the second computer.
[0020] In general, in another aspect, the invention features a computer program residing on a computer-readable medium. The program includes instructions for causing a computer to execute an application, to transparently receive a modules associated with the executing application, to store the received module independent of the executing application, and to integrate the received module with the executing application.
[0021] In general, in another aspect, the invention features a system for transferring information modules between computers. The system includes a first computer and a second computer. The first computer includes means for executing an application, means for receiving a sequence of modules associated with the application while the application is executing, and means for integrating a first module in the received sequence with the application. The second computer includes means for storing a collection of modules associated with the application, means for selecting a sequence of modules from the collection, and means for transferring the selected sequences from the first computer to the second computer.
[0022] Implementations may include one or more of the following advantages. Delays experienced when downloading an applications, a code module, or a data modules can be can be reduced. Software and data modules can be predictively delivered to a client workstation according to a particular end user's requirements. The order in which modules are streamed from a server to a client can be dynamically determined. A collection of module delivery sequences can be associated with a particular application or user and the sequences can be dynamically updated. Module delivery sequences can be determined based on individual software usage patterns or stored statistic associated with module usage. Module streaming can be interrupted and altered during the execution of an application. Implementations may include additional or alternative advantages as will become clear from the description and claims that follow.
[0023]
[0024]
[0025]
[0026]
[0027] FIGS.
[0028]
[0029] Referring to
[0030] Web pages and multimedia data sent from the server
[0031] Software execution may not follow a predictable natural linear order. Software may include jump statements, break statements, procedure calls, and other programming constructs that cause abrupt transfers of execution among sections of executing code. The execution path that is traversed during the processing of interrelated code modules (such as code segments, code classes, applets, procedures, and code libraries), will often be non- linear, user dependent, may change with each execution of the application program, and may change depending on the state of various data items. Although a natural order may be lacking, an advantageous order may be determined in which to stream modules. The order may be determined using criteria that is independent of the computer's internal architecture or internal operating system (execution environment) considerations.
[0032] Referring to
[0033] To minimize module download delays experienced by a user, module “E” may be transparently streamed from a server to the client computer. Transparent streaming allows future module use to be predicted and modules to be downloaded while other interrelated modules “A” are executing. Referring to
[0034] Referring to
[0035] The server
[0036] The sequence of modules sent in the stream TABLE 1 Graph Edge Table Edge Weight (A,B) 1 (A,D) 7 (A,E) 3 (B,C) 1 (B,G) 3 (C,E) 2 (C,G) 6 (D,F) 2 (E,H) 2 (F,H) 1 (G,E) 3 (G,H) 4
[0037] For example, Table 2 represents the minimum path weight between module “A” and the remaining modules of Table 1.
TABLE 2 Shortest Paths from Application Module “A” Shortest Path From To Weight Path A B 1 A-B C 2 A-B-C D 7 A-D E 3 A-E F 9 A-D-F G 4 A-B-G H 5 A-E-H
[0038] Based on the weight values shown in Table 2, the server TABLE 3 Shortest Paths from Module “B” Shortest Path From To Weight Path B C 1 B-C E 5 B-C-E G 3 B-G H 7 B-C-E-H
[0039] Based on the shortest path weights shown in Table 3, the server
[0040] Other algorithms may also be used to determine a module streaming sequence. For example, a weighted graph TABLE Preferred Path Table Edge Weight (A,B) 100 (A,D) 15 (A,E) 35 (B,C) 100 (B,G) 35 (C,E) 50 (C,G) 20 (D,F) 50 (E,H) 50 (F,H) 100 (G,E) 35 (G,H) 25
[0041] In an preferred-path (heavy weighted edge first) implementation, edges in the graph
[0042] 1: Create two empty ordered sets:
[0043] i) A candidate set storing pairs (S,W) wherein “S” is a node identifier and “W” is a weight of an edge that may be traversed to reach node “S.”
[0044] ii) A stream set to store a determined stream of code modules.
[0045] 2: Let Si be the starting node.
[0046] 3: Append the node S
[0047] 4: For each node S
[0048] {
[0049] If S
[0050] If S
[0051] }
[0052] 5: If the Candidate set is not empty Select the greatest weight pair (S
[0053] Let S
[0054] Repeat at step 3
[0055] For example, as shown in Table 5, starting at node “A” and applying the foregoing algorithm to the edges of Table 4 produces the stream set {A, B, C, E, H, G, D, F}:
TABLE Calculation of Stream Set Iteration {Stream Set}/{Candidate Set} 1 {A}/{(B,100) (D,15) (E,35)} 2 {A, B}/{(D,15) (E,35) (C,100) (G,35)} 3 {A, B, C}/{(D,15) (E,35) (G,35)} 4 {A, B, C, E}/{(D,15) (G,35) (H,50)} 5 {A, B, C, E, H}/{(D,15) (G,35)} 6 {A, B, C, E, H, G}/{(D,15)} 7 {A, B, C, E, H, G, D}/{(F,50)} 8 {A, B, C, E, H, G, D, F}/{}
[0056] Implementations may select alternative algorithms to calculate stream sets.
[0057] Application streaming may also be used to stream subsections of an application or module. For example, subsections of compiled applications, such as applications written in C, C++, Fortran, Pascal, or Assembly language may be streamed from a server
[0058] In a Microsoft Windows
[0059] Data and procedures within an application's code modules and libraries may be many hundreds or thousands of bytes long. Prior to executing an application, a client may need to retrieve a lengthy set of modules and libraries. By reducing the size of the module and library set, the initial delay experienced prior to application execution can be reduced. In a streaming implementation of application
[0060] A server
[0061] In an appended module implementation, streamed code modules are integrated with the executing application by appending received modules to their corresponding library or code file. For example, referring to
[0062] In some scenarios, removed code, such as procedure code
[0063] Code modules may be reduced in size without the use of stub procedures. For example, referring again to
[0064] Executor
[0065] Implementations may also stream entire modules or libraries. For example, main code module
[0066] In a protected-memory computer system, direct manipulation of executing application code and data may be restricted. In such systems, a “kernel” level processes or procedure may be required to support integration of streamed modules with executing application. In such a case, streaming support
[0067] Archive file such as CAB, tar, BINHEX, and ZIP files, including ZIP formatted Java Archive (JAR) files, can be streamed by extracting modules of data from the archive files and streaming those modules to a client terminal. In the following text, streaming of a Java Archive is detailed. The disclosed techniques may be applied to the streaming of other archive formats as well.
[0068] Java classes, as well as images, sounds, and other data files, can be aggregated together in a Java Archive files (a “JAR file”). A JAR file is a data archive using the ZIP archive format to aggregate a collection of logically separate data files.. The files in a JAR file can include Java class files, video, sound, and other data files, as well as meta-information files (the contents of which are define by Sun Microsystems Inc.'s JAR standard).
[0069]
[0070] A ZIP file's central directory
[0071] The size of a ZIP archive
[0072] Files
[0073] Conventionally, a JAR file
[0074] Referring back to
[0075] The receiving device
[0076] To reconstruct the JAR file
[0077] After allocating space for the JAR archive, the client places the module
[0078] Java programs executing at the client may begin using a module
[0079] The client device's file extraction code may be modified to generate an exception if a module requested by an executing application is missing from the archive. Thus, if the Java application request file
[0080] Java implementations may require the presence of the manifest file
[0081] In some implementations, redundant information in an archive file may be omitted prior to streaming. For example, the local file header data
[0082] For some data types, improved compression may be obtained using type-specific compression algorithms (rather than standard ZIP compression algorithms). Prior to streaming a module, the module may be decompressed and re-compressed into a new compression format. In such cases, additional software functionality (i.e., additional decompression algorithms and ZIP compression) may be implemented at the receiving device for the reconstruction of the JAR file.
[0083] If the receiving device
[0084] In some cases, an extracted file may be further subdivided before streaming. For example, file
[0085] Other methods of determining stream sets may be used. In a list-based implementation, the streaming control file may include predetermined list of module streaming sequences. For example, the streaming control file
[0086] In graph-based streaming control file implementations, the weight of edges connecting nodes may be determined statically or dynamically and may be determined based on a collection of historical usage data. For example, in a programmer-controlled implementation, a software programmer estimate the likelihood that particular transitions between nodes will occur based on the programmer's knowledge of the software code and the expected application usage patterns. Alternatively, application profiling programs may be used to gather run-time execution data recording transitions between various applets, Classes or code modules and thereby determine the likelihood that particular transitions will occur. In a client-feedback implementation, control data
[0087] In a client-controlled streaming implementation, streaming control data
[0088] Implementations may include a “handshaking” procedure whereby, at the start of application execution, control data
[0089] In a history-dependent implementation, a server or client can store data about a series of transitions between modules and calculate a new module stream based on a history of transitions. For example, referring to
[0090] The invention may be implemented in computer hardware, firmware, software, digital electronic circuitry or in combinations of them. Apparatus of the invention may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor; and method steps of the invention may be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output.
[0091] The invention may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory.
[0092] Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).