QuA
Service Plans for Context- and QoS-aware Dynamic Middleware
SIUMI’06 SIUMI’06 Sten Sten A. A. Lundesgaard Lundesgaard (presenter), (presenter), Ketil Ketil Lund Lund and Prof. Frank Eliassen and Prof. Frank Eliassen
Simula Simula Research Research Laboratory Laboratory University University of of Oslo, Oslo, Norway Norway
Agenda ••
Background and Problem
••
Approach - to enable mobile middleware support QoS-sensitive applications in a dynamic environment
••
Contribution –middleware architecture and service plan concept
••
Life-Cycle Phases –application
Background (1) ••
Currently Currently mobile mobile terminals terminals and and mobile mobile communication communication systems systems provide provide bestbesteffort QoS. effort QoS.
••
Application Application provide provide and and maintain maintain QoS-levels: QoS-levels: ••
QoS QoS mechanisms mechanisms integral integral part part of of the the application application logic logic (e.g., (e.g., rate rate adaptation, adaptation, content content processing, processing, error error correction). correction).
••
Applications Applications dynamically dynamically reconfigure reconfigure itself itself (e.g., (e.g., add, add, remove, remove, or or replace replace component). component). Cellular
Mobile com. sys
Symbian, PocketPC WLAN Linux, Windows
IP-network
Linux, Unix
LAN
Background (2) ••
Academia Academia works works on on dynamic dynamic middleware; middleware; employs employs alternatives alternatives of of the the application application together together with with late late bindings bindings (of (of components) components) for for run-time run-time configuration. configuration.
••
Management Management plane plane and and hard-coded hard-coded rules rules to to control control reconfiguration reconfiguration of of component component composition composition
••
Meta-level Meta-level for for introspection introspection of of the the running running application. application.
Problem ••
Each alternative explicitly (and completely) specified, i.e., many configurations equal number of specifications.
••
Dynamic (Re)Configuration according to changes in the environment, i.e., context-awareness only.
••
Specification specialised for platform, no reuse of specification and thus the alternative application.
Application Dynamic Middleware
Approach (1) ••
To solve the problem, we advocate that mobile middleware should be both context- and QoS-aware. Î Î ContextContext- and and QoS-aware QoS-aware architecture architecture
••
Use components as software entity for late-binding and -configuration: ••
Selects Selects and and combines combines components components for for aa given given context context and and resource resource QoS QoS characteristics characteristics and and user user QoS QoS requirements. requirements.
••
During During mobility mobility the the middleware middleware dynamically dynamically reconfigure reconfigure the the application application to to context context changes changes and and to to maintain maintain QoS: QoS: •• Parameter Parameter settings settings of of individual individual components components •• ••
Composition Composition of of components components Implementation Implementation of of component component type type
Approach (2) ••
Each alternative application configuration is prepared at design time and deployed onto the mobile middleware.
••
Specifications of the alternatives and internal representation within the middleware. Î Î Service Service Plan Plan Concept Concept
Agenda ••
Background and Problem
••
Approach - to enable mobile middleware support QoS-sensitive application in a dynamic environment
••
Contribution –middleware architecture and service plan concept
••
Life-Cycle Phases –application
Context- and QoS-aware middleware architecture (1) ••
Traditional Traditional mechanisms mechanisms supported, supported, e.g., e.g., context context and and reconfiguration reconfiguration management management
Î Î In In our our QoS-aware QoS-aware middleware middleware architecture architecture employ employ hooks hooks for for QoS QoS management management mechanisms. mechanisms.
Context- and QoS-aware middleware architecture (2) Î Î Service Service type type and and Service Service Plan Plan explicitly explicitly defines defines meta-level meta-level in in architecture. architecture. Î Î ServicePlanner ServicePlanner chooses chooses the the application application configuration configuration based based upon upon information information from ContextManager and ResourceManager and the service plans. from ContextManager and ResourceManager and the service plans. Î Î ServicePlanner ServicePlanner decides decides when when and and what what to to reconfigure, reconfigure, based based upon upon service service plans. plans. Î Î Configuration Configuration and and Reconfiguration Reconfiguration managers managers use use meta-level meta-level to to (re)configure (re)configure the the application. application.
Service Plan Concept (1) ••
An An application application is is formed formed by by many many components. components.
••
Each Each one one offers offers aa service, service, which which is is grouped grouped into into compositions compositions of of services. services.
Service Plan Concept (2) ••
To To be be able able to to define define alternatives alternatives of of these these compositions: compositions: •• Make Make the the interface interface of of each each service service explicit, explicit, i.e., i.e., service service type type ••
••
Introduce Introduce aa recursive recursive structure structure of of services. services.
Variation Variation points points are are placed placed in in the the structure structure and and service service type. type. ServiceTypei Servicej ServiceTypejk
ServiceTypej1 OR Servicej1 ServiceTypejl1
Servicej2
Servicejl
ServiceTypejl2
ServiceTypejlm
OR Servicejl1
Servicejl2
Servicejl3
Servicejln
Service Plan Concept (3) ••
Need Need some some means means to to associate associate the the implementation of a service to the implementation of a service to the service service type type Î Î the the service service plan. plan. ServiceType
••
1
Plan Plan specifies specifies ••
aa composition composition
••
aa component component
1..n
0..1
Component
Service Plan Concept (4) Extends the plan to include information elements about: ••
Dependencies Dependencies to to the the context context
••
Any Any parameter parameter configurations configurations
••
QoS QoS characteristics characteristics
ServicePlan 1..n
••
0..n
1
Application Life-Cycle
Application Design
Service Plan
Context- & QoS-aware architecture Context and Resource QoS changes
Life-Cycle –Deployment (1) ••
••
••
Service Service types types and and Service Service plans plans are are deployed deployed using using WSDL WSDL and and XML XML respectively. respectively. ••
Open Open standards, standards, Human Human readable, readable, and and supported supported by by software software design design tools. tools.
••
Service Service types types and and plans plans are are parsed parsed and and analysed analysed using using existing existing (J)DOM (J)DOM API API since since generic generic and and small small total total foot-print. foot-print.
In In case case of of aa service service composition composition the the WSDL WSDL file file (i.e., (i.e., the the service service type type to to the the subsubservice) service) imports imports the the name name spaces spaces of of the the services services in in the the composition. composition. ••
Avoid Avoid duplication duplication of of information. information.
••
Reuse Reuse of of to/from to/from message message definitions. definitions.
Service Service Plans Plans employ employ aa tree tree structure. structure. ••
Elements Elements (among (among other other things) things) for for specifying specifying dependencies dependencies to to context context elements in environment and calculating QoS at application and elements in environment and calculating QoS at application and user user level. level.
Life-Cycle –Deployment (2) ••
Specifying Context dependencies:
Life-Cycle –Deployment (3) ••
Specifying QoS: inputqoscontract_id state operation
qosmodel_id qosmapping_id
offeredServices
qosCharacteristics
inputQoSContract
contract_id
inDimension lowestQoS model_id
qosModel funcDimension qosMapping
mapping_id
function allocation
dimension unit direction minQoSvalue maxQoSvalue
Summary ••
Context- and QoS-awareness can be achieved in the mobile domain.
••
Require means to specify alternative application configurations independent of target platform.
••
Our solution: ••
New New contextcontext- and and QoS-aware QoS-aware middleware middleware architecture. architecture.
••
Concept Concept for for specifying specifying and and representing representing in in the the middleware middleware the the application application configurations configurations and and their their QoS QoS characteristics. characteristics.
Final Discussion
New services, design and rapid prototyping ••
••
The The idea idea of of services services and and service service composition composition is is not not new. new. Still Still they they are are useful useful the the terms, terms, since since enable enable us us to to discuss: discuss: ••
software software without without having having to to take take into into consider consider implementation implementation technologies. technologies.
••
reuse reuse of of existing existing fully fully functional functional software software that that can can be be accessed accessed by by users. users.
Increased Increased proliferation proliferation of of Internet Internet and and mobile mobile terminals terminals ++ ERP ERP and and e-commerce e-commerce and and m-commerce m-commerce systems systems => => engineering engineering methods methods and and tools tools and and middleware middleware that that allow allow for for shorter shorter development development time time at at aa lower lower cost cost and and self-configuration. self-configuration.
••
Hence, Hence, concepts concepts and and mechanisms mechanisms for for service service (oriented (oriented computing) computing) should should be be aa natural natural evolution evolution of of existing existing OOD OOD and and target target platforms. platforms.
Middleware, significant requirements for best support
••
Today, Today, main main motivation motivation for for middleware middleware is is to to reduce reduce the the volume volume of of code code and and testing testing needed needed (i.e., (i.e., fewer fewer engineers engineers in in the the project project Î Î lowest lowest possible possible development development cost). cost).
••
Additional Additional libraries libraries (with (with advanced advanced functionality) functionality) are are added added to to the the system system on on aa needed needed basis. basis.
••
Middleware Middleware should should be be possible possible to to use use on on as as many many types types of of computers computers as as possible, possible, open for configurations of its functionality, and at deployment time and run-time open for configurations of its functionality, and at deployment time and run-time add add mechanisms mechanisms needed needed according according to: to:
••
••
Technical Technical domain domain (mobile, (mobile, grid, grid, embedded) embedded)
••
Application Application type type (transaction, (transaction, streaming, streaming, content, content, logistics, logistics, control) control)
Dynamic Dynamic middleware middleware have have aa possibility possibility for for self-configuration, self-configuration, which which will will avoid avoid high high cost cost even even when when systems systems spans spans across across more more computers. computers.
