Communication is an essential aspect of services. Services do not only realize simple request-response scenarios, but increasingly implement complex and stateful communication protocols. Such a protocol speci es the order in which messages are sent and received by a service and is an essential part of a service description. Services are usually not executed in isolation, but as a collaboration which is composed of several services. The behavior of such a collaboration is not only determined by the communication protocol of each participating service, but also by the way messages are exchanged. A communication model speci es the properties of the message channels between the services and de nes the way how messages are sent and received. This paper studies and classi es several dimensions of communication models and describes their impact to the behavior of service compositions.
The paradigm of service orientation aims at replacing complex monolithic systems
by a composition of several simpler, yet logically or geographically distributed
components, called services. This distributed nature introduces new problems,
because independent services need to collaborate to reach a common goal. One
way to achieve correct collaboration is to o er standardized service descriptions.
The most prominent example is the language WS-BPEL [
Although a communication protocol speci es many dependencies between activities | be it internally or between one service's send activity and another service's receive activity | other details remain unspeci ed. Is the message exchange atomic, or is sending and receiving decoupled? Can the receiver block the sender? Can messages be bu ered, and if yes, how many of them? Each of these questions is not addressed by the WS-BPEL speci cation. However, they still have an impact on the behavior of the overall collaboration.
We observed that | apart from a vague distinction between synchronous and asynchronous message exchange | there does not exist a common understanding how communication should be modeled. This in turn makes it hard to compare existing results on the formalization and analysis of services. To this end, this paper studies communication models. A communication model speci es the aspects of the message exchange such as those previously sketched. It may also include the occurrence of faults. A fault is an undesired and abnormal scenario (i. e., a bu er over ow) for that the subsequent behavior is unspeci ed. A communication model thereby can be seen as the missing piece to completely describe and reason about the behavior of a service composition. Note that communication models are not tied to any speci c service description language or formalization.
This paper is not a survey on existing service description languages or service
formalizations; we refer the interested reader to survey [
The most apparent impact of the choice of a communication model becomes visible in the level of abstraction of the message bu er; that is, the infrastructure which transfers messages between two services. In case of synchronous communication, message exchange is assumed to be instantaneous: Messages are not bu ered and no intermediate state in which a sent message is pending is modeled. Thereby, the meaning of the term \synchronous" is closer to \isochronous" rather than \synchronization", because the latter can also be realized with two messages modeling a handshake.
On the other hand, sending of a message can be decoupled from receiving; that is, sent messages are bu ered until they are received and, as a consequence, communication is asynchronous. Even though considering intermediate states yields in an increased complexity, asynchronous communication allows for more e cient communication, because sender and receiver do not need to constantly synchronize, but can be executed more autonomously. Thereby, asynchronous communication naturally supports the distributed setting of services. blocking sending In the simplest communication model, message exchange is atomic. The sender waits until the receiver is ready for the message exchange, and then they synchronize by executing the sending and the receiving activity simultaneously. In this setting, the state in which the message is sent, but not yet received, is not modeled: the message channel is abstracted from. Consequently, the message exchange is executed in an all-or-nothing fashion. It is notable that the direction of the message exchange is irrelevant from a technical point of view, because there exists no distinguished initiator.
Variants of this synchronous communication loosen this symmetry between
sender and receiver and allow for nonblocking execution of the sending activity.
In case the sending activity can be executed independently from the receiving
activity, the setting in which the receiving activity is not ready for execution
(i. e., the synchronization fails) needs to be speci ed. Then, the message can be
either discarded or a fault occurs. The former scenario is motivated by signal
nets [
Figure 1 provides an overview of the di erent dimensions of synchronous
communication models. The most prominent service model using synchronous
communication is the \Roman model " [
In contrast to synchronous message exchange, asynchronous communication models re ne the message exchange and decouple the sending of a message from its receiving. This is usually motivated by performance issues, and the fact that the actual moment a message is received should be modeled independently of the moment of the sending. Consequently, the state in which the message is in transit (i. e., already sent but not yet received) is explicitly modeled. Consequently, an asynchronous communication model not only needs to specify the characteristics of the sending of a message, but also its transfer and its receipt. These characteristics can be grouped into properties of the employed message bu er (including how it can be accessed by the receiving activity) and sending strategies. buffer: ordering buffer: capacity buffer: quantity ordered unordered bounded unbounded one buffer
multiple buffers blocking sending (only for bounded buffer)
Message bu ers. An asynchronous communication model needs to specify three aspects of message bu ers: their capacity, their organization, and their quantity.
The capacity of a message bu er determines the maximal number of messages which can be simultaneously bu ered. In literature, the case in which a message bu er is unbounded is often considered. This absence of a capacity is typically motivated as a proper abstraction from a concrete, but unknown upper bound. Actually, the determination of the maximal capacity is not trivial, because it is not only in uenced by the service under consideration, but also by those services which are composed to it. Nevertheless, the need of a nite and xed capacity is motivated by the middleware which realizes the communication of services in reality. If the capacity is not known in advance, it may be approximated using capacity considerations or static analysis techniques, or it is chosen su ciently large.
The second aspect speci es how bu ered messages are organized. As
Kazhamiakin et al. [
Finally, communication can be organized using multiple bu ers. In the setting of ordered bu ers, this allows the receiver to access more messages and hence may enable more message-receiving activities compared with the case where only one message can be accessed. For the unordered case, multiple bu ers do not introduce additional behavior. In addition, by organizing each message in a separate ordered bu er, unordered bu ers can be simulated.
Sending strategies. Similar to synchronous message exchange, di erent parameters in uence the way sending activities are executed. For unbounded bu ers, a nonblocking sending is the simplest case. In case a bu er capacity is assumed, the situation in which the bu er is full needs to be speci ed. Either, the message cannot be sent (blocking) or sending is nonblocking and the message is discarded, a bu ered message is overwritten, or an error occurs.
Figure 2 diagrams the four dimensions of asynchronous communication models. Obviously, the bu er capacity and the bu er quantity need to be explicitly speci ed further than \bounded" and \multiple", respectively.
As an example from literature, open nets (previously called open work ow
nets) use interface places to model a message bu er. Using Petri net places yields
an asynchronous communication model with a single unordered bu er. The model
itself does not pose a capacity of the bu er and hence open nets impose an \always
succeed" sending strategy. Similarly, concurrent automata [
The previous section sketched di erent dimension of communication models. In
this section, we demonstrate how the choice of a communication model has an
impact on the controllability of a service. A service is controllable [
As a rst example, consider the service in Fig. 3(a). It controllable if we assume synchronous communication. An asynchronous communication model would need to specify a bu er capacity of at least 2 in case messages are not discarded, because a communication partner cannot observe the receipt of the A message. Figure 3(b) shows compatible partner for bounded channels with a \discard" strategy.
Figure 3(c) demonstrates the impact of ordering of bu ered messages: this service can only be controlled with synchronous communication or ordered bu ers, because reordering of messages A and B results in a situation in which a partner needs to \guess" whether to send a C or D message, and any guess could yield unreceived messages. A similar situation occurs in the interaction with the service in Fig. 3(d). This service cannot be controlled with an asynchronous communication model at all, because the result internal choice (modeled by an XOR gateway) cannot observed by a communication partner. In contrast, a partner with a synchronous communication model with blocking sending, however, can control the service.
Figure 3(e) shows an example of the impact of the bu er quantity. If we assume a single ordered bu er, this service is controllable, for instance by the service in Fig. 3(f). If we assume the transfer of message E takes very long (e. g., in case of a large video le), we cannot speed up the service composition by sending it concurrently to other messages as it is done in Fig. 3(g) which would receive A receive B send C (a) send A send B receive C (b) timeout receive A
receive B receive B
receive A receive C receive D receive A
receive B (c) (d) receive A
send A send B send C receive B
receive C receive D
send D receive E (e) send E (f) send A
send E receive B
receive C send D (g) be a correct partner in case we assume a distinct bu er for message E or an unordered bu er.
The presented examples show that the communication model has an impact
to the overall behavior of a service. In particular, message bu ers may introduce
\new" behavior by enabling message-receiving activities. This additional behavior
may yield in concurrent and more exible service compositions on the one hand,
but also in undesired problems such as deadlocks or unreceived messages on
the other hand. In the context of unordered asynchronous communication, we
already studied the reasons which may lead to uncontrollable service models [
We brie y studied communication models. By sketching di erent dimensions, we re ned and systematized the vague synchronous/asynchronous distinction which can be found in the literature. Furthermore, we demonstrated the impact of di erent communication models with respect to controllability. We showed that one and the same service model (given as BPMN diagram) can be controllable or uncontrollable depending on the chosen communication model.
Directions of future work are manifold. First, we plan to extend the dimensions
of the communication models with other aspects related to instantiation
semantics [
There already exist several approaches to translate between di erent
communication models. Fu et al. [
Finally, the classi cation further needs to be further di erentiated against
many approaches to characterize several aspects in the area of business processes
and services in terms ofpatterns. Whereas the control ow of a service can be
investigated using work ow patterns [