BPEL is the de facto standard for business process modeling in today's enterprises and is a promising candidate for the integration of business and Grid applications. Current BPEL implementations do not provide mechanisms to schedule service calls with respect to the load of the target hosts.
In this presentation (as well as in the corresponding publication), a solution that automatically schedules workflow steps to underutilized hosts and provides new hosts using Cloud computing infrastructures in peak-load situations is presented.
The proposed approach does not require any changes to the BPEL standard. An implementation based on the ActiveBPEL engine and Amazon's Elastic Compute Cloud is presented.
3. Business Process Execu<on Lang
‣ BPEL is the de facto (OASIS) standard for workflow /
business process modeling in the web service area
‣ Programming in the large: complex applica<ons are built
by composing exis<ng components (web services)
‣ the composed process is exposed as a web service itself
and integrates perfectly into SOAs
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
3
6. Business Process Execu<on Lang
<assign>
‣ Des<na<ons of invoke opera<ons are typically set at
<copy>
<from>
design <me <literal>
<wsa:EndpointReference xmlns:ns="NSPACE">
‣ sejng at run<me possible, but complicated
<wsa:Address>
hfp://FQDN:PORT/SERVICE‐ADDRESS
</wsa:Address>
<wsa:ServiceName PortName="Port">
ns:SERVICE‐NAME
</wsa:ServiceName>
<wsa:ReferenceParameters>
<wsa:To>...</wsa:To>
<wsa:Ac<on>...</wsa:Ac<on>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</literal>
</from>
<to variable="targetEPR"/>
</copy>
<copy>
<from variable="targetEPR" />
<to partnerLink="targetPL" />
</copy>
</assign>
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
5
7. Business Process Execu<on Lang
‣ Des<na<ons of invoke opera<ons are typically set at
design <me
‣ sejng at run<me possible, but complicated
‣ mixup of business logic and <assign>
<copy>
infrastructural sejngs <from>
<literal>
<wsa:EndpointReference xmlns:ns="NSPACE">
<wsa:Address>
hfp://FQDN:PORT/SERVICE‐ADDRESS
</wsa:Address>
<wsa:ServiceName PortName="Port">
ns:SERVICE‐NAME
</wsa:ServiceName>
<wsa:ReferenceParameters>
<wsa:To>...</wsa:To>
<wsa:Ac<on>...</wsa:Ac<on>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</literal>
</from>
<to variable="targetEPR"/>
</copy>
<copy>
<from variable="targetEPR" />
<to partnerLink="targetPL" /> Tim Dörnemann
</copy> Ernst Juhnke
</assign> Bernd Freisleben
5
8. Business Process Execu<on Lang
‣ Des<na<ons of invoke opera<ons are typically set at
design <me
‣ sejng at run<me possible, but complicated
‣ mixup of business logic and <assign>
<copy>
infrastructural sejngs <from>
<literal>
<wsa:EndpointReference xmlns:ns="NSPACE">
‣ very high modeling overhead for <wsa:Address>
hfp://FQDN:PORT/SERVICE‐ADDRESS
dynamic resource selec<on </wsa:Address>
<wsa:ServiceName PortName="Port">
ns:SERVICE‐NAME
</wsa:ServiceName>
<wsa:ReferenceParameters>
<wsa:To>...</wsa:To>
<wsa:Ac<on>...</wsa:Ac<on>
</wsa:ReferenceParameters>
</wsa:EndpointReference>
</literal>
</from>
<to variable="targetEPR"/>
</copy>
<copy>
<from variable="targetEPR" />
<to partnerLink="targetPL" /> Tim Dörnemann
</copy> Ernst Juhnke
</assign> Bernd Freisleben
5
16. Peak Load Scenario
‣ ‣ Scenario: sta<c/pre‐defined target hosts, workflow is
Scenario: sta<c/pre‐defined target hosts, workflow is
invoked many <mes in parallel
invoked many <mes in parallel
‣ leads to high load on workflow's target machines
‣ increase of workflow run<me / response <me
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
6
17. Peak Load Scenario
‣ ‣ Scenario: sta<c/pre‐defined target hosts, workflow is
Scenario: sta<c/pre‐defined target hosts, workflow is
invoked many <mes in parallel
invoked many <mes in parallel
‣ leads to high load on workflow's target machines
‣ increase of workflow run<me / response <me
‣ nega<ve user experience
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
6
18. Peak Load Scenario
‣ ‣ Scenario: sta<c/pre‐defined target hosts, workflow is
Scenario: sta<c/pre‐defined target hosts, workflow is
invoked many <mes in parallel
invoked many <mes in parallel
‣ leads to high load on workflow's target machines
‣ increase of workflow run<me / response <me
‣ nega<ve user experience
‣ loss of stability
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
6
19. Peak Load Scenario
‣ ‣ Scenario: sta<c/pre‐defined target hosts, workflow is
Scenario: sta<c/pre‐defined target hosts, workflow is
invoked many <mes in parallel
invoked many <mes in parallel
‣ leads to high load on workflow's target machines
‣ increase of workflow run<me / response <me
‣ nega<ve user experience
‣ loss of stability
‣ worst case: abandonment of workflow
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
6
20. Peak Load Scenario
‣ ‣ Scenario: sta<c/pre‐defined target hosts, workflow is
Scenario: sta<c/pre‐defined target hosts, workflow is
invoked many <mes in parallel
invoked many <mes in parallel
‣ leads to high load on workflow's target machines
‣ increase of workflow run<me / response <me
‣ nega<ve user experience
‣ loss of stability
‣ worst case: abandonment of workflow
‣ waste of CPU hours (lost intermediate results)
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
6
22. Desired Behavior On-demand
resources
node node node
node node
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
8
23. Desired Behavior On-demand
resources
node node node
node node
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
8
24. Desired Behavior On-demand
resources
node node node
node node
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
8
25. Desired Behavior On-demand
resources
node node node
node node
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
8
26. Desired Behavior On-demand
resources
node node node
node node
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
8
27. Cloud Compu<ng
‣ New paradigm for distributed compu<ng
‣ On‐demand resource provisioning /
Infrastructure as a Service (IaaS)
‣ (Illusion of) unlimited resources
‣ Pay‐as‐you‐go business model
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
9
28. Cloud Compu<ng
‣ New paradigm for distributed compu<ng
‣ On‐demand resource provisioning /
Infrastructure as a Service (IaaS)
‣ (Illusion of) unlimited resources
‣ Pay‐as‐you‐go business model
‣ Implementa<ons open use virtualiza<on
‣ Full (root) access to machines
‣ No batch system (exclusive use of resources)
‣ User may prepare VM image with required
sopware
‣ Easy reuse & deployment
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
9
30. Components
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
11
31. Components
<partnerLink name="decoderPL">
<partnerRole endpointReference="dynamic"
invokeHandler="java:LoadBalancer
?threshold=1.0;accessID=***;secretKey=***;
imageID=ami-95cc28fc;availZone=us-east-1c"/>
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
11
32. 2$%3/4$)
-$./0#%1
Registry 56&&$4#6%
!"#$%&'()*++,)
-$./0#%1
‣ stores informa<on about available hosts and
their services
‣ opera<ons to add, update, remove machines
‣ query for services via portType QNames
‣ UDDI connector to integrate external service
databases
‣ implements locking mechanisms to prevent on‐
demand resources from shutdown while in use
‣ persistence mechanism
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
12
33. Scheduler
‣ uses informa<on about infrastructure to make
scheduling decisions
‣ invokes Provisioner when no suitable machine is found
‣ automa<c deprovisioning of unused machines
‣ stores startup <me of virtual machine and their accoun<ng
model
‣ cost‐efficient scheduling
‣ scheduling algorithms are pluggable
‣ Prototype: For all machines with threshold < t, calculate
cm =
W IP Sm and select the minimum
max(loadm , 0.01) Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
13
34. Provisioner !"#$%&'()*+,-)'*+
!"#$%&%#'("
‣ provides one infrastructure‐independent
interface to manage startup, shutdown and
configura<on of different types of on‐demand
resources
‣ configura<on: firewall rules, sopware installa<on
‣ automa<cally (de‐)registers machines and
their services within registry
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
14
37. Implementa<on
‣ No changes to the BPEL standard required
‣ Makes use of Ac<veBPEL‘s extensibility mechanisms
(Interfaces and observers)
‣ Prototype uses Typica‐Library to manage EC2 instances
(developed by Xerox)
‣ Features:
‣ On‐demand provisioning and deprovisioning of virtual
machines (cost efficient)
‣ Framework supports exchangeability of scheduling
algorithms and provisioning components
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
16
41. Usage Example
‣ Video analysis workflow with
na<ve C/C++ code libraries
‣ needs to be recompiled for
every machine type
‣ Easy to use with Cloud
infrastructure
‣ compile once, embed in VM
image
‣ Prototypical implementa<on
for Amazon EC2
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
20
45. Conclusions
‣ Standard‐compliant extension of BPEL to model dynamic
target service selec<on
‣ Target machines are chosen with respect to their load
‣ On‐demand provisioning of resources in peak‐load
situa<ons
‣ Future Work
‣ Fault‐tolerant workflow execu<on (Cloud‐backed)
‣ Data flow op<miza<on in workflows
‣ Integrate with Eucalyptus
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
23
47. Thank you for listening
Any questions?
Tim Dörnemann
Ernst Juhnke
Bernd Freisleben
24
Hinweis der Redaktion
\n
Classical outline:\n- very brief introduction to BPEL, then Problem Statement/Motivation\n- Design introduces main components of architecture\n- Impl: no details\n- Evaluation w/ respect to performance\n
- BPEL = Business Process Execution Language\n
- All elements within a flow are executed in parallel unless the control flow is explicitly defined (arrows/connection)\n- Receive is starting point, receives input\n- Sequences are executed in parallel, then execution branches merge\n- Work is done in invoke operations -> external web services\n- Reply to user\n
\n
\n
\n
\n
\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
\n
\n
\n
\n
\n
\n
\n
\n
- Description (portType) of services in Workflow, not concrete target address\n- LoadBalancer determines the target service when invoke operation is executed\n- If no machine with low load is found => launch new instance using Provisioner\n
Hosting Environment = Middleware-Container in virtual/physical machine\n\nIMPORTANT: XML-snippet is in deployment descriptor which is not standardized/not part of BPEL\n
- add/update operation triggers WSDL parsing\n
WIPS = Whetstone Instructions per Second (mainly floating point)\nc_m = Capacity of m\n
- Sample: Nimbus/Virtual Workspaces uses WSRF and WS-Notification\n- EC2 offers plain Web Services with pulling mechanism\n
\n
Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
\n
\n
\n
Problemstellung: \n- Ver&#xF6;ffentlichung des Dienstes als &#x201E;Public Service&#x201C; (Web Service). \n- A priori ist nicht bekannt, wieviele Nutzer es geben wird. \n- Bei einer hohen -Nutzeranzahl kommt es zur Verlangsamung oder gar Abbruch\n-> Einsatz von EC2, damit Skalierbarkeit gegeben ist und keine &#xFC;bersch&#xFC;ssige Hardware vorhanden sein muss\n\n
- Only runs shown where VMs where booted\n- ECU = EC2-Compute Unit\n- Expected speedup: 4-5 times, reality: only 2-2,5 (single threaded library)\n- Fluctuations are due to number of VM boots\n
\n
\n
RW: \nDi Penta, WS-Binder (Policy)\nTRAP/BPEL, Proxy-Pattern\nfind_bind, Leymann, Language Extension\nMa et al., LoadBalancing of Engine, not Services\n
Frage: wie kommt man denn eigentlich zu den VM-Images? Unsere Tools benutzen ...\n