a soap-based system for the provision of e-servicesa system architecture, which partially fulfils...

www.elsevier.com/locate/csi

Computer Standards & Interfaces 26 (2004) 527–541

A SOAP-based system for the provision of e-services

Vassilis Kapsalis*, Konstantinos Charatsis, Manos Georgoudakis,Efstratios Nikoloutsos, George Papadopoulos

Industrial Systems Institute, University Campus, Building A, Rion, 26500 Patras, Greece

Received 28 January 2004; received in revised form 13 March 2004; accepted 23 March 2004

Available online 16 April 2004

Abstract

This paper describes an open-architecture system for the provision of e-services to home residents, consisting of healthcare,

safety and security services. The proposed system exploits the open Internet standards and is based on the hub-and-spoke

connection model between home users and service providers, through an intermediate entity called service aggregator. Health

status of each residential user, together with safety and security parameters are monitored and stored locally in each user’s home

system. Periodically, the measured values are transmitted and stored at the corresponding service providers’ databases.

Furthermore, each measured value is checked for the detection of alarms, which initiates notification transmissions to specific

users and/or service providers. The access rights to monitor/control the home system(s), retrieve historical data and configure

operation parameters are granted to several types of users based on their authorization level.

D 2004 Elsevier B.V. All rights reserved.

Keywords: e-Services; SOAP; Web Services; Internet; Home automation

1. Introduction The provision of wide-ranging householder and

Web has become a standardized infrastructure for a

great number of diverse applications, including,

among others, access to information, communication,

e-commerce, energy management and sophisticated

telemedicine applications. This standardized infra-

structure guarantees accessibility and usability advan-

tages to the whole range of participants including end-

users, operators and service providers.

0920-5489/$ - see front matter D 2004 Elsevier B.V. All rights reserved.

doi:10.1016/j.csi.2004.03.008

* Corresponding author. Tel.: +30-2610-910299; fax: +30-

2610-910303.

E-mail address: [email protected] (V. Kapsalis).

URL: http://www.isi.gr.

small business services using communications is a

developing major market in the deregulation of ener-

gy, communications and services era. The market for

services is large with, as yet, no ‘‘killer’’ application

identified which can on its own justify the services

infrastructure. Service bundling is required, within

which each service contributes to the financial viabil-

ity of providing the services to large numbers of

beneficiaries. Technologies have been developed

which enable services to be bundled together that

use different communication media and protocols

within the household.

Depending on their use, residences and workplaces

present a very challenging environment for the devel-

opment of a wide range of e-services. Although very

V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541528

different in nature, all these services may be devel-

oped over a common technological infrastructure,

which should bear specific characteristics such as

openness, conformance to emerging or de facto com-

mercial standards, modularity, distribution and flexi-

bility. According to recent international survey results,

e-services that give the ‘‘peace-of-mind’’ (security,

safety alerts and healthcare) are considered to be of

great importance both for the end-users and the

service providers [1].

Security is a well-established business sector with

plenty of traditional security companies in the market.

The huge installed base of security systems worldwide

has proven that this is of major importance for cus-

tomers. However, traditional security systems have not

yet adopted the new concept of ‘‘system integration’’

within the home. These systems constitute simply

isolated automation islands with restricted ability for

communication (costly and inflexible gateways) and

interoperability with others systems inside (HVAC,

lighting, etc.) and outside the home (through Internet).

The safety alert market is a relatively new one.

Insurance companies are naturally interested because

certain forms of house damage could be avoided. A

home insurance provider might offer a lower rate

based on the existence of certain safety measures such

as active leak, moisture, carbon monoxide and fire

detection, as well as other safety concerns. This service

could be provided both by insurance and security

companies and could be combined with security and/

or healthcare services, too. The bundle of services that

could be delivered by each provider depends on the

provider’s business model and the aimed target group.

Healthcare represents a market with great potential

for service providers. The capability to continuously

monitor critical care parameters from elderly or dis-

abled and transmit this information, in case of emer-

gency, to hospitals, physicians or paramedical services

reduces cost and increases the sense of safety and

security. Key drivers of this market are the constantly

increasing aging population that desire to live indepen-

dently, and the bridging of the geographical distances.

2. Related work

Several systems have been implemented for the

provision of healthcare services over Internet. Their

main functionality focuses on collecting measurement

data from off-the-shelf devices, store them locally and

subsequently transmit them to a central database for

access by experienced health personnel. The system in

Ref. [2] collects ECGs from the patient in his/her

home, through a Web interface and the data transfer to

a central repository takes place by means of a separate

FTP session. The system in Ref. [3] is a Win32

application, which communicates with a commercial

instrument that collects blood glucose levels (BGL)

and stores the measurements locally. Measured data is

transmitted to a central storage server using the server-

to-server protocol (STSP), which is an extension to

HTTP. The system in Ref. [4] uses a Java applet for

the collection and secure transmission of glucose data

to a central database over an Internet connection. The

system in Ref. [5] enables the capturing and the

transmission of video (through a web browser plug-

in) to a web site, together with patient-filled health

status surveys, by using the secure HTTPS protocol.

Both patients and doctors can access this web site to

monitor health status longitudinally.

A common feature of all these healthcare systems

is that they focus on a single application (measurement

of a specific biomedical parameter) and the transmis-

sion to a central server. These systems have not been

designed, in order to support several diverse services,

e.g., safety, security, etc., over the same networking

infrastructure, simultaneously. If a new application

(service) were required, a different system architecture

would be needed, in order to support it, which should

implement system and user access levels, as well. In

addition, all these systems are based on a point-to-

point connection model between home users and the

corresponding service provider, which coincides with

the central server. Each home user is connected

directly with his/her service provider (e.g., health

provider) in order to transfer (upload) measured data

or to access (download) historical data values. The

main features of this model are summarized below [6].

In the point-to-point model, the service providers

have to keep a separate network connection with each

home. The number of point-to-point connections

between n service providers and m home systems is

potentially up to n�m. In addition, the gateway,

which will constitute the entry point to each home

network, must implement advanced firewall function-

ality for protection from unwanted traffic and hacking

V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 529

attacks, a serious drawback for a common residential

user. Furthermore, the service providers need to know

about the particulars of each connected home net-

work, its protocols, gateway dialect and devices. If the

configuration of a home network changes, for instance

by replacing a gateway or the ISP, all service pro-

viders that provide services to this client must update

their databases. Finally, security administration, to

control which devices and operations the service

providers are allowed to access, is spread between

different Web sites, potentially having different user

interfaces and even security models.

A system capable to support several heterogeneous

automation subsystems within a building/industrial

environment was presented in Ref. [7]. The main

feature was the introduction of Web Gateway, in-

stalled in the end-user’s site, in order to allow diverse

service providers to offer their services in a uniform

way, through Internet. However, it suffers the draw-

backs mentioned above imposed by the point-to-point

architecture.

OSGi specification [8] is a general-purpose, man-

aged Java software framework that supports the de-

ployment of extensible and downloadable service

applications, known as bundles. The OSGi framework

facilitates the installation and operation of multiple

services on a single Open Services Gateway (set-top

box, PC, Web phone or dedicated residential gateway).

The specified APIs address service cradle-to-grave life

cycle management, interservice dependencies, data

management, device management, client access, re-

source management and security. However, the scope

of the OSGi specification does not cover the aspects of

the infrastructure required for a Web Services deploy-

ment and operation through an intermediate server [9].

For the most part, the specification concentrates on

many aspects of the local network. A remote manage-

ment specification that addresses issues, such as access

control, protection of the end user’s privacy, process-

ing of payments in a secure manner, protection of the

user from malicious interference, etc., which are

crucial for the deployment of services from service

providers, is still lacking from the OSGi specification

[10]. An approach based on the OSGi specification is

followed in a video-surveillance application, which is

described in Ref. [11]. The system introduced a remote

manager, capable to manage the service gateways and

the bundles running on them. Because there was a

direct point-to-point connection link between end-

users or service providers and the service gateways

for monitoring and control purposes, it suffers the

drawbacks of the point-to-point connection model.

A system architecture, which partially fulfils the

missing parts of the OSGi specification, through the

introduction of an intermediate server, called remote

manager, is presented in Ref. [10]. The system is

capable to manage OSGi-based service gateways. The

specified tasks for the remote manager include system

management, service publishing, monitoring of ser-

vice usage, creation of billing reports, communication

with the home gateways, scheduling of batch jobs, etc.

However, taking into account the plethora and diver-

sity of communication and automation technologies in

the home and building area, including LNS [12], EHS

[13], UPnP [14], etc., the feature of supporting OSGi-

based service gateways, only, makes these systems

quite restrictive and tightly coupled to Java language.

Furthermore, it requires that every home is equipped

with an OSGi-compliant service gateway.

The Panoramixk platform [15] introduced recent-

ly by Echelon is a scalable, enterprise-grade software

designed to reside in a corporate-owned or hosted data

centre and communicates across the Internet or a

private IP network to remote sites containing Lon-

Works networks of smart devices. The LonWorks

networks communicate with the data centre through

the exchange of SOAP messages, following a Web

Services approach. However, the system is based on

Echelon’s i.LONk 100 Internet Server and thus, as

tightly coupled with the LonWorks technology, can be

considered as a proprietary solution.

3. System architecture

This paper presents an integrated approach for the

effective provision of a bundle of e-services to home

residents, in a cost-effective way by using the prevail-

ing and open Internet standards. The proposed archi-

tecture is based on the hub-and-spoke connection

model, using an intermediate server called Service

Aggregator (SA), which is able to integrate and

manage a great number of diverse e-services to home

residents. Under this model, a number of Service

Providers (SPs) will be able to exploit a basic common

infrastructure installed in the residents’ homes, in


order to provide a bundle of heterogeneous e-services.

SPs only need to talk to the SA, who takes care of all

the details for each individual home network in a

transparent way. In contrast to the point-to-point

model, the number of connections between n SPs

and m home networks is potentially up to n +m instead

of n�m. The SA is able to support multiple device

control standards, gateway types and communication

protocols, on behalf of the SPs. Home residents and

SPs can access their networks, through an access

control mechanism in the SA, dealing with the assign-

ment of authorization rights to the underlying services.

The communication is based entirely on the SOAP

messaging protocol [16], which is a simple and

lightweight XML-based mechanism for exchanging

structured data between network applications. SOAP

is the chosen protocol for many reasons:

It is the standardized enveloping mechanism for

communicating document-centric messages and

remote procedure calls using XML.

It is simple; it is basically an HTTP POST with an

XML envelope as payload.

It is preferred over simple HTTP POST of XML

because it defines a standard mechanism to

incorporate orthogonal extensions to the message

using SOAP headers and a standard encoding of

operation or function.

Fig. 1. End-to-end sys

The use of the Web Services approach based on open

Internet standards for end-to-end communication pro-

vides a high degree of flexibility in the supported

platforms and device networks, overcoming the dis-

advantages of vendor-dependent (e.g., Panoramixk)

and language-dependent approaches (e.g., OSGi).

Each home network that can provide a SOAP API

can be easily integrated into the entire system, irre-

spective of its device networking technology and the

specific implementation details.

The proposed system implements a three-tier ar-

chitecture, which consists of the following layers, as

illustrated in Fig. 1.

Home layer: This layer encompasses the home

server and the following home subsystems:

Medical (healthcare) subsystem for monitoring of

vital signs.

Safety subsystem in order to detect life-threatening

conditions such as fire.

Security subsystem for intrusion detection.

Service Aggregator (SA) layer: The SA acts as an

intermediary between home and SP layers, allowing

remote access and control in a uniform and secure way

for all homes. Using the SA’s services, SPs can obtain

historical and real-time data, regarding the subsystem

of their interest, while they can update the service

tem architecture.


offerings to end-users. On the other hand, home users

are able to remotely access their home systems, through

the SA, for configuration and monitoring operations.

Service Provider (SP) layer: Using a thin-client

application which makes use of the SA’s SOAP API,

SPs can manage and retrieve data from home systems

installed at their customers’ premises. Moreover,

historical data and alarm notifications corresponding

to specific events within homes pass through the SA

and eventually they end up in the databases of the

SPs. In order to avoid overhead and for business

purposes as well, data retrieved from homes are only

tunneled through the SA but are not stored there.

Finally, the SA relays all commands issued to the

home subsystems by using the appropriate device

driver for each home network.

3.1. Home layer

As it has been mentioned above, the home layer

includes three types of devices: (a) a home server, (b)

health measurement devices and (c) automation devi-

ces. These devices constitute the home subsystems.

3.1.1. Home server

The central component of the home layer is the

home server, which communicates with all the mea-

surement and automation subsystems and, also, hosts

Fig. 2. Home server

the corresponding drivers and applications. The main

functions of the home server are to read data from the

underlying subsystems, which is stored in a local

database and to perform control operations to these

subsystems. In addition, the home server is the entry

point for access to each subsystem both for in-home

and out-of-home users, acting as a residential gateway,

providing the required security policy and connectiv-

ity functionality. The architecture of the home server

is illustrated in Fig. 2. All the modules have been

implemented as COM DLL servers using specific

COM standards, in order to ensure interoperability.

3.1.1.1. Comprising modules.

Serial (RS-232) modules. The serial modules are

essentially drivers that allow communication with

specific devices, which are attached to the serial ports

of the home server. The three serial drivers that have

been developed correspond to two medical devices

and one security/safety subsystem. Both the medical

serial modules implement two sets of functions. One

set is common to both of them and relate with general

serial port management commands such as open,

close, set speed, parity, etc. The second set implements

device-specific commands that translate to the propri-

etary protocol of each device. Apparently, all serial

modules, including those for the security/safety sub-

system feature a data parser so that messages from the

architecture.


devices are processed and proper events are triggered.

Some of the commands are read from an INI file. This

provides enhanced flexibility because the modification

or expansion of a system will be dealt by adding

additional commands to the INI file, rather than

having to recompile the corresponding COM serial

module.

Database module. The database module consists

of a relational database and a COM server, which

exposes a number of methods and properties for the

management of the storage/retrieval procedure. The

database holds data from all the subsystems along

with home-specific data, such as user’s identity,

address, etc. The COM server accepts calls and it

returns either requested records or confirmation for a

successful or failed operation such as a record update.

The responses from this component are synchronous;

therefore, it does not generate any events.

Alarm detection module. This module is re-

sponsible for the detection of abnormal situations

in any subsystem residing in the home. The detec-

tion, triggered by any new received set of data, is

achieved by comparisons of the measured values

with their corresponding threshold values. If an

alarm situation is detected, an appropriate event is

produced which indicates the subsystem that fired

the alarm plus specific information for the unique

identification of each alarm.

Central module. The central module is of partic-

ular interest because it is the module that coordinates

and manages all other modules. At the same time, the

central module is responsible for the communication

with the SA through its SOAPAPI using a proprietary

XML messaging format for exchanging data.

The central module is a COM client for all the

modules described so far, meaning it has access to

all their methods and events they expose. As far as

the events are concerned, the central module has

event sinks for all events and appropriate event

handlers. For example, when the safety/security

serial module receives data from the security sub-

system, it fires an event, which contains a string

with the result of the processing of the received

data. The corresponding event handler of the central

module receives the event and the accompanying

data. The event handler contains a call to the

appropriate module and passes over the received

data. In our example, the event handler contains a

call to the write method of the database module,

which causes the insertion of a new record to the

corresponding table. The central module contains

additional event handlers to handle events from the

time scheduler and the alarm detector. Basically,

each module is accessed indirectly by the other

modules, either through events or by using the

corresponding functions of the central module.

Another responsibility of the central module is the

transmission of the stored data, at scheduled intervals,

from the database to the SA and, also, the transmis-

sion of alarm notifications. This takes place in a

uniform way using a proprietary XML-formatted

document-centric message, which is sent inside a

SOAP envelope. For on demand transmission of

stored data to the SA, the central module implements

a SendData(data) method, which is triggered either by

the time scheduler module or by a SOAP-encoded

remote procedure call (RPC) command. It should be

noted that when the SA invokes commands to the

remote site’s central module, command invocation is

achieved using SOAP RPC because the central mod-

ule exposes its methods via a SOAPAPI manifested in

the corresponding WSDL file.

The format of the packet is shown in Fig. 3.

The Type can have the following possible values:

Alarm, Event, Response and Command. The Source

field contains a string with data related to the home

where the packet originated from. The Destination

field contains the type of the SP the contents of the

packet should reach. The exact SP is resolved by

examining the contents of the Source field and

referring to the SA’s Database. The SystemID field

indicates the home system the packet came from. The

Content field contains either the name of the com-

mand or the name of the parameter that the packet

carries. The ParamName attribute contains either the

name of a command parameter (optional) or the name

of a subparameter (nested parameter). The Type

attribute can have any of the four values: string,

int, array of str, array of int. Finally, the TimeStamp

element contains the Time and Date attributes that

hold the corresponding timestamps.

Time scheduler module. This module is respon-

sible for the timely execution of scripts, in order to

achieve unattended transmission of the stored data to

the corresponding SPs. The time scheduler module is

similar to the Task scheduler found in MSWindowsk.

Fig. 3. SOAP request/response messages.


It features a set of scripts that can be invoked in a timed

fashion. The commands of each script map directly to

the exposed methods of the rest COM modules. In

order to invoke a script, the time scheduler module

compares the preset time of a task with the system

time. When a match is found, it triggers an event for the

activation of the corresponding script, which initializes

a series of calls to the central module. Finally, this

module passes the calls to the corresponding COM

module(s), for the actual execution of the proper

operations, acting as a proxy for them.

3.1.1.2. Connection to the Internet. Generally, there

are four connection models for the connection of a

home to the Internet [17]:

Connecting each device directly to the Internet.

Connecting the devices to the Internet through a

residential gateway which implements network

address translation (NAT).

Use of the above topology but also tunnelling of

the connection through a security service provider

(SSP).

Connection between the home and a SSP over a

VPN.

The approach followed was based on the third

scenario, given that the application requirements did

not dictate a solution as sophisticated as the one

described in the fourth scenario. All traffic is routed

from the SA to the home. The home server accepts

connections only from the SA by checking the in-

coming IP address. It is assumed that in a real

commercial deployment, the SA will consist of server

farms with redundant servers, thus eliminating service

downtime due to scheduled maintenance or an un-

foreseen incident. Securing communications between

home and SAwas implemented using IPSec, which is

inherently in IPv6. IPSec is based on cryptography-

based protection services, security protocols and dy-

namic key management.

3.1.2. Medical subsystems

The medical subsystems are based on two com-

mercial available devices that monitor and transmit

several health parameters. These parameters are stored


in a local database. The first device monitors (ECGs)

and the second one measure heart rate, skin conduc-

tivity, overall activity and body temperature. Analyt-

ically, the devices and their functionality are described

in the following paragraphs.

The HealthFrontier ecg@homek [18] device is

capable to monitor heart-related parameters such as

the heart rate, ECG graph, QRS and ST. The device is

attached to the home server through its RS-232 serial

interface. Information from the device is sent to the

home server asynchronously. The RS-232 ECG mod-

ule polls periodically the device to check if the device

buffer contains new data. Once new data are detected,

they are retrieved and parsed while the device buffer

is erased so that the next time it is polled it has either

new data or no data at all. The polling solution was

implemented in order to minimize the patient’s inter-

action with the home server.

The second device, developed by IST Sec [19], is

the Vivagok wrist-mounted device, which monitors

the temperature, skin conductivity and body activity

levels, in real time. The wrist unit also features an

emergency button, which triggers an alarm signal

when pressed. The data is transmitted in a wireless

fashion to the base station, which is plugged to one of

the RS-232 ports of the home server. The data from

both the wrist unit and the ECG devices are stored in

the appropriate database residing in the home server.

3.1.3. Safety and security subsystems

The two subsystems are described as one because

they share the same hardware. More specifically, the

Caddxk NX-8 control panel [20] is used as a

common platform both for the safety and security

subsystems. The security subsystem detects and

reports an intrusion attempt while the safety subsys-

tem alerts in the case of in-house dangerous situations

such as flood and fire detection. In addition, the safety

subsystem monitors two electric loads, namely, the

oven and the water heater and has the capability to

remotely turn them off when particular conditions are

met, e.g., when the oven is on and the security

subsystem is in the arm state. The sensors for the

safety/security subsystem include motion detectors,

magnetic contact switches, smoke detectors, glass-

break detectors and electric current detectors. Because

the Caddxk system cannot produce an asynchronous

notification in the event of an alarm to the home

server, the safety/security serial component polls

periodically the state of the two subsystems. The fact

that the two subsystems share the same device does

not prevent two SPs from receiving distinctive notifi-

cations and from having access only to the function-

ality corresponding to each service. The security SP

can check the status of the security subsystem, bypass

zones, change the pin code of the user and of course

receive alarms. The safety SP can receive alarms from

the corresponding safety sensors and monitor/control

the two electric loads.

3.2. Service Aggregator (SA) layer

The SA comprises the middle layer of the three-tier

architecture, and is responsible for the integration and

management of the services provision. More specifi-

cally, it integrates all the components needed in order

to achieve secure and robust communication between

home users and SPs, for service distribution and

offering.

The transmission of periodic and/or alarm mes-

sages from any home subsystem to the corresponding

SP takes place through the SA. An end-to-end trans-

mission procedure is as follows. At the home layer, the

periodic/alarm transmissions are initiated based on the

time scheduler or alarm detection module, respective-

ly. Both modules are able to trigger specific events to

the central module, which performs the corresponding

actions in response to each of them. For example, the

event of periodic transmission of ECGs, initiates a

series of actions, including the retrieval of the proper

records from the local database, the appending of

relevant information about the identity of the particu-

lar home, etc., the formatting in an XML-based SOAP

message (Fig. 3) and, finally the transmission to the

SA. On the SA side, a SOAP server, instantiated by an

ASP Web page, receives the SOAP message, performs

the proper parsing and based on the message’s content,

creates the appropriate event and fires it into the SA

for handling. Each event is handled by the respective

event handler associated with it. Typical event han-

dlers react by sending out alerts (e-mail or SMS) in

order to notify SPs and/or end-users, invoking com-

mands on other devices, etc.

In a similar way, SPs and end-users perform

monitor and control operations to each home through

the SA. For this to be accomplished, the SA features a

V. Kapsalis et al. / Computer Standards

set of Functional modules that invoke the SA’s SOAP

clients, each of which acts as a proxy, in order to

access the particular functionality of a subsystem

residing at the home layer. Each module is service-

specific meaning that for each offered service there is

a corresponding module, which is provided by the SP

and maps to the corresponding subsystem at the

home. The modules can relay commands to homes

through the SOAP client and accept notifications from

homes through the SOAP server as can be seen in Fig.

4. The entities comprising the SA are the SOAP client

and server, the Database and the Functional modules,

are illustrated in Fig. 4, too.

3.2.1. Database

The Database of the SA layer is where all data

concerning the three-layer system is stored. Data

stored is relevant to configurations performed either

by SPs or end-users of the system. Specifically, data

that has to do with SPs include SP-IDs (identities),

contact information, messages format and transmis-

sion protocols (SMS, e-mail, XML message), services

description, services availability (which users they are

addressed to), subscribed users to services and billing

information about each user. Respectively, data

concerning end-users of the services includes infor-

mation about home-IDs, home-IPs, groups, devices

and home networks, access rights, services users are

subscribed to, and actions a user can perform. In our

implementation, the SA runs the MS SQL Serverkdatabase.

Fig. 4. The service

3.2.2. Functional modules

The SA’s functionality is based on its Functional

modules that essentially constitute the core of the SA.

SA’s clients (SPs and end-users) are able to access the

exposed services of these Functional modules and

make use of them in order, to monitor and control

home device networks. The SA’s Functional modules

can be seen in Fig. 4, and are presented in the

following passage.

3.2.2.1. Authentication and encryption. A significant

function of the SA is the high level security provision to

all connections either they are made by a home user or

an SP. Users wishing to access their accounts for

controlling and/or monitoring their underlying home

networks must be relied on secure connections. It is

equally important to ensure that established sessions

cannot be eavesdropped from the outside. For the

accomplishment of the above, the SA relies on well-

established techniques. In order to avoid eavesdrop-

ping, the SAmakes use of HTTPS, which is HTTP over

Secure Socket Layer (SSL). This security functionality

is implemented partially by the hosting OS (enabling

HTTPS and/or IPSec) and partially by the SA itself by

using an appropriate authentication mechanism.

3.2.2.2. Authorization (access control). Besides the

encryption and authentication, the SA incorporates an

authorization mechanism based on an integrated ac-

cess control policy, in order to ensure that specific

actions are performed by the authorized persons only.

& Interfaces 26 (2004) 527–541 535

aggregator.


SA’s access control policy is based on a role-based

security model. Under this model, SPs and end-users

are assigned to zero, one or more roles, which are

groups with specific access rights. Required roles can

be assigned to specific home subsystems and oper-

ations within each subsystem, which are accessed as

web services, through the appropriate SOAP API.

This mechanism assures that all operations are in-

voked only by users with the proper access rights

(belonging to a specific group), meaning that only

authorized users will be able to perform the assigned

operations to each subsystem. For example, if an SP

invokes an operation, such as controlling the status of

a home device that is possessed by another SP, the

system will check whether the SP requesting the issue

of the command has the required access rights and if

not it will forbid operation invocation.

For the entirety of home subsystems, there are

specific associations between user groups and each

supported action. Specifically, each distinct home sub-

system has its own proxy, in the form of a SOAP client,

residing in the SA. Any action in a home subsystem

takes place by the proper method invocation in the SA’s

SOAP client, which in turn, calls the corresponding

method of the remote residential SOAP server. The

mapping between users group and the allowed actions

are stored in the Database, residing in the SA. The

module keeps the Database updated and uses it to create

dynamically user-specific Web interfaces that corre-

spond to the particular user access rights, giving the

user the ability to control, contact andmaintain only the

systems that he/she is authorized to. The access control

mechanism is illustrated in Fig. 5.

Fig. 5. Access contr

3.2.2.3. Billing. One of the major SA’s functions is

the service provisioning billing management. The way

charging is performed, depends on the way each

service is offered, and can be based on various

scenarios such as per-hour use billing or per transac-

tion. Because the SA has the ability to make the

billing for its service provision, it is also able to

inform SPs and users, about their account status and

provide them standard data about each transaction

(account reference, time stamp, service package ref-

erence, unit price and total amount fields).

3.2.2.4. Scheduling. Although a scheduling timer

exists at the home layer and is user-configurable, an

SP might need to schedule tasks for all its clients. The

scheduler is essentially a global timer module (similar

to the Windowsk Task Manager), which can be

adopted by each SP to its account and be customized

so as to timely invoke its predefined actions. Each

SP’s scheduler configurations are stored in the SA’s

Database. These configurations can be separated in

two levels: one per user and one per service/function

in case an SP provides more than one offering. An

example of a scheduler’s operation would be the

collection of values returned from a specific device

within a remote device network by setting time

intervals for specific data retrieval.

3.2.2.5. Configuration and Web GUI. The Web

Graphical User Interface (Web GUI) consists of the

SA’s web pages, hosted in an ASP framework created

as a combination of static HTML templates and

dynamic content. All end-users that log on to the

ol mechanism.


system, view an interface dynamically created with

their personal preferences stored in the Database, and

interact with the system using the respective config-

uration pages. Users can maintain their accounts, view

and edit information and administer their remote

device network systems.

Using configuration ASP pages that interact with

the Functional modules the user can perform the

following functions:

Add new services (for SPs).

Subscribe to a new service (for home users).

Configure account settings.

Insert new SOAP server/client components.

Insert new Web GUI pages (that call and instantiate

SOAP objects).

Configure mode and format of the returned data.

Configure the scheduler to perform and call

specific actions.

Configure the operational scenarios of the under-

lying device networks.

3.2.3. SOAP servers/clients

The basic feature of the SA, for multiple services

provisioning, is based on its ability to support new

types of device networks. In order to support a device

network, a suitable interface is needed. In our system,

the interface is a COM component that acts as a SOAP

client to a remote device network and performs remote

procedure calls (RPCs) to the SOAP server residing at

the home network’s side. In addition, the communi-

cation between the SA and any SP, whenever the SA

needs to route data from a home to the corresponding

SP, is taking place through a type of SOAP client,

residing in the SA. Finally, specific interface compo-

nents work as SOAP servers for remote home servers,

serving their requests towards the SA. SOAP servers/

clients may be installed into the SA, by an SP with the

help of the configuration module.

3.3. Service Provider (SP) layer

SPs can be any business entity offering one or

more services through the network infrastructure to

home residents, e.g., a security provider offering

intrusion detection services, a hospital offering health

care services, an insurance company offering safety

alerts services, etc. In the current implementation, an

SP is the entity that essentially uses the infrastructure

of the system for the achievement of robust and

quality service provisioning. An SP not only adver-

tises and adds services to the SA, but at the same time

is the one responsible for the data retrieval and

manipulation from the home automation networks.

A service should be developed in such way that

would be in the position to establish itself to the SA

site, and be able to expose its functionality to the rest

two layers. In our approach, the service is installed to

the SA as a set of DLLs and a group of ASP pages. The

installed DLLs implement the desired functionality the

SA should exhibit so as to perform robust service

provisioning. The ASP pages are used from any

interested consumer, willing to add the service to his

service bundle, in order to configure the service and

adjust it to his own preferences. In case, an SP needs to

deploy any hardware device(s) to the home site of the

consumer, what would be needed for the achievement

of the quality service provision, is the ability for

remote configuration and management of those devi-

ces. An SP can control and configure those devices in

the home layer, through the SA. The latter checks the

SP’s access rights for the specific home, and if it has

the authorization to control the device on the home

site, it is admitted to access the specific device.

An SP that deploys a service over the Internet to

many consumers is in need of a very powerful

database and file directory system in its site. The SP

stores historical data from its customers, for reporting

and billing functions. Access to this stored data can be

relied either on the SA’s authorization mechanism,

described above, or on a separate mechanism, imple-

mented by the SP.

4. End-to-end operational scenarios

In the following sections, the end-to-end operations

for each provided service follows.

4.1. Medical service

A typical operation scenario for the medical sub-

system, which consists of the ECG capture, is as

follows. A home user captures an ECG waveform by

using the ecg@homek device. This ECG is transmit-

ted to the home server in ASCII format by the serial


connection (RS-232) and stored in the local database.

All stored ECGs can be viewed by a Web-based

interface, using the methods of the corresponding

COM modules (central module and database module).

These modules provide the proper functionality for

reading, modifying and deleting records from the local

database. Essentially, each local database contains

records that are part of the central database, residing

at the healthcare SP. New inserted records at the local

database are flagged and, periodically, are transmitted

to the central database for updating or insertion. The

period for the transmission of records is configured

through the time scheduler module that has been

described above. The transmission takes place through

the SA and not directly to the SP’s database. The

procedure is as follows. The time scheduler module

triggers transmission events for each subsystem in

predefined time instants. A transmission event for the

medical subsystem initiates a procedure that reads the

new records, constructs a SOAP (XML-encoding)

message consisting of these records and relevant infor-

mation, e.g., the patient’s identity, etc. and transmits it

to the SA. The entry point to the SA is an ASP Web

page, which is responsible for the instantiation of the

proper SOAP server and the parameter passing to this

object. The event handler, which is responsible for the

initiation of the proper action(s), based on each specific

event, usually sends a notification SMS and/or e-mail,

notifying the doctor about the newly received ECG.

Consequently, based on the configuration settings, it

retransmits the received data to the healthcare SP’s

database, through its SOAP client. The entire end-to-

end communication path (home–SA–SP) is based on

SOAP and XML.

The use of the SA as an intermediate, based on the

hub-and-spoke connection model, which relays re-

ceived data, frees the home server from communica-

tion and security aspects. The SP’s central database

contains a superset of all the patients’ ECG records

and is accessed by authorized personnel, through the

SA’s access control mechanism, which has been

described before. This architecture, which imple-

ments the operations of data origin authentication,

command authorization, message integrity protection,

etc. centrally at the SA, provides a high degree of

security and flexibility. A similar procedure takes

place in order to retrieve data from the Vivagokwrist-mounted device.

A user that is trying to access data from the

medical system can be either an end user or an SP

that wants to retrieve and work on data stored in the

SP’s database. The user logs in the SA, which builds a

customized interface (Web GUI) based on his/her

personal preferences and subscribed services. The

SA is acting as the intermediate point through which

someone can access both residential systems and the

SPs’ databases. The Web GUI uses the functionality

of the SA’s SOAP clients, in order to communicate

with the remote SOAP servers, residing either in the

end users’ homes or in the SPs’ sites. When the user

performs an action that interacts with any of these

remote SOAP servers, actually a method call is being

invoked to the corresponding component, conveyed

through a SOAP message. After a basic security check

for the validation of the sender’s identity, the SOAP

server parses the incoming message, makes an invo-

cation call to the corresponding component which

actually performs the requested action, and, eventual-

ly, responds with a SOAP message that includes either

the data generated from a method invocation or an

acknowledgement. The SA’s SOAP server receives

the SOAP message, parses it in order to retrieve the

needed data, and finally presents them in HTML

format to the user that initiated the transaction.

If the user has the proper authorization (doctor or

health professional) then the Web GUI provides him/

her the means for the configuration of the medical

subsystem’s parameters (e.g., period of data transmis-

sion etc.), at the end user’s home. In addition, he/she

is able to retrieve ECGs and relevant information

stored in the home server’s database. Furthermore,

he/she is able to access the ECGs of all his/her

patients that are stored in the SP’s database.

4.2. Safety and security service

A similar scenario is implemented for the safety and

security subsystems. An hypothetical case is analyzed,

in which the home user has left the residence, after

having armed the security subsystem but has forgotten

the electric oven on. Because the module for the two

subsystems polls the Caddxk NX-8 control panel at

short intervals, it will retrieve immediately the status of

the subsystem and will report that the security subsys-

tem is in armed state while one of the electric loads is

active. The status will be written to the corresponding


table of the home server’s database and at the same time

the alarm detectionmodule will check the current status

against alarms or potential risks. The latter will detect

that the subsystem’s status matches the conditions to

trigger an alarm. The alarm is sent from the alarm

detection module to the central module, which, in turn,

constructs an XML packet, corresponding to the cur-

rent situation and sends it as a SOAP message to the

SA. Once the SA receives the message, parses it and

analyzes its content, in order to identify the origin of the

alarm and the alarm type. Then, it produces an SMS,

which is sent to the corresponding (safety) SP. The

safety SP receives the SMS and using a thin client

connects to the SA. Once authentication and authori-

zation has passed successfully, the SP checks the safety

subsystem status in detail, through the customizedWeb

GUI. Normally, the SP issues a turn-off command,

which is forwarded to the appropriate SA’s SOAP

client. The latter sends the corresponding SOAP mes-

sage to the central module of the remote home server.

The central module passes the command using the

COM mechanism to the serial module that manages

the safety/security subsystem, which in turn, sends the

command to the Caddxk control panel. Once the latter

has received and executed successfully the command,

it sends a positive acknowledgment back to the home

server, which, is eventually forwarded to the command

initiator, through the Web GUI of the SA.

A similar scenario would take place for the security

subsystem. The difference is that in this case, an alarm

is detected directly from the serial module controlling

the two subsystems and not from the alarm detection

module because a fire alarm for example, is a straight-

forward event that does not require additional parsing

from the alarm detection module. In such a case, the

serial module produces an alarm event, which is

caught by the central module and handled in a manner

similar to the one described for the safety subsystem.

Issuing commands to the security subsystems and

accessing information residing at the SPs’ databases

require exactly the same procedure described both for

the safety and the medical subsystems.

5. Conclusion

This paper presented the architecture of a service-

oriented, Web-based system for the provision of

‘‘peace-of-mind’’ e-services to home residents over a

common networking infrastructure. A pilot application

has been developed that proved the feasibility of

bundling e-services over the proposed architecture.

Three different service providers were able to offer

their services to a number of home residents by using

the proper SOAPAPI interface of the SA. An extension

of the offered e-services in order to include energy

management and home automation is the next step

towards an integration of the main home automation

systems.

The pilot application was based mainly on com-

mercially available automation systems, which were

integrated into the home server, through their com-

munication (RS-232) interfaces. A more sophisticated

system would be implemented if the whole home

automation were based on a standard network tech-

nology (e.g., LonWorks, EHS, UPnP, etc.). This will

be feasible and cost-effective when a great number of

vendors in the areas of security, energy, device auto-

mation, etc., adopt a common standard and incorpo-

rate it into their products, ensuring interoperability

between different types of devices.

The use of a hub-and-spoke connection model, in

the form of an intermediate entity, called Service

Aggregation (SA), results into a number of advan-

tages both for end-users and SPs. The modular archi-

tecture of the SA provides the capability of integrating

and supporting a great number of heterogeneous e-

services from many SPs.

Regarding the end-to-end communication, the sys-

tem was based entirely on the prevailing and emerging

Internet standards, ensuring platform, vendor and lan-

guage independence. State-of-the-art technologies,

such as HTTP, XML, SOAP andWSDL guarantee that

the system is really open and future-proof. The use of a

service-based architecture keeps up with the evolution

of Internet that is gradually transforming from a hu-

man-oriented to a service-oriented universal network,

by extended use of Web services. Totally XML-based

information exchange between all the participant enti-

ties (home systems, SA and SPs) provides a viable

framework for universal connectivity without technol-

ogy barriers, which could be imposed by closed and

proprietary technologies.

The proposed topology addresses many issues

where future research could yield interesting results.

One such area would be the introduction of some sort


of ‘‘intelligence’’ to the central module. This translates

to a set of predefined rules that trigger a particular

alarm when violated or take proper action based on a

combination of possible events. An interesting chal-

lenge would be to model the possible scenarios so that

rules can be added even after system deployment.

Even more challenging is the detection of possible

life-threatening conditions without the use of explicit

predefined rules by means of neural network algo-

rithms because the possible combinations of possible

states between different systems increase exponential-

ly when a new system is introduced.

References

[1] Parks Associates study report: ‘‘E-home 2001 A Study of U.S.

Internet Households’’, 2001.

[2] F. Magrabi, N.H. Lovell, B.G. Celler, A web-based ap-

proach for electrocardiogram monitoring in the home,

Elsevier International Journal of Medical Informatics 54

(1999) 145–153.

[3] R. Bellazzi, S. Montani, A. Riva, M. Stefanelli, Web-based

telemedicine systems for home-care: technical issues and

experiences, Elsevier Computer Methods and Programs in

Biomedicine 64 (2001) 175–187.

[4] D.J. Nigrin, I.S. Kohane, Glucoweb: a case study of secure,

remote biomonitoring and communication, Proc. AMIA

Symp., 2000, pp. 610–614.

[5] C. Lau, R.S. Churchill, J. Kim, F.A. Matsen III, Y. Kim,

Asynchronous Web-based patient-centered home telemedicine

system, IEEE Transactions on Biomedical Engineering 49

(12) (2002 December) 1452–1462.

[6] V. Thorsteinsson, ‘‘Homeportal white paper: Delivering value

to personal networks’’ [Online], www.homeportal.com.

[7] V. Kapsalis, K. Charatsis, A. Kalogeras, G. Papadopoulos,

Web gateway: a platform for industry services over Inter-

net, IEEE International Symposium on Industrial Electron-

ics IEEE-ISIE’ 2002, L’ Aquila, Italy, 2002 (July), pp.

73–77.

[8] OSGi Service Platform Release 3, March 2003, [Online]

www.osgi.org.

[9] Broadband Device Web Services—An Overview, Second

Draft (Version 0.8), April 2003, Point Clark Networks,

[Online], www.pointclark.net.

[10] D. Valtchev, I. Frankov, Service gateway architecture for a

smart home, IEEE Communications Magazine, (2002 April)

126–132.

[11] Opensugar video alarm application [Online], www.opensugar.

com.

[12] LNS, Echelon, [Online], www.echelon.com/products/

development/lns/.

[13] EHS, Konnex Association, [Online], www.ehsa.com.

[14] UPnP, Understanding Universal Plug and Play, [Online],

www.upnp.org.

[15] Panoramix, Echelon, [Online], www.lonworks.echelon.com/

products/enterprise/panoramix/default.htm.

[16] Simple Object Access Protocol (SOAP) 1.1, W3C Note 08

May 2000, [Online] www.w3.org/TR/SOAP.

[17] A. Herzog, N. Shahmehri, A. Bednarski, I. Chisalita, U.

Nordqvist, L. Saldamli, D. Szentivanyi, M. Ostring, Security

issues in e-home network and software infrastructures, Pro-

ceedings of the 3rd Conference on Computer Science and Sys-

tems Engineering in Linkoping, Norrkoping, Sweden, 2001,

pp. 155–161.

[18] Healthfrontier, [Online], www.healthfrontier.com.

[19] IST International Security Technology Oy, [Online],

www. istsec.fi.

[20] GE Interlogix, [Online], www.geindustrial.com/ge-interlogix/.

Dr. V. Kapsalis received Diploma in Elec-

trical Engineering and PhD degree in Elec-

trical and Computer Engineering from the

University of Patras, Greece, in 1990, and

1994, respectively. Since 1990, he has been

involved in several projects in the Depart-

ment of Electrical Engineering, University

of Patras, and in the Institute of Biomedical

Technology (INBIT), under the framework

of European Union and Greek programmes.

During that period, he has developed sys-

tems and applications for process control, home/building automa-

tion and telemedicine applications. Currently, he is a senior research

engineer in the Industrial Systems Institute (ISI), working on

research projects supported by the Greek General Secretariat of

Research and Technology and the European Union and joint

projects with Greek industry. His research activities include real-

time MAC-layer protocols, industrial and home/building network-

ing systems, distributed control architectures, network integration

and Internet technologies.

Mr. Konstantinos Charatsis received his

degree in Electrical and Computer Engi-

neering in 1999 from the Aristotle Univer-

sity of Thessaloniki, Greece, and his MSc

degree in Automation and Control in 2000

from University of Newcastle Upon Tyne,

UK. His research area is the interoperability

of industrial and home networks through IP

protocols and Internet technologies. Since

September 2000, he is a Research Associ-

ate in the Industrial Systems Institute (ISI)

involved in research projects on the abovementioned area. He is

currently working towards his PhD in the Department of Electrical

Engineering at the University of Patras. During his studies, he

worked on the C.A.N. industrial network and his research interests

include industrial and home automation networks, Internet, and Web

Services.

http:\\www.homeportal.com

http:\\www.osgi.org

http:\\www.pointclark.net

http:\\www.opensugar.com

http:\\www.echelon.com\products\development\lns\

http:\\www.ehsa.com

http:\\www.upnp.org

http:\\www.lonworks.echelon.com\products\enterprise\panoramix\default.htm

http:\\www.w3.org\TR\SOAP

http:\\www.healthfrontier.com

http:\\www.istsec.fi

http:\\www.geindustrial.com\ge-interlogix\


M. Georgoudakis received the M.Eng. and

the M.Sc. degree in Electronic Engineering

from the University of Hull, UK in 1999

and 2002 respectively. Since 2000 he has

been involved in several European and

national projects in both the industry and

the academia. During that period he has

worked in the industry as communications

engineer and technical consultant while he

has worked as applications developer in the

Department of Electrical Engineering and

Computer Engineering and the Industrial Systems Institute (ISI).

Currently he is working towards his PhD in the field of real - time

industrial Ethernet while his research interests include distributed

applications, internet technologies integration and mesh networks.

Mr. E. Nikoloutsos received his Diploma

in Electrical Engineering & Computer

Technology from the University of Patras,

Greece, in 2000. Since 2000 he is a PhD

Student in the Department of Electrical

Engineering & Computer Technology,

University of Patras and has been working

in several projects under the framework of

European Union and Greek programs. His

research activities include real-time indus-

trial networks, network integration and

Internet technologies.

Professor George Papadopoulos is pro-

fessor in the Department of Electrical and

Computer Engineering at the University of

Patras and Director of the Applied Elec-

tronics Laboratory. Recently, he has been

appointed as director of the Industrial Sys-

tems Institute (ISI). His degrees, Ph.D. in

E.E. and MSEE, were obtained from the

Massachusetts Institute of Technology

(MIT) and the BEE from the City Univer-

sity of New York. His main research inter-

ests include the following areas: Microprocessor-based and

embedded system design, computer communication networks (pro-

tocol software and internetworking), communication electronics,

fieldbus based industrial control, integrated industrial information

systems, real-time kernels for industrial communications, home and

building information systems and machine vision for industrial

products inspection. He has participated as coordinator, partner or

subcontractor in many projects of the EU. Finally, as director of the

Applied Electronics Laboratory and the Industrial Systems Institute

he has been collaborating with many Greek industries through direct

contracts. The majority of these grants and contracts are in the areas

of embedded telecommunication systems and industrial information

systems.

a soap-based system for the provision of e-servicesa system architecture, which partially fulfils...

Documents