A Master Thesis on: Service Management for Smart Spaces (Intermediate T alk) Milad Khanibeik Supervisor: Prof. Dr.-Ing. Georg Carle Advisor: Marc-Oliver Pahl, Dipl.-Inform. April 2014 1
Structure of the Presentation • Smart Space Challenges • Requirements • Related Approaches and T echnologies • System Architecture • Evaluation Criteria • Timetable 2
Smart Space Challenges • Heterogeneity • Dynamicity • Complexity of application development • Some requirements of smart space services: • Portability • Reliability • Optimized resource usage • Energy saving 3
DS2OS Virtual State Layer: • A middleware to store and provide the states used by services • Interface portability • Fixed set of API between services (get/set, notify/subscribe, search, add/remove Sub-tree, register/unregister) • Location transparency • Service discovery 4
Requirements • Services need to be installed and updated in or removed from a smart space dynamically at runtime • Services should be distributed optimally among all the computing nodes to balance the load and reduce unnecessary network communications among computing nodes • The system should provide high level of resilience and reliability 5
Steps to Implement the Requirements The requirements can be implemented using these steps: 1. Service Portability: smart space services should be portable and dynamically deployable. (portability) 2. Service Control & Management: a module is needed to start/stop services at runtime, update them if any available, and rollback to an older version if any failure happened. (dynamicity) 3. Service Distribution: system’s load is measured and service instances should be distributed among computing nodes based on that. (reliability) 4. Service Monitoring: services execution is monitored to make sure they are still alive and working properly. 6 (reliability)
Related T echnologies and Researches • Virtual Machines: • Aura • Aura aims to create an environment that adapts • Migration of VMs among physical Portability: Isolating User T asks Portability: Isolating VMs itself based on the users’ context and needs machines (portability) (dynamicity). • VMs can be dynamically started, stopped Dynamicity: Environment and task Dynamicity: Middleware approach • It acts as a proxy for users: when a user enters a and migrated to another physical managers to adopt the task based on to partition HW new environment, his or her Aura marshals the machine (dynamicity) the current device and available appropriate resources to support the user’s task. • Using middleware approaches to applications • Aura Components: Task Manager , Context partition hardware into difgerent VMs Observer , Environment Manager , and Service • Universal Plug and Play Suppliers • Gaia: • Networked devices can join and leave Portability: Assign IP address the network easily and discover each • Homes, offjces, and meeting rooms capable of other and establish a network service to sensing user actions and equipped with a large communicate and share data (portability variety of devices will assist users with difgerent Dynamicity: Registrar nodes to tasks. and dynamicity) manage communication • Using DHCP and SSDP to handle • Other smart space solutions (HomeOS, H- Omega) dynamicity 7
Components Hierarchy 8
Service Containers • We need to add dynamicity to the Java environment to make jar fjles (smart space services) dynamically deployable: • Wrap services in OSGi bundles. • OSGi: • OSGi is a standard and secure component-oriented environment for the Java programming language that controls the life cycle of components and networked services anywhere in the network, something that does not exist in standalone Java environments. • iPOJO: • iPOJO is based on OSGi (facilitates the development) • Separates the non-functional parts from the core business logic • Manages the component instance lifecycle and the environment dynamics as never before possible • Service Hosting Environment: • iPOJO framework factory to deploy/remove iPOJO bundles 9
Managing Components • We introduced a hyper (half distributed, half centralized) managing service to control and monitor the smart space services. • Node-Local Service Manager (the distributed part) is running on all the computing nodes inside the network and monitors the execution of the services • Site-Local Service Manager (the central part) is running on one computing nodes and monitors the NLSMs, assigns services to them to execute, and manages the communication between the smart space and the global application store. 10
Node-local Service Manager (NLSM) • Running on each computing node of the smart space • Starts and stops services on its computing node • Monitors services to make sure they are alive and work properly • Sends feedback about service problems to the site-local service manager • Updates services if any update is available • Rolls back service if the updated one didn’t work and send feedback about this problem to the site-local service manager 11
Site-local Service Manager (SLSM) • Distributes services among computing nodes • Communicates with the Global Application Store to download and update services • Monitors NLSMs to make sure they are still alive and work properly • Restarts dead NLSMs and reassign services back to them • Checks for service dependencies on deploy time of services • Sends all the received feedbacks from all NLSMs to the application store 12
Global Application Store • A central place for: • developers to put their services • smart space users to download needed services • Rating mechanisms: • Explicitly by users • Implicitly by feedbacks of service executions from SLSMs 13
UI Service A place for Interactions between users and the system 14
System Architecture 15
Evaluation Criteria • User can install/remove services at runtime. • Services should be updated automatically if any is available. • Service dependencies should be considered at the deployment time. • Services execution will be monitored and feedback messages will be sent • Load is balanced among all computing nodes • Down services should be detected and restarted ASAP 16
How to test the system? • T est the system with 40 computing nodes and install 50 services at runtime on each • Services should be distributed optimally (not necessarily normal distribution) • Down services should be detected and restarted in less than a threshold time • Important services will be deployed n times (n is defjned by the system administrators) 17
Timetable 18
Implementation Phase Service Containers (~100 Line of Code) Service Hosting Environment (~300 LOC) Node-Local Service Manager (~500 LOC) Site-Local Service Manager (~700 LOC) Feedback Mechanism (~200 LOC) Global Application Store (~180 LOC) GUI service (~150 LOC) Deploy important services n times 19
Summary • Add features and new functionalities to the DS2OS to: • Add/Update/Remove services dynamically at runtime • Control life cycle of services • Balance the load among computing nodes • Monitor services • Send feedback about service execution to the GAP • Increase reliability of the smart space 20
References • [Harp03] Richard Harper. Inside the Smart House. Springer. 2003 • [RCKZ13] Vaskar Raychoudhury, Jiannong Cao, Mohan Kumar and Daqiang Zhang. Middleware for pervasive computing: A survey. Pervasive and Mobile Computing 9(2), 2013, P . 177-200. • [PaCa13c] Marc-Oliver Pahl and Georg Carle. The Missing Layer - Virtualizing Smart Spaces. In 10th IEEE International Workshop on Managing Ubiquitous Communications and Services 2013 (MUCS 2013), San Diego, USA, 2013. P . 139-144. • [Alli07] OSGi Alliance. About the OSGi Service Platform. http://www.osgi.org/wiki/uploads/Links/OSGiT echnicalWhitePaper.pdf, Jun 2007. • [EsHL07] Clement Escoer, Richard S. Hall and Philippe Lalanda. iPOJ: an Extensible Service-Oriented Component Framework. In IEEE Service Computing Conference 2007, Hawaii, USA, July 2007. • [Felib] Apache Felix iPOJO. http://felix.apache.org/documentation/subprojects/apachefelix-ipojo.html. 21
Thank You! 22
Recommend
More recommend
