A metadata-driven approach to context-sensitive composition of collaborations Eddy Truyen, Wouter Joosen and Pierre Verbaeten Bo 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?

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

How can web services leverage these mechanisms web servicesobjects object identity interface object WSDL XML data URI’s exception handling object life cycle open standards Proprietary nature message UDDI method service XMI metadatatype similar peer conceptNo 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 –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

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

Discussion Does 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 customizability  Frameworks 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 Revisiting desired properties

Independent extensibility = a system can cope with the late addition of components without requiring a global integrity check  Need 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 implementation Clients

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? ??

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