LEVELS OF ABSTRACTION IN

PROGRAMMING DEVICE ECOLOGY WORKFLOWS

Seng W. Loke, Sea Ling, Gerry Butler and Brett Gillick

School of Computer Science and Software Engineering

Monash University,

CaulfieldEast, VIC 3145, Australia

Keywords:

device ecology, workflow, abstraction levels, Web services, end-user control.

Abstract:

We explore the notion of the workflow for specifying interactions among collections of devices (which we

term device ecologies). We discuss three levels of abstraction in programming device ecologies: high-level

workflow, low-level workflow and device conversations, and how control (in the sense of operations issued

by an end-user on such workflows or exceptions) is passed between levels. Such levels of abstraction are

important since the system should be as user friendly as possible while permitting programmability not only

at high-levels of abstraction but also at low levels of detail. We also present a conceptual architecture for the

device ecology workflow engine for executing and managing such workflows.

1 INTRODUCTION

We envision device ecologies comprising collections

of devices (in the environment and on users) inter-

acting synergistically with one another, with users,

and with Internet resources, undergirded by appro-

priate software and communicating across the living

room or across nations. There has been significant

work in building the networking and integrative in-

frastructure for such devices, within the home, the of-

ﬁce, and other environments and linking them to the

global Internet. For example, UPnP (UPnP Forum,

2000a), SIDRAH (Durand et al., 2003) and Jini (Mi-

crosystems, 2001) provide infrastructure for devices

to be inter-connected, ﬁnd each other, and utilize each

other’s capabilities. Embedded Web Servers (Ben-

tham, 2002) are able to expose the functionality of de-

vices as Web services. Approaches to modelling and

programming such devices for the home have been

investigated, where devices have been modelled as

software components, collections of objects (Associ-

ation of Home Appliance Manufacturers, 2002), and

Web services (Matsuura et al., 2003). Recent work

has developed frameworks for aggregating, compos-

ing and building connections among networked de-

vices (Omojokun and Dewan, 2003; Kumar et al.,

2003; Butler, 2002; Newman et al., 2002; Kohtake

et al., 2003; Vildjiounaite et al., 2003; Sousa and Gar-

lan, 2003; Masuoka et al., 2003). However, there has

been little work on specifying at a high level of ab-

straction (and representing this speciﬁcation explic-

itly) how such devices would work together at the

user-task or application level, and how such work can

be managed. Our earlier work in (Loke, 2003) in-

troduced device ecology workﬂows as a metaphor for

thinking about how collections of these devices (or

devices in a device ecology) can work together to ac-

complish a purpose. (Rodrigues et al., 2004) investi-

gates mechanisms to permit a robot to recognize valid

commands in spoken sentences that may not be en-

tirely grammatically correct. This forms a building

block for the input of device commands.

In this paper, we deﬁne levels of abstraction for

programming device ecology workﬂows and describe

how these levels interact. We also show how work-

ﬂow operations issued by a user at one level of ab-

straction can map down to operations at another level

of abstraction and how exceptions in the lower level

can be reﬂected to the upper level. We aim to pro-

vide a framework for programming device ecologies

where new levels of abstraction can be built from

the lower levels, as needed. We contend that such a

formally grounded construction is important for task-

based programming in general (e.g., (Masuoka et al.,

2003)). Our contribution is to focus on the work-

ﬂows designated by multiple commands to different

devices, and the mapping of these workﬂows between

languages at different levels of abstraction. Since

the upper level is intended to form the user inter-

face, we represent workﬂows in an English-like lan-

guage. The lower level could be represented by lan-

guages such as BPEL4WS (Microsoft et al., 2003) or

137

W. Loke S., Ling S., Butler G. and Gillick B. (2005).

LEVELS OF ABSTRACTION IN PROGRAMMING DEVICE ECOLOGY WORKFLOWS.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 137-144

DOI: 10.5220/0002543701370144

 SciTePress

DysCo (Piccinelli et al., 2003). In our work we have

used BPEL4WS.

The rest of this paper is organized as follows. Sec-

tion 2 describes the notion of device ecology work-

ﬂows via an example and also introduces two device

ecology workﬂow languages at different levels of ab-

straction and how they formally relate to each other.

We also consider conversations with devices at the

lowest level of abstraction. The user should have con-

trol over the workﬂow execution and tasks within the

workﬂows. In Section 3, we consider how user spec-

iﬁed operations on workﬂows are related across the

different levels of abstraction and how exceptions are

reﬂected up to higher levels. We describe the concep-

tual architecture of a system for executing the multi-

layered workﬂows in Section 4 and brieﬂy outline our

current prototype. We conclude with future work in

Section 5.

2 PROGRAMMING DEVICE

ECOLOGIES

2.1 Device Ecology Workﬂows

Devices can work together with other devices, the

user (e.g., seeking approval for critical tasks) or Web

resources in accomplishing its goals, either as initi-

ated by users or by proactive smart devices. As illus-

tration, consider a device ecology workﬂow involv-

ing a television, a coffee-boiler, bedroom lights, bath-

room lights, and a news Web service accessed over

the Internet.

Figure 1 graphically depicts this workﬂow. The

dashed arrows represent sequencing, the boxes are

tasks, the solid arrow represents a control link for

synchronization across concurrent activities, and free

grouping of sequences (i.e., the boxes grouped into

the large box) represents concurrent sequences. This

workﬂow is initiated by a wake-up notice from Jane’s

alarm clock which we assume here is issued to the

Device Ecology Workﬂow Engine when the alarm

clock rings. This workﬂow can be described us-

ing BPEL4WS or other Web service workﬂow lan-

guages such as DysCo, and executed using a special-

ized workﬂow engine as outlined in (Loke, 2003).

2.2 User Command Language

One could create device ecology workﬂows as men-

tioned above using some tools. However, abbreviated

commands would make end-user programming sim-

pler. Such commands can then map down to lower

level workﬂows. We consider a small example of such

Figure 1: An Example Device Ecology Workﬂow

a two-level model. The top level is a small user com-

mand language, which we call eco, comprising com-

mands that can be combined for sequential or parallel

execution. For simplicity, we consider a device ecol-

ogy with only a few devices. Inspired by (Omojokun

and Dewan, 2003), we consider two kinds of com-

mands, those which affect a single device and those

which affect multiple devices. Commands affecting

multiple devices are directed to a pseudo device that

issues single-device commands to the appropriate de-

vices. In fact, the Device Ecology Workﬂow Engine

performs this function. It need only be provided with

a predeﬁned command set, expressed in eco, describ-

ing how to break down multi-device commands. This

procedure can be nested to any depth, where each

level of nesting corresponds either to a recursive call

to a single instance of the Engine, or to the invocation

of a separate instance.

The eco command language is deﬁned as follows

in EBNF:

Sentence ::= Clause (";" Clause)

"."

Clause ::= ActionClause | WaitClause

ActionClause ::= Prep

Opn Parm

Prep

Device

WaitClause ::= "wait for" Device

The symbols Device, Opn, Parm and Prep are

terminals. Device, which is always a noun in the

English-like language, designates the appliance that

an operation (a verb) is directed to. Parm designates

optional parameters. Prepositions (Prep) allow for the

insertion of words such as the or a to improve read-

ability. wait for speciﬁes a synchronization point.

An example of an expression in the above language

is as follows:

turn on room lights; close drapes;

show news on television.

Each of the above expressions in the language can

then be translated into a workﬂow expressed in a

lower level language. Since we assume that each de-

vice can be operated on via invocation of Web ser-

vices, this lower level language is BPEL4WS. Note

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

138

that some of the commands, although different in the

command language, might invoke the same Web ser-

vices with different parameters. The commands in the

task language are a combination of a verb and a noun,

some commands with parameters such as ‘news’. In

practice, the vocabulary of verbs and nouns can be

based on a task ontology such as CLEPE (Ikeda et al.,

1998). Alternatively, the nouns and verbs can be ex-

tracted dynamically by a service discovery process.

This is the approach we have taken here, which in-

volved dynamically creating the parser’s lexical ana-

lyzer from terminal symbols discovered at runtime.

The reason for the additional level of commands

above the BPEL4WS level is abstraction, so that the

user does not think of device ecology workﬂows in

terms of Web services but rather in terms of what

he/she observes or would expect of the devices in

everyday terms. For example, a user who does not

know anything about Web services can still com-

mand the device ecology based on the high-level com-

mands.

Moreover, many of these high-level commands are

applicable in different settings. For example, any

room that has lights can be commanded with “turn

on all lights” but such a command will translate into

a different low-level workﬂow, depending on what

lights are available in the room itself. Such transla-

tions from high-level commands to low-level work-

ﬂows can be pre-deﬁned (e.g., by an administrator

who is either a vendor or a savvy user) for each room

using methods such as that presented above. Hence,

the high-level command to turn on all lights has a dif-

ferent meaning or interpretation which is predicated

on the actual room (i.e., the actual device ecology)

the command is issued against. We term such com-

mands polydeco commands, referring to commands

whose meaning is device ecology dependent.

There would also be commands that are applica-

ble for different devices, and depending on the de-

vice, such commands will take on different mean-

ings (and interpretation). For example, the command

“switch on” can be applied to a light or to the tele-

vision and the command “open” can be applied to

drapes or to doors. We term such commands polyde-

vice commands. Similar to polydeco commands, the

actual meaning of the polydevice commands can be

pre-deﬁned, i.e., mappings from each command on a

device can be mapped to a conversation with the de-

vice.

Ideally, a user, through experience of and general

knowledge about the world, knows intuitively how to

command devices and device ecologies, and so, does

not need to learn about Web services or learn a new

command set for every room visited or for every de-

vice encountered. There will be devices that an indi-

vidual would not know about (e.g., new innovations)

or would not know the full features of - the user will

then need to learn new commands, perhaps adding to

those already available by general knowledge.

2.3 Device Ecology Workﬂows in

BPEL4WS

BPEL4WS represents concurrent execution of

processes by service invocations within a ﬂow

construct, and sequential execution by a sequence

construct. Interfaces between processes and with the

environment are represented by messages whose type

and structure can be deﬁned from primitive types.

Messages are received into variables, which form the

basis of communication between processes.

2.4 Translation

Each command in the top level language is translated

into a device ecology workﬂow in BPEL4WS. We as-

sume that there is a device ecology workﬂow engine

for executing BPEL4WS speciﬁcations - we return to

this point later. A command might be translated into

a set of alternative workﬂows in the lower level lan-

guage, where if one alternative fails during execution,

another can be tried. Eco expressions are translated

into BPEL4WS ﬂow constructs, except where the wait

operator signiﬁes sequential execution. For example,

the following expression:

turn on room lights; wait for lights;

show news on television.

is translated into the following core commands in

BPEL4WS. (assign commands have been omitted in

the interests of brevity.):

<invoke partnerLink="lights"

portType="lights:lightsSoap"

operation="turn"

inputVariable="turnIn">

</invoke>

<invoke partnerLink="television"

portType="tv:tvSoap"

operation="show"

inputVariable="showIn">

</invoke>

</sequence>

where [turn on lights] maps to a lower level

workﬂow where a number of lights are turned on (cor-

responding to a number of Web service calls) and

[close drapes] is a Web service call.

The mappings from high-level commands to lower

level workﬂows need to be kept in order that faults

at the lower level might be reﬂected up to the cor-

responding commands, since the user perceives the

commands as the units of activity.

LEVELS OF ABSTRACTION IN PROGRAMMING DEVICE ECOLOGY WORKFLOWS

139

2.5 Conversations with Devices

In the lower level workﬂow, we have assumed that

each task refers to a Web service call. In a simple

extension to this model, each such task on a device

might require a series of invocations on one or more

Web service calls on the device. For example, to turn

on a light, the system might ﬁrst make a Web service

call to query the status of the light, and if the light

is off, then make a call to another Web service (also

to the same device) to switch the light on. In short,

in general, a conversation with a device (comprising

several Web service exchanges of the kind modelled

by the Web Services Conversation Language (World

Wide Web Consortium, 2002) ) might be required for

a workﬂow task on the device.

Finite state machines can be used to model such

conversations as in (Benatallah et al., 2003). For ex-

ample, to switch the light on would involve ﬁrst in-

voking the get status service and then based on the

result returned, possibly invoking another Web ser-

vice to turn the light on. The device itself might make

calls back to the device ecology workﬂow engine that

is executing the workﬂow - for example, to notify a

subscriber who registered to be notiﬁed of an event.

UPnP devices will tend to require such conver-

sations. For example, the UPnP speciﬁcation for

a printer device (UPnP Forum, 2000b) has actions

(which can be viewed roughly as method calls) such

as GetPrinterAttributes, GetJobAttributes, CreateJob

and CancelJob. Hence, cancelling a job with a printer

might involve ﬁrst inquiring about a job before issuing

a cancel, or a task to print a document might involve

sending the job to the printer and then waiting for it to

ﬁnish (either checking the job status, or if supported,

registering to be notiﬁed of a job completion event).

3 END-USER CONTROL OF

DEVICE ECOLOGY

WORKFLOW EXECUTION:

INTER-LEVEL WORKFLOW

MANAGEMENT

Execution of a high-level device ecology workﬂow

will result in execution of low-level device ecology

workﬂows, which, in turn, will result in conversa-

tions with devices. We allow the user to control work-

ﬂow execution by issuing workﬂow operations to the

workﬂow engine.

The mapping between levels of workﬂows implies

that interruptions to workﬂow execution due to faults

will need to be reﬂected upwards to the higher level

workﬂow. For example, the command to turn on room

lights will fail if one of the lights cannot be turned

on. At this point, either a rollback occurs in which

lights turned on are switched off or in cases where

a rollback is inappropriate or impossible, some com-

pensatory action needs to be performed.

In addition, control at the higher level workﬂow

needs to be propagated to the lower levels. For exam-

ple, if the command to turn on room lights has been

issued, but the user decides to revoke this command

(or simply to terminate the higher-level workﬂow in

the midst of execution) and the resulting lower-level

workﬂow has started but not yet completed (e.g., only

one of three lights have been switched on), then the

lower-level workﬂow must also be stopped (and roll-

back or compensatory actions performed). What we

have is a situation akin to nested transactions in data-

bases. However, we have greater complexity in the

case where several different operations are possible

on device ecology workﬂows, including start, stop,

but also operations such as suspend and resume, undo

(similar to rolling back), which when issued for a

high-level workﬂow must be reﬂected down to lower-

levels, and from the lower-levels down to the indi-

vidual workﬂow task level (i.e. to the device con-

versations). For example, a cancel operation on a

task of a high-level workﬂow might translate down

to cancelling the corresponding low-level workﬂow

which in turn translates down to cancelling a device

conversation. But different possible translations are

possible. Suppose that a low-level workﬂow instance

is executing and in the middle of a conversation be-

ing carried out with the device, cancelling the corre-

sponding low-level workﬂow translates down to cer-

tain other service invocations to reverse the state of

the device, instead of simply stopping the conver-

sation. Also, cancelling a high-level workﬂow task

might translate down not to cancelling the low-level

workﬂow but triggering certain compensatory tasks.

For greater ﬂexibility, what is required is a means to

specify the translation semantics of operations on the

high-level workﬂow to operations on the low-level

workﬂow, and of operations on the low-level work-

ﬂow to operations on device conversations.

In the following subsections, we introduce opera-

tions on tasks and operations on workﬂows and illus-

trate their correspondences.

3.1 Operations on a Task

Given a task in a workﬂow, the state diagram in Fig-

ure 2 shows the operations on the task and what states

the task would move to as a result. A task can be in

any of ﬁve states: not started, executing, suspended,

completed, and abnormally terminated, and the al-

lowable operations are deﬁned to be start, cancel,

done, undo, pause, and resume. Not all the opera-

tions make sense in all the states, and so the diagram

only shows the operations which makes sense in each

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

140

Figure 2: State diagram for operations on a task.

of the states. Moreover, only changes on the task

state due to the operations are shown, and not the ef-

fects of the operations on the devices (or the devices’

states). The task state is stored within the device ecol-

ogy workﬂow engine.

A task either maps to a (1) conversation in the case

of the task being within a low-level workﬂow, or to

a (2) low-level workﬂow in the case of the task be-

ing within a high-level workﬂow (e.g., the task is a

high-level single device or multidevice command as

in Section 2).

1. If a task involves a conversation with the device,

the task state of “executing” would mean that the

conversation is happening and service calls are be-

ing made with the device, “suspended” would mean

that no service calls are currently being made even

if some calls have already been made (e.g., in the

middle of a conversation) and so, resuming would

mean the conversation with the device is contin-

ued, “completed” would mean that the conversa-

tion completed normally as pre-speciﬁed, and “ab-

normally terminated” would mean that the task did

not involve a conversation that completed based on

what is prescribed as normal (the conversation was

abruptly cancelled). Typically, we do not expect

it be possible to cancel or pause in the middle of

a service call, and so, a cancel or pause issued to

the task while a service call is made will take ef-

fect only after the call has returned. However, it is

sometimes possible to terminate an on-going oper-

ation of a device - e.g., cancelling a print job.

Starting a task would mean beginning a conversa-

tion between the device ecology workﬂow engine

and the device. Operations start, cancel, pause, and

resume have the same semantics for different de-

vices, whereas the operation undo would depend

on the device. The device can either provide an

undo service call which reverses effects since the

start of the conversation (or a compensatory ser-

vice call (e.g., as deﬁned in (Benatallah et al., 2003)

for Web services in general) for non-reversible ef-

fects to compensate for effects since the start of the

conversation), or an undo (a compensatory) service

call for identiﬁed calls in the conversation. For

example, a light might support service call(s) to

switch it on and off, which have complementary

effects. If the device provide no such (effect re-

versal or compensatory) calls, then the effect of a

user’s request to undo a task cannot be effectively

performed by the device ecology workﬂow engine,

i.e. undo might be supported on some devices but

not for others. Sometimes, it is not that a device

doesn’t support compensatory service calls but that

it is physically impossible to undo an action. For

example, cancelling a submitted and queued (but

not yet executed) print job is possible, whereas re-

versing a print job where the document has already

been printed is not.

2. If a (high-level) task maps to a low-level workﬂow,

the operations on the high-level task then maps to

operations on the corresponding workﬂow, as ex-

plained in the next two subsections.

3.2 Operations on a Workﬂow

We can now deﬁne operations on a (high-level or low-

level) workﬂow in terms of corresponding operations

on tasks within the workﬂow.

• To start a workﬂow would mean to start the ﬁrst

task of the workﬂow.

• To cancel a workﬂow would mean to cancel all

tasks of the workﬂow, whether the tasks have not

yet been started, or suspended (a completed task

cannot be cancelled but might be undone). Com-

pleted tasks are not affected. A cancellation should

be issued after a pause.

• To undo a workﬂow is to undo all completed or ter-

minated tasks, and can only be carried out if all the

tasks are either completed or terminated (e.g., if the

workﬂow has been cancelled). An undo should be

issued after completion or cancellation of the work-

ﬂow.

• To pause a workﬂow is to suspend all currently ex-

ecuting tasks.

• To resume a workﬂow is to resume all currently

suspended tasks.

Workﬂows for businesses have explored operations

such as cancel (Aalst et al., 2003) but the operations

we attempt to support are richer here since substan-

tial control needs to be provided for users of device

ecologies.

LEVELS OF ABSTRACTION IN PROGRAMMING DEVICE ECOLOGY WORKFLOWS

141

Figure 3: An example mapping from operation X on a

high-level workﬂow operation to corresponding operations

on tasks in a low-level workﬂow. The down arrows denotes

‘translates down.’

3.3 Correspondence of Operations in

High-Level Workﬂows with

Operations in Low-Level

Workﬂows

Operations on high-level workﬂows are mapped to

operations on tasks within the high-level workﬂow in

the manner described earlier. But an operation on

a task of a high-level workﬂow, where the task is

mapped not to a conversation with a device but to

a low-level workﬂow, will be mapped to an opera-

tion on the low-level workﬂow. The operation on a

low-level workﬂow then maps to operations on tasks

within the low-level workﬂow in the manner desribed

earlier.

Figure 3 shows an example route where an opera-

tion on a high-level workﬂow is mapped to operations

on tasks within a low-level workﬂow. n operation X

on a high-level workﬂow (issued by the user say) is

mapped to operation X on three tasks P, Q, and R

of the workﬂow. Each of these operations are sub-

sequently mapped down to device conversations. The

ﬁgure shows the mapping for the operation X on task

P. Because task P corresponds to a low-level work-

ﬂow W, the operation X on P is effectively an opera-

tion X on W. The operation on the workﬂow W is then

mapped to operation X on task A and B in W. The op-

eration X on task A (involving device A, say) and the

operation X on task B (involving device B, say) will

result in conversations via calls to Web services for

device A and for device B.

Using our example on turning on lights, once a

workﬂow for

turn on all lights; wait for lights;

open drapes.

has been issued, it will start to execute. After

some time, before completion, if the user now issues

a pause command, the command will be translated

down to the task level, and the workﬂow will be sus-

pended according to the semantics given above. The

aim of the operations on tasks and operations on the

workﬂows is to allow user control (at user’s will) over

them, even during their execution.

3.4 Handling Faults

So far, we have not considered in detail the map-

ping upwards of faults occurring in service calls dur-

ing conversations to faults in low-level workﬂows and

then to faults in high-level workﬂows.

Mapping rules are required in order to deﬁne how

an exception in a service call within a conversation

will be manifested at the high-level workﬂow, and ul-

timately to users. Depending on such deﬁnitions, the

response to an exception might be to cancel and undo

operations (including compensatory actions). More-

over, some faults might not be reﬂected up to higher

levels and need only be dealt with at a lower level. If

a high level task corresponds to two alternative low-

level workﬂows, a fault in one low-level workﬂow can

be handled by ﬁrst undoing the effect of the parts of

this workﬂow that has executed and then starting the

alternative workﬂow. Alternatively, some effects of

operations might not be rolled back or compensated

but can be safely ignored - depending on the applica-

tion scenario.

As example, consider the high-level task to turn on

all lights in the room. Such a high-level task translates

down to a low-level workﬂow and on execution of

the low-level workﬂow, perhaps only two of the three

lights are successfully turned on (say light 2 is faulty).

One way to handle the problem is ignore the fault and

continue with the other tasks in the workﬂow, which

makes sense in this example. Another way to handle

this fault is to undo the entire workﬂow (undoing any

successful operations before encountering the fault -

switching light 1 off) and stop. A third way to handle

the problem is to suspend the workﬂow when the fault

is encountered (say detected when the service call to

light 2 fails) and query the user about what to do (e.g.,

to undo the workﬂow or ignore the fault). The ﬁrst so-

lution is less obtrusive, to silently (with respect to the

user) ignore faulty operations and complete the work-

ﬂow, but logging faults detected for future analysis

and reporting. All three solutions can be supported by

the device ecology workﬂow engine but the actual be-

haviour in a particular workﬂow has to be pre-deﬁned

(again by an administrator or a savvy user).

Solutions to deal with dynamic changes in work-

ﬂow have been discussed at a higher-level of abstrac-

tion in terms of business process (Aalst, 2001). Some

of the techniques can be applied to our work, but the

focus will be on dealing with device failure and ser-

vice failure.

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

142

Figure 4: Multilayered Conceptual Architecture for Device

Ecology Workﬂow Engine

4 PROTOTYPE ARCHITECTURE

AND CURRENT

IMPLEMENTATION

The conceptual architecture for the engine that ex-

ecutes and manages device ecology workﬂows is

shown in Figure 4. Roughly, each layer of the archi-

tecture shows the components required to manage a

level of abstraction. Note that user operations on an

executing workﬂow such as cancel, pause, etc, can

be issued during workﬂow execution - not shown in

the diagram. The system keeps track of the corre-

spondences between device conversations and the as-

sociated tasks in the low-level workﬂow, and between

tasks in the high-level workﬂow and the associated

low-level workﬂows, in order that exceptions are cor-

rectly reﬂected up (if required) through the abstrac-

tion levels. If there is an exception in a call to de-

vice, it can be traced to its corresponding low-level

workﬂow task and then to its corresponding high-

level workﬂow task. For example, if there is an ex-

ception in the call to switch on a light, it can be traced

to the high-level task of turning on all lights, and the

system might report to the user that there is an error

in carrying out that high-level task but allow the user

to drill down to speciﬁc faults in the lower levels.

We are currently developing a prototype of our

system with a subset of BPEL4WS as the low-level

workﬂow language. Figure 5 shows the DecoFlow ap-

plication with a sample BPEL4WS document loaded

for visualisation. On the left side of the editor win-

dow is a tree displaying all of the information ob-

tained from the BPEL4WS document. On the right

hand side is the visualisation of the BPEL4WS doc-

ument which is represented by a series of connected

nodes which represent the process and activities from

the BPEL4WS document.

Figure 5: DecoFlow application with a sample BPEL4WS

document

5 CONCLUSION AND FUTURE

WORK

We have discussed three levels of abstraction: high-

level workﬂow, low-level workﬂow and device con-

versations, involved in programming device ecology

workﬂows, and how inter-level control is passed be-

tween levels. Such levels of abstraction are important

since the system should be as user friendly as possible

while permitting programmability not only at high-

levels of abstraction but also at low levels of detail.

We can consider more than the three levels of ab-

straction. One can iteratively build higher level com-

mand languages over the top level command lan-

guage, allowing workﬂows to be speciﬁed at an even

higher level of abstraction, but all linked within a uni-

form formal model. Future work also involves con-

tinuing our prototype implementation of our model

in a device ecology workﬂow engine which supports

the translation semantics and fault handling schemes

described earlier, and to extend our BPEL4WS low-

level workﬂow language with tasks that link to con-

versation speciﬁcations. Moreover, other work on dy-

namically selecting devices for a particular task such

as (Kumar et al., 2003; Butler, 2002) are complemen-

tary to our work - techniques can be considered in

using semantics to select devices for a workﬂow at

run-time. We are also working on methods to analyze

device ecology workﬂows before execution (Loke and

Ling, 2004). We are also working on an ontology of

polydeco and polydevice commands.

ACKNOWLEDGEMENTS

We would like to thank the Australian Research

Council for partial funding of this work.

LEVELS OF ABSTRACTION IN PROGRAMMING DEVICE ECOLOGY WORKFLOWS

143

Trademarks. UPnP is a trademark of UPnP Forum.

Jini is a trademark of Sun Microsystems.

REFERENCES

Aalst, W. (2001). Exterminating the dynamic change bug:

A concrete approach to support workﬂow change. In-

formation Systems Frontiers, 3(3):297–317.

Aalst, W., Hoftede, A., Kiepuszerski, B., and Barros, A.

(2003). Workﬂow patterns. Distributed and Parallel

Databases, 14(3):5–51.

Association of Home Appliance Manufacturers (2002).

Connected Home Appliances Object Modelling, CHA-

1-2002. Available at http://www.aham.org/.

Benatallah, B., Casati, F., Toumani, F., and Hamadi, R.

(2003). Conceptual Modelling of Web Service Con-

versations. Technical Report HPL-2003-60, HP Labs.

Bentham, J. (2002). TCP/IP Lean: Web Servers for Embed-

ded Systems (2nd Edition). CMP Books.

Butler, M. (2002). Using Capability Proﬁles for Appliance

Aggregation. Technical Report HPL-2002-173, HP

Labs.

Durand, Y., Vincent, S., Marchand, C., Ottogalli, F., Olive,

V., Martin, S., Dumant, B., and Chambon, S. (2003).

SIDRAH: A Software Infrastructure for a Resilient

Community of Wireless Devices. In Proceedings of

the Smart Objects Conference (SOC’03), Grenoble.

Ikeda, M., Seta, K., Kakusho, O., and Mizoguchi, R.

(1998). An Ontology for Building a Conceptual Prob-

lem Solving Model. In ECAI98 Workshop on Applica-

tions of ontologies and problem-solving model, pages

126–133, Brighton, England.

Kohtake, N., Matsumiya, K., Takashio, K., and Tokuda, H.

(2003). Smart Device Collaboration for Ubiquitous

Computing Environment. In Proceedings of the Work-

shop on Multi-Device Interface for Ubiquitous Periph-

eral Interaction at the 5th International Conference on

Ubiquitous Computing (UbiComp’03).

Kumar, R., Poladian, V., Greenberg, I., Messer, A., and

Milojicic, D. (2003). Selecting Devices for Aggrega-

tion. In Proceedings of the WMCSA 2003 (to appear).

Loke, S. (2003). Service-Oriented Device Ecology Work-

ﬂows. In Orlowska, M., Weerawarana, S., Papa-

zoglou, M., and Yang, J., editors, Proceedings of the

International Conference on Service-Oriented Com-

puting, Lecture Notes in Computer Science 2910,

pages 559–574, Trento, Italy. Springer-Verlag.

Loke, S. and Ling, S. (2004). Analyzing Observable Behav-

iours of Device Ecology Workﬂows. In Proceedings

of the 6th International Conference on Enterprise In-

formation Systems, pages 78–83, Portugal.

Masuoka, R., Parsia, B., and Labrou, Y. (2003). Task Com-

puting - the Semantic Web meets Pervasive Comput-

ing. In Proceedings of the 2nd International Semantic

Web Conference (ISWC 2003), Florida, USA.

Matsuura, K., Haraa, T., Watanabe, A., and Nakajima, T.

(2003). A New Architecture for Home Computing. In

Proceedings of the IEEE Workshop on Software Tech-

nologies for Future Embedded Systems (WSTFES03),

pages 71–74.

Microsoft, IBM, Siebel, BEA, and SAP (2003). Business

Process Execution Language for Web Services Version

1.1. Available at http://www-106.ibm.com/

developerworks/library/ws-bpel/.

Microsystems, S. (2001). Jini Network Technology. Avail-

able at http://wwws.sun.com/software/jini/.

Newman, M., Sedivy, J., Edwards, W., Smith, T., Marcelo,

K., Neuwirth, C., Hong, J., and Izadi, S. (2002). De-

signing for Serendipity: Supporting End-User Conﬁg-

uration of Ubiquitous Computing Environments. In

Proceedings of the Conference on Designing Interac-

tive Systems (DIS2002). Available at http://www.cs.

berkeley.edu/˜jasonh/publications/dis2002-speakeasy

-browser.pdf.

Omojokun, O. and Dewan, P. (2003). A High-Level

and Flexible Framework for Dynamically Composing

Networked Devices. In Proceedings of the 5th IEEE

Workshop on Mobile Computing Systems and Appli-

cations (WMCSA 2003).

Piccinelli, G., Finkelstein, A., and Williams, S. (2003).

Service-Oriented Workﬂows: the DySCo Framework.

In Proceedings of the Euromicro Conference, Antalya,

Turkey. Available at http://www.cs.ucl.ac.uk/

staff/A.Finkelstein/papers/euromicro2003.pdf.

Rodrigues, M., Teixeira, A., and Lopes, L. S. (2004). An

Hybrid Approach for Spoken Natural Language Un-

derstanding Applied to a Mobile Intelligent Robot. In

Sharp, B., editor, Proceedings of the 1st International

Workshop on Natural Language Understanding and

Cognitive Science, Portugal.

Sousa, J. and Garlan, D. (2003). From Computers Every-

where to Tasks Anywhere: The Aura Approach. In

Submitted. Available at http://www-2.cs.cmu.edu/

˜aura/docdir/sg01.pdf.

UPnP Forum (2000a). UPnP Device Architecture. Avail-

able at http://www.upnp.org/.

UPnP Forum (2000b). UPnP DeviceType: Printer Device

Template Version 1.01. Available at http://www.upnp.

org/.

Vildjiounaite, E., Malm, E., Kaartinen, J., and Alahuhta,

P. (2003). Networking of Smart Things in a Smart

Home. In Proceedings of the Workshop on the Inter-

action of HCI and Systems Issues in UbiComp (UBI-

HCISYS 2003) at the 5th International Conference on

Ubiquitous Computing (UbiComp’03). Available at

http://ubihcisys.stanford.edu/online-proceedings/

Ubi03w7-Vildjiounaite-ﬁnal.pdf.

World Wide Web Consortium (2002). Web Services Con-

versation Language (WSCL) 1.0. Available at http://

www.w3.org/TR/2002/NOTE-wscl10-20020314/.

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

144