A metadata-driven approach to context-sensitive composition of

collaborationsEddy Truyen, Wouter Joosen

and Pierre VerbaetenBo N. Jørgensen

Maersk Institute of Production Technology

Southern University of Denmark

Background• Our work is about distributed system infrastructure

that supports context-sensitive customization of distributed services – Different client contexts have different requirements in

terms of ‘desired features’– Client-specific and dynamic composition of feature

implementations

• Approach– Extensive componentization of features

• System = composition of feature components

– Per-client-request composition • composition process takes into account needs of the runtime context

Two questions?

• What’s a good component?– Improved feature modularization capability

• How can web services leverage context-sensitive composition of such components?– Bridge the chasm between OOP and web services– Object-oriented programming model ‘pur sang’?

• Interface interaction and versioning complexity

What’s a good component?

collaboration

object

role

Context-sensitive composition of collaborations

collaboration “yellow”

collaboration “orange”

collaboration “purple”

activate the yellow and the

purple feature for my requests

abstract collaboration

Needed mechanisms from an OO-standpoint

– Delegation (aka object-based inheritance)• Context-sensitive late binding

– Family polymorphism [Ernst, ECOOP’ 2001]• Scales late binding from objects to groups of objects

– Delegation Layers [Ostermann, ECOOP’2002] • Combines delegation and family polymorphism

group of objects

collaboration variant 1

currently invoking client

self

collaboration variant 2

How can web services leverage these mechanisms

web services objects

object identity

interface

object

WSDL

XML data

URI’s

exception handling

object life cycle

open standards

Proprietary naturemessage

UDDI

methodservice

XMI metadata type

similar peer conceptNo peer concept No peer concept

composite objects

Our approach• Lasagne [Truyen, ICSE’2001]

– metadata-driven approach to context-sensitive composition

• Focus on support for distributed systems• Basic mechanisms

– Message interception– Messages carry metadata

distributed system

collaboration variant 1

Malicious client

self

collaboration variant 2

– Simulated OO-mechanisms• Family polymorphism

– consistent configuration of peer objects

• Delegation– Context-sensitive late binding– But protect against malicious

clients

Our approach• configuration metadata

– how collaborations must be composed with each other– is managed by a trusted configuration manager– In OOP terms: encapsulation of specialization interface

• Immaculate Client Interface Principe [Steyaert, ECOOP’95]

• generic metadata – client-specific selection of desired collaboration components– is dynamically included in the header of messages– in OOP terms: qualified message passing

• Point-Of-View Notion of Multiple Inheritance [Carre, OOPSLA’90]• Split Objects [Bardou, OOPSLA, ’96]

Our approach• distributed thread

• propagates generic metadata with the locus of execution

• In OOP terms: family polymorphism• for a given client request, the self parameters must be

consistently evaluated in harmony to the same set of collaborations.

core

add generic metadata

{purple feature, yellow feature}to my request

core

core

component framework developers

configuration manager

client

collaborations

generic metadata

domain-specific metadata

domain-specific metadata parser

configuration-metadata + +

software architecture

@

• Overview

Conclusion

• Collaboration-based design improves feature modularization and reuse capabilities

• Metadata-driven composition of features – Necessary mechanisms are already at place in

web service infrastructure• Message headers

• Message interception

DiscussionDoes collaboration-based design make sense

at the level of composing web services

Eddy Truyen, Wouter Joosen and Pierre Verbaeten

Bo N. Jørgensen

Maersk Institute of Production Technology

Southern University of Denmark

Revisiting desired properties

• Modularity– Customizability depends on the ability the separate all

concerns of importance => limited impact of change

– Feature modularization capability depends on the kind(s) of decomposition and composition a programming language or design methodology supports

• Requirement analysis decomposes a system by ‘feature’

• Object-oriented design and implementation decompose a system by ‘object’

– Aspect-oriented programming

• Reusability– Application-domain specific reuse

• Component reuse• Architectural reuse: component interactions

Component frameworks Conflict between reuse and customizabilityFrameworks do not allow interaction refinement

– These limitations can be overcome in collaboration-based design

Revisiting desired properties

• Reusability (ctd.)– In collaboration-based design the hotspots are

not objects, but the interactions between objects

collaboration

object

role

Revisiting desired properties

• Independent extensibility= a system can cope with the late addition of components

without requiring a global integrity checkNeed for contractual specification of common

abstractions. Two senses of a contract:• Component contract

• specifies the interfaces provided by a component and the interfaces needed by a component to provide these services

• Interaction contract• specifies a pattern of interaction among different roles and the

reciprocal obligations of components that fill these roles

Revisiting desired properties

Context-sensitive composition of collaborations

collaboration “yellow”

collaboration “orange”

collaboration “purple”

activate the yellow and the

purple feature for my requests

abstract collaboration

Context-sensitive composition of collaborations

abstract collaboration

collaboration “yellow”

collaboration “orange”

collaboration “purple”

Activate the orange feature

for my requests

System implementationClients

Context-sensitive composition of web services

• Basis characteristics of process model– Processes are described as a set of collaborations

between various participants, including organizations, applications, employees, and other business processes.

– The ability to recursively decompose process models is generally required.

– The workflow defines how the participants in a process work together to execute a process from start to finish, and is also called choreography or orchestration.

– Workflow descriptions can be generated from collaboration models, or specified independently

Context-sensitive composition of web-services

• Collaboration-based design strategy – Does it make sense at this level?

web service

collaboration of web services

??

Context-sensitive composition of web-services

• Cross-organizational collaborations:– The “there is one administrator” fallacy– gradual and fragmented change, where old and

new collaboration components can coexist

=>Need for independent extensibility– Interaction contracts

Conclusion

• Collaboration-based design improves feature modularization and reuse capabilities

• Does collaboration-based design makes sense at the level of composing web services?– If yes, the notion of independent extensibility is

crucial