Modularized middleware architecture
for smart home & smart home lab
Software Engineering Laboratory
Department of Computer Science
Iowa State University
Design goals
• Reconfigurability
– Service coordinator (Service composer)
• A new description language or a extended version of BPEL4WS
– Service execution engine
• Scalability
– Fully modularized/Impendent layers
• operating system independent
• Application interchangeability by supporting Uniform APIs
– Easy to add/remove new services
• Component-based services to support “plug-and-play”
• Modularity
– Boundary between the layers for the smart home and the ones for the
smart home lab
• Our architecture includes the features that are required for experiments and
help write lab-only-used applications
• Two Java-based frameworks
– Minimize overhead at the deployment phase
Design characteristics
• Service
– All the services of the smart home are context-aware.
• Thus, service design also includes context analysis.
– Two levels of services to be associated
• Context-based service (high-level)
– The service delivered to a customer based on their necessity or
preference
• Device-specific service (low-level)
– The description of basic functionalities of a device such as sensors or
controllers
• Layered Middleware architecture
– Clear interface definitions between the layers
• EJB-based component support
– Java can work with (or over) OSGi
– JavaME is available for small devices
– Easy to interact with other services by extending smart home
services to web services
Middleware architecture overview
Web-based interface
Application
Service support
Service
DB (SDB)
Design
module
Device normalization/Integration
Physical
Availability
Service
Execution
module
Audit
module
Safety
CaseBased
module
Knowledge
DB (KDB)
Security
Context
analysis
module
Dev/Exp support
Middleware architecture layers (1/4)
• Physical
– Consist of a variety of devices and appliances such as cell
phones, PCs, PDAs, sensors, detectors, controllers (for example,
X10), etc.
• Device normalization/Integration
– Wrap any devices and appliances of the physical layer in a
software service to construct device-specific services
• Register them with service framework interfaces (SFIs)
– Java-based integration environment for services
• Communication management, Message processing, etc.
• Shared databases
– Knowledge database (KDB) for context-awareness
– Service database (SDB) for service publication and discovery
Middleware architecture layers (2/4)
• Service support
– Context analysis module
• Reason a situation based on diverse context through the
KDB
• Associate a context with a service in order to construct
context-based services
• Types of context
– Static context: Bar code, RFID tag, …
– Dynamic context: the data of sensors/controllers
– Service execution module
• Binding a service with real software
– Question: Need dynamic service composition?  Inference
engine
• Invoke services though the SDB
– Implicitly based on the context analysis
– Explicitly by the occupant
Middleware architecture layers (3/4)
• Development/Experiment support
– Design module
• Register/Publish an service
• Manage the SDB
• Describe using a standard service description language such
as WSDL
– Case-based module
• Define an association of a context with services
• Manage the KDB
• Describe using a new language or an extended version of
BPEL4WS
– Audit module
• Logging/Extracting data and status information
– Publish exceptional conditions
• Interact with the SDB and the KDB
Middleware architecture layers (4/4)
• Application
– Manage/Scheduling independent programs to
monitor/control services
– Examples
•
•
•
•
•
Context descriptor
Audit analyzer
Service composer
Service simulator
Service administrator
• Web-based Interface
– Optional to offer a consistent interface to occupants
– Provide ubiquitous accessibility by making
applications web-accessible
• Support remote access via both wired and wireless internet
Requirements for smart home lab (1/3)
•
The key requirements for the smart home lab
1.
2.
3.
4.
5.
SHL/SH shall have wireless/wire network
SH shall be operated normally when the middleware
architecture is abnormal
SHL/SH shall have the security mechanism
SH shall have the ability to detect occupants’ context and
identification if there are more than one occupant
Middleware Architecture
1)
The middleware architecture shall accept inputs/commands from
i.
ii.
iii.
iv.
v.
vi.
2)
Cell phones
PCs
PDAs
Sensors
detectors
Controllers (such as X10)
The middleware architecture shall have the ability to
communicate with other organizations
Requirements for smart home lab (2/3)
•
The key requirements for the smart home lab (cont)
5.
Middleware Architecture (cont)
3)
The middleware architecture shall give commands/outputs to
i.
ii.
iii.
iv.
v.
4)
5)
6)
7)
8)
9)
Cell phones
PCs
PDAs
Devices
Other organizations
The middleware architecture shall store data such that it can be
imported/exported in some specific formats (efficiently)
The middleware architecture shall be able to discover plug-in devices
The middleware architecture shall have the ability to integrate
appliances/devices
The middleware architecture shall automatically turn on/off some
appliances/devices if some specific events occur
The middleware architecture shall be able to change its behavior for
time- and situation-awareness
The middleware architecture shall be able to remind the occupants for
some specific things
Requirements for smart home lab (3/3)
•
The key requirements for the smart home lab (cont)
6.
Device Control
1)
2)
3)
7.
Researchers shall be able to enable/disable devices
Researchers shall be able to view/retrieve the status of a device
Researchers shall be able to operate all the functions of a device
Experiment Simulation Capability
1)
2)
3)
Researchers shall be able to create the
services/simulations/experiments over the middleware architecture
Researchers shall be able to extract system status information
Researchers shall be able to develop their new applications
Device Normalization/Integration
• OSGi (Open Services Gateway Initiative)
• EJB (Enterprise Java Beans)
Mobile telephone
Tablet PC
Indoor Communication
Outdoor
Communication
Powerline
B/S/
H/
Resi
denti
al
Gate
way
Why EJB/OSGi? (1)
To support component-based software architecture
–
–
–
–
–
Modular Components (EJB/OSGi)
Reusability (EJB/OSGi)
Collaborative Model (OSGi)
Highly Dynamic (OSGi)
Software Lifecycle Management (OSGi)
• EJB
– Visual assembly of applications
• OSGi
– Open industry framework and service-oriented
architecture
– Deployment of services in platforms
Why EJB/OSGi? (2)
• Advantages of OSGI
– OSGi defines a framework to mange bundles (units of
distribution) and the services they export
– Services can be obtained by querying the framework
through a set of properties
• Disadvantage of OSGi (cons of EJB)
– Assemblies are not static. Connections between
bundles occur depending on the availability of services
• Solutions [Cevantes02]
– Use bundles as distribution units that contain
JavaBeans
– Make these bundles export some particular services
that allows for the creation of instances of the
JavaBeans they export
– Give JavaBeans access to the OSGi framework, so
that they can quey for services in a complete way
[Cevantes02] H. Cervantes and J. Favre, “Comparing JavaBeans and OSGi Towards an Integration of Two
Complementary Component Models”, Euromicro Conference, 2002.