Advantages of Service-Interface-Based Protocol Frameworks

works

This section aims at showing the advantages of protocol implementations based on service interfaces over the ones based on events. We structure our discussion in three parts. First, we present how protocols interactions (as defined in Section 7.1) are modeled in both event-based and service-interface-based protocol frameworks. Then, we discuss the composition of protocol modules. Note that protocol compo- sition actually corresponds to define module bindings (see Section 3.1). Finally, we show that, contrary to events, service interfaces provide a convenient mechanism to implement DPU managers (see Section 4.2). The whole discussion is summarized at the end of the section.

7.4.1 Protocol Module Interactions

For each protocol module interaction, we describe how it is modeled in both cat- egories of frameworks. This leads to the following two conclusions: (1) service interfaces provide an adequate model for each interaction, while (2) events inade- quately model requests and replies, which increases the risk of programming errors. Requests. In service-interface-based frameworks, a request is generated to a ser- vice interface. Each request is handled by at the most one executer, since we allow only one executer to be bound to a service interface at a time. On the other hand, in event-based frameworks, a protocol module emulates a request by triggering an event. There is no guarantee that this event is bound to only one handler, which may lead to programming errors (remember that by definition, a request should not be processed by several modules).

Replies. When a protocol module generates a reply to a service interface, only the correct listener (identified when the corresponding request was issued) is executed. This ensures that a request issued by some protocol module Qi, leads to replies

7.4. ADVANTAGES OFSERVICEINTERFACES 79

This is not the case in event-based frameworks, as we now show. Consider pro- tocol module Q1 in Figure 7.1 that triggers event of type G to emulate a request.

Module S1 handles the request. When modules Si triggers an event of type H to

emulate a reply (remember that a reply can occur in any stack), both modules Qi

and Ri will handle the reply (they both contain a handler bound to H). This be-

havior is not correct: by definition, only protocol modules Qi should handle the

reply. Moreover, as modules Riare not necessarily implemented to handle replies

dedicated to Qi, this may lead to errors.

Solutions to solve this problem exist. However, they introduce an unnecessary burden on the protocol programmers and the stack composer. For instance, chan- nels allow to route events to ensure that modules handle only relevant events. How- ever, the protocol programmer must take channels into account when implementing protocols. Moreover, the composition of stacks becomes more difficult due to the fact that the composer has to create many channels to ensure that modules han- dle events correctly. An addition of special protocol modules (named connectors [BMN05, EMPS04]) for routing events is also not satisfactory, since it requires additional work from the composer and introduces overhead.

Notifications. Contrary to requests and replies, notifications are well modeled in event-based frameworks. The reason is that notifications correspond to the one- to-many communication scheme provided by events. In service-interface-based frameworks, notifications are also well modeled. When a module generates a noti- fication to a service interface si, all listeners bound to s are executed.

7.4.2 Protocol Module Composition

Since replies are the results of a request, there is a semantic link between these two kinds of interactions. The composer of protocol modules must preserve this link in order to compose correct stacks. We explain now that service based frameworks provide a mechanism to preserve this link, while in event-based frameworks the lack of such mechanism leads to error-prone composition.

In service-interface-based frameworks, requests and corresponding replies are issued to the same service interface. Thus, a service interface introduces a link between these interactions. To compose a correct stack, the composer has to bind to each service interface si an executer of a module that issues replies to si. Applying this simple methodology, ensures that requests issued to a service interface si are (1) effectively handled by some executer, and (2) result in replies issued to the same service interface si.

In event-based frameworks, all protocol interactions are issued through differ- ent event types. As a result, there is no explicit link between an event triggered upon a request and an event triggered upon the corresponding reply. Thus, the composer of a protocol stack must know the exact meaning of each event type in order to preserve the semantic link between replies and requests, and no simple methodology can be applied to compose correct stacks. Moreover, nothing pre-

80 CHAPTER7. SERVICEINTERFACE

vents the binding of a handler that should handle requests to an event type used to issue replies. This last problem can be, however, solved by typing handlers.

7.4.3 Implementation of DPU Managers

In Figure 7.4, we show how our solution to integrate a DPU manager (see Sec- tion 4.2) can be implemented in protocol frameworks that are based on service interfaces (in the left part of the figure) and on events (in the right part of the fig- ure). The two-sided arrows point to the protocol modules P1 and newP1 that are

switched.

P

R

Repl−P

Q

P

newP

Repl−P

newP

Q

R

Figure 7.4: Implementation of a DPU manager to replace protocol P (stack 1).

It can be seen that the approach that uses service interfaces has advantages. The intercepting module Repl-P1 has an interceptor bound to service interface t

that intercepts every request handled by modules P1 and all replies and notifica-

tions issued by P1. The addition of a DPU manager in a stack is therefore fully

transparent to other protocols.

In event-based frameworks, the solution requires to add an intermediate mod- ule Repl-P1 that intercepts the requests issued to P1 and also the replies and no-

tifications issued by P1. Although this ad-hoc solution may seem similar to the

service-interface-based approach, there is an important difference; DPU managers cannot be transparently added to a stack. Indeed, the event-based solution requires to (1) introduce new events (i.e., G’ and H’) and (2) slightly modify the module P1

since instead of handling events of type G and triggering event of type H, P1must

now handle and trigger events of different types G’ and H’ (see Fig. 7.4).

Note that, contrary to other event-based frameworks, Cactus [Cac01, BHSC98] allows to transparently add DPU managers to protocol stacks. We now explain why. Remember that Cactus allows to define priority for handler executions. This means that handlers with a low priority has a similar behavior as interceptors. Thus, a DPU manager that must intercept some event types G and H can be transparently implemented with two handlers with low priority which are respectively bound to G and H.

7.5. IMPLEMENTATION 81

7.4.4 Summary

Table 7.1 summarizes the whole discussion.

service-interface-based event-based Protocol Module Interaction an adequate an inadequate

representation representation Protocol Module Composition clear and safe complex

and error-prone Implementation of DPU Managers an integrated ad-hocsolutions

mechanism

Table 7.1: Service-interface-based vs. event-based.