Compositional Construction of Web Services Using Reo
Nikolay Diakov, Farhad Arbab
Dutch National Research Institute for Mathematics and Computer Science (CWI),
P.O. Box 94079, NL-1090 GB Amsterdam, The Netherlands
Abstract. A Web Service can represent a unit of business logic that an organi-
zation exposes to other organizations on the World Wide Web. The recent ef-
forts of the industry to agree on a common definition for Web Services resulted
in the Web Services (WS) standard that governs how one defines, advertises
and uses Web Services. Composition of primitive Web Services into complex
ones presents the next challenge for the industry. Existing proposals for lan-
guages for service composition (also called choreography of Web services)
typically come from the business process modeling community and often lack
foundations in theoretical computer science and possibilities to address compo-
sition from a more general perspective than business process applications only.
In this paper we present our work-in-progress on compositional construction of
Web Services using the Reo coordination language. The Reo language has a
strong formal basis and promotes loose coupling, distribution, mobility, exoge-
nous coordination, and dynamic reconfigurability. We carry out this work
within the context of the Cybernetics Incident Management (CIM) project.
1 Introduction
The main purpose of e-business consists of the automation of business processes
using software applications. Service-oriented computing focuses on describing the
externally observable behavior of such software applications. The Web Services
standard applies the ideas of service-oriented computing to the Web. A Web Service
represents a reusable piece of business logic that an organization can expose to other
organizations via the World Wide Web. Fig. 1 shows the organization of the main
ingredients of the WS standard [10] in a layered fashion.
Transport layer: H T T P , S M T P , e tc
XM L m essaging layer: SOAP
Service description layer: W S D L
Service
p u b lic a tio n /
discovery:
UDDI
Service
com position:
BPEL4W S,
WSCI, etc
Core W S
Fig. 1. WS layered architecture
Diakov N. and Arbab F. (2004).
Compositional Construction of Web Services Using Reo.
In Proceedings of the 2nd International Workshop on Web Services: Modeling, Architecture and Infrastructure, pages 49-58
DOI: 10.5220/0002666400490058
Copyright
c
SciTePress
The service transport layer has the responsibility for transporting messages between a
provider and a requestor of a Web Service. The XML messaging layer has the re-
sponsibility for the encoding of messages using a common XML format such as the
SOAP protocol [14], so that both sides can have a common understanding of the
structure of a message. The service description layer describes the public interface of
a Web Service using the Web Services Description Language (WSDL) [15]. Service
publication and discovery allows publishing and searching for Web Services using
the Universal Description, Discovery and Integration (UDDI) [16]. The SOAP,
WSDL, and UDDI specifications constitute the core of the WS standard. These speci-
fications have reached a mature state wherein many major software vendors have
committed to incorporating WS into the basic infrastructure of their products.
Automation of business processes across organizational boundaries has become a
recent trend in e-business. This trend reflects the need for explicit modeling of long-
running interactions and complex dependencies among different organizations. The
WS composition layer (Fig. 1) facilitates this need by allowing one to build new Web
Services out of simpler ones. At present, the industry has not agreed upon a common
specification for service composition. Business Process Execution Language for Web
Services (BPEL4WS) [17] and the Web Service Choreography Interface (WSCI) [18]
constitute two examples of candidates for a service composition specification stan-
dard.
Current proposals for a Web Service composition standard suffer from two major
types of problems [8]: (a) proposals often reflect some company interests in specific
domain issues, which makes them inadequate for treating more general problems in
service composition, and (b) proposals have operational semantic problems due to
their lack of a strong formal basis. These two problems contribute to the insufficient
expressive power of existing proposals in terms of a more theoretical perspective on
component composition (one can generally view Web Services as components). Fur-
thermore, it seems that current proposals for Web Service composition do not provide
sufficient expressive power to support coordination of distributed activities, for ex-
ample, as in transactions. We see this as the reason for the appearance of the WS-
Coordination [13] as a standardization activity that tries to fill this gap separately
from the composition of Web Services. The work described in this paper addresses
the problems we mentioned so far altogether using the Reo coordination language.
2 The Reo Coordination Language
Reo presents a paradigm for composition of software components based on the notion
of mobile channels. Reo enforces an exogenous channel-based coordination model
that defines how designers can build complex coordinators, called connectors, out of
simpler ones. Application designers can use Reo as a “glue code” language for com-
positional construction of connectors that orchestrate the cooperative behavior of
component instances in a component-based system. One can find an introduction to
Reo in [1], and a detailed elaboration on the language and its model in [2]. The Reo
coordination language provides, among others, the following features:
50
Loose coupling among components;
Support for distribution and mobility of heterogeneous components;
Exogenous coordination (i.e., by third parties);
Dynamic reconfigurability;
Formal semantics based on a coinductive calculus of flow [3] and (alternatively)
on constraint automata [4].
5.2 Basic concepts
Reo does not say much about the application components, whose activities it coordi-
nates. From the point of view of Reo, a system consists of a number of component
instances, communicating through connectors that coordinate their activities. Reo
assumes that a component instance contains one or more active entities (e.g., proc-
esses, agents, threads, actors, etc.), which communicate with entities outside of their
component instance only through input/output operations that they perform on a (dy-
namic) set of channel ends connected to the component instance. Reo completely
abstracts from the details of the communication within a component instance. Instead,
Reo focuses on the inter-component-instance communication, which takes place ex-
clusively through connectors.
Reo allows compositional construction of a connector out of simpler connectors,
where channels represent the atomic connectors. A channel has precisely two channel
ends. Reo introduces two types of channel ends: sink and source. A sink dispenses
data out of its channel. A source accepts data into its channel.
Reo models a connector as a graph of nodes and edges, where zero or more chan-
nel ends may coincide on every node, every channel end coincides on exactly one
node, and an edge exists between two nodes if and only if there exists a channel
whose channel ends coincide on those nodes.
When a component instance knows a channel end, any active entity inside it can
perform Reo operations on that channel end.
5.2 Reo operations
Reo defines the following operations, which relate to the manipulation of the connec-
tor topology: create, forget, join, split, and hide. The create operation creates a chan-
nel (of some defined type) and makes the channel ends available to the performer of
the operation. With the forget operation a component instance tells Reo that it does
not need a channel end anymore. The join operation allows joining of two nodes
identified by two channel ends, each coincident with one of the nodes. The split op-
eration allows for splitting a node into two nodes by specifying the channel ends that
the performer requires to coincide on the new nodes. The hide operation allows the
performer to protect the topology of a node designated by some coincident channel
end, making subsequent join and split fail on channel ends coincident with that node.
Reo defines the following operations, which allow input/output of data: connect,
disconnect, wait, read, take
, write, and move. The connect operation connects the
performer to a channel end by providing exclusive access to the node (and thus all
51
channel ends coincident with it) on which this channel end coincides. The disconnect
operation releases a previously established connection. The wait operation allows the
performer to wait for some condition on a channel end. The read operation allows the
performer to non-destructively read data from a sink. The take operation does the
same as read but it also removes the data from the sink. The write operation allows
the performer to write data to a source. The move operation allows the performer to
move a channel end to another location. Note that changing location does not change
the topology of the connector or the connection status of the moved channel end.
5.3 A useful set of primitive channels
Reo assumes the availability of an arbitrary set of channel types, each with well-
defined behavior. As an example, we present the following non-exhaustive set of
channel types, each with some distinctive properties: Sync, Filter, SyncDrain, Sync-
Spout, LossySync. A Sync channel has a source and a sink. Writing a message suc-
ceeds on the source of a Sync channel if and only if taking of a message succeeds at
the same time on its sink. The Filter channel behaves like the Sync except that it loses
all data that do not match the specified pattern of the Filter. A SyncDrain has two
sources. Writing a message succeeds on one of the sources of a SyncDrain channel if
and only if writing a message succeeds on the other source. A SyncSpout has two
sinks. A SyncSpout channel serves as an unbounded source of data that matches cer-
tain pattern on both of its sinks. A LossySync channel has a sink and a source. The
source always accepts all data items. If the sink does not have a pending read or take
operation, the LossySync loses the data item, otherwise the channel behaves as a
Sync.
3 Composing Web Services Using Reo
Consider an example in which some organization wants to offer a “Holiday Reserva-
tion Service” (HRS) that allows customers to organize holiday travels (Fig.2).
HOtel
Reservation
Service (HORS)
Flight
Reservation
Service (FRS)
Ca
r
Reservation
Service
(
CRS
)
Holiday
Reservation
Service (HRS)
A
E
Connector
Sync channel
Source channel end
B
F
C G
SyncDrain channel
Sink channel end
Fig. 2. Committing a transaction modeled with Reo
52
For simplicity, we assume that organizing a holiday requires making reservations for
a hotel, for a flight and for a car. Some other organizations offer services each doing
part of the job: hence the HORS, FRS and CRS services. Again for simplicity, we
assume that the HRS service has already negotiated with a client a selection of proper
flight, hotel and car. As the last thing before asking the customer to pay, the HRS
service needs to “commit” a transaction containing each of the reservations. Now, a
holiday reservation should only succeed when all other three reservations succeed.
We model the “commit” part of the behavior of the HRS service using a “barrier
synchronization” connector in Reo consisting of six synchronous channels and two
synchronous drain channels, organized together as in Fig.2.
The HRS service makes “commit” requests on channel ends A, B, and C in any or-
der and at times it needs to. According to the semantics of the barrier synchronization
connector, the three “commits” of the HRS system will succeed (the success condi-
tion for the holiday reservation) if and only if the three reservations at the HORS,
FRS and CRS services, respectively, succeed at the same time.
This example illustrates the ease with which Reo allows construction of connectors
that exhibit complex behavior such as transaction support. The simple composition
rules of Reo yield a surprisingly expressive power that enables the construction of
different types of communication infrastructures, such as peer-to-peer, shared data
space, software bus, etc., out of a very small set of primitive channel types [2], [11].
4 Reo Coordination Middleware
In order to use Reo for efficient construction of software applications such as Web
Services, we need to build a Reo coordination middleware.
A middleware coordinates the interactions among application components by pro-
viding functionality that bridges the gaps between software applications and the low-
level hardware and software [5]. A coordination middleware consists of system soft-
ware that provides a set of reusable common services and programming mechanisms
for coordination of component behavior. Coordination middleware simplifies the
development of distributed software applications by offering high-level abstractions
for programming of component compositions, conceptually closer to an application
model defined using a coordination language, than the low-level programming meth-
ods offered by most existing component middleware technologies.
Transport layer
Reo coordination layer
Reo component layer
Application layer
Fig. 3. Reo coordination middleware
53
We model a Reo coordination middleware as two separate layers between the trans-
port layer and the application layer (Fig. 3). The Reo coordination layer provides the
basic Reo functionality, such as basic channels and operations on their channel ends.
The Reo component layer provides the minimum services and tools necessary for
building, deploying and executing application components with Reo.
5 Reo-enabled Web Services
We consider Web Services as a class of software applications. In order to facilitate
this class with a Reo coordination middleware, we need to provide an additional ad-
aptation layer – the Reo WS layer (Fig.4). We do this in a layered fashion, because
we wish to allow the mutual coexistence of both Web Services and “pure” (non-Web
Services) Reo components.
Some transport layer
Reo coordination middleware
Reo WS layer
WS1
WS2
Composite
WS
Reo
connector
Fig. 4. Layered representation of a composite Web Service
The Reo WS layer effectively allows making a Reo component out of any Web Ser-
vice. This way Web Services can interact with Reo components and vice versa. Fur-
ther, we consider two ways to construct the Reo WS layer: (a) as an alternative trans-
port layer for the Web Services technology, and (b) as a collection of adapters. We
view these two approaches as complementary, because each has its own pros and
cons.
5.1 Reo Transport for Web Services
The WS standard separates the definition of messages exchanged with a Web Service
from the way the distributed environment communicates these messages to and from
a Web Service. We use this feature of the WS standard to define a Reo Transport For
Web Services – RT4WS (Fig. 5).
Some transport layer
Reo coordination middleware
Reo WS layer
WS1
WS2
Reo
connector
Reo Transport 4WS (RT4WS)
RT4WS Binding
Composite
WS
Fig. 5. Reo transport for Web Services
54
WS providers who choose the Reo coordination middleware need to select the
RT4WS for use with their Web Service. In order to do this in a generic way, the pro-
vider needs to use a special binding for the Reo transport. The RT4WS binding de-
fines how a provider sends messages with a particular transport (i.e., allows the pro-
vider to bind the service to the transport).
A Reo-enabled transport (potentially) allows for an efficient and transparent inte-
gration of the Reo middleware with an arbitrary existing Web Service. We regard the
fact that the provider must actually install the new transport in his infrastructure in
order to enable his Web Services for Reo as the main drawback of this approach.
5.2 WS Adapters for Reo
In the second approach we define two types of adapters (Fig. 6): Reo WS provider
adapters and Reo WS requestor adapters.
Some transport layer
Reo coordination middleware
Reo WS layer
WS1
WS2
Reo
connector
Reo WS
provider
adapter
Reo WS
requestor
adapter
Composite
WS
Fig. 6. Reo adapters for Web Services
The Reo WS provider adapter mediates all communication between the Reo coordi-
nation middleware and a Web Service. Effectively, the Reo WS provider adapter
appears to a Web Service as a typical WS requestor using one of the transports origi-
nally supported by the Web Service to make requests to the Web Service. On the
other hand, the Reo WS provider adapter appears as a special Reo component that
offers the functionality of the Web Service to other Reo-enabled Web Services or
“pure” Reo components. In a similar way, the Reo WS requestor can connect to a Reo
WS provider adapter, and appears to a typical WS requestor as a normal Web Ser-
vice. This allows a requestor (e.g., a composite Web Service) to use other Reo-
enabled Web Services or “pure” Reo-components as if they behaved as “normal”
(non-Reo-enabled) Web Services. Effectively, both adapters play the role of addi-
tional tiers between a service provider and a service requestor that enable their inter-
action with a Reo-enabled infrastructure provided by the Reo coordination middle-
ware.
Providers of Web Services need not do anything to allow their Web Services to in-
teract with Reo components, e.g., for the purpose of participating in a composition
with other Web Services. We consider this as the main advantage of the adapter ap-
proach. In fact, the WS provider need not know that someone “adapts” its Web Ser-
vices for use with the Reo infrastructure. We view possible performance degradation,
if any, resulting from the multiple transport protocols used in every adapter, as a
disadvantage of this approach. This problem often appears in multi-tier system.
55
6 Coordination Middleware based on MoCha
In this section we describe our high-level architecture of a coordination middleware
using the MoCha middleware. This architecture uses Web Services as a Reo compo-
nent model by following the transport approach we discussed earlier.
MoCha stands for Mobile Channels middleware [7], [9]. A mobile channels mid-
dleware provides channel communication with dynamic reconfiguration capabilities.
Mobile channels provide to components transparent support for mobility within a
distributed environment.
Transport: Java RMI
MoCha layer
easyMocha chocoMoCha
Full Reo coordination layer
Reo component layer
Applications: Java-based
Fig. 7. The MoCha middleware
The MoCha middleware (Fig. 7) implements a subset of the Reo functionality, limited
to direct component-to-component connections. The MoCha middleware constitutes
our first step toward a full Reo coordination middleware implementation. MoCha
uses Java RMI as a distributed processing environment. MoCha has three basic com-
ponents: the MoCha layer, easyMocha layer, and chocoMocha layer. The MoCha
layer provides the basic channel communication. The easyMoCha layer provides a
more extensive and user friendly interface together with the ability of keeping the
consistency of channel-end references for easier development of applications on top
of the MoCha layer. The chocoMoCha layer provides operations that allow compo-
nents to connect to and disconnect from MoCha channel ends. In order to become
fully Reo compliant, MoCha needs an additional layer that adds the concept of nodes
and operations such as join and split, among others, on Reo nodes. The MoCha layer
does not provide a component model, therefore we need an additional Reo component
layer to use MoCha in component-based applications. The work presented in [7]
describes a first version of such a component layer.
We use the MoCha prototype to build a Reo transport for Web Services. Fig. 8
shows the resulting coordination middleware architecture for WebServices.
56
Transport layer: Java RMI
MoCha
easyMocha chocoMoCha
Application layer
Mocha Transport 4WS (MoCha4WS)
MoCha4WS Binding
Reo component layer: Web Services
Fig. 8. Coordination middleware architecture for Web Services based on MoCha
The MoCha, easyMocha, and chocoMoCha layers constitute the bottom layer of the
coordination middleware. In order to integrate MoCha with Web Services we make a
MoCha4WS transport layer and a MoCha4WS Binding layer that allows the use of
this new transport. This effectively makes Web Services appear as a Reo component
layer, which designers can use to build applications imbued with the features that Reo
provides.
7 Conclusions
In this paper we presented our ongoing work on compositional construction of Web
Services. We use a coordination language, Reo, that promotes loose coupling, distri-
bution, mobility, exogenous coordination, and dynamic reconfiguration. We propose
Reo as a modeling language in which designers implement Web Service composi-
tions. The strong formal basis of Reo guarantees possibilities for both model checking
and verification, as well as well-defined execution semantics of a Web Service com-
position. As such, we consider Reo complementary to the existing languages (typi-
cally coming from the business process modeling community) for service composi-
tion.
We aim at producing a prototype coordination middleware that allows designers to
build robust and reconfigurable composite Web Services.
8 Acknowledgements
The authors would like to thank Juan Guillen-Scholten for his help on the MoCha
middleware. We carry out this work within the context of the Cybernetics Incident
Management (CIM) project, SENTER project nr. TSIT2021, The Netherlands.
57
References
1. Arbab, F., Mavadatt, F. “Coordination through channel composition”. In “Coordination
Languages and Models: Proc. Coordination 2002, volume 2315 of Lecture Notes in Com-
puter Science, Springer-Verlag, pp. 21-38.
2. Arbab, F. “Reo: A Channel-based Coordination Model for Component Composition”. To
appear in “Mathematical Structures in Computer Science”, 2004.
3. Arbab, F., Rutten, J.J.M.M. “A Coinductive Calculus of Component Connectors”. In the
Proceedings of 16th International Workshop on Algebraic Development Techniques
(WADT 2002), Lecture Notes in Computer Science 2755, Springer, 2003, pp. 35--56.
4. Arbab, F., Baier, C., Rutten, J., Sirjani, M. “Modeling Component Connectors in Reo by
Constraint Automata”. To appear in Electronic Notes in Theoretical Computer Science,
2004.
5. Schantz, R. E., and Schmidt, D. C. “Middleware for Distributed Systems: Evolving the
Common Structure for Network-centric Applications,” Encyclopedia of Software Eng.,
Wiley & Sons, New York, 2001; also available at
http://www.cs.wustl.edu/~schmidt/PDF/middleware-chapter.pdf
.
7. Guillen-Scholten, J.V., Arbab, F., de Boer, F.S., and Bonsangue, M.M. “A Channel-based
Coordination Model for Components”, in the Proceedings of 1st International Workshop on
Foundations of Coordination Languages and Software Architectures, ENTCS 68.3, Elsevier
Science, 2002.
8. Van der Aalst, W.M.P. “Don't go with the flow: Web services composition standards ex-
posed”. Trends and Controversies, IEEE Intelligent Systems, issue Jan/Feb, 2003.
9. Arbab, F., F., de Boer, F.S., Guillen-Scholten, G.V., Bonsangue, M.M. “MoCha: A Middle-
ware Based on Mobile Channels”. In the Proceedings of the 26th Annual International
Computer Science Software and Applications Conference (COMPSAC'02).
10. Web Services site. http://www.w3c.org/2002/ws/
11. Arbab, F. “Abstract Behavior Types: A Foundation Model for Components and Their
Composition”. In the Proceedings of the First International Symposium on Formal Methods
for Components and Objects (FMCO 2002), LNCS 2852, pp.33-70, 2003, The Netherlands.
12. The CIM project official web page. http://www.almende.com/cim
.
13. F. Cabrera et al., “Web Services Coordination (WS-Coordination)”, August 2002,
http://www.ibm.com/developerworks/library/ws-coor/
14. XML Protocol Group, “SOAP 1.2”, W3C Recommendation, June 2003,
http://www.w3c.org/2000/xp/Group/
15. E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, “Web Services Description
Language (WSDL) 2.0”, W3C, November 2001, www.w3.org/TR/wsdl20/
16. Universal Description, Discovery and Integration (UDDI) protocol 3.0, November 2004,
http://www.uddi.org/
17. F. Curbera, Y. Goland, J. Klein, F. Leyman, D. Roller, S. Thatte, and S. Weerawarana,
“Business Process Execution Language for Web Services (BPEL4WS) 1.1,” May 2003,
http://www.ibm.com/developerworks/library/ws-bpel
/
18. Web Services Choreography Interface 1.0 specification, December, 2003,
http://wwws.sun.com/software/xml/developers/wsci/
.
58