Dynamic and Selective Combination of Extension in Component-based Applications Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten, Bo N. Jørgensen

Dynamic and Selective Combination of Extension in Component-based

Applications

Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten, Bo N. Jørgensen

Outline

Motivation: Dynamic customization of distributed services

Overview of wrapper-based model Lasagne

Problem statement: analysis of problems with wrappers

Detailed overview of Lasagne

Lessons learned

Conclusion

Motivation

Support for dynamic and client-specific customization of distributed services is needed

An example: web service on the Internet Multiple clients are accessing service instance simultaneously Different clients have different customization needs One client must be able to customize the web service for use

in its own context, without affecting other clients (service behavior delivered to

other clients must not be affected)

Motivation (ctd)

Customization process = context-sensitive and dynamic combination of extensions to a minimal core system Extensions can be functional (e.g. refined core service) and

non-functional (e.g authentication, authorization)

Revisiting example: web service on the Internet Each client must be able to select a subset of extensions into

the core service for use in its own context:

per client request, per client session without interfering with other clients

Short overview of Lasagne

A programming, deployment and run-time model that supports dynamic combination of extensions per client request

Inspired by wrapper-based design patterns Decorator and Role Object

Advantages of wrappers already support combination of extensions to a component operate at instance-level => customization of online services

Deal with disadvantages of wrappers object identity problems

Wrapper-based design patterns Decorator [Gamma et al]

Disjunctive chaining supports selective combination

Agenda

Decorator 1 Decorator 2

Decorator 2

Decorator 1

Wrapper-based design patterns

Role Object [Baumer et al] Component type widening

Dynamically adds new service interface selection of roles by means of specification object

Role 2

Component

getRole(specification)

Role 1

AtomicAgenda

AuthorizationCheckWrapper

Authorization&

Access Control

DatingSystem

GroupAppointment

Service

SimpleAgendacore system

extensionsAccessDenied

ExceptionHandler

Problem Statement

System-wide interaction refinement

Spaghetti ProblemAgenda

DatingSystem

Object Identity Problem

Atomic Agenda

Atomic Agenda

Group App. Service

AccessDenied Exception Handler

Group App. Service


Authoriz. Check Wrapper




Atomic Agenda

Atomic Agenda


DatingSystem

Group App. Service


Group App. Service




Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service






Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service


authorization & access control




Spaghetti Problem Agenda

Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service






Coordination Problem Agenda

DatingSystem

Atomic Agenda

Atomic Agenda

Group App. Service


Group App. Service





Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service


Inconsistency




Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service


Calling context must be propagated over entire

core system




Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service



core system




Atomic Agenda

Atomic Agenda

DatingSystem

Group App. Service


Group App. Service


Contextual change must be propagated over entire

core system



Other problems solved

Partial ordering constraints between wrappers

Some wrapper composition logic should not be under control of the clients

Use of design patterns must be anticipated by core application developer.

Technical problems Problems with delegation and common self State consistency between multiple instances of the same

wrapper definition

Turning Spaghetti into Lasagne

Externalize wrapper composition logic from the code of core system and extensions

Clients can customize the wrapper composition logic on a per collaboration basis

High-level overview of Lasagne

Introductory terms Component-based, distributed core system

Component type =< {services}, {dependencies}> Connection supported by COTS middleware

Client request initiates collaboration between core components

Lasagne customization process consists of three phases: extension programming, deployment of extensions to a core system, and selective combination per collaboration

Agenda 1 DatingSystem Agenda 2

dependency servicecollaboration

connection


The extension programming model An extensions is implemented as layer of wrappers Wrappers are programmed in hybrid form between

Decorator and Role Object Each wrapper definition is meant for decorating a specific

minimal component type

Group App. Service

Atomic Agenda

*

<{Dating}, {Negotiation}>

<{Negotiation}, {}>


Deployment of extensions to core application Declarative specification of how to integrate wrappers to a

specific core application specify fine-grained partial ordering constraints

AtomicAgenda

AuthorizationCheckWrapper

Authorization&

Access Control

DatingSystem

GroupAppointment

Service

dynamic extensiblecomponent

SimpleAgenda

AccessDeniedExceptionHandler

Orderingconstraints


Selective combination per client request

dynamic adjustment of message flow through

appropriate chain of wrappers

:Agenda

Group App. Service

Atomic Agenda



:DatingSystem

Lasagne Concepts

Component Identity Aggregates core instance and its wrappers into one identity Removes the spaghetti of wrapper references

Extension Identifier qualified name that uniquely identifies an extension Is used to designate wrappers as belonging to a specific

extension Composition Policy {…}

specifies the subset of extension identifiers for a specific collaboration between client and core system

A composition policy propagates with the collaboration flow

Lasagne concepts

Contextual properties e.g client-specific preferences, message flow history defined as <name, value> pairs that propagate with the

collaboration flow Interceptors

define contextual properties of collaboration select or unselect extensions. Typical selection rule:

If <condition> is satisfied within <context> then attach/discard <extension identifier> to composition policy

Variation point Extension to runtime component model Generic message dispatch mechanism

Dynamically constructs wrapper chain Interprets composition policy and ordering constraints

Component Identity



Extension Identifiers



<“authoriz”>

<“group”>

Interceptors and Composition Policy



<“authoriz”>

<“group”>

{ } {<“authoriz”>}

add <“authoriz”>

If client_localhost on remote subnet then attach <“authoriz”> to composition policy

{<“authoriz”>}

{<“authoriz”>}

Attach client_localhost, client_identity as contextual properties to collaboration.

Interceptor definitions

{ }

•Propagation of composition policy

•Propagation of contextual properties

•Variationpoint performs automatic adjustment of message flow

Underlying runtime mechanisms



<“authoriz”>

<“group”>

{ } {<“authoriz”>}

add <“authoriz”>

{<“authoriz”>}

{<“authoriz”>}

Lessons learned

Lasagne is suitable for customization at the coarse-grained architectural level

Extensions are reusable over multiple applications is supported in Java implementation of Lasagne

(co-work with Renaud Pawlak) Wrappers are reusable over different types of

components Deployment-time operation that dynamically

connects extension operation to core operation.

Lessons Learned (ctd)

Lasagne is too low-level and complex to use Need to build higher-level tool or language on top

of Lasagne framework feedback from advanced separation of concerns

community Aspect-oriented programming Aspectual Components GenVoca and Mixin layers Multidimensional separation of concerns

Conclusion Customization of distributed services

non-invasive customization dynamic combination of system-wide extensions

consistency and scalability context-sensitiveness

simultaneous client-specific views message flow history

Lasagne prototypes Programming Languages with an open implementation

Correlate, Java Reflective middleware platforms

Java RMI, Lasagne ORB

Other problems solved

Partial ordering constraints between wrappers

Multiple instances of the same wrapper definition due disjunctive wrapper chains difficult to keep the states of different wrapper instances

consistent to each other

No Delegation Self-call of core component is not redirected through

wrappers

Some wrapper composition logic should not be under control of the clients



Atomic Agenda

Atomic Agenda


DatingSystem

Group App. Service


Group App. Service



core system



Atomic Agenda

Atomic Agenda


DatingSystem

Group App. Service


Group App. Service



core system

Lasagne mechanisms Underlying run-time component model

i1

component identity

i0

VariationPoint

wrapper instances

inner.inspect() i3

i2

core instance

(inner i0..3).inspect()

composition policy && ordering constraints

Documents

Dynamic and Selective Combination of Extension in Component-based Applications Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten, Bo N. Jørgensen