DELIVERABLE 2.3. Wearable Platform - Requirements Analysis

spongereasonInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

229 εμφανίσεις




















DELIVERABLE 2.3.
Wearable Platform
-
Requirements Analysis







LIFEWEAR, MOBILIZED LIFESTYLE WITH WEARABLES






COUNTRY

PARTICIPANT

VERSION

DATE

Spain

Tecnalia

0.1

21/06/2012

Spain

Tecnalia, Treelogic,
Deusto

0.2

25/06/2012

Spain

Tecnalia

0.3

27/06/2012

Spain

Tecnalia, UPM, TID

0.4

27/12/2012



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




2

/

39








CONTENTS

1

INTRODUCTION AND OBJ
ECTIVES

................................
................................
................................
.

3

1.1

E
XECUTIVE SUMM
ARY

................................
................................
................................
..........................

3

1.2

O
BJECTIVES

................................
................................
................................
................................
........

3

1.3

O
VERVIEW OF SECTIONS

................................
................................
................................
.......................

3

2

WEARABLE PLA
TFORM ESB

................................
................................
................................
...........

5

2.1

FIRST

STEPS

................................
................................
................................
................................
....

5

2.1.1

Prerequisites

________________________________
_____________________________

5

2.1.2

Instal
lation

________________________________
_______________________________

5

2.1.3

Launching

________________________________
________________________________

6

2.2

I
NSTALLATION OF
L
IFE
W
EAR BUNDLES
/
LIBRARIES

................................
................................
......................

6

2.2.1

WP5 Ontology

________________________________
____________________________

6

3

USAGE OF THE LIFEWEA
R ONTOLOGY API

................................
................................
....................

8

4

USAGE OF THE LIFEWEA
R WEARABLE PLATFORM

................................
................................
.......

12

4.1

D
EPLOYMENT OF PRODUCE
R BUNDLES

................................
................................
................................
...

12

4.1.1

Sarein


Tecnalia

________________________________
_________________________

13

4.1.2

UPM

________________________________
________________________________
___

18

4.1.3

Deusto
-

Treelogic

________________________________
________________________

25

4.1.4

Telefonica I+D

________________________________
___________________________

31

4.2

R
EST
SERVICES CONSUMPTION

GUIDE

................................
................................
................................
....

32

5

WEARABLE PLATFORM IN

THE LIFEWEAR REPOSIT
ORY

................................
..............................

36

6

CONCLUSIONS AND FURT
HER STEPS

................................
................................
...........................

38

7

REFERENCES
................................
................................
................................
................................

39






LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




3

/

39


1

INTRODUCTION AND OBJ
ECTIVES

1.1

Executive summary

The current document is delivered together with the prototype of the Wearable platform,
which means that b
oth deliveries are complementary. This deliverable can be considered very
valuable, since it provides comprehensive information about how to use and extend the
Wearable Platform. Before explaining the utilization of the platform, the document describes
how

to configure the environment, and more precisely, how to setup the Enterprise Service
Bus (ESB) that is being used as an integration mechanism of the different middleware
platforms used. The ESB is described in detail in D2.2 (“Semantic Middleware Interop
erability”
formerly known as “Requirements Reception”), hence, this document does not provide
technical details about its functionalities and neither the reasons that lead choosing this
solution, since they are already explained in the previously mentioned

deliverable.

This is the final version of the deliverable, and hopefully provides a full description about the
work performed in this work package over the past months.

1.2

Objectives

The main objective of this document is to serve as a User Guide of the prot
otype of the
Wearable platform. This manuscript provides information about how to use the Wearable
Platform, from the first steps and initial configuration to the usage and consumption of the
services provided by the solution. Therefore, this document cont
ains all the information
necessary in order to make the LIFEWEAR Wearable Platform operational in any environment.

This deliverable is complementary to the Software prototype delivery made in D2.4 “Wearable
platform”
;

hence, it is recommendable to use them

combined. Figure 1
-
1 illustrates the
approach followed for the implementation of the Wearable Platform. More concretely, the
figure depicts how the Semantic Middleware interacts with the developments made in another
work packages, since all together confo
rm the Wearable Platform.


Figure
1
-
1



Overview of the LifeWear Wearable platform

and its relationships with other
W
P
s
.


1.3

Overview of sections

Section 2

describes how to install, configure and launch the Ent
erprise Service Bus (ESB) that is
used in the project to
integrate the

different existing middleware approaches into the
LIFEWEAR Semantic Middleware. This section also explains the additional libraries that are
necessary to install in the ESB in order to
ensure the correct operational of the provided


LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




4

/

39

solution. Section 3 exemplifies how to use the LIFEWEAR Ontology API implemented in WP5
that facilitates methods and function to easily interact with the underlying ontology. Usage of
the Ontology API is mand
atory for each of middleware that are integrated in
LIFEWEAR

(through the ESB), so its installation in the ESB is another step of the working environment
setup procedure.

Later, Section 4 explains how to actually use the LifeWear Wearable Platform. On one
side, it
explains the installation and main characteristics of each of the gateways created for each
specific middleware that is integrated into the LifeWear Wearable Platform. This section also
describes the list of REST (REpresentational State Transfer)
services provided by each of the
middlewares. On the other side, this section provides a general explanation on how to
consume the REST services from the final applications that are being developed in WP4.
Section 5 summarizes how to access to the first
prototype of the Wearable platform in the
project repository. Finally, Section 6 presents the conclusions and the planned steps for the
next version of the Wearable Platform. Additionally, external references are summarized in
Section 7.


LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




5

/

39


2

WEARABLE PLATFORM

ESB

The ESB implementation chosen for this project is Fuse ESB

[1]
. Based on Apache ServiceMix

[2]
, Fuse ESB is standards
-
based and built using open source technology. The most important
features a
re that it is lightweight, multi
-
platform, and it uses the OSGi framework, providing a
mechanism that automates creating and maintaining OSGi bundles (FAB, Fuse Application
Bundle).

Fuse ESB supports the Java Business Integration (JBI) specification (JSR
208), JMS, HTTP, HTTPS,
FTP, XMPP, Web services, and a number of other bindings. Fuse ESB connectivity options can
be extended by using routing and integration components and it can be coupled to other
infrastructure services over a wide variety of transpo
rt protocols and data formats.

Finally, Fuse ESB supports event
-
driven architectures. Services deployed into the Fuse ESB
container can be fully decoupled, waiting idle on the bus until an appropriate service request
arrives.

The version of Fuse ESB used

in this project is the 4.4.1. Documentation and installation files
can be found under
their website
[3]
.

2.1

FIRST STEPS

2.1.1

Prerequisites



Java JDK 6 or later
[4]

§


SET
JAVA_HOME

environment variable to
J
DK_folder

installation directory

§


Add
JAVA_HOME /bin

to
PATH

environment variable



Ma
ven
[5]

§


SET
M2_HOME
environment variable to
MAVEN

installation directory

§


Set
MAVEN_OPTS

environment variable to
-
Xmx512M
to give the Ma
ven build more
memory in which to run

§


Add
JDK_MAVEN/bin

to
PATH

environment variable

2.1.2

Installation

2.1.2.1

Windows



Fuse ESB 4.4.1, is packaged either as a .zip file (Windows) or a .tar.gz file (*NIX). Using
a suitable archive tool, such as Zip or Gunzip, unpack
the distribution into a directory



Configuration:

§


Fuse ESB uses Apache Felix OSGi container by default

§


For changing it to Eclipse Equinox, open
etc/config.properties

file, change the
property
karaf.framework

to be:
karaf.framework=equinox

2.1.2.2

Linux



Downlo
ad the Fuse ESB Enterprise archive from the FuseSource Web

[6]
. The archive is
packaged as a tar.gz file. Unpack the archive in the target folder.



Configuration:

§


Fuse ESB uses Apache Felix OSGi container by default



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




6

/

39

§


For ch
anging it to Eclipse Equinox, open
etc/config.properties

file, change the
property
karaf.framework

to:
karaf.framework=equinox

2.1.3

Launching

NOTE: Some hints on how to interact with the ESB console after launching can be found in [1].

2.1.3.1

Windows



Start cmd.exe, go
t to
FUSE_ESB_INSTALLATION/bin
directory



Run the following command:
servicemix.bat


NOTE: Fuse ESB takes some time to load all its components and features, give it some time to
make sure it is started successfully

2.1.3.2

Linux



Open a terminal window and move to
F
USE_ESB_INSTALLATION/bin
directory



Run the following command:
./servicemix


NOTE: Fuse ESB takes some time to load all its components and features. A prompt and the
SERVICEMIX logo will appear when it has been started successfully.

2.2

Installation of LifeWear

bundles/libraries

This step has to be done before installing the specific components that set up the Wearable
Platform and that are introduced in Section 4. This step has also to be done before deploying a
bundle in the ESB with dependencies to the LifeWe
ar Ontology API. It is also mandatory to
follow the order indicated: API and API_Libraries afterward, otherwise unexpected behavior
may occur
.

NOTE: Make sure that the ESB is started, otherwise it’s not possible to deploy any bundle
within it.

2.2.1

WP5 Ontology

2.2.1.1

Ontology model configuration

Create a folder named “/ontologies” within the ESB directory and copy the .owl file containing
the model inside that folder
.

2.2.1.2

API libraries

To install the libraries that are required by the Ontology API, execute the following c
ommand
in the console of the ESB:

karaf@root> install file:[PATH]/API_Libraries.jar

NOTE: Substitute “PATH” with the location of the .jar file in your file systems.

After the execution of the install command and if everything is OK, a message showing the
i
dentifier assigned to the bundle is show in the console. The message should be similar to:
“Bundle id is 1”.

Once installed, the next step is to start the bundle. To do so, execute the following command:

karaf@root> osgi:start [bundleID]

NOTE: Substitute
“bundleID” with the identifier assigned after the installation
.

2.2.1.3

Ontology
API



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




7

/

39

The next step is then to install the bundle that provides the methods to access and interact
with the LifeWear ontology. In order to install it, execute the following command:



k
araf@root> install file:[PATH]/ API.jar

As before, once installed, the next step is to start the bundle using the command:

karaf@root> osgi:start [bundleID]



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




8

/

39


3

USAGE OF

THE

LIFEWEAR ONTOLOGY AP
I

The goal of this section is to describe how to create an execu
table project that consumes the
LifeWear Ontology API functionalities. The explanations given in this section and the pictures
attached to illustrate the process are based in the utilization of Eclipse as development
framework. Using
a

different developmen
t framework (such as Netbeans) is of course also
possible and the steps to reproduce are in essence the same. The objective of the
development is to obtain a deployable JAR file to be installed into the ESB, thus, the
implementation is not linked at all wi
th the development framework.

In order to deploy a bundle that uses the Ontology API into the ESB, the ontology API bundle
and the associated libraries bundle as explained in section 2.2.1 of the document have to be
already installed in the target ESB. Als
o, is also important to make sure that the ESB also
contains the ontology .owl model, otherwise any calls to the Ontology API will not work, since
the ontology semantic model is missing.

The steps to develop an ESB compliant bundle are listed below:

1.

Creat
e a new project of Plug
-
in nature.

2.

Edit the dependencies of the plug
-
in in the Manifest file as illustrated in Figure 3
-
1.

a.

Add a “Required Plug
-
ins” dependency to “OntologyLibraries”.

b.

Add an “Imported Packages” dependency to “context_API_Lifewear”.

NOTE: I
f the dependencies are added manually, Eclipse will report errors, since it is not
able to find the required plug
-
ins. Eclipse does not need to satisfy these requirements
correctly, since the goal is to deploy the jar in the ESB. However, in order to avoid

errors during the
bundle

development, and to make sure that the correct imports are
included and that the code is free of errors, it is possible to solve the errors with the
dependencies. In order to avoid the errors, copy the “OntologyLibraries” and the
“API”
.jar file in the “plugins” folder of Eclipse. Then, restart Eclipse and the errors should be
gone.


Figure
3
-
1



Required Ontology API and Ontology Libraries dependencies


1.

Now
it’s

time to use the Onto
logy API in our code. Some usage examples follow below:



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




9

/

39

Modifying context information
:
Modifying context information
: The below code creates a
new person named “
Fani
” and a new activity named “
working
”. Then the created activity
is added to the list of act
ivities that “
Fani
” is doing. This is accomplished as a transaction
.



Reading context information
:
The below code prints all the People concept instances
currently existing in the context model and the Activities instances bein
g performed by
those people
.




Printing all the context information represented in the context model
:
The next code
builds a SPARQL query to obtain all the tuples stored in the model, executes the query and
prints the obtained
results
.




2.

Once the development of the bundle logic has finished, the next step is to export the
project as a JAR in order to test within the ESB.

a.

To export the project select the “JAR file” option as seen on Figure 3
-
2. If you

try to export the project as a deployable plug
-
in the jar will not work in the
ESB.

b.

Configure the JAR name to generate and the export path as seen on Figure 3
-
3.
Select the same options as in the figure and click on the “Next” button (not in
the “Finish”
button).

String sparqlQueryString =
"SELECT ?s ?p ?o WHERE { ?s ?p ?o }"
;

ResultSet results
=Context
Model.executeQuerySELECT(sparqlQueryString);

ResultSetFormatter.out(results);

Con
textModel.transaction_begin(
"READ"
);

List people=Factory.
getAllPerson
(model);

Iterator it_p=people.iterator();

PersonImpl aux;

Iterator it_ac;

while
(it_p.hasNext()){

aux=(PersonImpl) it_p.next();

it_ac= aux.getActivity();

System.
out
.println(
"Activities tha
t "
+ aux.getName() +
" is doing:

"
);

while
(it_ac.hasNext()){

System.
out
.println(
"
\
t"
+((ActivityImpl)it_ac.next()).getName())}

}

ContextModel.
transaction_commit
();

Model model= ContextModel.model;

ContextModel.transaction_begin(
"WRITE"
);

PersonImpl p=(PersonImpl)

Factory.
createPer
son
(
"http://www.pros.com/individuals/Fani"
,
model
);

p.setName(
"Fani"
);

ActivityImpl a= (ActivityImpl)

Factory.
createActivity
(
"http://www.pros.com/ individuals/working"
,
model);

a.setName(
"working"
);

p.addActivity(a);

ContextModel.
transaction_commit
();



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




10

/

39


Figure
3
-
2



Option selected to export the Bundle as a JAR file


Figure
3
-
3



Configuration of the JAR file main properties




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




11

/

39

c.

Click again in the “Nex
t” button until you see the “JAR Manifest Specification”
option at the top of the window. The “Generate the manifest file” option is
selected by default, but it is necessary to select the “Use existing manifest
from workspace” instead as depicted in Figure

3
-
4, and select the
MANIFEST.MF file already existing in the project. This is
important;

otherwise
the JAR generated will not work in the ESB, because with the default option
the dependencies are not correctly included
.


Figure
3
-
4



Configuration of the JAR file Manifest properties

d.

Click on the finish button to generate the JARs file in the specified folder
.


3.

Now, the bundle is ready to be used in the ESB. Just install the file, start it and it should
be wo
rking and functional.




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




12

/

39


4

USAGE OF THE LIFEWEA
R WEARABLE PLATFORM

The integration of multi
-
disciplinary and heterogeneous devices in the Wearable platform is
internally performed by the means of integrating already existing middleware solutions as
depicted
in Figure 4
-
1. These different middleware solutions are also integrated in the ESB
following the same approach, which is to define a bundle gateway for each one in order to
make them “LIFEWEAR compliant”. Then, the LIFEWEAR ontology defined in WP5 provides

a
common interface to the Wearable Platform to share the information. Finally, the Applications
developed in WP4 connect to the ESB and consume the information available in the LIFEWEAR
ontology through the utilization of REST services
.



Figure
4
-
1


Overview of the LifeWear Wearable Platform internal Architecture


The approach of the
LIFEWEAR

Wearable Platform illustrated in Figure 4
-
1 is explained into
detail in D2.2 “Semantic Middleware Interoperability”.

Please refer to the mentioned
document to obtain more technical deta
i
ls about it, since the current document is concretely
focused on how to use the Wearable Platform.

The following subsections explain how to utilize the Wearable Platform at different le
vels.
First, subsection 4.1 explains how to integrate the date collected by the final devices in the ESB
thorough the utilization of intermediate middleware solutions. Secondly, subsection 4.2
explains how to utilize the REST services that are provided by
the Wearable Platform. It can be
said that this part is what really represents the essence of the Wearable Platform. Any final
user that wants to interact with the platform, should do it through these services, so it does
not matter how the platform intern
ally works. In order to define a new final application a user
can directly consume the data provided by the REST services or create a new ESB bundle that
uses the Ontology API
.


4.1

Deployment of producer bundles

This section explains how to install and deplo
y the gateways bundles defined for each
intermediate middleware in the ESB of the Wearable Platform. For each middleware the main


LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




13

/

39

characteristics, the devices connected to it and also the data provided by these devices are
described, which are finally REST

services
.

4.1.1

Sarein


Tecnalia

The middleware provided by Tecnalia is being used in the Ubiquitous Computing
scenario/demonstrator. For the time being, this producer bundle only provides sensors values.
The sensor measurements gathered are Temperature, Ambie
nt Light (both indoor and
outdoor, since there is more than one sensor deployed) and Weight Measurements taken from
a Weight Scale. These values are used in the scenario as additional sources of information in
order to generate the recommendations that ar
e presented to the user. For example, if the
outdoor temperature sensor detects a very high value, the recommendation to the user would
be to practice indoor exercise in order to avoid suffering sunstroke and the subsequent
problems that may affect the hea
lth of the person. User weight is taken into consideration
when recommending the type of exercise to perform.

The integration of the Tecnalia middleware in the ESB is divided in two steps. On the one side,
a bundle that serves as a gateway to the middlewa
re and makes the information provided by
the middleware LIFEWEAR compliant through the utilization of the LIFEWEAR Ontology
(storing also the data within it). On the other side, a bundle that connects to the Ontology and
offers the REST services associated

with the information of the devices provided by the
underlying middleware. The Figure 4
-
1 below illustrates the described process
.



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




14

/

39


Figure
4
-
2

Tecnalia Middleware integration with ESB


4.1.1.1

Prerequisites

4.1.1.1.1

Devices

For the time being, t
he device that is currently being utilized in this producer bundle is the
SunSPOT World Kit


[7]



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




15

/

39


Figure
4
-
3



SunSPOT Java Development Kit

This kit include
s wire
-
free sensor boards that provide different sensors measurements. The
boards can be combined in several ways to create complex networks of sensors.

The other element used is the weight scale from TaiDoc, model TD
-
2551.



Figure
4
-
4

-

TaiDoc Weight Scale

The weight scale provides measurements about weight and BMI. Communication with it is
granted thanks to an API provided by TaiDoc, but no more data can be provided because a
non
-
disclosure agreement bet
ween Tecnalia and TaiDoc was signed
regarding

this subject.


4.1.1.1.2

Libraries

No additional libraries are necessary to install in the ESB in order to make the

bundles run
correctly.

4.1.1.2

Bundles installation and configuration

As explained before, this solution is divi
ded in two different bundles that

have to be deployed
in the ESB in the following order:

-

Gateway bundle

This bundle is used to translate the ontology terms used in Tecnalia middleware
to the ones used in the ontology API, since they are different ontologie
s, a


LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




16

/

39

translator is needed. It used the ontology API to create the correspondent
LIFEWEAR ontology concepts. The name of the file is “
kp.integrator.plugin.jar
”.
The command to install the bundle in the ESB is the following:

karaf@root> osgi:install file:[PA
TH]:/ kp.integrator.plugin.jar

NOTE: Substitute “PATH” with the actual location of the jar in the
filesystem.

After executing the command the ESB associates a bundle Id to the element
just installed. Now, in order to
get the bundles

working
its

necessary t
o start it
using the following command:

karaf@root> osgi:start [bundleID]

-

REST interface bundle

This project depends on MAVEN
[5]

in order to provide the REST services
through the ESB. Since this bundle access the information a
vailable in the
LIFEWEAR Ontology in order to generate the REST services using JSON
messages, it is necessary to make sure that the Ontology API and the Ontology
Libraries have been previously installed in the corresponding MAVEN libraries
folder. The comm
ands to install these required bundles in the Maven
repositories are listed below:

cmd> mvn install:install
-
file
-
Dfile=20120524113250API_Libraries.jar
-
DgroupId=org.lifewear
-
DartifactId=20120524113250API_Libraries
-
Dpackaging=jar
-
Dversion=1.0.0

cmd> mvn

install:install
-
file
-
Dfile=API.jar
-
DgroupId=org.lifewear
-
DartifactId=API
-
Dpackaging=jar
-
Dversion=1.0.0


Once the bundles have been installed in MAVEN, the next step is to install the
bundles in ESB. The name of the file is “
lifewear.as.rest.json.jar

. The steps to
install and start this bundle are the same as explained before:

karaf@root> install file:[PATH]:/ lifewear.as.rest.json.jar

karaf@root> osgi:start [bundleID]

4.1.1.3

List of REST provided services

The previously explained bundles offer the following

REST services:

-

Outdoor Temperature.

-

Indoor Temperature.

-

Outdoor Light.

-

Indoor Light.

-

Weight
-
Scale.

In order to consume these services, it’s very important to know in advance the [IP] and [Port]
that is utilized by the server to expose the services. +


Out
door Temperature

The URI to consume the service is as follows:



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




17

/

39

http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/temperature_outdoor.json


The format of the answers proved is the following:



The possible measurements units f
or this value are: Celsius,
Fahrenheit

and Kelvin. By default
the temperature value is provided in Celsius
.


Indoor Temperature

The service can be reached at the following URI:

http://

[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/temperature_indoor.json


The format of the answer is as follows:



The possible measurements units for this value are: Celsius,
Fahrenheit

and Kelvin. By default
the temperature value is provided in Celsius
.


Outdoor Light

The URI to consume the servic
e is:

http://

[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/light_outdoor.json


The format of the answer is the following:


{






light_outdoor_value:

"X"





light_outdoor_unit: "X"

}


{






temperature_indoor_value: "X"





temperature_indoor_unit: "X"

}


{






temperature_outdoor_value: "X"





temperature_outdoor_unit: "X"

}




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




18

/

39


The possible measurements units for this value are:
Luminance, Candela and Lux
. By default
the temperat
ure value is provided in Luminance
.


Indoor Light

The service is available at the URI below:

http://

[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/light_indoor.json


The format of the answer is as follows:



The possible measure
ments units for this value are:
Luminance, Candela and Lux
. By default
the temperature value is provided in Luminance
.


Weight Scale

The service is available at the URI below:

http://

[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/scale_weight.json


The for
mat of the answer is as follows:


The possible measurements units for this value are: Kilograms and Pounds. By default the
weight value is provided in Kilograms.



4.1.2

UPM

UPM middleware is used in the Ubiquitous Computing scenario.

This middleware produces
both context (room temperature) and user´s physiological parameters (body temperature,
breath rate and heart rate). These values are utilized in the scenario as additional sources of
information in order to generate the recommenda
tions that are presented to the user. These
{






scale_weight_value: "X"





scale_weight_unit: "X"

}


{






light_indoor_value: "X"





light_indoor_unit: "X"

}




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




19

/

39

values are also used for alarms generation (
e.g.
: when the heart rate exceeds a specified value,
an alarm is sent to the user recommending stopping the exercise).

Alarms can be presented in a wide range of wearab
le devices:
smart phones
, WIMM Android
Watch

[10]
, etc.

The integration of the UPM middleware in the ESB is composed by a single bundled deployed
inside the ESB. This bundle acts a gateway between the WSN and the REST interface

offered to
access the services. The ontology is also used to store the data collected. A general overview of
the architecture is shown in next figure
.










LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




20

/

39


Figure
4
-
5

UPM Middleware integration with ESB


4.1.2.1

Prerequisites

4.1.2.1.1

Devices

The WSN is composed by SunSpot nodes, from Oracle

[7]
.

The device used to monitor user´s physiological data is the
Zephyr Bioharness

[11]
.
This device
is able
to collect several physiological data (heart rate, acceleration, position, breath data,
temperature, ECG, etc.). This bundle uses the heart rate, breath rate and body temperature.

4.1.2.1.2

Libraries

A standard Fuse/ESB installation includes all the required librar
ies for the UPM bundle.


4.1.2.2

Bundles installation and configuration

It is only necessary to install and start the UPM
-
Lifewear bundle:



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




21

/

39

osgi:install lifewearUPM
(This command installs bundle in the ESB)

osgi:start [bundle ID]
(This command starts the bundle
)


4.1.2.3

List of REST provided services

UPM lifewear bundle offers the following REST services:

-

Room Temperature.

-

Body Temperature.

-

Breathing rate.

-

Heart rate.

-

Alarms.


Room Temperature

The URI to consume the service is as follows:

http://
[IP]:[PORT]
/

cxf/crm/li
fewear/temp/[room_ID]

The JSON answer is as follows:


The possible measurements units for this value are: Celsius or
Fahrenheit
.


Body Temperature

The URI to consume the service is as follows:

http://
[IP]:[PORT]
/

cxf/crm/lifewe
ar/bodyTemp

The JSON answer is as follows:

{


"transport": "j2me.radiogram",


"envelope": "JSON
-
2.0",


"target": "[destination_addres
s]",


"origin": "[source_address]",


"response":


{



"operation": "temp",



"parameters": [ C , 0 ] ,



"result": "VALUE"


}

}



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




22

/

39



Measurement unit: Celsius.


Breathing Rate

The URI to consume the service is as follows:

http://
[IP]:[PORT]
/

cxf/crm/lifewear/breathRate

The JSON answer is as follows:



Measurement unit: Breathings per minute.


{


"transport": "j2me.radiogram",


"envelope": "JSON
-
2.0",


"target": "[destination_address]",


"origin": "[source_address]",


"respon
se":


{



"operation": "breathRate",



"parameters": [ VOID ] ,



"result": "VALUE"


}

}

{


"transport": "j2me.radiogram",


"envelope": "JSON
-
2.0",


"target": "[destination_address]",


"origin": "[sourc
e_address]",


"response":


{



"operation": "bodytemp",



"parameters": [ VOID ] ,



"result": "VALUE"


}

}



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




23

/

39


Heart Rate

The URI to consume the service is as follows:

http://
[IP]:[PORT]
/

cxf/crm/lifewear/HeartRate

The JSON answer is as follows:



Measurement unit: Beats per minu
te.


Alarms service

The URI to consume the service is as follows:

http://
[IP]:[PORT]
/

cxf/crm/lifewear/alarm

The JSON answer is as follows:

{


"transport": "j2me.radiogram",


"envelope": "JSON
-
2.0",


"target": "[destination_address]",


"origin": "[source_address]",


"response":


{



"operatio
n": "HeartRate",



"parameters": [ VOID ] ,



"result": "VALUE"


}

}



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




24

/

39



4.1.2.4

Security mechanisms

The middleware also includes some security mechanisms in order to
guarantee that only
authorized nodes are able to publish or consume data. The security system is based on trust
domains, and it is composed by several elements, which are presented below.

The Security Manager (SM) is the principal actor of the security m
odel, and should be an
external host able to generate symmetric and asymmetric keys securely. The ESB is the perfect
candidate for this task, but it is open for other elements depending on the implementation.
Several nodes (N) sharing the same Domain Key (
DK) and some aspects in common (mission,
localization, capabilities, etc.) define a Trust Domain (TD). Each TD has a Trust Policy (TP),
including the behaviors, measures, actions and other aspects regarding the life
-
cycle of a Trust
Domain. Also a Domain K
ey Server (DKS) exists in each TD.
The DKS

is a special node in charge
of distributing the Domain Key when needed. A single node can act as a DKS if the Security
Manager decides it.
Every
node in the network has its own Node
unique identification
(NID)
and

an individual Node Key (NK). The ciphering methods and keys sizes used when ciphering a
message are defined inside the Ciphering Suite (CS).

Since WSN nodes have several limitations, a full and robust Public Key Infrastructure

(PKI)

should not fit these
nodes. For this reason, a hybrid PKI and symmetric keys schema has been
used in this project.
Two types of keys are used in PKI cryptography: Public Key (Kp), the part of
the key assumed to be freely distributed, and Private Key (Ks), the part of the key t
o be kept in
secret and not distributed. In this security model,
PKI is used for the communication between
special nodes (Security Manager and Domain Key Server), and a simple
-
but
-
secure AES
symmetric key is used for the
regular

nodes. Size of this AES key

is constricted by the nodes
computing power and, thinking in a scalable architecture, is defined by a Ciphering Suite field
in the ciphered data packets, in order to determine the length of the key or select a new
algorithm (such as RC5, etc.).

Trust Doma
ins definition can be done following several policies: number of nodes per domain,
node localization, domains for specific functionality (e.g.: temperature measurement, intrusion
detection, environmental monitoring, etc.) or any other distribution demanded

by a specific
application.

{


"transport": "j2me.radiogram",


"envelope": "JSON
-
2.0",


"target": "[destination_address]",


"origin": "[source_address]",


"response":


{



"operation": "alarm",



"para
meters": "ALARM_TYPE" ,



"result": "VALUE"


}

}



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




25

/

39

For each Trust Domain defined, a Domain Key Server is assigned (either in deployment or run
time) and a Domain Key is shared. Any node participating in a TD can assume the DKS role if
the former DKS has been compromised. If the
compromise affects only a simple node, a re
-
keying method is enough: DKS asks SM for a new DK, and then this new key is sent to all nodes
but the compromised one, using each Node Key.

Domain Key Server stores its own pair of public and secret keys (and als
o the public key of the
Security Manager, so as to communicate with it), the Domain Key (to communicate with nodes
participating in the domain) and the security policy for the domain.

The other nodes also need to keep some important information: the node
id and key, the
Domain Key, the public key of the Security Manager (used if Security Manager assigns the role
of the former Domain Key Server to a new node)
.

Cryptographic information shared by nodes has been reduced to a minimum, in order to
minimize the
risk when a node is compromised. In
this

security model
, if a single node or a DKS
is compromised, just the Domain Key is evidenced (as the public key of the SM can be revealed
without security issues). Re
-
distributing a new DK or designating a new DKS wil
l be enough to
recover the
confidence
.



4.1.3

Deusto
-

Treelogic

Deusto


Treelogic bundle is the bundle developed in healthcare demonstrator. This bundle
manages the connection and data exchange between the ESB and the University of Deusto
middleware: Otsopack

[13]
. It is integrated in the ESB as an OSGI
-
bundle and it consists in an
Otsopack node that consumes data from the middleware as long as it receives REST petitions
from the application layer
.



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




26

/

39


Figure
4
-
6

Deusto

Treelogic Middleware integration with ESB

4.1.3.1

Prerequisites

4.1.3.1.1

Devices

The devices used in this bundle are the following ones:

Zephyr HxM

[12]



This device can monitor heart rate, instant speed dis
tance… but in this
bundle development, it only has been considered the following parameter:



Heart Rate

Zephyr Bioharness

[11]


This device is able to collect data form ECG, heart rate, acceleration,
position, breath data, tempe
rature… but in this bundle development, it only have been
considered the following parameters:



Heart Rate



Breath Rate



Electrocardiogram



Breathing Wave


4.1.3.1.2

Libraries



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




27

/

39

With the bundle installation, all required libraries are included, the only one that needs to
be
installed as an OSGI bundle is the
Ostopack library

[2
]
. It is required because an Ostopack
middleware’s node is integrated in the bundle.

This library must be installed from the ESB console with the next command:

osgi:install

s wrap:file:///
fileURL

Th
is command installs the library as a bundle in the ESB.

4.1.3.2

Bundles installation and configuration

The Deusto
-
Treelogic bundle is a Maven project and it has been developed with an open
source IDE, Eclipse. For this reason, the Eclipse
plug
-
in

“Maven Integra
tion for Eclipse” is
required. It can be downloaded from here:

http://marketplace.eclipse.org/content/maven
-
integration
-
eclipse

Once Eclipse is configured and ready for Maven,

these are the required steps for installing the
bundle in the ESB:

1)

The bundle must be compiled and installed in the Maven local repository. Because of
this, user should execute the following Maven instructions in the bundle Eclipse
project in the followin
g order.

i.


Maven Clean

ii.

Maven Generate
-
Sources

iii.

Maven Install

2)

Once the bundle has been installed in the Maven local repository, user must execute
these commands in the ESB console to deploy the OSGI bundle in the ESB.

a.

Installing the bundle in the ESB from the

Maven repository

osgi:install mvn:
groupId/artifactId

groupId

-

org.apache.servicemix.lifewearOSTO

artifactId
-

lifewearOSTO

After this installation command, the ESB assigns a “bundle ID” to the bundle.
This ID is required to manage the bundle (Start, Stop
, Delete).

b.

Starting the bundle execution

osgi:start
bundleID

Once the bundle has been started, it is ready to manage the REST requests. It
can be Stopped and Deleted with the following commands

osgi:stop
bundleID

osgi:uninstall
bundleID

3)

If the bundle proje
ct is modified, it will be necessary to repeat step 1) in the Eclipse
project, and update the bundle in the ESB with this command:

osgi:update
bundleID


4.1.3.3

List of REST provided services

Deusto
-
Treelogic bundle, offers the following REST services:



Heart Rate
service



Breath Rate service



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




28

/

39



Breathing Wave service



Electrocardiogram service

With these descriptions:

Heart Rate service

This service allows users to check the instant Heart Rate value received from the devices.
Its response is a JSON with multiple paramet
ers, but the Heart Rate value is contained in
the “
service_value
” tag. The rest of the JSON information contains the service units, the
service type, a timestamp the device name, the user name… This parameter can be read
from both devices (HxM and Bioharne
ss), so there is a parameter that allows users to
choose which device they want to use (if they want to specify any).

URI


http://
[IP]:[PORT]
/lifewear/example/pulse?device=
[DEVICE]
&callback=?

[IP]:[PORT]

: It is the IP direction and port of the ESB serve
r.

[DEVICE]
: It allows choosing the device to monitor the heart rate. It has three possible values,
with three possible responses.


“bioharness”
: JSON Response structure

?({

1:{

service_name
:
"Instant Heart Rate"
,

service_state
:
""
,


(active/inactive)

se
rvice_timestamp
:
""
,

(number of packet)

device_name
:
"Bioharness"
,

person_name
:
""
,


(not used yet)

service_type
:
"float"
,

service_units
:
"bps"
,

service_value
:
value

},

})


“hxm”
: JSON Response structure

?({

1:{

service_name
:
"Instant Heart Rate"
,

servi
ce_state
:
""
,


(active/inactive)

service_timestamp
:
""
,

(number of packet)

device_name
:
"Zephyr HxM"
,



person_name
:
""
,


(not used yet)

service_type
:
"float"
,

service_units
:
"bps"
,

service_value
:
value

},

})


“all”
: JSON Response structure

?({

1:{

serv
ice_name
:
"Instant Heart Rate"
,

service_state
:
""
,


(active/inactive)

service_timestamp
:
""
,

(number of packet)



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




29

/

39

device_name
:
"Bioharness"
,

person_name
:
""
,



(not used yet)

service_type
:
"float"
,

service_units
:
"bps"
,

service_value
:
value

},

2: {

servic
e_name
:
"Instant Heart Rate"
,

service_state
:
""
,


(active/inactive)

service_timestamp
:
""
,

(number of packet)

device_name
:
"Zephyr HxM"
,

person_name
:
""
,



(not used yet)

service_type
:
"float"
,

service_units
:
"bps"
,

service_value
:
value

}

})

This paramet
er is the only one which can be obtained from both devices. For this reason,
its JSON response (device=all) is composed by two JSON responses.


Breath Rate service

This service allows users to check the instant Breath Rate value received from the Zephyr
B
ioharness. Its response is a JSON with multiple parameters, but the Breath Rate value is
contained in the “
service_value
” tag. In the same way as Heart Rate service, the rest of
the JSON information contains the service units, the service type, a timestamp

the device
name, the user name…

URI


http://
[IP]:[PORT]
/lifewear/example/brate?callback=?


[IP]:[PORT]

: It is the IP direction and port of the ESB server

JSON Response structure

?({

service_name
:
"Instant Breathing Rate"
,

service_state
:
""
,


(active/
inactive)

service_timestamp
:
""
,


(number of packet)

device_name
:
"Bioharness"
,

person_name
:
""
,



(not used yet)

service_type
:
"float"
,

service_units
:
"bps"
,

service_value
:
value

})


Electrocardiogram service

This service allows users to check the user’s
Electrocardiogram (ECG) received from the
Zephyr Bioharness. Its response is a JSON with multiple parameters, but the ECG array is
contained in the “
service_values
” tag. This tag is an array with the user’s ECG in a
temporal window of 2 seconds long aprox.

As the rest of the REST services, the rest of the JSON information contains the service
units, the service type, a timestamp the device name, the user name…

URI


http://
[IP]:[PORT]
/lifewear/example/ECG?callback=?



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




30

/

39

[IP]:[PORT]

: It is the IP direction and

port of the ESB server

JSON Response structure

?({

service_name
:
"ECG"
,

service_state
:
""
, (active/inactive)

service_timestamp
:
""
,


(number of packet)

device_name
:
"Bioharness"
,

person_name
:
""
,



(not used yet)

service_type
:
"float"
,

service_units
:
"
mV"
,

service_initial_time
:
""
,

service_time_step
:
0.004
,

service_num_values
:
504
,

service_values
:

[
Value0,

Value1
,

Value2
,



Value503
]

})


Breathing wave service

This service allows users to check the user’s Breathing wave (BWave) received from the
Zephyr

Bioharness. Its response is a JSON with multiple parameters, but the BWave array
is contained in the “
service_values
” tag. This tag is an array with the user’s breathing
wave in a temporal window of 5.9 seconds long aprox.

As the rest of the REST services
, the rest of the JSON information contains the service
units, the service type, a timestamp the device name, the user name…

URI


http://
[IP]:[PORT]
/lifewear/example/bwave?callback=?

[IP]:[PORT]

: It is the IP direction and port of the ESB server

JSON Re
sponse structure

?({

service_name
:
"Breath Rate Array"
,

service_state
:
""
, (active/inactive)

service_timestamp
:
""
,


(number of packet)

device_name
:
"Bioharness"
,

person_name
:
""
,



(not used yet)

service_type
:
"float"
,

service_units
:
"Amplitude"
,

serv
ice_initial_time
:
""
,

service_time_step
:
"0.05556"
,

service_num_values
:
108
,

service_values
:

[
Value0,

Value1
,

Value2
,



Value107
]

})




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




31

/

39

4.1.4

Telefonica I+D

In order to integrate applications in L
IFEWEAR

project, an ESB has been provided via an OSGI
bundle. Thank
s to this bundle, the applications developed by consortium partners may be
integrated in a single platform.

In our case (group training application) we have not used most of the functionalities provided
by the ESB. The main functions used are hardware and
location abstraction for the data server
and the client application, i.e. The ESB is mainly used between the server and the client as a
bridge. This is shown in
the following figure:



Figure
4
-
7

TID ESB int
egration into LIFEWEAR platform


T
he exchange of data between the client

PC
, the OSGI server

bundle



the ESB

-

and the
server

providing the data
can be seen
with more detail in
the following figure
.




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




32

/

39


Figure
4
-
8

Client
-
Server interaction detail



One of the main advantages of the ESB approach is the possibility to use resources provided by
other partners or entities, thus being able to use data coming from different sensors such as
outdoor temperature, humid
ity, etc.

By using the ESB we could also combine data from different sensors to obtain more complex
services. For instance, we could compose the data provided by an ambient measuring device
with the data provided by a vital constants measuring device to ob
tain other not so evident
data such as instant performance, performance evolution, tiredness,

health risk detection,
illness, etc.


4.2

R
est services
consumption

guide

Most of the data exposed by the LIFEWEAR framework can be consumed by making queries
using a

REST interface that, when responding, offers the data using the well
-
known JSON
format. The current section, servers as a general purpose user guideline on how to consume
and interact with REST services that provides an answer in the JSON format. To see t
he
concrete list of REST services provided by the Wearable Platform, check the subsections
named “List of REST provided services” that are part of the previous section.

Using JSON implies having to parse or deserialize the response obtained when querying t
o the
LIFEWEAR PLATFORM for data into a specific data representation that varies depending on the
programming language: Javascript, Java, C++, ObjC, etc. Most of the times the objective of the
parsing procedure is to obtain a representation of the response

as an instance of a pre
-
defined
class in the programming language selected.

For instance, if a user of the LIFEWEAR PLATFORM asks for temperature outside a room or
building, most surely this implies that there is a class with concepts such as
:



location



m
easurement



user



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




33

/

39



Etc...

After querying for the data, if there is data existent, response could be something like this:



The message itself needs to be parsed into
an

object representation in most languages, a
process known as “d
ecoding” or “parsing”. There are many ways to achieve this, but most of
them comprise the use of third
-
party libraries that ease the coding/decodin
g JSON messages.
To name a few:

Java

C

C++

C#

PHP

Simple
-
json

Gson

Flexjson

JSONlib

Jettison

org.json

CJSON

json
-
c

Jansson

JSON_checker

jsoncpp

libjson

JSONKit.

ThorsSerialize
r

JsonBox

rapidjson

fastJSON

LitJSON

JsonFx

JSONShar

fluent
-
json

Manatee Json

json

Services_JSON

Zend_JSON

Solar_Json


Obviously there are differences among those libraries, but an analysi
s on those differences is
out of the scope of this document. An example using one of the most famous Java JSON
libraries, Gson, will depict how to parse an incoming JSON message.

Gson converts Java objects into a JSON message and vice
-
versa, is capable of
converting a
JSON message into a Java object. It can even work with objects pre
-
defined, where the source
of t
hese objects is not available.

Let us suppose a developer that uses the LIFEWEAR PLATFORM receives the JSON message
depicted before:

{"message": {


"user": "John Doe",


"measurement": "temperature",


"location": "outdoor",


"value": "32.5",


"unit": "Celsius",


}

}




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




34

/

39



Using Java, Gson and supposing there is

a class named Message, which

could look like this:



The process to transform the received JSON message into an instance of the Message class
could not be simple thanks t
o Gson, as depicted below:

public class Message {


private String USER;


private String MEASUREMENT;


private String LOCATION;


private String VALUE;


private String UNIT;



@Override


pu
blic String toString() {


String ret = new String();


ret = “Message received from “ + USER + “ type “ + MEASUREMENT +
“ in “ + LOCATION + “ with value “ + VALUE + “ expressed as “ +
UNIT;


return ret;


}

}

{"message": {


"user": "John Doe",


"measurement": "t
emperature",


"location": "outdoor",


"value": "32.5",


"unit": "Celsius",


}

}



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




35

/

39



Once Gson converts the JSON message into an
instance

of Message, the developer has full
access to the object properties for further process (storage, reasoning, etc). Clearly this is a
quite straight

forward and simple way to decode JSON messages. This was a simple example,
but Gson can also handle complex object structures, such as those that have lists or arrays
in
the fields section or even
other classes, thanks to the use of Java Reflection.

That
said, a user/developer of the LIFEWEAR PLATFORM has a wide array of
possibilities

to
choose from, selecting the programming language and the associated JSON parsing library in
order to be able to consume the information/services provided by the LIFEWEAR PL
ATFORM.
The usage of a REST interface with JSON responses allows a platform independent data
consumption
and unified

way to ac
cess
that

services/information

although it requires a slight
effort in the developer side for the composition of services.

import java.io.IOException;

import jav
a.io.InputStreamReader;

import java.io.Reader;

import com.google.gson.Gson;

import com.google.gson.GsonBuilder;


public class JsonToJava {



public static void main(String[] args) throws IOException {


Reader reader = new InputStreamReader(JsonToJava.c
lass


.getResourceAsStream("Server.json"));



Gson gson = new GsonBuilder().create();


Message m = gson.fromJson(reader, Message.class);


m.toString();


reader.close();


}

}




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




36

/

39


5

WEARA
BLE PLATFORM IN THE
LIFEWEAR REPOSITORY

The assets that form part of the prototype of the Wearable Platform are available at the
Project management and Wiki website in the following location:
http://lifewear
.info/pm/index.php

NOTE: In order to obtain a username and password to enter this internal website, ask for
credentials to Mobilera, which is in charge of the website.

Once you enter the website, select the “Files” menu option, and at the right side of th
e page
you will see the following menu that contains folders for all the work packages of the project
and also for the demonstrators:


Figure
5
-
1



LifeWear project website Files area

The contents of the Wea
rable Platform prototype are located under the “wp2” folder, and
more concretely in the “D2.4 Wearable Platform”

sub
-
folder within it. As depicted in Figure 5
-
2, this folder contains additional folders with the aim to organize the information as described
in the current deliverable, with the aim to facilitate the identification of the different assets.




LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




37

/

39


Figure
5
-
2



Wearable Platform Prototype contents

These folders contain the libraries and jar bundles me
ntioned along the documents. Sections
2.2.1, 4.1.1.2, 4.1.2.2 and 4.1.3.2 give detailed instructions on how to install the bundles in
order to start working with them.


LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




38

/

39


6

CONCLUSION
S

AND FURTHER STEPS

This document represents the final delivery of the LIFEWE
AR Wearable Platform, and is
distributed together with the Platform SW Prototype, with the aim to serve as a usage manual
for the potential users. The installation, configuration and first steps of the different assets
that constitute the Wearable Platform

are described along the document. The development of
the Wearable Platform is finished at this time.

The demonstrators and scenarios defined in WP1 and WP6 play a key role in the development
of the Wearable Platform. To some
extent
, it can be said that th
e development of the Platform
is somehow driven by the evolution of the defined demonstrators. The explanation of this is
that the demonstrators serve to test the robustness and performance of the implemented
solution. The demonstrators have evolved (and c
ontinue evolving) to include new devices and
functionalities, and the different assets that are deployed in Platform ESB have to be updated
accordingly to give support to the new required functionalities.

Thus, this documents
summarizes

all the work devel
oped in WP2 regarding the LIFEWEAR
Wearable Platform. The platform itself should be ready to use in the rest of LIFEWEAR work
packages
.



LifeWear, Mobilized Lifestyle with Wearables

©
LifeWear




39

/

39


7

REFERENCES

[1]

Fuse ESB
http://fusesource.com/product
s/enterprise
-
servicemix/

[2]

Apache Service Mix
http://servicemix.apache.org/

[3]

Fuse ESB enterprise
http://fusesource.com/products/fuse
-
esb
-
enterpris
e

[4]

Java Oracle
http://www.oracle.com/technetwork/java/javase/downloads/index.html

[5]

Maven
http://maven
.apache.org/download.html

[6]

Fuse ESB 4.4.1
http://fusesource.com/products/fuse
-
esb
-
enterprise.Fuse ESB 4.4.1

[7]

SunSpots
http://www.s
unspotworld.com/

[8]

TaiDoc Weight Scale
http://www.taidoc.com/weight
-
scales
-
TD
-
2551.html

[9]

ESB Console commands reference documentation
http://fusesource.com/docs/esb/4.2/command_ref/ESBintro.html


[10]

WIMM One Watch
http://www.wimm.com/

[11]

Zephyr BioHarness
http
://www.zephyr
-
technology.com/team
-
performance/bioharness
-
3/

[12]

Zephyr HmX
http://www.zephyranywherestore.com/corporate/dp/B009I08RB2

[13]

Otsopack Library
http://code.google.com/p/otsopack/