Page 1

A Framework for Linking and Pricing

No-Cure-No-Pay 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

2Humboldt-Universit¨ at zu Berlin, Institut f¨ ur Informatik

Unter den Linden 6, 10099 Berlin, Germany

stahl@informatik.hu-berlin.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 (no-cure-no-pay)

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 sell-side and a buy-side. 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 buy-side of the one is connected to the sell-side 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 no-cure-no-pay 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/16-1).

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 sell-side 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 buy-side process that takes care

of the purchase of a service. The sell-side and buy-side 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 no-cure-no-pay 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 (WF-net) [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[Ct|Xt= 1] = νt, cost expectation in case of success.

We use the well known inequality of Chebyshev [6] for a non-negative random

variable Y

IP[Y ≥ c] ≤ IE[ϕ(Y )]/ϕ(c)

for each non-decreasing 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 sell-side 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 buy-side 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 sell-side and a buy-side 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

(no-cure-no-pay).

To provide the service, the provider might have to consume third-party ser-

vices in some order. Clearly, the provider needs to orchestrate these third party

services on-the-fly 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 sell-side processes of the web

service and the buy-side processes of the outsourced tasks. Figure 1 visualizes the

sell-side 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 sell-side 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 buy-side of an outsourced task contains a buy-side process in which first a

request for a proposal is sent to a potential supplier. The process is the “mirror”

of the sell-side process except that the buy-side 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 sell-side 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 buy-side 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 sell-side 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 sell-side process and the buy-side 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 buy-side of one task to the sell-side

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. Buy-side and sell-side 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

buy-side) and lower part (sell-side) 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 tree-like fashion, where

the leaf nodes in the tree corresponding to elementary or outsourced tasks and

the non-leaf 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

e-mail (task m). The process can be expressed in our process-algebraic notation

as follows (note that we have to unfold the iteration (f||t)·e once as the iteration

is executed at least once): p = u · (f||t) · e · ((f||t) · 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· Xa|Xa= 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· Xa|Xa= 1] · IP[Xa= 1]+

a+ µ2

a+ sa· (σ2

b+ µ2

b) + 2 · µb· IE[Ca|Xa= 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·b|Xa·b= 1]

= { By definition. }

IE[Ca+ Xa· Cb|Xa= Xb= 1]

= { Calculus. }

IE[Ca|Xa= Xb= 1] + IE[Xa· Cb|Xa= Xb= 1]

= { Calculus. Caand Xbare independent. }

IE[Ca|Xa= 1] + IE[Cb|Xa= Xb= 1]

= { Cband Xaare independent. }

IE[Ca|Xa= 1] + IE[Cb|Xb= 1]

= { By definition. }

νa+ νb

4.2Parallel composition

Assume that we have a parallel construct a||b that contains tasks a and b. Thus,

a||b 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

a||b is successful if both a and b are successful. The following theorems use the

properties: Xa||b= Xa· Xband Ca?b= Ca+ Cb.

Theorem 5 (Success probability of a||b).

sa||b= sa· sb.

As the proof is similar to Theorem 1, we skip it.

Theorem 6 (Cost expectation of a||b).

µa||b= µa+ µb

Proof.

µa||b

= { By definition. }

IE(Ca||b)

= { Both a and b will be executed: Ca||b= 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 a||b).

σ2

b

a||b= σ2

Proof.

σ2

a||b

= { 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

a||b) − (IE(Ca||b))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 a||b if success).

νa||b= νa+ νb

Proof.

νa||b

= { By definition. }

IE[Ca||b|Xa||b= 1]

= { See Theorem 5 and Theorem 6. }

IE[Ca+ Cb|Xa= Xb= 1]

= { Calculus. }

IE[Ca|Xa= Xb= 1] + IE[Cb|Xa= Xb= 1]

= { a and b are independent. }

IE[Ca|Xa= 1] + IE[Cb|Xb= 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