RobustBPEL2: Transparent Autonomization in Business Processes through Dynamic

Proxies

Onyeka EzenwoyeS. Masoud Sadjadi

Autonomic Computing Research Lab

Florida International University

ISADS 2007

Introduction

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)

Introduction

The Problem The existing marketplace is littered with proprietary

middleware/protocols (e.g. Java RMI, .NET, CORBA, etc) for service interaction.

These protocols do not openly support inter-organization service interactions over the internet.

Java RMIApp 1 App N…

Firewall

Firewall Firewall

Firewall

Enterprise A

Enterprise B

Enterprise C

Enterprise D

Internet.NET

App 1 App N…

CORBAApp 1 App N…

etc.App 1 App N…

Web services

What is a Web Service Web services are applications that

communicate through middleware (WSDL) over the internet.

Core Technologies XML (eXtensible Markup Language) SOAP (Simple Object Access Protocol) WSDL (Web Service Description Language)

Business Processes

Service Aggregation

Production

Service

Customer Customer

Accounting

Service

Inventory

Service

Delivery

Service

Sales ServiceSales Service(a workflow)

Business Process Execution Language (BPEL)

BPEL is workflow language for recursive 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.

*A Loan Approval Process

*www.activebpel.org

Web Service

Web Service

Client

Client

BPEL

Workflow Design Structure

Non-DAG Support for iterations, loops

Data Movement Centralized

Service

Service

Service

ServiceOrchestration

application

BPEL

Workflow Design Composition System

User-directed Language-based (xml-based) Graph-based

Fault tolerance Non Has fault and event handlers

BPEL Challenges

Not modular enough to support Separation of concerns Maintainability Evolution

BPEL is not dynamic No runtime workflow alteration for optimization or

fault-tolerance

BPEL Challenges

Minimal fault handling. Supports compensation handling.

Dynamism through middleware application, messaging.

Our Approach

Transparent Adaptation Allows introduction of new code (component) at

run-time does not tangle cross-cutting concerns with

original application (separates functional code from non-functional code)

preserves desirable original behavior is transparent to the original code (the original

code is unaware of the adaptation)

RobustBPEL

Why RobustBPEL BPEL is susceptible to failures of partner services BPEL provides no fault tolerance BPEL is not dynamic BPEL not modular enough for aspect programming Provide robustness in the event of failure of invoked

services. Allow for runtime introduction of components

RobustBPEL

RobustBPEL-1 (Static Proxies) [ICEIS-06]

RobustBPEL-2 (Dynamic Proxies) [ISADS-07]

RobustBPEL

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

Task level Retry Alternate resource

*A Loan Approval Process

*www.activebpel.org

Web Service

Web Service

Client

Client

A better Loan Approval Process

Web Service

Web Service

Monitor Web

Service

Monitor Web

Service

Generated Dynamic

Proxy

Generated Dynamic

Proxy

Generated Adapt-Ready

BPEL

Generated Adapt-Ready

BPEL

RobustBPEL-2 GeneratorRobustBPEL-2 Generator

File or Document Processor Data Flow

XMLConfiguration

File

XMLConfiguration

File

LocalDisk

Parser

Dynamic Proxy

Compiler

Adapt-Ready BPEL

Compiler

Template for Proxy Class

Template for Proxy Class

OriginalBPEL

OriginalBPEL

Binding stub for WSi

Binding stub for WSi

Binding stub for WSi

Binding stub for WSi

Legend:Legend:

Generator

The Proxy

Proxy is specific but dynamic Interface for proxy is specific One proxy from every adapted process Discovers and bind to alternate services

AggregateWeb Service

Client Program

1

2WS1

pt1

WSn

ptn

......

n partner Web services

Service port type (pt) Service dependency1Web service (WS) Sequence of events

Legend:Legend:

Architectural diagrams showing the sequence of interactions among the components in a typical aggregate Web service.

Adapt-ReadyAggregate

Web Service

1

2WS1

pt1

WSn

ptn

......

Static

Proxy

4WSi1

pti

WSip

pti

......

WSj1

ptj

WSjq

ptj

......

ptjpti

3

p equivalent Web services for WSi

q equivalent Web services for WSj

n partner Web services

Absence of Faults

Presence of Faults

generated to

handle the faults

by two selected

partner Web

services

(WSi and WSj)

Client Program

Service port type (pt)

Service dependency (static binding)

1Web service (WS) Sequence of events

Legend:Legend:

Service dependency (dynamic binding)

Sequence of interactions in RobustBPEL-1

1

2WS1

pt1

WSn

ptn

......

Dynamic

Proxy

4

UDDI

~WSi

ptj

~WSj

ptj

UDDI registryservices

Dynamically identified equivalent Web services for WSi and WSj

n partner Web services

5

ptjpti

3 Absence of Faults

Presence of Faults

Adapt-ReadyAggregate

Web Service

generated to

handle the faults

by two selected

partner Web

services

(WSi and WSj)

Client Program

Service port type (pt)

Service dependency (static binding)

1Web service (WS) Sequence of events

Legend:Legend:

Service dependency (dynamic binding)

Sequence of interactions in RobustBPEL-2

Questions?