Object oriented processing system and data sharing environment for applications therein

[0002] 1. Field of the Invention

[0003] This invention relates to a system and method for passing data from one object to another within an application in an object oriented processing system running multiple instances of the application.

[0004] 2. Description of the Prior Art

[0005] In an object oriented processing system based on an object oriented language such as Java, C++ and the like, an “application” is a collection of one or more instances of objects that perform a specific function or task and an application “instance” is one specific and independent case or request for an application's functions comprising one set of the application's object instances typically running in an assigned thread of execution. Data can be passed from one object to another object within an application via arguments to methods associated with the individual objects that comprise the application. This method of data passing has the difficult requirement that cooperating objects have advance knowledge of all the data that a called object will need, as well as all the data that will be needed by any object that works with the called object.

[0006] A second method for sharing data among objects in an object oriented processing system is the Java InfoBus API. The InfoBus API facilitates data communication between objects cooperating in the same Java Virtual Machine (JVM). Using the notion of a “bus,” the InfoBus API allows objects that implement it to “plug into” the bus. Any “plugged in” member of the bus can exchange information with any other member in a structured way. The downside of sharing data through the InfoBus API is the lack of data persistence. Because the bus structure does not retain the data after its transmission, the data cannot be referenced at some later time.

[0007] A third method for providing data to remote objects (i.e., ones not called directly) is to place them in a shared location. By way of example, in a Java-based object oriented processing system, the JVM executes the series of objects that comprise one or more Java applications. A static hash table can be defined that allows the application objects to store and retrieve data using hash table “key” identifiers. Defining a static hash table to provide for storage and retrieval of data is desirable because the key identifiers and values of key identifiers are unknown to objects at compile time.

[0008] This method works well when only one instance of the application is executing in the JVM. However, it is often desirable to run multiple instances of the same application in multiple thread groups. For example, running multiple instances of an application simultaneously in an object oriented environment can be used to advantage in a telephone call center. Multiple incoming calls at the call center require simultaneous processing. This processing can be implemented by spawning new application instances as new calls arrive. The processing of multiple calls thus results in the simultaneous execution of multiple instances of the same application. A problem arises relative to data sharing in this situation because each application instance cannot have its own static hash table. A static hash table is a “class” variable such that only one such table can reside within the JVM. Nor can multiple instances of an application running within a single JVM use the same static hash table to store local copies of data. Each application may require the placement of different information in the hash table and such storage in a single hash table might lead to data collisions.

[0009] Accordingly, there is a need in an object oriented computing environment for a system and method that allows multiple instances of applications to run simultaneously, with each spawned application instance having reliable access to its data. What is required is a system and method for providing an environment of variables and objects that are local to an application, and segregated from other applications running simultaneously therewith. (As used in this patent application, “variable” is not limited to simple String or Integer values; rather, it refers to a specific instance of any object in an object oriented processing system.)

[0010] A system and method in accordance with the invention provides a global data sharing environment and data sharing proxy agent for multiple application instances in an object oriented processing system. In response to an object in an application instance calling a data storage or retrieval method for sharing data with other objects, the data is transparently stored in or retrieved from a local data sharing environment that corresponds to the requesting object's application instance and is managed by the proxy agent within the global data sharing environment. The data sharing environment provides a “store” where data to be shared persists until it is changed or deleted, or until the supporting JVM terminates.

[0011] In preferred embodiments of the invention, local data sharing environments are implemented by creating, for each application instance, a local hash table that stores or references the data to be shared among the objects of that application instance. These data or data references are keyed by data identifiers maintained in the key indexes of the local hash tables. The preferred implementation of the global data sharing environment includes a global hash table that stores or references the local hash tables. These local hash tables or hash table references are keyed by application instance identifiers. When an object in an application instance wishes to store data in or retrieve data from its local hash table, it issues a data sharing request using one of its local hash table data identifier keys. The proxy agent operating in the global data sharing environment processes the data sharing request by determining the application instance identifier corresponding to the application instance holding the object that made the data sharing request. The proxy agent queries the global hash table using the application instance identifier as a key to identify the local hash table that corresponds to the application instance to which the requesting object belongs. The proxy agent completes the data sharing transaction by querying the local hash table identified by the global hash table query using the data identifier provided by the requesting object as the key.

[0012] The foregoing and other features and advantages of the invention will be apparent from the following more particular description of a preferred embodiment of the invention, as illustrated in the accompanying Drawing, in which:

[0013] FIG. 1 is a block diagram showing a first scheme for sharing data among objects of an application object group in a prior art object oriented processing system;

[0014] FIG. 2 is a block diagram showing a second scheme for sharing data among objects of an application object group in a prior art object oriented processing system;

[0015] FIG. 3 is a block diagram showing an object oriented processing system constructed in accordance with a preferred embodiment of the invention;

[0016] FIG. 4 is a block diagram showing a local data sharing environment for a spawned application instance object group in the object oriented processing system of FIG. 3;

[0017] FIG. 5 is a block diagram showing a global data sharing environment managing local data sharing environments for multiple instances of application object groups in the object oriented processing system of FIG. 3; and

[0018] FIGS. 6-8 are flow diagrams showing method steps performed in accordance with the invention to implement the data sharing environment of FIG. 5.

[0019] Turning now to the figures, wherein like reference numerals represent like elements in all of the several views, FIGS. 1 and 2 illustrate, by way of additional background, the prior art data sharing schemes described above wherein data is passed from object to object, as shown in FIG. 1, or placed in a static hash table, as shown in FIG. 2. More particularly, in the sharing scheme of FIG. 1, objects A, B, C and D are part of an application in an object oriented computing environment such as a JVM. Data item D2 residing in object A is passed directly to object B by means of an argument in a call to method M7. Data item D2 is then passed to remote objects C and D by means of arguments in calls to methods M4 and M5, respectively. Similarly, data item D9, residing in object B, is passed to objects C, D and A via the calls to methods M4, M5 and M1, respectively. Likewise, data item D11 is passed to objects D and A via the calls to methods M5 and M1.

[0020] In the sharing scheme of FIG. 2, objects A, B, C and D comprise an application in an object oriented computing environment, and specifically a JVM. The static hash table H resides outside an application that includes objects A, B, C and D. The hash table H1 provides a key-based storage and retrieval mechanism for the data items in each of the objects, as described above by way of background. As FIG. 2 illustrates, object A stores data item D2 in the static hash table H1 under key K2. Data item D2 is shared with remote objects C and D when those objects retrieve D2 from H1 using key K2.

[0021] Turning now to FIG. 3, an exemplary object oriented processing system 2 illustrates one possible implementation of the present invention in a telephone call processing center. As is known in the art, a call processing center provides automated call handling services in response to incoming calls to an enterprise such as a business, a governmental agency or other entity. As shown in FIG. 3, the processing system 2 includes switching circuits 4 for receiving calls from a calling party and routing those calls to an appropriate called destination, such as a telephone, a voice mail system, or the like. Program execution is provided by a central processing unit (CPU) 6 communicating over a shared bus 8 with a data storage medium 10, along with program memory 12 for use during program execution. Call processing functionality is provided by an object oriented software environment that runs on the processing system 2. In operation, the call center processes each menu-driven call by creating an application instance with storage for call-related data. As each call is processed, the objects within each application instance store and retrieve data using a novel data sharing “environment.” These application instances and data storage and retrieval mechanisms are described in more detail below.

[0022] Turning now to FIG. 4, an application instance 20 running in the object oriented processing system 2 is shown as including objects A, B, C and D, referenced by numerals 22, 24, 26 and 28, respectively. As is known in the art, these objects contain both data and methods. Logically associated with the application instance 20 is an instantiated hash table object 30, which is of class Env (described below). The hash table 30 is a key-based data storage and retrieval structure that provides a local environment that can be used by the objects A through D to share data within the application instance 20. In the example shown in FIG. 4, object A stores data item D2 (or a reference thereto) in the Env hash table 30, where it is associated with a key K2. This data is then shared when objects C and D retrieve the data item D2 from the hash table 30 using the key K2.

[0023] Turning now to FIG. 5, the Env class from which the hash table 30 was created is illustrated as a global environment Env 40. Env 40 provides data storage and retrieval services on behalf of application instances 48, 50 and 52. It contains hash tables e_globalEnv 42, e_envTbl 44 and e_threadGroupEnv 46. The e_globalEnv hash table 42 is a static hash table of global variables (global data table) to which all application instances have access and which can be used for sharing data therebetween. The hash table e_threadGroupEnv 46 is a non-static hash table template of local data keyed by data name descriptors. The hash table e_envTbl 44 is a static global hash table that is keyed by thread group identifiers and whose elements can either be references to local env objects 54, 56 and 58, or the objects themselves. As such, the hash table e_envTbl 44 is a “hash table of hash tables.” Each of the local env objects is an instantiation of the Env 40 that contains a local env.e_threadGroupEnv hash table of local data (or references thereto) keyed by data name descriptors. The local env.e_threadGroupEnv hash table for env 54 provides a data storage and retrieval mechanism for the group of objects referenced by numeral 60 in the first application instance. Similarly, for the second and third application instances, the local env.e_threadGroupEnv hash tables for envs 56 and 58 provide data storage and retrieval for object groups 62 and 64, respectively.

[0024] Env 40 also contains data storage and retrieval methods 66 that object groups 60, 62 and 64 call in order to store and retrieve data variables relative to their local environments. The steps for each of these methods are depicted in the flow diagrams in FIGS. 6-8. Advantageously, the transfer of data to and from the local environments is performed transparently and without knowledge thereof by the application instance objects. As far as each application instance is concerned, there is only a single static environment dedicated to that application instance and which is accessible via a standard set of environment method calls. Unbeknownst to the application instances, the global Env 40 responds to the method calls from objects in each application instance by accessing the application instance's local env 54, 56 or 58. The global Env 40 thus acts as a data sharing proxy agent on behalf of requesting objects. As part of this proxy agent function, and as described in more detail below, Env 40 identifies the calling object and its local environment using the object's thread group identifier. Other identifying features might also be used, as will be appreciated by persons skilled in the art.

[0025] Turning now to FIG. 6, the actions resulting from a call in step 70 to a method that either creates a data variable or changes an existing one are shown. This method shall be referred to as the “setVar” method. It is a static method and thus belongs to the Env 40 class. As is shown in FIG. 6, setVar first performs a check in step 72 for the existence of a local env.e_threadGroupEnv table corresponding to the calling object. Such a table is created in step 74 if it does not already exist. The method for creating the local environment is described below in connection with FIG. 7. The initial setVar calling and table check, as described relative to steps 70 and 72, may be implemented with the following Java commands:

[0026] public static synchronized boolean setVar(Object key,Object def)

[0027] {

[0028] return(setVar(key,def,e_dfltProperty));

[0029] }

[0030] /**

[0031] “setVar( )” creates a variable in the local environment of the ThreadGroup if the named variable does not exist either in the local or global environment. “setVar( )” insures that a local environment exists before anything else is done, hence the first call to “setVar( )” performs a “createEnv( )” call for the ThreadGroup if it has not been done already. “setVar( )” overwrites an existing variable if the variable already exists. It operates preferentially on the local environment.

[0032] */

[0033] public static synchronized boolean setVar

[0034] (

[0035] Object key,

[0036] Object def,

[0037] VarPropertiesEnum props

[0038] )

[0039] {

[0040] // Insure that a local environment exists before attempting to

[0041] // set a variable.

[0042] Env env=getEnv( );

[0043] if (env==null)

[0044] {

[0045] if (createEnv( )==false)

[0046] return(false);

[0047] env=getEnv( );

[0048] }

[0049] The getEnv( ) method, which calls createEnv( ), uses the calling object's thread group identifier to find the local environment, as the following Java code indicates:

[0050] public static Env getEnv( )

[0051] {

[0052] if (e_envTbl==null)

[0053] createEnv( );

[0054] ThreadGroup tg=Thread.currentThread( ).getThreadGroup( );

[0055] Env env=(Env)e_envTbl.get(tg);

[0056] return(env);

[0057] }

[0058] As is shown in step 76, after ensuring that a local environment table exists, setVar tests if the variable already exists in the local env.e_threadGroupEnv table. If the variable does exist in the local env.e_threadGroupEnv table, then the existing variable is overwritten in step 78. If the variable does not exist in the local environment, the setVar method checks if it exists in the global environment table e_globalEnv 42, as is shown in step 80. If the variable does exist in the global environment table e_globalEnv 42, then the existing variable is overwritten with the new value in step 82. If the variable does not exist in the local or global environment, setVar creates it in the local environment in step 84. The aforementioned tests for the existence of the variable in the local and global environments and the subsequent setting of the variable, as described relative to steps 76-84, may be implemented using the following Java commands:

[0059] // Does the variable already exist in the local environment?

[0060] // If so, change it there.

[0061] if (env.e_threadGroupEnv.getVar(key) !=null)

[0062] return(env.e_threadGroupEnv.setVar(key,def,props));

[0063] // If the variable doesn't exist in the local environment,

[0064] // but does exist in the global environment, change it in

[0065] // the global environment.

[0066] else if (e_globalEnv.getVar(key) !=null)

[0067] return(e_globalEnv.setVar(key,def,props));

[0068] // If the variable doesn't exist either place, create it in

[0069] // the local environment.

[0070] else

[0071] return(env.e_threadGroupEnv.setVar(key,def,props));

[0072] }

[0073] Turning now to FIG. 7, a flow diagram corresponding to step 74 in FIG. 6 is shown with actions invoked by a method call in step 90. This method creates a local environment table and shall be referred to as the “createEnv” method. As is shown in step 92 of FIG. 7, createEnv first checks for the existence of the static global hash table, e_globalEnv 42. If this hash table does not already exist, createEnv creates it in step 94. Similarly, step 96 performs a test for the existence of the static global hash table, e_envTbl 44 and step 98 creates the table if it does not already exist. These checks and the creation of the static global tables as described relative to steps 92-98 may be implemented with the following Java commands:

[0074] // Create your own environment based on your own ThreadGroup

[0075] public static synchronized boolean createEnv( )

[0076] {

[0077] return(createEnv((EnvOptionsEnum)null,

[0078] Thread.currentThread( ).getThreadGroup( )));

[0079] }

[0080] public static synchronized boolean createEnv(EnvOptionsEnum opts)

[0081] {

[0082] ThreadGroup tg=Thread.currentThread( ).getThreadGroup( );

[0083] return(createEnv(opts,tg));

[0084] }

[0085] public static synchronized boolean createEnv

[0086] (

[0087] EnvOptionsEnum opts,

[0088] ThreadGroup tg

[0089] )

[0090] {

[0091] if (opts==null)

[0092] {

[0093] opts=EnvOptionsEnum.defaultValue( );

[0094] }

[0095] if (e_globalEnv==null)

[0096] e_globalEnv=new VariablesCache( );

[0097] if (e_envTbl==null)

[0098] e_envTbl=new Hashtable( );

[0099] As is shown in step 100, createEnv continues with a test to determine if e_envTbl 44 contains a local environment table entry for the thread group identifier that was passed to createEnv as an argument. If e_envTbl 44 has no such entry, the method creates a new local environment in step 102, creates a new local environment table env.e_threadGroupEnv (e.g., 54, 56 or 58) in step 104, and finally puts the new local environment table entry into e_envTbl 44 in step 106. The createEnv method returns to the calling object in step 107. The check for the table associated with the key, the creation of a new local environment table entry, and the return to the calling object, as described relative to steps 100-107, may be implemented by using the following Java commands:

[0100] if (e_envTbl.containsKey(tg)==false)

[0101] {

[0102] Env localEnv=new Env( );

[0103] localEnv.e_threadGroupEnv=new VariablesCache( );

[0104] localEnv.e_envFlags=opts;

[0105] e_envTbl.put(tg,localEnv);

[0106] return(true);

[0107] }

[0108] return(false);

[0109] }

[0110] Turning now to FIG. 8, a flow diagram for retrieving data is shown with actions invoked by a method call in step 110. This method retrieves the data associated with a specific data identifier key and shall be referred to as the “getVar” method. As is shown in step 112 of FIG. 8, getVar first determines whether the hash table e_globalEnv 42 exists. If this table does not exist, a null value is returned immediately in step 113. If, however, e_globalEnv 42 does exist, step 114 accesses the calling object's thread group identifier and attempts to retrieve the local environment from e_envTbl 44 using the thread group identifier as the key. If the local environment was found based on the test in step 116, the getVar method attempts to retrieve the variable from the calling object's local hash table env.e_threadGroupEnv in step 118. If the variable was found after testing therefor in step 120, the variable is returned in step 122. If the local environment was not found in step 116, or if the variable was not found in step 120, the getVar method tries to retrieve the variable from the global environment in step 124. These steps 112-124 for using a specified key to get a local or global version of a variable may be implemented with the following Java commands:

[0111] public static synchronized Object getVar(Object key)

[0112] {

[0113] // If there is no hash table of global variables, getVar

[0114] // returns a null value.

[0115] if (e_globalEnv==null)

[0116] return(null);

[0117] // Attempt to retrieve the variable from the local hash table

[0118] // env.e_threadGroupEnv using the specified key.

[0119] Object ans=getLocalVar(key);

[0120] // If there was no local hash table or if the variable was

[0121] // not found in the local environment, attempt to retrieve

[0122] // the variable from the global hash table e_globalEnv using

[0123] // the specified key.

[0124] if (ans==null)

[0125] ans=getGlobalVar(key);

[0126] // The final answer is a null value if the variable was

[0127] // not found in env.e_threadGroupEnv or e_globalEnv.

[0128] // Otherwise, the returned answer is the variable of interest.

[0129] return(ans);

[0130] }

[0131] public static synchronized Object getLocalVar(Object key)

[0132] {

[0133] // If there is no hash table of global variables, getLocalVar

[0134] // returns a null value.

[0135] if (e_globalEnv==null)

[0136] return (null);

[0137] Object ans=null;

[0138] // Retrieve the current code's ThreadGroup and then look up

[0139] // the local hash table of variables keyed on the ThreadGroup.

[0140] ThreadGroup tg=Thread.currentThread( ).getThreadGroup( );

[0141] Env env=(Env)e_envTbl.get(tg);

[0142] // If there is a local hash table env.e_threadGroupEnv

[0143] // keyed on the ThreadGroup, attempt to retrieve the variable

[0144] // from that hash table.

[0145] if (env !=null)

[0146] ans=env.e_threadGroupEnv.getVar(key);

[0147] return(ans);

[0148] }

[0149] public static synchronized Object getGlobalVar(Object key)

[0150] {

[0151] // If there is no hash table of global variables, getGlobalVar

[0152] // returns a null value.

[0153] if (e_globalEnv==null)

[0154] return(null);

[0155] // Attempt to retrieve the variable from the hash table of

[0156] // global variables.

[0157] return(e_globalEnv.getVar(key))

[0158] }

[0159] Accordingly, an object oriented processing system and data sharing environment for applications running therein has been described. While various embodiments have been disclosed, it should be apparent that many variations and alternative embodiments could be implemented in accordance with the invention. It is understood, therefore, that the invention is not to be in any way limited except in accordance with the spirit of the appended claims and their equivalents.