FIG. 1 is a block diagram of prior art system 100. System 100 includes client 110 and service-oriented architecture 120. Client 110 may comprise a Web browser to access services provided by service-oriented architecture 120 via HyperText Transport Protocol (HTTP) communication.
In one operational example, a user may manipulate a user interface of client 110 to input an instruction (e.g., update inventory). Client 110, in response, may transmit a corresponding HTTP service request to service-oriented architecture 120 as illustrated. Service-oriented architecture 120 conducts any processing required by the request (e.g., updating a list of inventory) and, after completing the processing, provides a response to client 110.
Client 110 does not receive any indication from service-oriented architecture 120 during the above-mentioned processing. Accordingly, after inputting the instruction and before receiving the response, the user is left to wonder whether any processing is occurring as a result of the instruction, whether service-oriented architecture 120 is non-responsive, or whether a network error has occurred between client 110 and service-oriented architecture 120. Service requests which require lengthy processing exacerbate this dilemma.
Due to the request/response nature of HTTP, the foregoing cannot be addressed simply by programming service-oriented architecture 120 to send some sort of progress indicator to client 110. In non-HTTP systems, the server system may be hardcoded to provide progress information on a case-by-case basis, or to provide all generated feedback information to the client. The former approach is inefficient and resource-intensive, while the latter approach overwhelms the client with cryptic information which, even if understood, may provide little indication of the progress of the overall business process being executed.
Accordingly, what is needed is a system to provide meaningful progress information to a client of a service-oriented architecture.
USPTO Backgrounds
USPTO Backgrounds