ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING TRANSPARENT SHAPING TECHNIQUES Onyeka Ezenwoye Autonomic Computing Research Laboratory School of Computing and Information Sciences Florida International University

2 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Motivation Background Our Approach Solutions Related Work Future Work Conclusion

3 The Trend  Organizations need to integrate applications and data with other divisions, customers, partners, etc.  Service aggregation Overview: Motivation Production Service Customer Accounting Service Inventory Service Delivery Service Sales Service (a workflow) Background Our Approach Related Work Future Work Conclusion Solutions

4 The Trend (2)  High-level composition languages and tools. Overview: Motivation Graphical Modeling Environment Language Grammar Background Execution Engine Our Approach Related Work Future Work Conclusion Solutions

5 The Trend (3)  Grid: share resources for the purpose of coordinated problem solving. Overview: Motivation Interaction between components institutional boundary applicationresource Background Our Approach Related Work Future Work Conclusion Solutions

6 The Problem Overview: Motivation Domain expert does not need to know about: Service oriented architecture Web services Fault-tolerance Adaptability Background Our Approach Related Work Future Work Conclusion Solutions

7 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Background Motivation Our Approach Related Work Future Work Conclusion Solutions

8 Web services Overview: Motivation Background  A Web service is an application that is accessible over the internet. Java RMI App 1App N … Enterprise A Enterprise B Enterprise C Enterprise D Internet.NET App 1App N … etc. App 1App N … Core Technologies: WSDL (Web Service Description Language) SOAP UDDI (Universal Description Discovery and Integration) Our Approach Related Work Future Work Conclusion Solutions CORBA App 1App N …

9 Web services (2) Overview: Motivation Background Subscribe Publish (WSDL) SOAP Service Consumer Client Service Provider Service UDDI Registry WSDL Legend request flow reply flow program boundary module boundary SOAP Service Description WSDL Our Approach Related Work Future Work Conclusion Solutions

10 Composition Language  Business Process Execution Language (BPEL) –BPEL is workflow language for composing aggregate Web service –A BPEL process is defined in terms of its interactions with partners. Overview: Motivation Background Our Approach Related Work Future Work Conclusion Solutions BPELComposition UDDIDiscovery WSDLDescription SOAPMessage XMLEncoding Production Service Customer Accounting Service Inventory Service Delivery Service Sales Service (BPEL Process)

11 BPEL Overview: Motivation Background Service BPEL Process Service InterfaceMessage flow  Workflow Design –Graph Structure  Support for iterations, loops  Data Movement –Centralized. Our Approach Related Work Future Work Conclusion Solutions

12 BPEL Overview: Motivation Background Service BPEL Process Service InterfaceMessage flow  Workflow Design –Graph Structure  Support for iterations, loops  Data Movement –Centralized. Our Approach Related Work Future Work Conclusion Solutions

13 BPEL Overview: Motivation Background Service BPEL Process Service InterfaceMessage flow  Workflow Design –Graph Structure  Support for iterations, loops  Data Movement –Centralized. Our Approach Related Work Future Work Conclusion Solutions

14 BPEL Challenges  Fault tolerance –Limited –Has fault and event handlers –Supports compensation handling  Not modular to support –Separation of concerns –Maintainability –Evolution  BPEL is not dynamic –No runtime workflow alteration for optimization or fault-tolerance Overview: Motivation Background Our Approach Related Work Future Work Conclusion Solutions

15 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Motivation Our Approach Background Related Work Future Work Conclusion Solutions

16 Our Approach  Transparent Adaptation –allows introduction of new code (component) at run- time –does not tangle code for adaptive behavior with original application (separates functional code from non-functional code) –preserves desirable original behavior –adaptation is transparent to the original code (the original code is unaware of the adaptation) Overview: Motivation Background Our Approach Related Work Future Work Conclusion Solutions

17 Our Approach (2)  Encapsulate BPEL activities with generic hooks.  Hooks will point to “proxy” Web Service.  Fault tolerance and adaptation will be provided through Proxy service  Fault tolerance  Retry  Alternate resource Overview: Motivation Background Our Approach Related Work Future Work Conclusion Solutions

18 Our Approach (3) Overview: Motivation Service BPEL Process Service InterfaceMessage flow Related Work Future Work Conclusion Solutions Background Our Approach

19 Our Approach (3) Overview: Motivation Service BPEL Process Service InterfaceMessage flow Related Work Future Work Conclusion Solutions Background Our Approach Proxy Service

20 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Motivation Background Solutions Related Work Our Approach Future Work Conclusion

21 Solutions  RobustBPEL (Static Proxies) [11]  RobustBPEL-2 (Dynamic Proxies) [10]  TRAP/BPEL (Generic Proxies) [9] Overview: Motivation Related Work Background Our Approach Future Work Conclusion Solutions

22 Original Application Overview: Motivation Related Work Background Our Approach Future Work Conclusion Solutions Production Service Customer Accounting Service Inventory Service Delivery Service Sales Service (BPEL Process)

23 Static Proxies Overview: Motivation Related Work Background Our Approach Adapt-Ready Aggregate Web Service WS 1 pt 1 WS n pt n n partner Web services Absence of Faults Presence of Faults Client Program Legend: Service port type (pt)Service dependency Web service (WS) Future Work Conclusion Solutions

24 Adapt-Ready Aggregate Web Service WS 1 pt 1 WS n pt n pt j Static Proxy WS i1 pt i WS ip pt i WS j1 WS jq pt i p equivalent Web services for WSi q equivalent Web services for WSj n partner Web services Absence of Faults Presence of Faults Client Program Legend: Service port type (pt)Service dependency Web service (WS) Static Proxies Overview: Motivation Related Work Background Our Approach Future Work Conclusion Solutions

25 Dynamic Proxies Overview: Motivation Related Work Background Our Approach pt j Adapt-Ready Aggregate Web Service WS 1 pt 1 WS n pt n Dynamic Proxy pt i registry service n partner Web services Absence of Faults Presence of Faults Client Program Legend: Service port type (pt)Service dependency Web service (WS) Future Work Conclusion Solutions

26 Dynamic Proxies Overview: Motivation Related Work Background Our Approach pt j Adapt-Ready Aggregate Web Service WS 1 pt 1 WS n pt n Dynamic Proxy pt i registry service n partner Web services Absence of Faults Presence of Faults Client Program Legend: Service port type (pt)Service dependency Web service (WS) Future Work Conclusion Solutions

27 Generic Proxies  Why –One proxy for multiple composite services  Promote reuse –Improved adaptive behavior  Avoid failed components  Failure must not occur first –User-specified failure handling  Choice  Retry  Replicate  Alternative  Check-pointing –Dynamic Policy modification Overview: Motivation Related Work Background Our Approach Future Work Conclusion Solutions

28 Generic Proxies (2) Overview: Motivation Related Work Background Our Approach Service discovery Client Program pt g Adapt-Ready Aggregate Web Service 1 Adapt-Ready Aggregate Web Service K … Generic Proxy Developed once to provide autonomic behavior. Recovery Policy Future Work Conclusion Solutions Replicate Retry Alternative resource

29 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Motivation Related Work Future Work Conclusion Background Our Approach Solutions

30 Related Work  Dynamism and Fault-Tolerance in Web service composition –Messaging layer adaptation  Policy-driven  Require purpose built engine  AdaptiveBPEL [4], wsBus [6], Charfi [7] –Application Layer  BPEL manually annotated with comments/code  Require purpose built engine  Baresi [5], BPELJ [8]  Adaptability in scientific Grid Workflow systems –user-defined failure handling –Karajan [1], Kepler [2]  No separation of concerns –Grid-WFS [3]  Workflow annotated with failure handling strategy Overview: Motivation Background Our Approach Related Work Future Work Conclusion Solutions

31 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Related Work Future Work Conclusion Motivation Background Our Approach Solutions

32 Future Work  Grid Computing –Extending Recovery Policy –Very High-level composition tools for scientific grid applications  Software Adaptation –Languages –Applications Overview: Future Work Conclusion Related Work Motivation Background Our Approach Solutions

33 Agenda  Motivation  Background  Our Approach  Solutions  Related Work  Future Work  Conclusion Overview: Future Work Conclusion Related Work Motivation Background Our Approach Solutions

34 Conclusion  Acknowledgements –FIU  Dr. Masoud Sadjadi (Advisor)  Eduardo Monteiro –IBM Research Overview: Conclusion Future Work Related Work Motivation Background Our Approach Solutions

35 Conclusion  Questions? Overview: Conclusion Future Work Related Work Motivation Background Our Approach Solutions

36 References 1. G. von Laszewski et. al, Java CoG Kit Karajan/GridAnt Workflow Guide, Technical Report, Argonne National Laboratory, B. Ludäscher et. al, Scientific Workflow Management and the KEPLER System, Concurrency and Computation: Practice & Experience, Special Issue on Scientific Workflows, S. Hwang and C. Kesselman, GridWorkflow: A Flexible Failure Handling Framework for the Grid, Proc. 12th IEEE International Symposium on High Performance Distributed Computing, Erradi et. al. Towards a policy driven framework for adaptive web services composition. In Proceedings of International Conference on Next Generation Web Services Practices, Baresi et. al. Smart monitors for composed services. In ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, Erradi et. al. wsBus: QoS-aware middleware for relaible web services interaction. In IEEE International Conference on e-Technology, e-Commerce and e-Service, Charfi et. al. An aspect based process container for BPEL. In Proceedings of the 1st Workshop on Aspect-Oriented Middleware Development Blow et. al, Bpelj: BPEL for Java. White Paper. 9. Onyeka Ezenwoye and S. Masoud Sadjadi. TRAP/BPEL: A framework for dynamic adaptation of composite services. (WEBIST 2007) 10. Onyeka Ezenwoye and S. Masoud Sadjadi. RobustBPEL2: Transparent autonomization in business processes through dynamic proxies. (ISADS 2007) 11. Onyeka Ezenwoye and S. Masoud Sadjadi. Enabling robustness in existing BPEL processes. (ICEIS 2006)Overview: Conclusion Future Work Related Work Motivation Background Our Approach Solutions