Variability Oriented Programming – A programming abstraction for adaptive service orientation Prof. Umesh Bellur Dept. of Computer Science & Engg, IIT Bombay, Narendra Nanjungud, IBM Research, India

Dagstuhl, May 2009 Umesh Bellur The story so far…. Most adaptive systems have been considered from the perspective of adding self* properties transparently to an existing system.  No efforts to have the developer direct and control adaptation. Enterprise systems are suffering from:  Lack of adaptability  Lack of agility (the ability to sustain a rate of change)  Costs of construction, production and maintenance.

Dagstuhl, May 2009 Umesh Bellur Analysis The lack of agility stems from:  Tight coupling and the static hardwired nature of the distributed object paradigm.  Integration leading to compile time reuse. High costs result from:  Integration instead of runtime composition  Having to host everything

Dagstuhl, May 2009 Umesh Bellur Elements of the solution A development paradigm based on:  Loose coupling  Dynamic discovery and invocation  Run time composition  Software as a utility or a service With the appropriate runtime time support. In other words, an architecture for adaptable computing.

Dagstuhl, May 2009 Umesh Bellur Genesis - SOA Key SOA principles:  Loose coupling  Dynamic discovery  Workflow like composition  Software as a Service However, this is only an architectural style – there are NO infrastructure implementations that truly deliver any of these except SaaS.

Dagstuhl, May 2009 Umesh Bellur Elements of Adaptability in SOA Variability points - where should we look to adapt? Adaptability triggers – when should we look to adapt? Variability policy – how should we look to adapt? What other support do we need?

Dagstuhl, May 2009 Umesh Bellur Where in an SOA environment? At service call out points – functional or QoS adaptation. At service provisioning points – resource adaptation. Perhaps adaptive workflows that go to make up complex services as well? Others???

Dagstuhl, May 2009 Umesh Bellur Conceptual Model of a Service Each service consists of:  Service description  Task descriptions  Execution sequence of tasks  Variability Points Each task consists of :  Data Types  Operational Signature  Preconditions  Effects Service Task Resource Component 1 > N

Dagstuhl, May 2009 Umesh Bellur Triggers of Change Resource availability or unavailability  Hard resources  Soft resources or services Should we differentiate between a hard resource such as a CPU and a soft resource such as a software service? How does one capture these triggers? Is just standardization the answer?  Context specification and observer patterns are usually the solution in pervasive environments.

Dagstuhl, May 2009 Umesh Bellur Variability Policy ECA type action rules How complex should we allow this to get? How does a programmer constrain this?  For example: restricting the domain of a service discovery? What if there are policy conflicts – perhaps leading to deadlocks.

Dagstuhl, May 2009 Umesh Bellur Other support Context descriptions to capture availability of resources. Software engineering methodologies for adaptable programming???  Variability Oriented Software Engineering  Program conformance with variability descriptions – a calculus of variations??

Dagstuhl, May 2009 Umesh Bellur One possible structuring of Context TaskServiceComponent E-ContextRestrictions on resource- based characteristics of the resource this task is to be bound to - such as no images in reply, etc. E-Context in case of service includes execution environment (i.e. both software/hardware) as well as physical properties gathered as via context like location of service Technology environment needed for the component to execute, e.g., J2EE container S-ContextQoS requirement of the task, e.g., response time and cost QoS capability ranges and associated costs for invoking service QoS capability ranges R-ContextN/A Resources needed to supply a given QoS; typically expressed as compute units, memory etc.

Dagstuhl, May 2009 Umesh Bellur Infrastructure Compiler support  To describe variability at variability points  To check semantic correctness and applicability of these solutions Run time (Middleware)  Semantic discovery  Context awareness and resource discovery.  ECA type policy execution.

Dagstuhl, May 2009 Umesh Bellur Prototype Implementation Adaptive Runtime  Component in the Resource Allocation Engine that provides the basic runtime environment and deployment support for applications (both client and services). Responsible for maintaining bindings with context providers and enforcing restrictions/preconditions. Policy  Defines the policy specifying behavioral adaptation on context changes Policy Engine  Responsible for inspecting client and server policies for context types and registering for notifications with appropriate context providers Notification Handler  Created for every notification request. Registers to monitor context changes and generate notifications every time the condition is satisfied Service Discovery Agent  Implements context matching and evaluation. Context matching carried out via bipartite graph matching algorithm. Context evaluation and ranking is done by collecting contextual information from respective context providers and executing evaluation and ranking functions provided by the client in the query.