A metadata-driven approach to context-sensitive composition of collaborations

1. 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

2. 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

3. 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

4. What’s a good component?

5. Context-sensitive composition of collaborations abstract collaboration collaboration “yellow” activate the yellow and the purple feature for my requests collaboration “orange” collaboration “purple”

6. 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

7. How can web services leverage these mechanisms web services objects No peer concept similar peer concept No peer concept object identity object life cycle URI’s composite objects object XML data interface WSDL XMI metadata type exception handling UDDI open standards method service Proprietary nature message

8. 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

9. 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]

10. core core core 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. add generic metadata {purple feature, yellow feature} to my request

11. Overview

12. 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

13. 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

14. 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

15. Revisiting desired properties • 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

16. Revisiting desired properties • Reusability (ctd.) • In collaboration-based design the hotspots are not objects, but the interactions between objects

17. 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

18. Context-sensitive composition of collaborations abstract collaboration collaboration “yellow” activate the yellow and the purple feature for my requests collaboration “orange” collaboration “purple”

19. Context-sensitive composition of collaborations Activate the orange feature for my requests abstract collaboration collaboration “yellow” collaboration “orange” collaboration “purple” System implementation Clients

20. 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

21. Context-sensitive composition of web-services • Collaboration-based design strategy • Does it make sense at this level? ??

22. 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

23. 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