WEB DISPATCH SERVICE
A system and method for accessing an application server includes sending a service command from a requestor to a dispatch server, processing the service command on the dispatch server, translating the service command on the dispatch server into an application request to the application server, wherein the translating is based on a service definition stored on the dispatch server, and processing the application request. In one embodiment, the dispatch server includes a dispatch processor that is further programmed to manage a user interface, wherein the user interface includes a service registration interface, a service modification interface, and a service deletion interface.
Latest Patents:
- METHODS AND COMPOSITIONS FOR RNA-GUIDED TREATMENT OF HIV INFECTION
- IRRIGATION TUBING WITH REGULATED FLUID EMISSION
- RESISTIVE MEMORY ELEMENTS ACCESSED BY BIPOLAR JUNCTION TRANSISTORS
- SIDELINK COMMUNICATION METHOD AND APPARATUS, AND DEVICE AND STORAGE MEDIUM
- SEMICONDUCTOR STRUCTURE HAVING MEMORY DEVICE AND METHOD OF FORMING THE SAME
This application is a Divisional of application Ser. No. 10/140,347, filed on May 56, 2002, which is incorporated herein by reference.
FIELD OF THE INVENTIONThe present invention is related to software application management, and more particularly to the translation of simple service requests into complex web links.
BACKGROUND OF THE INVENTIONComputer science has forever grappled with solving the following, contrary statements: systems become more brittle as intelligence is distributed, but systems also become less scalable as intelligence is centralized. How can we enjoy the benefits of distributed scalability with the superior availability and reliability of centralization? There has been a steady evolution of tools and methods to answer this question. The advent of libraries and routines that could be included (linked) in multiple applications migrated to shared libraries that mitigated the need to rebuild every application when a referenced routine was changed. Later, the concept of objects promoted reuse and portability by only exposing necessary methods and properties to the using application. Today, we routinely use object brokers that provide objects as services to applications, further insulating developers from the intricacies of a desired capability while still providing the functionality required.
Another current example is the use of stored procedures to access database information rather than using specific structured query language (SQL) commands in a given application. This moves a large portion of database intelligence out of the application and into the database server, which effectively centralizes more of the intelligence while distributing the capability. A change can be made to the centralized stored procedure to fix a bug or add functionality to all applications that use the procedure without requiring a change to each application itself.
Today, however, we have no similar mechanism for minimizing intelligence required by one web application that needs to access the services of another web application. For example, to display employee information in a web application, one could use an employee lookup program. However, to use that application, one must know things such as the server the application is currently running on, the path to and name of the application, and what information the program needs to provide the desired service. All of this information may be encoded in a Universal Resource Locator (URL) or link. This is not necessarily a lot of information to maintain, but if any of that information changes, the link will break. As the number of copies of this link grow, and if the link itself becomes more complex, then the maintenance could become more significant.
Clearly, the information required by a web application can be even more involved in certain circumstances. For example, enabling applications with Top Tier's Drag and Relate (DnR) capability, while powerful, can require significantly more intelligence in the enabled application. Additionally, most DnR Enabled Applications (DEAs) need to know when they are DnR enabled, since displaying DnR links outside of DnR aware environments could be confusing to the user, and simply won't work if activated. Further, DEAs must encode information into the DnR links so the DnR servers understand what to do with the DnR link. Again, if any of that information changes, then the application will break. This approach becomes untenable in a large enterprise with many applications cross-linking each other.
For the reasons stated above, and for other reasons stated below which will become apparent to those skilled in the art upon reading and understanding the present specification, there is a need for the present invention.
BRIEF SUMMARY OF THE DRAWINGSIn the following drawings, where the same number reflects similar function in each of the drawings,
In the following detailed description of the preferred embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific preferred embodiments in which the inventions may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical and electrical changes may be made without departing from the spirit and scope of the present invention. In certain embodiments, reference is made to certain outside technologies to exemplify the utility of these embodiments of the invention. These technologies are not associated with, or required by, these embodiments of the invention for operation, but are described only to demonstrate the flexibility and utility of these embodiments of the invention in various operating environments. The following detailed description is not to be taken in a limiting sense, and the scope of the present invention is defined by the claims.
INTRODUCTIONIt is interesting to consider web pages and applications in terms of objects and transactions. One can consider a single, static web page as a simple object with a single method called “display my contents.” The method is invoked via the web link for that page. Web pages generated by an application are just slightly more complex objects that now include zero or more properties. These properties are sent to the application in the link itself or through other data that a browser can send to the link's destination. Thus, the method of an application is just a bit more complex and may be called something like “display my contents based on my properties.”
By the nature of the environment, web applications are transaction-based. A web application is nothing more than a collection of web pages presented to a browser with a common look, feel, and purpose. The web environment itself neither cares nor knows about any application, and is, in fact, stateless. The web is only concerned with requests and responses. Using an employee lookup program (i.e. white pages) example, an entry page might present a list of many things that can be done, such as looking up an employee by last name (or by user-name or employee number), or searching the phone book for phone numbers, parts of names, etc. In fact, each of these capabilities is a transaction that may be executed independent of the others as long as the correct information is passed to the right server.
This object and transaction orientation makes the web very flexible and powerful. This same capability, however, can also cause reliability, availability, and scalability (RAS) issues in an enterprise if not carefully managed. RAS issues have been around in the software development field for many years, and new technologies have evolved over time to address them. Such technologies are less mature in the web environment. Certain embodiments of the present invention described below apply some of the lessons learned in traditional software development to a web environment of linked objects and transactions.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the embodiments shown in
This embodiment provides several advantages. First, system 200 is more reliable, because the transaction time between client 220 and dispatch server 100 is quite small. Dispatch server does not need to maintain state information about its transaction with client 220, and therefore the transaction rate can be quite high. Second, system 200 provides a clearer security model, because client 220 directly invokes application request 280 to application server 210 (i.e. dispatch server 100 redirects application request 240 back to client 220, rather than sending it to application server 210). This provides a clearer security model and eases cookie management.
To further exemplify the advantages of this embodiment, we can use two analogies. The first analogy is that of a taxi service. Aside from not having to drive, a key benefit is that we don't need to know where a destination is, or how to get there. We can just hop in and ask to be taken to a certain location, and a while later, we arrive there. For less common destinations, we may have to provide a specific address to the taxi driver, but we still don't have to know how to get there. And, for generic locations, we may not even need to know the name of the location. For example, we might just say to the taxi driver, “Take me to the closest book store.” This is an example of how we minimize the information we need to do something (i.e. get to a destination) by relying on another source (i.e. the taxi driver) for that information.
The second analogy is that of a vacation in Mexico. Let's say you decide to vacation in Mexico and don't speak Spanish, but your traveling companion does. While in a restaurant, you need to use a restroom (which you are quite certain that the restaurant has). You ask your traveling companion for help. She tells you how to ask for the restroom in Spanish, and further informs you that you can ask a clerk in the restaurant, such that the clerk will understand your request, and also be able to give you a correct response (as to how to find the restroom). There are at least two important points in this analogy: (1) your traveling companion did not ask for you, but told you how to ask, and (2) your traveling companion also told you where to ask. By correctly formatting (and redirecting) an application request in this embodiment, the dispatch server is basically telling you how and where to ask. By returning the application request in a redirect message, the dispatch server is letting the client make the request, not actually calling the target application server directly.
In some embodiments, application requests 240 and 280 are complex addresses. In other embodiments, service request 230 includes a URL. In other embodiments, the processing of service request 230 on dispatch server 100 includes validating service request 230, and checking service request 230 for parameters.
In the embodiment shown in
In another embodiment, service user 283 implements use 295 for use case 287 to discover available services on the dispatch provider. User interface 291 aids in the discovery process, and database 290 is used to query information about available services on the dispatch provider.
In another embodiment, service provider 282 implements use 293 for use case 285 to modify an existing service on the dispatch provider. User interface 291 aids in the modification process, and database 290 is updated for the modified service.
In another embodiment, service provider 282 implements use 294 for use case 286 to delete an existing service on the dispatch provider. User interface 291 aids in the deletion process, and database 290 is updated to delete the indicated service.
At checkpoint 660 of
At checkpoint 550 of
In this embodiment, service registration and request redirection functionalities allow the dispatch server to translate service command 810 into application command 820. Before service command 810 arrives at the dispatch server, the employee lookup application owner must register the “employee lookup by_workno” service with the dispatch server, including a required parameter “emp” that designates a single employee number. Additionally, during registration, dispatch server must store data for the given service indicating that the program “emp/default.asp” on server “iisprod” must be invoked with a single parameter “emp.” Parameters may be passed to an application using a GET method, and also may be passed using a POST method. The GET method passes parameters to an application directly in the address (e.g. URL). The POST method passes parameters in other data that is sent to the application. In the present embodiment, the parameter “emp” is passed using the GET method. In some embodiments, the dispatch server also stores data for the given service that associates a description and owner with the service, and this information is provided to clients during service discovery.
After service registration, a client sends service command 810 to the dispatch server. After service command 810 is translated into application command 820 by the dispatch server, application command 820 is redirected back to the client. By sending the client back the application command in a redirect message, the dispatch server lets the client make the request to the application server directly. This approach has certain benefits. After the dispatch server has translated the request, it is basically done. This involves a simple database query and some possible data formatting, all of which can be done quite quickly. The dispatch server then sends a small amount of data back to the client. It does not have to wait for the target application to respond, nor does it route the results from the target application back to the client. This means that the dispatch server does not need to maintain any state information, and that the dispatch server will be able to handle many service commands per second. Further, the application command redirection approach minimizes the network path (and traffic) for the results to get from the target application back to the client. It also is important for usage logging, access tracking, and security management.
In another embodiment, the dispatch server directly sends application command 820 to the application server, and routes an application response back to the client. In this embodiment, the dispatch server would need to maintain some state information.
In yet another embodiment, the service registration process is at least partially automated. In this embodiment, a dispatch interface is designed so that an application can register itself for all of its available services. In one specific embodiment, the Extensible Markup Language (XML) provides a simple, hierarchical messaging protocol whereby the required service components are described, filed, and updated by existing applications.
In yet another embodiment, the dispatch server provides currently available service information to clients who send service inquiry requests to the dispatch server. In this way, clients find out about (i.e. discover) services offered by the dispatch server. In one specific embodiment, a client can inquire about a reserved service, such as a service named “info,” from the dispatch server. After receiving this inquiry, the dispatch server would return information about itself to the client. Further, if the “info” service is called with a “services” parameter (which is a reserved parameter name for the reserved service “info”), then the dispatch server will directly respond to the client with a list of published services, their names, required parameters, a description, and human contact information. In another embodiment, the service inquiry (i.e. discovery) process is also at least partially automated. In this embodiment, an XML-enabled interface is provided, such that clients inquire which services are available, and how to access them.
Additional decoupling is available between calling and target applications if the dispatch server provides parameter formatting. This not only removes the burden of parameter formatting from the calling application, but also eliminates the need to possibly support multiple formatting of the same parameter for different target applications.
To send content request 860 to a DnR server, the DnR server requires the employee number to be an 8 digit integer with zero left padding. (In this scenario, DnR server is a content server.) In this instance, the formatting is performed by the dispatch server, and the formatting code is eliminated from the employee lookup program (i.e. client).
It should be noted that the example shown in
Another key feature of another embodiment of a dispatch server is accepting a service request from a client that has only a subset of a target application's required parameters. This is to say that the dispatch server can provide default parameters if they are omitted. Continuing with the example embodiment above in
In another embodiment of the present invention, the dispatch server provides source routing. In this embodiment, service requests are translated into application requests just as before. However, during the translation process, the dispatch server determines the geographic location of the requesting client and one or more application servers that provide the requested service. That is to say, there can be many application servers in different geographic locations that provide the requested service. Source routing occurs when the dispatch server determines the closest application server to the requesting client when translating a service request and redirecting an application request back to the client. For example, in a specific embodiment, application servers in the United States, Italy, and Japan all provide a common service of “employee_stock_quoting.” A client in Italy sends a service request for “employee_stock_quoting” to the dispatch server. The dispatch server will achieve source routing by assessing the client's location (Italy), and determining that the nearest application server that provides the requested service is the one in Italy. The dispatch server will redirect an application request back to the client, wherein the application request includes the address of the application server in Italy.
In another embodiment, the dispatch server uses a load-balancing strategy when choosing the appropriate application server and thereby creating an application request. In this way, routing of requests is achieved to maximize the load-balancing strategy used by the dispatch server. This occurs when multiple application servers in a given geographic location provide the requested service. The dispatch server implements a load-balancing strategy to determine which application server will handle the application request. In one embodiment, the load-balancing strategy includes a round-robin strategy.
CONCLUSIONAlthough specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiment shown. This application is intended to cover any adaptations or variations of the present invention. Therefore, it is intended that this invention be limited by the claims and the equivalents thereof.
Claims
1. A method for registering services on a web dispatch server, the method comprising:
- sending a registration request from a host to the web dispatch server, the registration request having a first service name;
- processing the registration request on the web dispatch server;
- registering a new service for the registration request on the web dispatch server, the new service having a second service name; and
- storing the new service in a web dispatch database,
- such that a user can access the new service of the host by sending a service request to the web dispatch server.
2. The method of claim 1, wherein the first service name is substantially equal to the second service name.
3. The method of claim 1, wherein the registration request further includes one or more service parameters.
4. The method of claim 3, wherein the new service further includes one or more service parameters.
5. The method of claim 3, wherein the one or more service parameters of the registration request include a Universal Resource Locator.
6. The method of claim 4, wherein the one or more service parameters of the new service include a Universal Resource Locator.
7. The method of claim 1, further comprising:
- displaying a web dispatch service user interface screen.
8. A method for centralized management of complex web links on a web dispatch provider, the method comprising:
- storing an application service definition in a centralized database of the web dispatch provider, wherein the application service definition includes a service name and one or more service data entries;
- receiving a first service request from an end-user;
- translating the first service request into a first application request, wherein translating the first service request is at least partially based on the application service definition;
- redirecting the first application request back to the end-user;
- changing at least one of the one or more service data entries in the application service definition without changing the service name;
- receiving a second service request from the end-user, wherein the second service request is substantially equal to the first service request;
- translating the second service request into a second application request, wherein the second application request is substantially different from the first application request, and wherein translating the second service request is at least partially based on the changed application service definition; and
- redirecting the second application request back to the end-user.
9. The method of claim 8, wherein the one or more service data entries of the application service definition include parameters for enablement and disablement.
10. The method of claim 8, wherein the method is performed in an order as recited in claim 8.
11. A system for registering services, the system comprising:
- a web dispatch server comprising: a data store; and a processor programmed to process a registration request received from a host, the registration request having a first service name, registering a new service for the registration request, the new service having a second service name, and storing the new service in the data store, such that a user can access the new service of the host by sending a service request; and
- the host operatively coupled to the web dispatch server, wherein the host is operable to send the registration request to the web dispatch server.
12. The method of claim 11, wherein the first service name is substantially equal to the second service name.
13. The method of claim 11, wherein the registration request further includes one or more service parameters.
14. The method of claim 11, wherein the registration request and the new service each further include one or more service parameters.
15. The method of claim 13, wherein the one or more service parameters of the registration request include a Universal Resource Locator.
16. The method of claim 13, wherein the one or more service parameters of the new service include a Universal Resource Locator.
17. The method of claim 11, wherein the processor is further programmed to initiate display of a web dispatch service user interface screen.
18. The method of claim 11, wherein the host is an application server.
19. The method of claim 11, wherein the host is a client computer.
20. A system for generating form data, the system comprising:
- a web dispatch system comprising: a data store; and a processor programmed to direct a service request from a browser to a dispatch server, transform the service request into an application command, the application command including form data, and redirecting the application command back to the browser; and
- a browser executed on a client computer and operatively coupled to the web dispatch system to send a service request to the web dispatch system.
21. The system of claim 20, wherein the service request does not include any form data.
22. The system of claim 20, wherein the browser is configured to send the service request using a POST method.
23. The system of claim 20, wherein the browser stores the service request as a browser bookmark.
Type: Application
Filed: Jul 18, 2006
Publication Date: Nov 9, 2006
Applicant:
Inventors: Don Acree (Boise, ID), Rian Chipman (Boise, ID), Brooklin Gore (Boise, ID), Craig Kickel (Boise, ID)
Application Number: 11/458,184
International Classification: G06F 15/177 (20060101);