With Andy's methodology we generate a generic object on the client that can create any line or bar chart. Then pass it a link or a pointer to the the data source as well as a pointer to a configuration file that tells the generic obkect how to render the data. For instance the following examples are restful calls that will give us the data and tell us wow to render it.

The existing technology that is used to create graphs and charts over the internet is based on a traditional single request methodology.

With this methodology a request is made to a web server for a graph. The server will then acquire the data from a database or some other source and transform it using simple matrix transformation algorithms into an image of a graph. Once the image has been generated the entire graph is passed back to the client as a single image or Flash application with the data embedded in the HTML.

In this current model the data may also be passed to the client object by embedding it in the HTML and allowing the embedded application to access that data on the client side. This differs from the Andy's method in that the data is not sent to the client along with the embedded application but rather a second request is mage for the data.

With Andy's method, applications or embedded objects become tightly coupled with server side application and are used to make specific request to the server for raw data and then transform that data into images. Likewise with Andy's method other aptitudes used to define the data are passed separately to the client allowing the user to select metrics and dates which can be used to define the domain set of data.

These parameters are then sent back to the server in a second request so that only the raw data needed to generate that particular view of a graph can then be requested. Once this second request is made the client will then generate the graph. This second request will allow the client to redraw the graph without having to refresh the entire page or iframe.

With this new invention graphs or images used to represent data are generated on the client side and only raw data is transferred over the network. This means that 2 requests are made to the web server. The first request is for the initial web page that contains an application or an embedded object. This object on the client then makes a second request to the server for the raw data.

With the use of Andy's method a request is made to the web server. The web server then serves up or pushes content up to the client along with the emended application. The web server will also embed dynamic JavaScript variables that represent attributes of the graph as well as pointers back to the web server in the form of a URL. This source URL will be used as a pointer back to the web server that will allow the embedded object to acquire the raw data.

This is done through the embedded object as a web service known as a REST (Representational State Transfer) call back to the server to acquire the data. This means that the URL acts like a function call so that a request is made by the client and the data is returned.

With this methodology 2 requests are made. The first request is for the html and a second for the raw data. There may be additional AJAX calls to the server in order to get the list of metric names, IDs, dates, and other attributes that can be passed back to the server through the source URL. These parameters can be used to generating the appropriate data. Once the dashboard (a collection of reports or graphs) has been configured by the user the state of that dashboard can be persisted through additional AJAX calls to the server.

The embedded object will then take this URL and make a call back to the web server. The web server will then return a set of data as name value pairs, delimited text, or XML to the embedded object. Once the embedded application on the client side receives the data it will then transform the data using a simple matrix transformation algorithm and generate an image representing the data graphically.

Andy's method makes possible the ability draw the graph on the client side in real time, instead of on the server side. By doing this there are 3 main benefits that will improve performance and usability.

• Reduced bandwidth

By only passing raw data to the client the web server only has to pass a small amount of content over the network instead of the entire image. This also means that if the user decides to modify attributes of the graph the client is able to request only the data that has changes.

• Increased response time

When new data becomes available the client can make a request to the web server for only the data that has changes. This means that the graph can be redrawn immediately when new data becomes available.  The user does not have to wait until for the entire the graph to refresh from the server. Therefore there is no delay or refresh action that has to take place for the image to update the effect to the user is an almost instantiations update.

• Reduced cycle time on the web server.

If the server does not have to generate the graph, the processing resources required to do the matrix transformations and generate the graph can be executed on the client in the browser. This will allow the client machine to share the processing resources needed to generate the presentation of the data as a graphical representation.

1. The user will go to a login page and type in their username and password. The server will authenticate the user and retrieve information about the user like customer id, available date ranges, available graphs and metrics, and the persisted state of the dashboard. This data is then embedded in the HTML and passed back to the client along with dynamic pointers back to the server so that the embedded application knows how and where to request the data. If the data is coming from a disparate source (meaning that the data exists on a different server like an Amazon web service) that information will also be passed to the client as an attribute.
2. The client will then use JavaScript to embed an object of application in the HTML. The JavaScript will then pass these parameters to the embedded object. Once the object has been instantiated on the client side in the browser and all of the appropriate attributes have been passed to it using JavaScript the object is ready to make its request for the raw data.  
3. When the embedded object is ready it will then take all of the appropriate attributes and build a URL dynamically. This URL will point back to the server as a web service request of the appropriate raw data. The embedded Object will use this URL to initiate the request and load the raw data. When the request is made the server will return the raw data to the embedded object that will load those variables into a data structure that will exist in memory on the client machine. This data will then be transformed into an image and displayed to the user as a graph.
4. When the server receives the request for raw data it will first check the session context to make sure the request is coming from a legitimate client who has been correctly authenticated. Once the request has been validated the set of parameters that have been passed to it by the client will then be used to retrieve the correct data. The actual raw data may come form a local database or from another web service. The key to this component is that the server will be able to take a set of parameters that were passed to it from the client as part of the request and use those parameters to dynamically generate the data appropriate for that particular client or request. The client may in fact have several graphs all on one page each making multiple requests. Likewise there may be hundreds if not thousands of clients all of which are making different requests back to the server for a variety of different graphs. However, the server will be able to keep track of all of these different requests and pass back only the appropriate data to each client through a combination of the parameters that are being passed to it from the client as well as the session information stored in memory on the server side.

Periodically the embedded object that generates the graph will continue to make new requests to the server and redraw the graph as new data becomes available. This request and redraw will all be transparent to the user. When new data becomes available the graph can be redrawn instantaneously without a page refresh or flicker effect. Generally when a web page reloads HTML the user will observe a flicker as the entire page will go blank for a fraction of a second as browser will re-render the HTML and any objects in it. The elimination of the flicker effect is the primary advantage of the ARD methodology.