Methods and systems for java interapplet communication

Background of the Invention

1. Field of the Invention

The present invention relates to interprocess communication and in particular to Java inter-applet communication for applets in different HTML frames.

2. Background of the Invention

In distributed computing environments, processes communicate with one another using various inter-process communication (IPC) standards. Processes, as used herein, were first to both user processes (application programs) and system processes. IPC communication standards generally utilize a technique referred to as sockets to communicate between cooperating processes. A first process establishes a socket by identifying the protocols to be used and the destination process with which it wishes to communicate. The second process also establishes a socket identifying the protocol supported for communicating with other processes. The second process then listens for another process to establish communications directed to its (the second process) address.

Java is a computer programming language recently gaining popularity for development above portable application programs. Java is an interpreted computer programming language. An interpreted computer programming language is one which does not directly translate into buying eerie executable code. Rather, the source language (or an intermediate binary representation thereof) is processed by a program, an interpreter, which performs appropriate functions to implement the high-level source language statement. Interpreted languages such as Java are therefore often restricted in their functionality. Such restrictions are often considered desirable to enhance security measures within a system.

In particular, Java is frequently used for implementing so-called applets operable in the World Wide Web/Internet distributed computing environments. In such environments, a Web browser (client) downloads information from identified Web server. The information in the, typically referred to as a page, may include a job of applets to be downloaded to the Web browser. The Web browser includes a Java language interpreter which then interprets the downloaded applets to perform the desired task.

The Java specification generally precludes objects such as Java applets within one "Page" from communicating with objects in a second "Page". Further, in the Java specification, a single displayed screen in the users Web browser may include a number of frames (distinct sections of information displayed for the user). A frame is generally considered the equivalent of a Page with regard to the security measures of the Java specification which preclude objects communicating between pages or frames. It is therefore a problem in the Java language to communicate between applets outside of common HTML page.

Though applets in different frames in the Java language are not generally permitted to communicate with other applets using IPC sockets, they are or permitted to communicate with processes on the server from which the Java applets were loaded. One solution to the inter-applet communication problems noted above has been for applets desiring communication to use a particular messenger service on the server from which the applets were loaded. Each applet is able to communicate with the messenger service on the server from which they were loaded. Therefore, the applets may communicate with one another via the messenger service as an intermediary.

This solution is incomplete and cumbersome. Furthermore, involving standards in the job of language specification may preclude such communication links even with the server processes. First, the prior solutions are cumbersome in that both applets must communicate with the server process to effectuate their inter-applets communications. This utilizes valuable bandwidth where the communication links are slow or otherwise limited. The solutions are incomplete in the sense that only applets downloaded from a common server may communicate using these prior techniques.

Another prior solution has been to utilize the Java script language as in intermediary between two applets desiring to communicate. The job of applets invoke functions in Java script to effectuate other desired inter-applet communication. However, this solution is not standardized into supported only on the Netscape communicate or product. Older Web browsers and Microsoft Internet Explorer are incapable of implementing the solution.

It is evident from the above discussion that a need exists for improved inter-applet communications in the Java programming language.

Summary of the Invention

The present invention solved the above and other problems, thereby advancing the state of the useful arts, by providing and inter-applet communication capability which is portable to a number of Web browsers, within standard Java language specifications, and less cumbersome in use of bandwidth than prior solutions. In particular, the present invention provides for defining a superclass common to all applets needing to communicate with each other. All applets desiring to so communicate are defined as some classes of the superclass. The superclass has static variables defined therein and methods for notifying applets of changes in those static variables. The static variables are therefore useful for inter-applet communication purposes.

As compared to prior techniques no communication bandwidth need be utilized to communicate between applets in different frames of a Web browser. More specifically, a server based messenger processes not required for inter-applet communications in accordance with the present invention. Further, defining applets in accordance with the superclass of the present invention is within the standards prescribed for the Java programming language. The present invention is therefore more portable to a variety of job of implementations and associated Web browsers as compared to prior techniques.

These and other features, aspects, and objects of the present invention will become apparent etc.

Brief Description of the Drawings

<ul id="ul0001" list-style="none" compact="compact"><li>Figure 1 is a block diagram of the superclass and applet subclasses of the present invention;</li><li>Figure 2 is a flowchart describing a first method of the applet superclass of the present invention;</li><li>Figure 3 is a flowchart describing a second method of the applet superclass of the present invention; and</li><li>Figure 4 is a flowchart describing a third method of the applet subclass overriding the nominal third method defined by the applet superclass in accordance with the present invention.</li></ul>

Detailed Description of the Preferred Embodiments

While the invention is susceptible to various modifications and alternative forms, a specific embodiment thereof has been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

Figure 1 is a block diagram depicting class and object relationships associated with the methods and structures of the present invention. Within HTML page 100 the present invention defines a Java applet superclass 102. All Java applets requiring inter-applet communication are derived from (specializations of) superclass 102. Included within applet superclass 102 is a static notification list structure 104 used as described herein below to register applets requiring notification of particular event occurrences. At least three methods, 106, 108 and 110, are also defined within applet superclass 102. The first method 106 provides for addition and deletion of entries in the notification list 104. In the preferred embodiments, method 106 is actually subdivided into two distinct methods, a first method for adding entries to the notification list and a second method for deleting entries from the notification list. To simplify the description herein, a single method 106 is presented for both purposes. A second method 108 enables notification of the occurrence of a particular event. As discussed further herein below, this method is invoked by one applet to signal occurrence of particular events to other applets which have registered their interest in the notification list 104. Applets register such notification by invocation of the first method 106. The third method 110 provides for actual processing associated with a particular applet in response to notification of the occurrence of particular event. In superclass 102, this third method 110 provides a function intended to be overridden by a function within an applet instance. The overriding method within a specific applet instance performs the actual processing required when notification is received of the occurrence of a particular event.

As noted above, Java and HTML specifications preclude applets within different frames of an HTML page from directly communicating with one another. Without the methods and structures of the present invention, an applet operable in a first HTML frame 112 and another applet operable and second HTML frame 120 would be incapable of inter-applet communication. In accordance with the present invention, first applet 114 is a specialization of (derived from) applet superclass 102. In other words, it is a subclass of applet superclass 102. First applet 114 therefore inherits objects and methods 116 defined by applet superclass 102. The inherited objects and methods 116 comprise static notification list structure 104 and methods 106, 108 and 110. First applet 114 further comprises applet specific objects and methods 118 which perform the particular processing for which first applet 114 is designed within the first HTML frame 112.

In like manner, second applet 122 is a specialization of (derived from) applet superclass 102. As a derived subclass, second applet 122 inherits objects and methods 104 through 110 as inherited objects and methods 124. In particular, second applet 122 includes an overridden event notification handler method 126 which overrides the inherited method 110. As depicted in figure 1, second applet 122 is therefore intended to receive notification of the occurrence of events from information generated by a first applet 114. For this reason second applet 122 includes the overridden event notification handler method 126. In like manner to first applet 114, second applet 122 further comprises applet specific objects and methods 128 for performing the specific processing within the second HTML frame 122.

As shown in figure 1, first applet 114 is intended to generate information (event occurrence notifications) and communicate such notifications to second applet 122 using the static features and associated methods of applet superclass 102. Those skilled in the art will recognize that first applet 114 may also include an overriding event notification handler method to permit bi-directional communications (i.e., event notification directed from second applet 122 back to first applet 114). Further, those skilled in the art will recognize that any number of additional applets operable within any number of additional HTML frames may receive event notification messages from the event notification generating applet.

Figure 2 is a flow chart describing the method (106 of figure 1) of the present invention for adding or deleting entries to the static notification list 104 of figure 1. Element 200 is first operable to lock a semaphore to assure mutual exclusivity for multiple applets attempting to manipulate the static notification list simultaneously. Element 202 is next operable to determine whether the invocation of the method has requested the addition or deletion of an entry in the notification list. If addition of an entry to the notification list is requested, element 204 is next operable to determine if the requesting applet (provided as a parameter to the method) is already present in the notification list. If no such entry is found in the notification list, element 206 is next operable to add an entry corresponding to the requesting applet to the notification list. In both cases, processing continues with element 214 to complete the method by unlocking the previously locked semaphore.

Element 204 is optional in that, depending upon the application of the communication system of the present invention, it may be unnecessary to check the list. Applets could be designed to assure that they would register once and only once. Therefore the need to check whether the applet is already in the list is obviated. However, those skilled in the art will recognize that the method as depicted in figure 2 with the optional test of element 204 may be appropriate in certain applet instances. Such design choices are well known to those skilled in the art.

Elements 208 through 212 are operable in response to a determination by element 202 that the invocation of the method requests deletion of an entry from the notification list. Element 208 is first operable to locate an entry in the notification list corresponding to the requesting applet (provided as a parameter to the method invocation). Element 210 is then operable to determine if such an entry was found by operation of element 208. If such an entry is located, element 212 is next operable to delete the located entry from the notification list. In either case, processing then continues with element 214 to complete processing of the method by unlocking the previously locked semaphore.

As noted above, the method of figure 2 is described as a single method which effectuates processing for both addition and deletion of entries in the notification list. Addition and deletion of entries may also be implemented as two separate methods as in the preferred embodiment and best presently known mode of practicing the invention described herein below. A first method for adding entries to the list and a second method for deleting entries from list. Furthermore, those skilled in the art will readily recognize that the notification list may be implemented using any of several well-known data structures and programming techniques. For example, the notification list may be a simple array into which entries are added and deleted as described herein below. Or, for example, the notification list may be implemented as a linked list structure or queue in which entries are added by linking them into the list and deleted by unlinking them from the list. Many other equivalent data structures will be recognized by those skilled in the art.

An applet which has a corresponding entry in the notification list is referred to herein as registered. Adding an entry is therefore also referred to as registering while deleting an entry is also referred to as unregistering the applet.

Figure 3 is a flow chart describing operation of a method 108 invoked to provide notification of the occurrence of a particular event. Element 300 is first operable to set a local pointer variable or other index to the first notification list entry. Elements 302 through 308 are then operable iteratively to process each entry in the notification list. Element 302 is operable to determine whether the local pointer variable indicates that it is presently pointing at the end of the list. If so, processing of the method is completed. If not, processing continues with element 304.

Element 304 is then operable to determine whether the particular event supplied as a parameter to the method invocation matches and event identification stored in the entry of the notification list. As noted in figure 3, this processing step is optional in that the processing may simply provide notification to all registered applets of all events for which notification generated. The optional processing of element 304 therefore permits filtering of the notification process to provide the information only to those registered applets seeking notification of the particular event for which notification has been generated. If the optional processing element 304 determines that the stored event in the notification list entry is not to the same as the event for which notification has been generated, processing continues with element 308 described below. If the two events are the same, element 306 is next operable to invoke the event notification handler method of the applet identified in the current notification list entry.

In the best presently known mode of practicing the invention, as discussed further below, the optional processing of element 304 is not deemed necessary. In other words, in the best presently known mode of practicing the invention all registered applets are notified of any event. The event handler method of the applets then determines which events it wishes to process further and which are of no interest. Those skilled in the art will recognize the benefit of the optional processing of element 304 where the number of communicating applets is large or where the number of different event types is large. In such applications, it may be preferred that the communication system allow filtering of event messages as noted in element 304 of figure 3. Such design choices are well known to those skilled in the art.

Element 308 is then operable to move the local pointer variable or other index to the next notification list entry. Processing then continues by moving back to element 302 to determine if more entries remain to be processed.

Figure 4 is a flow chart describing operation of an exemplary event notification handler method 110 (as overridden in the second applet 122 by method 126). The method of figure 4 generally describes the processing by element 400 as specifically required for a particular applet when notification is received of the occurrence of a particular event. As noted above, the particular event and a parameter associated with the event are provided to the invocation of the method of figure 4 as parameters.

As noted above, the particular event may or may no be of interest to the applet. The event handler method therefore performs any tests and filtering appropriate to the applet to determine which events are relevant to the particular applet. Relevant event notifications are processed in the applet (by the event handler method) and irrelevant events are simply ignored. Such design considerations are specific to the particular application of the applets and the inter-applet communication system of the present invention and are well known to those skilled in the art.

The methods of the present invention may be further understood with reference to the following Java applet sample code. In particular, the Java applet sample code described below represents the best presently known mode for practicing the invention. Those skilled in the art or recognize a wide variety of equivalent code and data structure implementations which achieve the same purpose and provide similar functionality. The Java applet sample code herein below is therefore not intended to limit the scope of the invention but rather is supplied to provide an exemplary implementation of the features of the present invention.<img file="EP0974897A2_D0001.tif" /><img file="EP0974897A2_D0002.tif" />

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character, it being understood that only the preferred embodiment and minor variants thereof have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.