SERVICE REALIZATION AND COMPOSITION ISSUES IN THE

HOMECARE DOMAIN

Alireza Zarghami, Mohammad Zariﬁ Eslami, Brahmananda Sapkota and Marten van Sinderen

Department of Electrical Engineering, Mathematics and Computer Science

University of Twente, Enschede, The Netherlands

Keywords:

Homecare, Independent living, Service realization, Service composition, SOA, Homecare platform, Wellbe-

ing.

Abstract:

Most of the industrialized countries are facing a new situation which is the increasing number of elderly

people and the enormous cost of associated healthcare. IT-based homecare services have been proposed as a

solution to alleviate this problem. However, the adoption of the homecare services is hindered by the fact that

there are many heterogeneous IT solutions, which prevent interoperability and integration of existing as well

as future applications. Service-Oriented Architecture and its advantage of service composition in a loosely-

coupled manner are being considered as a promising approach to promote interoperability. In this paper, we

explain our motivation for and understanding of a generic service-oriented homecare platform. We consider

the SOA paradigm and its idea of logical separation of concerns to deﬁne a service realization and composition

framework and to identify its challenges in order to realize and compose the homecare services. Using our

framework, we evaluate three academic homecare projects to see how they address the identiﬁed challenges.

The work presented in this paper helps researchers to understand the state-of-the-art of homecare-related

platforms and technologies; and to outline issues for further research in the homecare domain.

1 INTRODUCTION

The population of many Western-European countries

have an increasing percentage of elderly people and,

consequently, the healthcare-related cost for these

countries is growing (European Commission, 2007).

Providing automated care support for elderly in their

own home, i.e., homecare services, is proposed as

a highly desirable solution to alleviate the problem

of the growing healthcare related cost, and conse-

quently has attracted attention from the ICT indus-

try (European Commission, 2007) (Gassner and Con-

rad, 2010). Homecare service provisioning often uti-

lizes a set of heterogeneous software and hardware

solutions which must cooperate seamlessly. A com-

prehensive solution, like a common platform to make

them interoperable, is still an open research area. Dis-

tributed, dynamic and heterogeneous environments

increasingly challenge the goal of homecare services

(Bricon-Souf et al., 2005)(Bottaro et al., 2008).

The recent progress in ubiquitous computing, Re-

mote Monitoring and Treatment (RMT), and do-

motic applications leads to many useful components

and technologies for the homecare services provi-

sioning. Therefore, an integration solution which

can bring all these components and technologies to-

gether seems more interesting than any time before.

SOA with its service composition principle provides

a promising approach for homecare platforms that

support seamless cooperation of heterogeneous tech-

nology solutions. Several efforts to deﬁne such a

service-oriented platform have been undertaken (Bot-

taro et al., 2008)(Mikalsen et al., 2009)(Gray et al.,

2007). We believe in service-oriented homecare plat-

forms and therefore, we aim to explain our motivation

for and understanding of such a platform.

The homecare services hosted on the platform can

be composed and realized at different levels, from low

level hardware devices to high level end-user applica-

tion services. To elaborate these composition hierar-

chy, we deﬁne a service realization and composition

framework to show different layers of functionality

while each layer employs the services, i.e, functional-

ities of its lower layer and provides new functionali-

ties for its next higher layer. The lower layers mostly

concern about service realization while the higher lay-

ers concern about service composition.

Our objective is to deﬁne a service realization and

composition framework consisting of several func-

tional layers, for a generic SOA-based homecare plat-

347

Zarghami A., Zariﬁ Eslami M., Sapkota B. and van Sinderen M..

SERVICE REALIZATION AND COMPOSITION ISSUES IN THE HOMECARE DOMAIN.

DOI: 10.5220/0003630203470356

In Proceedings of the 6th International Conference on Software and Database Technologies (ACT4SOC-2011), pages 347-356

ISBN: 978-989-8425-76-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

form to position and classify related challenges as

well as their corresponding solutions which are al-

ready utilized. As such, the proposed framework out-

line issues for further research on homecare service

realization as well as composition challenges. The

framework can also be used to explain the state-of-

the-art with respect to homecare platforms, showing

how these platforms address the challenges at differ-

ent layers.

The remaining of this paper is organized as fol-

lows: In Section 2, we discuss interoperability from

information and behaviour perspectives, and how ex-

isting service-oriented homecare platforms tackle the

interoperabilitychallenges. We also clarify our under-

standing of a generic homecare platform. In Section

3, we explain some of interoperability issues in the

homecare domain which are used to classify the chal-

lenges in our framework. In Section 4, we elaborate

our service composition framework. In Section 5, we

map three homecare-related academic projects to our

framework to evaluate their approaches with respect

to the identiﬁed challenges. Finally, in Section 6, we

conclude and discuss our work and explain our plan-

ning of future work.

2 SOA AND HOMECARE

The adoption of homecare services is hindered by

the fact that there are many heterogeneous ICT solu-

tions, which prevent interoperability and integration

of existing as well as future applications. To this

end, Service-oriented Architecture and its advantage

of service composition in a loosely-coupled manner

are being considered as a promising approach to pro-

mote interoperability (Bottaro et al., 2008) (Mikalsen

et al., 2009) (Gray et al., 2007) (Nee et al., 2008).

2.1 Role of SOA in Homecare

The complexity of interoperability and its mul-

tifaceted characteristics lead to several deﬁni-

tions (Kosanke, 2006). The IEEE Glossary deﬁnes

interoperability as ”the ability of two or more systems

or components to exchange information and to use the

information that has been exchanged” (IEEE, 1990).

System can be understood in terms of different per-

spectives such as information and behavior. The in-

teroperability challenges can be considered based on

these different perspectives of systems.

The interoperability challenges from the infor-

mation perspective can be seen as the difﬁculty in

sharing information between systems due to differ-

ences in coding, formatting and data representation

schemes. An existing homecare platform, SAPHIRE,

employs a cross-enterprise document sharing archi-

tecture to tackle information interoperability like dis-

covery of and access to relevant electronic health

records(EHR) (Nee et al., 2008). The interoperabil-

ity challenges from the behaviour perspective can

be seen as the difﬁculty in using each others func-

tions due to differences in the protocols at which

they are used. Another existing homecare platform,

MPOWER, introduces a solution based on SOA and a

message translator pattern to provides interoperability

services for Ambient Assisted Living (AAL) environ-

ment (Mikalsen et al., 2009).

2.2 Homecare Platform

An application platform, according to ISO/IEC

14252, is deﬁned as ”a set of resources, includ-

ing hardware and software that support the ser-

vices on which application software will run” (IEEE,

1998). By homecare platform, we mean an applica-

tion platform which provides technology-independent

services for homecare applications in the sense that it

hides the complexity of underlying software and hard-

ware entities. The platform employs a set of physical

devices like to provide services which are utilized by

homecare applications. The platform services are ac-

cessible through a set of interfaces that make the char-

acteristics of underlying technology as transparent as

possible.

Social

carers

Care

center

Care providers

Controlled

service

Third-party

service

Medicine

dispenser

Homecare application

platform

Homecare

applications

Internet

External

applications

Care receiver

Remote

monitoring

services

Figure 1: The overall view of a generic homecare platform.

Our overall view of a generic homecare platform

is shown in Figure 1. There are four types of stake-

holder who interact with the homecare platform and

applications. The Care receivers, live at the place, for

instance, apartment where the platform has been in-

stalled. They uses a set of interfaces either computer-

based GUI or physical devices like a Medicine dis-

penser to receive care services. On the other hand,

the Care providers, either professional from a Care

center or Social carers like the neighbors and friends,

provide care services through the platform. They can

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

348

even act as an application developer, to create a new

application based on exiting platform services (pro-

vided by the platform or the applications) or tailor

the current applications for a speciﬁc care receiver.

The Controlled services providers, as the third type

of stakeholder, provide the components which are in-

stalled within the platform, for example, a Medicine

dispenser. The platform should provide standard in-

terfaces for the Controlled services providers to install

and manage the life cycle of their components, with-

out interfering the operation of other components.

The fourth type of stakeholder is the Third-party ser-

vice providers whose services are accessible through

the Internet and can be exploited by applications run-

ning on the homecare platform. For instance, the Re-

mote monitoring services provided by MobiHealth

can be used by other homecare applications to check

oxygen saturation and blood pressure of the Care re-

ceivers. MobiHealth can have its own infrastructure

and devices like COPD sensors inside the home sepa-

rate than the homecare platform.

3 INTEROPERABILITY ISSUES

To achieveinteroperabilityfor the homecare platform,

distribution, heterogeneity and dynamicity (Bottaro

et al., 2008) should be addressed in design and imple-

mentation time. In this subsection, we explain these

issues and their causes in homecare domain.

Distribution. In distributed system, a reliable

medium for communication and seamless addressing

is considered as an interoperability challenge. The

medium should provide location transparency and

hide the complexity of underlying communication in-

frastructure. Care receivers and care providers should

be able to use services provided by homecare appli-

cations which are located in different places, for in-

stance, different rooms, through the platform. Care

providers may use homecare applications from both

inside and outside home. External services provided

by the Third-party service providers should be acces-

sible through the Internet for the Homecare applica-

tions.

Heterogeneity. Interoperability is especially hard to

achieve if distributed systems are made up of het-

erogeneous subsystems that are developed, managed

and/or owned by different organizations. From the

software point of view, the applications might follow

different protocols for discovery (e.g., WS-Discovery,

SLP), interaction (e.g., SOAP,RMI) and transporta-

tion (e.g. TCP, UDP). From a hardware point of

http://www.mobihealth.com/

view, they can have different capabilities varying

from a resource-constrained sensor to a computing

device with high computation resources. The soft-

ware and hardware heterogeneity arise a set of con-

straints which should be taken into account in imple-

mentation time.

Dynamicity. We deﬁne dynamicity in homecare do-

main as any type of change and demand which makes

current behaviour of homecare applications not de-

sired for the stakeholders. The changes and demands,

coming from the care receiver, homecare applications

and environment, can arise dynamicity either in short-

term or long-term (McBryan et al., 2008). From care

receiver point of view, some of the dynamicity like a

visual impairment development occur over a long pe-

riod of time and can be addressed in design time. On

the other hand, some others like location and activity

might change in short-term and must be handled in

runtime. From a system point of view, most changes

like device availability and location, are short-term.

As long-term systems’ dynamicity, we can mention

relocation of physical devices, for example, the clos-

est medicine dispenser to the kitchen, after the relo-

cation of physical devices, is not the closest one any-

more.

4 SERVICE COMPOSITION

FRAMEWORK

As explained before, a generic homecare platform en-

hances the creation of new homecare applications and

tailoring the current applications for a speciﬁc care

receiver. We propose a service realization and com-

position framework to show different functional lay-

ers and to identify corresponding challenges. To add

to the understanding of our framework deﬁnition, we

demonstrate functionality of the layers based on two

well-known application scenarios for homecare appli-

cations as follows:

• Remote Medicine Prescription. A doctor col-

lect information about health condition like oxy-

gen saturation of John, as an elderly who has

minor form of COPD (Chronic obstructive pul-

monary disease ), living in a home equipped with

homecare services. The doctor may requires ex-

tra information such as John’s position (for ex-

ample, training or bed room) along with his oxy-

gen saturation. The doctor can set different oxy-

gen saturation thresholds for different positions

of John, for instance, bedroom or training room

to be notiﬁed. John can consult with the doc-

tor through a audio/video communication on his

SERVICE REALIZATION AND COMPOSITION ISSUES IN THE HOMECARE DOMAIN

349

Tablet(Tablet PC) or PDA (Personal Digital As-

sistant) and ﬁnally the doctor prescribes the neces-

sary medicine. A medicine dispenser device will

be programmed based on the prescription.

• Medicine Reminder. The homecare services will

remind John of taking the medicine on time. This

reminder message can be shown through Tablet

or PDA based on the John’s preferences. For in-

stance, if he is in living room, he prefers to see the

message on the Tablet instead of PDA.

We demonstrate our framework in three steps.

First, we explain our methodology for deﬁning the

framework. Second, we explain the functionality and

the composition relationships of the layers. By com-

position relationship we mean that a layer composes a

set of functionalities provided by the layer lower than

itself (except the lowest layer). Third, we discuss the

challenges imposed by the homecare-related interop-

erability issues for each of the composition relation-

ships. Due to service composition hierarchy, we de-

ﬁne the composition relationships between the layers.

4.1 Methodology

The functional aspect of homecare services are the

concerns of the work presented in this paper and thus

we focus on interoperability challenges from the be-

haviour perspective. We consider behaviour perspec-

tive because it allows us to look at the systems be-

haviour while using each others’ functions. It is dif-

ﬁcult to relate the information interoperability to the

functional layers as deﬁned in our framework. There-

fore, we do not consider information interoperability

challenges in this paper.

In order to classify challenges and break them

down to smaller ones, we employ the functional lay-

ering of SOA as deﬁned in (Arsanjani, 2004), as the

basis for deﬁning our service realization and compo-

sition framework. The service-oriented architecture

provides guidelines to achieveinteroperabilitythat as-

sists different organizations to be dynamically inte-

grated regardless of their technologies, platform and

application speciﬁcation. The SOA paradigm can be

considered as a set of distinct layers of abstractions

which describes a logical separation of concerns (Ar-

sanjani, 2004). Each layer employs the functionalities

of its lower layer and provides new functionalities for

its next higher layer.

Based on the work presented in (Arsanjani, 2004),

we deﬁned a service realization and composition

framework as a set of ﬁve functional layers. These

layers are numbered 1 to 5 and cover differentaspects,

of a homecare domain, spanning from low level hard-

ware devices to high level end-user application ser-

vices. The lowest layer is numbered 1 and the highest

layer is numbered 5 as shown in Figure 2. The lay-

ers are deﬁned such that each layer employs the func-

tionalities of its lower layer and provides new func-

tionalities to its next higher layer. Given two layers of

the proposed framework, a layer is considered lower

than the other if it covers more concrete entities of the

homecare domain. This means that the lower layers

are mostly concerned about service realization while

the higher layers are mostly concerned about service

composition. This kind of layering is useful in analyz-

ing problems in the homecare domain in a systematic

way.

In the proposed framework, physical devices like

sensors are located in the lowest layer which is num-

bered 1. The software components which realize

service interfaces to communicate with the physical

devices are placed on the next layer which is num-

bered 2. The software components which provide a

uniform service layer on top of all the existing ser-

vice interfaces to hide the heterogeneity and distribu-

tion of underlying components are placed in the layer

which is numbered 3. A set of basic functionalities

which can be composed and conﬁgured by the care

providers to create homecare applications are placed

in the layer which is numbered 4. This layer hides

the details of concrete implementations of the lower

layers. The highest layer, which is numbered 5, con-

tains the homecare applications which directly inter-

act with care receivers.

4.2 Functionality of the Layers

Our proposed homecare service realization and com-

position framework is shown in Figure 2. The left

part shows a functional layering which are provided

by homecare applications. The right part presents a

platform which provides several services like messag-

ing and coordination to the application functional lay-

ers. The platform enhances the development and ex-

ecution of the homecare applications. Since, we aim

to emphasize on service realization and composition

challenges from the application point of view, we do

not discus the platform part in this paper. Not to men-

tion, communication relationships among geographi-

cally distributed systems are established through the

platform. Composition relationships among layers

are shown by a line ended with circle and can have

1:n and 1:1 cardinality which will be individually dis-

cussed in each layer.

Figure 3 shows an instance of the service hierar-

chy of the homecare applications for the two scenarios

which is mentioned in the beginning of this section.

The lines between layers show the composition rela-

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

350

Hardware

layer (HW)

Component

-based

services (CS)

ICT

services

(IS)

Service

building

block (SBB)

End-user

application

services (EAS)

Homecare application

platform

Homecare applications

Concrete

service

...

Concrete

service

...

Context

service

...

Virtual

device #1

Virtual

device #n

Physical

device #1

Physical

device #n

Figure 2: Service hierarchy of the homecare applications.

SBB

EAS

service

Medicine

dispenser

Position

sensors

Tablet

PDA

Location

service

Video session

manger

Audio session

manger

Reminder

Notific

-ation

Consult-

ing

Monit-

oring

Remote medicine

prescription

Medicine

reminder

PDA virtual

device

Tablet virtual

device

Location

server

MD virtual

device

Monit-

oring

Figure 3: An instance of the service hierarchy of the home-

care applications for the two scenarios.

tionships which follow the cardinality of relationships

between layers shown in Figure 2.

Hardware (HW). In the this layer, we have a set of

physical devices such as sensors, actuator and multi-

media interfaces. For the target scenarios, we can

mention position sensors, medicine dispenser, Tablet

and PDA. The COPD sensors to check oxygen satura-

tion is managed by the Third-party service providers,

therefore the platform does not have any responsibil-

ity for the COPD sensor and we do not consider it

in this layer. The positioning sensors are employed

to determine John’s location. The constituents of the

HW layer can only provide their functionalities to

their representative components located in the next

higher layer. Therefore, any interaction with the de-

vices located in the HW layer, should be done through

their corresponding virtual devices implemented in

the Component-based services (CS) layer. The com-

position relationship between HW and CS layer has

1:1 cardinality. It means that for each physical de-

vice in the HW layer, there is only one representative

Virtual device in the CS layer.

Component-based Services (CS). In this layer, we

have a set of virtual devices which can be seen as

service realization out of the physical devices in the

lower layer. In general, the virtual devices realize the

services by three main strategies: wrapper, adapter

and generic service interface. As the wrapper, a soft-

ware component, encapsulates a physical device and

provides its own service interface like a OSGi bundle

(Gray et al., 2007). As the adapter, a software com-

ponent or an application, plays an intermediary role

between the physical devices and the upper functional

layer. For instance, a component so-called frame sen-

sor adapter (FSA) allows to uniformly collect data

from sensors (Loniewski et al., 2009). As the generic

service interface, the virtual devices provide a set of

generic interfaces to call physical devices. The Con-

trolled services providers who produce the physical

devices can implement the interfaces in their own. For

the target scenarios, MD (medicine dispenser) virtual

device provides access to program and activate the

physical Medicine dispenser.

ICT Service (IS). In this layer, we have two type of

services: Context and Concrete services. Context ser-

vices aggregate raw data from one or several virtual

devices to infer whether trigger a particular event or

not. Accordingly, the composition relationship be-

tween the IS and CS layers has 1:n cardinality. We

deﬁne the Concrete services to hide the heterogeneity

and distribution of the virtual devices and to provide

a uniform protocol to discoverand interact with them.

The Concrete services have two main functionalities:

mediation and messaging. The mediation provides in-

teroperability between two or several virtual devices

which might use different discovery and interaction

protocols. The messaging provides transparent com-

munication with the virtual devices. These two func-

tionalities are supported by the platform services. For

the target scenarios, the Video session manager pro-

vide a uniform access for Tablet and PDA virtual de-

vices to mange a video communication session with

a standard protocol like SIP (Session Initiation Pro-

tocol). The video streaming infrastructure is consid-

ered as part of the platform. The Monitoring con-

crete service is provided by the Third-party service

providers through the platform services over the In-

ternet without any corresponding virtual device in our

framework.

Service Building Block (SBB). In this layer, we place

homecare related service building blocks (SBB), i.e.,

the smallest manageable services, which cannot be

broken down further into smaller services from the

care providers’ point of view. However, from the plat-

form’s point of view, these services might exploit one

or several of the Concrete services provided by the

IS layer. For instance, the Reminder service employs

the Location service to identify John’s location and

SERVICE REALIZATION AND COMPOSITION ISSUES IN THE HOMECARE DOMAIN

351

remind him through Audio session manager or Audio

session manager. Therefore, the SBB layer has 1:n

composition relationship with the IS layer. In our sce-

narios, from the care providers’ point of view, there

are several SBBs like MD and Reminder. The SBBs

are reusable and context-independent basic services

which can be composed to create and tailor home-

care applications. Each of the SBBs can be seen as

a service interface with a set of operations. Beside

the SBBs, the homecare applications needs a set of

events to implement their logics. Due to the SOA

paradigm, we deﬁne the Notiﬁcation services to han-

dle these events. The Notiﬁcation is deﬁned based on

one or several events triggered by the services located

in the IS layer. For instance, a medicine reminder

notiﬁcation to trigger Medicine reminder application

can be deﬁned based on two events, the availability of

the medicine dispenser and John being at a predeﬁned

place.

End-user Application Services (EAS). In this layer,

we place the homecare applications which are repre-

sented by a set of service plans to fulﬁll the home-

care scenario objectives. For instance, the objective of

the Medicine reminder scenario is to remind the care

receiver to take medicine on time. The service plan

speciﬁes the application behaviour in runtime and can

be deﬁned by composing services. Each homecare

application has one or several service plans consist of

one or several SBBs. Therefore, the composition rela-

tionship between the EAS and the SBB layer has 1:n

cardinality. We classify the functionality of this layer

in three steps: generation, evaluation and transforma-

tion. In the ﬁrst step, a service plan is generated by

the care providers based on existing service interfaces

of SBBs. In the second step, the service plan should

accommodate the care receiver’s preferences and the

runtime situation of the environment, to prioritize the

alternative possibilities of service execution. In the

third step, the service plan must be transformed to an

executable composed service by mapping the service

interfaces to concrete service providers like an avail-

able medicine dispenser.

4.3 Challenges between the Layers

As mentioned in our methodology, we focus on

the interoperability challenges of systems as under-

stood from the behaviour perspective in the home-

care domain. We associate the interoperability chal-

lenges with the composition relationships between

the functional layers as deﬁned in our framework.

These challenges which are categorized into the three

homecare-related interoperability issues (explained in

Section 3), are discussed below:

HW-CS. The composition relationship between these

two layers is one-to-one. This means that from the IS

layer there is no distinction between physical devices

and their corresponding virtual devices. Therefore,

we do not consider any dynamicity and distribution

challenges in this composition relationship. However,

we consider the heterogeneity challenge because the

hardware devices could come from different manu-

facturers and with different proprietary solutions. We

identify three challenges with respect to device het-

erogeneity. a) Behaviour: providing a uniform ser-

vice interface for the physical devices despite their

heterogeneous behaviour is a tough challenge. The

uniform service interface should support both static

and non-static characteristics of the behaviour of the

virtual devices. Different virtual devices, for exam-

ple, can have the same static characteristics like ser-

vice interface signature with different non-static char-

acteristics like various order of function access. b)

Resource-constrained devices: having various phys-

ical devices with resource limitations (e.g., memory

size, computation power) leads to several constraints

on their usage. c) communication: physical devices

could have different communication protocols which

the virtual devices should support to provide commu-

nication protocol transparency or even location trans-

parency.

CS-IS. The composition relationship between these

two layers is many-to-one. This means that one

ICT service could communicate with one or more

component-based services. Therefore, we consider

dynamicity, heterogeneity and distribution challenges

in this composition relationship. Speciﬁcally, we

identify three challenges with respect to dynamicity.

a) Life-cycle of virtual devices: providing a cooper-

ation environment is required to enable several Con-

trolled services providers to manage their component

life-cycle (for example, install and conﬁgure) without

interfering other components’ operations. b) Plug-

and-Play support: availability of the virtual devices,

in homecare environment, is not guaranteed. The vir-

tual devices should be allowed to register itself to the

system automatically and be operational as soon as

they become available. c) Dynamic binding: specify-

ing concrete virtual devices in service plan is difﬁcult

because the virtual devicescould come and go. There-

fore, the platform should bind the service plan to the

concrete virtual devices based on runtime situation.

We identify one challenge with respect to the het-

erogeneity. Discovery/Interaction protocols: deﬁni-

tion of the CS layer implies that there should be no

heterogeneity issue above that layer. However, some

strategies used by the CS layer like the generic service

interface, only address the heterogenous behaviour of

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

352

the virtual devices. Therefore, there is a need be-

tween CS and IS layers to support different discovery

(for example, WS-Discovery, SLP) and interaction

(for example, SOAP, RMI) protocols. We also iden-

tify one challenge with respect to distribution. Loca-

tion transparency: component-based services could

be physically distributed. In that case, providing a lo-

cation transparent communication infrastructure is a

challenge.

IS-SBB. The composition relationship between these

two layers is many-to-one. This means that one ser-

vice building block could communicate with one or

more IS services. We assume that the IS layer hides

all issues related to distribution and heterogeneity.

Therefore, we consider only the dynamicity chal-

lenges in this composition relationship. We identify

three challenges with respect to dynamicity. a) QoS-

aware provisioning: providing information about dy-

namic QoS of home network (Bottaro et al., 2008)

which is used as the underlying communication tech-

nology in the homecare domain (for example, dy-

namic bandwidth) is essential to improve the home-

care application performances. It is required to bind

SBB to more reliable services which can decrease the

possible future interoperability problems that may ap-

pear otherwise, i.e., if the SBB is bound to unreliable

services. b) Runtime matching: in runtime, the plat-

form might bind a particular SBB to various concrete

services due to their (un)availabilityin differenttimes.

This can be done by automatically matching the avail-

able concrete services with the SBBs. By using QoS

information provided by the IS layer, even in case of

availability of several concrete services, the platform

can bind the SBBs to the most reliable concrete ser-

vice. c) Generic SBB model: providing a generic

mechanism to model the SBBs, understandable for

both the platform and care providers, is considered

as a challenge, specially due to the complexity of the

behaviour of the services provided by the lower layers

and their dynamic QoS which are not known at design

time. The SBBs should have two representations: in-

ternal and external. The internal view is used to be

interpreted by the platform while the external format

is used to present the SBBs to the care providers.

SBB-EAS. The composition relationship between

these two layers is many-to-one. This means that one

end-user application service could be composed by

one or more SBBs. In this composition relationship,

we consider only the dynamicity challenges but not

the heterogeneity and distribution challenges because

of the same reason as mentioned in IS-SBB compo-

sition relationship. We identify two challenges with

respect to dynamicity. a) Runtime adaption: in run-

time, if there is no available concrete services for a

speciﬁc SBBs, the platform has to adapt the service

plan itself by substituting that SBB with one or sev-

eral other SBBs whenever possible. It can automati-

cally compose, for instance, a set of available SBBs

to fulﬁll the functionality of one particular SBB. The

service plan adaption should be able to accommodate

the information about QoS of services provided by the

lower layer for the most reliable adaption. b) Simple

service plan: To have a realistic solution, with respect

to large variety of possibly changes coming from both

the care receivers and homecare applications, provid-

ing a convenient approach for the care providers to

assist them in generating the service plan is an essen-

tial need. The summary of these challenges are shown

in Table 1.

Table 1: The summary of challenges between the

functional layers (Dy:Dynamicity, Hg:Heterogeneity,

Ds:Distribution).

Interoperability challenges Dy Hg Ds

SBB-EAS

Runtime adaption X

Simple service plan X

IS-SBB

QoS-aware provisioning X

Runtime matching X

Generic SBB model X

CS-IS

Life-cycle of virtual devices X

Plug-and-play availability X

Dynamic binding X

Discovery/Interaction protocols X

Location transparency X

HW-CS

Behaviour X

Resource-constrained devices X

Communication X

5 EVALUATION

Based on our study, there are two well-known tech-

nologies exploited by homecare applications: OSGi

and web services. To cover a wide range of solutions

in SOA-based homecare applications, we have stud-

ied academic homecare projects from the both afore-

mentioned technologies. We have selected three of

these projects as examples to show the feasibility of

our proposed framework. They use discrete heuris-

tics in each of the layers as deﬁned in our frame-

work. The three selected projects are as follows:

(1) MATCH

(Mobilising Advanced Technologies for

Care at Home), (2) MPOWER

(Middleware Plat-

form for eMPOWERing cognitive disabled and el-

derly), (3) Amigo

(Ambient Intelligence for the net-

worked home environment).

http://www.match-project.org.uk/main/main.html

http://www.sintef.no/Projectweb/MPOWER/

http://www.hitech-projects.com/euprojects/amigo/

SERVICE REALIZATION AND COMPOSITION ISSUES IN THE HOMECARE DOMAIN

353

Table 2: The technologies and solutions are employed by the three projects.

Match(1) MPOWER(2) Amigo(3)

EAS XML, Directed graph BPEL, UML service models BPEL, OWL-S

Interactive evaluation Online semantic reasoning

SBB XML, Interaction model WSDL, IBM UML Proﬁle OWL-S, Amigo-S

OWL-based events Rule-based notiﬁcation

IS Message broker component Open ESB Middleware

SDP and SIP meditation

CS OSGi, UPnP Platform-independent models OSGi, .NET, UPnP

Wrapper Adapter Generic service interface

HW Residential gateway Proprietary framework (FSA) Domotic infrastructure

Table 2 summarizes the technologies and solu-

tions exploited by these projects in each of the func-

tional layers as deﬁned in our framework. Moreover,

Table 3 shows to what extent these projects support

the identiﬁed interoperability challenges for each of

the functional layers. In continue, we explain the two

tables together from the lowest layer and gradually

move to upper layers.

In the HW layer, Match uses OSGi component,

i.e., bundles to represent physical devices. With re-

spect to Resource-constrained devices, these bundles

are located in a residential gateway or any intermedi-

ary which has JVM installed and can communicate

with their corresponding devices through heteroge-

neous Communication protocols. MPOWER exploits

a proprietary framework, so-called Frame Sensors

Adapter (FSA), to collect data from several sensors.

MPOWER delegates management of heterogeneous

Communication protocols and Resource-constrained

devices to FSA. Amigo has developed a domotic in-

frastructure to decouple the technologies used in the

HW layer from the virtual devices in the CS layer.

The infrastructure supports heterogeneous Communi-

cation protocols and employs C as programming lan-

guage to deal with Resource-constrained devices.

In the CS layer, Match uses OSGi to manage the

dynamicity of Life-cycle of virtual devices. It utilizes

UPnP protocol to address Plug-and-play support by

providing simpliﬁed installation upon internet-based

communication protocols. The OSGi bundles address

the heterogeneity of Behaviour of physical devices

by using wrapping techniques. MPOWER employs

a platform-independent model which can be realized

on several platforms such as web services, .NET,

CORBA and J2EE. We could not ﬁnd explicit infor-

mation with respect to the support for Life-cycle of

virtual devices and Plug-and-Playsupport in the liter-

ature concerning MPOWER. MPOWER uses the FSA

as an adapter to hide the heterogeneous behaviour of

the physical devices. Amigo develops a middleware

which can be installed on individual platforms to sup-

port both OSGi and .Net standards or even indepen-

dent of both of them. It also follows OSGi and UPnP

based techniques as used in Match to support Life-

cycle of virtual devices and Plug-and-play support.

Amigo has developed a domotic service model spec-

iﬁcation to address the heterogeneity of behaviour

of physical devices. The virtual devices can use the

generic service interface instead of directly commu-

nicating with the heterogeneous physical devices.

In the IS layer, Match has developed its own mes-

sage broker for the messaging functionality of the

Concrete services. This broker is implemented by a

OSGi bundle to address dynamic binding and Loca-

tion transparency. As Match has employed wrapping

in the CS layer, there is no need for the mediation

and the heterogeneity of Discovery/Interaction proto-

cols are already supported by the CS layer. MPOWER

has deﬁned an enterprise service bus based on Open

ESB for the messaging. It supports Location trans-

parency but it does not completely support Dynamic

binding (for example, dynamic endpoints). MPOWER

like Match also does not need the mediation due to

use of adapter in the CS layer. Amigo has devel-

oped an interoperable middleware core which pro-

vides service discovery protocols (SDP) and service

interaction protocols (SIP). The SDP addresses the

heterogeneity of Discovery protocols by parsing the

input protocol and composing the target output pro-

tocol. The SDP dynamically instantiates a stub from

the description and reference of the services. The stub

which addresses the heterogeneity of Interaction pro-

tocols and Location transparency, can act as interme-

diary mediation. None of these three projects, pro-

vide QoS-aware provisioning. It means that runtime

matching and adaption in the SBB and EAS layers, are

completely unaware of the quality of Concrete ser-

vices during runtime.

In the SBB layer, Match describes the SBBs in

XML format from very abstract level to concrete

interaction interface, similar to Concur Task Trees

(Mori et al., 2004). The abstract level can be used as

the external language for the care providers to support

Generic SBB model. This simplicity is enhanced by a

technology-agnostic description of services written in

OWL (Web ontology languages) to associate a set of

predeﬁned events to their possibly corresponding vir-

tual devices, using human-understandable concepts.

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

354

The ability of SBBs interface matching (McBryan

et al., 2008) supports the dynamic Runtime match-

ing. However, it does not accommodate the QoS

of the corresponding Concrete services. MPOWER

has deﬁned SBBs as WSDL ﬁles for the internal pur-

poses. Due to the complexity of WSDL for unskilled

users, IBM UML proﬁle for software services (John-

ston, 2005) has been exploited as the external lan-

guage to address Generic SBB model. We could not

ﬁnd explicit support mentioned in the publications of

MPOWER for Runtime matching. Amigo develops the

Amigo-S language based on OWL-S to describe ser-

vices for both external and internal language with dif-

ferent levels of abstraction to address Generic SBB

model. Moreover, Amigo provides rule-based aware-

ness and notiﬁcation services (ANS) which can en-

hance Generic SBB model for the Notiﬁcation ser-

vices. Amigo-S is part of a comprehensive approach

towards semantic service description, discovery, com-

position, adaption and execution (SD-SDCAE) which

speciﬁes QoS as well as behaviour of services. It

uses runtime semantic reasoning to support Runtime

matching.

Finally, in the EAS layer, Match uses directed

graph to deﬁne service plan, by matching the SBBs

interaction interfaces (McBryan et al., 2008). It gen-

erates several service plans for a target scenario by

traversing all possible paths in the graph. The ab-

stract service plan, excluding detailed service inter-

face, supports Simple service plan. The possible multi

traversal paths enable the platform to provide Runtime

adaptionby generatingalternativeservice plans based

on available concrete services at runtime. However,

QoS is not considered to evaluate possible alterna-

tive service plans. MPOWER has a set of predeﬁned

UML service models which are implemented by its

own domain-speciﬁcmodeling language (DSML) and

understandable for care providers. Based on the target

scenario and the existing service plan models, it gen-

erates the service plan and transforms it to executable

composed service using BPEL standard. We could

not ﬁnd explicit support mentioned in the publications

of MPOWER, for the support of Runtime adaption. In

Amigo, to address Simple service plan, tasks are mod-

eled by abstract workﬂow based on semantic contex-

tual model which is created by a user-friendly GUI. In

runtime, by using semantic service discovery, several

alternative service plans are generated by composing

available Concrete services in different ways. The

Runtime adaption is addressed by runtime semantic

reasoning. Although the service plans can be eval-

uated based on QoS and context properties, due to

lack of QoS-aware service provisioning, the Runtime

adaption is partially supported. Finally, the service

plan is transformed to an executable composed ser-

vice using BPEL standard.

Table 3: The challenges addressed by the three projects

(Supported:S, Partially supported:P, Not supported:N).

Challenges (1) (2) (3)

SBB-EAS

Runtime adaption P N P

Simple service plan S S S

IS-SBB

QoS-aware provisioning N N N

Runtime matching P N S

Generic SBB model S S S

CS-IS

Life-cycle of virtual devices S N S

Plug-and-play availability S N S

Dynamic binding S P S

Discovery/Interaction protocols S S S

Location transparency S S S

HW-CS

Behaviour S S S

Resource-constrained devices S S S

Communication S S S

6 CONCLUSIONS

In this paper, we introduce a functionality layering

framework to analyze the issues related to service re-

alization and composition in the homecare domain.

This framework is useful for both the service devel-

opers as well as the researchers. Developers can sys-

tematically breakdown the problems in different lay-

ers and ﬁnd the corresponding solutions whereas the

researchers can use the framework to ﬁnd issues in the

existing solutions. We also discussed what interoper-

ability challenges exist between different functional

layers. This helps developers and domain experts to

identify such challenges pertaining to the homecare

domain without the need of a speciﬁc methodology to

apply the proposed framework for the same purpose.

Finding the related works to compare the pro-

posed framework was one of the difﬁculties we faced

while performing the work presented in this paper. To

the best of our knowledge, the proposed framework is

the ﬁrst one that attempts to classify service realiza-

tion and composition issues in the homecare domain.

A service composition framework introduced in (Rao

and Su, 2005) assumes availability of services and fo-

cuses on automatic service composition. In the home-

care service provisioning, availability of the homecare

services is not a valid assumption. Due to several low

level hardware devices which might be employed by

the homecare service provisioning, service realization

challenges should also be taken into account.

We used our framework to analyze three exist-

ing SOA based homecare projects and to demon-

strate the applicability of the proposed framework.

Though we selected only three SOA based homecare

projects, the proposed framework can be used to an-

SERVICE REALIZATION AND COMPOSITION ISSUES IN THE HOMECARE DOMAIN

355

alyze other SOA based homecare projects to investi-

gate to what extend the identiﬁed challenges are ad-

dressed by them. Analysis of larger number of SOA

based homecare platforms would even help us deﬁne

homecare challenges more accurately and even to re-

ﬁne the proposed framework. If we perform a large

scale analysis of homecare platforms we could pos-

sibly identify some new challenges or the challenges

which are already identiﬁed may disappear. Such a

large scale analysis, however, would require more re-

search efforts and is left as part of our future work.

Based on our study, we observed that existing so-

lutions can handle distribution and heterogeneity is-

sues. However, the dynamicity issues, which affects

almost all the functional layers and plays an impor-

tant role in homecare service realization, are not well

addressed and therefore further research is required.

With respect to dynamicity, the service plan should

be simple but detailed enough to enable the home-

care platform to match and adapt them to the avail-

able concrete services at runtime in a lightweight and

QoS-aware manner. With this observation, we aim at

addressing these issues in our future works.

ACKNOWLEDGEMENTS

This work is part of the IOP GenCom U-Care

project(http://ucare.ewi.utwente.nl) which is spon-

sored by the Dutch Ministry of Economic Affairs un-

der contract IGC0816.

REFERENCES

Arsanjani, A. (2004). Service-oriented modeling and archi-

tecture. IBM developer works.

Bottaro, A., Simon, E., Seyvoz, S., and Gerodolle, A.

(2008). Dynamic web services on a home service plat-

form. In Proc. 22nd Int. Conf. Advanced Information

Networking and Applications, pages 378–385.

Bricon-Souf, N., Anceaux, F., Bennani, N., Dufresne, E.,

and Watbled, L. (2005). A distributed coordination

platform for home care: analysis, framework and pro-

totype. Int. J. of Medical Informatics, 74(10):809–

825.

European Commission (Jun. 2007). Ageing well in the in-

formation society - an i2010 initiative - action plan

on information and communication technologies and

ageing. Technical report, EU.

Gassner, K. and Conrad, M. (nstitute for Innovation and

Technology (IIT), March 2010). ICT enabled inde-

pendent living for elderly - A status-qua analysis on

products and the research landscape in the ﬁeld of

Ambient Assisted Living (AAL) in EU-27.

Gray, P. D., McBryan, T., Hine, N., Martin, C. J., Gil,

N., Wolters, M., Mayo, N., Turner, K. J., Docherty,

L. S., Wang, F., and Kolberg, M. (2007). A scalable

home care system infrastructure supporting domicil-

iary care. Technical report, Department of Computing

Science and Mathematics University of Stirling.

IEEE (December 1998). IEEE guide for developing user or-

ganization open system environment (OSE) proﬁles,

Portable Applications Standards Committee, IEEE

Computer Society. IEEE Std 1003.23-1998.

IEEE (New York, NY, 1990). Institute of electrical and elec-

tronics engineers: Ieee standard computer dictionary:

A compilation of ieee standard computer glossaries.

Johnston, S. (2005). Uml 2.0 proﬁle for software

services. IBM developerWorks http://www. ibm.

com/developerworks/rational/library/05/419 soa.

Kosanke, K. (2006). Iso standards for interoperability: a

comparison. Interoperability of Enterprise Software

and Applications, pages 55–64.

Loniewski, G., Ramon, E., Walderhaug, S., Mar-

tinez Franco, S., Cubillos Esteve, J., and Marco, E.

(2009). Data Management in an Intelligent Environ-

ment for Cognitive Disabled and Elderly People. Elec-

tronic Healthcare, pages 50–57.

McBryan, T., McGee-Lennon, M. R., and Gray, P. (2008).

An integrated approach to supporting interaction evo-

lution in home care systems. In PETRA ’08: Proceed-

ings of the 1st Int. Conf. on Pervasive Technologies

Related to Assistive Environments, pages 1–8, New

York, NY, USA. ACM.

Mikalsen, M., Hanke, S., Fuxreiter, T., Walderhaug, S.,

Wienhofen, L., and Trondheim, N. (2009). Inter-

operability services in the MPOWER Ambient As-

sisted Living platform. Stud Health Technol Inform,

150:366–70.

Mori, G., Paterno, F., and Santoro, C. (2004). Design and

development of multidevice user interfaces through

multiple logical descriptions. IEEE Transactions on

Software Engineering, 30(8):507–520.

Nee, O., Hein, A., Gorath, T., Hulsmann, N., Laleci, G. B.,

Yuksel, M., Olduz, M., Tasyurt, I., Orhan, U., Do-

gac, A., Fruntelata, A., Ghiorghe, S., and Ludwig,

R. (2008). Saphire: intelligent healthcare monitoring

based on semantic interoperability platform: pilot ap-

plications. IET Communications, 2(2):192–201.

Rao, J. and Su, X. (2005). A survey of automated web ser-

vice composition methods. In Cardoso, J. and Sheth,

A., editors, Semantic Web Services and Web Process

Composition, volume 3387 of LNCS, pages 43–54.

Springer Berlin / Heidelberg.

ICSOFT 2011 - 6th International Conference on Software and Data Technologies

356