transparent robustness in service aggregates onyeka ezenwoye school of computing and information...
Post on 18-Dec-2015
213 views
TRANSCRIPT
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?