- Introduction
- Synchronous Web Services
- Asynchronous Web Services
- Conclusion
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Asynchronous Web Services
Unlike RPC, which relies on frequent invocations with limited data passing per invocation (to minimize network traffic), the asynchronous model (also known as the document-centric model) advocates passing a document between the requestor and the provider. In most cases, this is the preferred way of integrating at the enterprise level for the following reasons:
- Loose coupling
- Asynchrony support
- Business-level interface
Loose Coupling
With traditional integration methods such as enterprise application integration (EAI), integration tends to happen on a point-to-point basis, and the two endpoints—or more specifically, the applications at each endpoint—have intimate knowledge of each other, which creates dependencies. For example, if the dependency is a particular database product, changing the database product would most likely cause the system to fail.
Loose coupling advocates using a public contract with the public XML messages that the applications will exchange (this is the purpose of the WSDL document); but leaving the implementation details to each application. Loose coupling therefore separates the interface from the implementation details, creating a much weaker dependency between the endpoints. Loose coupling is more resilient than tight coupling to the inevitable changes that will occur.
Another advantage of loose coupling is that the sender and the receiver(s) don't have to be available at the same time. In a later article, we'll examine how a sender can message multiple recipients.
Asynchrony Support
A complex interaction can require a long span of time, and often consists of applications and manual processes. At any given time in this process, the following problems may occur:
A particular resource may be unable to respond immediately because it's unavailable or busy.
The bandwidth may not be available for the two systems to be reliably connected.
The request may take a long time to complete. (In this case, the receiving application should send an acknowledgment to the requester to broadcast that it has successfully received the message.)
As an example, consider the use of a phone call versus an email message. The phone call is synchronous because it requires both parties to be available (and both phones to be functional) for an exchange of information; that is, both sides have to be synchronized. An email message is asynchronous because the originating party can send the message and then turn to a different task, without having to wait for a response. The recipient can be offline, but will eventually receive the message. Asynchrony requires the support of a solid messaging infrastructure that guarantees delivery (described in the later section "Messaging"); thus, asynchronous systems are often called message-based systems. As we'll see later, however, guaranteed delivery is not yet part of the current web services standards.
If the asynchronous model is so superior, why would we use the synchronous model at all? The short answer is that it's much more difficult to implement an asynchronous model, and in many cases asynchrony is not even needed. Consider a scenario where a customer's credit card needs to be validated. In this case, the customer is not allowed to continue the transaction until the credit card has been validated; the synchronous model is sufficient—and in fact preferred.
Business-Level Interface
A third characteristic of an asynchronous web service is a business-level interface. As mentioned earlier, CORBA and other forms of middleware (J2EE and DCOM) supported the concept of loose coupling, but their model was flawed because it encouraged designing a distributed system as though calls to a remote system were transparent. That is, all invocations were handled without regard to network latency, often the biggest bottleneck in a distributed system. During execution, a program makes a great number of calls, passing along associated parameters, and the performance of a system is directly dependent on the total elapsed time of these calls.
A classic way of designing systems is to pass only the minimum data necessary during each invocation, resulting in many roundtrip invocations. This model results in a fine-grained interface that's much more granular than may have been originally surmised; that is, the list of operations that can be invoked is long because each one performs a very granular piece of functionality, usually getting or setting data.
As an example, consider a "create a customer" business scenario. From the business analyst's perspective, creating a customer is a single business process. But because of the way traditional middleware works (fine-grained interfaces), the public interface—the one that's exposed to the outside world—lists all the low-level operations. This exposure of low-level details often leads to tight coupling, a potential maintenance problem, but it can also lead to performance problems.
Figure 1 illustrates some problem areas with this model.
)
Figure 1 A typical low-level interface.
Many roundtrip invocations are manageable on a local area network, but this setup doesn't scale to the Internet because of unpredictable delays between the caller and recipient. As an example, consider that a local call (on the same machine) can complete in microseconds, and a remote call between two machines connected on a LAN can complete in milliseconds. A remote call between two machines connected across the Internet can take seconds, which is potentially thousands of times slower. Recall that the performance of a system is directly tied to the total invocation time, and it becomes fairly obvious that this model is not well suited for the Internet. Instead of viewing the architecture as a series of connected applications, we need to view it as a series of connected businesses and define the interfaces at that level.
Identifying a business-level interface is not as simple as it may appear. To minimize roundtrip invocations, the two parties need to mutually agree on a business process (such as "create a customer") and then define an associated document structure that allows the recipient to process the information without requiring roundtrip invocations. This document structure can (and should) follow industry-specific standards—for example, the HR industry defines a standard structure called HRXML—which can minimize the work of defining the structure and facilitate interoperability. The challenge then is to build a workable process model along with the associated documents to interact with the various parties.