an eca-based framework for decentralized coordination of ubiquitous web services

www.elsevier.com/locate/infsof

Information and Software Technology 49 (2007) 1141–1161

An ECA-based framework for decentralized coordinationof ubiquitous web services

Jae-Yoon Jung a, Jonghun Park b,*, Seung-Kyun Han b, Kangchan Lee c

a Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlandsb Department of Industrial Engineering, Seoul National University, San 56-1, Silim-Dong, Gwanak-Gu, Seoul, 151-742, Republic of Korea

c Electronics and Telecommunications Research Institute, 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, Republic of Korea

Received 1 April 2006; received in revised form 12 November 2006; accepted 24 November 2006Available online 18 January 2007

Abstract

Emerging ubiquitous computing network is expected to consist of a variety of heterogeneous and distributed devices. While web ser-vices technology is increasingly being considered as a promising solution to support the inter-operability between such heterogeneousdevices via well-defined protocol, currently there is no effective framework reported in the literature that can address the problem of coor-dinating the web services-enabled devices. This paper considers a ubiquitous computing environment that is comprised of active, auton-omous devices interacting with each other through web services, and presents an ECA (Event-Condition-Action)-based framework foreffective coordination of those devices. Specifically, we first present an XML-based language for describing ECA rules that are embeddedin web service-enabled devices. An ECA rule, when triggered by an internal or external event to the device, can result in the invocation ofappropriate web services in the system. Subsequently, we consider the situation in which the rules are introduced and managed by multi-ple, independent users, and propose effective mechanisms that can detect and resolve potential inconsistencies among the rules. The pre-sented ECA-based coordination approach is expected to facilitate seamless inter-operation among the web service-enabled devices in theemerging ubiquitous computing environments.� 2006 Elsevier B.V. All rights reserved.

Keywords: ECA rules; Ubiquitous web services; Device coordination; Rule conflicts; Conflict detection and resolution

1. Introduction

Ubiquitous computing is emerging to improve the qual-ity of human life and the behavior of businesses throughdigital technology convergence [44]. Currently ubiquitousenvironments are increasingly becoming heterogeneousand service rich domains where a diversity of communica-tion devices, such as laptops, portable digital assistances,digital home appliances, automotive telematics, and vari-ous sensors, are interconnected each other across differentplatforms and networks. For such computing environ-ments, web services technology can provide an effectivemeans for achieving inter-operability among the communi-cation devices [32,42].

0950-5849/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2006.11.008

* Corresponding author. Tel.: +82 2 880 7174; fax: +82 2 889 8560.E-mail address: [email protected] (J. Park).

Several ongoing efforts, including UPnP (Universal Plugand Play) 2.0 [41] for home networks, and OWSER (WebServices Enabler Release) from OMA (Open Mobile Alli-ance) [36] for mobile services, and Microsoft’s invisiblecomputing platform [34] for tiny devices, are attemptingto embed web services technology into various devices forthe purpose of materializing pervasive networks. At thesame time, recently proposed web service proposals, suchas WS-Eventing [3] and WS-Addressing [8], are also accel-erating the acceptance of web services technology for dis-tributed service devices through, respectively, providingendpoint descriptions and communication mechanisms.In this paper, we collectively refer to the web servicesembedded in the devices of ubiquitous networks asubiquitous web services.

There are three fundamental issues around the develop-ment and deployment of ubiquitous web services. The first

mailto:[email protected]

1142 J.-Y. Jung et al. / Information and Software Technology 49 (2007) 1141–1161

issue is on the service descriptions and messaging proto-cols. The early web services specifications, WSDL andSOAP, still appear to serve as base standards even in ubiq-uitous computing applications. The second issue focuses onthe service discovery and awareness. In this issue, researchon semantic web and ontology-based modeling as well asthe quality of service (QoS), is actively progressing forrealizing pervasive and autonomous computing [11,21].The last issue is concerned with service coordination whichwe attempt to address in this paper.

The service coordination problem is increasingly beingconsidered as significant in order to provide users with moreconvenient services in ubiquitous computing environments[45,31]. Specifications for service coordination in businesscomputing area, such as WS-BPEL [1] and WS-CDL [28],have enabled orchestration and choreography of web ser-vices [38], and facilitated integration of internal systems aswell as external business partners. In these specifications,centralized process enactment engines are responsible ofinterpreting and executing process descriptions, transitingthe states of process instances, and maintaining long-livedtransactions.

However, centralized process enactment approachespose several limitations when they are applied to ubiqui-tous environments. Many ubiquitous service devicesassume mobility, and they may frequently join or leave vir-tual network. Yet, the existing centralized coordinationmethods cannot embrace dynamic connectivity for mobilecommunication devices since they use static service bindingto service providers. Moreover, heavy enactment enginethat supports long-lived transactions cannot be embeddedin ubiquitous devices since they do not have sufficient com-puting capability. As a result, the ubiquitous service devicesrequire more dynamic, lightweight and decentralized coor-dination mechanism that can be implemented in mobilecommunication networks. Motivated by this, a decentral-ized rule-based service coordination framework is pro-posed in this paper for web service-enabled devices inubiquitous computing environments.

Our proposed framework for ubiquitous web servicecoordination takes the Event-Condition-Action (ECA)rule-based approach. ECA rules were originally proposedin the database community in order to provide traditionaldatabase systems with the capability of event-driven,instantaneous response [4,18]. Since the ECA approachoffers a means of the concise and distinct descriptions ofreactive behaviors, it has been adopted in a variety ofapplication fields, and it is currently recognized as one ofthe most effective coordination methods for carrying outdistributed coordination [5,7,15].

In this paper, we first present an XML based language,named WS-ECA (Web Services-ECA), for describingECA rules that define reactive behaviors of variousubiquitous web services as well as service interactions.The WS-ECA rules are embedded into the devices, andthen triggered by internal or external events of devices.The triggered rules, when their conditions are satisfied,

are activated to execute specific actions. WS-ECA rulessupport two types of service interactions: one is serviceinvocation, and the other is event notification. Serviceinvocation is a synchronous call that uses request/re-sponse mechanism. On the other hand, event notificationprovides a means of informing the devices of event occur-rences according to the publish/subscribe mechanismdefined in WS-Eventing specification. Event notificationsrepresent loosely-coupled and reactive service interactions,and they complement the rather passive service invoca-tions [13,24,33]. In addition, the publish/subscribe mecha-nism of WS-Eventing is appropriate for ubiquitousenvironments where an event of a device may affect multi-ple neighboring devices.

Subsequently, the paper looks into the situation in whichthe ECA rules are dynamically added to and removed fromthe devices by independent users. In this case, multiple rulesthat are stored in different devices at different time maycause inconsistency problems, and in order to address thisproblem, we propose effective mechanisms that can detectand resolve the conflicts among the rules. For this purpose,we introduce the notion of service constraints that representa set of actions of service invocations that are not allowed tobe made simultaneously. For example, the mutual exclusionrequirement that turning on and off an audio device shouldnot be performed at the same time is modeled as a serviceconstraint. The service constraints provide a means to spec-ify the requirements the system consisting of various devicesmust satisfy, and serve as a basis against which the rule con-flicts are checked.

Specifically, service conflicts are categorized into staticand dynamic ones depending on the time when theconflicts are checked and resolved. The static conflicts areidentified when a new rule is added to the system, andthe rule cannot be registered if it causes a conflict withany of the existing rules. On the other hand, the dynamicconflicts represent the potential conflicts that may arise atrun-time among the rules when they are activated simulta-neously by some event occurrence. Therefore, the dynamicconflicts are detected and resolved during run-time byutilizing some prescribed rules that resolve the conflicts.

The proposed framework for coordinating ubiquitousweb services has been developed to address the needs foractive service invocation, lightweight implementation, anddecentralized coordination in ubiquitous service environ-ment. That is, the framework not only supports the tradi-tional passive web service invocation model, but also theactive invocation model in which the web services are trig-gered upon the occurrences of internal and external events.In addition, contrary to the coordination languages such asWS-BPEL and WS-CDL that focus on the stateful, long-lived business processes, the framework supports statelessinteractions to provide the capability of spontaneous reac-tion of service devices. Finally, in the proposed framework,the rules governing the behavior of devices are decentral-ized across the network and executed independently byindividual devices.

J.-Y. Jung et al. / Information and Software Technology 49 (2007) 1141–1161 1143

The paper is organized as follows. We first discuss relat-ed work on event-driven rule management in Section 2.The proposed framework for ECA rule-based managementof web service devices is presented in Section 3, and thenthe structure and elements of the WS-ECA language arepresented in Section 4. Subsequently, the conflict detectionand resolution mechanisms for decentralized ECA ruleprocessing are described in detail in Section 5. Finally,Section 6 concludes the paper.

2. Related work

2.1. Ubiquitous web services

Many research projects, including Oxygen [35], SmartDust [26], and Smart-Its [23], have shown broad potentialsof ubiquitous computing. For instance, oxygen projectaimed at pervasive, human-centered computing whichimplies that in the future the ubiquitous technologywill get along with humans just like oxygen any timeand any place. The project is composed of five base tech-nologies – device, network, software, perceptual, and usertechnologies.

In particular, user technologies include collaborationmechanism that aims to facilitate device control in user-centered networks and spontaneous communicationbetween device to device, device to human, and human tohuman through coordinating a variety of communicationdevices. This is similar to the objective of this paper, whichattempts to coordinate ubiquitous web services by usingdistributed rules that govern the interactions among dis-tributed devices.

In parallel to the rapid development of ubiquitous com-puting technologies, web services are emerging as a prom-ising communication protocol in ubiquitous computingnetworks [11,39]. Some of recent research efforts, such asMicrosoft’s invisible computing project, UPnP 2.0 devicearchitecture, and OMA OWSER, show substantialapproaches to ubiquitous device communication based onweb services, and they are built upon the web service-en-abled devices that can run across a diversity of mobileand wireless platforms.

More specifically, Microsoft’s invisible computing plat-form attempts to realize seamless computing world forsmall devices by implementing web services on a chip.UPnP defines a distributed, open network architecturewhere devices are connected directly each other at home,office, and public spaces. Later, UPnP 2.0 adopted theweb services as a base technology for enhancing deviceinteroperability. In the meantime, the mobile web servicesworking group of OMA has published the OWSER speci-fication to define necessary infrastructure for offering webservices in wireless network environment. Based on HTTPand other technical specifications of web, they are antici-pated to adopt various web service technologies for servicediscovery, QoS policy, authentication, and service descrip-tion and invocation.

These previous research efforts have provisionedthe potential and usability of web services in ubiquitouscomputing, suggesting that web service-enabled devices willbe increasingly spread out in the emerging ubiquitousenvironments. Therefore, the problem of developing aneffective framework for decentralized coordination ofubiquitous web services appears to be quite necessary.

2.2. Distributed event-driven rules

Event-driven rules were introduced to provide tradi-tional database systems with active functionalities suchas integrity enforcement and view materialization[12,37]. Many research groups proposed active databasesystems, including SAMOS [22], Sentinel [12], DEVICE[4], EXACT [19], and HiPAC [18]. In these systems, trig-gering events are usually defined in terms of data manip-ulation operations and transaction commands [37]. Event-driven rules have also been employed for a variety ofrule-based applications, including expert systems [4],workflow systems [9], collaborating agents [6,27], andmiddleware [15].

Furthermore, ECA-based rule management has beenactively applied to distributed and parallel database sys-tems owing to its advantages of distinct and comprehensi-ble rule descriptions [15,43]. An excellent work onsummarizing the important issues of parallel rule process-ing such as condition matching and rule execution inknowledge based systems can be found in Vlahavas andBassiliades [43]. More recently, Cilia and Buchmann [15]used ECA rules to describe and chain business rules in het-erogeneous e-business environment. Facca et al. [20] tookan ECA based approach to develop adaptive web applica-tions, and Kantere and Tsois [27] proposed an ECA rulemanagement method for data management in P2Pnetwork.

Policy-based management is also an area where ECArules, called the policy description languages (PDL), wereapplied for distributed system coordination [10,30]. Shan-kar et al. [40] suggested ECA-P with post-conditions, whichis the state of a system after processing a rule. Theyaddressed limitations of existing ECA rules by proposinga mechanism of static and dynamic conflict detection andresolution for ubiquitous computing environments. Yet,the centralized way of distributed application coordinationhas made it difficult to apply their results to the problemconsidered in this paper mainly due to the issues of devicecapacities, communication overhead, mobility, and privateresource management.

Another important research issue that arises whenapplying ECA rules to decentralized coordination is man-agement of rule conflicts. Chomicki et al. [14], Kantereand Tsois [27], and Shankar et al. [40] presented logic-based approaches to detection and resolution of ruleconflicts. However, they assume the time granularity atrun-time, failing to consider instant reactions on eventoccurrences. This makes their approaches unsuitable to


the ubiquitous environment considered in this paper wheretwo events that occur within the same time window maycause a service conflict. Furthermore, their approachesrequire to check if individual rule causes any conflicts atrun-time, which is a time consuming task.

In contrast, the proposed approach first eliminates thestatic conflicts and then marks the rules that can be trig-gered by the same event occurrences as potential conflictsat design-time, and subsequently checks actual conflictsamong the marked rules at run-time. This is particularlyuseful for the considered computing environment, since itcan reduce the time required for conflict detection and res-olution as well as the communication overhead at run-timethrough allowing only the rules with potential conflicts tobe checked against actual conflicts at run-time.

There are several recent research results on event-basedservice computing using web services technology. SCXML(State Chart XML) specification [2] provides a languageby which a control mechanism can be described throughthe use of distributed finite state machines. Yet, it focuseson the behavioral description of an individual devicerather than a system consisting of multiple devices. Inaddition, recently proposed specifications, such as WS-Eventing [3] and WS-Addressing [8] are also acceleratingthe implementation of service-oriented ubiquitous comput-ing systems.

WS-Addressing offers a promising way of the endpointdescriptions of service partners for synchronous and asyn-chronous communication. On top of this, WS-Eventingdefines the messaging protocols to support the publish/sub-scribe mechanism among web service applications. Eventnotifications are delivered via SOAP messaging, and thecontent of the notifications can be described withoutrestrictions for a specific application. WS-Eventing can bealso used to develop an extended protocol to supportevent-driven interactions via web services.

In our research, WS-Eventing is employed as a meansfor delivering event notifications to devices. Whenever anew ECA rule is registered to a device, the device needsto check if the rule contains any new external event definedin the event part of the rule or any new event notification

WS-ECA Rules

Actions

Invoke extServiceInvoke intService

Generate extEventGenerate intEvent

Events

Service eventsTime events

Internal eventsExternal events

Variables

Event variablesDevice variables

ECA Rule

Event

Condition

Action

WS-ECA Rules

Actions

Invoke extServiceInvoke intService

Generate extEventGenerate intEvent

Events

Service eventsTime events

Internal eventsExternal events

Variables

Event variablesDevice variables

ECA Rule

Event

Condition

Action

Fig. 1. The structure o

action defined in the action part, so that it can start anew subscription to the external event or create a newevent publication according to WS-Eventing specification,respectively. WS-Eventing also provides additional servicessuch as publication/subscription renewal, state checking,and fault handling.

3. Management of WS-ECA rules

In the proposed framework, a service device is surround-ed by various event sources and service providers that,respectively, offer event notifications and web services.That is, service devices are assumed to interact each othervia the events generated via publish/subscribe mechanismof WS-Eventing and the web service invocations that userequest/response interaction model based on SOAPmessaging.

Following the structure of traditional ECA rules, theproposed language for rule descriptions, named WS-ECA, consists of events, conditions, and actions [25]. Theevent is a notification message that can be one of fourprimitive event types, namely (i) internal event if it is gener-ated by a device itself, (ii) external event if it is deliveredfrom other devices, (iii) time event that occurs after certaintime has elapsed, and finally (iv) service event that is gener-ated at the point of invoking a service of a device. The con-dition is a boolean expression that must be satisfied forsome action of a device to occur. It is defined by use ofevent variables contained in an event message or devicevariables maintained by a device. Finally, the action repre-sents an instruction carried out by a device, which includesprimitive actions such as web service invocation and eventgeneration. Fig. 1 shows the proposed structure of WS-ECA rules.

The proposed architecture for processing WS-ECA rulesis shown in Fig. 2. Each service device maintains a set ofWS-ECA rules defined by users and activates the rules inresponse to the triggering events at run-time. Global rulemanager (GRM) is responsible for analyzing the consistencyof rules at design-time and then for resolving rule conflictsat run-time. GRM is introduced to overcome the locality of

Device

Device

WS-ECA Rules

Services

event notification

service invocation

WS-ECA RulesWS-ECA Rules

WS-ECA Rules

Services


Web serviceproviders

Event sources

event notification

serviceinvocation

Device

Device

WS-ECA Rules

Services

event notification

service invocation


WS-ECA Rules

Services


Web serviceproviders

Event sources

event notification

serviceinvocation

f WS-ECA rules.

Serviceconstraints

Resolutionrules

ECArules

Ruleengine

Compositeevent

detector

Conditionevaluator

Actionexecutor

Globalrule storage

Design-timerule verifier

Staticconflictdetector

Dynamicconflictdetector

Dynamicconflictresolver

Run-timerule verifier

Event notifications

Local rulemanager

(1) registerECA rules

Service Device

Global Rule Manager

(5) store rules

(2) verify rules (c) resolve dynamic conflicts

Service invocationEvent publication(external events)

Temporal event generator

Internalevents

temporal events

(3) SCdetection

(4) DCdetection

(a)

(b)

(f)

(d) DCchecking

(e) DCresolution

Fig. 2. Architecture for WS-ECA rule processing.

Fig. 3. The overall WS-ECA schema.


service devices in terms of handling rule conflicts, and it isassumed to be deployed in a machine with moderate com-puting power. For instance, a personal computer mayimplement the functionality of GRM in a home networkwhile a variety of home appliances play roles as servicedevices.

In Fig. 2, the procedures, (1)–(5), are performed atdesign-time in order to verify WS-ECA rules and registerthem to devices. When a user requests the local rule man-ager of a service device to register a new rule, the rule ver-ifier of GRM consults with two conflict detectors, namelythe static rule conflict detector and the dynamic rule con-flict detector, to check the rule (indicated as (3) and (4) inFig. 2). While the static rule conflict detector is responsiblefor checking inconsistencies of the new rule with the exist-ing rules, the dynamic rule conflict detector examines anypotential conflict at run-time and requires the user to pro-vide the rules that can resolve the conflict if it turns out thata conflict may occur during run-time. Only the rules thatcomplete the verification are allowed to be registered tothe device, and the rules that can lead to a conflict atrun-time are marked by the dynamic rule conflict detector.Detailed algorithms used by these detectors will bepresented in Section 5.

On the other hand, (a)–(f) in Fig. 2 represent the run-time procedures carried out for processing the registeredrules and resolving dynamic rule conflicts. The compositeevent detector embedded in a device waits for an eventthat can be either internal or external to the device, andthen checks if the condition of the triggered rule is satis-fied. When the condition is satisfied and the rule has nomark for dynamic conflict, the corresponding action isexecuted immediately. Otherwise, the rule with a mark ischecked by the dynamic conflict detector to see whetheror not the conflict is imminent for a given state. If it is,the dynamic conflict resolver coordinates the devices withthe conflicting rules by use of the predefined resolution

rules. The resulting actions will be free from run-timeconflicts.

4. WS-ECA: an ECA rule description language for web

service devices

This section describes the XML schema of WS-ECA indetail. WS-ECA rules allow the web service-enabled devicesto interact each other via event-based interactions. WS-ECAhas been designed so that it can support (i) event passing bywhich certain events to be forwarded or broadcast to targetdevices, (ii) temporal reaction that allows different actions tobe performed according to the occurrence times of the sameevent, and (iii) rule chaining through which complex rulescan be constructed from several simple rules.

Fig. 3 shows the overall XML schema of WS-ECA. WS-ECA consists of a series of definitions for variables, events,and actions from which rules are constructed after specify-ing conditions. Furthermore, it supports the primitiveevents and actions as well as the composite ones for distrib-uted coordination of ubiquitous service devices. In whatfollows, we describe each element in detail.

4.1. Event

An event is an incident that triggers a rule. It is catego-rized into four primitive events, namely internal event,external event, time event, and service event. Internal eventis generated by the internal system components of a device,and it is defined to recognize the state change of a device orto trigger other rules. External event is generated from aremote publishing device and transmitted to a subscriberdevice via WS-Eventing protocol. Time event occurs whenthe timer of a device reaches some specific point in time. Itis further classified into three types: absolute, periodic, andrelative. The time event of absolute type occurs oncewhereas the event of periodic type occurs periodically.The time event of relative type is defined in relation withsome other event by use of ‘before’ and ‘after’ operators.Finally, service event is specified in reference to a specificservice invocation action defined for a device. It can beone of two types: before and after. The service event ofbefore (after, respectively) type is generated before (after,

Fig. 5. Variable schema of WS-ECA.


respectively) the specified service of a device starts (finishes,respectively).

Not only the primitive events introduced above, WS-ECA also supports specification of a composite event basedon them by use of the following logical operators:

• Disjunction (e1�e2�. . .�en): The composite event of type‘‘OR’’ has more than one sub-event, and it requires thatat least one of the sub-events must occur during somespecific time interval.

• Conjunction (e1�e2�. . .�en): The composite event of type‘‘AND’’ has more than one sub-event, and it requiresthat all of the sub-events must occur during some specif-ic time interval.

• Serialization (e1;e2;. . .;en): The composite event of type‘‘SEQ’’ has more than one sub-event, and it requiresthat all of the sub-events must occur sequentially duringsome specific time interval.

• Negation (�e): The composite event of type ‘‘NOT’’ hasonly one sub-event, and it requires that the sub-eventmust not occur during some specific time interval. Nega-tion can only be defined for the events in conjunction orserialization.

Fig. 4 shows the schema defined in WS-ECA for spec-ifying the primitive events as well as the compositeevents. The time interval necessary for a composite eventis denoted as TTL. We remark that event compositioncan be done recursively to represent complex eventstructures.

Fig. 4. Event schema of WS-ECA.

Table 1Extension functions to XPath’s built-in functions

Functions Retu

eca:getVariable(event QName, path PathExpr) xs:a

eca:getDateTime(event QName) xs:d

4.2. Condition

The condition of a WS-ECA rule is a boolean statementthat must be satisfied in order to activate the rule. It isdescribed in terms of an XPath expression [16], and theexpression in the condition may refer to values from theevent definition and use the variables defined in a WS-ECA document.

The syntax for the variables is presented in Fig. 5.Variables may refer to specific elements of an event definedin WS-ECA rules (called event variables) or they may beused to represent a state of a device (called device vari-

ables). They can be also used to express the conditions orto assign necessary input data for actions such as serviceinvocations and event publishing. We define two extensionfunctions to assign the value to a variable as shown inTable 1. The first function extracts a specific value froman event variable, and the second returns the date and timeinformation.

4.3. Action

The action part of WS-ECA contains the instructionthat is executed when a triggered rule is activated.Examples of the instructions include processing a user’srequest through service invocation, triggering anotherrule of a device by generating an internal event, andinteracting with other devices by publishing externalevents. Specifically, a primitive action can be: (i) invoke-

Service (service) that invokes an internal or external ser-vice, (ii) createExtEvent (event) that generates anexternal event and publishes it to subscribed devices,and (iii) createIntEvent (event) that generates an internalevent and triggers other rules of a device. The invoke-Service action uses the request/reply mechanism whilethe createExtEvent action bases on the publish/subscribemechanism. Finally, the createIntEvent action is definedwhen rule chaining is necessary for carrying out compli-cate service logic.

Contrary to the event part, the action part supports onlyone type of composite action: conjunction of primitiveactions. Given a set of actions, a1, a2, . . . ,an, the conjunctive

rn type Return value

ny Specific value from an event variable

ateTime Date and time information

Fig. 6. Action schema of WS-ECA.


action (a1 � a2 � . . .� an) requires all sub-actions to beexecuted. Fig. 6 shows the proposed schema for the actionelement of WS-ECA. The rationale behind allowing onlythe conjunctive actions is that deterministic disjunctiveand sequential actions can be alternatively expressed byuse of other primitives already defined in WS-ECA. Thatis, a set of disjunctive actions that are executed accordingto their specific conditions can be represented as a set ofWS-ECA rules for the same event with different conditions.Likewise, a set of sequential actions can be expressed as aseries of WS-ECA rules that are chained via internalevents.

4.4. Example

As a motivating example, we consider the followingscenario, ‘‘morning cook service’’, illustrated in Fig. 7.A user sets the get-up time to 7:00 AM on the alarmclock before sleeping. In the next morning, the clockinforms the rice cooker of ‘20 min before get-up’. Thecooker starts to cook, and if rice is not enough, it alertsto the user at his/her get-up time. When the cooking iscompleted, the cooker informs the coffee maker, andthe coffee maker will start to prepare morning coffee after10 min.

<events>

<timeEvent type=‘‘periodic’’ name=‘‘get-up-time’’ unit=‘‘P1D’’> 7:00 AM </timeEvent>

<timeEvent type=‘‘relative’’ name=‘‘before-get-up-time’’

baseEvent=‘‘get-up-time’’ interval=‘‘-PT20M’’/>

</events>

The scenario described above can be represented asthe set of rules shown in Fig. 8. For the alarm-clock,two time events are periodically generated, and the rulesare provided to check if it is not a holiday. Each rule,when the condition is satisfied, will execute an actionthat publishes an external event to the subscribing devic-es, namely the rice-cooker and the coffee-maker. As forthe rice-cooker, the first rule is to invoke the cookservice when it receives the alarm of ’20 min beforeget-up’. The next two rules of the rice-cooker, one for

generating an event before the cook service and theother for generating an event after the cook service,may, respectively, generate an internal event ‘out_of_rice’and external event ‘cooking_completion’, depending onthe condition. The last rule of the rice-cooker, which istriggered by a composite event enabled when the exter-nal event ‘alarm’ and the internal event ‘out_of_rice’are received sequentially within an hour, will executean alert service if the condition is satisfied. Finally, therule defined for the coffee-maker will require the ‘make-Coffee’ service to be started 10 min after it receives acomposite event that is enabled when two externalevents ‘cooking_completion’ and ‘alarm’ are receivedwithin 30 min.

Having introduced the example, we proceed to specifythe rules in terms of the proposed WS-ECA language.First, the events for the alarm clock are defined by usingthe time events of periodic and relative types as follows.Note that the periodic time event ‘get-up-time’ occursevery morning, while the relative time event ‘before-get-up-time’ occurs in reference to ‘get-up-time’. We alsoremark that the values of unit and interval attributesof timeEvent element are represented by use of durationin XPath specification [16]. For example, unit = ‘‘P1D’’of the periodic time event below denotes that the eventoccurs ‘every day’, and interval = ‘‘�PT20M’’ of the rel-

ative time event below denotes that the event occurs‘20 min before’ the base event.

Next, the events for the rice cooker show the usage ofother event types. The before and after service eventsdefined for the cooking service are introduced, and theinternal and external events are declared so that they canbe used in the following composite event, ‘get-up-after-out-of-rice’ which will be triggered when the external event‘alarm’ is followed by the internal event ‘cooking’ within 1hour (i.e. TTL=‘‘PT1H’’).

<events>

<svcEvent type=‘‘before’’ name=‘‘before-cooking’’ service=‘‘rc:cook’’/>

<svcEvent type=‘‘after’’ name=‘‘after-cooking’’ service=‘‘rc:cook’’/>

<intEvent name=‘‘cooking’’/>

<extEvent name=‘‘alarm’’ eventID=‘‘...’’/>

<compositeEvent type=‘‘SEQ’’ name=‘‘get-up-after-out-of-rice’’ TTL=‘‘PT1H’’>

<event name=‘‘cooking’’/><event name=‘‘alarm’’/>

</compositeEvent>

</events>


The actions defined below for the rice cooker containthree types of primitive actions, including createIntEvent,createExtEvent, and invokeService. The ‘start-cooking’and ‘detect-out-of-rice’ actions respectively generate twointernal events, ‘cooking’ and ‘out-of-rice’, which will beused to chain with other rules in the WS-ECA specification.The ‘complete-cooking’ action generates an external eventwith a URI that will be published to all external devicesthat are subscribing to the event. Finally, the ‘invoke-cook-ing’ and ‘alert-out-of-rice’ actions will respectively invokeinternal and external services based on the WSDL docu-ment with namespace ‘rc:’. A complete specification ofWS-ECA rules for the example presented in this sectionis provided in Appendix.

<actions>

<createIntEvent name="start-cooking’’ intEvent="cooking"/>

<createIntEvent name="detect-out-of-rice’’ intEvent="out-of

<createExtEvent name="complete-cooking’’

<extEvent="http://di.snu.ac.kr/event/rice-cooker/cooking-co

<invoke name="invoke-cooking’’ service="rc:cook"/>

<invoke name="alert-out-of-rice’’ service="rc:alert">

<rc:contents>out of rice</rc:contents>

</invoke>

</actions>

extEvent(20min before ‘get-up’)

get-up time=7:00AM

extEvent(‘get-up’)

cook

alert(

after intEvent(out_of_

extEvent(get-up)

Fig. 7. Morning cook

5. Conflict detection and resolution of WS-ECA rules

WS-ECA rules can be defined by multiple users and reg-istered to distributed devices. As a result, some rules mayhave inconsistencies with each other and may cause con-flicts when triggered and executed in a distributed mannerat run-time. In this section, we present a framework forconflict detection and resolution of WS-ECA rules imple-mented in distributed devices. We first introduce the notionof a service constraint, which represents a set of serviceinvocation actions that are not allowed to occur at thesame time. That is, an event may result in execution ofactions that belong to the same service constraint, and wesay that a set of WS-ECA rules has a conflict if some of

-rice"/>

mpletion"/>

()intEvent(out_of_rice)

if rice is not enough

)

rice)

if cooking is completed

extEvent(cooking_completion)

timeEvent(10min aftercooking_completion& get-up)

invokeService(makeCoffee())

svcEvent(beforecook())

svcEvent(aftercook())

service example.

Fig. 8. ECA rule example of morning cooking service.


the rules triggered by an event can lead to violation of theservice constraints.

In addition, we categorize the WS-ECA rule conflictsinto two types according to the time when they areresolved. The first type is static conflict that is examinedat design-time to determine if there is a set of rules thatviolate service constraints. Once such rules are found,they cannot be registered together to the systems andthey must be modified to avoid the service conflicts.The second is dynamic conflict which is judged at run-time to see if there is a set of rules enabled coincidentallythat may lead to the conflicts against the service con-straints although no logical contradiction was identifiedat design-time. The rules with a dynamic conflict will beallowed to be registered only after supplementing manu-ally the corresponding resolution rules that can settlethe conflicts at run-time. The resolution rules, which arealso defined as WS-ECA rules, are triggered when corre-sponding dynamic conflict occurs at run-time. Detaileddescriptions on the resolution rules will be given in Sec-tion 5.3.

Fig. 9 shows the overall framework for conflict detectionand resolution in consideration for two types of WS-ECArule conflicts. The proposed framework is composed of twophases of conflict management, namely the design-timeconflict detection and run-time conflict detection and reso-

lution. At the design-time phase, the rules created by a userare forwarded to GRM, which then checks if each rulecauses any static conflict by comparing it with those regis-tered already to devices. In case that any static conflict isdetected, the user will be notified of the detailed conflictand requested to modify the rule to remove the conflict.

When no static conflict is identified, GRM subsequentlychecks if the rule can cause a dynamic conflict atrun-time. If any potential dynamic conflict is detected,the user is notified of the service conflict (i.e., the serviceactions involved and the corresponding service constraints)and the conflict details (i.e., the set of events and condi-tions). In this case, the user must supply appropriatedynamic conflict resolution rules that can arrange the con-flict situation at run-time. Only after registering these reso-lution rules to GRM, the new rule can be registered to aservice device with a mark which indicates the rule maycause a dynamic conflict at run-time. The other rulesinvolved in the dynamic conflict also need to be marked.

At run-time, the rule processor embedded in a servicedevice waits for a triggering event. When a rule is triggered,it checks whether or not the rule is marked with a dynamicconflict. If no marking is associated with the rule, itsactions will be executed immediately. Otherwise, the deviceneeds to consult with GRM to see if a dynamic conflict isimminent. In case that no dynamic conflict is identified,

Fig. 9. Framework for ECA rule conflict management.


the actions defined for the rule are executed. Otherwise,GRM sends the appropriate action instructions to thedevices involved in the conflict through looking up thedynamic conflict resolution rules supplied at design-time.

5.1. Basic concepts

In this section, we present formal semantics and proper-ties of the proposed WS-ECA rules and provide necessarydefinitions on which the algorithms for conflict detectionand resolution are based. First, we formally define theWS-ECA normalized rule set.

Definition 1 (Normalized rule set). A normalized rule set,RSWS, is a finite set of WS-ECA rules, R = (ER,CR,AR),where ER, CR, and AR, respectively, represent the sets ofevents, conditions, and actions defined as follows.

1: ER ¼ feje ¼ e1; . . . ; en; where

ei ¼ etime; eint; eext; or esvc; i ¼ 1; . . . ; ng

Event set ER consists of the disjunction of one or moreserializations of events, where the serialization is expressedas e1; . . . ;en. An event ei is one of the following types: timeevent etime, internal event eint, external event eext, and ser-vice event esvc.

2: CR ¼ fcjc¼ c1 ^ � � � ^ cm; and cj ¼ r1hr2; j¼ 1; . . . ;mgð2Þ

Condition set CR consists of the disjunction of zero ormore conjunctions of condition predicates. Each conjunc-

tion is expressed as c1 � � � �� cm, and the condition predi-cate cj is expressed as r1h r2, where h is an operator fromthe set {=, „, <, 6, >, P}, and ri, i = 1, 2, is a constant,an event variable, or a device variable.

3: AR ¼ faja ¼ asvc; aint; or aextg ð3ÞAction set AR consists of the conjunction of one or moreprimitive actions, which can be invokeService asvc (svc),

createIntEvent aint(eint), or createExtEvent aext(eext).

RSWS represents the set of all WS-ECA rules definedfor all devices in the system in a normalized form. The con-dition set bases the formalism on the work presented byChomicki et al. [14] and extends it to allow both the con-junctions and the disjunctions of condition predicates inorder to conform to WS-ECA language. The action setexpresses the conjunction of the primitive actions whichneed to be executed when a rule is activated. As for theevent set of RSWS, the following Lemma establishes thatany composite event defined in WS-ECA by use of fourlogical operators (disjunction, conjunction, serialization,and negation presented in Section 4) can be transformedto a subset of ER. Therefore, any WS-ECA rule can beequivalently described in terms of the normalized rule set.

Lemma 1. Any valid composite event defined in terms of

WS-ECA can be equivalently translated to the subset of

event set ER of normalized rule set RSWS:

Proof. A composite event is defined by use of fouroperators, disjunction �, conjunction �, serialization ; ,and negation �, and it satisfies the following properties:

(i) e1;(e2;e3) = (e1;e2);e3

(ii) e1;(e2 � e3) = (e1;e2) � (e1;e3)(iii) e1;(e2 � e3) = (e1;e2 � (e1;e3)(iv) (e1 � e2) � e3 = (e1 � e3) � (e1 � e3)(v) e1 � e2 = (e1;e2) � (e2;e1)

From the properties (i), (ii), and (iii), any valid compositeevent expression in WS-ECA can be transformed into theequivalent conjunctions and disjunctions of serializations.Subsequently, conjunctions can be re-written as disjunc-tions and serializations by using the properties (iv) and(v), resulting in the disjunction of serializations as definedin ER.

Lemma 1 is based on the assumption that parallel eventsto a service device can be effectively represented as inter-leavings of them. Considering that each service device playsa role of observer when it receives events from other devic-es via wireless or wired communication channel, we believethat this is a reasonable assumption for the consideredubiquitous environments. Next, we present a series of def-initions for the purpose of development of the rule conflictdetection algorithms in the next section.

Definition 2 (Event dominance). Let ei and ej be twoserializations of events. ei is said to be dominant over ej


(represented as ei ! Eej) if the occurrence of ei implies theoccurrence ej. That is, ei ! Eej, if ei ¼ ei

1; . . . ; ein, and

ej ¼ eia; . . . ; ei

s; . . . ; eit; . . . ; ei

m (1 6 a < s < t < m 6 n).

Definition 3 (Concurrability). Let RS be a normalizedrule set with two or more rules, and efinal be a primitiveevent. RS is said to be concurrable for a final event efinal ifall rules in RS are triggered at the same time when efinal

occurs. That is, RS is concurrable for efinal if 8Ri 2 RS,$ei (¼ ei

1; . . . ; einÞ 2 ERi, such that ei

n ¼ efinal.

Definition 4 (Co-triggerability). Let RS be a normalizedrule set with two or more rules, and etrig be a primitive orcomposite event. RS is said to be co-triggerable for thetriggering event etrig if RS is concurrable for the final eventof etrig and etrig triggers all the rules in RS. That is, RS isco-triggerable for etrig, where etrigð¼ etrig

1 ; . . . ; etrign Þ 2 ERt,

Rt 2 RS if 8Ri 2 RSði 6¼ tÞ, 9eið¼ ei1; . . . ; ei

mÞ 2 ERi, suchthat ei

m ¼ etrign and etrig ! Eei.

Event dominance is defined to analyze the relationshipbetween the event serializations. As an example, for twoserializations of events ea = e1;e2;e3;e4;e5 and eb = e2;e4,the occurrence of ea guarantees the occurrence of eb, andtherefore ea is dominant over eb. From the definition ofevent dominance, it immediately follows that if ei = ej,ei ! Eej and ej ! Eei. That is, two equivalent events aredominant over each other. Event dominance is used toidentify the rules that can be triggered together by an event.When a normalized rule set is concurrable, all rules in theset have a serialization event with the same final event efinal.If efinal occurs after all the preceding events have occurred,all rules in the set will be triggered simultaneously. There-fore, it follows that if some rules in a concurrable rule sethave service actions violating any service constraints, itmay cause rule conflicts. On the other hand, if a normalizedrule set is co-triggerable, all rules in the set have a serializa-tion event that has the same final primitive event and alsohas the same dominant event etrig, which is also an event ofa rule in the set.

Note that, the rules in a co-triggerable rule set that haveactions against service constraints necessarily lead to con-flicts when the event etrig happens and the required condi-tions are satisfied at run-time, and therefore they shouldnot be allowed to be registered at design-time. However,the rules in a concurrable rule set that have actions againstservice constraints do not always result in a conflict whenthe event efinal occurs at run-time, since the precedingevents of some rules may not have occurred. Hence, theserules should be checked at run-time to see if they actuallylead to a conflict.

The rules triggered at the same time may have differentconditions that need to be met, making some rules withpotential conflicts actually result in conflicts or not depend-ing on the condition. The next two definitions further char-acterize the potential conflicts in view of the conditionsdefined for a normalized rule set.

Definition 5 (Compatibility). Let RS be a normalized ruleset with two or more rules. RS is called compatible if theconditions in RS can be satisfied simultaneously. That is,RS is compatible if c1 � . . . � cm „ false, where ci 2 CRi,Ri 2 RS (1 6 i 6 m and CRi „ /). Otherwise, RS is calledincompatible.

Definition 6 (Co-satisfiability). Let RS be a normalizedrule set with two or more rules, and csat be a condition ofa rule in RS. RS is called co-satisfiable for csat if csat

can satisfy all rules in RS. That is, RS is co-satisfiablefor csat, where csat (¼ csat

1 ^ . . . ^ csatm ) 2 CRs and

Rs 2 RS, if 8Ri 2 RS (i „ s and CRi „ /), $ci 2 CRi suchthat csat = ci � cany, where cany is either a true conditionor conjunction of any csat

k (1 6 k 6 m).

If a normalized rule set is compatible, it means that it ispossible for the rules in the set to be satisfied simultaneous-ly in some case, whereas if the rule set is incompatible, allthe rules in the set cannot be satisfied simultaneously inany case. On the other hand, if a normalized rule set isco-satisfiable, a rule in the set has the condition csat thatcan also satisfy all the other rules in the set which havethe same condition as csat or less constrained conditionsthan csat, including a null condition (i.e., true condition).A co-satisfiable rule set is compatible since there alwaysexists a valid condition csat = c1 � . . . � cm „ false, whereci 2 CRi, Ri 2 RS, and 1 6 i 6 m.

Example 1. Consider a normalized rule R0 whose condi-tion is an empty set, which means true condition. R0 iscompatible with any other rule since the true conditioncan be satisfied simultaneously with any other conditions.In addition, R0 is also co-satisfiable with other rulessince the conditions of the other rules can satisfy the truecondition of R0, (i.e., conditions of the other rulesbecome csat in this case). As another example, considerthree rules R1, R2, and R3, such that CR1 = {c1, c2},CR2 = {c1 � c3}, and CR3 = {�c3}. Out of all combina-tions of these, the only co-satisfiable rule set is {R1, R2}for csat = c1 � c3, and the compatible rule sets are {R1,R2} and {R1, R3}, while the incompatible rule sets are{R2, R3} and {R1, R2, R3} due to the fact that(c1 � c3) � (�c3) = false.

5.2. Rule conflict detection

Service constraints are defined as conjunctions of two ormore service actions. The constraints are stored in GRM,and they are used as criteria for judging service conflicts.In the following two definitions, we formally define the ser-vice constraints and rule conflicts.

Definition 7 (Service constraints). Service constraintsACWS is a power set of the service action set such thatAC = {a1,. . ., an j a1 � . . . � an are not allowed to beactivated simultaneously and ai = asvc, i = 1, . . ., n}2ACWS.


Definition 8 (Rule conflict). Let RStrig be a normalizedrule set of which the rules are triggered on the occurrenceof a primitive event. It is said that RStrig has a rule conflictif two or more service actions of RStrig are contained inone of the elements of ACWS.

The rules can be triggered directly or indirectly. We saythat a rule is directly triggered on the occurrence of a prim-itive event when its event specification has one or moreevent serializations whose final event is the primitive event.On the other hand, a rule is said to be indirectly triggered ifit is triggered by the generated events from createIntEvent

or createExtEvent on the occurrence of a primitive event.In what follows, we elaborate more on the two types of ruleconflicts and then present algorithms for detecting conflicts.

5.2.1. Static conflict detection

A normalized rule set is said to have a static conflict ifthere exists a situation in which triggered rules cause a ser-vice conflict. Depending on whether the rules with conflictsare triggered directly or indirectly by an event, the staticconflict is further divided into two types, namely absolute

conflict and chained conflict. First, the absolute conflict isdefined as follows.

Definition 9 (Absolute conflict). Let RStrig be a co-trigg-erable and co-satisfiable set of normalized rules. It is saidthat RStrig has an absolute conflict if the rules haveservice actions that violate a service constraint AC ofACWS. Formally, a co-triggerable and co-satisfiable setRStrig has an absolute conflict if 9AC 2ACWS such thatAC � fasvcjasvc 2 ARi;Ri 2 RStrigg.

In WS-ECA, there are two primitive actions, createExt-

Event and createIntEvent, that can, respectively, generatean event to trigger other rules in an external device andinternal device. The rules indirectly triggered by such anevent generation action may also cause a service conflictwith each other or with directly triggered rules. This typeof conflict is called a chained conflict which is formallydefined in the following definition.

Definition 10 (Chained conflict). Let RStrig0 be a co-triggerable and co-satisfiable set of normalized rules

Fig. 10. Absolute and chained con

without absolute conflict, and RSchain be a set ofnormalized rules that are co-satisfiable with RStrig andcan be triggered by an event generated from a rule ofRStrig0 or from another rule of RSchain. It is said thatRStrig0 [RSchain has a chained conflict if the rules inRStrig0 [RSchain have service actions violating a serviceconstraint. Specifically, RStrig0 [RSchain has a chainedconflict if 9AC 2ACWS, such that AC � fasvcjasvc 2ARi;Ri 2 RStrig0 [RSchaing.

From the above definitions of absolute and chained con-flicts, it follows that a normalized rule set with an absoluteor chained conflict necessarily has a static conflict since theco-triggerability and co-satisfiability of the rule set impliesthe existence of the triggering event etrig and the satisfiablecondition csat.

Example 2. An example of static conflict is illustrated inthe rule triggering graph of Fig. 10, where all rules are co-triggerable for the serialization event e4;e1, which is adominant event over e1. Two tables in Fig. 10, respectively,show the rules and service constraints. Note that ER

denotes the disjunction of events while AR represents theconjunction of primitive actions. For example, rule R2 istriggered by either event e1 or e5, and it requires to carryout both actions asvc

2 and aint(e3). In this example, directlytriggered rule set {R1, R2}, which is co-satisfiable for thecondition c1 � c3, has an absolute conflict, since it permitsthe actions against the service constraint AC1. Further-more, the directly or indirectly triggered rule set {R1, R3,R4}, which is co-satisfiable for the condition c1 � c3, makesa chained conflict against AC2, while the indirectlytriggered rule set {R5, R6}, which is co-satisfiable for thecondition c1, also results in a chained conflict against AC3.

In the proposed framework, GRM detects static con-flicts by considering the other existing rules in all devicesof the system when a new rule needs to be registered to aservice device. Fig. 11 shows the proposed algorithm forstatic conflict detection.

To start the algorithm static_conflict_detection, a newrule Rnew is given with a normalized rules set RSWS, a ser-vice constraint set ACWS, and a conditional action set

flict in a rule triggering graph.

Fig. 11. Algorithm static_conflict_detection.


cAWS, which are updated for every rule insertion. Theoutput of the algorithm is a static rule conflict set RCstatic.First, the algorithm constructs the conditional action setcA from the new rule by function makeCondActs(Rnew)(Line 2). The function identifies the service actions of boththe new rule Rnew and the rules that can be triggered byRnew, and then it returns a set of conditional actions(a,C), where a is a service action and C is the conditionset that must be satisfied to execute the action a.

Subsequently, the algorithm starts to check for a staticrule conflict for each serialization event e 2 ERnew (Lines3–12). Static conflict can arise in two types of co-triggerablerule sets related to event e. The first is the set of rules thatcan be triggered by e, and the second is the set of the rulesthat can be triggered by edom, the dominant co-triggering

events of e. In particular, in the second case, we only needto check the rules triggered by the most dominant co-trig-gering events. This is because the rule set of the most dom-inant co-triggerable events of ecompletely includes those ofother co-triggerable events of e. It follows that if there is nostatic conflict for the most dominant co-triggering events,there is no static conflict for the other co-triggering events,as well as event e. In Line 4, function findMDE(e) finds themost dominant co-triggering events for e. For instance, let{e4, e1;e4, e2;e4, e1;e3;e4, e2;e3;e4} be a co-triggering event setof e4. The most dominant events of e4 in this case aree1;e3;e4 and e2;e3;e4.

In case of no co-triggering event for e, we only need tocheck if the conditional action set of the new rule cARnew

has any service conflict by itself through the function


checkConflict(e,cA) (Line 5). Otherwise, for all the mostdominant co-triggering events edom 2MDE(e), we take aunion of cA(edom) and cARnew and then check the serviceconflict (Lines 7–10). Finally, if the new rule has no staticconflict, the algorithm updates the conditional action setsfor all edom of each event e 2 ERnew (Lines 13).

The algorithm uses function checkConflict(e, cA) inorder to check static conflicts in conditional action sets.In this function, if the conditional action set includes anyservice constraint, the algorithm tests the co-satisfiabilityof the rules with the conflicting actions by using functioncheckCoSatisfiability(cAconflict) which checks the co-satifi-ability of the conditional actions cAconflict based on the ser-vice constraint AC 2ACWS. The function first finds allcombinations of the conditions that can result in an actionin the service constraint AC, and then it checks co-satisfi-ability of all combinations of conditions. If there is a com-bination that turns out be co-satisfiable, this means thatthere exists a co-satisfying condition csat, where serviceactions in cAstatic triggered by an event ewill necessarilyviolate the service constraint AC.

Performance of the algorithm static_conflict_detectiondepends on the size of the normalized rule set and the ser-vice constraints set. Time complexity of the algorithm isO(nenam), where ne and na denote the number of eventsand actions in the rule set, respectively, and m is the num-ber of service constraints. This follows from the observa-tion that the total number of dominant events is less thanne (i.e., jMDE(e)j < ne), and the traversals in the functioncheckConflicts(e, cA) require O(nam) since the size of con-ditional action set is smaller than na and the size of serviceconstraints set is m (i.e. jcAj < na and jACWSj ¼ m).

Example 3. We demonstrate the proposed algorithmthrough an example. Suppose that a new rule R7 is addedto the problem in Example 2 and ACWS has only oneconstraint, as shown in Fig. 12. The event specification ER7

has only one event e1, which has the co-triggering evente4;e1(i.e., ER7 = {e1} and MDE(e1) = {e4;e1}). Therefore, itis not necessary to make a new conditional action set of e1,since the set will be included in the set of e4;e1 (i.e.,cA(e1) � cA(e4;e1)). From Fig. 10, we obtain cA(e4; e1) =cAR1 [ cAR2, where cAR1 = {(asvc

1 , {c1 � c3}), (asvc3 , {c1 �

Fig. 12. Example of stat

c3})} and cAR2 = {(asvc2 , {}), (asvc

4 , {}), (asvc5 , {c1}),

(asvc6 , {})}. Next, we get cA 0(e4;e1) = {(asvc

1 ,{c1 � c3}),(asvc

2 , {}), (asvc3 , {c1 � c3}), (asvc

4 , {}), (asvc5 ,{c1}), (asvc

6 , {}),

(asvc7 , {c1 � c7})} since cA 0(e4;e1) = cA(e4;e1) [ cAR7 and

cAR7 = {(asvc7 , {c1 � c7})}. Finally, we obtain a static con-

flict set RCstatic from the result of function checkCon-

flict(cA 0(e4;e1)). The static conflict set isRCstatic = {(e4;e1,{asvc

5 ,asvc6 ,asvc

7 }, {R5,R6,R7})}, which means that R7 hasonly one static conflict in which the triggering event e4;e1

causes a service conflict against the constraint {asvc5 , asvc

6 ,asvc

7 } in the rule set {R5, R6, R7}.

5.2.2. Dynamic conflict detection

Under the existence of composite events that aredefined by using conjunctions, disjunctions, and serializa-tions, the exact event matching alone cannot guaranteethe nonexistence of conflicts at run-time. Suppose thattwo rules, respectively, contain conjunctions of events,e1 � e2 and e1 � e3, with true conditions. Assuming thatthe resulting actions of two rules violate a service con-straint, we cannot tell at design-time whether or not theywill lead to a rule conflict since we do not know if twoevent e2 and e3 can occur simultaneously. The similarargument can be made for the case of conditions of therules. We know that a co-satisfiable rule set has a situa-tion in which all the rules can be satisfied. However, wedo not know whether a compatible rule set may have sucha situation or not at run-time. These kinds of conflicts arecalled as dynamic conflicts, which are dependent on theactual event occurrences and the evaluation of conditionsat run-time. Dynamic conflict is formally defined asfollows.

Definition 11 (Dynamic conflict). Let RStrig be a set ofnormalized rules. It is said that RStrig has a dynamicconflict if it is a concurrable and compatible rule set and itsrules have service actions against any service constraint inACWS. Formally, RStrig has a dynamic conflict if (i)$efinal, such that 8Ri 2 RStrig, 9eið¼ ei

1; . . . ; ein) 2 ERi, and

efinal ¼ ein, (ii) "Ri 2 RStrig (1 6 i 6 m), $ci 2 CRi, such that

c1 � . . . � cm „ false, and finally (iii) 9AC 2ACWS, suchthat AC � ARStrig, where ARStrig = {asvc j asvc 2 ARi, Ri 2RStrig}

ic conflict detection.


Having a dynamic conflict for a rule set means that it ispossible for the rules in the set to result in some service con-flict since (i) the rules can be triggered simultaneously (i.e.,concurrability), (ii) the conditions defined for the rules canbe satisfied at the same time (i.e., compatibility), and (iii)the resulting actions of the rules can cause a conflict againstsome service constraint. GRM identifies the possibility ofdynamic conflicts induced by a new rule only after the ruleis judged to have no static conflict. We propose a dynamicconflict detection algorithm in Fig. 13. Indeed the algorithmis an extension from the static conflict detection algorithm.

Fig. 13. Algorithm dynam

The algorithm dynamic_conflict_detection starts with anew rule Rnew, a normalized rules set RSWS, and a serviceconstraint set ACWS, and a conditional action set ecAWS,as an input. The output of the algorithm is dynamic ruleconflict set RCdyn. It has the same structure as in static_con-

flict_detection. However, since dynamic conflicts are depen-dent on the preceding events of final primitive events as wellas the conditions, the algorithm introduces ecA(efinal) whichis the conditional action set with preceding events for eachfinal event efinal. Furthermore, (a,C,Eprec) 2 ecA(efinal)denotes that, on the occurrence of efinal, service action a will

ic_conflict_detection.


be executed when the condition set C is satisfied and all thepreceding actions in Eprec have been already carried out.

Similar to the static conflict detection algorithm, thealgorithm also checks dynamic rule conflict for each serial-ization event e 2 ERnew (Lines 3–8). Dynamic conflict mayhappen from the rules that have the events with the samefinal primitive event. Function makeCondActs4DC(Rnew)of Line 2 is similar to function makeCondActs(Rnew) inthe algorithm static_conflict_detection. The only differenceis that service actions in the set ecA accompany the preced-ing events set as well as their conditions set.

Next, we take the union of the conditional action set ofefinal, ecA(efinal), and that of the rule, ecARnew, and thencheck if the set has any service conflict through the functioncheckConflict4DC(efinal, ecA) (Lines 5–6). In case that evente is the first event with the final event efinal in all rules, thealgorithm constructs a new conditional action set fromecARnew and then checks the service conflict.

Finally, if the new rule has no dynamic conflict, the algo-rithm updates the conditional action set of the final event,ecA(efinal) (Line 8). If there exists any dynamic conflict,the algorithm creates a dynamic conflict check rule (DCCR)for each dynamic conflict, and then marks the rules that areinvolved in the dynamic conflict (Lines 10–13). At run-time,DCCR is responsible for checking if the prescribed condi-tions are satisfied after the preceding events have occurred.If it turns out that the dynamic conflict is imminent, the cor-responding resolution rule will be triggered.

Time complexity of the algorithm dynamic_con-

flict_detection is O(nenam), where ne, na, and m representthe numbers of events, actions, and service constraints,respectively. Function checkConflicts4DC(e, ecA) takesthe time O(nenam) since the size of conditional action setecA is smaller than neÆna and the size of service constraintsset is m (i.e. jecAj < nena and jACWSj = m).

Example 4. The proposed dynamic conflict detectionalgorithm is demonstrated through an example. Supposethat a new rule R07 is introduced to the modified example ofFig.10 and ACWS has only one constraint, as shown inFig.14. Event specification ER70 has only one serializationevent e8;e1, whose final primitive event e1 also appearsas a final event of other serializations e4;e1 and

Fig. 14. Example of dyna

e1(i.e.ER70¼fe8 ; e1g, and efinal = e1).In this case, we use the

existing conditional action set of e1.We obtain ecA(e1) =ecAR1(e1) [ ecAR2(e1), where ecAR1(e1) = {(asvc

1 ,{c1 � c3},{e4}), (asvc

3 ,{c1 � c3},{e4})} and ecAR2(e1)={(asvc2 ,{},{}),

(asvc4 ,{},{}), (asvc

5 ,{c1 � c5},{}), (asvc6 ,{c6},{e7})}.And then

we compute ecA 0(e1) = {(asvc1 ,{c1 � c3},{e4}), (asvc

2 ,{},{}),(asvc

3 ,{c1 � c3},{e4}), (asvc4 ,{},{}), (asvc

5 ,{c1 � c5},{}), (asvc6 ,

{c6},{e7}), (asvc7 ,{c7},{e8})} since ecA(e1) = ecA(e1) [

ecAR7(e1) and ecAR7 = {(asvc7 ,{c7},{e8})}. Finally, we get

the dynamic conflict set RCdyn from the result of functioncheckConflict4DC(ecA 0(e1)): RCdyn = {(e1, {asvc

5 , asvc6 , asvc

7 },fR50 , R60 , R70}, {e7 � e8}, {c1 � c5 � c6 � c7})}, which saysthat R07 has only one dynamic conflict. That is, if thepreceding event e7 � e8 has occurred before the final evente1, and the condition c1 � c5 � c6 � c7 is satisfied, the evente1 will cause a service conflict against the constraint {asvc

5 ,asvc

6 , asvc7 } that involves the rule set fR50 , R60 , R70}.

5.3. Dynamic rule conflict resolution

GRM identifies static conflicts and dynamic conflictsbefore new rules are registered in distributed devices, asillustrated in Fig. 9. When a rule has only dynamic conflictwithout any static conflict, it can be registered to a deviceafter adding dynamic conflict resolution rules that willresolve the dynamic conflicts at run-time. Such a rule is reg-istered with a mark indicating the possibility of a dynamicconflict, and it is the responsibility of GRM to check if thedynamic conflict actually can happen before activating theservice actions of the rule. The procedures defined for man-aging dynamic conflicts are illustrated in Fig. 15.

When a rule marked with a dynamic conflict (DC) isready to activate its actions after its event specificationand condition are satisfied, the device requests DC check-ing to GRM as shown in Fig. 15. For this purpose,GRM asks the status of the other devices that have regis-tered the marked rules of the DC. Shortly, the devices withthe marked rules report their status (i.e., events history andconditions). GRM then determines the possibility of occur-rence of the DC based on the overall status, and informsthe devices of the result, which includes the instructionsfor service actions in case that DC is going to happen.

mic conflict detection.

Fig. 15. Procedure for dynamic conflict management.

Fig. 17. DCCR and DCRR for the dynamic conflict of Example 4.


The devices finally activate their service actions accordingto the instruction.

The structures for the dynamic conflict check rule(DCCR) and the dynamic conflict resolution rule (DCRR)are shown in Fig. 16. Note that both rules are also WS-ECA rules. The event specification of DCCR includes theevent for checking DC (eDC) and the preceding-event-set(EPrec). The eDC is an external event that will be sent fromthe device to GRM. When GRM receives eDC, it inspectsthe preceding events in EPrec from all devices that are asso-ciated with the marked rule.

Finally, Fig. 17 shows examples of DCCR and DCRRfor detecting and resolving the dynamic conflict of Example4., which is RCdyn = {(e1, {asvc

5 , asvc6 , asvc

7 }, fR50 , R60 , R70},{e7 � e8}, {c1 � c5 � c6 � c7})}. DCCR is generated auto-matically when the marked rule is registered to the device,while DCRR should be defined by an administrator.That is, users only have to define dynamic conflict resolutionrules (DCRR) according to their preferences. For example,the simplest DCRR would be an ECA rule that has truecondition and the most preferred service action. Once adynamic conflict is detected, GRM will generate internalevent DC1. Two DCRRs presented in Fig. 17 take care ofthe conflict based on the current temperature in thisexample.

Fig. 16. Schema of DCCR and DCRR.

6. Conclusions and future work

This paper presented an event-based rule descriptionlanguage, named WS-ECA, for effective coordination ofweb service-enabled devices in ubiquitous computing envi-ronment. WS-ECA enables users to describe required inter-actions among the service devices in a system wheremultiple devices exchange their events and interact witheach other based on WS-Eventing and web service invoca-tions. While existing web service based process executionlanguages such as WS-BPEL and WS-CDL are specificallyproposed for supporting long-running, transactional busi-ness processes, the proposed WS-ECA attempts to supportinstantaneous, reactive actions of web service-enableddevices upon a WS-Eventing message through providingmeans for stateless, event-based interactions.

WS-ECA rules for individual devices may have inconsis-tencies with each other and cause undesirable situationswhen they are executed concurrently, since they are created


and processed independently. To address this problem, weproposed a framework for conflict detection and resolutionof distributed WS-ECA rules. The conflicts of WS-ECArules defined for distributed devices were categorized intostatic and dynamic conflicts depending on whether the con-flict is resolved at design-time or run-time. When a rule isevaluated to contain logical contradiction with other rulesat design-time, it is said to be in a static conflict, and it can-not be registered to the system and must be modified by auser.

On the other hand, if it is judged to have any potentialdynamic conflict with others at run-time, additional rulesthat are responsible for handling the conflict by instructingsome prescribed actions to the corresponding devices needto be supplemented for the case that the conflict actuallyhappens at run-time. In this paper, we proposed necessaryconcepts and formal characterizations of WS-ECA rules,and presented algorithms for static conflict detection aswell as dynamic conflict detection and resolution. The pre-sented framework for event-driven, decentralized coordina-tion of distributed web service devices is expected tocontribute to the efficient implementation of emergingubiquitous service-based systems.

<ECARule name="alarm-clock-rules"

targetNampespace="http://di.snu.ac.kr/alarm-clock/rule

xmlns:al="http://di.snu.ac.kr/alarm-clock/type/"

xmlns="http://di.snu.ac.kr/2005/eca/">

<events>

<timeEvent type="periodic" name="get-up-time" unit="P1

0000-00-00T07:00:00Z </timeEvent>

<timeEvent type="relative" name="before-get-up-time"

baseEvent="get-up-time" interval="-PT20M"/>

</events>

<actions>

<createExtEvent name="pre-alarm"

extEvent="http://di.snu.ac.kr/event/alarm-clock/al

<al:contents>'20min before get-up'</al:contents>

</createExtEvent>

<createExtEvent name="get-up-alarm"

extEvent="http://di.snu.ac.kr/event/alarm-clock/al

<al:contents>'get-up'</al:contents>

</createExtEvent>

</actions>

<rules>

<rule name="alarm-before-get-up-rule">

<event name="before-get-up-time"/>

<condition expression="/alarm/today/@holiday='no'"

<action name="pre-alarm"/>

</rule>

<rule name="alarm-on-get-up-rule">

<event name="get-up-time"/>

<condition expression="/alarm/today/@holiday='no'"

<action name="get-up-alarm"/>

</rule>

</rules>

</ECARule>

Future work includes access control mechanism andresource management for the purpose of effective rule man-agement in ubiquitous service environments with multipleusers. For instance, authority management with ACL(Access Control Level) can be employed to resolve serviceconflicts in multi-user environments. Moreover, advancedservice monitoring and administration are also required forrobust rule management which includes the issues such asdetection and resolution of deadlock and livelock arising inubiquitous service network supporting active rule processing.

Acknowledgement

This work was supported by the Korea Research Foun-dation Grant funded by the Korean Government(MOEHRD) (KRF-2005-041-D00917).

Appendix A. WS-ECA rules for the morning cook serviceexample

A. alarm-clock.xml

s/"

D">

arm">

arm">

/>

/>


B. rice-cooker.xml

<ECARule name="rice-cooker-rules"

targetNampespace="http://di.snu.ac.kr/rice-cooker/rules/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:rc="http://di.snu.ac.kr/rice-cooker/WSDL/"


<variables>

<variable name="hasEnoughRice" deviceVar="rc:hasEnoughRice"/>

</variables>

<events>

<intEvent name="cooking"/>

<extEvent name="alarm"

eventID="http://di.snu.ac.kr/event/alarm-clock/alarm"/>

<svcEvent type="before" name="before-cooking" service="rc:cook"/>

<svcEvent type="after" name="after-cooking" service="rc:cook"/>

<compositeEvent type="SEQ" name="alarm-after-out-of-rice" TTL="PT1H">

<event name="cooking"/><event name="alarm"/>

</compositeEvent>

</events>

<actions>

<createIntEvent name="start-cooking" intEvent="cooking"/>

<createIntEvent name="detect-out-of-rice" intEvent="out-of-rice"/>

<createExtEvent name="complete-cooking" extEvent="http://di.snu.ac.kr/event/rice-

cooker/cooking-completion"/>

<invoke name="invoke-cooking" service="rc:cook"/>

<invoke name="alert-out-of-rice" service="rc:alert">

<rc:contents>out of rice</rc:contents>

</invoke>

</actions>

<rules>

<rule name="cooking-rule">

<event name="alarm"/>

<condition expression="(/alarm/contents='20min before get-up') |

(/alarm/contents='30min before dinner')"/>

<action name="start-cooking"/>

</rule>

<rule name="enough-rice-rule">

<event name="cooking"/>

<condition expression="hasEnoughRice=true"/>

<action name="invoke-cooking"/>

</rule>

<rule name="not-enough-rice-rule">

<event name="cooking"/>

<condition expression="hasEnoughRice=false"/>

<action name="detect-out-of-rice"/>

</rule>

<rule name="out-of-rice-alarm-rule">

<event name="alarm-after-out-of-rice"/>

<condition expression="/alarm/contents='get-up'"/>

<action name="alert-out-of-rice"/> </rule>

<rule name="cooking-completion-rule">

<event name="after-cooking"/>

<condition expression="true"/>

<action name="cooking-completion"/>

</rule>

</rules>

</ECARule>


C. coffee-maker.xml

<ECARule name="alarm-clock-rules"

targetNampespace="http://di.snu.ac.kr/alarm-clock/rules/"

xmlns:al="http://di.snu.ac.kr/alarm-clock/type/"


<events>

<timeEvent type="periodic" name="get-up-time" unit="P1D">

0000-00-00T07:00:00Z </timeEvent>

<timeEvent type="relative" name="before-get-up-time"

baseEvent="get-up-time" interval="-PT20M"/>

</events>

<actions>

<createExtEvent name="pre-alarm"

extEvent="http://di.snu.ac.kr/event/alarm-clock/alarm">

<al:contents>'20min before get-up'</al:contents>

</createExtEvent>

<createExtEvent name="get-up-alarm"

extEvent="http://di.snu.ac.kr/event/alarm-clock/alarm">

<al:contents>'get-up'</al:contents>

</createExtEvent>

</actions>

<rules>

<rule name="alarm-before-get-up-rule">

<event name="before-get-up-time"/>

<condition expression="/alarm/today/@holiday='no'"/>

<action name="pre-alarm"/>

</rule>

<rule name="alarm-on-get-up-rule">

<event name="get-up-time"/>

<condition expression="/alarm/today/@holiday='no'"/>

<action name="get-up-alarm"/>

</rule>

</rules>

</ECARule>

References

[1] T. Andrews et al., Business Process Execution Language for WebServices: Version 1.1, OASIS, 2003. <http://www-128.ibm.com/developerworks/library/specification/ws-bpel/>.

[2] R.J. Auburn, J. Barnett, M. Bodell, T.V. Raman, State Chart XML(SCXML): State Machine Notation for Control Abstraction 1.0,W3C Working Draft, 2005.

[3] D. Bank et al., Web Services Eventing, W3C Member Submission,2006. Available from: <http://www.w3.org/Submission/WS-Event-ing/>.

[4] N. Bassiliades, I. Vlahavas, DEVICE: compiling production rulesinto event-driven rules using complex events, Information andSoftware Technology 39 (5) (1997) 331–342.

[5] J. Bemmel, P. Dockhorn, I. Widya. Paradigm: event-driven comput-ing. Lucent Technologies, white paper, 2004. Available from:<https://doc.telin.nl/dscgi/ds.py/>.

[6] M. Berndtsson, S. Chakravarthy, B. Lings, Extending databasesupport for coordination among agents, International Journal ofCooperative Information Systems 6 (3–4) (1997) 315–340.

[7] G. vonBulltzingsloewen, A. Koschel, P.C. Lockemann, H.-D. Walter,ECA functionality in a distributed environment, in: N.W. Paton(Ed.), Active Rules in Database Systems, Springer, 1999, pp. 147–175.

[8] M. Gudgin, M. Hadley, T. Rogers, Web Services Addressing 1.0-Core, W3C Recomendation, 2006. Available from: <http://www.w3.org/TR/ws-addr-core/>.

[9] C. Bussler, S.Jablonski, Implementing agent coordination for work-flow management systems using active database systems, in: Pro-

ceedings of the International Workshop on Research Issues in DataEngineering (RIDE), 1994, pp. 53–59.

[10] S. Calo, M. Sloman, Policy-based management of networks andservices, Journal of Network and Systems Management 11 (3) (2003)249–252.

[11] A. Carter, M. Vukovic, A framework for ubiquitous web servicediscovery, in: Proceedings of the 6th UbiComp, 2004. Available from:<http://ubicomp.org/ubicomp2004/adjunct/posters/carter.pdf/>.

[12] S. Chakravarthy, E. Anwar, L. Maugis, D. Mishra, Designof sentinel: an object oriented DBMS with event-basedrules, Information and Software Technology 36 (9) (1994)555–568.

[13] K.M. Chandy, Event-driven applications: costs, benefits and designapproaches, Gartner Application Integration and Web ServicesSummit 2006, 2006. Avilable from: <http://www.infospheres.cal-tech.edu/papers/Gartner_20060620.pdf/>.

[14] J. Chomicki, J. Lobo, S. Naqvi, Conflict resolution using logicprogramming, IEEE Transactions on Knowledge and Data Engi-neering 15 (1) (2003) 244–249.

[15] M. Cilia, A. Buchmann, An active functionality service for e-businessapplications, ACM SIGMOD Record 31 (1) (2002) 24–30.

[16] J. Clark, S. DeRose, XML Path Language (XPath) Version 1.0, W3CRecommendation, 1999. Available from: <http://www.w3.org/TR/xpath/>.

[18] U. Dayal, B. Blaustein, A.P. Buchmann, S. Chakravarthy, D.Goldhirsch, M. Hsu, R. Ladin, D. McCarthy, A. Rosenthal, TheHiPAC project: combining active databases and timing constraints,ACM SIGMOD Record 17 (1) (1998) 51–70.

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

http://www.w3.org/Submission/WS-Eventing/

http://www.w3.org/Submission/WS-Eventing/

http://https://doc.telin.nl/dscgi/ds.py/

http://www.w3.org/TR/ws-addr-core/

http://www.w3.org/TR/ws-addr-core/

http://ubicomp.org/ubicomp2004/adjunct/posters/carter.pdf

http://www.infospheres.caltech.edu/papers/Gartner_20060620.pdf

http://www.infospheres.caltech.edu/papers/Gartner_20060620.pdf

http://www.w3.org/TR/xpath

http://www.w3.org/TR/xpath


[19] O. Diaz, A. Jaime, EXACT: an extensible approach to active object-oriented databases, VLDB Journal 6 (4) (1997) 82–295.

[20] F.M. Facca, S. Ceri, J. Armani, and V. Demalde, Building reactiveweb applications. In Proceedings of the 14th International WorldWide Web Conference (WWW 2005), 2005, pp. 1058–1059.

[21] A. Friday, N. Davies, N. Wallbank, E. Catterall, S. Pink, Supportingservice discovery, querying and interaction in ubiquitous computingenvironments, Wireless Networks 10 (6) (2004) 631–641.

[22] S. Gatziu, K.R. Dittrich, SAMOS: an active object-oriented databasesystem, IEEE Data Engineering Bulletin 15 (1–4) (1992) 23–26.

[23] H. Gellersen, G. Kortuem, A. Schmidt, M. Beigl, Physical prototyp-ing with Smart-Its, IEEE Pervasive Computing 3 (3) (2004) 74–82.

[24] J. Hanson, Event-driven services, in: SOA: design an event-driven andservice-oriented platform with Mule, JavaWorld, 2005. Availablefrom: <http://www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html/>.

[25] J.-Y. Jung, S.-K. Han, J. Park, K. Lee. WS-ECA: an ECA ruledescription language for ubiquitous services computing, in: Proceed-ings of the Workshop on Empowering the Mobile Web (MobEA IV)in conjunction with WWW 2006, 2006. Available from: <http://www.research.att.com/~rjana/MobEA-IV/PAPERS/MobEA_IV-Pa-per_10.pdf/>.

[26] J.M. Kahn, R.H. Katz, K.S.J. Pister, Mobile networking for SmartDust, in: Proceedings of ACM/IEEE International Conference onMobile Computing and Networking (MobiCom 99), 1999, pp. 17–19.

[27] V. Kantere, A. Tsois, Using ECA rules to implement mobile queryagents for fast-evolving pure P2P networks, in: Proceedings of the 3rdInternational Joint Conference on Autonomous Agents and Multi-agent Systems, 2004, pp. 1510–1511.

[28] N. Kavantzas, et al., Web services choreography description languageVersion 1.0, W3C Candidate Recommendation, 2005. Availablefrom: <http://www.w3.org/TR/ws-cdl-10/>.

[30] J. Lobo, R. Bhatia, S. Nagvi, A policy description language, in:Proceedings of National Conference on the American Association forArtificial Intelligence, 1999, pp. 291–298.

[31] T.S. Lopez, D. Kim, T. Park, A service framework for mobileubiquitous sensor networks and RFID, in: Proceedings of the 1stInternational Symposium on Wireless Pervasive Computing, 2006.

[32] Z. Maamar, On coordinating personalized composite web services,Information and Software Technology 48 (7) (2006) 540–548.

[33] B. Michelson, Event-driven architecture overview: event-driven SOA isjust part of the EDA story, White paper, Patricia Seybold Group, 2006.Available from: <http://www.psgroup.com/detail.aspx?ID=681/>.

[34] Microsoft, The Microsoft invisible computing project web site.Available from: <http://research.microsoft.com/invisible/>.

[35] MIT Project Oxygen web site. Available from: <http://oxy-gen.lcs.mit.edu/>.

[36] OMA: OMA Web Services Enabler (OWSER): Overview, OMA-AD-OWSER Overview-V1 1-20060328-A, 2006. Available from: <http://www.openmobilealliance.org/release program/owser v11.html./>.

[37] N.W. Paton, O. Dı´ az, Active database systems, ACM ComputingSurveys 31 (1) (1999) 63–103.

[38] C. Peltz, Web services orchestration and choreography, IEEEComputer 36 (10) (2003) 46–52.

[39] A. Sashima, N. Izumi, K. Kurumatani, Location-mediated coordi-nation of web services in ubiquitous computing, in: Proceedings ofIEEE International Conference Web Services (ICWS’04), 2004, pp.109–114.

[40] C.S. Shankar, A. Ranganathan, R. Campbell, An ECA-P policy-based framework for managing ubiquitous computing environments,in: Proceedings of the 2nd International Conference on Mobile andUbiquitous System, 2005, pp. 33–42.

[41] UPnP, The UPnP forum web site. Available from: <http://www.upnp.org/>.

[42] S. Vinoski, Integration with web services, IEEE Internet Computing 7(6) (2003) 75–77.

[43] I. Vlahavas, N. Bassiliades, Parallel, Object-oriented, and ActiveKnowledge Base Systems. Advances in Database Systems, KluwerAcademic Publishers, 1998.

[44] M. Weiser, The computer for 21st century, Scientific American 265(1991) 94–104.

[45] Y. Yokohata, Y. Yamato, M. Takemoto, H. Sunaga, Servicecomposition architecture for programmability and flexibility inubiquitous communication networks, in: Proceedings of InternationalSymposium on Applications and the Internet Workshops(SAINTW’06), 2005, pp. 142–145.

http://www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html

http://www.javaworld.com/javaworld/jw-01-2005/jw-0131-soa.html

http://www.research.att.com/~rjana/MobEA-IV/PAPERS/MobEA_IV-Paper_10.pdf



http://www.w3.org/TR/ws-cdl-10/

http://www.psgroup.com/detail.aspx?ID=681

http://research.microsoft.com/invisible/

http://oxygen.lcs.mit.edu/

http://oxygen.lcs.mit.edu/

http://www.openmobilealliance.org/

http://www.openmobilealliance.org/

http://www.upnp.org

http://www.upnp.org

an eca-based framework for decentralized coordination of ubiquitous web services

Documents