Transparent Robustness in Service Aggregates

Onyeka Ezenwoye

School of Computing and Information Sciences

Florida International University

May 2006

2

Agenda

Outline

• Introduction• Service Oriented Architecture (SOA)• Methodology• Preliminary Study• Remaining Research

Agenda

Introduction

SOA

Methodology

Preliminary Study

Research

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

Service Oriented Architecture

Outline

• What is a service– Self-contained application component that is

remotely accessible.Agenda

Introduction

SOA

Methodology

Research

Serviceprovider

Servicebroker

Servicerequestor

Find

BindPublish

• Actors in SOA– Provider

– Broker

– Requestor

• Goal– Facilitate integration

– Reuse

Preliminary Study

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 Customer

Accounting

Service

Inventory

Service

Delivery

Service

Sales ServiceSales Service(a workflow)

Preliminary Study

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

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

Preliminary Study

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

Preliminary Study

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

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

Preliminary Study

Outline

• *A Loan Approval Process

Agenda

Introduction

SOA

Methodology

< $10.000

“high”

“low”

>= $10,000

*www.activebpel.org

Client

Client

Web Service

Web Service

Research

Preliminary Study

12

Preliminary Study

Outline

Agenda

Introduction

SOA

Methodology

• 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>Research

Preliminary Study

13

Preliminary StudyOutline

Agenda

Introduction

SOA

Methodology

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

Research

Preliminary Study

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

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

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

Preliminary Study

Outline

Agenda

Introduction

SOA

Methodology

• An unmonitored invocation

<invoke name="invokeApprover" partnerLink="approver" portType="loanApprovalPT“

operation="approve" inputVariable="request"

outputVariable="approvalInfo"></invoke>

Research

Preliminary Study

18

Preliminary StudyOutline

Agenda

Introduction

SOA

Methodology

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

Research

Preliminary Study

19

Preliminary Study

Outline

Agenda

Introduction

SOA

Methodology

• A better Loan Approval Process

Research

Preliminary Study

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

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 Document Process Data Flow

Legend

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 Document Process Data Flow

Legend

Broker binding and querying stub

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

Questions?