composition of service and protocol speciﬁcations in ... · pdf filecomposition of service...

2306IEICE TRANS. INF. & SYST., VOL.E87–D, NO.10 OCTOBER 2004

PAPER

Composition of Service and Protocol Specificationsin Asynchronous Communication System

Noppadol MANEERAT†,††, Ruttikorn VARAKULSIRIPUNTH†a), Bhed Bahadur BISTA†††, Nonmembers,Kaoru TAKAHASHI††††, Yasushi KATO††††, Members, and Norio SHIRATORI†††††, Fellow

SUMMARY One of the important techniques in communication sys-tem design is the composition of service and protocol specifications. Inthis paper, we have presented a new approach to the composition techniquebased on the weak bisimulation concept. The main objective is to combineservice specifications and protocol specifications individually and simulta-neously. The composition technique can maintain the equivalence betweenthe composed service and protocol specifications. LOTOS language termsare utilized to describe the communication specifications. The applicationon the asynchronous model is presented. Moreover, a support system of thecomposition technique is developed and presented in this paper.key words: LOTOS, LTS, weak bisimulation, asynchronous model

1. Introduction

Communication system consists of two elements, i.e., pro-tocol and service. Protocol is a set of processes (entities)communicating with each other under defined rules to ac-complish a common task. Service is a set of requested tasksthat are processed by protocol. Therefore, the proper de-sign of service and protocol specifications becomes impor-tant. A service is specified based on the temporal orderingof actions that may occur at different Service Access Points(SAPs). A protocol is specified so that each communicatingprocess provides service at its SAP by exchanging messageswith each other.

In previous studies related to communication systemdesign, the technique to derive protocol specifications fromservice specifications was presented [2], [4], [5], and thetechnique of partial functional protocol specification wasdiscussed [6]–[8]. Bista et al. [3] proposed a compositionalapproach for constructing communication service and pro-tocol simultaneously. They considered service and proto-col as parallel elements. The advantage of this approach

Manuscript received April 22, 2002.Manuscript revised April 12, 2004.†The authors are with the Faculty of Engineering & Research

Center for Communications and Information Technology, KingMongkut’s Institute of Technology Ladkrabang, Bangkok 10520,Thailand.††The author is with Computer Research and Service Center,

King Mongkut’s Institute of Technology Ladkrabang, Bangkok10520, Thailand.†††The author is with the Faculty of Software and Information

Science, Iwate Prefectural University, Iwate-ken, 020–0173 Japan.††††The authors are with Sendai National College of Technology,

Sendai-shi, 989–3128 Japan.†††††The author is with Research Institute of Electrical Communi-

cation, Tohoku University, Sendai-shi, 980–8577 Japan.a) E-mail: [email protected]

is that it is easy to design and verify the specifications be-cause the composed protocols were defined in terms of sub-functions. They used Langerak’s algorithm [2] to decom-pose service and to construct the equivalent protocol speci-fications. Four major operators in LOTOS [1], i.e., enabling,choice, parallel, and disabling were used in compositionmethod. They applied this technique to synchronous com-munication model to show its availability.

In this paper, we have modified and extended thecomposition technique of Bista et al., in order to apply itto the asynchronous communication model. We use theweak bisimulation concept to combine service specificationsand protocol specifications individually and simultaneouslywhile maintaining the equivalence between composed ser-vice and composed protocol specifications. Finally, we havedeveloped its support system.

2. Definition of Transition and Bisimulation

LOTOS (Language Of Temporal Ordering Specification)[1] is an FDT (Formal Description Technique) developed byISO for the formal description of distributed systems. Theprocess behavior is expressed in terms of temporal orderingof its actions. Operators used in this paper to represent aprocess are shown in Table 1.

“stop” denotes the inaction of the specified process.“exit” denotes a process which performs the successful

termination action δ and becomes stop.“a; P” and “i; P” denote process P preceded by the ac-

tion a and the internal or unobservable action i, respectively.“P” denotes the invocation of process P.“P1 [] P2” denotes a process with the alternative com-

position of processes P1 and P2 where it is ready to behaveas P1 or as P2.

“P1 >> P2” denotes a process with the sequential com-

Table 1 Basic LOTOS operators.

Name OperatorInaction stopSuccessful termination exitAction prefix a; P, i; PProcess Instantiation PChoice P1 [] P2Enabling P1 >> P2Parallel composition (Synchronization) P1 |[G]| P2Parallel composition (Interleaving) P1 ||| P2Disabling P1 [> P2

MANEERAT et al.: COMPOSITION OF SERVICE AND PROTOCOL SPECIFICATIONS2307

position of processes P1 and P2 where execution of actionsof P2 starts only after P1 successfully terminates.

“P1 |[G]| P2” denotes a process with parallel compo-sition of processes P1 and P2 where G specifies the list ofsynchronization actions. An action listed in G or δ can beexecuted as a common action of P1 and P2 while other ac-tions are executed independently. When G is empty, i.e. |[]|,it is usually represented by |||.

“P1 [> P2” denotes a process with the interrupted com-position of processes P1 and P2 where P1 is interrupted byP2.

Here, our technique is mainly concerned with a labeledtransition system to describe the formal semantics of a pro-cess. We define Act as a set of actions, Act* as a set ofsequences of actions in Act and i* as zero or more i (inter-nal) actions. Act(P) is defined as the set of actions whichprocess P can execute.

[Definition 1] A Labeled Transition System (LTS) L is aquadruple < S , A, T, s0 >, where S is a nonempty set ofstates, A is a subset of Act, T ⊆ S × A × S is a transitionrelation and s0 ∈ S is the initial state of L. �

Using the operational semantics given in the above def-initions, a bisimulation relation is defined:

[Definition 2] Let L1 =< S 1, A1, T1, s10 > and L2 = <S 2, A2, T2, s20 > be labeled transition systems. A binaryrelation R ⊆ S 1 × S 2 is a weak bisimulation relation if(s1, s2) ∈ R implies that, for all t ∈ (Act − {i})*,

1. if s1t⇒ s′1 for some s′1, then s2

t⇒ s′2 and (s′1, s′2) ∈ R for

some s′22. if s2

t⇒ s′2 for some s′2, then s1t⇒ s′1 and (s′1, s

′2) ∈ R for

some s′1. �

In this definition, if t = a1 . . . an ∈ (Act − {i})*, then

st⇒ s′ stands for

si∗→ a1→ i∗→ a2→ i∗→ . . . i∗→ an→ i∗→ s′

Here, the notation s1a→ s2 represents the transition from

state s1 to state s2 by the execution of the action a.L1 is weakly bisimilar to L2 (or L1 is weakly bisimula-

tion equivalent to L2) written as L1 ≈ L2, if (s10, s20) ∈ R forsome weak bisimulation R. A process P is weakly bisimilarto a process Q (or P is weakly bisimulation equivalent to Q),written as P ≈ Q, if the labeled transition systems of P andQ are weakly bisimulation equivalent.

3. Service and Protocol Models

In this section, the models of service and protocol in asyn-chronous communication system are described first. Next,a polling mechanism is introduced to preserve the order ofactions and is used to let the behaviors of service and proto-col be equivalent. Finally, the decomposition algorithm thatis used to derive the equivalent protocol specification from

Fig. 1 (a) Service model and (b) Protocol model.

Fig. 2 LTS of service specification.

a service specification automatically is summarized.

3.1 Service Model

A service is modeled as a black box as shown in Fig. 1 (a).Here, we know only what is provided at each SAP but wedo not know how. The black box represents all of the lowerlayers including local node, network and remote node. Aservice is described by the temporal ordering of actions thatoccur at SAPs. In this paper, we assume that there aretwo SAPs, where SAP1 is at node 1 and SAP2 is at node2. The service specification is in an action-prefix form,e.g., S =

∑{ai; Ai|i ∈ I} for some finite index set I whereeach Ai is either a process identifier or an expression in anaction-prefix form. The behavior of a specification is rep-resented by an LTS. We define

∑as the generalized choice

among behavior expressions distinguished by the index setI. For example, if S =

∑{ai; Ai|i ∈ I} for some finite in-dex set I where each Ai is either a process or an expres-sion in an action-prefix form, and when I = {1, 2}, we haveS = a1; A1[]a2; A2 and furthermore if A1 = b1; stop andA2 = b2; stop then S = a1; b1; stop[]a2; b2; stop. In thiscase, the LTS of this specification S is shown in Fig. 2.

3.2 Protocol Model

In contrast to service, a protocol is modeled as a white boxshown in Fig. 1 (b). A protocol is a specification of commu-nication entities that communicate with each other to pro-vide a service at SAPs. We also assume that the protocolmodel has two SAPs, (SAP1 and SAP2), with two protocolentities, PE1 and PE2. The protocol specification specifiesthe behavior of the protocol entities mediated by Mediumwhich is thought of as the whole of the lower layers. PE1sends messages to PE2 through synchronized gate send1and receives messages from PE2 through synchronized gaterec1. On the other hand, PE2 sends and receives messagesto and from PE1 via synchronized gates send2 and rec2, re-spectively.


According to Fig. 1 (b), a protocol is expressed by thefollowing expression in LOTOS where Medium is defined inSect. 3.4.

(PE1|||PE2)|[send1, rec1, send2, rec2]|MediumThe service and the protocol specifications must

be weakly bisimulation equivalent when internal actions,which occurred except that SAPs, are hidden from the en-vironment.

The weak bisimulation equivalence between the ser-vice and the protocol specifications basically means that,from an external observer’s point of view, the actions thatoccur at SAPs of the service specification are indistinguish-able from the actions that occur at SAPs of the protocol spec-ification.

3.3 Polling Mechanism

In general, protocol entities communicate in parallel viaMedium as shown in Fig. 1 (b). Then, the order of ac-tions in protocol and service specifications may be differ-ent when the actions at different SAPs were chosen by theenvironment. The service and the protocol may not bebisimilar, because the temporal order may not be main-tained. Therefore, we have applied a mechanism to ex-change a polling message between entities in order to main-tain the order. Figure 3 (a) shows the LTS of a sim-ple service specification where action a1 occurs at SAP1and action b2 occurs at SAP2. Figure 3 (b) shows theLTS of the corresponding protocol specification using thepolling mechanism for each node. Nodes 1 and 2 exchangethe polling messages (send1!poll, rec2!poll, send2!poll andrec1!poll)† with each other at the point where actions atdifferent SAPs are possible to occur. It is easily shownthat Figs. 3 (a) and 3 (b) are weakly bisimulation equiva-lent when we hide the polling messages. The exchange ofpolling messages is thus a simple but a powerful way of ac-complishing the weak bisimulation equivalence. Figure 4

Fig. 3 (a) LTS of service specification and (b) LTS of protocol specifica-tion with polling mechanism.

Fig. 4 LTS of protocol specification without polling mechanism.

shows the LTS of protocol specification without pollingmechanism. In this case, each action occurs at each SAP in-dependently. So the LTSs shown in Figs. 3 (a) and 4 are notweakly bisimulation equivalent because the temporal orderis different.

We use the polling mechanism when our compositiontechnique requires one to preserve the weak bisimulationequivalence between service and protocol specifications aswell as when a service is decomposed into the correspond-ing protocol.

3.4 Summary of the Decomposition Algorithm

The basic idea of the decomposition algorithm [2] is to sendeither a sent or a received action signal after an observableaction. We then decompose a service specification S. We as-sume that Med1 and Med2 are buffers within Medium whichis able to hold one message simultaneously. A message fromPE1 to PE2 is sent through synchronized gate send1 and re-ceived at synchronized gate rec2. A message from PE2 toPE1 is sent via synchronized gate send2 and received at syn-chronized gate rec1. Medium is defined as follows,

Medium = Med1|||Med2where Med1 =

∑{send1!m; rec2!m; Med1|m ∈ M}Med2 =

∑{send2!m; rec1!m; Med2|m ∈ M}where M is the universe of messages.

In this algorithm, we identify specifications of proto-col entities by T1act(S), T1pas(S), T2act(S), and T2pas(S).Here, T1act(S) and T1pas(S) correspond to PE1, T2act(S)and T2pas(S) correspond to PE2. T1act(S) and T1pas(S)are not independent of each other. If an action in T1act(S)has been executed, T1pas(S) should be notified in order toproduce the appropriate behavior after the action. This noti-fication is done by a message on synchronization via a syn-chronization gate. T1act(S) is a process that contains send-ing actions and T1pas(S) is a process that contains receivingactions. T2act(S) and T2pas(S) are similarly explained.

As we do not treat any internal actions in this paper,we omit the decomposition that contains the internal actioni. The decomposition algorithm is shown as follows. Weassume that an expression S in an action-prefix form hasbeen given. This algorithm decomposes S into T1act(S),T1pas(S), T2act(S), and T2pas(S), where actions of node 1are ai (i ∈ I) and actions of node 2 are b j ( j ∈ J).

Decomposition Algorithm

S =∑{ai; Ai|i ∈ I}[]∑{b j; B j| j ∈ J}

Then,T1act(S ) =

∑{ai; send1!mi; T1pas(Ai)|i ∈ I}[]send1!poll; (

∑{rec1!m j; T1act(Bj)| j ∈ J}[]rec1!poll; T1act(S ))

T1pas(S ) =∑{rec1!m j; T1act(B j)| j ∈ J}

[]rec1!poll; (∑{ai; send1!mi; T1pas(Ai)|i ∈ I}

†In LOTOS, when processes exchange message, message, bysynchronizing at the gate, gate, it is represented as gate!message.This is a LOTOS syntax.


[]send1!poll; T1pas(S ))T2act(S ) =

∑{b j; send2!m j; T2pas(B j)| j ∈ J}[]send2!poll; (

∑{rec2!mi; T2act(Ai)|i ∈ I}[]rec2!poll; T2act(S ))

T2pas(S ) =∑{rec2!mi; T2act(Ai)|i ∈ I}

[]rec2!poll; (∑{b j; send2!m j; T2pas(B j)| j ∈ J}

[]send2!poll; T2pas(S )) �

[Theorem 1] Let S be a process in an action-prefix formand T1act(S ) and T2pas(S ) defined by the decompositionalgorithm. Then

S ≈ hide send1, rec1, send2, rec2 in(T1act(S ) ||| T2pas(S ))|[send1, rec1, send2, rec2]|Medium �

<Example of decomposition>We apply the decomposition algorithm to a simple servicespecification as described below.Given S = a1; b2; stop, S ′ = b2; stop, and S ′′ = stopThe result of decomposition of the service is shown as fol-lows.

T1act(S ) = a1; send1!a1; T1pas(S ′)[]send1!poll; rec1!poll; T1act(S )

T1pas(S ′) = rec1!b2; T1act(S ′′)[]rec1!poll; send1!poll; T1pas(S ′)

T1act(S ′′) = send1!poll; rec1!poll; T1act(S ′′)T2pas(S ) = rec2!a1; T2act(S ′)

[]rec2!poll; send2!poll; T2pas(S )T2act(S ′) = b2; send2!b2; T2pas(S ′′)

[]send2!poll; rec2!poll; T2act(S ′)T2pas(S ′′) = rec2!poll; send2!poll; T2pas(S ′′) �

4. Composition Method

In this section, we propose our composition method for ser-vice and protocol specifications. First, outline of composi-tion of specifications is described. Next, the characteristicsof the composition method are given followed by the com-position methods.

4.1 Outline of Composition

In our composition method, we assume that protocol spec-ifications P1 and P2 are derived from the service specifi-cations S 1 and S 2, respectively by applying the decompo-sition algorithm described in Sect. 3.4. Under this assump-tion, S 1 and S 2, as well as P1 and P2 are composed. Then,the composition of the service and the protocol specifica-tions would be weakly bisimilar and is described as follows(see Fig. 5).

S 1 ∗ S 2 ≈ hide send1, rec1, send2, rec2 in((T1act(S 1) ∗ T1act(S 2))|||(T2pas(S 1)∗T2pas(S 2))) |[send1, rec1, send2, rec2]| Medium

Here, the symbol * represents the LOTOS operator whichcan be any of the following: enabling, choice, parallel, ordisabling. The enabling “>>” can be used for serializing thephases, the choice “[]” for selecting features, the parallel

Fig. 5 Relation between the composed service and protocol specifica-tions.

Fig. 6 Protocol entity 1.

“|[G]|” for combining functions executed in parallel, and thedisabling “[>” for disconnection or interruption.

4.2 Characteristics of Composition Method

In this section, we explain the preconditions and the char-acteristics of composition and decomposition of the speci-fications. In order to manifest that the composition of theprotocols can be done without any contradiction, it is im-portant to keep the weak bisimulation equivalence betweenthe composition of the service specifications which repre-sent the external behaviors of the system and the composi-tion of the protocol specifications which represent how toprovide the services in the system. The protocol specifica-tions are derived by the decomposition of the service speci-fications using the Langerak’s decomposition algorithm. Incase of decomposition in the asynchronous model, main-taining the order of actions is controlled by sending andreceiving the synchronization actions through the mediumbetween the entities.

The expression S as the object of the decompositionmeans the service which may contain some choices betweendifferent nodes. Therefore the polling messages should beadded to the derived protocol specification to maintain theweak bisimulation equivalence with the service specifica-tion. Two service specifications, which correspond to theprotocol specifications P1 and P2, have been considered.The polling messages exchanged between entities of P1 andthe polling messages exchanged between entities of P2 aredistinguished as poll and poll′, respectively, as shown inFigs. 6, 7 and 8. And by doing so, the composition methodbecomes more simple.

The basic idea of the composition of service and proto-


Fig. 7 Protocol entity 2.

Fig. 8 LTS of resultant protocol specification.

col specifications is described as follows.Given the service specifications S 1 and S 2 correspond-

ing to the following protocol specifications P1 and P2 re-spectively, we have;

P1 = (T1act(S 1)|||T2pas(S 1))|[send1, rec1, send2, rec2]| Medium


S 1 and S 2 are weakly bisimulation equivalent to P1and P2, respectively when we hide the notification actionssend1, rec1, send2 and rec2, and are shown as follows.

S 1 ≈ hide send1, rec1, send2, rec2 in P1S 2 ≈ hide send1, rec1, send2, rec2 in P2In order to compose the protocol specifications corre-

sponding to the service specifications under the precondi-tions mentioned above, we compose the entities that corre-spond to the same node (SAP) in P1 and P2. Composition ofservice and protocol specification has been done as follows.Service specification:

S 1 ∗ S 2Protocol specification:

((T1act(S 1) ∗ T1act(S 2))|||(T2pas(S 1)∗T2pas(S 2))) |[send1, rec1, send2, rec2]| MediumThe composition of the services should become weakly

bisimulation equivalent to the composition of the pro-tocols as shown below when the notification actionssend1, rec1, send2, and rec2 are hidden.

S 1 ∗ S 2 ≈ hide send1, rec1, send2, rec2 in((T1act(S 1) ∗ T1act(S 2))|||(T2pas(S 1)∗T2pas(S 2))) |[send1, rec1, send2, rec2]| MediumThe symbol “∗”means “[]”, “>>”, or “|[G]|” in the LO-

TOS operators. The protocol composition methods whichare choice, enabling, and parallel compositions agree withthe expression mentioned above. The polling messages,which have been kept during the decomposing service spec-ification, work well in maintaining equivalency when thechoice between different nodes exists.

<Example of composition>We show an example where the composition operator is thechoice. Service specifications S 1 and S 2 are given as fol-lows.

S 1 = a1; b2; stopS 2 = c2; d1; stopAfter decomposition of services into protocol entities,

we compose the entities at the same node together. The en-tities of each node, node 1 and node 2, are shown in Figs. 6and 7, respectively. The resultant protocol specification isshown in Fig. 8.

Note that an action subscript i (i = 1, 2), such as a1 andc2, represents the action executed at the SAP i (node i). Thisnotation is used throughout the rest of the paper. �

As shown in this example, in order to make the com-position methods more general and simpler, several pollingmessages are introduced in protocol specification. However,unnecessary polling messages can be removed without anyproblem. For instance, in Fig. 6, polling messages can be re-moved without any effect to the system except polling mes-sages between actions a1 and rec1!c2. If the polling mes-sages are not for the choice between different nodes, we canremove them.

In case of disabling, the composition of the servicesand the protocols generally does not become weakly bisim-ulation equivalent by using the above expression.

Disabling is the composition that a service can inter-rupt every state of another service. The polling messages,which have been kept during the decomposition of the ser-vice specification, work to maintain the equivalency only inthe case of choice between the initial actions. Therefore,the other composition method needs to be applied. We con-vert the disabling expression into an expression that containschoices. The derivation process of disabling method is de-scribed in Sect. 4.3.4. Intermediate behavior expressions Pand Q, which correspond to node 1 and node 2, respectively,have been created for disabling composition as follows.

S 1 [> S 2 ≈ hide send1, rec1, send2, rec2 in(P ||| Q) |[send1, rec1, send2, rec2]| Medium


4.3 Composition Methods

In this section, four types of the composition methods corre-sponding to the LOTOS operators, “>>”, “|[G]|”, “[]”, and“[>” are shown.

Due to the introduction of polling messages, the com-position methods ensure that the protocol specification andthe service specification are weakly bisimilar. The proof ofthe correctness of the composition methods can be done bythe expansion technique [2]. In the expansion technique, theprotocol specification which consists of parallel composi-tion of protocol entities and the medium is expanded (flat-tened) using the inference rules of the LOTOS parallel oper-ator until the protocol specification cannot be expanded [3].

4.3.1 Enabling

Enabling composition between two service specificationsS 1 and S 2 is shown as “S 1 >> S 2” using the LOTOS op-erator “>>”. This means that after S 1 normally completed,S 2 occurs. So we directly compose the protocol entities atthe same node of P1 and P2, and the equivalency is main-tained.

[Method 1]The following protocol specifications P1 and P2 are

derived from the service specifications S 1 and S 2 by thedecomposition algorithm.



S 1 and S 2 are weakly bisimulation equivalent toP1 and P2, respectively when the notification actionssend1, rec1, send2, and rec2 are hidden and are shown be-low.

S 1 ≈ hide send1, rec1, send2, rec2 in P1S 2 ≈ hide send1, rec1, send2, rec2 in P2The compositions of the services and the protocols are

executed as follows.Service: S 1 >> S 2Protocol: ((T1act(S 1) >> T1act(S 2)) |||

(T2pas(S 1) >> T2pas(S 2)))|[send1, rec1, send2, rec2]| Medium �

<Example of Method 1>Service specifications S 1 and S 2 are given as follows.S 1 = a1; b2; exit, S 1′ = b2; exit, S 1′′ = exitS 2 = c2; d1; stop, S 2′ = d1; stop, S 2′′ = stopWe decompose them and get the protocol specifications, P1and P2.P1 = (T1act(S 1)|||T2pas(S 1))

|[send1, rec1, send2, rec2]| MediumT1act(S 1) = a1; send1!a1; T1pas(S 1′)

[]send1!poll; rec1!poll; T1act(S 1)T1pas(S 1′) = rec1!b2; T1act(S 1′′)

[]rec1!poll; send1!poll; T1pas(S 1′)T1act(S 1′′) = send1!poll; rec1!poll; T1act(S 1′′)T2pas(S 1) = rec2!a1; T2act(S 1′)

[]rec2!poll; send2!poll; T2pas(S 1)T2act(S 1′) = b2; send2!b2; T2pas(S 1′′)

[]send2!poll; rec2!poll; T2act(S 1′)T2pas(S 1′′) = rec2!poll; send2!poll; T2pas(S 1′′)


T1act(S 2) = send1!poll′; (rec1!c2; T1act(S 2′)[]rec1!poll′; T1act(S 2))

T1act(S 2′) = d1; send1!d1; T1pas(S 2′′)[]send1!poll′; rec1!poll′; T1act(S 2′)

T1pas(S 2′′) = rec1!poll′; send1!poll′; T1pas(S 2′′)T2pas(S 2) = rec2!poll′; (c2; send2!c2; T2pas(S 2′)

[]send2!poll′; T2pas(S 2))T2pas(S 2′) = rec2!d1; T2act(S 2′′)

[]rec2!poll′; send2!poll′; T2pas(S 2′)T2act(S 2′′) = send2!poll′; rec2!poll′; T2act(S 2′′)Services and protocols are weakly bisimilar when we

hide the notification actions.S 1 ≈ hide send1, rec1, send2, rec2 in P1S 2 ≈ hide send1, rec1, send2, rec2 in P2Then, we get the compositions of the specifications by

applying Method 1 as follows.Service specification:

S 1 >> S 2 = a1; b2; exit >> c2; d1; stopProtocol specification:

((T1act(S 1) >> T1act(S 2))|||(T2pas(S 1) >>T2pas(S 2))) |[send1, rec1, send2, rec2]| MediumThe compositions of the services and protocols are

weakly bisimilar when we hide the notification actions.S 1 >> S 2 ≈ hide send1, rec1, send2, rec2 in

((T1act(S 1) >> T1act(S 2))|||(T2pas(S 1) >>T2pas(S 2))) |[send1, rec1, send2, rec2]| Medium

�

4.3.2 Parallel

If G is a set of the synchronization actions at S 1 and S 2,the parallel composition between two service specificationsS 1 and S 2 is shown as “S 1 |[G]| S 2” using the LOTOSoperator “|[G]|” and G = Act(S 1) ∩ Act(S 2). If G = ø,S 1 and S 2 become an asynchronous parallel composition,and if G � ø, they become a synchronous parallel compo-sition synchronized at the actions in G. In case that S 1 andS 2 have no synchronization actions, the actions of S 1 andS 2 can occur independently with any order. On the otherhand, in case that S 1 and S 2 have some synchronizationactions, these actions must occur synchronously at S 1 andS 2, and the other actions occur independently. In the caseof protocol composition, we can compose the protocol enti-ties in parallel at the same node of P1 and P2, respectively.If P1 and P2 have some synchronization actions, they willbe synchronously composed in their actions and notificationactions.


[Method 2]The precondition is the same as Method 1. When

we express the synchronization actions as G = Act(S 1) ∩Act(S 2), G1 = Act(T1act(S 1))∩ Act(T1act(S 2)) and G2 =Act(T2pas(S 1)) ∩ Act(T2pas(S 2)), we execute the parallelcomposition of the services and the protocols as follows.Service: S 1 |[G]| S 2Protocol: ((T1act(S 1) |[G1]| T1act(S 2)) |||

(T2pas(S 1) |[G2]| T2pas(S 2)))|[send1, rec1, send2, rec2]| Medium �

<Example of Method 2>Service specifications S 1 and S 2 are given as follows.S 1 = a1; b2; stop, S 1′ = b2; stop, S 1′′ = stopS 2 = c2; a1; stop, S 2′ = a1; stop, S 2′′ = stopWe decompose them and get the protocol specifications, P1and P2.P1 = (T1act(S 1)|||T2pas(S 1))|[send1, rec1, send2, rec2]| MediumT1act(S 1) = a1; send1!a1; T1pas(S 1′)







T1act(S 2′) = a1; send1!a1; T1pas(S 2′′)[]send1!poll′; rec1!poll′; T1act(S 2′)


[]send2!poll′; T2pas(S 2))T2pas(S 2′) = rec2!a1; T2act(S 2′′)




S 1 |[a1]| S 2 = a1; b2; stop |[a1]| c2; a1; stopProtocol specification:

((T1act(S 1) |[a1, send1!a1]| T1act(S 2)) |||(T2pas(S 1) |[rec2!a1]| T2pas(S 2)))|[send1, rec1, send2, rec2]| MediumThe compositions of the services and protocols are

weakly bisimilar when we hide the notification actions.S 1 |[a1]| S 2 ≈ hide send1, rec1, send2, rec2 in((T1act(S 1) |[a1, send1!a1]| T1act(S 2)) |||

(T2pas(S 1) |[rec2!a1]| T2pas(S 2)))|[send1, rec1, send2, rec2]| Medium �

4.3.3 Choice

Choice composition between two service specifications S 1and S 2 is shown as “S 1[]S 2” by using the LOTOS opera-tor “[]”. This means that either S 1 or S 2 is selected. Thepolling messages, which have been kept when decomposingthe service specifications, work to maintain the equivalency.

[Method 3]The precondition is the same as Method 1. We execute

the choice composition of the services and the protocols asfollows.Service: S 1 [] S 2Protocol: ((T1act(S 1)[]T1act(S 2))|||(T2pas(S 1)[]

T2pas(S 2))) |[send1, rec1, send2, rec2]| Medium�

<Example of Method 3>Service specifications S 1 and S 2 are given as follows.S 1 = a1; b2; stop, S 1′ = b2; stop, S 1′′ = stopS 2 = c2; d1; stop, S 2′ = d1; stop, S 2′′ = stopWe decompose them and get the protocol specifications, P1and P2.P1 = (T1act(S 1)|||T2pas(S 1))|[send1, rec1, send2, rec2]| MediumT1act(S 1) = a1; send1!a1; T1pas(S 1′)







T1act(S 2′) = d1; send1!d1; T1pas(S 2′′)[]send1!poll′; rec1!poll′; T1act(S 2′)


[]send2!poll′; T2pas(S 2))T2pas(S 2′) = rec2!d1; T2act(S 2′′)





S 1[]S 2 = a1; b2; stop[]c2; d1; stopProtocol specification: (See in Figs. 6, 7 and 8)

((T1act(S 1)[]T1act(S 2))|||(T2pas(S 1)[]T2pas(S 2)))|[send1, rec1, send2, rec2]| MediumThe compositions of the services and protocols are

weakly bisimilar when we hide the notification actions.S 1[]S 2 = hide send1, rec1, send2, rec2 in((T1act(S 1)[]T1act(S 2))|||(T2pas(S 1)[]T2pas(S 2)))|[send1, rec1, send2, rec2]| Medium

�

4.3.4 Disabling

Disabling composition between two service specificationsS 1 and S 2 is shown as “S 1 [> S 2” by using the LOTOSoperator “[>”. The choice composition method cannot beapplied to disabling directly, because the equivalency is notmaintained. Then we need to consider another method. Weconvert the expression of disabling into another one consist-ing of only the choice, and consider the disabling method asa repetition of choice. Before going to the method, we showthe process of developing the disabling method with an ex-ample.

[Derivation Process of Disabling Method]Assume the following service specifications S 1 and

S 2.S 1 = a1; b2; stopS 2 = c2; d1; stopB = d1; stopLet S be the following service composed by disabling.S = S 1 [> S 2 = a1; b2; stop [> c2; BWe can convert the above expression into another one

consisting of only the choice shown below.S = a1; (b2; (stop[]c2; B)[]c2; B)[]c2; BWe divide the above expression into each choice ex-

pression as follows.A0 = a1; A1[]c2; BA1 = b2; A2[]c2; BA2 = stop[]c2; B = c2; BThe protocol specifications of S 1 and S 2 correspond

to the following P1 and P2 which have a style without thepolling messages.

P1 = (E1|||E2) |[send1, rec1, send2, rec2]|Medium

P2 = (F1|||F2) |[send1, rec1, send2, rec2]|Medium

where entity correspondence is as follows.E1 and F1 are entities at node1.E2 and F2 are entities at node2.

The specifications of each entity are as follows.E1 = a1; send1!a1; rec1!b2; stopE2 = rec2!a1; b2; send2!b2; stopF1 = rec1!c2; d1; send1!d1; stopF2 = c2; send2!c2; rec2!d1; stopGenerally, the weak bisimulation equivalence is not

preserved by a straightforward composition between proto-

col entities corresponding to the same node of S 1 and S 2.S 1 [> S 2 � hide send1, rec1, send2, rec2 in((E1 [> F1) ||| (E2 [> F2))|[send1, rec1, send2, rec2]| MediumSo, we introduce intermediate behavior expressions P

and Q which satisfy the next formula.S 1 [> S 2 ≈ hide send1, rec1, send2, rec2 in(P ||| Q) |[send1, rec1, send2, rec2]| MediumP and Q correspond to the protocol entities at node 1

and node 2, respectively.In order to derive P and Q, we consider the decompo-

sition of A0. A0 is a choice between a1 and c2 at the dif-ferent nodes. We must add the polling messages. The partsof the protocol specification corresponding to a1 and c2 atnode 1 are “a1; send1!a1” and “rec1!c2”, respectively andthe parts of the protocol specification corresponding to a1

and c2 at node 2 are “rec2!a1” and “c2; send2!c2”, respec-tively. Therefore, the intermediate behavior expressions cor-responding to A0 are the following.

P = a1; send1!a1; P1[]send1!poll;(rec1!c2; B[]rec1!poll; P)

Q = rec2!a1; Q1[]rec2!poll;(c2; send2!c2; B[]send2!poll; Q)

Next, we consider the decomposition of A1. A1 is achoice between b2 and c2 at the same node. We do notneed to add the polling message. The parts of the proto-col specification corresponding to b2 and c2 at node 1 are“rec1!b2” and “rec1!c2”, respectively, and the parts of theprotocol specification corresponding to b2 and c2 at node 2are “b2; send2!b2” and “c2; send2!c2”, respectively. There-fore, the intermediate behavior expressions correspondingto A1 are the following.

P1 = rec1!b2; P2[]rec1!c2; BQ1 = b2; send2!b2; Q2[]c2; send2!c2; BNext, we consider the decomposition of A2. A2 does

not include choice. So, the intermediate behavior expres-sions corresponding to A2 consist of only the actions relatedwith c2 as follows.

P2 = rec1!c2; BQ2 = c2; send2!c2; BFinally, we get the intermediate behavior expressions

P and Q by substituting P2 and Q2 for P1 and Q1 respec-tively, and by substituting P1 and Q1 for P and Q respec-tively. Namely, when we execute the disabling composition,we convert the expression of disabling composition into an-other one consisting of only the choice operators, then wederive P and Q, and we compose P and Q finally. �

[Method 4]When we execute the disabling composition, we con-

vert the expression of disabling composition into anotherone consisting of only the choice operators, then we deriveP and Q, and finally compose P and Q.

P1 and P2 shown below are derived from the servicespecifications S 1 and S 2 by applying the Langerak’s de-composition algorithm without polling messages.

P1 = (E1 ||| E2) |[send1, rec1, send2, rec2]|


MediumP2 = (F1 ||| F2) |[send1, rec1, send2, rec2]|

Mediumwhere the correspondence of entities is shown below.

E1 and F1 are entities at node1.E2 and F2 are entities at node2.Based on the premise mentioned above, we execute the

disabling composition of the services and the protocols asfollows.Service: S 1 [> S 2Protocol: (P ||| Q) |[send1, rec1, send2, rec2]| Medium

The intermediate behavior expressions P and Q are de-rived by repetition of the procedure shown below.

If InitM(E1) ∪ InitM(F1) ⊆ ActR(N1) orInitM(E1) ∪ InitM(F1) ⊆ ActR(N2)then P = InitM(E1); (Der(E1)[> F1)[]F1

else P = InitM(E1); (Der(E1)[> F1)[]send1!poll; (F1[]rec1!poll; P)

If InitM(E2) ∪ InitM(F2) ⊆ ActR(N1) orInitM(E2) ∪ InitM(F2) ⊆ ActR(N2)then Q = InitM(E2); (Der(E2)[> F2)[]F1

else Q = InitM(E2); (Der(E2)[> F2)[]rec2!poll; (F2[]send2!poll; Q)

where Der(E1) [> F1 means executing this procedure onceagain with the substition of E1 by Der(E1), and Der(E2)[> F2 means executing this procedure once again with thesubstition of E2 by Der(E2).

The functions in this method are defined as follows.ActR(Ni) is the set of the actions which can occur at

node i and its notification actions related to these actions.InitM(E) is the set of the pair of the actions which can

occur at first in entity E and its transmission notification ac-tions, or the set of the receiving notification actions.

Der(E) is the set of the behavior expressions immedi-ately after the execution of the InitM(E). �

<Example of each function>If E = a1; send1!a1; rec1!b2; stopthen InitM(E) = {a1; send1!a1}

Der(E) = {rec1!b2; stop}ActR(N1) = {a1; send1!a1}ActR(N2) = {rec1!b2} �

5. Support System

The support system has five working stages; those are (i)entering service specifications (S 1 and S 2), (ii) the selectionof the composition operator, (iii) the decomposition, (iv) theresult of composition, and (v) LTS of composition, as shownin Fig. 9.

At the first stage, a user enters service specificationsthrough the service specification windows and may savethem as text files and reload them to specify again. Onedifferent point from LOTOS in an action prefix form is thata node number is put within “{}”. After the user enters S 1,the support system will check the syntax of expression basedon the LOTOS syntax. If S 1 has syntax errors, the support

Fig. 9 Flowchart of the support system.

system will show these errors. If S 1 has no errors, the sup-port system permits the user to enter S 2. Entering S 2 is thesame as the case of S 1.

At the second stage, the support system shows the com-position method window for the user to select the LOTOSoperator, which can be one of four types of composition op-erators.

At the third stage, the support system decomposes ser-vice specifications into protocol specifications automaticallyand shows the protocol specification window which includesprotocol specifications of S 1 and S 2.

At the fourth stage, the support system shows that thecomposition of the services and the composition of proto-cols are weakly bisimilar when notification actions (internalactions) are hidden. The support system provides the userwith the selection of another composition, the compositionof new services, or LTS.

At the last stage, if LTS is selected, the support systemwill show LTS of the composed services.

<Application example>We apply the proposed composition method and the supportsystem to construct service and protocol specifications forBulk Data Transfer part of the FTAM (File Transfer, Accessand Management) [9], [10] OSI Application Layer as an ex-ample for their evaluation.

FTAM has many services such as F-READ, F-WRITE,F-TRANSFER-END, F-DATA, F-CANCEL, etc. For thisapplication, we consider two alternative services of datatransfer in FTAM, i.e., F-READ and F-WRITE services.In FTAM service, there are two associated users, Initiatorand Responder. The Initiator requests a service from theResponder, and then the Responder replies to the request.After the Initiator executes an F-READ request (F-WRITErequest), the F-READ service (F-WRITE service) begins.

The F-READ service specifies a data transfer from theResponder at a node to the Initiator at another node. Thedata will be transferred until the transfer is completed. The


Responder executes an F-DATA-END request to inform theInitiator that the data transfer is completed. Then, the Initia-tor confirms the completion using an F-TRANSFER-ENDservice. After that, the F-READ service is finished.

Similarly, the F-WRITE service specifies a data trans-fer from the Initiator to the Responder. The data will betransferred until the transfer is completed. The Initiator exe-cutes an F-DATA-END request to inform the Responder thatthe data transfer is completed. Then, the Initiator confirmsthe completion using an F-TRANSFER-END service. Afterthat, the F-WRITE service is finished.

The LTSs of the F-READ and F-WRITE service spec-ifications are shown in Fig. 10. The F-READ service willstart when a read request signal (F-Rd_Req1) is issued, andthe F-WRITE service will start when a write request sig-nal (F-Wt_Req1) is issued. At first, the support systemshows the asynchronous protocol model to the user as shownin Fig. 11. The user just puts the F-READ and F-WRITEservice specifications into the support system as shown inFig. 12. Then, the support system will ask the user to se-lect one of the four composition operators (choice, enabling,parallel and disabling) as shown in Fig. 13. The user selectsthe choice operator because the two services are composedalternatively. Then, as shown in Fig. 14, the protocol speci-fication is automatically derived (composed) from the com-posed service specification, in accordance with the compo-sition method. Finally, it is displayed that the composedservice specification and the composed protocol specifica-tion are weakly bisimilar when the notification actions arehidden, as shown in Fig. 15.

Fig. 10 (a) LTS of F-READ service (S1) and (b) LTS of F-WRITE ser-vice (S2).

Fig. 11 Display of asynchronous protocol model.

Fig. 12 (a) Input of service specification S1 and (b) Input of service spec-ification S2.

Fig. 13 Selection of a composition operator.

Fig. 14 Derived protocol specification.

Fig. 15 Composition result.


Similarly, other services such as F-TRANSFER-ENDand F-CANCEL can be also composed, and the correspond-ing equivalent protocol specification can be derived, usingthe proposed composition method and the support system.

Finally, it is noted that protocol specifications derivedby applying the proposed method are somewhat complexsince they contain some redundant polling messages. How-ever, as suggested in Sect. 4.2, they could be removed(though it is one of our future works), thereby relaxing theproblem of efficiency.

6. Related Work

We briefly describe some closely related work in this sec-tion.

In [3], service and protocol specifications, which per-form a several kind of functions, are combined together. Theapproach considers synchronous communication model,i.e., the communicating entities reside in the same system.Unlike the present work, they do not consider entities resid-ing in different locations, i.e., the asynchronous communi-cation model.

There are studies similar to the present work, but theydiffer in approach and purpose. References [4] and [5] pro-pose approaches to derive the specification of n protocol en-tities from a service specification. This is basically a speci-fication transformation but not specification integration andtransformation. Unlike our approach, any addition of a com-ponent service specification cannot be handled.

The authors in Ref. [6] propose a method to derive pro-tocol specification from service specification using the de-composition but this approach becomes difficult when manyfunctions and behaviors of service specifications and proto-col specifications have to be considered simultaneously.

Reference [7] proposes a compositional approach inwhich sub-function protocols are designed independentlyand are combined together to obtain a composite protocol.This approach considers only protocol specifications but notservice specifications. What kind of service will be providedis not clearly mentioned. The approach is based on Commu-nicating Finite State Machine (CFSM).

Reference [8] discusses sequential, recursive and alter-native composition of component service specifications toobtain an integrated service specification. The protocol isderived from the integrated service specification using tran-sition synthesis rules. The specifications are modeled inCFSM. This approach has two steps: (a) composition ofservice components and then (b) transformation of the inte-grated service specification to a protocol specification con-taining two entities. Our approach is a single step approach;the composition of service specifications only. The proto-col specification is automatically derived when the servicespecifications are combined together. In [8], after obtain-ing the integrated service specification by combining com-ponent service specifications, the integrated service specifi-cation is further modified in order to avoid any logical er-rors (unspecified reception and deadlock) in derived pro-

tocol specifications. We believe that the functionalities ofservice components should be maintained in the integrated(composed) service specification. Any modification, if re-quired, should be introduced in lower level or transformedspecifications, e.g., in protocol specifications. In our com-position method, the component service specifications andthe composed (integrated) service specification are not mod-ified, thus maintaining the functionalities of given compo-nent service specifications in the composed service specifi-cation.

7. Conclusion

We have proposed composition method of service and pro-tocol specifications, for four composition types called en-abling, parallel, choice, and disabling, which are LOTOSoperators, for the asynchronous communication model in-volving two SAPs (two nodes). In our previous method [3],only the synchronous model was used. However, the asyn-chronous model is more suitable in the practical commu-nication networks. By applying this composition method,a good design of services and protocols has been achievedand we have developed its support system.

Because there are many redundant polling messages incomposed (derived) protocol specifications, future work willinvolve the optimization of redundant polling messages.

Acknowledgments

A part of this research was supported by JGN-2 project andResearch Grant of Kiban (B): No.6300011 from Ministry ofEducation, Science and Culture, Japan.

References

[1] ISO, “Information processing systems—Open systems inter-connection-LOTOS-A formal description technique based on thetemporal ordering of observational behavior,” ISO 8807, 1989.

[2] R. Langerak, “Decomposition of functionality: A correctness pre-serving LOTOS transformation,” in Protocol Specification, Testingand Verification, pp.203–218, 1990.

[3] B.B. Bista, K. Takahashi, and N. Shiratori, “A compositional ap-proach for constructing communication services and protocols,”IEICE Trans. Fundamentals, vol.E82-A, no.11, pp.2546–2557, Nov.1999.

[4] G. Bochmann and R. Gotzhein, “Deriving protocol specificationfrom service specification,” Proc. SIGCOMM’86, vol.14, pp.144–156, 1986.

[5] C. Kant, T. Higashino, and G.V. Bochmann, “Deriving protocolspecifications from service specifications written in LOTOS,” Dis-tributed Computing, vol.10, no.1, pp.29–47, 1996.

[6] A. Khoumsi and K. Saleh, “Two formal methods for the synthesisof discrete event systems,” Computer Networks and ISDN Systems,vol.29, no.7, pp.759–780, 1997.

[7] H.A. Lin and C.L. Tarng, “An improved method for construct-ing multiphase communications protocols,” IEEE Trans. Comput.,vol.42, no.1, pp.15–26, 1993.

[8] M. Nakamura, Y. Kakuda, and T. Kikuno, “On constructing com-munication protocols from component-based service specifications,”Comput. Commun., vol.19, pp.1200–1215, 1996.


[9] ISO, “File service definition: File transfer, access and management— Part 3,” ISO 8571-3, 1989.

[10] ISO, “File protocol definition: File transfer, access and management— Part 4,” ISO 8571-4, 1989.

Noppadol Maneerat received the B.Sc. de-gree in Physics from Srinakharinwirote Univer-sity, Pitsanuloke, Thailand in 1990, the M.Eng.degree in Electrical Engineering from KingMongkut’s Institute of Technology Ladkrabang(KMITL), Bangkok, Thailand in 1997. Heis now an engineer in the Information Systemand Quality Assurance Division, Computer Re-search and Service Center, KMITL. He is cur-rently working toward the D.Eng degree at Fac-ulty of Engineering, KMITL. His current re-

search interests are protocol design, concurrent system design, computercommunication network, wireless communication and analog-digital com-munications.

Ruttikorn Varakulsiripunth received theB.E. degree in Electrical and Electronics fromKyoto University, Kyoto, Japan in 1978. He ob-tained his M.E. and Ph.D. degrees in Electricaland Communication Engineering from TohokuUniversity, Sendai, Japan in 1983 and 1986, re-spectively. He is now an associate professor inthe Department of Electronics, Faculty of Engi-neering, King Mongkut’s Institute of Technol-ogy Ladkrabang, Bangkok, Thailand. His cur-rent research interests are concerned with com-

puter communication network including switching system, queueing anal-ysis, flow and congestion control, multimedia communication, wirelesscommunication, image processing and natural language processing.

Bhed Bahadur Bista received the B.Eng.degree in Electronics from University of York,England in 1991 and the M.S. and Ph.D. de-grees in Information Science from Tohoku Uni-versity, Japan in 1994 and 1997 respectively. Heworked as a research associate at Miyagi Uni-versity from April 1997 to March 1998. Atpresent, he is an associate professor in Facultyof Software and Information Science, Iwate Pre-fectural University, Japan. His current researchinterests are protocol specification and synthe-

sis, and formal description techniques. He is a member of IPSJ and IEEE.

Kaoru Takahashi received the Ph.D. degreefrom Tohoku University in 1992. From 1993to 1995, he was a senior visiting researcher inthe Advanced Intelligent Communication Sys-tems Laboratories. He is now a professor in theDepartment of Information and CommunicationEngineering, Sendai National College of Tech-nology. Currently, he is doing research on dis-tributed systems design, Semantic Web, networksecurity and so on. He received the 25th An-niversary Memorial Prize-Winning Paper Award

of IPSJ (Information Processing Society of Japan) in 1985, the 6th Telecom-munication Advancement Foundation Incorporation Award in 1991, andthe Information Network Research Award of IEICE in 1997. He is a mem-ber of IPSJ.

Yasushi Kato is currently a professor andthe chairman in the Department of InformationEngineering, Sendai National College of Tech-nology. His research interests include concur-rent systems design, Semantic Web, multi-agentsystem, micro-ITRON based embedded systemand education method for digital technology.He received the Ph.D. degree in Electrical andCommunication Engineering from Tohoku Uni-versity, Sendai in 1978. He had been a visitingresearcher at Twente University, the Netherlands

from 1995 to 1996 and had engaged in the research on formal descriptiontechniques. He received the achievements award of JSEE (Japanese Societyfor Engineering Education) in 1994. He is a member of IPSJ (InformationProcessing Society of Japan) and JSEE. He is also a senior visiting advisorof Miyagi, Fukushima and Iwate Prefectural Institute of Technologies.

Norio Shiratori was born in Miyagi Pre-fecture, Japan, on May 11, 1946. He receivedthe B.E. degree from Tokai University, Tokyo,in 1972, and the M.E. and Ph.D. degrees in Elec-trical and Communication Engineering from To-hoku University, Sendai, in 1974 and 1977, re-spectively. He has joined RIEC (Research Insti-tute of Electrical Communication), Tohoku Uni-versity, Sendai, since 1977, and he is now aProfessor of Computer Science at RIEC of To-hoku University. Professor Norio Shiratori re-

ceived the 25th Anniversary of IPSJ Memorial Paper Award in 1985, the6th Telecommunications Advancement Foundation Incorporation Award in1991. He was awarded the Best Paper in ICOIN-11 and ICOIN-12 in 1997and 1998, respectively, and also the IPSJ Best Paper Award in 1997, andthe Best Paper Award of ICPADS in 2000. He has been named a Fellow ofthe IEEE for his contributions to the field of computer communication net-works since 1998. He has also received the IPSJ Fellow and IEICE Fellowsince 2000 and 2002, respectively.

composition of service and protocol speciﬁcations in ... · pdf filecomposition of service...

Documents