a soap-based system for the provision of e-servicesa system architecture, which partially fulfils...
TRANSCRIPT
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
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541530
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 531
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541532
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 533
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
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541534
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541536
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 537
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
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541538
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
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 539
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
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541540
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.
V. Kapsalis et al. / Computer Standards & Interfaces 26 (2004) 527–541 541
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.