WO1999061980A1

WO1999061980A1 - Architecture for executing program code

Info

Publication number: WO1999061980A1
Application number: PCT/AU1999/000379
Authority: WO
Inventors: James Christian Ladd
Original assignee: James Christian Ladd
Priority date: 1998-05-22
Filing date: 1999-05-21
Publication date: 1999-12-02
Also published as: WO1999061980A8; AUPP365798A0

Abstract

The invention provides a software architecture which can be dynamically updated witout rebuilding the components of the system. The architecture includes objects, each having receptor for receiving instructions and associated parameters, and returning results, and an effector for performing an operation. At least one of objects (a receiving object) provides the advantages of the invention by including an object jump table listing link objects. When the receiving object receives a call message, the call message is forwarded to the link object if there is a corresponding entry in the receiving object's jump table. The forwarded call message, which is received by the link object's receptor, includes an effect instruction for the link object to operate its effector. Once the link object's effector completes its operation, it returns a response to the link object's receptor, which forwards the response to the receiving object's receptor. The receiving object's jump table can be modified by adding, removing or changing entries once the receiving object is created, and while the receiving object is running, allowing increased flexibility in the use of the described software architecture.

Description

ARCHITECTURE FOR EXECUTING PROGRAM CODE

Field of the Invention

This invention relates to architectures for executing program code.

Background of the Invention

New applications created for existing computer operating systems use system libraries (for example, dynamic link libraries in Microsoft operating systems and shared libraries in Unix-style operating systems) provided as a component of the operating system. Developers are provided information concerning available libraries and, with the aid of an supporting documentation, write new applications for use with the operating system.

This approach provides some flexibility in constructing applications as it allows programmers to define functions having the same name but which perform different (though typically similar) processing. The system determines which function to call based on the current parameters provided and the return value expected. This determination is performed either during compilation or at runtime.

This a program to dynamically determine its operation as it is running, but the available options are fixed, and cannot be changed as the program runs. Modification is only possible by recompilation, thus involving a programmer manually changing the specifications, and rebuilding the system. To implement the changes, the current version of the system must be shut down and then replaced with the updated version. Rigourous testing is required to ensure that the system is functioning correctly. This inflexibility is a significant disadvantage.

Accordingly an object of the invention is to provide a computing architecture for the execution of computer program code which can be more readily modified than the architectures presently available. Summary of the Aspects of the Invention

The invention provides an architectecture for executing program code including:

program code objects, each having a receptor, and an effector for performing an operation associated with the object, at least one of the objects also having a jump table referencing other objects;

wherein if a call message identifying a link object is sent to a receiving object, the receiving object's receptor towards the call message to the link object if the link object is identified in the receiving object's jump table, the forwarded call message including an effect instruction for the link object to operate its effector,

wherein the forwarded call message sent to the link object is received by the link object's receptor which instructs the link object's effector to perform an operation associated with that object, upon completion of which the link object's effector returns a response to the link object's receptor, which is then forwarded back to the receiving object.

The invention also provides a method of executing program code including:

sending a call message to a receiving object's receptor, the call message identifying a link object;

forwarding the call message from the receiving object's receptor to the link object's receptor if the receiving object has an entry which authorises forwarding the call message to the link object, the forwarded call message including an effect instruction for the link object to execute an operation associated with the link object; and

responding to the forwarded call message by executing an operation associated with the link object and returning a response from the link object's receptor to the receiving object's receptor once the link object completes its operation. The invention also provides a computer program product including information representing an architecture in accordance with the invention, or able to be installed on a computing system so that a user can cause a method in accordance with the invention. The invention also provides a computing system containing an architecture in accordance with the invention, or when programmed to peform a method in accordance with the invention. A computer program product can include, for example, a CD-ROM or a magnetic or optical storage device.

The invention also provides a computing operating system or computing application stored in a memory means of a computing system, or recorded in a computer program product, or transmitted over a network, the operating system or application including an architecture in accordance with the invention, or using a method in accordance with the invention.

Preferably, the jump table of objects can be modified by adding, removing or altering listed objects, thus correspondingly modifying the operations available from the respective object containing the jump table. Preferably, this modification can be done while the respective object is being used in a functioning application or operating system, that is, there is no requirement for stopping operation of the application or operating system.

Embodiments of the invention thus provides an architecture which is dynamically modifiable in a real and effective sense. As object jump table contents can be installed after the object is created or while it is running, this modification can be referred to as "training" the object.

Preferably, there are a large number of objects forming the computer program architecture and these are substantially identical in the structure of their program code, differing only in relation to the contents of their respective jump tables and in the operations performed by their effectors. Of course, to implement the invention requires only one object having a jump table, but additional flexibility is achieved by providing further objects with jump tables which can be dynamically modified as noted above. It will be understood that, by virtue of the structure of the architecture, each object can be considered as having one or more other objects within it, linked through its object jump table.

Description of Drawings

Fig. 1 is a schematic diagram representing the structure of each object of a computer program architecture according to an embodiment of the invention.

Figs. 2A to 2E are schematic diagrams representing the principal steps involved in calling up and performing of an operation utilising the preferred architecture of the invention.

Figs. 3A to 3G are schematic diagrams representing an exemplary operation as described below.

Description of Preferred Embodiments

Fig. 1 shows a building unit of a computing architecture according to the invention. This building unit is analogous with an "object" in existing architectures, but is referred to below as an Atom.

Atom 10 consists of a Receptor 12, a Jump Table 14, and an Effector 16. All external communication with the Atom is through Receptor 12. An incoming message is called a Receptor Message, and an outgoing response is called a Receptor Response. The Effector 16 is the component of Atom 10 that specifies a method or function to be peformed when instructed by the Receptor 12. Each Atom 10 typically has a single dedicated Effector for performing an operation characteristic of that Atom 10. An Effector can perform no operations if appropriate.

A Receptor Message is typically received from another Atom. In this case, the calling Atom is termed the Caller, and the receiving Atom is termed the Receiver.

When a Caller sends a Receptor Message to a Receiver, the Caller always receives a Receptor Response. (The Receptor Message does not necessarily come from another Atom, but can emanate from other sources.)

Each Atom maintains a Jump Table which allows the Atom to contact other Atoms as required. As outlined above, Receivers receive information from Callers through the Receiver's Receptor, in the form of a Receptor Message. Information is returned via a Receptor Response.

The contents of each Atom's Jump Table can be installed after an Atom is created and can be installed or modified while the Atom is running. This is referred to as "learning" or "training" the Atom. Thus the Jump Table 14 is a dynamically modifiable list of other Atoms with which Atom 10 can be linked. Each entry in the Jump Table includes a characteristic segment of program code which is effectively a Message ID (MSG ID) for an Atom with which a link can be made.

As described below, an Atom's Receptor 12 can receive a Receptor Message called a Call Message, which prompts the Receptor 12 to identify the Atom corresponding with the Call Message in the Atom's Jump Table and to communicate with that Atom.

The Effector 16 is enabled by receipt of an Effector Message from the Atom's Receptor when the Receptor receives the Call Message. Once the Effector completes its operations, it returns an Effector Response to the Receptor.

These steps are now outlined, with reference to Figs. 2A to 2E.

Step 1 (Fig. 2A)

A Receiver's Receptor 12 receives a Receptor Message from a Caller. The Receptor Message is a Call Message and includes a Message ID for another Atom (that is, not the Receiver called by the Caller) to perform an operation. The Call Message may include parameter values or arguments related to that operation. Step 2 (Fig. 2B)

Receptor 12 checks the Message ID included in the Call Message against entries in the Jump Table 14.

Step 3 (Figs. 2C & 2D)

If the corresponding entry is found, the Receptor communicates with the Atom 10^* identified by the Message ID by forwarding the Call Message to the Receptor 12^* of that Atom identified by the Message ID, together with an effect instruction. In this case, the message sent is "Apply to" Message ID. An identifer for the Atom 10 is added at the front of Call Message, which is then forwarded to the link Atom 10^*.

The Receptor Response generated by the linked Atom 10^* is in turn returned to Atom 10. (The way in which the Receptor Response is generated by the linked Atom is described below at step 4).

If the Message ID is not found in the Jump Table (see Fig. 2D), a "no such message" receptor response is returned to the calling Atom 10^*. A Receptor Response is always returned, even if there is technically no response, for which case an empty value is returned. If an error occurs during processing, an error response is provided.

Step 4 (Fig. 2E)

If the Message ID is an "Apply To" Message ID, then the Receptor 10^* calls the Effector 16^* with an Effector Message and its Effector Response is returned to the calling Atom 10 via the successive respective Receptors 12* and 12 of the linked Atom and the calling Atom which first received the Call Message.

An Effector Response is returned by the Effector 16^* to the Receptor 12^* after it completes operations and is always returned, even if there is, technically no response, in which case an empty value is returned. If an error occurs during processing, an error response is returned.

Turning to more general matters, the Call Messages that an Atom responds to are unique to each Atom, except for a set of Common Messages listed below:

Entries in the Jump Table are modified once the Atom is created, by using the Add Service, Remove Service and Change Service messages listed in the table above. This allows the Atom to respond to other messages after the Atom is created. As described above, these services or messages are set up in the Jump Table which provides links to other Atoms characterised by particular functions or operations. Modification of the Jump Table by way of the modification of available services is performed during the Atom's existence, and can be performed while the Atom is operationally available to users and to a network to which the operating system is attached. Accordingly, this process is referred to as "learning", or "training" the Atom.

Use of a uniform integrated architecture as described above allows a computer system written using the principles of the invention to dynamically add, delete, and change its operations without having to stop, rebuild, test and restart the system.

Example

The following example is briefly set out with reference to Figs. 3A to 3G. It outlines the example of an Atom asked to return a numeric value formatted as a string. The objects involved include the following pre-existing Atoms with the minimum settings indicated in the table below:

The principal steps are as follows:

Fig. 3A Start sends the Call Message (Main, "Display", 512) to the Main.

Fig. 3B Main's Receptor looks for "Display" in Main's Jump Table.

Fig. 3C Main's Receptor finds "Display" and forwards the Call Message (Display, "Apply to", Main, 512) to Display.

Fig. 3D Display's Receptor sends the Effector Message (Main, Display, 512) to its Effector.

Fig. 3E Display's Effector performs its manipulations and returns "512" to Display's Receptor.

Fig. 3F Display's Receptor returns "512" to Main. Fig. 3G Main's Receptor returns "512" to Start.

An example implementation is now described.

A pseudo-code implementation for a Receptor is set out below. The code shows both the interface and the implementation:

Receptor: receiverObject, messageId, messageName, argCount, argArray

The steps involved are:

1. Find class object for "receiverObject" 2. Get service object for message (Id, Name) from class object

3. Apply the service object to "receiverObject"

4. Return result to caller

Similarly, a pseudo-code implementation for an Effector is set out below. The details of course depend on the function to be performed by the Effector.

Effector: receiverObject, serviceObject, argCount, argArray.

The actual implementation for an Object is now described, in relation to the C programming language in the Microsoft Windows™ 95 operating system.

Step 1

Create a Win32 Dynamic Load Library for Microsoft Windows. Microsoft Visual Studio can be used for this purpose.

Step 2

Create a "main.c" source and a "main.h" header file, including suitable definitions for the Receptor. The "main.h" header file preferably defines types and structures appropriate for use by the system. The Receptor is defined as follows:

PUBSVC ObjectGRK PTR rcvr, DTA id, PTR msg, DTA argc, PTR args, PTR xtra )

Step 3

Create a stub function in the "main.c" file for the Receptor, and compile the library. An example stub follows:

PUBSVC ObjectGRI( PTR rcvr, DTA mid, PTR msg, DTA argc, PTR args, PTR xtra ) { return( 0 ) ; } Step 4

An Object is now created. If it is only necessary to integrate an existing application or library with an Object, the function implemented in Step 3 is all that is required. Of course, it is necessary to include details in the stub function to call the functions of your existing application or library.

Step 5

The next thing to implement is the "message processing".

This is done by adding the global variable "Class" to your code "main.c" and other logic as follows:

PTR Class = 0;

PUBSVC ObjectGRI( PTR rcvr, DTA mid, PTR msg, DTA argc,

PTR args, PTR xtra )

{

PTR svc = 0; if ( Class == 0 )

{

/* create class (OJT) */ Class = CreateClassOJT() ; } /* mid is special service "effect" */ if ( mid == effect id )

{

/* get effector and effect. */ svc = (*(GRIP) (*(PTR)rcvr)) (rcvr, effectorMid, 0,0); return( ( (GEIP) svc) (xtra, rcvr, argc, args) ); } else { /* find service for "mid" */ svc = Class [ mid ] ; return( (* (GRIP) (* (PTR)rcvr) ) (rcvr, effectMid, argc, args, rcvr) ); } }

The "message processing" logic determines if the Receiver of the message has a Jump Table. If there is no Jump Table, it is created.

When the "OJT" is created the logic determines if the message is the special case "effect", if it is then the Receiver's Effector is retrieved (via a call to the Receiver's Receptor) and then the Effector service is called. The result is returned to the Caller.

Any other message is processed by looking up the "OJT" for an object in the slot indicated by the message identifier "mid". If an object is found, then the objects Receptor is sent the message "effect" asking the object to call its effector service on the passed parameters. The result of the effect message is returned to the Caller.

Step 6

The function "CreateClassOJT" must now be implemented. It is a matter of design implementation at to how the function is implemented for existing objects, but following is the implementation for the Object":

Note: The implementation above does not encompass the use of "LOAD MAPS", which are externalised definitions used by Objects to describe their interactions with other components, as well as other characteristics. This is not shown as it is not mandatory to be an "Object".

Step 7

Below is example code showing the using the Object" component from a Microsoft Windows 95 application:

/* load library containing object */ HINSTANCE hLib = Load ibrary("Object .dll") ; FARPROC rcptr = GetProcAddress(hLib, "Ob ectGRI") ;

• /* call receptor for object to create a new object instance. */ PTR ans = ( (GRIP) rcptr) ( 0, newMid, 0, 0, 0 );

/* use object instance. */ FreeLibrary(hLib) ;

It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims

1. An architectecture for executing program code including:

2. An architecture as claimed in claim 1 wherein the jump table can be modified by addition, removal or alteration of entries for various link objects.

3. An architecture as claimed in any one of claims 1 or 2 wherein the jump table can be modified while the object is being used by the computing architecture.

4. An architecture as claimed in any one of claims 1 to 3 wherein entries in the jump table are installed after the object is created.

5. An architecture as claimed in any one fo claims 1 to 4 wherein the modification of the jump table can be achieved by using appropriate call messages to the object.

6. An architecture as claimed in any one of claims 1 to 5 wherein the call message originates from a calling object, being one of the program code objects.

7. An architecture as claimed in claim 7 wherein the receiving object's receptor forwards to the calling object the response received from the link object's receptor.

8. An architecture as claimed in any one of claims 1 to 7 wherein each of the program code objects has a receptor, an effector for performing an operation associated with the object, and a jump table referencing other objects, each object differing in relation to the contents of their jump tables and the operations peformed by their effectors.

9. A method of executing program code including:

responding to the forwarded call message by_. executing an operation associated with the link object and returning a response from the link object's receptor to the receiving object's receptor once the link object completes its operation.

10. A method as claimed in claim 9 further including modifying the jump table by adding, removing or altering entries for link objects.

11. A method as claimed in any one of claims 9 or 10 wherein the modification can occur while the object is being used.

12. A method as claimed in any one of claims 9 to 11 wherein entries in the jump table can be installed after the object is created.

13. A method as claimed in any one of claims 9 to 12 wherein the modification of the jump table is achieved by using appropriate call messages to the object.

14. A method as claimed in any one of claims 9 to 13 wherein the call message is sent from a calling object, being one of the program code objects.

15. A method as claimed in claim 14 wherein the receiving object's receptor forwards to the calling object the response received from the link object's receptor.

16. A computer program product including information representing an architecture as claimed in any one of claims 1 to 8.

17. A computer program product able to be installed on a computing system so that a user can cause the method as claimed in any one of claims 9 to 15.

18. A computing system containing an architecture as claimed in any one of claims 1 to 8, or when programmed to perform a method as claimed in claims 9 to 15.

19. A computing operating system or computing application stored in a memory means of a computing system, or recorded in a computer program product, or transmitted over a network, the operating system or application including an architecture as claimed in any of claims 1 to 8, or using a method as claimed in any one of claims 9 to 15.