This work is based on three fundamental observations:
Within this general framework, this paper focuses on classes of messages, e.g., in an e-commerce application, the message classes might include, ``invoice'', ``receipt'', ``acknowledgment'', etc. We study the case where the peers are represented by Mealy machines (finite state machines with input and output). The sets of conversations exhibit unexpected behaviors. For example, there exists a composite e-service based on Mealy peers whose set of conversations is not regular nor context free. The set of conversations is shown to be context sensitive. One cause for this is the queuing of messages; we first introduce an operator ``prepone'' in an attempt to simulate queue delays. Although the set of conversations of each composite e-service with Mealy peers is closed under prepone, we illustrate that prepone does not completely capture the queue delay effects. We refine the prepone operator to a ``local'' version which applies to conversations by individual peers. Another aspect of the composite e-service is that decisions are only made by individual e-services possibly with communications with each other. This means that each e-service sees only a ``local'' view of the global conversation. Consequently, Mealy implementations in the composite e-service will also include conversations that whose ``projections'' to individual e-services are consistent with the local e-services. We use projection-join closure to capture such situations. This is reminiscent of the decomposition and join in the relational databases. However, there are still Mealy peers whose set of conversations is not prepone and projection-join closure of any regular language. Therefore we propose conversation specifications as a formalism to define the conversations allowed by an e-service composition.
In this paper we present two technical results concerning the interplay between the local behaviors of Mealy peers and the global behaviors of their compositions. One result shows that for each regular language its local prepone and projection-join closure corresponds to the set of conversations by some Mealy peers effectively constructed from . The second result gives a condition on the shape of a composition which guarantees that the set of conversations that can be realized is the local prepone and projection-join closure of a regular language.
The paper is organized as follows. Section 2 presents a formal framework
for studying composite e-services. Sections 3, 4, and 5 present some preliminary
results that focus on an abstract view of the formal framework based on
the classes of messages passed between e-services and finite state automata;
results here illustrate the unexpected nature of the interplay between
local and global in composite e-services. Section 6 concludes the paper.
A fundamental observation is that an e-service (1) provides services through ``service sessions'' and (2) reacts to ``events'' during a session, although the implementation of an e-service may be very complex. Fig.1 illustrates an abstraction of an e-service (called here a peer) as a program that processes the input events from an input queue and determines the response if any (in the form of outgoing events) and termination. For the present we make no assumptions about the computational power of a peer, nor how much storage it has.
Events form the enabling mechanism in composing e-services. In this paper, we focus on an important kind of event--``messages'' between the individual e-services. Messages are organized into a finite collection of ``message classes'' (each message is in exactly one class). Message classes can be used to simplify and organize the specification of actions. A message class consists of a name and a finite set of attributes. A message of a class consists of an identifier of an e-service enactment (session), an identifier for the message itself, the sender, the receiver, and a function mapping each attribute of to a value (of appropriate type).
``11-1-2002'', ``$2,500'', 43-56483, .
Roughly, a peer implementation can be viewed as a ``program'' that decides, based on the received messages and the messages already sent, if a new message should be sent, and/or if the session should terminate. AZTEC  classifies e-services into two types: (1) Discrete e-services that do not allow interactions during the service, and (2) Interactive e-services that allow arbitrarily many interactions during the service, such as VCR type of controls during a session. A discrete e-service can be viewed as a service whose output depends only on the original input, while in an interactive e-service inputs can be unpredictable and the e-service reacts to input as they occur. AZTEC  emphasizes the importance of interactive e-services in the context of telecommunications applications, but they are also relevant in the context of e-commerce. A single occurrence of ordering a book can be modeled using discrete e-services. But in many cases a vendor wants to track the entire relationship with a customer, and perhaps modify customer treatment accordingly (e.g., frequent flier programs). In this case, some of the e-services used are fundamentally long-running and interactive.
We now start to lay the foundation for a formal study of global behavior of composite e-services. The first step is to formalize the notion of a ``schema'' for a composite e-service.
DEFINITION. An e-composition schema (ec-schema) is a triple , where is a finite set of message classes, a finite set of (abstract) peers (e-services), and is a finite set of one-way communication channels, 1 i.e., is a finite set of triples such that, , , and for each pair of channels and in, if and , then ; otherwise, .
be an ec-schema. In a channel ,
is the sender and
the receiver of the channel, and only messages in classes in
are allowed to be sent on the channel. We fix the following notations in
the remainder of the paper. For each peer,
denote the sets of (classes whose) messages may be put in the input queue
and in the output by,
. Finally, let
be an ec-schema and .
A (peer) implementation of
is a computable function which maps a sequence of incoming and outgoing
messages (a word over)
is a mapping
such that for each,
is an implementation of .
The e-service implementation described above is very general. In the following sections, we introduce a specific type of implementations based on Mealy machines and study the global behavior of a composition and the local behaviors of individual e-services.
In the technical discussions, we consider a special family of implementations called ``Mealy implementations'' (or ``Mealy peers'') based on Mealy machines . There are two primary reasons. First, Mealy machines are a variant of finite state machines and seem suitable for modeling e-services. Second, Mealy implementations make it possible to analyze some aspects of the global behavior. As we shall see, our preliminary results suggest a ``top-down'' approach to e-service compositions and raise many interesting questions.
denote the empty string. If
is an alphabet, we define
(the extended alphabet with the empty string).
be an ec-schema and .
A Mealy implementation of
is a (nondeterministic) Mealy machine
is a finite set of states,
the starting state,
a set of final states,
are derived from
as before, and
is a transition function such that it either consumes a nonempty input
or produces a nonempty output but not both (empty moves are allowed). An
ec-implementation is Mealy if its peer implementations are all Mealy.
A Mealy implementation of a peer reacts to messages according to their
classes while ignoring the contents. Although Mealy implementations are
finite state machines, they can model e-services in many applications nicely.
This is illustrated by Example 2.1, where the message
classes effectively dictate the actions to be taken by each server and
consequently the responses.
Example 3.1Fig. 4 shows a family of Mealy peer implementations for the warehouse example of Example 2.1. (The implementation for Warehouse2 is analogous to the implementation for Warehouse1.) In these diagrams, we use ``'' (``'') to denote sending (receiving) a message from class . It can be verified that the ec-language generated by this Mealy implementation
We now define the notion to capture the computation of ec-implementations.
Let be an ec-schema where . Suppose that is a Mealy ec-implementation for . An ec-configuration of is a -tuple of the form
For ec-configurations and , we say that if one of the following three conditions holds:
DEFINITION. Let be an ec-schema where and a Mealy ec-implementation of. A word over is a (halting) conversation for if
While Mealy peers resemble I/O automata  and interface automata [6,5], the communication model is different. In our composition model, Mealy peers communicate asynchronously. Specifically, a queue is used for each peer to buffer messages that were received but not processed so far. In approaches such as CSP , and I/O and interface automata, the communicating processes execute a send and a corresponding receive action synchronously. This makes Mealy implementations significantly different from the communication model used in approaches such as CSP, I/O and interface automata. Our model of Mealy peers is similar to Communicating Finite State Machines defined in . However, in our model messages are exchanged through a common medium and then stored in the queues of the peers, whereas in  each pair of communicating machines use isolated communication channels. Our goal is to investigate the global behavior of the protocol by investigating the possible configurations of the watcher which models the behavior of this common medium. Finally,  studies ``quasi-realtime'' automata with queues. These are single automata with one or more queues, where an automaton can write a bounded number of letters on the queue(s) for each input letter read. In  the input and queue alphabets maybe different; in our framework the alphabets are identical.
Example 4.1Figure 5 shows a Mealy implementation with two peers. Peer sends requests while responds with a message for each message. Since messages can be temporarily stored in the queue of , the ec-language consists of words with the same number of 's as's and each has a corresponding that occurs somewhere beforehand. Note that . Therefore is not regular (but it is context free).
Using an idea similar to that in Example 4.1,
one can easily construct a Mealy ec-implementation whose ec-language is
not regular nor context free but context sensitive. However,
THEOREM 4.2Let be an arbitrary Mealy ec-implementation of any ec-schema.
We now return to the phenomenon exposed by Example 4.1. A close examination indicates that the primary reason for this behavior is that the message queue of a peer serves as a ``buffer'' for the input: while conversations monitor the arrival of messages at the queues the messages may not be read right away. To understand this effect, we introduce the operator PREPONE on the alphabet of an ec-schema as follows.
Let be a word in, where is in the set of messages on the channel from to and in the set of messages on the channel from to. If either (1) and are disjoint, or (2) and , then includes the word . Intuitively, the operator PREPONE allows two messages in a conversation to be swapped if the senders and receivers are completely disjoint, or a later message to a peer can arrive in the queue earlier than an outgoing message from the peer since the outgoing message cannot depend on a later arrived message.
It is important to note that PREPONE applies to the global sequence of messages observed by the watcher. We will exhibit later in the section that is not strong enough to characterize the behaviors of Mealy ec-implementations.
If is a language over, we define to be the smallest language that contains and is closed under . The following interesting property holds for .
LEMMA 4.3For each Mealy ec-implementation of an ec-schema, (closure under PREPONE).
Since the set of context-sensitive languages does not have the closure property, the following holds.
COROLLARY 4.4 There is a context-sensitive language such that for any Mealy ec-implementation .
The second property of ec-languages concerns with combining ``local views'' of conversations into global conversations, this is reminiscent of the join operator in the relational database model.
Example 4.5 Consider an ec-schema that has four peers , and three channels , , and . Is there any Mealy ec-implementation that generates the regular language ? Note that the peer groups and are in fact independent; there is no communication possible between them. It can be shown that any Mealy ec-implementation that generates also generates each of , and.
The above example suggests that if two global behaviors have exactly the same local views, they are indistinguishable. We formalize this concept below.
The definition of given for Mealy ec-implementations has the effect of generating words. We now define a kind of converse for individual Mealy peer implementations, which has the effect of consuming words. Let be a Mealy implementation for a peer . Let . A local (l-)configuration of is is a triple . In an l-configuration , is the current state of the peer , is the sequence of messages in the input queue of , is a sequence of ``future messages'' including the incoming messages not yet in the queue of and the messages to be sent out by (i.e., represents the remaining portion of a conversation projected to the messages visible to ).
We define for a pair of l-configurations and if one of the following holds for some and some :
Let . A local (l-)run of is a (finite) sequence of l-configurations () such that for . A word in the language is a (halting) execution of if for some (final) state .
For word and peer, let denote the restriction of to the set ().
LEMMA 4.6Let be a Mealy ec-implementation of an ec-schema . Let. If for each peer, is a (halting) execution of , then is a (halting) conversation for . The converse is also true.
PROOF (Sketch) Let be a word over . We outline a proof for the direction ``if projection of to each peer is a (halting) execution, then is a (halting) conversation''. The converse is trivial.
Without loss of generality, we assume that the ec-schema has peers . Since for each peer , the projection is a local execution, there exists a corresponding l-run for . We show that is a (halting) conversation by constructing an ec-run that simulates each . The construction has phases. Phase 0 is the initialization phase where we simulate in the global ec-run the initial-moves of each until it advances to an l-configuration that is ready to do a send-message action or an enqueue-message action. Then in each phase , we simulate the transmission of message, where only the sender and receiver of are involved. We start with the sender of . We execute the send- action, and its follow-up actions such as-moves and consume-message actions, until we encounter an enqueue-message or send-message action on a message where . Then we turn to the receiver of , execute the enqueue- action and the follow-up actions until an action related to a later message is reached.
We can prove the correctness of the above process by an induction on the number of phases. Specifically, it can be shown that (1) after the completion of phase , the l-run of each peer has been simulated right before the last l-configuration which contains the future messages , and (2) the simulation can always proceed. It follows that the last global ec-configuration is consistent with the last l-configuration for every .
Now we define the join operator which takes as input a sequence of languages where each is a set of words for peer , and is the number of peers in the ec-schema. It returns a language over .
LEMMA 4.7For each Mealy ec-implementation of an ec-schema with peers, .
Given a language over , let denote the minimal superset of that is closed under and. From Lemmas 4.3 and 4.7, we can infer that for each Mealy ec-implementation , the following holds:
Essentially, this states that any Mealy ec-implementation that generates the behavior set must also generate its closure. One interesting question is given, is it always possible to synthesize a Mealy ec-implementation such that ?
The answer unfortunately is negative. Consider the following example.
Example 4.8Shown in Figure 6 is an ec-schema that consists of three peers and three channels. The language , and it is obvious that .
If is recognized by, consider the scenario that takes the local execution path and takes the path . It is not hard to see that is a conversation since sends while having in its input queue. Thus .
One reason that the cannot be the set of conversations by some Mealy ec-implementation is that applying to (global) conversations is too weak. Consider the projection of the conversation on in Example 4.8. If it is not accepted by , it must be the result of applying one or more ``prepone'' like swaps on an accepted word. For example, swap the sequence of output message and input message, we get from . Note that this type of swap differs from since the former is applied locally instead of globally. Secondly, we allow the receiver of the first message and the sender of the second message to be the same, which is forbidden in . We call this type of swap a local prepone defined below. For each peer , if
Using local prepone operators and , we define for each language over the ec-closure of as follows.
Now let us consider the inverse of the synthesis problem. Given a Mealy ec-implementation , can we find a regular language as its core? The following example provides a negative answer.
Example 4.9Consider an ec-schema shown in Figure 7 consisting of 3 Mealy peers, and 3 channels. Intuitively, sends, say messages of class , to, a message to , and then halt; responds to each message by send a message to ; expects at the beginning and then consumes all messages. It is not hard to see that the only way for to halt is for to keep all messages in its queue till after sends to . Thus is its ec-language. It can be shown that each subset of satisfies the following property
PROPOSITION 4.10There exists a Mealy ec-implementation such that for each regular language .
DEFINITION. Let be an ec-schema. A conversation specification for is a specification (e.g., by regular expression, finite state automaton, intertask dependencies, etc.) of a language over . The language specified by is denoted. Let be a conversation specification. An ec-implementation of conforms to if is contained in the ec-closure of, and realizes if the ec-closure of.
We are interested in the following question: For a conversation specification ,
can we construct a (Mealy) ec-implementation
that realizes ?
The main result of the section is to show that the answer is positive.
THEOREM 5.1For every regular language , one can effectively construct a Mealy ec-implementation that realizes.
We now discuss the proof of the above theorem. The proof consists of the following main steps. First, we construct a finite state automaton that accepts. From , we construct, for each peer , a Mealy implementation . This construction is essentially a projection: replace all edges in that are irrelevant to channels connected to by moves, change edges of messages sent to as input, and finally edges of messages sent by as output. To prove that the composition of the implementation generates exactly, we have to show that
LEMMA 5.2Let be a Mealy implementation for peer . A word is a halting execution if and only if .
PROOF (Sketch) We prove by induction that is a sufficient condition for being a local execution. In the induction proof it suffices to show the claim that if a word is contained in for some local execution , is also a local execution. The proof of the claim is straightforward, because we can always construct an l-run for by modifying the l-run of.
Next we show that is a necessary condition. We show that for any halting execution, we can always find such that , by applying ``reverse prepone'' procedure finitely many times. We briefly describe the procedure below. Consider the l-run of the local execution . Let be the first send-message action such that input queue is not empty, i.e., . It is not hard to show that can be written as , where includes those eagerly processed messages before the arrival of any message in. Now let , we can show that and is also a halting execution. Repeat the above procedure, until we cannot find a send-message action with a non-empty queue, then we get a list where, , and for each , . The last word is the we are looking for.
Lemma 5.2 implies the following corollary.
COROLLARY 5.3Given a Mealy ec-implementation for an ec-schema . The conversation set generated by is the following:
DEFINITION. Let be an ec-schema. Let be the non-directed graph where
PROPOSITION 5.4 Let be a tree-based ec-schema and a Mealy implementation for . Then for some regular language .
PROOF (Sketch) First we extend the notion of conversation to indicate when messages are read from an input queue, in addition to when messages are written onto the input queue. Let . A read-augmented conversation of implementation is a word over the alphabet that corresponds to a computation over , where each occurrence of a letter corresponds to a time when letter was read from a peer's input queue. Given such a , denotes the projection of onto the alphabet.
Now let and be as in the statement of the proposition. A key lemma is to show that if is a read-augmented conversation of corresponding to a halting computation, then there is a read-augmented conversation of such that and has the immediate read property, that is, for each occurrence of occurring in there is an occurrence of immediately following in . The key idea of the proof is that since is tree-based, entire blocks of a computation occurring in one ``part'' of the tree (if partitioned by removing ) can be ``delayed'' or ``accelerated'' so that a message is not put onto the queue of peer until is ready to read that message.
From the above key lemma, we learn that each halting conversation is contained in for some word , where satisfies the following condition: for each peer, the projection is accepted by. Let , it is not hard to show that is a regular language, and . Let be the Mealy ec-implementation generated from the projection of to each peer. It is easy to infer that . Combined with the known fact that
Acknowledgment: Bultan was supported in part by NSF grant CCR-9970976 and NSF Career award CCR-9984822; Fu was partially supported by NSF grant IIS-0101134 and NSF Career award CCR-9984822; Su was also supported in part by NSF grants IIS-0101134 and IIS-9817432.
 The 3rd generation partnership project 2. http://www.3gpp2.org.
 A dynamic warehouse for XML data of the Web.IEEE Data Engineering Bulletin, 2001.
 Relational transducers for electronic commerce. In Proc. ACM Symp. on Principles of Database Systems, 1998.
 Interface automata. In Proceedings of the Ninth Annual Symposium on Foundations of Software Engineering (FSE'01), pages 109-120, 2001.
 Interface theories for component-based design. In Proceedings of the First International Workshop on Embedded Software (EMSOFT '01), Lecture Notes in Computer Science 2211. Springer-Verlag, 2001.
 The scala home page. http://lamp.epfl.ch/scala/.
 DAML-S: Web service description for the semantic web. In Proc. Intl. Semantic Web Conf. (ISWC), July 2002.
 Self-coordinated and self-traced composite services with dynamic provider selection. Technical report, University of New South Wales, March 2001. (Available at http://sky.fit.qut.edu.au/ dumas/selfserv.ps.gz).
 Quasi-realtime languages.Mathematical Systems Theory, 4(2):97-111, 1970.
Business process execution language for web services (version 1.0).http://www.ibm.com/developerworks/library/ws-bpel, 2002.
 On communicating finite-state machines.Journal of the ACM, 30(2):323-342, 1983.
 C-commerce virtuality - will it work in the Internet? In Proc. of International Conf. on Advances in Infrastructure for Electronic Business, Science, and Education on the Internet (SSGRR 2000), 2000. (http://www.ssgrr.it/en/ssgrr2000/proceedings.htm).
Proceedings of Workshop on Web Services, E-Business, and the Semantic Web (WES). Springer-Verlag Lecture Notes in Computer Science, number 2512, Toronto, 2002.
 Developing e-services for composing e-services. In Proceedings of CAISE 2001, Interlaken, Switzerland, June 2001.
 Dynamic and adaptive composition of e-services.Information Systems, 26(3):143-163, 2001.
 Beyond discrete e-services: Composing session-oriented services in telecommunications. In Proc. of Workshop on Technologies for E-Services (TES), Rome, Italy, September 2001.
 Detecting changes in xml documents. In Proc. Int. Conf. on Data Engineering, 2002.
 XL: An XML programming language for web service specification and composition. In Intl. World Wide Web Conf. (WWW2002), 2002.
 Types for correct communication in client-server systems. Technical Report CSD-TR-00-07, Department of Computer Science, Royal Holloway, University of London, December 18 2000.
 Communicating sequential processes.Communications of the ACM, 21(8):666-677, 1978.
22Introduction to Automata Theory, Languages, and Computation. Addison Wesley, 1979.
 Hierarchical correctness proofs for distributed algorithms. In Proc. 6th ACM Symp. Principles of Distributed Computing, pages 137-151, 1987.
 Semantic web services. In IEEE Intelligent Systems, March/April 2001.
 Simulation, verification and automated composition of web services. In Intl. World Wide Web Conf. (WWW2002), 2002.
Simple object access protocol (soap) 1.1. W3C Note 08, May 2000. (http://www.w3.org/TR/SOAP/).
 Session initiation protocol. http://www.sipforum.org.
This document was generated using the LaTeX2HTML translator Version 2002 (1.62)
Copyright © 1993, 1994, 1995, 1996,
Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.