Leveraging synchronous communication protocols to enable asynchronous application and line-of-business behaviors

Methods and systems of leveraging synchronous communication protocols to enable asynchronous application and line of business behaviors. An application platform may be provided and configured to provide a pending state for any synchronous operation. The pending state may indicate that the operation has not been completed yet. For an application which may know how to track an operation that has a pending state, the application may control when the operation enters and exits the pending state. The application may communicate to the application platform to hold off on other operations dependent upon the pending operation when the pending operation is not complete. For an application which does not know how to track an operation that has a pending state, the application platform may ignore the pending state of the operation and proceed to other operations. Accordingly, the synchronous user experience is preserved where a straightforward, down-level user interface and experience is appropriate. The user interface and experience is also extended when an application knows how to interpret and present the asynchronous nature of various underlying systems.

BACKGROUND

When an operation is performed in software applications, the operation may typically either succeed or fail immediately. This behavior may be called a synchronous application behavior. However, there are many cases of asynchronous application behaviors in software applications as well. In such cases, the application may not complete synchronously as soon as a user takes a particular operation. For example, when working with collaborative or line of business (“LOB”) systems, a software application tends to be structured in a more complex manner. The application may trigger a workflow that is routed to multiple users via a collaboration server. The application may also trigger a workflow over a LOB system. In addition, many operations on a LOB system inherently take a “long” time because many interconnected systems need to work in serial to get the entire LOB system to behave appropriately.

There may be LOB and collaborative systems/applications that understand the inherent asynchronous nature of the information and processes they are dealing with, and build the asynchronous behaviors into their user experience. However, those systems/applications are perceived as complex and difficult to use. Therefore, there is a need to enable asynchronous data-exchange and business-processes by building on top of and extending existing underlying communication protocols that are inherently synchronous.

SUMMARY

Embodiments of the present invention solve the above and other problems by leveraging synchronous communication protocols to enable asynchronous application and line of business behaviors. According to one embodiment, an application platform may be provided and configured to provide a pending state for any synchronous operation. The pending state indicates that the operation has not been completed yet. For an application which knows how to track an operation that has a pending state, the application may control when the operation enters and exits the pending state. The application may communicate to the application platform to hold off on those operations dependent upon the pending operation because the pending operation is not complete. For an application which does not know how to track an operation that has a pending state, the application platform may ignore the pending state of the operation and proceed to other operations. Accordingly, the synchronous user experience is preserved where a straightforward, down-level user interface and experience is appropriate. Further, the user interface and experience is extended when an application knows how to interpret and present the asynchronous nature of various underlying systems.

According to one embodiment, a data provider interface may be provided for an application to update locally cached authoritative data when the application knows events that may affect the authoritative data and when the authoritative data from a LOB system is available.

According to another embodiment, an application may be configured to introduce exceptions corresponding to out-of-band changes. The out-of-band changes are changes or events that are outside the control of an application or an application platform. The out-of-band exceptions may have custom exception handling logic to process the out-of-band changes. Exception-handler codes may be provided for the exceptions such that an exception handler can be invoked even when the entire application itself is not currently running.

These and other features and advantages, which characterize the present invention, will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of the invention as claimed.

DETAILED DESCRIPTION

As briefly described above, embodiments of the present invention are directed to leveraging synchronous communication protocols to enable asynchronous application and line of business behaviors. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. These embodiments may be combined, other embodiments may be utilized, and structural changes may be made without departing from the spirit or scope of the present invention. The following detailed description is therefore not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents.

Referring now to the drawings, in which like numerals refer to like elements through the several figures, aspects of the present invention and an exemplary computing operating environment will be described.FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which embodiments of the invention may be implemented. While the invention will be described in the general context of program modules that execute in conjunction with program modules that run on an operating system on a personal computer, those skilled in the art will recognize that the invention may also be implemented in combination with other types of computer systems and program modules.

Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In addition, the invention may be practiced in an Internet web-based environment where components of the invention, including rich client user interface components, described and illustrated herein, may be hosted in a website remote from users of the components of any given embodiment of the invention.

Referring now toFIG. 1, an illustrative operating environment for embodiments of the invention will be described. As shown inFIG. 1, computer100comprises a general purpose desktop, laptop, handheld, mobile or other type of computer (computing device) capable of executing one or more application programs. The computer100includes at least one central processing unit108(“CPU”), a system memory112, including a random access memory118(“RAM”) and a read-only memory (“ROM”)120, and a system bus110that couples the memory to the CPU108. A basic input/output system containing the basic routines that help to transfer information between elements within the computer, such as during startup, is stored in the ROM120. The computer102further includes a mass storage device114for storing an operating system132, application programs, and other program modules.

The mass storage device114is connected to the CPU108through a mass storage controller (not shown) connected to the bus110. The mass storage device114and its associated computer-readable media provide non-volatile storage for the computer100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by the computer100.

According to various embodiments of the invention, the computer100may operate in a networked environment using logical connections to remote computers through a network104, such as a local network, the Internet, etc. for example. The computer100may connect to the network104through a network interface unit116connected to the bus110. It should be appreciated that the network interface unit116may also be utilized to connect to other types of networks and remote computing systems. The computer100may also include an input/output controller122for receiving and processing input from a number of other devices, including a keyboard, mouse, etc. (not shown). Similarly, an input/output controller122may provide output to a display screen, a printer, or other type of output device.

As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device114and RAM118of the computer100, including an operating system132suitable for controlling the operation of a networked personal computer, such as the WINDOWS® operating systems from Microsoft Corporation of Redmond, Wash. The mass storage device114and RAM118may also store one or more program modules. In particular, the mass storage device114and the RAM118may store application programs, such as a software application124, for example, a word processing application, a spreadsheet application, a slide presentation application, a database application, etc.

The mass storage device114and the RAM118may store an application platform210. The mass storage device114and the RAM118may also store applications220. According to embodiments of the present invention, an example of a suitable application220is DUET developed by MICROSOFT CORPORATION and SAP.

FIG. 2is a simplified illustration of leveraging synchronous communication protocols to enable asynchronous application and LOB behaviors. An example system200is used to illustrate the use-case of this invention. There are many other use-cases for asynchronous application and LOB behaviors which may be applied to the present invention. As should be appreciated, description of the present invention in terms of a specific example is for purposes of illustration only and is not limiting of the vast numbers of applications and systems for which embodiments of the present invention may be utilized.

In the example system200, an application platform210may be arranged and configured to provide productivity services and tools for software developers to build and deploy applications220to surface and access information and processes of LOB systems230.

Applications220may be built upon the application platform210. The applications220may be software applications that provide one or more useful software application modules, or the applications220may be a software application suite that provides one or more useful software application modules (or, individual software applications). An example of a suitable application220is OFFICE manufactured by MICROSOFT CORPORATION that provides multiple software application modules/applications such as WORD (document objects), EXCEL (spreadsheet objects), POWERPOINT (slide presentation objects), and ACCESS (database objects). Another example of a suitable application220is OUTLOOK manufactured by MICROSOFT CORPORATION that provides multiple software application modules/applications for creating and editing various objects, for example, emails tasks, contacts and appointments. A suitable application220may be a single application that provides one or more useful application modules. For example, the application220may be a word processing application, such as MICROSOFT WORD, that provides one or more modules for preparing and editing different types of objects (e.g., resume document module, letter document module, memorandum document module, and the like).

Applications220may be developed to combine the productivity tools in the application platform210with information and processes defined in the LOB systems232so that a user may surface and access the information and processes in familiar user interfaces and environments of the application platform210. For example, an application220may be developed for combining the productivity tools of a spreadsheet application, such as MICROSOFT EXCEL, with an associated LOB230(e.g., a quarterly sales management module) for accessing and surfacing in the spreadsheet application and its associated user interface information from the LOB230. An example of a suitable application220may be DUET developed by MICROSOFT CORPORATION and SAP.

The applications220may initiate operations to be run in the LOB systems230. Many operations on a LOB system230, e.g., changing the discount percent on a product line item/SKU, or changing the address of an employee, etc., inherently take a “long” time because many interconnected systems need to work in serial to get the entire LOB system230to behave appropriately. In addition, batch processing is a well-known technique used in a LOB system230. The requests from various sources are processed in batches, and responses are sent out in batches as well. The responses may therefore take a long time to come back, and are not immediate. A LOB system230may also expose actions that trigger analytical computation and creates summaries of results that are presented to a user. Analytical computations and report generation are inherently computationally expensive, and are usually scheduled to run at specific intervals only. The analytical computations and report generation therefore take a long time to come back to the application220.

When working with collaborative or LOB systems, the application itself220may be structured in a more complex manner. The application220may trigger or participate in a workflow that is routed to multiple users via a collaboration server. The application220may also trigger a workflow over a LOB system230. In all such cases, the application220which natively understands the entire work may not complete synchronously as soon as a user takes a particular action on a particular client.

An application220may sometimes change the version of the objects it is dealing with. A version change is a big step since it may require a data/metadata update or migration, which is expensive. During this process, changes to that object may have to be blocked or kept as pending.

Some applications220may need to get an integrated view of the whole system after making many related changes. For example, one application may submit many purchase orders, another application may update discount percentages of multiple line-items/SKUs, and yet another application may change the overall organization budget, etc. In such cases, it may make sense for an application to get a snapshot of the state of the system after all the above pending changes are reconciled, and disallow any further changes until the whole system reaches a steady state.

The application platform210may generate a pending state for any synchronous operation in the application platform210. The pending state may indicate that the operation has not been completed yet. The application220may control when the operation enters the pending state. The application220may communicate to the application platform210when it wants entering the pending state to happen. The application platform210may not necessarily figure it out on its own. The application220may also control when the operation exits the pending state and becomes either successful or failed. Finally, the application220may specify a pre-determined time-out period of how long a synchronous operation can remain in a pending state. After the pre-determined time-out period expires, the application platform210may automatically fail the pending operation. This is essentially for error handling and cleanup so that the application platform210may not be flooded with large numbers of incomplete pending operations.

Advantageously, the system200may enable asynchronous data-exchange and business-processes by building on top of and extending existing underlying communication protocols that are inherently synchronous. Specifically, according to one embodiment, for an application220that knows how to track an operation that has a pending state, the application220may communicate to the application platform210to hold off on operations which are dependent upon the pending operation. The application220may allow the application platform210to block a certain operation that depends on the pending operation, and to make progress with other operations that do not depend on the pending operation. For an application220that does not know how to track an operation that has a pending state, the application platform210may then ignore the pending state of the operation and proceed to other operations. Accordingly, the synchronous user experience is preserved where a straightforward, down-level user interface and experience is appropriate. Further, the user interface and experience is extended when applications know how to interpret and present the asynchronous nature of various underlying systems.

FIGS. 3-4are simplified illustrations of leveraging synchronous communication protocols to enable asynchronous application and LOB behaviors where the application220and the application platform210may run on a client machine240. According to one embodiment, the applications220and the application platform210may run on a client machine220. The LOB system230may run on a server machine240. Alternatively, the application platform210may run on both the client machine240and the server machine250.

Referring toFIG. 3, the application220may initiate operations to the LOB system230. The application operations may be queued up in the operation queue on the client machine240when the client machine240is off-line, and may be synchronized or replayed to the LOB system230when the client machine240comes back on-line. According to one embodiment, in step1illustrated inFIG. 3, a sync component214in the application platform210may retrieve the operation information from the operation queue212.

Then in step2, the sync component214may request an execution of an operation in the operation queue212against the LOB system230. The LOB system230may return only a technical acknowledgement back. At this point, the operation may have not been completed yet.

In step3, the sync component214may update the status of the operation in the operation queue212to a pending state. The pending state may indicate that the operation has not been completed yet. The application220may know that the request for the operation has been submitted and the operation has not been completed yet.

In step4, the application220may learn from the LOB system230when the operation has been completed, and then the application220may retrieve the appropriate data from the LOB system230.

In step5, the application220may then update the operation queue212according to the response from the LOB system230. The updating may include updating operation status and authoritative data. For an application that tracks and understands a pending state, the application may correlate the result in step5to the request in step1. For an application220that does not track or understand the pending state, the application may only communicate to the application platform the request submitted in step3and may only show the response in step5as an unrelated, uncorrelated event.

Referring toFIG. 4, in step6, the sync component214may retrieve information from the operation queue212about an operation in the pending status that has been in that status for longer than a pre-determined time-out period. In step7, the sync component214may update the status of the operation in the operation queue, to a “failed” status after the operation has been in the pending status for longer than the pre-determined time-out period.

FIG. 5is a simplified illustration of allowing an application220to control authoritative data exchange between an application platform210and a LOB system230. The application220may communicate to the application platform210and update locally cached authoritative data216when authoritative data from the LOB system230is available. The authoritative data may be the data in the LOB system230that the application220and the application platform210work with. Instead of periodic refresh of authoritative objects and their content, the application220may communicate to the application platform210when the authoritative data is available.

According to one embodiment, the application platform210may include a data provider interface502for the locally cached authoritative data216. The data provider interface502may be arranged and configured to access and update the locally cached authoritative data216. The application platform210may assume that the data provided through the data provider interface502is authoritative LOB data.

The application220may update the locally cached authoritative data216asynchronously through the data provider interface502. The application220may update the locally cached authoritative data216asynchronously based on events that may occur outside the application platform210at the application level. The application220may provide the LOB data immediately as soon as the related authoritative data is available in the LOB system230. The application platform210may not have to go through the periodic cache refresh to fill up the authoritative data. When the application220knows events that can affect the authoritative data, the application220may communicate to the application platform210and update the authoritative data directly through the data provider interface502. The authoritative data itself may be obtained through the LOB system203directly via events or other means. According to another embodiment, the locally cached authoritative data216may be updated synchronously using the periodic cache refresh as well.

FIG. 6is a simplified illustration of introducing out-of-band exceptions into a normal request-reply processing channel in the application220. Referring toFIGS. 2 and 6, the application220may introduce exceptions corresponding to out-of-band changes. The out-of-band changes are changes or events that are outside the control of the application220or the application platform210. The out-of-band exceptions may have custom exception handling logic to process these changes.

According to one embodiment, the application220may create an exception without executing an operation, and introduce it into the application platform210as if it were an exception that was the result of a real operation invocation. The introducing of exceptions therefore may provide the application220and the application platform210ability to process out-of-band changes as if they were results of operations that were invoked on the client.

The application220may provide an exception-handler for the exceptions such that the handler can be invoked even when the entire application itself is not currently running. This gives the application220and the application platform210ability to have custom handling logic created by applications that know what to do for specific LOB exceptions. Moreover, since the custom handling logic may run even without the rest of the business logic of the application running, it is possible for a down-level application to understand why the application platform210takes certain actions, as opposed to just seeing the end results and not knowing what causes that to happen.

Referring toFIG. 6, the operation queue212may have various operations to be submitted. The operation Op1602is an operation that has already been submitted successfully. The operation Op2604is an operation that is being submitted now. The out-of-band exception OOB606is an exception that introduces an out-of-band change. The operation Op3608is an operation that is not yet submitted. According to one embodiment, there may be three possible ways of adding the OOB exception606to the application220and then the operation queue212. The first way is as a result of the recoverable failure state5. The second one is as a result of post successful operation completion actions state7where the request processing channel routinely checks for exception conditions outside of the current operation being executed. The third way is as a result of a truly asynchronous event that communicates to the application220about the exceptional condition, for example, via some business alert or other kinds of instant communication, in state8.

Once the OOB exception606is introduced, it may first be picked for execution normally in state1. Next, the OOB exception606may immediately move to the recoverable error state5directly. The out-of-band exception OOB606will not have to be actually sent to the LOB system230. Other than this, the application220and the application platform210proceed as usual, including adding additional OOB exceptions. After all OOB exceptions are handled, state7may be reached for post execution actions, which may go on as usual.

OOB exception execution as modeled and illustrated inFIG. 6advantageously achieves submitting an operation directly to the LOB system230, but also leverages all error handling and post-processing capabilities built into the client operation execution pipeline. According to one embodiment, the OOB exception606may be introduced into the middle of the operation pipe after the current operation is executed. The OOB exception606may also be introduced after all operations that are independent of the OOB exception in the output queue.

It should be appreciated that various embodiments of the present invention may be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, logical operations including related algorithms can be referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims set forth herein.

Although the invention has been described in connection with various embodiments, those of ordinary skill in the art will understand that many modifications may be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of the invention in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.