Transparent optimization of network traffic in distributed systems

A distributed system having a client and a server includes a state manager interposed between the client and the server. The state manager has a capability to generate a list of object attributes required to represent a state of the distributed system and a capability to cache object attributes so as to be locally accessible by the client. The distributed system further includes a service component interposed between the state manager and the server. The service component has a capability to fetch data from the server based on the list of object attributes.

BACKGROUND OF INVENTION

1. Field of the Invention

The invention relates generally to communication between processes and, more specifically, to a method for optimizing network traffic in distributed systems.

2. Background Art

Modem enterprise applications are typically implemented as multi-tier systems. Multi-tier systems serve the end-user through a tree of client/server pairs. Enterprise systems are typically implemented with a number of components, where each component may contain multiple object instances at runtime. The components are distributed across the client/server pairs. At runtime, each component interacts with other components in the system to provide a set of functions to the system. Typically, a component will require multiple interacts with other components to accomplish a given task.

FIG. 1shows distributed components2,4in a client/server environment. The component2is the client, and the component4is the server. The client component2uses services from the server component4in order to provide functions to the system. As an example, the client component2may be a web component hosted on a web server6, and the server component4may be an application component hosted on an application server8. The client component2may contain the logic required to display content on a web browser10. In order to generate content for the web browser10, the client component2would typically need to access enterprise data, which may be held within a database12or within some other persistent data store. The client component2interacts with the enterprise data in the database12through the server component4. At runtime, the server component4includes one or more objects14, which may be persistent objects that model data within the database12or transient objects that can perform operations such as reading or writing from the database12or executing business logic.

At runtime, the client component2and the server component4belong to different address spaces, which may be in the same machine or in different machines connected by a network link, such as network link16. Before the client component2can invoke a method of a server object14, the server object14must exist in the server component4. If the server object14is not already in the server component4, the client component2needs to call on other objects already in the server component4to create the server object14. Typically, the client component2calls on an object factory18that knows how to create the server object14. Once the server object14is created or found, the client component2can invoke a method of the server object14by sending a message to the server object14. Typically, the client component2locates the server object14through an object location service20that keeps track of the location of all distributed objects in the system. The server object14executes the operation requested by the client component2and returns the result to the client component2.

One of the important aspects of distributed applications is remote transparency, i.e., the ability to hide the fact that an object may be located on a different machine, allowing local objects to send messages to the remote object as though the remote object were in the same execution space. Before the client component2can send a message to the server object14, it must know the reference to the server object14. If the client component2and server component4are hosted on separate machines, the reference to the server object14will be remote, which means that some form of remote procedure call is needed to invoke methods of the server object14. The client component2achieves remote transparency by calling into a stub object14S, which is a local representation of the server object14and implements the visible interface of the server object14. The stub object14S forwards the request from the client component2to the server object14over the network link16. The stub object14S also receives the response from the server object14over the network link16and passes the response to the client component2. Communication between the stub object14S and the server object14is transparent to the client component2.

The client component2can retrieve or update data contained within the server object14by invoking get (accessor) or set (mutator) methods, respectively, on the server object14. The programmer can use a natural object-oriented coding style for client access of server data, which is terribly inefficient. As a trivial example, the client code below requires six network calls just to access its minimal server data:

Such inefficient distribution code would result in excessive remote calls from the client to the server, which will degrade the scalability and performance of the distributed application. For optimal distribution performance, all needed data should be fetched from and then later stored back to the server with just a single network call. In between, this data should be cached and accessed on the client side as local proxy objects.

The approach described above requires the design of an optimized server application programmer interface (API) and the client proxies for the application. There are software patterns that provide guidelines for hand written optimization at the application design/development stage. See, for example, Martijn Res, “Reduce EJB Network Traffic with Astral Clones,” JavaWorld, December 2000. However, it should be noted that the design of an efficient API, such as suggested above, is too hard to accomplish by hand, particularly because the work must be repeatedly performed as the application evolves and is enhanced. For existing applications, i.e., applications that are compiled and ready-to-run, developing an efficient API would mean a total rewrite of the application. This is typically not an attractive option where considerable time and money have been spent on the existing application or resources to develop a new application are not available.

SUMMARY OF INVENTION

In one aspect, the invention relates to a distributed system having a client and a server. The distributed system comprises a state manager interposed between the client and the server and a service component interposed between the state manager and the server. The state manager has a capability to generate a list of data attributes required to represent a state of the distributed system and a capability to cache data attributes so as to be locally accessible to the client. The service component has a capability to fetch data from the server based on the list of data attributes.

In another aspect, the invention relates to a distributed performance optimizer for a distributed application. The distributed performance optimizer comprises a client portion that generates a list of attributes of remote data required to represent a state of the application and that has a capability to cache attributes from the remote data. The distributed performance optimizer further includes a server portion that fetches the attributes from the remote data.

In another aspect, the invention relates to a method for optimizing a distributed application having a client and a server. For each state of the application, the method comprises predicting a set of objects in the server and a set of corresponding object attributes required to represent the state of the application, creating a proxy for each object in the set of objects, prefetching data from the set of objects based on the set of corresponding object attributes, and caching data in the proxy.

In another aspect, the invention relates to a method for optimizing an existing distributed application having a client and a server. The method comprises interposing a distributed performance optimizer between the client and the server such that correspondence between the client and the server is routed through the distributed performance optimizer. The method further includes creating a proxy for data in the server and making the proxy locally accessible to the client, predicting a set of data attributes to fetch into the proxy for a current state of the application, fetching the predicted set of data attributes from the server and storing data attributes in the proxy, and synchronizing data attributes stored in the proxy with data attributes in the server.

In another aspect, the invention relates to a method for optimizing an existing distributed application having a client and a server. The method comprises generating a local representation of the server that is accessible to the client. The method further includes prefetching data from the server into the local representation to represent a state of the application, tracking the changes made to data fetched into the local representation, and synchronizing data in the server with data in the local representation.

DETAILED DESCRIPTION

The present invention relates to a method for optimizing an existing distributed application. The present invention relates to a method for minimizing client/server roundtrips. Further, the present invention relates to a method for merging services on a client and expanded merged services on the server. The present invention relates to a method for merging services on the service and expanded merged services on the client.

FIG. 2shows a distributed performance optimizer22, according to one embodiment of the invention, positioned in between a client component2M and the server component4(previously shown inFIG. 1). The client component2M is a modified version of the client component2(shown inFIG. 1) of the distributed application described in the background section. The client component2M is modified such that requests normally made to the server component4now go to the distributed performance optimizer22. This allows the distributed performance optimizer22to perform various optimization services in addition to processing the requests. The distributed performance optimizer22has a client portion24that interacts with the client component2M and a server portion26that interacts with the server component4. The client portion24and the server portion26of the distributed performance optimizer22communicate over the network link16.

The client portion24of the distributed performance optimizer22includes a state manager28and a transport packager30. The state manager28intercepts calls from the client component2M in order to insert optimization services, such as prefetching data from the server based on data usage pattern and merging a sequence of remote method calls into a single network call. At runtime, the state manager28learns the states and transitions in the application. A state may correspond to information displayed to an end-user, e.g., using the web browser10. In order to generate the information to display to the end-user, the client component2M may obtain data from one or more objects in the server component4, or data from a database12connected an application server8. A transition may correspond to one or more business method calls required to move the application from one state to another. Typically, the transition is initiated through user gestures, such as clicking a mouse or hitting a key. The state manager28learns the objects needed to represent each state of the application and prefetches data from the server based on this information. The state manager28may be implemented as a runtime library that includes a set of routines that are bound to the client, e.g., client component2M, at runtime.

The client-side transport packager30receives objects from the state manager28and packs the objects for transport to the server portion26. The client-side transport packager30also receives object packages from the server portion26and unpacks the object packages so that the state manager28can access the objects.

The server portion26of the distributed performance optimizer22includes a server-side transport packager32and a service component34. The server-side transport packager32receives object packages from the client-side transport packager30and unpacks the object packages so that the service component34can access the objects. The server-side transport packager32also receives objects from the service component34and packs the objects for transport to the client-side transport packager30. In one embodiment, the service component34provides application-independent services to the state manager28, such as fetching data from the server component4based on a usage description from the state manager28, synchronizing data cached in proxy objects in the state manager28with data stored in objects in the server component4, and invoking method calls on objects in the server component4.

In order to enable the distributed application to take advantage of the distributed performance optimizer22, the client component2M is instrumented such that calls that would normally be made to the server component4are now made to the state manager28. Such calls may include calls for creating, finding, or destroying objects in the server component4, calls for accessing data stored in objects in the server component4, and calls for changing data stored in objects in the server component4. To the client component2M, the state manager28is a local representation of the server component4. The state manager28includes proxies for the objects in the server component4. The client component2M interacts with the state manager28and proxies in the state manager28just as it would with the server component4and objects in the server component4. The process of modifying the client component2M would include parsing the source code or machine code for the client component2M and replacing calls for objects in the server component4with calls for proxies in the state manager28.

The state manager28processes some of the calls from the client component2M and invokes services from the service component34for calls that need to be processed by the server component4. In one embodiment, the state manager28locally processes calls for getting or setting object attributes and forwards calls for executing logic to the service component34. The state manager28is interposed between the client component2M and the object location service20so that the client component2M cannot get a reference to the objects in the server component4directly. Instead, all correspondences between the client component2M and the service component4are routed through the state manager28. As previously mentioned, this allows the state manager28to insert optimization services into the system. The process for interposing the state manager28in between the client component2M and the object location service20includes replacing calls in the client component2M normally made to the object location service20with calls to an object location service36that is internal to the state manager28. The state manager28will obtain references to objects in the server component4as needed and include the references in the proxies for the objects.

In order for the state manager28to be able to create proxies for objects in the server component4, the state manager28must have the appropriate proxy classes in its runtime library. The proxy classes are created by analyzing the server component4and determining the definition of objects in the server component4. This process can involve parsing the machine code or source code (if available) for the server component4. In some cases, the object definitions can be obtained from a descriptor file deployed with the server component4. Once the object definitions are determined, the proxy classes can be created for the server objects using the object definitions. The proxy classes would mimic the interface of the server objects and have variables for caching state from the server objects. The proxy classes are included in the state manager28, where they can be instantiated as needed. The state manager28stores references to the proxies inside an object cache38. As in the case of the server component4, the state manager28may also include one or more object factories40that know how to instantiate the proxies.

When a proxy is initially created, it does not contain server data. The state manager28determines what attributes (data) to fetch from the server object represented by the proxy based on how the client component2M uses the attributes of the server object. As previously mentioned, the state manager28has a capacity to learn dynamically how the client component2M uses the objects in the server component4. The state manager28learns by intercepting all calls from the client component2M and collecting information about the objects and attributes involved in the calls. The state manager28then uses the collected information to determine which attributes to fetch into proxies. The information required to determine which attributes to fetch into proxies may also be provided to the state manager28from the results of a static analysis of the application. The state manager28generates a list of attributes to fetch from the server component4and sends the shopping list to the service component34. The service component34then uses the shopping list to fetch data from the objects in the server component4and sends the data back to the state manager28, where they are stored in the appropriate proxies. By sending the list of attributes to the server component34, all the attributes needed for a particular state of the application can be obtained in a single network call.

The client component2M can edit the data stored in proxies. The state manager28keeps track of the changes made to the proxies. In one embodiment, the state manager28does not immediately send changes made to the proxies to the server component2. Rather, the state manager28waits until the application is ready to transition into another state. This transition is usually signaled by the client component2sending a request to the state manager28to invoke a remote business method on a server object. This remote business method is not a call to access or mutate attributes of the server object. Before the state manager28asks the service component34to invoke the remote business method, the state manager28first calls on the service component34to synchronize the server data with the data cached in the proxies. Typically, this involves invoking a method of the service component34that takes an object package and a description of what was changed by the client as parameters. The service component34updates the server objects using the data stored in the object package and the description of what was changed by the client. After the service component34updates the server objects, the state manager28then asks the service component34to invoke the remote business method. The service component34invokes the business method and returns the result to the state manager28along with the data modified by executing the business method.

As previously described, the client-side and server-side transport packagers30,32enable objects to be transported between the state manager28and the service component34. Objects typically contain a wealth of data and behavior corresponding to the union of all possible application of those objects. Therefore, objects can be quite large. To optimize the amount of data transferred over the network link16, the client-side and server-side transport packagers30,32enable the state manager24and service component34to specify exactly what portions of an object graph to package and send over the network link16. The term “object graph” means a set of objects that reference each other. When an object is packaged for transport, the objects related to that object are also packaged to ensure that the relationships between the objects are maintained. A subset of an object graph is known as an object graph projection. The client-side and server-side transport packagers30,32can recreate the original object graph with only the data specified in the object graph projection. The object graph projection can be determined based on how the client uses the server objects. The client-side and server-side transport packages30,32package objects for transport using network protocols. The objects are packaged in a format suitable for transport, such as byte stream or XML format.

FIG. 3illustrates, in flowchart form, a typical operation of the system illustrated inFIG. 2is described below. The client component2M sends a request to the object location service36for a reference to the object factory40(Step100). The state manager24intercepts the request, collects information about the request, and then yields control to the object location service36(Step102). The object location service36gets the reference to the object factory40and returns the reference to the client component2M (Step104). The client component2uses the reference to request the object factory40to find a proxy14P for the server object14(Step106). The state manager24intercepts the request, collects information about the request, and then yields control to the object factory40(Step108).

The object factory40searches the object cache38for the proxy14P (Step110). If the proxy14P exists in the object cache38, the object factory40returns the proxy14P to the client component2(Step112). If the proxy14P does not exist in the object cache38, the object factory40creates the proxy14P (Step114) and then calls the object location service20for a remote reference to the server object14(Step116). The object factory40includes the remote reference to the server object14in the proxy14P (Step118). Note that this assumes that the server object14actually exists in the server component4. If the server object14does not exist, the server object14will have to be created first before the object factory40can obtain the reference to the server object14.

Before returning the proxy14P and related objects to the client component2M, the state manager28intercepts the proxy14P and generates a list of its attributes and related objects to fetch into the proxy14P (Step120) and sends the request to the service component34(Step124) The service component34fetches the list of its attributes and related objects as previously described and returns the data to the state manager28, where the data is then cached in the proxy14P (Step126). Once the client component2M receives the proxy14P, the client component2M can access or edit the server data cached in the proxy14P (Step128). The state manager28continues to monitor interactions between the client component2and the proxy14P in order to determine how the client component2uses the data in the proxy14P and the changes made to the proxy14P (Step130). If the client component2requests for an attribute that is not cached in the proxy14P, the state manager28fetches the attribute and adds the attribute to the collection of attributes to prefetch for that particular state of the application. All of these operations, i.e. calling the remote location service for a remote reference to the server object, sending a request list of object attributes, and returning these fetched attributes, can be accomplished in a single client/server roundtrip.

FIG. 4, illustrates in flowchart form, the typical steps involved in invoking business methods in accordance with the present invention. The client component2M may invoke one or more business methods from the interface of the proxy14P. The business methods are actually implemented in the server object14. Therefore, the proxy14P needs to forward the method call to the server object14. The state manager24first collects data about the objects and attributes involved in the method call, i.e., the parameters passed in with the method call (Step132). Then the state manager28calls on the service component34to synchronize all involved proxies with their corresponding server objects as previously described (Step134). Then the state manager28calls on the service component34to invoke the business method on the server object14as previously described (Step136). The service component34returns the result of the business method and any changed data to the state manager28(Step140). All of these operations, i.e., synchronizing proxy data with server data, invoking business method call, and receiving the result of the method call, can be accomplished in a single client/server roundtrip. The state manager28passes the result received from the service component34to the client component2M (Step140).

When the client component2M no longer needs the proxy14P, the client component2M calls on the object factory40to destroy the proxy14P. A similar call may also be made by the state manager28to the server component4to destroy the server object14.

The state manager28can generate a logic script which contains a sequence of execution instructions to be performed on the server in a single roundtrip. The actions can include invoking business methods on objects in the service component34, updating objects in the service component34, and fetching data from objects in the service component34. The state manager28can also learn the business methods required to move from one state of the application and generate a logic script ahead of time based on the current state of the application.

The invention provides one or more advantages. The distributed performance optimizer collects information about how the client uses server data and uses this information to prefetch data from the server. The distributed performance optimizer caches the server data as proxy objects, which can be locally accessed by the client, thus reducing data roundtrips between the client and server. The distributed performance optimizer combines a sequence of remote calls required to put the application in a certain state into a single network call to further reduce the client/server roundtrips. The distributed performance optimizer also transfers the optimum amount of data between the client and server.