A Framework for Linking and Pricing NoCureNoPay Services.
ABSTRACT In this paper, we present a framework that allows us to orchestrate web services such that the web services involved in this orchestration interact properly. To achieve this, we predefine service interfaces and certain routing constructs. Furthermore, we define a number of rules to incrementally compute the price of such a properly interacting orchestration (i.e. a web service) from the price of its web services. The fact that a web service gets only payed after its service is delivered (nocurenopay) is reflected by considering a probability of success. To determine a safe price that includes the risk a web service takes, we consider the variance of costs.

Chapter: Compositional Service Trees
Wil M. P. van der Aalst, Kees M. van Hee, Peter Massuthe, Natalia Sidorova, Jan Martijn van der Werf[Show abstract] [Hide abstract]
ABSTRACT: In the world of Service Oriented Architectures, one deals with networks of cooperating components. A component offers services; to deliver a service it possibly needs services of other components, thus forming a service tree. This tree is built dynamically and not known beforehand. It is hard to verify the behavior of a service tree by using standard verification techniques, because these techniques typically assume a static flattened model. In this paper we model a component by an open Petri net. We give a sufficient condition for proper completion (called soundness) that requires only pairwise checks of the service compositions. We also provide a correctnessbyconstruction approach for building services trees.06/2009: pages 283302;
Page 1
A Framework for Linking and Pricing
NoCureNoPay Services
K.M. van Hee1, H.M.W. Verbeek1, C. Stahl2 ?, and N. Sidorova1
1Department of Mathematics and Computer Science,
Eindhoven University of Technology
P.O. Box 513, 5600 MB Eindhoven, The Netherlands
{k.m.v.hee,h.m.w.verbeek,n.sidorova}@tue.nl
2HumboldtUniversit¨ at zu Berlin, Institut f¨ ur Informatik
Unter den Linden 6, 10099 Berlin, Germany
stahl@informatik.huberlin.de
Abstract. In this paper, we present a framework that allows us to orchestrate web
services such that the web services involved in this orchestration interact properly. To
achieve this, we predefine service interfaces and certain routing constructs.
Furthermore, we define a number of rules to incrementally compute the price of such a
properly interacting orchestration (i.e. a web service) from the price of its web services.
The fact that a web service gets only payed after its service is delivered (nocurenopay)
is reflected by considering a probability of success. To determine a safe price that includes
the risk a web service takes, we consider the variance of costs.
1Introduction
In the future, the world of web services will most likely behave in a way similar
to business units in a real economy. Web services will sell services to their clients,
that may be web services themselves. In order to produce these services, they may
buy services from other web services. So each web service has two (inter)faces:
a sellside and a buyside. In order to deliver one service, a tree of other web
services forming a supply chain may be needed. Two services in the chain are
linked if the buyside of the one is connected to the sellside of the other. A web
service may be successful or it may fail. Examples of web services that might be
used by other web services are public web services providing the stock market
prices, weather forecasts, and news items. Other examples of web services that
could be used in supply chains are computations, such as actuarial computations
and risk analysis computations. Also services providing movies, television, and
telephone services could be part of such a web service supply chain.
Web services will be paid for by a system of micro payments [1]. We assume
a nocurenopay system, which implies that a service is paid for if and only if
the service is successfully delivered. There are at least two important questions
for such world of services: firstly, how do we guarantee that two linked services
work properly together? Secondly, what should be the price of service in order to
be profitable?
?Funded by the DFG project “Substitutability of Services” (RE 834/161).
Page 2
For the first question we have to define what it means for two services to
work properly together. Informally, this means that a service request is always
followed by a response: either the requested service is delivered, or a message is
sent saying that the requested service cannot be delivered. We provide in this
paper a framework where this property is guaranteed. In our framework, each
web service contains a sellside process that represents the protocol for selling a
service. Internally, there is a process for the orchestration of the services. A service
is built up from tasks that are either elementary or compound. An elementary
task is either executed by the web service itself or it is outsourced to another
web service. In the latter case the task contains a buyside process that takes care
of the purchase of a service. The sellside and buyside processes of all services
together form the choreography of the world of web services. They are designed
in such a way that two arbitrary services fit together properly.
The second part of the paper considers the pricing mechanism for services.
For the price of a service we have to take into consideration that a service may
fail. Since we assume a nocurenopay system, a web service may have to pay all
or some of its service providers while it fails to deliver its service to its client. This
can be due to stochastic phenomena, such as the availability of servers. In that
way, a web service takes risks. Therefore, it is a nontrivial problem to determine
the price of a service. We develop a method to determine the expectation µ and
the variance σ2of the cost of the service. Assuming a normal distribution for
service cost C, we may say that the cost of service is less or equal to µ + 1.65· σ
with probability 95%. This assumption may be justified by the fact that a service
is built up by several independent services. We also provide an exact probabilistic
bound for the cost of a service.
The paper is structured as follows. Section 2 introduces Petri nets and some
probability notions. The framework for linking web services is presented in Sec
tion 3. Here, web services are considered as components and the choreography
and orchestration processes are modeled as Petri nets. Then, in Section 4, we
present our pricing model for web services. We show how to compute the ex
pected cost and the cost variance of a web service in an inductive way. Related
work is presented in Section 5 and finally, Section 6 concludes the paper.
2Preliminaries
Petri nets and workflow nets We assume the usual definition of a (place/
transition) Petri net N = (P,T,F) (see [2], for instance) and use the standard
notation to denote the preset and postset of a place or a transition:•x = {y 
(y,x) ∈ F} and x•= {y  (x,y) ∈ F}.
The state of a net is a marking m which is a distribution of (black) tokens
over the set of places. A transition is enabled if each place of its preset holds a
token. An enabled transition t can fire in a marking m by consuming tokens from
the preset places and producing tokens for the postset places, yielding a marking
2
Page 3
m?. The firing of t is denoted by m
marking m by a firing of a (possibly empty) sequence of transitions is denoted
by m
A workflow net (WFnet) [3] is a Petri net N = (P,T,F) that is specifically
tailored towards modelling workflow processes. A workflow net N has exactly one
input place i, i.e.•i = ∅, and one output place o, i.e. o•= ∅, and every place and
transition lies on some path from i to o.
An important correctness property of workflows is soundness [3], which com
prises the requirements that for every transition sequence that fires starting from
the initial marking a marking can be reached where only o is marked, and no
transition is dead in N. Soundness can be automatically checked by a number of
Petri net tools, like the tool Woflan [4,5].
t− → m?, reachability of a marking m?from a
∗− → m?.
Some notions of probability A service consists of tasks. Each task t has
a random variable Xt with a Bernoulli distribution: Xt = 1 indicates success
whereas Xt= 0 indicates failure. Furthermore, the probability of success for a
task t is IP[Xt= 1] = st.
Each task t (either elementary or compound) has a random variable Ctde
noting the cost of the task. In case t is a compound task, Ctincludes the costs
of the tasks it contains. This random variable depends in general on Xtand has
the following characteristics:
– IE[Ct] = µt, cost expectation,
– var(Ct) = σ2
In Section 4 we will see that, to compute the cost variance, we need to compute
the following auxiliary variable:
– IE[CtXt= 1] = νt, cost expectation in case of success.
We use the well known inequality of Chebyshev [6] for a nonnegative random
variable Y
IP[Y ≥ c] ≤ IE[ϕ(Y )]/ϕ(c)
for each nondecreasing function ϕ and any positive number c. In particular,
t, cost variance.
IP[(Ct− µt)/σt ≥ c] ≤ IE[((Ct− µt)/σt)2]/c2= 1/c2
and therefore
IP[Ct≥ µt+ c · σt] ≤ IP[(Ct− µt)/σt] ≤ 1/c2.
3Web Services Framework
In the web services domain, Petri nets provide a good formalism to model web
services that communicate with each other through an interface, which is typically
modeled by interface places (see [7], for example). For this reason, we distinguish
3
Page 4
interface places from other places. An interface place can either be an input place
or an output place. An input place has no (internal) input arcs, whereas an output
place has no (internal) output arcs. As a result, a web service is not allowed to
communicate with itself.
A web service has a sellside process and an orchestration process. The orches
tration process has to be executed in order to deliver the service. The orchestra
tion process consists of tasks. We distinguish elementary tasks, outsourced tasks,
and compound tasks. An elementary task is modeled as a Petri net transition. An
outsourced task is in fact a subnet that contains a buyside process. A compound
task is a subnet containing elementary or outscourced tasks. In fact, the whole
orchestration process can be considered as one (compound) task. As mentioned
in the introduction, we can distinguish between a sellside and a buyside of a
web service. Typically, when some service wants to use another service, that is,
if the former consumes a service that is being provided by the latter, the for
mer first requests a quote from the latter. Based on the offer from the provider
(which is optional, as the provider may decide not to offer the service), the client
decides to either accept or reject the offer. If the offer is accepted, the provider
actually provides the service, which might either succeed or fail. This result is
communicated to the client, which pays the provider if the result was a success
(nocurenopay).
To provide the service, the provider might have to consume thirdparty ser
vices in some order. Clearly, the provider needs to orchestrate these third party
services onthefly to achieve its goal. In contrast, the negotiation between the
provider and the customer belongs to the choreography process.
3.1Choreography
The choreography in the framework consists of the sellside processes of the web
service and the buyside processes of the outsourced tasks. Figure 1 visualizes the
sellside of a web service, whereas Figure 2 visualizes the buy side of a task. As
usual, circles represent places and squares represent transitions. For the ease of
reference, sad smileys have been used for the failure places and happy smileys for
the success places.
Underlying assumption for the sellside of a web service is that it can handle
a predefined number of requests simultaneously. This predefined number corre
sponds to the number of tokens which are initially put into the place idle. Thus,
if the maximum number of requests is being handled, then no offer can be made
for the next request.
The buyside of an outsourced task contains a buyside process in which first a
request for a proposal is sent to a potential supplier. The process is the “mirror”
of the sellside process except that the buyside process handles requests in a
sequential order.
4
Page 5
request no offerofferrejectaccept
start
failure
failure
success
success
payment
idle
decidingwaiting processingfinishing
Orchestration
Choreography/Sell
Component
Fig.1. The sellside of a web service
3.2 Orchestration
The web service can perform an elementary task like a computation, an out
sourced task that requests a service from another web service like retrieving some
information from an underlying database, or a compound task that needs to
orchestrate a number of (sub)tasks. In principle, such an orchestration can be
arbitrarily complex, but in this paper we consider four types of operations to
construct compound tasks:
1. sequence, i.e. performing a number of tasks in a given order,
2. parallel composition, i.e. performing a number of tasks simultaneously,
3. choice, i.e. performing one task chosen from several tasks, based on some
decision, and
4. while, i.e. performing a task as long as some condition holds.
Nevertheless, we would like to stress that the framework can be extended with
additional orchestration types if needed (as long as soundness is guaranteed, see
further down in this section). Reason for restricting to this set of operations in
this paper is that these four types are sufficient to explain the matters at hand,
whereas additional types might only distract the reader.
Figures 3–6 visualize these four basic orchestration types. Again, we use the
sad smileys for the failure places and the happy smileys for the success places, and
we use grey boxes to visualize the orchestrated tasks. For the sake of simplicity,
we used only two tasks for the sequence, parallel composition, and choice, but it
is not hard to see that this scheme can be extended to any number.
We provide a brief explanation for the parallel orchestration: this orchestration
fails if any of the tasks fails, and succeeds if all the tasks succeed. An alternative
would be to use 2ntransitions (where n is the number of tasks) to handle this
orchestration scheme, but such a scheme scales badly leading to a net explosion.
5
Page 6
start
no offeroffer rejectacceptrequest
failure
failure
success
successpayment
started
offeredacceptedcompleted
requested
Choreography/Sell
Component
Orchestration
requestno offerofferreject acceptfailuresuccesspayment
Task/Buy
Fig.2. A task in the buyside of a web service
Sequence
(Compound) Task(Compound) Task
Fig.3. A sequence of tasks
Therefore, we use a scheme that requires only 2n+3 transitions and 2 additional
places: failures and successes. These places hold the failure and success messages
(tokens). If n successes have been signalled, and hence no failures, the orches
tration may signal success. If some failures have been signalled, then we allow
the signalled successes to be converted into failures. After all successes have been
converted this way, the orchestration can signal its failure. Note that we use here
transitions that consume n tokens simultaneously in one firing and that n is a
parameter here.
For the while case, if the specified condition holds, then the T transition can
fire, otherwise the F transition can fire.
Figure 7 depicts an example service using the web service framework, con
taining one choreography component (the sellside process of the service), three
6
Page 7
(Compound) Task(Compound) Task
Choice
Fig.4. A choice between tasks
n
n
failures successes
(Compound) Task (Compound) Task
Parallel
Fig.5. A number of tasks in parallel
F
T
(Compound) Task
While
Fig.6. A while construct
7
Page 8
request no offerofferrejectaccept failure successpayment
Orchestration
Orchestration
Orchestration
Task
Task/Buy
Task/Buy
Task
Choreography/Sell
Component
Fig.7. An example service
Fig.8. Checking orchestration soundness
orchestration components (which are compound tasks), and four tasks (the buy
side processes of the service). Thereby, Task denotes an elementary task and
Task/Buy an outsourced task. The sellside process and the buyside processes
are fixed (see Figures 1 and 2), but the orchestration components are not (so
they are not displayed). Using the orchestration components (see Figures 3 to 6)
we can build a complex orchestration hierarchy.
3.3Soundness
Clearly, any task should lead to either a success or a failure, i.e. if a task starts
with one token in its start place, then for any reachable marking it should be
possible to reach the marking with only one token either in place success or in
place failure. We call this the soundness of a task. This soundness concept differs
a little from the one given in Section 2, namely we have two final places (success
and failure) instead of one. By the construction of Figure 8 these notions can be
unified. In order to analyze the soundness of a task, we distinguish two parts:
soundness of the choreography part and of the orchestration part.
For the choreography part we connect the buyside of one task to the sellside
of another service as displayed in Figure 9. We first neglect the three places start,
failure and success at the bottom. Then, soundness is not difficult to verify. This
8
Page 9
start
no offeroffer
reject acceptrequest
failure
failure
success
success
payment
startfailuresuccess
Fig.9. Buyside and sellside combined
can be done by brute force model checking since the set or reachable markings
is finite. It is also easy to verify this property by observing that the upper (the
buyside) and lower part (sellside) of the model are almost symmetrical state
machine nets that have the property that each choice is made by only one of
them. Now consider places start, failure and success at the bottom. Here we have
to make the assumption that if a token is put into start, eventually there will be
a token in either failure or success. Under this assumption the system is sound. So
we introduce here the concept of conditional soundness: the choreography part
is sound if the invoked tasks are sound.
For the orchestration part we use the same conditional soundness. We argue
that we only need to check soundness on elementary tasks, as any orchestration is
sound if and only if its tasks are sound. This is straightforward to check using only
Figures 3 to 6. In case that the framework is extended by some new orchestration
types, we need to check this requirement (i.e. the orchestration is sound if and
only if the tasks are sound). So we only have to check the soundness of elementary
tasks and they are just transitions.
9
Page 10
3.4Running example
We have restricted ourselves to orchestration processes that are constructed using
the four routing constructs sequence, parallel composition, choice, and iteration.
Therefore, we can present an orchestration process in a treelike fashion, where
the leaf nodes in the tree corresponding to elementary or outsourced tasks and
the nonleaf nodes correspond to a compound task with one of the four routing
constructs. This allows us to represent the orchestration processes in a process
algebraic notation where the sequence operator is denoted by ·, parallel composi
tion by , choice by +, and iteration by∗. We will assume that∗binds strongest,
then ·, then +, and last . This notation is very useful for the derivation of the
cost formulas in Section 4.
As an example process consider an image editing process p. The customer
uploads an image (task u). Then, the following procedure is applied: the image
is finished (task f) and concurrently a thumbnail is created (task t). Afterwards
the results are evaluated (task e). In case that the evaluation is negative, the
procedure is repeated. Finally, if the image is too big, it is stored temporarily
and only a link is sent to the customer (task l); otherwise the image is sent by
email (task m). The process can be expressed in our processalgebraic notation
as follows (note that we have to unfold the iteration (ft)·e once as the iteration
is executed at least once): p = u · (ft) · e · ((ft) · e)∗· (l + m).
For the example, we assume that the following characteristics are given:
– In 90% of the cases, the upload succeeds.
– In 95% (80%) of the cases, finishing (creating the thumbnail) succeeds which
costs the customer e20 (e10).
– In 99% of the cases the evaluation succeeds which costs another e5; in only
20% of the cases the loop has to be repeated.
– In 30% of the cases, the image is too big; the storing is charged with e10
whereas the sending of the images costs e1.
Note that we have two kinds of probabilities: the probability of a choice in the or
chestration, here used for the iteration, and the probability of failure of a service.
If some task of a service fails, the whole service fails. The question now is, what
should the service provider charge the consumers to make any profit, and what
are the risks involved? In the following, we present a mathematical framework to
answer this question.
10
Page 11
4Pricing Model
The probability of success of a task t is st. The cost Ctof task t is a random
variable, with expectation µt, conditional expectation νt, given the service does
not fail and variance σ2
price and the risk in case of failure. The price should compensate the loss in case
the service fails. So a lower bound for the price is µt/stwhich gives an expected
reward of (µt/st)·stwhich equals to the expected cost. However, the service must
have an earning capacity to cover losses, so we choose a price µt/st+ b where
b is a parameter to be determined. The expected profit will be b · st which is
the difference between the expected reward and the expected cost. In order to
determine b, we have to calculate the risk. There are several ways to define the
risk.
An obvious definition of risk is the probability that the real cost exceed the
expected reward. So IP[Ct≥ µt+ b · st] should be small enough. If we accept a
5% risk we have to choose b such that
t. With these four characteristics we will determine a safe
IP[Ct≥ µt+ b · st] = IP[(Ct− µt)/σt≥ b · st/σt] ≤ 0.05
Assuming a normal distribution for Ct, we derive from the standard normal dis
tribution, that b·st/σt= 1.65 and so b = 1.65·σt/stand therefore the price of the
service is (µt+ 1.65 · σt)/st. The assumption of normality is justified by the fact
that a service is built up by several independent services and so the central limit
theorem [6] justifies a normal approximation. We also have an exact probabilistic
bound based on the Chebyshev inequality (see Section 2)
IP[(Ct−µt)/σt≥ (b·st)/σt] ≤ IE[((Ct−µt)/σt)2≥ (b·st/σt))2] = σ2
since IE[((Ct−µt)/σt)2] = 1. This gives b = (σt/st)/√0.05 = 4.47·σt/stwhich is
almost three times as large as the former bound.
A second way to define the risk is the expected cost, under the condition that
the task fails. Since we will calculate νtthis can be expressed as µt−νt·st. Note
that this quantity is independent of the price. A third way is to define the risk
as IE[max(0,Rt− Ct)] where Rtis a random variable that represents the reward
for a task t, so Rt= 0 in case of a failure and Rt= µt/st+ b in case of success.
This measure for risk, however, requires knowledge of the complete distribution
of Ct. Therefore we will use the first interpretation of risk.
In the rest of this section we will calculate the four characteristics in an induc
tive way: for an elementary task t we assume they are given. This is reasonable,
because such values can be estimated from log files, for instance. For a com
pound task we will derive the characteristics for the four orchestration constructs
sequence, parallel, choice, and iteration. We use Xtas the random variable that
indicates if the task t is a success (Xt= 1) or a failure (Xt= 0). So this random
t/(b2·s2
t) = 0.05
11
Page 12
variable has a Bernoulli distribution with probability of success st. Note that Ct
and Xtare dependent. The reason for this is in the sequence construct: the cost
in case of failure might be less than the cost of success. In the rest of the paper
we assume that each invocation of a task instance is (stochastically) independent
of all other instances, in particular for a ?= b we have Xaand Caare mutually
independent of Xband Cb.
4.1Sequence
Assume that we have a sequence construct a·b that contains (in the given order)
tasks a and b. Thus, a · b prescribes that first a has to be completed, after which
b can be started. First, we compute the success probability (sa·b) for a·b; second,
we compute its cost expectation (µa·b); third, we compute the cost variance (σ2
and fourth, we compute the conditional cost expectation of a·b in case of success
(νa·b). In all cases, we assume that these characteristics for a and b are known
(by induction, if you will).
For the following proofs two properties are important: Xa·b= Xa·Xband Ca·b=
Ca+ Xa· Cb.
a·b);
Theorem 1 (Success probability of a · b).
sa·b= sa· sb.
Proof.
sa·b
= { Definition of sa·b. }
IP[Xa·b= 1]
= { a · b is successful iff both a and b are successful: Xa·b= Xa· Xb. }
IP[Xa· Xb= 1]
= { a and b are Bernoulli distributed. }
IP[Xa= 1 ∧ Xb= 1]
= { Successes of a and b are independent. }
IP[Xa= 1] · IP[Xb= 1]
= { Definition of saand sb. }
sa· sb
Theorem 2 (Cost expectation of a · b).
µa·b= µa+ sa· µb
Proof.
µa·b
= { Definition of µa·b. }
IE(Ca·b)
= { b is only executed iff a succeeded. }
12
Page 13
IE(Ca+ Xa· Cb)
= { Xaand Cbare independent. }
IE(Ca) + IE(Xa) · IE(Cb)
= { By definition. }
µa+ sa· µb
For the proof of the next theorem, we need the following lemma:
Lemma 1.
IE(C2
a·b) = σ2
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · µb· νa· sa
Proof.
IE(C2
= { Definition of Ca·b. }
IE((Ca+ Xa· Cb)2)
= { Calculus, definition of µc. }
IE(C2
= { a and b are independent. }
IE(C2
= { σ2
σ2
= { Due to the Bernoulli distribution, IE(X2
σ2
= { Case distinction: a either succeeds (Xa=1) or fails (Xa=0). }
σ2
2 · IE(Cb) · IE[Ca· XaXa= 0] · IP[Xa= 0]
= { Calculus. IE(Cb) = µb. }
σ2
= { By definition. }
σ2
a·b)
a+ X2
a· C2
b+ 2 · Ca· Xa· Cb)
a) + IE(X2
a= IE(C2
a+ µ2
a) · IE(C2
a) − (IE(Ca))2, hence IE(C2
a+ IE(X2
b) + 2 · IE(Cb) · IE(Ca· Xa)
a) = σ2
a+ (IE(Ca))2= σ2
a+ µ2
a, etc. }
a) · (σ2
b+ µ2
b) + 2 · IE(Cb) · IE(Ca· Xa)
a) = IE(Xa) = sa. }
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · IE(Cb) · IE(Ca· Xa)
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · IE(Cb) · IE[Ca· XaXa= 1] · IP[Xa= 1]+
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · µb· IE[CaXa= 1] · IP[Xa= 1]
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · µb· νa· sa
Theorem 3 (Cost variance of a · b).
σ2
a·b= σ2
Proof.
σ2
a·b
= { By definition. }
IE(C2
= { Lemma 1. See Theorem 2 }
σ2
= { Calculus. }
σ2
= { Calculus. }
σ2
a+ sa· σ2
b+ (sa− s2
a) · µ2
b+ 2 · (νa− µa) · sa· µb
a·b) − (IE(Ca·b))2
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · µb· νa· sa− (µa+ sa· µb)2
a+ µ2
a+ sa· (σ2
b+ µ2
b) + 2 · µb· νa· sa− µ2
a− s2
a· µ2
b− 2 · µa· sa· µb
a+ sa· σ2
b+ (sa− s2
a) · µ2
b+ 2 · (νa− µa) · sa· µb
13
Page 14
Theorem 4 (Conditional cost expectation of a · b if success).
νa·b= νa+ νb
Proof.
νa·b
= { By definition. }
IE[Ca·bXa·b= 1]
= { By definition. }
IE[Ca+ Xa· CbXa= Xb= 1]
= { Calculus. }
IE[CaXa= Xb= 1] + IE[Xa· CbXa= Xb= 1]
= { Calculus. Caand Xbare independent. }
IE[CaXa= 1] + IE[CbXa= Xb= 1]
= { Cband Xaare independent. }
IE[CaXa= 1] + IE[CbXb= 1]
= { By definition. }
νa+ νb
4.2Parallel composition
Assume that we have a parallel construct ab that contains tasks a and b. Thus,
ab prescribes that both a and b have to be executed, and that they can be
executed in parallel. Like with the sequence construct, the parallel construct
ab is successful if both a and b are successful. The following theorems use the
properties: Xab= Xa· Xband Ca?b= Ca+ Cb.
Theorem 5 (Success probability of ab).
sab= sa· sb.
As the proof is similar to Theorem 1, we skip it.
Theorem 6 (Cost expectation of ab).
µab= µa+ µb
Proof.
µab
= { By definition. }
IE(Cab)
= { Both a and b will be executed: Cab= Ca+ Cb. }
IE(Ca+ Cb)
= { a and b are independent. }
IE(Ca) + IE(Cb)
= { By definition. }
µa+ µb
14
Page 15
Theorem 7 (Cost variance of ab).
σ2
b
ab= σ2
Proof.
σ2
ab
= { By definition. }
IE(C2
= { See Theorem 6. }
IE((Ca+ Cb)2) − (IE(Ca+ Cb))2
= { Calculus. a and b are independent. }
IE(C2
= { Calculus. a and b are independent. }
IE(C2
= { Calculus. }
IE(C2
= { By definition. }
σ2
b
a+ σ2
ab) − (IE(Cab))2
a+ 2 · Ca· Cb+ C2
b) − (IE(Ca) + IE(Cb))2
a) + 2 · IE(Ca) · IE(Cb) + IE(C2
b) − (IE(Ca))2− 2 · IE(Ca) · IE(Cb) − (IE(Cb))2
a) − (IE(Ca))2+ IE(C2
b) − (IE(Cb))2
a+ σ2
Theorem 8 (Conditional cost expectation of ab if success).
νab= νa+ νb
Proof.
νab
= { By definition. }
IE[CabXab= 1]
= { See Theorem 5 and Theorem 6. }
IE[Ca+ CbXa= Xb= 1]
= { Calculus. }
IE[CaXa= Xb= 1] + IE[CbXa= Xb= 1]
= { a and b are independent. }
IE[CaXa= 1] + IE[CbXb= 1]
= { By definition. }
νa+ νb
4.3 Choice
Assume that we have a choice construct a+b that contains tasks a and b, and that
the alternatives (a and b) are chosen with an independent random variable A,
with IP[A = 1] = α = 1−IP[A = 0]. If A = 1, then a will be chosen, else if A = 0,
then b will be chosen. The following theorems use: Xa+b= A · Xa+ (1 − A) · Xb
and Ca+b= A · Ca+ (1 − A) · Cb.
Theorem 9 (Success probability of a + b).
sa+b= α · sa+ (1 − α) · sb.
15