WO2003067852A2

WO2003067852A2 - An application programming interface (api) for plug-in modules performing protocol and payload transformation

Info

Publication number: WO2003067852A2
Application number: PCT/US2003/003795
Authority: WO
Inventors: Jeremy S. De Bonet
Original assignee: Idetic, Inc.
Priority date: 2002-02-07
Filing date: 2003-02-07
Publication date: 2003-08-14
Also published as: AU2003224610A1; AU2003224610A8; WO2003067852A3

Abstract

Systems and methods for using plug-in modules to process transactions in a proxy, wherein portions of the transaction information such as client requests and corresponding server responses may be transformed before delivery to their destinations. One embodiment comprises an application programming interface (API) implemented in a proxy that enables the use of individual plug-in modules to perform transaction processing, including transformations on requests and/or responses handled by the proxy. In one embodiment, transactions are broken down into stages comprising initializing the transaction, sending an opening statement, getting a request, transforming the request, logging in and obtaining authorization, generating a response, transforming the response, sending the response, and terminating the transaction. Because the proxy uses plug-in modules for the stages, functionality and protocol support can be easily modified, and code re-use is increased.

Description

DESCRIPTION

A PLUG-IN API FOR PROTOCOL AND PAYLOAD TRANSFORMATION

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 60/354,949, entitled "A Plug-In API For Protocol And Payload Transformation," by Jeremy S. de Bonet, filed February 7, 2002, which is hereby fully incorporated by reference herein. Additionally, U.S. Provisional Patent Application No. 60/349,344, entitled "Modular Plug-In Transaction Processing Architecture" by de Bonet et al., filed January 18, 2002 and U.S. Provisional Patent Application No. 60/349,424, entitled "Network Proxy Platform that Simultaneously Supports Data Transformation, Storage, and Manipulation for Multiple Protocols" by de Bonet et al., filed on January 18, 2002U.S. Patent

Application Serial No. 10/342,113 (Attorney Docket No. IDETl 130-1), entitled "Method and System of Performing Transactions Using Shared Resources and Different Applications," by de Bonet et al., filed January 14, 2003 are incoφorated by reference herein.

REFERENCE TO APPENDICES Appendices are included in this application by way of attachment, the totality of which is hereby incoφorated by reference for all puφoses as an integral part of this application. Appendix I is entitled "Network Proxy Platform and Its Use" and includes 17 pages of text and 8 sheets of drawings, and Appendix II includes 13 pages of text and 11 sheets of drawings.

BACKGROUND FIELD OF THE INVENTION

The invention relates generally to computer and software architectures, and more particularly to systems and methods for constructing network transaction processing platfonns that comprise plug- in modules which perform transformations on client requests and server responses.

RELATED ART

A vast majority of tlie computer systems that are currently in use are not configured strictly as stand-alone devices. In other words, they are coupled to other computers, and possibly other types of devices, through one or more networks. For example, it is typical for a personal computer set up for use at a person's home or business to be connected to tlie Internet. The computer can therefore communicate with other computers through the Internet.

Many ofthe communications that occur over tl e Internet and other networks can be characterized as client — server communications. That is, one computer acts as a server and provides ("serves") data to those who request it. The computers that make tlie requests serviced by the servers are clients. Communications between clients and servers typically consist of a client generating a request for data and transmitting this request to a server, followed by a server generating responsive data and transmitting this data back to the requesting client.

Many client-server systems incoφorate a proxy to improve the efficiency ofthe system. A proxy is located between the client and server. The proxy receives requests from the client and, if possible, responds to the request without forwarding it to the server. If the proxy cannot provide a response to the request, the request is simply forwarded to the server in the same manner as if the proxy were not present. The proxy thereby reduces the load on the server.

SUMMARY

One or more ofthe problems outlined above may be solved by the various embodiments ofthe invention. Broadly speaking, the invention comprises systems and methods for processing transactions between first party and a second party, wherein communications between the parties are transformed using plug-in software modules. One embodiment ofthe invention comprises an application programming interface (API). The

API defines interfaces for a series of plug-in modules that are configured to perform various stages of processing on transactions that are handled using the API. One or more of he interfaces defined by the API are designed to enable the use of modules that perform transformations on the transactions. Because the API supports the use of plug-in modules, the specific transformation processing that is performed can be easily changed by the replacement of one plug-in module with another.

In one embodiment, the API is implemented in a network proxy application. The proxy application executes on a computer that serves as the hardware platform for the proxy. The proxy receives requests for information from network clients and transmits information responsive to the requests back to the respective clients. The proxy may retrieve the responsive information from its own cache, or it may forward the clients' requests to a server and obtain and the information from the server in response to the forwarded request. The proxy, however, is configured to modify the request, the responsive information, or both. In other words, after the proxy receives the request from the client, the proxy may transform the request in some manner before forwarding the request to the server. Similarly, after the proxy receives responsive information from the server, the proxy may transform this information before the information is forwarded to the client.

The software application and/or API described above are embodied in a computer-readable medium such as a floppy disk, hard disk drive, CD-ROM, DVD-ROM, RAM, ROM, DASD array, magnetic tape, optical storage device and the like. It should be noted that the computer readable medium may comprise a RAM or other memory which forms part of a computer system. The computer system would thereby be enabled to perform a method in accordance with the present disclosure and is believed to be within the scope ofthe appended claims. Numerous additional embodiments are also possible.

The various embodiments ofthe invention may provide a number of advantages over prior art systems and methods. For example, by transforming client requests and server responses, proxies may be able to provide additional functionality to client-server transactions and improve the performance ofthe system. Further, by breaking down the processing of transactions into stages and processing each ofthe stages in a modular fashion, the ability ofthe system to be modified to provide additional functions or to support additional protocols is greatly increased. Still further, by extending the API to include plug-in functionality, new modules can be created by parties other than the producer ofthe server application and plugged into the system without the need to expose source code.

DRAWINGS

Other objects and advantages ofthe invention may become apparent upon reading the following detailed description and upon reference to the accompanying drawings. FIGURE 1 is a diagram illustrating some of the basic components of a network system in accordance with one embodiment.

FIGURE 2 is a diagram illustrating the components of an exemplary computer system that can be used as a platform for the client, proxy or server in one embodiment.

FIGURE 3 is a diagram illustrating the modular structure of a proxy application in accordance with one embodiment.

FIGURE 4 is a diagram illustrating the relationship ofthe stages of processing of a network transaction in accordance with one embodiment.

FIGURE 5 is a diagram illustrating the replacement of a plug-in module to the proxy application in accordance with one embodiment. While the invention is subject to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and the accompanying detailed description. It should be understood, however, that the drawings and detailed description are not intended to limit the invention to the particular embodiment which is described. This disclosure is instead intended to cover all modifications, equivalents and alternatives falling within the scope ofthe present invention as defined by the appended claims.

DETAILED DESCRIPTION

One or more preferred embodiments ofthe invention are described below. It should be noted that these and any other embodiments described below are exemplary and are intended to be illustrative of the invention rather than limiting. Broadly speaking, the invention comprises systems and methods based on plug-in modules, for receiving and processing client requests in a proxy, wherein the requests and responses thereto may be transformed before delivery to the server and/or client.

One embodiment ofthe invention comprises an application programming interface (API) that enables the use of individual plug-in modules to perform transformations on requests and/or responses handled by the proxy. The API also defines interfaces for a plurality of plug-in modules that perform different stages ofthe processing ofthe transaction comprising the request and response. The API is implemented in a proxy application that is designed to handle network transactions between the client and server. In one embodiment, transactions are broken down into seven stages, including initializing the transaction, sending an opening statement, getting a request, logging in and obtaining authorization, generating a response, sending the response, and terminating the transaction. A set of plug-in modules, each one corresponding to one ofthe stages, is also provided. The plug-in modules use the API to pass transaction information from one module to the next and to thereby completely process (and transform, if necessary) the request and response ofthe transaction. Depending upon the type of communication that is being carried on between two parties, different sets of plug-in modules can be installed to provide different processing, such as providing different functionality or supporting different protocols.

The various embodiments ofthe invention may provide a number of advantages over prior art systems and methods. For example, by transforming client requests and server responses, proxies may be able to provide additional functionality to client-server transactions and improve the performance ofthe system. Further, by breaking down the processing of transactions into stages and processing each ofthe stages in a modular fashion, the adaptability ofthe system may be increased. For instance, the system may be adaptable to provide additional functions or to support additional protocols. Still further, by extending the API to include plug-in functionality, new modules can be created by parties other than the producer ofthe server application and plugged into the system without the need to expose source code.

It should be noted that, while the description ofthe various embodiments contained in this disclosure focus on the use of a network proxy to handle communications between a client and a server, other embodiments ofthe invention may involve proxies that handle communications between entities that do not have a client-server relationship.

One embodiment ofthe invention is implemented in a network environment. Referring to FIGURE 1, a diagram illustrating some ofthe basic components of a network system is shown. As depicted in this figure, the system comprises a client 12, a proxy 14 and a server 16. Client 12 is coupled to proxy 14 via a first network 13, while Server 16 is coupled to proxy 14 via a second network 15. Proxy 14 may include a memory or storage device (not shown) for caching data received from server 16. It should be noted that the network configuration illustrated in FIGURE 1 is intended to be exemplary rather than limiting. Other embodiments may employ alternative configurations. For example, there may be multiple clients and multiple servers that are interconnected by multiple individual networks. Alternatively, a client may be directly coupled to a server without an intervening network. Many such variations are possible.

The communications between client 12 and server 16 comprise network transactions. In a typical transaction, client 12 generates a request and transmits the request via network 13 to proxy 14. proxy 14 then takes one of two actions. If proxy 14 can provide a response to the request, it generates the response and returns the response to client 12. If proxy 14 cannot provide a response to the request, it forwards the request via network 15 to server 16. Upon receiving the request, server 16 processes the request and generates a response to the request. This response is returned to proxy 14, which then forwards the response to client 12. Client 12 normally cannot distinguish between responses generated by server 16 and those generated by proxy 14.

In the present systems and methods, proxy 14 does not simply forward and or respond to client requests and server responses, but also performs transformations on the requests and responses.

These transformations may be broken down into "upstream" transformations (i.e., modifications of client requests) and "downstream" transformations (i.e., modifications of server responses). The upstream transformations may be useful, for example, when it is desirable to control a client's access to resources, or to provide additional information to the server which is not included in the client's original request. The downstream transformations may be used, for example, to remove information that is present as a result of an upstream transformation by proxy 14, or to modify data (e.g., compress image files) to more closely match the capabilities ofthe client device.

Communications between client 12, proxy 14 and server 16 (as well as networks 13 and 15) can be accomplished using electronic, optical, radio-frequency, or other signals. For example, client 12 may convert signals received from proxy 14 and server 16 to a human understandable form and may convert input from a human understandable form to appropriate electronic, optical, radio- frequency, or other signals to be used by proxy 14 or server 16. Similarly, when an operator is at server 16, server 16 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human understandable form to appropriate electronic, optical, radio-frequency, or other signals to be used by proxy 14 or client 12. In one embodiment, each of client 12, proxy 14 and server 16 is implemented in a corresponding computer system. These computer systems may comprise general puφose desktop computers, laptop computers, or other types of devices capable of communicating over the networks and processing the information communicated between them. Referring to FIGURE 2, a diagram illustrating the components of an exemplary computer system is shown. The computer system illustrated in this figure may be used as a platform for client 12, proxy 14 or server 16. As shown in FIGURE 2, computer system 20 comprises a central processing unit ("CPU") 22, read-only memory ("ROM") 24, random access memory ("RAM") 26, hard disk drive ("HD") or storage memory 28, and input/output device(s) ("I/O") 29. I/O 29 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. The computer systems that provide platforms for the client and server may each have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For simplicity, the computer illustrated in FIGURE 2 is depicted in as having one of each ofthe listed hardware components. It should be noted that FIGURE 2 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to persons of skill in the art. "Computer" and "computer system," as used herein, are intended to include any type of data processing system capable of performing the functions described herein. "Computer-readable media," as used herein, refers to any medium that can store program instructions that can be executed by a computer, and includes floppy disks, hard disk drives, CD-ROMs, DVD-ROMs, RAM, ROM, DASD arrays, magnetic tapes, floppy diskettes, optical storage devices and the like. As explained above, the different protocols that can be supported and functionalities that can be provided by different proxies and servers may result from the use of different software applications. The support of different protocols and functionalities is facilitated in the present embodiment by running a modular software application on the proxy computer. More particularly, the software application uses an API that enables individual plug-in modules to be used to perform different stages ofthe processing of network transactions.

Referring to FIGURE 3, a diagram illustrating the structure of a proxy application in accordance with one embodiment is shown. As shown in the figure, a network proxy application 40 runs on top ofthe operating system 30 ofthe proxy computer. Network proxy application 40 includes an API 45 through which the application interfaces with a plurality of plug-in modules 50. Plug-in modules 50 perform the processing of transactions handled by the proxy. The flow of data from one module to another is indicated by the arrows extending from one module to the next. The data is transferred between modules via API 45.

It should be noted that, for the puφoses of this disclosure, like items in the figures may be indicated by the same reference number, followed by a lowercase letter, e.g., 50a, 50b, and so on. The items may be collectively referred to herein simply by the reference number, without the lowercase letter. It should also be noted that "n" is used herein (e.g., "50n") to indicate a variable number, rather than to specifically indicate the 14th item in a series of items (i.e., because n is the 14th letter in the alphabet).

A subset of plug-in modules 50 correspond to the different stages of transaction processing that occur in almost all network proxies. These stages include: initializing the transaction; sending an opening statement; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction. Additionally, in this embodiment, plug-in modules 50 include a module that transforms requests received from the client, and a module that transforms responses received from the server. These stages, particularly the transformation of requests and corresponding responses, will be described in more detail below. It should be noted that, while the present embodiment utilizes the specific modules described below, other embodiments may partition the processing of transactions in a different manner and may therefore use a different number of stages that include different portions ofthe overall processing.

Each of modules 50a — 50n performs the processing for a corresponding portion ofthe overall processing ofthe transaction. In one embodiment, each module performs its processing, then passes the resulting information to the next module, which performs its processing, and so on, until the transaction is completely processed. Thus, in the case of a network proxy situated between a client and server, a client request would be received by module 50a, which would begin processing the request and then pass its results to module 50b. Module 50b would process the information received from module 50a and then pass its results to module 50c. This would be repeated for each module, concluding with module 50n, which would transmit the response to the original request back to the client.

As indicated above, one embodiment ofthe present system includes modules for transformation ofthe client requests and server responses in addition to modules for the normal processing ofthe transactions. The transformation modules include an upstream module and a downstream module. The upstream module is designed to transform a request that is received from the client before a response to the request is generated, while the downstream module is designed to transform the response to the request before the response is returned to the client. In one embodiment, the proxy application and/or the API are configured to enable caching ofthe transformed response data. Just as the processing performed by each ofthe non-transformation modules corresponds to a particular stage in the overall processing ofthe transaction, the transformations performed by each of the transformation modules can also be considered stages in the processing ofthe transaction. The relationship of these stages is illustrated in FIGURE 4.

Referring to FIGURE 4, a diagram illustrating the stages of processing of a client-server transaction in accordance with one embodiment is shown. As depicted in the figure, the non- transformation stages ofthe processing comprise initializing the transaction; sending an opening statement; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction. Processing stages _ — _ are described in more detail in U.S. Patent Application Serial No. (Attorney Docket No. IDETl 130-1), entitled "Method and System of Performing Transactions Using Shared Resources and Different Applications," by de Bonet et al., filed January 16, 2003, which is incoφorated by reference herein. Upstream transformation ("transform request") stage 84 immediately follows "get request" stage 83. Downstream transformation ("transform response") stage 87 immediately precedes "send response" stage 88.

Proxies typically cache responses received from the server so that later requests for the same information can be serviced by the proxy. That is, upon receiving the same request again, the proxy can respond directly by retrieving the responsive data from the cache and sending this data to the client. The data sent to the client is the same data previously provided by server. In the present embodiment, the proxy is configured to cache the transformed response rather than the response provided by the server. Thus, the proxy can respond to later, identical requests without having to send a transformed request to the server or to transform the received response.

It should be noted that the relative positions of these stages may vary in other embodiments. For example, the processing corresponding to upstream transformation stage 84 and downstream transformation stage 87 could immediately precede and follow, respectively, "generate response" stage 88. The stages need not even be separate, h another embodiment, the processing of both upstream transformation stage 84 and downstream transformation stage 87 could be included in the processing of "generate response" stage 88.

The particular type of transformation processing implemented in the present systems and methods may vary from one embodiment to another. For example, in one embodiment, the upstream transformation processing may consist of identifying a resource which the client is attempting to access via the request, determining whether the client is authorized to access this resource and, if the client is not authorized to access the requested resource, the request may be modified to identify a different resource for which the client has access authorization. In another example, the upstream transformation processing may consist of adding information to the request before forwarding it to the server. Such information might include information relating to the client device (e.g., device type or location), or information relating to usage of the requested resource (e.g., an account number to which the resource service should be billed).

The processing embodied in the downstream transformation may also vary from one embodiment to another. For example, it may not be necessary or desirable to include information that is added to the request by the upstream module in the response that is transmitted back to the client. The downstream transformation may therefore consist of removing this information from the response before the response is forwarded to the client, hi another example, the downstream transformation may consist of adding cache control headers to the response in order to facilitate coordination of caches in the proxy and client, hi yet another example, the transformation may consist of manipulation of images within the responsive data (e.g., color reduction or compression of images). This system may provide a number of advantages over the prior art. For example, proxies in the prior art typically do not perform any type of transformation on the requests or responses better communicated between the client and server, so the present system may provide additional capabilities through the transformations. Further, because the system is designed to use plug-in modules for the processing ofthe transactions between the client and server, the capabilities of a particular proxy can be easily modified by replacing one or more current modules with new modules that provide the desired functionality. Still further, because the modules are plugged into an API that exposes the fimctionality required to plug modules into the proxy application, these modules can be created by parties other than the producer ofthe proxy application.

Referring to FIGURE 5, a diagram illustrating the replacement of a plug-in module to the transaction processing application is shown, h this example, the application is first configured with plug-in modules 50a-50n. Module 50i is configured to perform the upstream transformation of received requests. In order to modify the manner in which the requests are transformed, it is only necessary to provide a new plug-in module, 5 li, that provides the desired transformation functionality and to replace the original module, 50i, with the new module, 5 li. It should be noted that any one or more of plug-ion modules 50a-50n may be replaced in this manner. The replacement ofthe modules may be employed to modify the functionality of the system (e.g., to transform requests in a different manner), or to support different protocols. It should also be noted that the proxy application may instantiate multiple processing pathways, so that different types of transactions can be handled by the proxy in different ways. The operation ofthe proxy can therefore be easily modified by replacement of individual plug-in modules, rather than the rewriting or replacement ofthe entire proxy application. The embodiments described above the focus on the higher-level system ofthe proxy. It should be noted that alternative embodiments ofthe invention may comprise the proxy application itself, or even the API that enables the use ofthe plug-in transformation modules. The details of an API in accordance with one embodiment are described below.

In this embodiment, the API comprises an upstream API and a downstream API. The upstream API is responsible for rewriting the client request, and potentially responding directly to it. The downstream API is used after the rewritten request is issued by the proxy on behalf of the client. The downstream module is applied to the response from the content server, and is able to transform both the response header and the response content before it is sent back to the client.

The upstream API includes a formal declaration for a plug-in module that performs the upstream transformation. In one embodiment, the formal declaration for this module may be as follows. typedef bool (*UpsfreamModule)

(

// outputs Header & hdrOut,

Buffer & buffOut, Log & logSummary, bool & backToClient

Parameters & parameters,

// inputs const Header & hdrRequest, const Buffer & BuffRequest, const int fallbackOrder

); The general process performed by the upstream module comprises transforming the request header into the output header, and optionally providing an output buffer that is sent directly to the client when backToClient is set to true. Setting backtoClient to true circumvents sending the transformed request to an external content server and subsequently calling the downstream transformation module. New upstream modules can be installed using the function: void InstallUpstreamModule(const char *sName, UpstreamModule fxn);

Existing upstream modules can be called from within other modules using the function: bool ExecUpstreamModule( const char *sName,

// module arguments Header & hdrOut, Buffer & buffOut,

Log & logSummary, bool & backToClient,

Parameters & parameters, const Header & hdrRequest, const Buffer & buffRequest const int fallbackOrder );

The general process performed by the downstream module comprises transforming the content server response header and response buffer into the output header and buffer. The output header and buffer are then sent to the requesting client. typedef bool (*DownstreamModule)

(

// outputs

Header & hdrOut, Buffer & buffOut,

Log & logSummary,

// inputs const Header & hdrReceived, const Buffer & buffReceived, const Header & hdrRequest, const Buffer & buffRequest const int fallbackOrder, const Parameters & parameters );

A downstream module can be registered with the following function. Additionally, this function takes a NULL terminated list of parameter names. The values for these parameter names are used in one embodiment to distinguish between cache entries. In order for transformed content to be pulled from the cache in this embodiment, all parameters in this list must exactly values corresponding to the pulled content. The value of any parameters which are used by this module but not in this list will not be considered when checking for a cache hit. void InstallDownstrearnModule( const char *sName, DownstreamModule fxn, ...

); Existing downstream modules can be called from within other modules using the following function. bool ExecDownstreamModule( const char *sName,

// module arguments

Header & hdrOut,

Buffer & buffOut,

Log & logSummary, const Header & hdrReceived, const Buffer & buffReceived, const Header & hdrRequest, const Buffer & buffRequest const int fallbackOrder, const Parameters & parameters );

By decomposing a network proxy into these two modular stages using the API specified herein, the creation of new modules (potentially by third parties) which allow for different functionality is made easier than with methods in the prior art.

Portions ofthe methods described herein may be implemented in suitable software code that may reside within ROM 24, RAM 26, hard disk drives 28 or other computer-readable media within the system. The software code may also be contained on a separable data storage device, such as a removable hard disk, or on removable computer-readable media such as a DASD array, magnetic tape, floppy diskette, optical storage device, or the like. In one embodiment, the software code may comprise lines of compiled C , Java, or other language code. The various software components may reside on a single computer or on any combination of separate computers. Other configurations may also be used. For example, the functions of proxy 14 may be implemented in multiple computers that interact to perform the functions ofthe proxy. Additionally, a computer program or its software components within such code may be embodied in more than one computer-readable medium. Similarly, components ofthe software may reside on multiple computers.

The benefits and advantages which may be provided by the present invention have been described above with regard to specific embodiments. These benefits and advantages, and any elements or limitations that may cause them to occur or to become more pronounced are not to be construed as critical, required, or essential features of any or all ofthe claims. As used herein, the terms 'comprises,' 'comprising,' or any other variations thereof, are intended to be inteφreted as non- exclusively including the elements or limitations which follow those terms. Accordingly, a system, method, or other embodiment that comprises a set of elements is not limited to only those elements, and may include other elements not expressly listed or inherent to the claimed embodiment.

While the present invention has been described with reference to particular embodiments, it should be understood that the embodiments are illustrative and that the scope ofthe invention is not limited to these embodiments. Many variations, modifications, additions and improvements to the embodiments described above are possible. It is contemplated that these variations, modifications, additions and improvements fall within the scope ofthe invention as detailed within the following claims. APPENDIX I NETWORK PROXY PLATFORM AND ITS USE

Reference is made in detail to exemplary embodiments ofthe network proxy platform and its use, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements). A method and system can comprise a software architecture that allows different applications in the same or different communications protocols to interact with shared resources within a computer. More specifically, code for a computer program may be written to increase the amount of code that is generic to (i.e., shared by) more than one application or communications protocol and reduce the amount of code that handle application-specific or protocol-specific actions. In one embodiment, a transaction may be broken down into a set of discrete actions. The discrete actions may include functions that are common to more than one network application. These functions may be performed by the shared resources. For each action, code that is specific to a particular protocol or application may be written as part of a software plug-in module with function calls to functions ofthe shared resources. Each software plug-in module may substantially act similar to a manager for the action, where common tasks are delegated to the shared resources and the module performs specialized functions. Each protocol may have its own set of software plug-in modules for the discrete actions. New applications and support for new protocols can be added by developing a new set of plug-in modules instead of writing an entirely new program. New applications for the same protocol may be developed by replacing or editing as little as one plug-in module from a different application in the same protocol. The software architecture can reduce development time, increase the likelihood that new applications may be developed quickly with fewer changes from an existing application, more protocols will be properly supported, and reduce the burden on hardware and software resources.

A few terms are defined or clarified to aid in understanding the descriptions that follow. A network includes an interconnected set of server and client computers over a publicly available medium (e.g., the Internet) or over an internal (company-owned) system. A user at a client computer may gain access to the network using a network access provider. An Internet Service Provider ("ISP") is a common type of network access provider.

As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such method, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one ofthe following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

The term "software component" is intended to mean at least a portion of a computer program (i.e., a software application). An example includes a software plug-in module or the like. Different software components may reside in the same computer program or in different computer programs on the same computer or different computers.

Before discussing embodiments ofthe network proxy platform, an exemplary hardware architecture for using network proxy platform is described. FIG. 1 illustrates such an exemplary hardware architecture and includes client computer 120, proxy computer 140, and server computer 160. Client computer 120 and proxy computer 140 are bi-directionally coupled to network 11, and proxy computer 140 and server computer 160 are bi-directionally coupled to network 13. Each of networks 11 and 13 may be an internal network or an external network (e.g., the Internet). In one embodiment, networks 11 and 13 may be the same network, such as the Internet. Computers 140 and 160 may be bi-directionally coupled to databases 14 and 16, respectively. Client computer 120 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular phone, or nearly other device capable of communicating over network 11. Other client computers (not shown) may also be bi-directionally coupled to network 11. The proxy computer 140 can be a server computer, but in another embodiment may be a client computer. Other server computers (not shown) similar to server computer 160 may be bi-directionally coupled to network 13.

In an alternative embodiment, each of proxy computer 140 and server computer 160 may be replaced by a plurality of computers (not shown) that may be interconnected to each other over a network or a combination of networks. For simplicity, a single system is shown for each of proxy computer 140 and server computer 160. The client computer 120 can include central processing unit ("CPU") 122, read-only memory

("ROM") 124, random access memory ("RAM") 126, hard drive ("HD") or storage memory 128, and input/output device(s) ("I/O") 129. I/O 129 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. Proxy computer 140 can include CPU 142, ROM 144, RAM 146, HD 148, and I/O 149, and server computer 160 can include CPU 162, ROM 164, RAM 166, HD 168, and I/O 169.

Each ofthe computers in FIG. 1 may have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For simplicity, each computer is illustrated as having one of each ofthe hardware components, even if more than one is used. Note that FIG. 1 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to skilled artisans. Each of computers 120, 140, and 160 is an example of a data processing system. ROM 124, 144, and 164; RAM 126, 146, and 166; HD 128, 148, and 168; and databases 14 and 16 can include media that can be read by CPU 122, 142, or 162. Therefore, each of these types of memories includes a data processing system readable medium. These memories may be internal or external to computers 120, 140, or 160.

Portions ofthe methods described herein may be implemented in suitable software code that may reside within ROM 124, 144, or 164, RAM 126, 146, or 166, or HD 128, 148, or 168. The instructions in an embodiment may be contained on a data storage device, such as HD 148. FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202, on HD 148. Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device. hi an illustrative embodiment, the computer-executable instructions may be lines of compiled assembly, C, C*^"*^", Java, or other language code. Other architectures may be used. For example, the functions of any one of the computers may be performed by a different computer shown in FIG. 1. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

In the hardware configuration above, the various software components may reside on a single computer or on any combination of separate computers. In alternative embodiments, some or all of the software components may reside on the same computer. For example, one or more the software component(s) ofthe proxy computer 140 could reside on the client computer 120, the server computer 160, or both. In still another embodiment, the proxy computer 140 and database 14 may not be required if the functions performed by the proxy computer 140 are merged into client computer 120 or server computer 160. In such an embodiment, the client computer 120 and server computer 160 may be bi-directionally coupled to the same network (not shown in FIG. 1).

Communications between any ofthe computers in FIG. 1 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, when a user is at client computer 120, client computer 120 may convert the signals to a human understandable form when sending a communication to the user and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by, computers 140 or 160. Similarly, when an operator is at server computer 160, server computer 160 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by computers 120, 140, or 160.

Attention is now directed to the methodology of developing a software architecture for the software in accordance with one embodiment. The method can comprise breaking down a transaction into a set of discrete actions. The actual definitions used for separating the transaction into the discrete actions is variable and may be selected by skilled artisans in manners that best suit their particular transactions, hardware requirements, and software requirements. The method can also include determining which functions within the set of discrete actions are common to more than one application. As more are identified, the number of shared resources can increase and the amount of application-specific code can be decreased. Therefore, skilled artisans are encouraged to examine the software from many different levels of abstraction to discover potential shared resources that may otherwise be missed.

The method can further comprise generating software components for the discrete actions. A set of software plug-in modules can correspond to the different discrete actions for the transaction. Each application may have its own set of software plug-in modules. The amount of code within each software plug-in module should be kept relatively low if the identification of shared resources was performed properly. To the extent code for any shared resources does not currently exist, code for the shared resources should be generated to maximize its ability to be used by as many different plug-in modules as possible. At least two ofthe software plug-in modules for different applications, whether they use the same or different protocols, can make function calls to any one or more ofthe shared resources. For different applications using the same protocol, only a request manipulation plug-in module, a content manipulation plug-in module, or both may be the only modules changed. Therefore, creating new application for the same protocol may be simplified because other plug-in modules used for the application may be copied from another application using the same protocol. These other plug-in modules may be substantially the same between the applications. By replacing or editing the request manipulation plug-in module, content manipulation plug-in module, or both, new applications may be developed very quickly.

Regarding applications in different protocols, each protocol may have a module that performs substantially the same action as any or all ofthe similar module(s) for the other protocol(s) though reducing this duplicative code by combining the common functionality is preferable.

Attention is now directed to the software architecture ofthe software in accordance with one embodiment. The software architecture is illustrated in FIGs. 3 and 4 and is directed towards an electronic transaction that can be performed over a network. A basic idea behind the architecture is to allow programming code for shared resources to be commonly used by as many different network applications as possible. Note that all ofthe resources may or may not be shared by all the applications. The programming code for each application-specific plug-in module may include code to connect the incoming communication in any supported application to the shared resources. By limiting the code within the plug-in modules, a user ofthe software architecture can reduce development time, increase the likelihood that more applications in the same or different protocols will be properly supported (especially proprietary protocols that may be used by only a limited number of computers or users), and reduce the burden on hardware and software resources for different applications because only relatively small plug-in modules may be used.

In FIG. 3, each row of boxes 3200, 3400, and 3600 represents different applications in the same or different protocols. For example, row 3200 may represent a first application using HTTP, row 3400 may represent a different application using HTTP, and row 3600 may represent yet another application in a different protocol, such as POP, SNMP, WAP, and the like. Note that the series of dots between rows 3400 and 3600 indicate that many other applications in the same or different protocols may be present. Additionally, the architecture may be configured to allow the addition of future applications. The software architecture easily supports at least three different and potentially many more protocols .

Referring to row 3200, each ofthe boxes 3202 through 3214 represents different stages (actions) that may occur during an electronic transaction. For example, box 3202 may represent a request reception plug-in module, box 3204 may represent an authorization plug-in module, box 3206 may represent a request manipulation plug-in module, box 3208 may represent a content retrieval plug-in module, box 3210 may represents a content manipulation plug-in module, box 3212 may represent a content delivery plug-in module, and box 3214 may represent a post-response communication plug-in module (e.g., acknowledgement, billing, etc.). Each module may correspond to one or more ofthe discrete actions. Details about the individual plug-in modules are described later in this specification. Note that the other rows 3400 and 3600 include corresponding boxes for substantially the same types of actions except that they are designed for different applications. More specifically, box 3402 represents an incoming message reception plug-in module for a different application using the same protocol as box 3202, and box 3602 represents an incoming message reception plug-in module for yet another application using a different protocol compared to box 3202. New applications that make use of already-supported protocols can be developed with a minimum of effort. This is achieved by creating a new row, which makes use of protocol specific plug-ins used in another row and combines them with other plug-ins developed for the specific application at hand. Some plug-in modules may be substantially the same for many different applications in the same protocol. In different protocols, the plug-in modules for at least some ofthe different applications may provide substantially the same functionality, although the code within those plug-in modules may be different compared to similar modules for the other protocols.

Within the software architecture, shared resources are illustrated as planes 3102, 3104, and 3106 that lie beneath each ofthe rows 3200, 3400, and 3600. Referring to FIG. 4, interfaces may be made to each ofthe shared resources for each plug-in module. Specifically referring to box 3214, functional connectivity 4102 links module 3214 and shared resource 3102. Likewise, functional connectivity 4104 links module 3214 and shared resource 3104, and functional connectivity 4106 links module 3214 shared resource 3106. Links 4102, 4104, and 4106 can be achieved by function calls to the shared resources. Examples ofthe shared resources may include a content cache, a parameter cache, a connection pool, a domain name server cache, a clock, a counter, a database, a global variables space (e.g., a logging database), or the like. A list of potential shared resources is nearly limitless. Note that not all shared resources may be connected to all modules along a row. For example, modules 3202 and 3204 may not need access to the content cache because they may not receive or process content returned for a request. Each connection from a client may be handled independently on its own thread. However in other embodiments, fewer threads or a single thread can be used to operate all connections to a specific row that supports a particular application or protocol. Unless stated to the contrary, the method below is described from the perspective of proxy computer 140.

FIG. 5 includes a flow diagram of a method of performing an electronic transaction that corresponds to the software plug-in modules that lie along any of rows 3200, 3400, and 3600. Note that all modules are not required and that functions of some modules may be combined with others (e.g., authorization may be part of processing an initial request). The process flow diagram will be briefly covered followed by a more detailed description of each module.

The method can comprise receiving a request from a client computer using a request reception plug-in module (block 502) and performing authorization using an authorization plug-in module (block 504). The method can also comprise manipulating a request using a request manipulation plug-in module (block 512). The method can further comprise retrieving content using a content retrieval plug-in module (block 522). The method can yet further comprise manipulating returned content using a content manipulation plug-in module (block 532) and sending the modified content to the client computer using a content delivery plug-in module (block 534). The method can still further comprise processing post-response communications using a post-response plug-in module (block 542). Note that not all of the activities described in the process flow diagram are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some ofthe activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs. Attention is now directed to the protocol-specific plug-in modules along the rows 3200, 3400, and 3600 and how they are related to the activities illustrated in FIG. 5. Although the discussion is directed to row 3200, the corresponding modules along other rows can provide similar functionality. Also, in the example below, client computer 120 is sending a request for content to proxy computer 140, and server computer 160 is providing content in response to the request. The flow of information could be in the opposite direction (server computer 160 seeking information from client computer 120). The method can comprise receiving a request from client computer 120 using request reception plug-in module 3202 (block 502 in FIG. 5). Request reception plug-in module 3202 can be used when a request from client computer 120 is received or accessed by proxy computer 140. Module 3202 can initially generate an associative array from portions ofthe header ofthe request. Part or all ofthe associative array may be used by the other modules along the same row. The associative array may provide information that can be part of function calls to the shared resources. Any or all the data (including the associative array) may be passed from any prior plug-in module (e.g., module 3202) to any or all the subsequent plug-in modules along the same row (e.g., 3204, 3206, 3208, 3210, 3212, or 3214). The method can also comprise performing authorization using authorization plug-in module

3204 (block 504). The authorization plug-in module 3204 is optional and can be used for determining whether a user at client computer 120 has proper authorization. The authorization modules may be based on an Internet Protocol ("IP") address or a name and a password. Module 3204 may send the P address or name and password to a shared resource to determine if the user is allowed access. The method can further comprise manipulating the request using request manipulation plug-in module 3206 (block 512). Request manipulation plug-in module 3206 may be used to modify, replace, or otherwise manipulate the request. For example, proxy computer 140 may have code to redirect a URL within a request to a different URL. More specifically, proxy computer 140 may make a function call to that shared resource using the requested URL. The shared resource may pass the different URL back to module 3206. Module 3206 may have the logic to put the different URL in the correct protocol, so that it will be understood by a computer that may receive the redirected request.

The method can yet further comprise retrieving content using content retrieval plug-in module 3208 (block 522). Content retrieval plug-in module 3208 may be used to send the request and receive or access content in response to the original request or manipulated request. More specifically, a request originating from client computer 120 may have been processed by proxy computer 140 before being received by server computer 160. Content from server computer 160, in response to the processed request from proxy computer 140, would be processed using module 3208. Similar to module 3202, the code may parse the content from server computer 160 into a header portion and a content portion and append that information onto a previously generated associative array. The method can still further comprise manipulating returned content from the server computer using content manipulation plug-in module 3210 (block 532). Content manipulation plug- in module 3210 may be used to add or modify content before sending it to client computer 120. More specifically, proxy computer 140 may add advertisements or supplementary information from third parties to the content provided by server computer 160. In an alternative embodiment, part or all of the content originating from server computer 160 may be deleted or replaced with other content. The method can comprise sending the modified content to the client computer using content delivery plug-in module 3212 (block 534). Content delivery plug-in module 3212 may be used to route the content, after manipulation, if any, to client computer 120. Some ofthe information in the associative array generated when the original request from client computer 120 was processed may be used by module 3212 when sending the outgoing content to client computer 120.

The method can also comprise processing post-response communications using post-response plug-in module 3214 (block 542). Post-response communication plug-in module 3214 may be used for acknowledgement, billing, or other puφoses. For example, after content is successfully sent to client computer 120 from module 3212, module 3124 could then charge the user's credit card for that transaction. Alternatively, module 3214 may look for a signal that service to or from client computer 120 or server computer 160 is being terminated for the current transaction. Such post-response processing may be helpful in avoiding invoices or other bills sent to a user at client computer 120 if a product or service was either incomplete or defective or to properly reflect the connect time for a transaction. Along similar lines, one ofthe planes as illustrated in FIG. 3 may include global space variables that may need to be used by other shared resources, proxy computer 140, or the plug-in modules. System statistics are examples of information that may be within a global variable space. This information may be useful to proxy computer 140 or another computer, such as client computer 120 or server computer 160, in monitoring activity. The statistics may include how many computers are connected to proxy computer 140, the amount of time each of those computers are connected to proxy computer 140, the amount of or time lapsed during transactions being processed through proxy computer 140, or the like.

These global variables may be used in conjunction with a module, such as authorization module 3204. If too many users are currently logged into proxy computer 140, authorization may be denied even if the computer attempting a connection to proxy computer 140 has proper security clearance. After another transaction by another client computer is terminated, a signal from module 3214 can be sent to the logging system within the shared resources. A new client computer may now gain access to the services provided by proxy computer 140 after the connection from the other transaction is terminated. Attention is now directed to more specific activities that may be performed by a specific module, and how that specific module may interact with other modules for the same transaction using a specific application. The process flow diagram illustrated in FIGs. 6-8 is used to describe some of the specific activities. Again, unless stated to the contrary, the method is primarily described from the perspective of proxy computer 140. To aid in understanding the method in FIGs. 6-8, a specific example is used and occasionally referenced. In the example, an incoming communication may be a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The client computer 120 is communicating using HT P, using a Netscape™ browser (of AOL Time Warner, hie. of New York, New York), and has a MacOS X™ operating system (of Apple Computer, Inc. of Cupertino, California).

Referring to FIG. 6, the method can comprise receiving an incoming communication for a specific application (block 602). The communication can comprise a request, a message, or other form of communication. The communication can be sent by client computer 120 and received or accessed by proxy computer 140 via network 11. Proxy computer 140 can access or read at least a portion ofthe incoming communication and determine the specific application for the communication. In the example, the incoming communication is a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The incoming communication will also contain other information within the header ofthe request. In the example, the other information can include the browser and operating system of client computer 120.

After determining the application for the communication, proxy computer 140 can determine which row 3200, 3400, 3600, or other or row of plug-in modules will be used for the transaction. At this point in the method, proxy computer 140 may activate any or all ofthe plug-in modules for the row corresponding to the specific application. In one embodiment, plug-in modules within each row may be activated only as they are first used. Referring to the example, the request is for an application corresponding to row 3200. Therefore, plug-in module 3202 may be activated. If the communication is for another application, plug-in module 3402 or 3602 may be activated for the particular application.

The method can further comprise routing the incoming communication to a first software plug-in module for the specific application (block 604). Proxy computer 140 can route the request to request reception software plug-in module 3202 because the incoming request uses the application corresponding to row 3200. The method can comprise parsing the incoming communication into a header portion and a content portion (block 622). The parsing can be performed by module 3202 to obtain information from the request.

The method can also comprise generating an associative array using information contained within the header portion (block 624). The associative array can include nearly any finite number of rows. Each row can comprise a key and a value. The key can comprise a parameter within the header portion, and the value can comprise a value for that parameter. In general, the header portion may include one or more lines of a command followed by a command argument. The command may be a key, and the command argument may be the corresponding value for the key. The associative array may be searched by the key or the value. By knowing conventions used by each ofthe protocols for incoming communications and the characteristics of headers used for those protocols, formation ofthe associative array can be performed without complicated coding requirements. The associative array is flexible regarding the number of rows and allows different sizes of associative arrays to be used for different protocols.

For HTTP, one ofthe lines within the header may include a line with "User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:l.l) Gecko." The key will be "User-Agent," and the value will be " Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv: 1.1) Gecko." For POP, a line may include "RETR 27," where 27 is an object identifier for is a particular item to be retrieved. The key will be "COMMAND," and the value will be "RETR." A second entry will be made with a key of "ARGUMENT" and a value of "27." For SNMP, a line may include "get 47.12.112.38," where 47.12.112.38 corresponds to an object identifier. The key will be "COMMAND", and the value will be "GET," and a second entry will have the key "ARGUMENT" and the value "47.12.112.38."

The content may or may not be part ofthe associative array. If it is, the associative array can include a key of "CONTENT" and the entire content data block as the value. For an image, the content may be a very large amount of data. Alternatively, the associative array may be paired with a data pointer that points to the data block, rather than incoφorating it directly into the associative array.

Turning to the example, the associative array may include information as shown in Table 1 below. Descriptive names are used instead of actual names to aid in understanding the associative array. Also, the associative array may include many more rows. Because the associative array may be searched by key or value, the order of the rows is unimportant.

Table 1. Exemplary associative array

The method can also comprise generating a function call to at least one ofthe shared resources using data within the associative array (block 702 in FIG. 7). In the example, proxy computer 140 can make a function call to a shared resource, more specifically to a clock (shared resource) and a logging system (another shared resource) to get the time and log the beginning ofthe transaction. The logging information may include the time and a transaction identifier. Note that some ofthe information within the associative array could be sent with the function call to the shared resource. The method can further comprise receiving data from the function call (block 704). In the example, the transaction identifier may be passed back to module 3202. The method can still further comprise processing data from the function call with other code within the first software module (block 706). Module 3202 may be more focused on processing the incoming message rather than processing data coming back from the function call. Other modules, such as the content deliver plug- in module 3212, may perform such data processing. Note that the application-specific processing may occur before, during, or after function call(s), if any, are made to the shared resource(s).

A determination may be made whether the first software plug-in module is the last software plug-in module (diamond 722). If so, the method may end. Otherwise, the method may continue with passing any or all ofthe data (including the associative array) from a prior software plug-in module to the next software plug-in module (block 802 in FIG. 8). hi the example, the next software plug-in module is authorization module 3204. Authorization module 3204 may use some ofthe information that was collected or generated by module 3202. Passing the information reduces the load on hardware by not sending a communication from proxy computer 140 to another computer (e.g., client computer 120) or making the same or similar function call to a shared resource for the same information.

The method can also comprise generating a function call to at least one ofthe shared resources using data within the associative array (block 822). Authorization module 3204 may make a function call to the parameter system to determine if the user has proper authorization, whether access can be granted (whether number of users currently connected to proxy computer has exceeded its limits), priority of connection (level or speed of service to be provided), etc. Module 3204 may pass user name and password when making the function call to the logging system. Module 3204 may also make a function call to the shared clock to obtain a time for the action.

The method can also comprise receiving data from the function call (block 824). The data may include information regarding whether user at client computer 120 has proper security clearance, whether the connection could be made, priority ofthe connection, and the like. The method can further comprise processing data from the function call with other code within the current software plug-in module (block 826). An example may include sending a communication from proxy computer 140 to client computer 120 informing the user whether the connection was made. Alternatively, no further processing may occur with module 3204.

A determination may be made whether the current software plug-in module is the last software plug-in module (diamond 842). If so, the method may end. Otherwise, the method may continue with block 802 in FIG. 8 and proceed in an iterative manner until the last software plug-in module is reached. The remaining modules along row 3200 will be addressed to complete the example transaction to give a better understanding of actions within the modules and some function calls that those modules may make. More or fewer modules may be used. Also, more, fewer, or different function calls may be made by the modules.

Data can be passed to request manipulation software plug-in module 3206. A function call can be made to a shared resource to determine if the request should be changed. The function call may pass information that a request for www.yahoo.com has been received or accessed. The shared resource may include logic to replace the original client request with www.google.com. The associative array may be changed to replace www.yahoo.com with www.google.com or be appended to note that the manipulated request is www.google.com.

Module 3208 may perform the content retrieval. A function call can be made to a content cache (shared resource) at proxy computer 140 to determine if the content cache includes a network page for www.google.com specifically formatted for a computer having a Netscape™ browser and a MacOS X™ operating system. Note that the browser and operating system information can be obtained from the associative array. If the content cache has the network page, it can be passed to module 3208. Otherwise, module 3208 may formulate an HTTP request to server computer 160 requesting the network page for the specific browser and operating system of client computer 120. After proxy computer 140 obtains the proper network page from server computer 160, module 3208 may send a function call to the content cache at proxy computer 140 to cache the network page. The proper network page and other information previously collected may be sent to module 3210.

Content manipulation module 3210 may delete, add, or replace some or all ofthe content within the proper network page returned. For example, when the proper Google network page is received or accessed, module 3210 may add advertisement(s) around the border(s) ofthe page. A function call can be made to a shared resource to determine which advertisement(s) should be added. The logging system may keep track of which advertisement is being added, whose advertisement it is, and how many times the advertisement has been added during the current billing cycle. The logging system, which is a shared resource, may access the counter (another shared resource) by itself, hi other works, some or all ofthe shared resources may interact with each other without requiring an application-specific software plug-in module to intervene. The manipulated content and other information may be passed to module 3212.

Content delivery software plug-in module 3212 may take the Google network page formatted for a Netscape™ browser and MacOS X™ operating system and the advertisement(s) from module 3210 and prepare a communication using HTTP. The communication can be sent from proxy computer 140 to client computer 120. Function calls can be made to the logging system to note the actual content sent to client computer 120 and time sent. Any or all information collected or generated by modules 3202-3212 may be passed to module 3214. Post-response communications module 3214 may be used to track usage or billing information. At the end of a transaction, module 3214 may make a function call to the clock to determine the current time, and make another function call to the logging system to determine how much time lapsed during the transaction and record any billing information. The billing information may be within a shared resource managed by an accounting department. Billing information for the user at client computer 120 may be passed from one ofthe shared resources to module 3214, which may return some ofthe information for the user at client computer 120. Proxy computer 140 may send a message to client computer 120 similar to "You were connected for 2.1 minutes and were charged $ 1.27. Thank you for using our service." Alternatively, no message may be sent and the method may end.

Note that not all ofthe activities described in the process flow diagram in FIGs. 6-8 are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some ofthe activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs.

The power of creating new applications for the same protocol may be better understood with the flow diagram in FIG. 9 and an example. In one embodiment, different applications may be generated for different priorities of users for a network site. The communication protocol may use HTTP. The method can comprise developing a first set of plug-in modules for a first application (block 902). The set may correspond to row 3200 and be directed to premium users of a network site. A new application may need to be developed for regular users of the network site. The communication protocol may also use HTTP. The method can comprise copying the first set of plug- in modules to form a second set of plug-in modules (block 922).

For the new application, only the request manipulation plug-in module, the content manipulation plug-in module, or both may be replaced. The remainder ofthe plug-in modules may be unchanged and be substantially the same as the remainder ofthe plug-in modules for the first application.

The method may comprise replacing a first request manipulation plug-in module with a second request manipulation plug-in module for a second application (block 924). For example, the premium user may have access to some network pages that the regular user may not. If the regular user requests a premium page, the second request manipulation module may direct the regular user to another network page for which the regular user has proper access.

The method may also comprise replacing a first content manipulation plug-in module with a second content manipulation plug-in module for the second application (block 926). The premium user may have only 10 percent of his or her window occupied by advertisements, whereas the regular user may have 50 percent of his or her window occupied by advertisements. The second content manipulation module may reformat the retrieved content to allow for more advertising space. The second content manipulation module may also access the shared resources to obtain the advertisements and keep track of which advertisements were used. Device dependent optimization of network pages (desktop computer vs. cellular phone, etc.) can be achieved by plugging in a module which transcodes content using settings developed for the particular device that made the initial request. After one or both ofthe request manipulation and content manipulation modules are replaced, the method can still further comprise executing the second application using the second set of plug-in modules (block 942).

Note that while the example focused more on replacing specific modules, in other embodiments, those modules may be generated by editing code within the corresponding modules within the first set for the first application.

After reading this specification, skilled artisans will appreciate that entirely different applications, using the same network protocol, can be developed by simply inserting new plug-in module(s) at the request manipulation location, the content request location, or both locations.

In other embodiments, the method and system may be used for nearly any other network communications. As an example, client computer 120 may make a request for information within a database located at server computer 160. The request may be handled in a manner similar to a request for a network page. If the user does not have proper authorization to all information within a request, the request manipulation module may request only that information for which the user has property access or the content manipulation module may add information stating that the user does not have proper access to some or all the information.

In another embodiment, the multiple-protocol software architecture and plug-in modules may be installed in client computer 120 or server computer 160. Not all modules in proxy computer 140 may be needed by client computer 120 or server computer 160. Authorization modules 3204, 3404, and 3604 may not be used or can be coded to allow authorization (always authorized) at client computer 120. The content manipulation modules 3210, 3410, and 3610 may not be used by the server computer 160. After reading this specification, skilled artisans are capable of determine which modules are needed and which ones can be eliminated or bypassed (module exists but passes information through without performing any other significant activity).

The software components can be designed to maximize their ability use shared resources while minimizing the amount of code used for application-specific operations. Therefore, relatively smaller plug-in modules (compared to the shared resources) may be used to access the shared resources illustrated in the planes below the modules. In this manner, less code needs to be written for a new protocol compared to the prior-art method of writing or copying and modifying an entire program for a specific protocol. For applications in the same protocol, the specific coding requirements may be much less. Furthermore, protocols are more likely to be supported because the coding requirements are less, and therefore, may be generated for protocols that have relatively fewer users compared to other protocols. The method and system are significantly more efficient in both time and cost compared to existing prior-art methods dealing with the problem of many different applications in the same or different protocols.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

APPENDIX π

One or more preferred embodiments are described below. It should be noted that these and any other embodiments described below are exemplary and are intended to be illustrative rather than limiting.

Broadly speaking, these embodiments comprise systems and methods for processing transactions in a server by breaking down the transaction into several stages and performing the processing corresponding to each stage using a different plug-in module that is interfaced with the server application. One embodiment comprises an application programming interface (API) that enables the use of individual plug-in modules to perform different stages ofthe processing of a transaction. The API may be implemented, for example, in a server application that is designed to process network transactions. In one embodiment, transactions are broken down into seven stages: initializing the transaction; sending an opening statement; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction. A set of plug-in modules, each one corresponding to one ofthe stages, is provided to handle the processing for each of the stages. The plug-in modules use the API to pass transaction information from one module to the next and to thereby completely process the transaction. Depending upon the type of communication that is being carried on between two parties, different sets of plug-in modules can be installed to provide the needed processing, whether it be different functionality, or different protocols.

The various embodiments described herein may provide a number of advantages over prior art systems and methods. For example, by creating a system that breaks down network transactions into a series of stages, and by processing each ofthe stages in a modular fashion, the number of protocols supported by the system can be rapidly increased. The modular processing ofthe stages also increases the ability of the system to adjust and modify the communication that takes place within the processing ofthe transactions. The use ofthe API therefore provides greater control and flexibility over the various stages of transaction processing. Still further, by extending the API to include plug- in functionality, new modules can be created by parties other than the producer ofthe server application and plugged into the system without the need to expose source code. It should be noted that, while the description ofthe various embodiments contained in this disclosure focus on communications between a client and a server, other embodiments may concern communications between any two parties. There need not be a client-server relationship between them. Thus, embodiments may be designed to handle processing of a facsimile communications between one facsimile machine and another, voice-over-IP communications between a cellular phone and a computer, or any other type of network communications. One embodiment is implemented in a network environment. Referring to FIGURE 1, a diagram illustrating some ofthe basic components of a network system is shown. As depicted in this figure, the system comprises a client 12 and a server 14, each of which is interconnected to a network 16. Server 14 is configured to provide information responsive to requests from client 12 (i.e., to service the requests).

The communications between client 12 and server 14 comprise network transactions, a typical transaction, client 12 generates a request and transmits the request via network 16 to server 14. Upon receiving the request, server 14 processes the request and generates a response to the request. For example, server 14 may retrieve a web page that was requested by client 12. This response is then transmitted from server 14 to client 12 via network 16.

It should be noted that the network configuration illustrated in FIGURE 1 is intended to be exemplary rather than limiting. Other embodiments may employ alternative configurations. For example, there may be multiple clients and multiple servers that are interconnected by multiple individual networks. Alternatively, a client may be directly coupled to a server without an intervening network. Many such variations are possible.

Communications between client 12 and server 14 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, client 12 may convert signals received from server 14 to a human understandable form and may convert input from a human understandable form to appropriate electronic, optical, radio-frequency, or other signals to be used by server 14. Similarly, when an operator is at server 14, server 14 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human understandable form to appropriate electronic, optical, radio-frequency, or other signals to be used by client 12.

In one embodiment, each of client 12 and server 14 is implemented in a corresponding computer system. These computer systems may comprise general puφose desktop computers, laptop computers, or other types of devices capable of communicating over network 16 and processing the information communicated between them. Referring to FIGURE 2, a diagram illustrating the components of an exemplary computer system is shown. The computer system illustrated in this figure may be used as a platform for either client 12 or server 14.

As shown in FIGURE 2, computer system 20 comprises a central processing unit ("CPU") 22, read-only memory ("ROM") 24, random access memory ("RAM") 26, hard disk drive ("HD") or storage memory 28, and input/output device(s) ("170") 29. I/O 29 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like.

The computer systems that provide platforms for the client and server may each have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For simplicity, the computer illustrated in FIGURE 2 is depicted in as having one of each ofthe listed hardware components. It should be noted that FIGURE 2 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to persons of skill in the art.

"Computer" and "computer system," as used herein, are intended to include any type of data processing system capable of performing the functions described herein. "Computer-readable media," as used herein, refers to any medium that can store program instructions that can be executed by a computer, and includes floppy disks, hard disk drives, CD-ROMs, DVD-ROMs, RAM, ROM, DASD arrays, magnetic tapes, floppy diskettes, optical storage devices and the like.

As explained above, the different protocols that can be supported and functionalities that can be provided by different servers may result from the use of different software applications. The support of different protocols and functionalities is facilitated in the present embodiment by running a modular software application on the server computer. More particularly, the software application uses an API that enables individual plug-in modules to be used to perform different stages ofthe processing of network transactions.

Referring to FIGURE 3, a diagram illustrating the structure of a server application in accordance with one embodiment is shown. As shown in the figure, a network server application 40 runs on top ofthe operating system 30 ofthe server computer. Network server application 40 interfaces with a plurality of plug-in modules 51-57 which perform the processing of transactions handled by the server. Server application 40 interfaces with plug-in modules 51 -57 via an API (not shown in FIGURE 3) that defines the interface with each module. Plug-in modules 51-57 correspond to the seven stages ofthe transaction processing identified above (initializing the transaction; sending an opening statement; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction). These stages will be described in more detail below.

The structure ofthe present application has illustrated in FIGURE 3 stands in stark contrast to the typical structure of prior art applications, which are represented by the structure illustrated in FIGURE 4. As shown in this figure, rather than using plug-in modules to perform the transaction processing, prior art applications employed a single application 100 running on the operating system 30 to provide the necessary processing. If it was necessary to change the processing (e.g., modifying the functionality or supported protocols), the entire application had to be rewritten or replaced. Using the present methodologies, the same changes can be made by replacing one or more ofthe plug-in modules (51-57), which requires substantially fewer resources.

Referring to FIGURE 5, a diagram illustrating the flow of data from one plug-in module to the next in the processing of a network transaction is shown. FIGURE 5 corresponds to the structure of FIGURE 3, but includes only a portion ofthe structure. As depicted in this figure, plug-in modules 58 and 59 interface with server application 40 via API 45. Each of modules 58 and 59 performs the processing for a corresponding portion ofthe total processing for the transaction (i.e., each performs the processing for a corresponding stage). It should be noted that the plug-in modules in this figure are referenced by numbers 58 and 59, rather than any of 51-57 because FIGURE 5 is representative of any pair of consecutive modules in the group 51-57. Thus, for example, modules 58 and 59 may correspond to modules 51 and 52, modules 52 and 53, modules 53 and 54, and so on. Plug-in module 58 receives any transaction information it requires and begins performing its stage of processing for the transaction. If module 58 corresponds to module 51, it receives this information from the client via the network. Otherwise, module 58 receives the necessary transaction information from the preceding plug-in module via API 45. When module 58 completes its stage of the processing, the resulting transaction information is conveyed to plug-in module 59 via API 45. Plug-in module 59 then performs its stage ofthe processing. If there are modules subsequent to module 59, the resulting transaction information is conveyed to the subsequent module via API 45. If module 59 corresponds to module 57 of FIGURE 3, processing ofthe transaction is complete, and the results are conveyed to the client via the network.

The flow of processing described above corresponds to a single transaction processing pathway. A single program may instantiate multiple pathways that use different combinations of modules to perform the necessary processing. A single pathway may perform one or multiple tasks. The processing associated with each pathway will be performed in generally the same manner as described above, using the modules called upon instantiation of that pathway. It should be noted that different pathways may call the same modules and thereby reuse the same program code. Referring to FIGURE 6, a diagram illustrating the replacement of a plug-in module to the transaction processing application is shown. In this example, the application is first configured with plug-in modules 51-54, 55a, 56 and 57. Module 55a corresponds to the generation of a response to a request. In order to modify the manner in which a response to the request is generated, it is only necessary to provide a new plug-in module, 55b, that provides the desired functionality and to replace the original module, 55a, with the new module, 55b.

Referring to FIGURE 7, an alternative module-replacement scenario is illustrated, h this figure, the transaction processing application is initially configured to process HTTP transactions. If it is desired to handle transactions using other protocols, this can be accomplished by replacing the HTTP modules (51c-57c) with modules (51d-57d) supporting the alternative protocol (e.g., FTP). It should be noted that, although the illustration of FIGURE 7 depicts the replacement of all seven plug- in modules, it may be possible to accomplish the same puφose through replacement of fewer modules the same processing is performed in a particular stage, independent ofthe protocol change. It should also be noted that the replacement of modules may be accomplished dynamically (i.e., while the application is executing) by making the modules available and simply instantiating a communication pathway using calls to the modules that are appropriate for the pathway (this will be addressed in more detail below). Portions ofthe methods described herein may be implemented in suitable software code that may reside within ROM 24, RAM 26, hard disk drives 28 or other computer-readable media within the system. The software code may also be contained on a separable data storage device, such as a removable hard disk, or on removable computer-readable media such as a DASD array, magnetic tape, floppy diskette, optical storage device, or the like, h one embodiment, the software code may comprise lines of compiled C , Java, or other language code.

The various software components may reside on a single computer or on any combination of separate computers. Other configurations may also be used. For example, the functions of server 14 may be implemented in multiple computers that interact to perform the functions ofthe server. Additionally, a computer program or its software components within such code may be embodied in more than one computer-readable medium. Similarly, components ofthe software may reside on multiple computers.

Referring to FIGURE 8, a diagram illustrating the processing of a network transaction using the server application of FIGURE 3 is shown. In this figure, the processing ofthe transaction is depicted as block 60. The processing within block 60 is broken down into seven stages represented by blocks 61-67. Block 61 corresponds to the processing that is performed by plug-in module 51 (i.e., initialization ofthe transaction), while block 62 corresponds to the processing of plug-in module 52 (i.e., sending an opening statement), and so on. Upon completion of all ofthe individual stages, processing ofthe transaction is completed. Again, this processing conttasts the prior art, in which the transaction processing was not segregated into stages, but was instead combined into one block (see item 110 of FIGURE 9) so that even minor changes required the application as a whole to be rewritten or replaced.

In the embodiments described above, the processing ofthe network transactions is broken down into the seven stages of: initializing the transaction; sending an opening statement; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction. These stages are used because processing for every network transaction includes these stages, although the sending of an opening statement may be optional. The processing of a network ttansaction will be described below to illustrate the functions of each ofthe stages.

In one embodiment, the processing ofthe network transactions is based upon the notion of a ttansaction processing pathway. A pathway is a type of communication that may be employed to carry on communications between the client and a server. For example, the client and server may set up a pathway for HTTP communications, POP communications, MMS communications, SMS communications, instant messaging, file transfers (via FTP), or the like. There may be several pathways set up between the client and server, each one for a different type of communications. The client and server use a particular pathway for communications of a corresponding type. A series of communications between the client and server using this pathway comprise a session. Each individual communication between the client and server (e.g., a request for a web page and the resulting service of that page) is a transaction. Thus, in a simple example (illustrated in FIGURE 10), a client and server may communicate by: initializing a pathway (71); initializing a session (72); processing a set of transactions (73-76); terminating the session (77); and then terminating the pathway (78).

Just as there may be multiple sessions within a pathway and multiple transactions within a session, there are multiple stages within the processing of each ttansaction. The stages ofthe transaction processing in one embodiment are illustrated in FIGURE 11. As shown in this figure, the overall processing ofthe ttansaction (80) consists of transaction initialization (81), sending an opening statement (82), getting a request from the client (83), logging in and obtaining authorization (84), generating a response (85), sending the response to the client (86) and terminating the transaction (87). As described above, these processing stages are implemented in one embodiment using individual plug-in modules that interface with the server application via an API. The API can be defined as described below. During initialization of the pathway, pathway parameters can be set up. An example is shown below. A preferred way of setting up the parameters is to use the method described in "System And Method For Program Configuration" (U.S. Patent Application No. 10/345,084, filed January 15, 2003), which is incoφorated by reference as if set forth herein in its entirety). Other suitable methods could be used, however. Additionally, as with all stages, log information can be generated.

typedef bool (*Pathway_lhitialization)

( const Parameters &pathway_parameters, Log &pathway_log );

Each new connection is considered a session. When a new connection is established, the step of session initialization occurs. An example is shown below. During this stage, parameters for the session are set up. Session parameters can make use ofthe pathway parameters, for example, to set up default or systemwide values. Session parameters exist only for the duration ofthe current session, and are unique to the current session (i.e. multiple concurrent sessions each have their own session parameters)

typedef bool (*Session_Initialization) ( Parameters &session__parameters, const Parameters &pathway_parameters, Log &session_log, const Log &pathway_log Connection &connection

);

Each session comprises a series of transactions. During initialization of a new transaction, transaction parameters are set up. An example ofthe API definition for this stage is shown below. Like session parameters, transaction parameters exist only for a single ttansaction. typedef bool (*Transaction_Initialization)

(

Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathway_parameters,

Log &ttansaction_log, const Log &session_log, int number_of_transactions

);

Depending on the communication protocol, each transaction can begin with zero, one or a series of messages being sent from the system to the client. An example ofthe API definition for this stage is shown below. This stage may not be required in some types of transactions, typedef bool (*Send_Opening_Message) (

Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathway_parameters, Log &transaction_log, Connection &connection

);

Next, a request is received from the client. An example ofthe API definition for this stage is shown below. Depending on the nature ofthe communication protocol, a request optionally comprises a request header and/or a request buffer. typedef bool (*Get_Request)

(

Header &request_header, Buffer &request_buffer Log &transaction_log, Connection &connection );

In the next stage of processing, authorization ofthe request is performed. An example ofthe API definition for this stage is shown below. Authorization can be based on many different factors, including user ID, client IP address, account information, system usage information, etc. typedef bool (* Authorization)

(

Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathwayjparameters, Request &request,

Log &transaction_log

);

hi the next stage of processing, the request is analyzed and a response is generated. An example ofthe API definition for this stage is shown below. In the case where the system is acting as a proxy, a secondary request may be generated to some other content server and that response can be optionally manipulated and put in place ofthe response header and buffer, typedef bool (*Generate_Response)

( Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathway_parameters, const Header &request_header, const Buffer &request_buffer Header &response_header, Buffer &response_buffer Log &transaction_log

It should be noted that the Generate_Response stage is the point at which the processing performed by a proxy typically differs from that of a server. In the case of a server, the information responsive to the client request is generated locally. In the case ofthe proxy, the proxy attempts to locally generate the information responsive to the request (e.g., by retrieving the information from a cache). If the proxy cannot provide the responsive information itself, the proxy forwards the request on behalf of the client to a server, which returns the responsive information to the proxy. In other words, the proxy either generates the requested information by itself, or it obtains the information from a server.

One or many modules can be used to issue requests to servers on behalf ofthe client (see the http_make_request_to_server module in the multi-task example below). A whole fleet of such modules, e.g.: pop_make_request_to_server, nntp_make_request_to_server, https_make_request_to_server, ftp_make_request_to_server, etc. Cross-protocol applications can be easily created by just plugging in a different make_request_to_server module. For example, HTTP requests can be converted to POP so that the web can be used to access email attachments. Further, many requests to servers could be made in response to receiving a single client request. For example, a proxy could: speed up the download of information by requesting information simultaneously from multiple servers, or could combine information from multiple different requests to the same server. Finally, the response is sent to the client. An example ofthe API definition for this stage is shown below. typedef bool (*Send_Response) (

Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathway_parameters, ResponseHeader &responseHeader, ResponseBuffer &responsebuffer

Log &transaction_log, Connection &connection

); At the end of a transaction, a cleanup function can be called which can generate logs, free allocated resources etc. An example ofthe API definition for this stage is shown below, typedef bool (*Transaction_Teπnination)

( Parameters &transaction_parameters, const Parameters &session_parameters, const Parameters &pathway_parameters, Log &transaction_log, Connection &connection );

At the end of a session, the connection is closed and a cleanup function can be called which can generate logs, free allocated resources, etc. An example is shown below, typedef bool (*Session_Tenrrination) ( const Parameters &session_parameters, const Parameters &pathway_parameters, Log &session_log, Connection &comιection );

When the system is shut down, or a soft restart is required, tlie pathway is terminated. A cleanup function can be called at these times to generate logs, free allocated resources, etc. typedef bool (*Patl way_Tennination) ( const Parameters &pathway_parameters, Log &pathway_log

);

If any of the functions for tl e stages return a false value, tlie transaction and session can be immediately terminated, and the connection closed, tl e case of a false response from tl e Pathway_* functions, tlie pathway can be terminated, and connections will not be made or accepted.

A new pathway can be created by calling an installation function. During the use of this pathway, each ofthe specified functions is called for the corresponding stage of processing (e.g., setting up tlie pathway and its sessions, and processing the transactions). bool Install_New_Pathway( const Pathway_hιitialization pathway_initialization, const Session_Initialization session_initialization, const Transaction_lnitialization ttansaction_initialization, const Send_Opening_Message send_opening_message, const GetJRequest getjrequest, const Authorization authorization, const Generate_Response generate_response, const Send_Response send_response, const Transaction_Termination transaction_termination, const Session_Termination session_termination, const Pathway_Termination pathway_termination

);

Many simpler installation functions can be created on top ofthe general function set forth above by allowing the function caller to only specify functions for some ofthe pathway stages. Default functions are inserted for the non-specified stages. An example of this would be the function below, which allows for the creation of an HTTP module that can generate requests on the fly. bool Install_SimpleHTTPResonse_Pathway( const Generate_Response generate_response,

) { return h stall_New_Pathway( General_HTTP_Pathway_Initialization,

General_HTTP_Session_Initialization, General_HTTP_Transaction_Initialization, General_HTTP_Send_Opening_Message, General_HTTP_Get_Request, General_HTTP_Authorization, generate_response, General_HTTP_Send_Response, General_HTTP_Transaction_Termination, General_HTTP_Session_Termination, General_HTTP_Pathway_Termination

); }

By decomposing the transaction processing system into these modular stages, e.g. using the

API specified here, the creation of new pathways to support different functionality and protocols becomes substantially easier than was the case for the methods ofthe prior art.

It should be noted that the pathways described above perform a single task. That is, they process each ttansaction in the same manner. As noted above, a pathway may alternatively be configured to perform multiple tasks. Thus, rather than dispatching requests to completely different programs, a pathway can be configured to dynamically select different series of modules to process a particular transaction. There can be substantial overlap and reuse of functionality between the different series of modules. An example which might perform one of several tasks in a web proxy is shown below. Send_Opening_Message ==> [do_nothing_module]

Get_Request ==> [get_http_request_module]

Authorization ==> ^rhttp_proxy_authorization]

if (task is caching proxy) { Generate_Response ==> [http_check_cache]

==> [http_make_request_to_server] ==> [http_add_to_cache]

} else if (task is transformation proxy) { Generate_Response ==> [h1tp_make_request_to_server]

==> [optimize_content]

} else if (task is pass-thru proxy) {

Generate_Response => [http_make_request_to_server] } else if (task is web server) {

Generate_Response ==> [get_file__off_disk]

}

Send_Response ==> [http_send_response] Transaction_Termination ==> [do_nothing_module]

In this example, "<stage> ==> [modules]" means that that identified transaction stage (<stage>) is associated with the list of modules ([modules]) following the arrows (==>). It can be seen in this example that most ofthe modules are shared across all tasks (e.g. get_http_request_module is used by all), while other modules (e.g. http_make_request_to_server) used only for certain ones ofthe tasks.

The benefits and advantages which may be provided have been described above with regard to specific embodiments. These benefits and advantages, and any elements or limitations that may cause them to occur or to become more pronounced are not to be construed as critical, required, or essential features of any or all ofthe embodiments. As used herein, the terms "comprises," "comprising," or any other variations thereof, are intended to be inteφreted as non-exclusively including the elements or limitations which follow those terms. Accordingly, a system, method, or other embodiment that comprises a set of elements is not limited to only those elements, and may include other elements not expressly listed or inherent to the claimed embodiment.

Claims

1. A software program product embodied in a computer-readable medium, comprising: an application programming interface (API); wherein the API defines one or more interfaces to corresponding plug-in processing modules; and wherein at least one interface corresponds to a transformation stage of processing of a transaction.

2. The software program product of claim 1, wherein the at least one interface corresponding to the transformation stage comprises a first interface corresponding to an upstream transformation stage and a second interface corresponding to a downstream ttansformation stage.

3. The software program product of claim 1 , wherein the at least one interface corresponding to the transformation stage comprises an interface corresponding to transformation of a client request.

4. The software program product of claim 1 , wherein the at least one interface corresponding to the transformation stage comprises an interface corresponding to transformation of a server response.

5. The software program product of claim 1, wherein the API is embodied in a network proxy application.

6. The software program product of claim 5, wherein at least one interface corresponds to a stage of processing in which a client request is transformed.

7. The software program product of claim 6, wherein at least one interface corresponds to a stage of processing in which a server response is transformed.

8. The software program product of claim 5, wherein at least one interface corresponds to a stage of processing in which a server response is transformed.

9. The software program product of claim 5, wherein the network proxy application is configured to dynamically install a plug-in module corresponding to the transformation stage.

10. The software program product of claim 1 , wherein the one or more interfaces correspond to stages of processing of a transaction.

11. The software program product of claim 10, wherein the stages comprise, in addition to the transformation stage: initializing the ttansaction; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the ttansaction.

12. The software program product of claim 11, wherein the stages of processing further comprise sending an opening statement.

13. The software program product of claim 1 , further comprising one or more plug-in modules corresponding to the one or more interfaces, wherein each ofthe plug-in modules corresponds to a unique stage of processing ofthe ttansaction.

14. The software program product of claim 13, wherein the stages comprise, in addition to the transformation stage: initializing the ttansaction; getting a request; logging in and obtaining authorization; generating a response; sending the response; and terminating the transaction.

15. The software program product of claim 14, wherein the stages of processing further comprise sending an opening statement.

16. A method comprising: defining one or more interfaces to corresponding plug-in processing modules; wherein at least one interface corresponds to a ttansformation stage of processing of a transaction.

17. The method of claim 16, further comprising: providing a plurality of plug-in processing modules corresponding to a plurality of stages of processing, wherein the stages include initializing the transaction, sending an opening statement, getting a request, transforming the request, logging in and obtaining authorization, generating a response, transforming the response, sending the response, and terminating the transaction; and processing a client-server transaction, wherein the processing includes a plurality of processing stages, each of which is performed by a corresponding one ofthe plug-in processing modules.

18. The method of claim 16, further comprising providing at least one plug-in processing module corresponding to the at least one interface, wherein the at least one plug-in processing module performs a transformation.

19. The method of claim 18, further comprising receiving a client request, wherein the transformation comprises transformation ofthe client request.

20. The method of claim 18, further comprising receiving a server response, wherein the transformation comprises transformation ofthe server response.

21. The method of claim 18, wherein providing the at least one plug-in processing module corresponding to the at least one interface comprises dynamically installing the at least one plug-in processing module.

22. The method of claim 21 , wherein dynamically installing the at least one plug-in processing module comprises dynamically de-installing a current plug-in processing module and dynamically installing the at least one plug-in processing module in place ofthe de-installed plug-in processing module.

23. The method of claim 16, wherein the one or more interfaces include a first interface corresponding to an upstream transformation processing plug-in module and a second interface corresponding to a downstream transformation processing plug-in module.

24. The method of claim 23, further comprising: receiving a client request, wherein the upstream transformation comprises transformation ofthe client request; and receiving a server response, wherein the downstream ttansformation comprises transformation ofthe server response.

25. The method of claim 23, further comprising dynamically installing at least one ofthe upstream transformation processing plug-in module and the downstream transformation processing plug-in module.