WO2003060709A2

WO2003060709A2 - Proxy framework

Info

Publication number: WO2003060709A2
Application number: PCT/EP2003/000405
Authority: WO
Inventors: Frank Brunswig; Rudolf Niessen
Original assignee: Sap Aktiengesellschaft
Priority date: 2002-01-16
Filing date: 2003-01-16
Publication date: 2003-07-24
Also published as: AU2003235637A1; AU2003235637A8; WO2003060709A3

Abstract

Computer system, comprising an application programming interface for interacting with applications that run on the computer system, the application programming interface being connected to a proxy framework with a reference manager, for building and destroying of types and objects, and providing access to data, a method interface, for providing an application with communication to objects, and an event handler, for outputting event results with respect to objects, further provided with a communication section for communication with other computer contexts.

Description

PROXY FRAMEWORK

The invention relates to computer systems and computer system architecture in general .

Methods for communication between distributed objects are known in the art, for example the Remote Method Invocation (RMI) in Java, Distributed Common Objects Model (DCOM) from Microsoft, and ORBIX from lona (an implementation according to the Common Object Request Broker Architecture (CORBA) standards) . These methods are usable with objects that have a low frequency, i.e., communicate few method calls. A problem with these methods is the potentially reduced performance when used with distributed objects with a high frequency of method calls.

By keeping the number of method calls as low as possible and bundling calls as much as possible, the reduction of performance can be kept in check to some extend with the known methods. However, this controlling and bundling requires considerable work on part of the application designer, and prevents a priori the transparent use of distributed objects. For a very specific but frequently occurring scenario (the control of a Graphical User Interface on a server by means of a client) the ABAP Automation Controller from SAP AG of alldorf (Baden) , Germany offers a solution that gives very efficient communication between the respective objects. However, its application is limited to the

ABAP runtime environment .

Another problem with the known methods of communication between distributed objects is that the methods are not fully transparent. Objects used in Java, DCOM and the

CORBA standards are only transparent to homogeneous objects; and objects that are not , according to the native standard are not directly supported. For these other objects, interfaces and bridges are needed, and this limits the transparency. CORBA objects are transparent, but need to be . implemented according to the CORBA standard, and thus limit general application, as different programming interfaces are needed, to support non-native standards and/or objects.

The need exists for a better method for communication between distributed objects, and in particular a method that yields a better performance. To overcome the abovementioned problems, the invention provides a computer system according to claim 1.

By providing a computer system with a proxy framework according to the invention with a unified object oriented programming interface for application or system development, the transparency of different component models in the application programming interfaces is improved. By guiding communication through a remote automation controller, the performance is improved.

According to the invention, the proxy framework provides interfaces for pluggable software bridges for component models, and decides in runtime about the appropriate use of the bridges for each component, dependent on the topology of the distributed network.

The invention further relates to a program storage device readable by a computer system, embodying a program of instructions executable by the computer system to perform a method according the invention.

Advantageous embodiments of the invention are the subject of the dependent claims. Other aspects and advantages of the invention will be apparent from the following example of an embodiment of the invention, which is described referring to the Figs., in which:

Fig. 1 shows schematically a layer model of a computer control system according to the invention,

Fig. 2 shows schematically an example of a system according to the invention,

Fig. 3 shows schematically another example of a system according to the invention, and Figs. 4, 5, and 6 show schematically an example of a flow of method calls and events in a system according to the invention.

Within the context of this description, an object is a software component with an identity that can be created and destroyed in a runtime environment . The condition or status of an object is changed or inspected by using method calls. Simplified method calls are for example "Set" and "Get" , which are used to inspect or change defined properties of an object. Furthermore, objects can create and send out messages to alert potential users of status changes within an object. Distributed objects can live fully or partially in different (runtime) environment contexts. Contexts can be, for example, threads, processes, computers, and computer systems .

In the following, an example of a computer control system according to the invention will be described. In Fig. 1 a schematic layer model of a proxy framework

PF according to the invention is shown, which proxy framework can be implemented as a programming interface for object oriented programming for applications and systems. As such, the proxy framework would run on a computer system in the context of a runtime environment. The proxy framework PF has an application program interface (API) for communication with applications.. The API can be adapted to communicate with one or several programming languages or protocols, for example Java, COM, CORBA, and C++. For each programming language the API is adapted to provide for the interfaces, objects, services that the respective programming language specifies for remote method calls. The proxy framework further has a reference manager RM - and a corresponding memory manager MM. The memory manager can be connected (for example using a plug-in) with an external memory manager EMM, for example for shared memory.

The proxy framework can f rther have a method interface MI that can be connected to an invoke handler IH. The invoke handler can be connected with external plug-ins over bridges for method invocation BMI . Such externals can for example be Java methods (JAV) or a remote automation controller RAC.

The proxy framework can further have an event handler EH that can be connected to an event interface El . The event interface El can be connected with external plug- ins for event handling over bridges for event handling BEH. Such externals can, for example, be Java methods (JAV) or COM methods. The bridging elements EMM, BMI, BEH can be implemented as plug-in elements and can provide for communication with external components. In another embodiment of the invention, the bridging elements can be fully or partly integrated within the proxy framework.

In Fig. 2 an example of an embodiment of a system according to the invention is shown. A backend machine BM, for example a server computer system, runs a controlling backend application . CBA. The backend application communicates with a proxy framework PF according to the invention as described above. The proxy framework PF is in this example has a reference manager RM, a method interface MI, and an event handler EH. The proxy framework lias a remote automation controller RAC that communicates with the proxy framework; in this example the remote automation controller is integrated into the proxy framework. The remote automation controller RAC is in this example provided with a method collector MC for collecting, organizing and temporarily storing methods calls, for example, in a method queue. The remote automation controller RAC is in this example further provided with a streamer STR for packaging, for example by serialization, methods calls received from the method collector. Through the streamer, the remote automation controller can communicate with the network layer NL of the controlling backend application CBA and the backend machine BM. The remote automation controller communicates through a message dispatcher MD with the network layer NL.

Through a network connection, which can be implemented using any suitable data communication network, the backend machine BM can communicate with a front-end machine FM. The front-end machine FM, for example a client computer system, can run a user interface application UIA. The front-end machine FM is also provided with a proxy framework PF according to the invention as described above. The proxy framework of the front-end machine FM is in this example provided with a reference manager RM, a method interface MI, and an event handler EH. Optionally, the reference manager RM, the method interface MI, and the event handler EH be provided with respectively a memory manager MM, an invoke handler IH and an event interface El, as shown in the previous example. The proxy framework is further provided with a remote . automation controller RAC that communicates with the proxy framework. The remote automation controller RAC is in this example provided with a streamer STR for processing, for example by deserialization, method calls received from the backend machine BM. The remote automation controller can communicate with the network NWC through a message dispatcher MD. and the network layer NL of the front-end machine FM. The proxy framework has a Java bridge JB for communication with the user interface application UIA. In this example the Java bridge JB is part of the proxy framework.

In Fig. 3 another example of an embodiment of a system according to the invention is shown. In this example the invention can be implemented in a single computer system. A computer system WS, for example a workstation, runs a controlling application CAP. The application CAP communicates with a proxy framework PF according to the invention as described above . The proxy framework PF is in this example provided with a reference manager RM, a method interface MI, and an event handler EH. The proxy framework is further provided with a Java bridge JB for communication with a user interface application UIA. The user interface application UIA can for example run on the workstation S.

In this example no remote automation controller is used, as the proxy framework has already loaded the specific bridges for the components, ones that directly call the respective software environments. The model for the application programs, i.e., the synchronizing mechanisms, does not require changes.

The remote automation controller can, however, be implemented in embodiments with a single context, for example with a context with multiple threads. For example: calls from Microsoft COM objects that have user interface (OLE Custom Controls) can be synchronized over the message queue of the thread wherein the objects are created. This synchronization is the bottleneck for this process, and can be eliminated by the introduction of a remote automation controller according to the invention.

Elementary types of the proxy framework can be managed by their references . The reference management can be done by any suitable method, for example by simple reference counting or other known techniques such as garbage collecting. The reference manager can be implemented in one embodiment of the invention such that it does not need to rely on knowledge whether other objects have references to a variable or to other objects. Preferably, the reference manager has information about the status of variables or objects, for example whether they are still in use or not. Based on whether variables or objects are in use, the reference manager builds its internal management and the- connections to the remote automation controller and respective bridges. External memory management (EMM) can be used, implemented for example as shown in Fig. 1 as a plug-in, for example, to use and manage shared memory. Functions for creation, access and reference management can in one embodiment of the invention be provided for all elementary types within the proxy framework.

The proxy framework can have functions for elementary types, for example, for creation, access, and reference management. In one embodiment functions are provided that can increase or decrease a reference count of an instance. If in such a case the reference count goes to zero (or any other start value) , it can be regarded that this variable or object is no longer in use. The associated resources (such as memory) can be released or for elementary types be stored for reuse in a type specific cache. The reference manager can be used by the application and those bridges that can support a corresponding object model, and can also be used by the remote automation controller. In one embodiment of the invention the reference management of the proxy framework can be integrated in various software environments .

In one embodiment of the invention the proxy framework can be implemented to function without having to rely on (pre-existing) information with respect to classes; in such an implementation, the relation between objects, methods, properties and events is known at the user side and in the implemented components. The proxy framework can communicate using a dynamic invoke mechanism, with which the proxy framework can be integrated in software environments that do not natively support static object models, for example scripting engines.

The call mechanism of the proxy framework can be, based on dynamic function calls; one or more software layers can be put between the actual call and the execution of the call. In such an implementation, the inherent and transparent support of the remote automation controller can also be maintained in the case that the caller and the called live in separate contexts.

The actual call on methods can be made through an associated bridge. Viewed from the proxy framework, the remote automation controller can be seen as a bridge. The bridge can convert variables in the required object model and map the proxy framework object references onto object references for the respective applications. With a method call using the invoke handler of a bridge, the interface for the processing of parameters and return values can be similar. Therefore return values can be used immediately (for example when processing a method queue) as parameters for consecutive method calls. Return values can also be used during the processing of a method queue (once or multiple times) as return values for consecutive methods .

The respective invoke handlers can be made known within the proxy framework, for example dynamically or statically. In the static case the invoke handlers can be connected directly to the application program or system. In the dynamic case the invoke handler (s) are loaded into the application program or system during runtime. The invoke handlers are preferably implemented as plug-ins, that is with a defined interface, so that the number of invoke handlers, and therefore the number of supported object models, can be increased. The section of the invoke handler that contains the specifics of the supported object model is indicated as the bridge for this specific object model. The invoke handlers use the proxy framework and use its lifetime management of objects, the memory management for parameters and variables and the access functions . The respective bridges can be implemented as plug-ins and preferably adapted to the specific software components in which they are integrated. In one embodiment of the invention, the bridge can provide the runtime environment (for example a JavaScript engine) for the component .

The bridges can be implemented using any suitable known method, such as for example using a repository. In such a repository within the proxy framework object classes are described that the proxy framework needs for the communication with contexts connected to the proxy framework.

The effective call on any method can be made through the invoke handler; the specific object calls can be realized with bridges that are loaded into the proxy framework.

The method of synchronization can depend on the topology, as will be further described in an example hereinafter. With a topology that crosses multiple contexts the return values of the method calls can be for example updated after the synchronization. The synchronization can be triggered for example by the system or by the application program. With system- triggered synchronization, the application can for example be time driven or event driven. In case of time driven synchronization the system triggers the application as soon as the synchronization has been finished.

In one embodiment of the invention, accessing a non- actualised value in the proxy . framework can trigger a forced synchronization. These kinds of synchronizations can be implemented in performance critical systems, to for example minimize the number of roundtrips over a network.

In one embodiment of the invention, events can be used next to or instead of method calls. In one example of such an embodiment, the events can be treated as method calls that do not have return values. Events can then be represented accordingly as non-synchronizing (for example property change events) and synchronizing (for example button clicks) . This embodiment can be used for interactive user interfaces with components and controls from various software environments (for example Java Beans and ActiveX) . The processing of the events can be implemented using a publish/subscribe mechanism, in which a component or object can trigger one or more events. The user of a component (the subscriber) can register with the proxy framework for events in queued form (for example property change) or events in synchronized form (for example button clicks) . The user can decide whether an event should be synchronized or queued.

The application or system can . process the events synchronously or asynchronously. . With synchronous processing the- application or system can use, for example, a wait-for-event loop. The synchronous process can be used for example for peer-to-peer communication, and client server applications wherein the server provides user surfaces for the client .

The asynchronous processing can use, for example, a dispatch model with an event queue. Asynchronous processing can for example be used for pure client- server systems, wherein the events can be received simultaneously from for example different client systems with graphical user interfaces and/or other servers (for example, workflow systems and mailing systems) . The event queue in the server system and the event dispatcher can provide ^" for serialized distribution of events to the applications .

Also for the functioning of the events, an interface can be provided for in the form of an event handler. The event handler can be, build as a plug-in bridge and can perform the task of outputting and receiving events. The actual management of events, such as the registration and the notification can, in such a case, be done within the proxy framework. The remote automation controller according to the invention can include a collector and a streamer. The collector can build a queue of method calls. The method calls can be distinguished in several types, for example the method calls can be divided into create object, destroy object, call method, set property and get property. The management of the identities of the objects and the memory management of the variables and parameters can take place in the proxy framework. On receipt of a method call on an object the remote automation controller increases all respective references and puts the method call in the method queue . An example in pseudo code is :

Invoke (Context, Opcode, Object, Arguments, Return)

[ Reference (Context) Reference (Object)

Reference (Arguments) Reference (Return)

MethodQueue.Append (Context, Opcode, Object, Arguments, Return) ] At this point the method calls are not yet processed and the return values are not available. At the time of synchronization the streamer puts out this queue in serialized form. The streamer can provide the method queue in any possible format, independent of machine code (byte order) or code page (internationalization/Unicode) . The streamer can communicate across context borders, using any known suitable method, for example TCP/IP, HTTP, shared memory, and semaphores. During synchronization, the processing of the application can be stopped. In an embodiment of the invention, an event driven model can be used that generates an event as soon as the synchronization is finished, and accordingly at the event the reprocessing starts.

The method queue lands in the streamer of the remote automation controller of the other context (for example, a process on an other computer system) . The streamer deserializes the stream and processes the methods calls in the exact order by calls on the proxy framework. The proxy framework recognizes during

' creation of an object, which bridge should be used. If an object contains objects, the bridge is also associated to those objects. The proxy framework calls the correct invoke handler for the object. The invoke handler itself can be dependent on the object model, and can be loaded at runtime from a library. The invoke handler processes the method calls by converting the required parameters in the form required for the respective runtime environment and object model and by projecting object references of the proxy framework onto object references of ^• the object model and after completing the method call updating the return values in the proxy framework. The mapping of the proxy framework references onto the object model references can, for example, be performed by hash or slot methods.

After completing the method queue, the streamer serializes the return values. The stream is guided back into the context of the actual application. The counterpart in the original application or system receives the stream of return values. This stream is deserialized; and the changed return values are changed in the proxy framework, and the contained references that were needed for the method calls are reset. As soon as no reference has to be kept on a value, are all resources (for example, memory) for this value are released, for example, using garbage collection. In one embodiment, a cache is provided for elementary types, thereby improving performance.

In an embodiment of the invention, the remote automation controller can process bi-directional calls. To this end, the remote automation controller sends in the stream with every synchronization point a stack call counter (for example, starting with 1) , the method queue, the event queue, and the return values of already processed method calls. The synchronization across contexts is performed until the counter reaches its starting value. After that, the application can continue. With this method, the stack call processing can be performed across computer system boundaries. The methods and events can be processed serialized.

In Figs. 4-6, an example of an implementation of the invention is shown. In this example a first context Cl and a second context C2 are provided for, wherein the contexts Cl, C2 can, for example, be made up of separate computer systems, such as a server computer system and a client computer system. Both contexts are provided with a proxy framework and a remote automation controller according to the invention. Both contexts communicate through a network connection, which can be implemented using any suitable data communication network. In this example, the context Cl runs a application AP.

In Fig. 4 an example of a collector state of the proxy framework PF according to the invention is shown. An application AP creates one or more objects, and calls methods for these objects (step A in Fig. 4) ; a sample set of typical method calls (numbered I through VI) for the objects is shown in table T in Fig. 4. Every call is routed over the proxy framework PF and the reference manager RM of the proxy framework PF (step B) . The proxy framework PF in turn calls a invoke handler IH. The invoke handler IH communicates directly with the remote automation controller RAC; in another embodiment of the invention the invoke handler IH has a bridge that manages the communication to the remote automation controller RAC. When the remote automation controller RAC receives the respective method calls, the RAC stores each of them in a method queue MQ (step C in fig. 4) , together with the arguments and return values of the respective method calls. Note that the application AP does not see that any of the methods are temporarily stored; for the application, the method calls are just made.

To further process the methods calls that have been stored after a certain period number of method calls have been stored in the method queue, a synchronizing step is performed. In Fig. 5 an example of an implementation for such synchronizing step is shown, with a first context Cl and a second context C2. The application AP gives the (explicit) command "synchronize" (step D' ) to the proxy framework PF. The proxy framework PF will hand over the command to the event handler EH, step E. The event handler will then look for a subscriber to this synchronizing event (step F) , over a communication link CL. Over the link CL the remote automation controller RAC (step G in Fig. 5) is contacted and the the stored method queue MQ is then sent through a streamer interface STR to the remote automation controller. Now the event request and the streamed automation queue are sent through a communication link CL, for example, a computer network

(step H) from the first context Cl to the second context C2. In the second context, the respective streamer interface STR of the remote automation controller RAC deserializes the method queue (step I in Fig. 5) , and passes the information over to the proxy framework PF of the second context C2. Here the method calls are handled by the local invoke handler IH, which gives them out through a bridge (step J in Fig. 5) . In this example the bridge is a Microsoft COM bridge, and therefore the resulting method calls will be compliant to the COM standard (step K in Fig. 5) . Now the methods can be handled and executed by a local application AP2. The local application is running in context C2.

In the next step the return values, as result of the executed method calls, are returned to the application

AP that called the methods on the objects. In Fig. 6 is shown how this step is performed. The return values RV are communicated to the streamer STR and serialized

(step L) . The serialized data is then communicated through the communication link CL to the other context

Cl . Here the data stream is sent to the streamer STR of the RAC (step M) and deserialized. In the proxy framework PF the data is now updated (N) through the reference manager. Now the synchronization is completed (step O) and the event handler returns the call (step

P) . The synchronization is now completed for the application (step Q) and the application AP can continue.

The invention further relates to a program storage device readable by a computer system, embodying a program of instructions executable by the computer system to perform any method according to the invention. As this invention may be embodied in several forms without departing from the spirit of essential characteristics thereof, the present embodiment is therefore illustrative and not restrictive, since the scope of the invention is defined by the appended claims rather than by the description preceding them, and all changes that fall within the metes and bounds of the claims, or equivalence of such metes and bounds thereof are therefore intended to be embraced by the claims.

Claims

1. Computer system, comprising: an application programming interface (API) for interacting with applications that run on the computer system, the application programming interface (API) being connected to a proxy framework (PF) comprising a reference manager (RM) , for building and destroying types and objects, and providing access to data, a method interface (MI) , for providing an application with communication to objects, and an event handler (EH) , for outputting event results with respect to objects, further provided with a communication section (JB, RAC) for communication with other computer contexts.

2. Computer system according to claim 1, wherein said communication section is a remote automation controller (RAC) .

3. Computer system according to claim 2 , wherein the remote automation controller (RAC) has a method collector (MC) for processing method calls.

. Computer system according to claim 3 , wherein the method collector (MC) is operable to build a queue of method calls.

5. Computer system according to any of the preceding claims, wherein the remote automation controller (RAC) has a streamer STR for packaging methods calls received from the method collector (MC) .

6. Computer system according to any of claims 2-5, wherein the remote automation controller (RAC) is connected with the reference manager (RM) , method interface (MI) , and event handler (EH) over respective plug-in interfaces.

^■ 7. Computer system according to any of the preceding claims, wherein the reference manager (RM) is provided with a memory manager (MM) for accepting external memory management plug-ins.

8. Computer implemented communication method, comprising the steps of receiving method calls in a proxy -framework (PF) , routing said calls over a reference manager (RM) of the proxy framework (PF) , communicating said calls over an invoke handler (IH) of the proxy framework (PF) to a remote automation controller (RAC) , building out of said received calls a method queue (MQ) in said remote automation controller (RAC) , and sending out said method queue (MQ) .

9. Method according to claim 8, further comprising receiving said method calls from an application program in a first context, said proxy framework (PF) being located in said first context .

10. Method according to claim 8, further comprising sending out said method queue from said first context to a second context .

11. Method according to claim 10, further comprising receiving method calls from said second context .

12. Program storage device readable by a computer system, embodying a program of instructions executable by the computer system to perform a method according to any of claims 8-11.