1. Technical Field
The present disclosure relates to balancing load requests and failovers, more specifically, to balancing load requests and failovers using a UDDI proxy.
2. Description of the Related Art
Web services are quickly transforming the way modern businesses interact and share information. Web services are software systems that can be identified by Universal Resource Identifiers (URI) in a fashion that is analogous to the way websites may be identified by Uniform Resource Locators (URLs). Web services generally contain public interfaces and bindings that enable users and other software systems such as other web services to seamlessly utilize the functionality of the web services. In this way, web services enhance the way computers communicate with users and each other.
To enable the vast variety of computer systems to communicate with each other, cross-platform programming languages have been developed. A popular example of one such computer language is Extensible Markup Language (XML). Many web services communicate using instructions written in XML.
However, before a software system can utilize the functionality of a web service, the software system should first be able to locate and connect to the web service. The process of locating and connecting to a web service is known as discovery and integration. To facilitate discovery and integration, the Universal Description, Discovery and Integration (UDDI) standards have been adopted.
UDDI consists of a standardized vocabulary for detecting and describing the functionality of web services. UDDI also provides for UDDI repositories which are generally directories where information pertaining to a business, its services, technical information, and information about specifications for the business's web services can be looked up.
Web services may be made available to a large number of potential users. These users may access the web services via a local area network or a wide area network. For example, web services may be made available over the Internet. Web services may therefore be made available to potential users world wide. Because web services communicate using cross platform communication languages, web services may be accessible to users and software systems operating on a wide variety of platforms. Additionally, web services may utilize the unicode text format to allow web services to interact with users and software systems located in countries throughout the world regardless of the language spoken in those countries.
Because of the very large number of potential web service users and the complexity of many web services, web services can push even the most capable servers running the web services to their limits. Web service use is often referred to as load. Servers that run web services generally have a load capacity indicating the quantity of load the server can handle. Servers that may be over loaded may not be able to function properly. For example, an over loaded server may stop handling requests for web services. An overloaded server may also cease functioning, thereby denying all web service requests.
One option for handling the problem of excess load is to use more powerful servers to run the web services. More powerful servers may be able to handle more simultaneous requests for web services and/or web services requiring more rigorous computation. This potential solution is limited. For example, the great number of users of a web service may overload even the most powerful servers. Additionally, more powerful servers may be disproportionably more expensive. For example, a server that is marginally more powerful may be substantially more expensive.
Another option is to load balance. Load balancing involves using more than one server to run the same web service. The load may then be spread among multiple servers all working towards processing web service requests. There are many techniques for spreading load among multiple servers. These various techniques employ various distributed scheduling algorithms to allocate requests among the available servers.
Distributed scheduling algorithms may be static, dynamic or preemptive. Static algorithms allocate requests to servers at run time without taking into account the current load at the various servers. One example of a static algorithm is round robin. Here, requests may be allocated to each server in turn. Another example of a static algorithm is random selection. Here, requests may be allocated to a server selected at random with each server having an equal probability of receiving the next request. Static algorithms may also be modified to account for varying capabilities of the available servers. For example, the round robin algorithm may be modified to allocate additional requests to high-capacity servers. For example, the random selection algorithm may be modified to give high-capacity servers a greater probability of receiving the next request.
Dynamic algorithms may take into account the current load volume in each server before allocating a request. Dynamic algorithms may allocate requests to the most capable server available at the time the request is received. For example, a request might be sent to the server with the smallest load. Load level may be determined, for example, by using the Web Services Distributed Management (WSDM) protocol. Such algorithms have the advantage of potentially making more efficient use of available resources thereby potentially reducing the amount of servers required and/or increasing the speed at which requests may be processed.
Preemptive algorithms may be able to migrate a request that is currently being processed from one server to another where it may be deemed beneficial. Such algorithms have the potential to make even more efficient use of computational resources.
As mentioned above, excess load may be able to render a web service server inoperable. Therefore, another option for handling the problem of excess load is to use a failover. A failover may be a redundant or standby server that can automatically take over for the primary server in the event the primary server fails. Failover servers may be referred to as “hot standby” or “warm standby” servers. The use of a failover allows for the web service to continue handling requests even in the event of a server malfunction, for example, the failover server (secondary server) may take over for the primary server when excess load causes the primary server to fail. However, the usefulness of the failover server is not limited to handling problems associated with excess load. Failovers may be used to ensure the continued offering of web services in any number of circumstances that may render the primary server non-functional.