Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Transparent Robustness in Service Aggregates Onyeka Ezenwoye School of Computing and Information Sciences Florida International University May 2006."— Presentation transcript:

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

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

3 3 Introduction 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) Agenda Introduction SOA Methodology Research Preliminary Study

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

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

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

7 7 Methodology 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) Agenda Introduction SOA Methodology Research Preliminary Study

8 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.) Agenda Introduction SOA Methodology Research Preliminary Study

9 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) Agenda Introduction SOA Methodology Research Preliminary Study

10 10 Preliminary Study 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. Agenda Introduction SOA Methodology Research Preliminary Study

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

12 12 Preliminary Study Outline Agenda Introduction SOA Methodology Partners in BPEL Research Preliminary Study

13 13 Preliminary Study Outline Agenda Introduction SOA Methodology Activities in BPEL … … … … … Research Preliminary Study

14 14 Preliminary Study Outline Agenda Introduction SOA Methodology 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. Research Preliminary Study

15 15 Preliminary Study Outline Agenda Introduction SOA Methodology 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 Research Preliminary Study

16 16 Preliminary Study Outline Agenda Introduction SOA Methodology 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. Research Preliminary Study

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

18 18 Preliminary Study Outline Agenda Introduction SOA Methodology <invoke name="invokeApprover“ … Research Preliminary Study

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

20 20 Preliminary Studies Outline Agenda Introduction SOA Methodology 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 Research Preliminary Study

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

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

23 23 Remaining Research Outline Agenda Introduction SOA Methodology Research Preliminary Study 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

24 24 Questions?


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

Similar presentations


Ads by Google