Implementing SOA: Using Services
This chapter is from the book
This chapter is from the book
This chapter is from the book
Services, on their own, provide no benefit. To get benefit from your services, you need to employ them as an element of a larger process—a process that provides value to your enterprise. Other participants in the process need to interact with the service and benefit from the service results. Thus you need to be able to integrate the service with other services and nonservice functionality as well as to form your business processes. This chapter explores a number of choices that are available for integrating services into business processes.
Service Interaction Patterns
Synchronous Request-Reply
When you think of "using" a service, what probably comes to mind first is having the service user ask the service provider to perform the service—and then waiting for the result. This style of interaction is characterized by the synchronous request-reply pattern shown in Figure 4-1. It is perhaps the most common service interaction style.
)
Figure 4-1 Synchronous Request-Reply Interaction Pattern
The synchronous request-reply pattern is simple. The service provider only needs to supply a single operation interface (Figure 4-2). The service user calls this operation to submit the request, and this same operation provides the mechanism for returning the result.
)
Figure 4-2 Synchronous Request-Reply Interface
Asynchronous Request-Reply
The synchronous request-reply interaction pattern is not sufficient to build most real-world business processes. Much as you (and the retailer) might like it, when you order a book online, the book does not arrive while you are still sitting at the keyboard! You don't wait for the book, to the exclusion of all other activity, until it arrives. Instead, you go off about your business for a few days until the book is delivered. This is the style of interaction represented by the asynchronous request-reply pattern shown in Figure 4-3.
)
Figure 4-3 Asynchronous Request-Reply Interaction Pattern
Since the asynchronous request-reply pattern delivers the result at some future point, it requires a mechanism—a second operation—for the service provider to deliver the result. If the service provider is to initiate the delivery of the result, then the service user typically provides an operation and corresponding interface for this purpose (Figure 4-4). Note that for the service provider to use this interface, the original request must tell the service provider about the interface to be used to deliver the result.
)
Figure 4-4 User-Supplied Asynchronous Result Interface
Alternatively, the service provider could supply a result retrieval operation with its corresponding interface (Figure 4-5). With this approach, the service user invokes the result retrieval operation to determine whether the result is ready and retrieve it if it is. This is the style of interaction you use when you take your laundry to the dry cleaners. In the first interaction, you deliver the dirty laundry, and in the second you go back to pick up the cleaned items.
)
Figure 4-5 Provider-Supplied Asynchronous Result Interface
When the service provider supplies a result retrieval operation, the service user is the one who initiates the second interaction. For efficiency, the service provider typically specifies a time after which the results will be available. This response-time service-level agreement (SLA) is a promise, but there is no absolute guarantee that your laundry will be ready at that time. But if the service provider meets the promise most of the time (99%), it makes for an efficient interaction. In the absence of such an SLA, the service user can only guess at when the result will be ready. This guesswork leads to the repeated invocation of the interface to determine whether the results are ready—an inefficient process often referred to as polling.
Message-based service access, which involves a third-party communications intermediary, is inherently asynchronous. Thus message-based communications provides a convenient alternative for returning asynchronous results. Message-based approaches are discussed later in this chapter.
Subscription
Subscription services (Figure 4-6) deliver more than one result. They provide an ongoing series of results spread out over time. In using a subscription service, the service user registers with the service provider to receive a series of results—asynchronously. Your newspaper subscription is an example of this type of service, as are the stock market activity alerts delivered to your phone or computer.
)
Figure 4-6 Subscription Interaction Pattern
Like the asynchronous request-reply pattern, the subscription pattern also requires two operation interfaces (Figure 4-7). If the parties are interacting directly, generally one of the interfaces will be provided by the service provider and the other by the service user. The service provider supplies a synchronous request-reply subscription interface that results in acknowledgment of the subscription. The service user provides an interface for the subsequent delivery of the expected results. As with asynchronous request-reply, the subscription request must indicate how the results are to be delivered.
)
Figure 4-7 Typical Subscription Interfaces
Unsolicited Notification
The existence of the service user's delivery interface opens up the possibility for a fourth interaction pattern: the unsolicited notification (Figure 4-8). Once a service provider becomes aware of the presence of a delivery interface, there is nothing stopping the service provider from sending results that were not explicitly requested. The most obnoxious form is, of course, junk mail and its electronic equivalent, spam. But unsolicited notification can be beneficial as well. Companies often notify their employees and customers of significant events using such notifications. If you see flames in an auditorium, yelling "Fire!" is an unsolicited notification as well. You (the service provider) are notifying others in the auditorium (the service users) of the presence of a dangerous situation.
)
Figure 4-8 Unsolicited Notification Pattern
Unsolicited notifications only require a single interface—the delivery interface on the service user (Figure 4-9). As you shall see shortly, the use of a messaging service provides another means of delivering unsolicited notifications.
)
Figure 4-9 Unsolicited Notification Interfaces
Interaction Pattern Summary
More complex interaction patterns than these are, of course, possible. But every interaction pattern can be assembled from these four basic patterns: synchronous request-reply, asynchronous request-reply, subscription, and unsolicited notification. Therefore, a detailed understanding of these four patterns will provide you with the tools to analyze any interaction pattern you may encounter. Chapter 27 will explore the properties of these patterns in more detail and will elaborate on some of the more common complex interaction patterns as well.