In spite of considerable progress that has been made in the area of Service Oriented Computing, the impact on society has still been limited. There is not yet such a thing as an Internet of Services that would allow users to integrate the services they want to use easily and seamlessly. It has been acknowledged that users must play a more active role in service composition, if only because of the long tail of specific and heterogeneous services around [1] that simply cannot be handled all by the IT departments. Enterprise mashups may provide an instrument to realize this service cocreation effort of users and developers [7]. In this paradigm, software resources such as (REST or SOAP) web services are embedded in widgets that provide simple user interaction mechanisms to these resources; these (visual) widgets are combined by the user himself to create mashups.
However, users are not interested in composing web services as such. To them, these are merely interfaces to "real" services such as traveling, meeting support, child care, entertainment or car maintenance. Users have a need to plan and coordinate the services they use (cf. [2]).
Fig. 1 depicts the envisioned user-centric service coordination cycle: users compose mashups and interact with the widgets in them to access web services. The web service typically supports the coordination with a service provider who offers a real-world service as part of a service bundle. The service affects a resource that concerns the user (the resource could be the user himself, for instance in the case of a hotel reservation). That web services themselves may be composite software entities is left out of this figure as being less relevant to the user, but is of course relevant to the software developer.
Both web services and services need a description, but what should be in this description? In composing web services, a major challenge is to reconcile incompatible data representations. In composing services in the real world, a major challenge is to meet the constraints imposed by the fact that resources are scarce, can only be in one place at a time and often cannot be shared. For that reason, [13] argues convincingly that "asset-driven" service modeling will be a central concern in developing an Internet of Services and claims that "novel methodologies and tools are needed to support the modeling of the key assets of services". In our view, this modeling should support at least conflict prevention and conflict detection.
Let s be a service that a user U intends to consume and let M be the set of resources and actors involved in the execution of s. Each m in M has a time-based context A(E,C) where E is a set of events planned for m and C a set of constraints on E. The goal of conflict prevention is to ensure that when s is added to the planning of U, all context constraints are still met, for all m in M. Typical events that stem from the planning of s are the start of the service execution and its ending. The goal of conflict detection is to check context constraints when an event e is added. Typical events are contingencies such as a flight being delayed. We can assume that in a future Internet of Services and Internet of Things, most of these events are generated without active user involvement. If s is a composite service, then the check should be done on all the services involved individually and jointly.
In order to make conflict prevention and conflict detection possible at all, web services must provide more information than input and output requirements such as we find in a WSDL document. What we need is a generic language to describe services, the resources they use as well as planned and actual events on the type level.
Web services can use this language to represent the preconditions and effects of the real services they connect to as well as their own semantics. A mashup environment can collect and combine this information, integrate it with other sources such as the user's agenda (that should be represented in the same format) in order to provide the user with the conflict prevention and conflict detection functionality described above. On the basis of the service description and after instantiating the formulae with actual data, the user immediately knows the effect of a successful service invocation.
In this paper, we propose to ground the service description language in the REA ontology [9] where we concentrate on coordination services as being of most interest to the user. An advantage of REA is that it has a very small set of basic concepts, and therefore is relatively easy to understand.
To arrive at rigorous and relevant research results, we use Peffers' design science phases [12]. The problem identification and motivation has been stated. Our solution objective is to develop a coordination service description language based on REA (without addressing a particular syntactic style, e.g. OCL or OWL). In section 2, we work out how REA represents services and the coordination of services. On the basis of that we show in section 3 how service descriptions can be developed that enable the required conflict detection (design and development). This is applied to the wellknown hotel reservation case (demonstration).
The Resource-Event-Agent (REA) ontology was first formulated in [9] and has been developed further, e.g. in [14,4,8]. The following is a short overview of the core concepts of the REA ontology based on [16].
A resource is any object that is under the control of an agent and regarded as valuable by some agent. This includes goods and services. The value can be monetary or of an intangible nature, such as status, health state, and security. Resources are modified or exchanged in processes. A conversion process uses some input resources to produce new or modify existing resources, like in manufacturing. An exchange process occurs as two agents exchange (provide, receive) resources. To acquire a resource an agent has to give up some other resource. An agent is an individual or organization capable of having control over economic resources, and transferring or receiving the control to or from other agents [5]. Agents participate in events from inside (the primary perspective of the model) or outside.
The constituents of processes are called economic events. An economic event is carried out by an agent and affects a resource. The notion of stockflow is used to specify in what way an economic event affects a resource. REA identifies five stockflows: produce, use, consume, give and take, where the first three occur in conversion processes and the latter two in exchange processes. REA recognizes two kinds of duality between events: conversion duality and exchange duality.
Events can be assigned to a location. Sometimes the acronym REAL is used for REA plus location [11].
Using the REA model, we can define the notions of capacity and availability. We take the perspective of the resource manager a (e.g. hotel manager) who has received or reserved certain resources from another agent x (e.g. hotel owner). He can commit resources of a certain resource type to another agent x for a certain date. In that case, there is a specify relationship between the reservation and the resource type. The commitment/reservation has a cardinality indicating the number of resources reserved. The actual allocation of resources (instances) to a certain reservation is usually done later. If we assume the Capacity is stable over time, the following definitions suffice: The capacity for a resource type t is what the agent has received or that is made available to him (and that is of the resource type t. To calculate the availability at some date/time d, we first sum up the commitments, and detract this number from the capacity.
Coordination services are defined in [16] as services supporting an exchange process (a set of events) for a good or a service. Processes like identification, negotiation, order execution and after-sales take place in both cases. We introduce the notion of coordination object for the object of these processes: what is negotiated and executed? The central coordination object is the purchase order fulfilled by the exchange event, but in complex processes there are many more. The following two reoccur quite often, especially when services are concerned: appointment and reservation. The reason for that is simply that the delivery of a service requiring resources from both the provider and customer to be present at the same time and place requires more coordination than the delivery of a good.
Using REA coordination objects can be specified in terms of commitments. Therefore, another way of characterizing coordination services is to say that these services manipulate commitments: their goal is to give, take and fulfill commitments.
We assume that for all coordination objects there is an agreement process first followed by an execution and evaluation process, that is, the coordination process per coordination object takes the form of a "Conversation for Action" [3,6]. The message exchange in these conversations is not in the scope of this paper, but what is important is the effect of these conversations, since that is directly relevant for a user composing and using a certain mashup application.
In standard REA, a reservation is a relationship between a commitment and a resource. In the following, we use the term "reservation" more specifically for a commitment that precedes the purchase order, which obliges a provider not to sell a resource to any other agent than the customer for whom the reservation is created. From an economic point of view, the main objective of this kind of reservations is to reduce uncertainty about the business transactionto mitigate the risks involved, such as items being out of stock or functionality not available, and to reduce the need for slack [15]. So although the reservation has some costs in the form of less operational discretion, it increases the total value for both customer and provider.
The REA application model in Fig. 2 contains and relates two coordination objects: reservation and purchase order. The reservation is commitment that specifies a resource type and there is a "reserve" relationship with resource, being all resources involved in the fulfillment of the commitment and set apart for that purpose. Quite often, the commitment specifies a resource type only and the allocation of the specific resource is done later. According to REA, there is exchange reciprocity between commitments. This reciprocity leads to dependencies between commitments that must be managed properly by the coordination services. The contract can be explicit or implicit. It may contain additional commitments, usually conditional ones (terms), such as a penalty for non show-up. In line with [8] we distinguish between dcommitments (decrement) and i-commitments (increment), for commitments by or to the service provider, respectively. The fulfill relationship is one between commitment and economic event. The fulfillment of the reservation is the accept-order event by which the purchase order is created. The fulfillment of the purchase order is the service exchange event. Since this could be seen as the ultimate objective of the reservation as well, we define a fulfill* relationship being the transitive closure of fulfill-relationships.
Using the REA ontology, service descriptions can be developed for coordination services either in the form of REA events REA relations. The relations and terms have a direct counterpart in REA or have been defined in section 2. We use some shorthands for the events. Commit stands for create commitment, Cancel for withdraw commitment. Purchase and Pay stand for the standard exchange events. Move stands for the event of changing the location of the agent or some resource. In both Commit and commitment we make use of an embedded functor e(x,t) where e is an Event Type, x can be a any object (and there may be more than one argument x) and t is a time reference. Expressions of this form are called i-events and are used in the same way as actions in the situation calculus [10], where they can be the object of a do-action.
Using these predicates, we define the following list of coordination services (table 2). Note that they are services in terms of [16]: their goal is an event that affects a relevant resource. Being coordination services, they manipulate commitments. Table 2 presents the IOPEs (Input/Output/Precondition/Effect) for hotel services but in a quite general way. As such it can be applied to a flight service or theater service as well. However, the way the coordination services are bundled in web services may differ. In the typical hotel case, the Create_Contract and Check_In are one transaction: at the moment the customer shows up, according to his reservation, a contract is set up and a specific resource is allocated. In the typical flight case, the Create_Contract is performed long time before the Check_In.
As said in section 1, each resource or agent is assumed to have a time-based context A(E,C) where E is a set of planned events and C a set of constraints on E. To support conflict detection and conflict prevention, we should be able to check whether E meets the constraints C.
Let M be the set of resources relevant to U. To determine the contents of M, the set E u of committed events for U is calculated first as follows: For some m M, the context E m contains the committed events that involve m. Note that U M. However, not only the context of U, but the context of every m M should not violate its constraints. The constraints in the context can be resource-specific, but a very fundamental constraint is that there can be no "agenda conflict": To prevent conflicts when considering the use of a service s, the user first adds the commitments produced by s to his context (using the coordination service effect descriptions), and then executes the conflict detection process.