ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING TRANSPARENT SHAPING TECHNIQUES Onyeka Ezenwoye...

ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING TRANSPARENT SHAPING TECHNIQUESTRANSPARENT SHAPING TECHNIQUES

Onyeka Ezenwoye

Autonomic Computing Research Laboratory

School of Computing and Information Sciences

Florida International University

http://www.cs.fiu.edu/~oezen001

2

AgendaAgenda

Motivation Background Our Approach Solutions Related Work Future Work Conclusion

OvervieOverview:w:Motivation

Background

Our Approach

Solutions

Related Work

Future Work

Conclusion

3

The TrendThe Trend

Organizations need to integrate applications and data with other divisions, customers, partners, etc.

Service aggregation


Production

Service

Customer Customer

Accounting

Service

Inventory

Service

Delivery

Service

Sales ServiceSales Service(a workflow)

Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

4

The Trend The Trend (2)(2)

High-level composition languages and tools.


Graphical Modeling Environment

<process name="google-amazon" > <variables> <variable name="requestMessage"/> </variables> <assign name="AssignVariables"> <copy> <from part="author"/> <to part="phrase"/> </copy> </assign> <receive operation="input"/> <invoke inputVariable="ItemMsg"> <target linkName="Link66"/> <source linkName="Link61"/> </invoke> <reply operation="input"> <target linkName="Link61"/> </reply></process>

Language GrammarBackground

Execution Engine

Our Approach

Related Work

Future Work

Conclusion

Solutions

5

The Trend The Trend (3)(3)

Grid: share resources for the purpose of coordinated problem solving.


Interaction between components

institutional boundary

application resource

Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

6

The ProblemThe Problem


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

AgendaAgenda


OvervieOverview:w:

Background

Motivation

Our Approach

Related Work

Future Work

Conclusion

Solutions

8

Web servicesWeb services


Background

A Web service is an application that is accessible over the internet.

Java RMIApp 1 App N…

Enterprise A

Enterprise B

Enterprise C

Enterprise D

Internet

.NETApp 1 App N…

etc.App 1 App N…

Core Technologies:•WSDL (Web Service Description Language)•SOAP•UDDI (Universal Description Discovery and Integration)

Our Approach

Related Work

Future Work

Conclusion

Solutions

CORBAApp 1 App N…

9

Web services Web services (2)(2)


Background

Subscribe Publish (WSDL)

SOAP

Service Consumer

Client

Service Provider

Service

UDDI Registry

WSDL

Legendrequest flow

reply flow

program boundary

module boundary

SOAP

Service Description

WSDL

Our Approach

Related Work

Future Work

Conclusion

Solutions

10

Composition LanguageComposition 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.


Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

BPEL Composition

UDDI Discovery

WSDL Description

SOAP Message

XML Encoding

Production

Service

Customer

Accounting

Service

Inventory

Service

Delivery

Service

Sales ServiceSales Service(BPEL Process)

11

BPELBPEL


Background

Service

Service

Service

ServiceBPEL

Process

Service Interface Message flow

Workflow Design– Graph Structure

Support for iterations, loops

Data Movement– Centralized.

Our Approach

Related Work

Future Work

Conclusion

Solutions

12

BPELBPEL


Background

Service

Service

Service

ServiceBPEL

Process





Our Approach

Related Work

Future Work

Conclusion

Solutions

13

BPELBPEL


Background

Service

Service

Service

ServiceBPEL

Process





Our Approach

Related Work

Future Work

Conclusion

Solutions

14

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


Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

15

AgendaAgenda



Our Approach

Background

Related Work

Future Work

Conclusion

Solutions

16

Our ApproachOur 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)


Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

17

Our Approach Our Approach (2)(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


Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

18



Service

Service

BPELProcess


Related Work

Future Work

Conclusion

Solutions

Background

Our Approach

19



Service

Service

BPELProcess


Related Work

Future Work

Conclusion

Solutions

Background

Our Approach

Proxy Service

20

AgendaAgenda



Background

Solutions

Related Work

Our Approach

Future Work

Conclusion

21

SolutionsSolutions

RobustBPEL (Static Proxies) [11] RobustBPEL-2 (Dynamic Proxies) [10] TRAP/BPEL (Generic Proxies) [9]


Related Work

Background

Our Approach

Future Work

Conclusion

Solutions

22

Original ApplicationOriginal Application


Related Work

Background

Our Approach

Future Work

Conclusion

Solutions

Production

Service

Customer

Accounting

Service

Inventory

Service

Delivery

Service

Sales ServiceSales Service(BPEL Process)

23

Static ProxiesStatic ProxiesOvervieOverview:w:Motivation

Related Work

Background

Our Approach Adapt-ReadyAggregate

Web Service

WS1

pt1

WSn

ptn

......

n partner Web services

Absence of Faults

Presence of Faults

Client Program

Legend:Legend:

Service port type (pt) Service dependencyWeb service (WS)

Future Work

Conclusion

Solutions

24

Adapt-ReadyAggregate

Web Service

WS1

pt1

WSn

ptn

......

ptj

ptj

ptj

Static

Proxy

WSi1

pti

WSip

pti

......

WSj1

WSjq

......

pti

p equivalent Web services for WSi

q equivalent Web services for WSj


Absence of Faults

Presence of Faults

Client Program

Legend:Legend:


Static ProxiesStatic ProxiesOvervieOverview:w:Motivation

Related Work

Background

Our Approach

Future Work

Conclusion

Solutions

25

Dynamic ProxiesDynamic ProxiesOvervieOverview:w:Motivation

Related Work

Background

Our Approach

ptj


Web Service

WS1

pt1

WSn

ptn

......

Dynamic

Proxy

pti

registryservice


Absence of Faults

Presence of Faults

Client Program

Legend:Legend:


Future Work

Conclusion

Solutions

26

Dynamic ProxiesDynamic ProxiesOvervieOverview:w:Motivation

Related Work

Background

Our Approach

ptj


Web Service

WS1

pt1

WSn

ptn

......

Dynamic

Proxy

pti

registryservice


Absence of Faults

Presence of Faults

Client Program

Legend:Legend:


Future Work

Conclusion

Solutions

27

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


Related Work

Background

Our Approach

Future Work

Conclusion

Solutions

28

Generic Proxies Generic Proxies (2)(2)


Related Work

Background

Our Approach

Service discovery

Client Program Client Program

ptg


Web Service 1


Web Service K…

Generic

ProxyDeveloped once

to provide

autonomic

behavior.

Recovery Policy

Recovery Policy

Future Work

Conclusion

Solutions

Replicate

Retry

Alternative resource

29

AgendaAgenda



Related Work

Future Work

Conclusion

Background

Our Approach

Solutions

30

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


Background

Our Approach

Related Work

Future Work

Conclusion

Solutions

31

AgendaAgenda


OvervieOverview:w:

Related Work

Future Work

Conclusion

Motivation

Background

Our Approach

Solutions

32

Future WorkFuture Work Grid Computing

– Extending Recovery Policy– Very High-level composition tools for scientific grid

applications

Software Adaptation– Languages– Applications

OvervieOverview:w:

Future Work

Conclusion

Related Work

Motivation

Background

Our Approach

Solutions

33

AgendaAgenda


OvervieOverview:w:

Future Work

Conclusion

Related Work

Motivation

Background

Our Approach

Solutions

34

ConclusionConclusion Acknowledgements

– FIU Dr. Masoud Sadjadi (Advisor) Eduardo Monteiro

– IBM Research

OvervieOverview:w:

Conclusion

Future Work

Related Work

Motivation

Background

Our Approach

Solutions

35

ConclusionConclusion Questions?OvervieOvervie

w:w:

Conclusion

Future Work

Related Work

Motivation

Background

Our Approach

Solutions

36

ReferencesReferences1. G. von Laszewski et. al, Java CoG Kit Karajan/GridAnt Workflow Guide,

Technical Report, Argonne National Laboratory, 2005.2. B. Ludäscher et. al, Scientific Workflow Management and the KEPLER System,

Concurrency and Computation: Practice & Experience, Special Issue on Scientific Workflows, 2005.

3. S. Hwang and C. Kesselman, GridWorkflow: A Flexible Failure Handling Framework for the Grid, Proc. 12th IEEE International Symposium on High Performance Distributed Computing, 2004.

4. Erradi et. al. Towards a policy driven framework for adaptive web services composition. In Proceedings of International Conference on Next Generation Web Services Practices, 2005

5. Baresi et. al. Smart monitors for composed services. In ICSOC ’04: Proceedings of the 2nd international conference on Service oriented computing, 2004.

6. Erradi et. al. wsBus: QoS-aware middleware for relaible web services interaction. In IEEE International Conference on e-Technology, e-Commerce and e-Service, 2005

7. Charfi et. al. An aspect based process container for BPEL. In Proceedings of the 1st Workshop on Aspect-Oriented Middleware Development. 2005

8. 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)

OvervieOverview:w:

Conclusion

Future Work

Related Work

Motivation

Background

Our Approach

Solutions

ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING TRANSPARENT SHAPING TECHNIQUES Onyeka Ezenwoye...

Documents

Transcript of ENABLING ADAPTABILITY IN COMPOSITE SERVICES USING TRANSPARENT SHAPING TECHNIQUES Onyeka Ezenwoye...