In the future vision of an Internet of Services, users take an active role in service selection and composition. In this context, web services are mostly interfaces to real services and can be classified as coordination services with respect to the latter. To enable users to perform service composition, the effect of the coordination services must be described in such a way that users are not only able to discover services but also to detect and prevent possible conflicts in their composition. To meet these requirements, a service description language for coordination services is proposed based on the REA business ontology.
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 [
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. [
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, [
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 [
To arrive at rigorous and relevant research results, we use Peffers’ design science
phases [
The Resource-Event-Agent (REA) ontology was first formulated in [
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 [
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 [
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:
Capacity(a,t) = card(R)
R= {r: resource | typify(r,t) ( x:agent received(a,x,r)
s:reservation (give(x,s) take(a,s) specify(s,t) reserve(s,r)) } Reserved(a,t,d) = ∑ c: card(s,c), s RS(a,t,d) where
RS(a,t,d) = {s: reservation | x,a:agent give(a,s) take(x,s) specify(s,t)
date(s,d) }
Available(a,t,d) = Capacity(a,t) - Reserved(a,t,d) 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 [
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” [
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 transaction – to mitigate the risks involved,
such as items being out of stock or functionality not available, and to reduce the need
for slack [
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 [
Using the REA ontology, service descriptions can be developed for coordination services either in the form of REA events REA relations. Table 1 specifies the basic predicates.
RELATIONS At(Agent,Location) Fulfil(Event,Commitment) Clause(Commitment, Contract) Available(Agent, ResourceType,Time): Number Capacity(Agent , Resource Type):Number PlannedCapacity(Agent, Resource Type, Time):Number
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
[
Using these predicates, we define the following list of coordination services (table
2). Note that they are services in terms of [
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 Coordination
Service Check_Availability Create_Reservation Cancel_Reservation Create_Contract Check_In Check_Out Receive_Payment Cancel_Contract
Input ResrcType R Time T User U Customer C Time T ResrcType R Customer C Time T ResrcType R Id Res Customer C Time T Id Res Customer C Time T Id PO Customer C Id Ri Customer C Id PO Customer C Time T Resource Rs Id PO
Output Bool A Id Res Id PO Amount F Id Ri Id S Id P 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 Eu of committed events for U is calculated first as follows:
fulfill*(e,c) participate(e,U))}
Eu = {e: event | c: commitment(c) Then
M = {m | e Eu: stockflow(e,m) participate(e,m)} (resources and agents involved, as far as known)
For some m M, the context Em 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”:
e1, e2 Em e1.time e2.time = Another general constraint is that the resource can be at only one place at a time, and needs time for moving: e1, e2 Em : e1.time.end = e2.time.start e1.location = e2.location e1, e2 Em : next(e1, e2) e1.location <> e2.location ( ei Em : e1< ei < e2 ei.type= «move» e1.object = m
ei.destination = e2.location) where next(e1, e2) means that e2 is the first event after e1.
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.