MW4SOC, Middleware 2010 Middleware for Adaptive Service Orientation Nanjangud C Narendra IBM Research India, Bangalore [email protected] Umesh Bellur.

MW4SOC, Middleware 2010

Middleware for Adaptive Service Orientation

Nanjangud C NarendraIBM Research India, [email protected]

Umesh BellurDept of Computer Science and EngineeringIIT Bombay [email protected]

Umesh Bellur - MW4SOC 2010

Agenda

The Context – Pervasive Computing

Service Orientation and it’s use in Pervasive computing environments• Towards a formal foundation for services• The need for adaptation in SOC middleware

An Adaptive SOC Middleware Architecture• Functional and Architectural Adaptation in SOC middleware to

support pervasive computing • Context awareness for adaptation• Middleware for Facilitating Adaptation in SOC• Experimental Results

Future Work


Agenda





Future Work


Pervasive Computing

“The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life till they are indistinguishable from it”

Mark Weiser, Inventor of Pervasive Computing at Xerox PARC


What Characterizes PC?

Large number, diversity of computing nodes• Components not necessarily designed to work

together Heterogeneity at all levels – HW, OS, Language,

Semantics

Dynamic nature of the environment• Changing resources in a virtualized

environment• Changing set of services caused by mobility


Key Challenges in Pervasive Computing

Interoperability of Interacting Components• Protocol and interface compatibility issues

Security & trust in the presence of mobility

Computational continuation at space boundaries in the presence of a:

Changing resource map Changing services map


Impact on Middleware

Traditionally middleware consists of two components:1. A Container to provide services such as persistence, distributed

transaction management and security to objects in it.2. A communications bus that provides transparency of location and

hides hardware, OS and language heterogeneity (orpc++).

PC however now makes new demands on middleware:• Ability to dynamically map computation to underlying

hardware and OS resources.

• Ability to now dynamically bind to available software resources => Service discovery and (re)binding.


Summarizing shortcomings

Both of these capabilities call for the middleware to “react” to dynamism in the operating environment by “adapting” to triggers

This view of adaptation is shared by:• Grid Computing (with dynamic scheduling)• Autonomic computing


Agenda





Future Work


Service Orientation

Is an architectural style that seeks to achieve loose coupling amongst interacting software agents

Key elements (proposed) include:• Publication of service descriptions

Syntactic descriptions of functionality

• Dynamic discovery of these capabilities (not quite there yet)

• Dynamic binding of users to service providers• The “Publish-Find-Bind” triangle


Why Service Orientation for Adaptive Computing?

Service discovery for dynamic optimization.

Composition and dynamic service binding for adapting to changing software resources in a dynamic environment.

Clean separation between the abstract description of capability (functional & QoS) and it’s concrete avatars


The evolution of Service Orientation

Dynamiccontent

Staticcontent

InteroperableSyntax

InteroperableSemantics

Web Services

WWW Semantic Web

Semantic WebServices

Global Ontology andFederated Web Services Registry for Discovery

NOW Future

Future


From SOC Middleware to PC Middleware

Today’s middleware for SOC (primarily for web services) provides the infrastructure for:• Standards compliance for interoperability purposes.• Service publication into a registry• A weak form of Discovery via UDDI• Asynchronous service invocation via callbacks – programming

model

But to work as the middleware for pervasive computing it needs to be augmented with:• Semantic descriptions and true Discovery• Service continuation in the presence of mobility• Dynamic service provisioning in the presence of varying

resources.• A programming model that allows one to direct adaptation.


Agenda



An Adaptive SOC Middleware Architecture• A programming model to direct adaptation• Context awareness for adaptation• Middleware architecture for facilitating adaptation in SOC• Experimental Results

Future Work


Adaptation in SOC - Requirements

A programming model that allows one to express reaction to possible triggers:

A middleware runtime that:• Is Reflective – current computational state, available

resources• Support dynamic reconfigurability of applications running on

it.• Apart from the usual requirements of asynchronous service

invocation.


Implications of these Requirements

Semantics as well as QoS driven context needs to be added to the description, publication, discovery and binding of services.

Granular breakup of the execution of a service• With a view toward allowing the middleware to gain control

of the computation at specified points• A new programming model needed for this

For composite services - dependence on context to be carried with the service along it’s execution path.


What is a service?

A service is an abstract semantic description of a computational capability along with a context specifying non-functional attributes that is published and can be instantiated dynamically• Service Description using the IOPE* form along with a provider

context • Service Request also using IOPE formats along with consumer

context• Service Matching using both the functional description and

context.• Service Provisioning based on negotiated match and the merged

context

Two aspects to concretizing this:• Functional: realized by using other services or computational

entities (aka components) at the lowest level.• Quality: realized by matching physical resources to the

components to deliver the quality demanded.

* Input, Output, Precondition and Effect


Realizing a Service – Conceptual Model

Service realization is a workflow of tasks for granularity of control• Tasks are described using the

<I,O,P,E,B> tuple where B describes the binding to a service or component.

• A NULL binding indicates a service variability point.

The middleware needs to find a binding at runtime

• Shows a set of dependencies on other services or components

Service composition can be done by interface automata that looks for safety of merging IOPE descriptions


Non-functional Requirements

Provider Side Consumer Side

Environment Infrastructure needed for the component to execute.For example: a J2EE component needs a JVM and a J2EE container to execute – it may further mention a specific RDBMS which it can work with etc.

Device and connectivity information of theConsumer component, Language environment of the consumer etc. For example: PDA with limited bandwidth and display capabilities.

Service QoS range that is supported by the provider component. Performance, availability and other guarantees provided by The component under appropriate resource allocation. This could even be additional information regarding behavioral guarantees such as type of algorithm used or the communication protocols supported in implementing the service.

QoS information that is needed by theConsumer component. In addition theconsumer can request for specific types ofService such as the algorithm it wishes the provider to use for providing the service.

Resource Resources needed by the provider to supply the QoS range it supports. This can include threads, CPU speeds, memory, DB connections etc.


Adaptation

Two types of adaptation:• Variability specification driven• Context change driven

Essentially an externalization of dependencies so that they can be rewired dynamically at “use time”.


Variability Driven

A variability point (VP) is a task specification without a preset binding.

Variability specification is a constraint on the service that can be bound to that task. Apart from IOPE, it specifies services to be excluded and any additional constraints (TBD)

A VP causes a trap to the adaptation handler that will find a suitable service, bind it and issue an invocation. • As opposed to a static binding which is known apriori.


Functional Building blocks of Variability Driven Adaptation

Component Repository

Component Discovery

& Publishing

TaskDispatcher

Component selection

ServiceCall

VariabilityTrap Handler

Service ProcessFlow Controller

(WorkflowInstantiation &

Control)

Variability Trap

Executing Component

Service Call for task

Component call for task

Service Repository

Service Discovery

Adaptation RT

SOC Run TimeCall ServiceWith Binding

Discover Binding for IOPE

ResourceAllocation

Engine


Sequence Diagram of Variability

ART Trap handler SOC RT Serv.

Cache

Disc.Engine

Serv.Repository

Discover Variability Spec (IOPE)

Search IOPE

Service bindingsSelected Binding for IOPE (Eg: foo)

VariabilityTrap

ServiceProcess flowController

Done

Invoke Service (foo) with Binding

Service Result

F00

Invoke foo

Foo callback


Context for Adaptation

Each service (provider) also exports a set of dynamic context that can serve as the basis for adaptation:• Eg.: Current response times for service, service activation and

deactivation (default) etc. • The type of value being provided is advertised.• Each service supports a subscription interface for contextual

information.

A service invoker can listen on these contexts and change it’s binding upon any change.

Other context sources include: client side environment information such as network bandwidth, processing capability etc.


Context driven Adaptation Technique

1. Context sources advertise subscription interfaces.

2. Each subscription is associated with a filter to eliminate unwanted changes

3. Context consumers receive notifications upon context change that behave as interrupts.

4. Context consumers specify policies (actions) for each interrupt type. Two possible policies which can be combined appropriately:1. Replace an existing service binding with an equivalent one.2. Cancel in-progress service invocations, rebind and reissue

invocation


AdaptationPolicies Repo

Application Code(call services)

Adaptation RT

SOC RuntimeDiscover and bind to servicesService Calls, Handle callbacks

Service Discovery Engine(Semantic Matchmaking, Composition)

ServicesCache

Observer

Trigger Handler

Context NotificationHandler

PolicyEngine

ContextSource

Service DescriptionRepository

(Context Source)

Functional Building Blocks of Context Driven Adaptation


Adaptation Triggers

1. A new service entering the operating environment in which the runtime is executing

2. An existing service leaving (perhaps by shutting down or due to mobility) the operating environment

3. A trigger related to some contextual change other than the above two triggers


Sequence Diagram of Service Call

App Code SOC RT Serv. Cache

Disc.Engine

Serv.Repository

Call fooGet Binding

Update Cache

F00

Invoke foo

Foo callback

Foo result

Cache miss Search(foo)

Foo BindingsFoo binding

Disc foo

Foo Binding


Sequence Diagram of Triggers Leading to Rebinding

ARTTrigger Handler + Policy

Engine SOC RT Serv. Cache

Disc.Engine

Serv.Repository

Policy Repository

Trigger (foo)

Get Policy

policy

Rebind (foo)

Disc fooSearch foo

Foo bindingsSelected Binding for foo

Modify cache for foo

DoneDone


Current Status

Middleware: Detailed design and implementation of:• Context source interfaces• Subscription filtering• Notifications• Policy specifications and execution.

Semantic SOA• Semantic IOPE specifications of services• Semantic Matchmaking• Automated composition based on IOPE.


Notification Overhead


Policy Execution Overhead


Conclusions & Future Work

Service orientation is a good basis for pervasive computing middleware

However, it needs precision in definitions and needs to be augmented with adaptive capabilities

Two main categories of adaptation – functional and architectural

Needs a new programming model Current Status – prototype middleware developed

and tested on a case study Future work – incorporate workflow adaptation

(incorporating task re-planning mid-stream) and conduct experiments on larger case studies


THANK [email protected]


BACKUP SLIDES



QoS and Resource Management - Meta scheduler

Seamless execution of long running computations across variability points • Discovery • Monitor resources • Match making engine

Discovery unit Monitor

Service aggregationBased on new variability point.

Broker

QoS calculator

Match making engine


Components of the meta schedular

Monitor • Monitoring the availability of resources

Broker• Translating QoS objectives into appropriate resources

QoS Calculator • Recalculates the QoS at points of reconfiguration.

Discovery • Maintains the list of services or resources.

Service Aggregation Unit • Aggregates services based on available resources.


Execution of Workflow

Based on these inputs dynamic service lookup and binding is done After a services is identified the task can be executed


Workflow for functional adaptation

resources are not available, functional adaptation has to be carried out


Prototype Details

Policy – currently Java classes used for policy specification due to greater flexibility (XML can also be used since it is declarative)

Policy Engine – inspects policies for context types & registers for notifications with appropriate context providers

Notification Dispatcher – new one created for every notification request; registers to monitor context changes & generates notifications every time the condition is satisfied

Service Discovery Agent – relies on IOPE-based matchmaking for discovering appropriate services


Performance Evaluation

Experiments carried out on an Intel®CoreTM2 Duo Processor T5500 (1.66 GHz), 2 GB RAM, running Fedora Core 9 Linux

Average service rebinding time from cache = 31 ms

Average service rebinding time with discovery = 123 ms

MW4SOC, Middleware 2010 Middleware for Adaptive Service Orientation Nanjangud C Narendra IBM Research India, Bangalore [email protected] Umesh Bellur.

Documents