Transparent Robustness in Service Aggregates

1. Transparent Robustness in Service Aggregates Onyeka Ezenwoye School of Computing and Information Sciences Florida International University May 2006

2. Outline Introduction Service Oriented Architecture (SOA) Methodology Preliminary Study Remaining Research Agenda Agenda Introduction SOA Methodology Preliminary Study Research

3. Outline The trend Organizations need to integrate applications and data with other divisions, customers, partners, etc. This is commonly known as Enterprise Application Integration (EAI) or Business Process Integration (BPI) Need to integrate leads to Service Oriented Architectures (SOA) Introduction Agenda Introduction SOA Methodology Preliminary Study Research

4. Outline What is a service Self-contained application component that is remotely accessible. Service provider Bind Publish Service requestor Service broker Find Service Oriented Architecture Agenda Introduction • Actors in SOA • Provider • Broker • Requestor • Goal • Facilitate integration • Reuse SOA Methodology Preliminary Study Research

5. Outline Uses application integration component reuse encapsulation of business functions as services aggregation of services (business processes) Customer Customer Sales Service (a workflow) Accounting Service Production Service Inventory Service Delivery Service Service Oriented Architecture Agenda Introduction SOA Methodology Preliminary Study Research

6. Outline The problem Services are geographically dispersed Services can be autonomous Communicate via the internet unreliable unboundeddelays The Challenge How to improve the fault tolerance and reliability of existing service aggregates. Service Oriented Architecture Agenda Introduction SOA Methodology Preliminary Study Research

7. Outline Transparent Adaptation introduce new code (component) at run-time Does not tangle cross-cutting concerns with original application (Separate functional and non-functional requirements) preserve desirable original behavior Original application is unaware of adaptation (transparent) Methodology Agenda Introduction SOA Methodology Preliminary Study Research

8. Outline Web Services Applications whose interfaces are described using Web Services Description Language (WSDL) Core technologies XML (Extensible Martkup Language) SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language) WSDL An XML language used to describe and locate Web services. Describe functionality of a web service Specify how to access the service (binding protocol, message format, and etc.) Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

9. Outline Benefits of Web Services More lightweight that distributed object systems Easier to communicate between applications (loosely coupled) Rapid development (use internet HTTP protocol) Facilitates reuse of existing services (business to business) Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

10. Outline Business Process Execution Language (BPEL) BPEL is workflow language for composing aggregate Web service XML based A BPEL process is defined in terms of its interactions with partners. A partner may provide service to the process, require service from the process or both. Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

11. Outline *A Loan Approval Process < $10.000 >= $10,000 “high” “low” Preliminary Study Client Agenda Introduction Web Service SOA Web Service Methodology Preliminary Study Research Client *www.activebpel.org

12. Outline Partners in BPEL <partnerLinks> <partnerLink myRole="approver" name="customer" partnerLinkType="lns:loanApprovalLinkType"/> <partnerLink name="approver" partnerLinkType="lns:loanApprovalLinkType" partnerRole="approver"/> <partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLinkType" partnerRole="assessor"/> </partnerLinks> Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

13. Outline Activities in BPEL <process> … <flow> <receive name="receive" partnerLink="customer" …> … </receive> <invoke name="invokeapprover" partnerLink ="approver“ …> … </invoke> <invoke name="invokeAssessor" partnerLink="assessor" …> … </invoke> <reply name="reply" partnerLink="customer" …> … </reply> </flow> </process> Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

14. Outline Why BPEL Widely used Susceptible to failures of partner services BPEL provides limited fault tolerance Fault handlers and Event handlers (timeouts) We need ways to Provide robustness in the event of failure of invoked services. Improve reliability. Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

15. Outline Current Approaches to making BPEL robust BPELJ Extend BPEL with Java Requires extending BPEL engine (limits portability) Baresi Manual annotation with non BPEL code Cumbersome and error prone Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

16. Outline Our Approach Encapsulate BPEL activities with generic hooks. Hooks will point to “proxy” Web Service. Proxy Web service will upon failure of monitored service, statically (or dynamically) find and bind equivalent services Equivalent services may have the same portType (interface) as the failed service. The proxy introduces new services (behavior) transparently. Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

17. Outline An unmonitored invocation <invoke name="invokeApprover" partnerLink="approver" portType="loanApprovalPT“ operation="approve" inputVariable="request" outputVariable="approvalInfo"></invoke> Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

18. Outline <scope><faultHandlers> <catchAll> <invoke name="InvokeProxy" partnerLink="proxy" portType="proxyPT" operation="approve" inputVariable="request" outputVariable="approvalInfo"/> </catchAll></faultHandlers><eventHandlers> <onAlarm for="'PT15S'"> <throw faultName="bpws:forcedTermination"/> </onAlarm> </eventHandlers><invoke name="invokeApprover“ … </invoke> </scope> Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

19. Outline A better Loan Approval Process Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

20. Outline Defining the Proxy Can be generic or specific Specific proxy interface for is same as monitored service Aggregate interface for multiple monitored service Generic proxy has a fixed (generic) interface for all monitored services Proxies can use static or dynamic discovery Preliminary Studies Agenda Introduction SOA Methodology Preliminary Study Research

21. Outline Generating the adaptive BPEL and static proxy Generated Robust BPEL Original BPEL Static Proxy Generator Template for Proxy class WSDL for substitute Web services Generated Static Proxy Legend File or Document Process Data Flow Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

22. Outline Generating the adaptive BPEL and dynamic proxy Generated Robust BPEL Original BPEL Template for Proxy class Dynamic Proxy Generator Generic binding stub for substitute Web services Generated Dynamic Proxy Broker binding and querying stub Legend File or Document Process Data Flow Preliminary Study Agenda Introduction SOA Methodology Preliminary Study Research

23. Outline Aggregate Service How to deal with stateful services E.g., Rollback (undo application logic) Delegate all fault handling to proxy BPEL catchAll problem Proxy Use dynamic discovery. Harmonize interface differences in service equivalents. Improve discovery Prevent client failure (incompatible data types) Techniques to clearly identify equivalents Classification schemes in broker Remaining Research Agenda Introduction SOA Methodology Preliminary Study Research

24. Questions?