Asynchrony and Web Services

Communications between distributed systems fall into two basic categories: synchronous and asynchronous. Synchronous communications consist of round-trip messages in which the sender waits for a reply. Submitting a Web page form and waiting for a confirmation page is a familiar example of a synchronous operation. In contrast, with an asynchronous message, the sender can submit a request, and then go about its work. If a reply does come, then the original sender can pick it up when it wants. Email works asynchronously, for example.

When two computers talk to each other, the exchange is often a synchronous form of communication known as a remote procedure call, or RPC. With an RPC, one computer actually executes a program on the other computer as if it were a local application. Now, many of today’s applications of Web Services are for RPCs, and Web Services are reasonably well suited for this task. However, Web Services are equally well suited for asynchronous messages. As ZapThink explained in an earlier ZapFlash, the fact that Web Services offer a standard way of sending and receiving both synchronous and asynchronous messages is in itself a powerful idea — or idée forte.

The reason that this fact is powerful is because the ability to exchange both kinds of messages is essential to the ability to perform long-running transactions. Typical transactions — say, transferring money from checking to savings — must take place very quickly and reliably, because the various systems involved must wait to make sure the transaction was successful before they go about their business. Such ordinary transactions are therefore constrained by the fact that they must be synchronous. However, a transaction might have multiple steps, for example, company A submitting a purchase order to company B, who fulfills the order and then submits the invoice to company A, who pays it. Such a transaction might take weeks, and thus must be handled asynchronously. Web Services are particularly suited for handling such long-running transactions, because of their support for asynchrony. Unfortunately, many of today’s Web Services implementations leverage only the synchronous aspects of Web Services, limiting their power.

As ZapThink’s research frequently discusses, asynchrony and coarse granularity are two of the key properties that elements of an SOA exhibit. However, these two concepts are actually two sides of the same coin. As application logic and functionality become more coarse grained, they become more “business-like” and less “API-like.” The coarsest of all Services might be the “do business with my company” Service. At this level, all of the details of how the company operates (its processes and Services) are hidden from the Service consumer.

Furthermore, companies are looking to build SOAs that are able from the outset to tie together a diverse collection of Services, activities, tasks, and external processes into orchestrated processes. Such orchestration is especially potent because of the ability to take those orchestrated processes and expose them as Services that can themselves be consumed by other processes or choreographed for interaction with external processes. This recursive process composition accomplishes another key idée forte of SOAs – coarse granularity — by hiding process implementation details behind a Service definition abstraction. Calling applications should not have to know whether or not the Service they are requesting is an atomic Service or a Service that is composed of subprocesses and other Services. Orchestrating processes in this manner helps to create higher levels of process definition and abstraction that eventually meets business requirements.

Flipping this argument on its head, one can say that implementing process-driven SOAs allows enterprises to offer application functionality that provides asynchrony at multiple levels. While communication at the lowest levels of the process might be synchronous (for instance, requests to databases or enterprise applications), the processes themselves are implemented in an asynchronous fashion. Thus, there is no important distinction between asynchronous and synchronous processes. Rather, there are long-lived and short-lived processes, which are implemented in whatever fashion is necessary to meet the requirements of the process. In fact, the process designer should be shielded from the notion of asynchrony entirely. All architects should care about is that a process can be executed within acceptable time frames. Thus, since asynchrony is shielded from the consumer, it must be assumed that any interaction can be synchronous or asynchronous in nature.

The consequences of asynchronous Web Services

However, applying asynchronous techniques and technologies to Web Services implementations, especially those that participate in loosely coupled SOAs, is far from trivial, and the consequences are tremendous. In particular, if asynchrony becomes the modus operandi for communication between Web Services consumers and producers, then one must ask whether the implementation infrastructure is up to the task – in particular, whether an application server or a message bus is appropriate for handling the requirements of asynchrony.

Application servers provide a single execution environment aimed at providing reliable and scalable access to application functionality that resides on the server, whereas message buses are focused on reliable and scalable interactions among loosely coupled systems. Since Web Services are themselves simply comprised of XML-based documents, perhaps message buses are more suited for the coarse-grained, loosely coupled, asynchronous nature of Web Services-based SOAs. However, since the functionality that is abstracted by the Web Services often resides on a single server or collection of servers, that functionality often is implemented on an application server. As a result, a hybrid model for Web Services implementations is often best: using message buses for Service orchestration and choreography, and application servers for atomic Service invocation.

Finally, there is a difference between managing synchronous invocations of Web Services and asynchronous invocations of those same Services. The management issues involved with synchronous Services include making sure that a given Service is available, routing requests in real-time, and decoupling the access mechanism from the Service’s own connection capabilities. However, these capabilities are not required for asynchronous Service invocation. In particular, SOAs that are process-driven support asynchronous process and Service invocation inherently, since the process management system’s queuing mechanism serves as a way to manage the connectivity requirements for individual Web Services. So, what is needed from a management solution in the case of asynchronous Services is not the active management of connections between Service requesters and providers, but rather the isolation of the business process system from having to worry about the implementation details of each Service. This requirement means that management systems must handle policy-based service binding, fulfillment of process activity requirements, facilitating location independence, and business event management.

ZapThink take

As companies move toward SOAs, any business process of importance will consist of a composition of a business’ important Services and activities. In addition, many of these processes will be long-running and require high reliability. Implementing Web Services simply as an extension of synchronous, object-oriented technologies and approaches will quickly complicate any effort to realize the benefits of an SOA. As a result, it is imperative for companies to implement asynchrony — one of the three fundamental tenets of Service-orientation — in order to meet the requirements of long-running, business-critical processes.