Modified Gradient Search for Level Set Based Image Segmentation Abstract-Level set methods are a popular way to solve the image segmentation problem. The solution contour is found by solving an optimization problem where a cost functional is minimized. Gradient descent methods are often used to solve this optimization problem since they are very easy to implement and applicable to general nonconvex functionals. They are, however, sensitive to local minima and often display slow convergence. Traditionally, cost functionals have been modified to avoid these problems. In this paper, we instead propose using two modified gradient descent methods, one using a momentum term and one based on resilient propagation. These methods are commonly used in the machine learning community. In a series of 2-D/3-D-experiments using real and synthetic data with ground truth, the modifications are shown to reduce the sensitivity for local optima and to increase the convergence rate. The parameter sensitivity is also investigated. The proposed methods are very simple modifications of the basic method, and are directly compatible with any type of level set implementation. Downloadable reference code with examples is available online. O NE POPULAR approach for solving the image segmentation problem is to use the calculus of variations. The objective of the segmentation problem is defined with an energy functional, and the minimizer of this functional represents the resulting segmentation. The functional depends on properties of the image such as gradients, curvatures and intensities, as well as regularization terms, e.g. smoothing constraints. Early variational methods, such as Snakes and Geodesic Active Contours [1] - [4] , often have boundary based terms such as an edge map. A parametrized curve, the active contour, is evolved according to the minimization of the cost functional until it converges to an equilibrium state representing the resulting segmentation. Later variational methods often include terms which are more region-based, allowing segmentation of objects without distinctive edges. These methods are often based on the Mumford-Shah segmentation model [5] where the image is partitioned into piecewise smooth regions with short boundaries. Chan-Vese used this model together with implicit contours represented by level sets [6] - [9] . This made the optimization problem easier and it naturally handles segmentation topology changes.. In order to solve the optimization problem in level set segmentation methods, the gradient descent method is very often used. It deforms an initial contour in the steepest (gradient) descent of the energy. The equations of motion for the contour, and the corresponding energy gradients, are derived using the Euler-Lagrange equation [10] and the condition that the first variation of the energy functional should vanish at a (local) optimum. Then, the contour is evolved to convergence using these equations. The use of a gradient descent search commonly leads to problems with convergence to local optima and slow convergence in general. The problems are accentuated with noisy data or with a non-stationary imaging process, which may lead to varying contrasts for example. The problems may also be induced by bad initial conditions for certain applications. Traditionally, the energy functionals have been modified to avoid these problems by, for example, adding regularizing terms to handle noise, rather than to analyze the performance of the applied optimization method. This is however discussed in [11] , [12] , where the metric defining the notion of steepest descent (gradient) has been studied. By changing the metric in the solution space, local optima due to noise are avoided in the search path.. There are many, and much more advanced, alternatives to gradient descent. For nonconvex functionals, there are global optimization techniques such as subdivision schemes with much better performance [13] . Their high complexity, however, makes them applicable for small problems only. Stochastic methods such as the Monte-Carlo (MC) family is another alternative. Simulated annealing implemented with the Metropolis algorithm and local updates has been a popular choice [14] , [15] . Unfortunately its convergence to a global solution is logarithmically slow, limiting its usefulness but spurring the development of more advanced MC methods, such as basin hopping [16] . This is used in the context of Mumford-Shah segmentation by Law et al. They propose a hybrid approach combining gradient descent based and stochastic optimization methods to resolve the problem of bad initial guesses, resulting in near global optimal solutions [17] . There are also recently developed methods which use a dual formulation of the Total Variation (TV) norm in order to perform fast global minimization of the boundary [18] - [20] . Solem et al. propose using quotient functionals and partial extremal initialization in order to decrease the computation time of the traditional gradient descent method with several orders of magnitude [21] . Graph-based formulations have also been used where a low-energy solution is found by using techniques of combinatorial optimization on a modified Mumford-Shah functional, reformulated on an arbitrary graph [22] . Boykov et al. combined geodesic active contours and graph cuts to find globally minimum geodesic contours [23] . Chang et al. use an active contour model with gradient descent replaced by graph cut global optimization [24] , [25] .. In spite of these more advanced methods, optimization using gradient descent search is still very common and in active use. This is partly due to its simple implementation, but also to its direct applicability to general non-convex functionals. The focus of this paper is to show that the performance of these standard searches can easily be improved upon by very simple modifications.. The paper contains the following contributions: We present two modified gradient descent methods, one using a momentum term and one based on resilient propagation (Rprop). Our ideas stem from the machine learning community where gradient descent methods often have been used in order to train learning systems, e.g. adapting the weights in artificial neural networks. The proposed methods are very simple, but effective, modifications of the basic method and are directly compatible with any type of level set implementation. The first proposed method is based on a modification which basically adds a momentum to the motion in solution space [26] . This simulates the physical properties of momentum and often allows the search to overstep local optima and take larger steps in favorable directions. The second proposed method is based on resilient propagation (Rprop) [27] , [28] . In order to avoid the typical problems of gradient descent search, Rprop provides a modification which uses individual (one per parameter) adaptive step sizes and considers only the signs of the gradient components. This modification makes Rprop less sensitive to local optima and avoids the harmful influence of the magnitude of the gradient on the step size. Individual adaptive step sizes also allow for cost functionals with very different behaviors along different dimensions because there is no longer a single step size that has to be appropriate for all dimensions. In this paper, we show how these ideas can be used for image segmentation in a variational framework using level set methods.. These ideas were initially presented in [29] and [30] . Here, the performances of the proposed methods are quantified in a series of 2D/3D-experiments using real and synthetic data with ground truth. The sensitivity to parameter settings is also investigated, providing greater insights into the performance of the methods. In comparison with standard and stochastic gradient descent (SGD), the modifications are shown to reduce the sensitivity for local minima and to increase the convergence rate. Downloadable reference code with examples is available online.. The paper proceeds as follows: In Section II, we describe the ideas of gradient descent with momentum and Rprop in a general setting and give examples highlighting the benefits. Then, Section III discusses the level set framework and how the proposed methods can be used to solve segmentation problems. The method and the setup of the segmentation experiments in 2D and 3D are presented in Section IV, together with implementation details. The results of these experiments are then presented in Section V. In Section VI we discuss the results and Section VII concludes the paper and presents ideas for future work. Image segmentation using the level set method involves optimization in contour space. In this context, gradient descent is the standard optimization method. We have discussed the weaknesses of this method and proposed using the Momentum and Rprop methods, very simple modifications of gradient descent, commonly used in the machine learning community. The modifications are directly compatible to any type of level set implementation, and downloadable reference code with examples is available online. In addition, we have shown in a series of experiments how the solutions are improved by these methods. Using Momentum and Rprop, the optimization gets less sensitive to local optima and the convergence rate is improved. Rprop in particular is also shown to be very insensitive to parameter settings and to different gradient behaviors. This is very important in practical use since Rprop will work out-of-the-box in many applications using only the standard values of its parameters. In contrast to much of the previous work, we have improved the solutions by changing the method of solving the optimization problem rather than modifying the energy functional. Note that since the focus of this paper is to compare different optimization methods given a certain input, the quality and accuracy of the resulting segmentations may not be comparable to the reference segmentations. The point of these experimental segmentations is to highlight the advantages of the Momentum and Rprop methods in contrast to the ordinary gradient descent. By optimizing the input data (i.e. the filters generating the target function) the segmentations can be improved.. The experiments show the standard gradient method, i.e. SGD with σ = 0, converges to the closest local optimum with resulting poor segmentations. SGD with σ > 0 can escape early local optima with the right amount of noise.. However, choosing σ is nontrivial since too much noise causes the solution contour to jump into the surrounding noise. In addition, GD and SGD converges slowly as their step lengths are proportional to the magnitude of the gradient. These magnitudes can be very low in regions with low signal to noise ratios. A large learning rate η can compensate for this, but will often give rise to oscillations. For certain combinations of parameters, SGD results in good segmentations.. We can also see that the Momentum method can be fast and robust to local optima given an appropriate set of parameters. In experiment Spiral for example, Fig. 8(b) , 32% of the runs achive good segmentation (Y > 0.90). Finding these parameters are not easy however as about 52% of the runs do not reach an acceptable quality. In the Retina experiment, Fig. 9(c) , the ROC-curves of the Momentum method have a lot of variation, again showing large sensitivity to its parameters. A set of parameters that is robust to local optima and gives high segmentation velocity may not converge as it instead oscillates around a solution. This can also be seen in Retina, where 49% of the runs achive acceptable segmentations (Y > 0.75) even though only 30% converge. Because the Momentum method still uses the magnitude of the gradient, it is sensitive to larger regions with low gradient magnitudes. This can be seen in experiment Shell, where all convergent runs stop close to the first wide saddle point. The Momentum method is however robust to large but very local changes in gradient due to the momentum term.. Rprop, in contrast, is very sensitive to large changes in the direction of the gradient since it uses the signs of the gradient components. Rprop is, for the same reason, completely insensitive to the magnitude of the gradients. This can be seen in e.g. Shell, where Rprop passes the first wide saddle point where the other methods stop or struggle. In the Spiral experiment, see Fig. 8(d) , Rprop have 40 ROC-curves with small variation. 88% of these runs are good segmentations. For Retina, Fig. 9 , the ROC-curves of Rprop have low variation. About 76% of these runs result in acceptable segmentations. The experiments clearly demonstrate Rprops robustness against parameter changes and insensitivity towards local optima. For data sets where the magnitude of the gradient has a wide distribution of values, it can be difficult to find a constant learning rate that works for the SGD and Momentum method, see experiment Spiral and Retina for instance. Rprop solves this by continuously adapting the learning rates according to the behavior of the local gradients. The ROC-curves for the experiments confirm this as they show low sensitivity for parameter changes for Rprop in contrast to the Momentum method.. The VascuSynth experiment evaluates the methods on 100 different volumes. The results and behaviors we discussed above are confirmed in this experiment, see Table III . The parameter insensitivity of RPROP stands out as 99% of the runs consistently converges to good solutions. The implementations of the methods are simple, but the interpretation of the gradients must be given special care as described in section IV-B above. Currently we rely on reinitializing the level set function to maintain the signed distance property, but we plan to investigate more elegant solutions to this problem, following the ideas in [46] .. The Momentum and Rprop methods converge in fewer iterations than the standard/SGD method but are slower per iteration. The difference in time per iteration is insignificant in 2D but larger in 3D, where the standard/SGD method is between 50-100% faster than the others. The Momentum method can be as fast or faster than the Rprop method for a good set of parameters. However, looking at the mean performance for a large set of parameters, Rprop converges in significantly less number of iterations as the experiments show. They have approximately the same time complexity per iteration. In order to quantify the quality of a segmentation, we use its corresponding standard Receiver Operating Characteristic (ROC) curve [44] . The ROC is a plot of the true positive rate (TPR) vs. the false positive rate (FPR) of the segmentation for different threshold choices T . It describes the relation between the sensitivity (= TPR) and the specificity (= 1 − FPR), i.e. the relation between correctly segmenting the object and correctly ignoring the background. As a quality measure we use Youden's Index Y [45] , which is a summary statistic of the ROC curve. It is defined as:. = max where T is the threshold. Y is simply the point on the ROC curve with the largest height over the diagonal (TPR = FPR). A perfect segmentation without false positives will give Y = 1. The worst possible (random) segmentation would lie on the diagonal, yielding Y = 0. In the context of level set segmentation, the optimal threshold is per definition T = 0, i.e. the zero level set.. In the following we define acceptable segmentations and good segmentations as runs where Y >0.75 and Y >0.90 respectively. "Y C " denotes the Youden's index for converged runs only; the convergence criterion is defined in IV-C above. The numbers in parentheses give the standard deviation of the measures. In addition, we define Weighted iterations as the number of iterations before convergence divided by the resulting Y of the run. This lets us compare the effectiveness of the methods even if they converge to different solutions. In order to compare real time performance we also look at the clocktime per iteration. The results when testing all combinations of the parameters in Table I are shown in Table II for experiment 1-4, Table III for experiment 5.. Examples of the resulting segmentations for the proposed methods are shown in Fig. 8, Fig. 9, Fig. 10 and Fig. 11 . The figures show both the best segmentation achieved and all the ROC curves which give an indication of parameter sensitivities for the methods.

O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I I O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A

Computational

Study

of

Cost

Reoptimization

for

Min-Cost

Flow

Problems

In

the

last

two

decades,

a

number

of

algorithms

for

the

linear

single-commodity

Min

Cost

Flow

problem

(MCF)

have

been

proposed,

and

several

efficient

codes

are

available

that

implement

different

variants

of

the

algorithms.

The

practical

significance

of

the

algorithms

has

been

tested

by

comparing

the

time

required

by

their

implementations

for

solving

"from

scratch"

instances

of

(MCF),

of

different

classes,

as

the

size

of

the

problem

(number

of

nodes

and

arcs)

increases.

However,

in

many

applications

several

closely

related

instances

of

(MCF)

have

to

be

sequentially

solved,

so

that

reoptimization

techniques

can

be

used

to

speed

up

computations,

and

the

most

attractive

algorithm

is

the

one

which

minimizes

the

total

time

required

to

solve

all

the

instances

in

the

sequence.

In

this

paper

we

compare

the

performances

of

four

different

efficient

implementations

of

algorithms

for

(MCF)

under

cost

reoptimization

in

the

context

of

decomposition

algorithms

for

the

Multicommodity

Min

Cost

Flow

problem

(MMCF),

showing

that

for

some

classes

of

instances

the

relative

performances

of

the

codes

doing

"from

scratch"

optimization

do

not

accurately

predict

the

relative

performances

when

reoptimization

is

used.

Since

the

best

solver

depends

both

on

the

class

and

on

the

size

of

the

instance,

this

work

also

shows

the

usefulness

of

a

standard

interface

for

(MCF)

problem

solvers

that

we

have

proposed

and

implemented.

The

linear

single-commodity

Min

Cost

Flow

problem

(MCF)

is

a

very

interesting

problem

sitting

"on

the

edge"

between

linear

and

combinatorial

optimization.

Given

a

directed

graph

G

(N,

A),

with

n

|N|

nodes

and

m

|A|

arcs,

the

m-vector

c

of

arc

costs,

the

m-vector

u

of

arc

upper

capacities

and

the

n-vector

b

of

node

deficits,

the

problem

is

defined

as.

In

other

words,

a

flow

x

of

minimal

cost

has

to

be

found

that

satisfies

both

node

balancing

constraints

(for

each

node,

the

flow

leaving

the

node

minus

the

flow

entering

must

be

equal

to

the

flow

produced

by

the

node)

and

arc

capacity

constraints.

This

problem

has

a

huge

set

of

applications,

either

in

itself

or

-more

often

-as

a

submodel

of

more

complex

and

demanding

problems,

e.g.

This

is

testified

by

the

enormous

amount

of

research

that

has

been

invested

in

developing

efficient

solution

algorithms

for

(MCF)

problems

either

by

specializing

LP

algorithms

-such

as

the

Simplex

method

or

the

Interior

Point

method

-to

the

network

case,

or

by

developing

ad-hoc

approaches

such

as

those

of

It

is

therefore

extremely

interesting,

both

for

practitioners

and

for

algorithms

developers,

to

evaluate

which

algorithm

is

the

most

efficient

in

practice

to

solve

(MCF).

This

is

usually

done

as

follows:

a

large

set

ofusually

randomly

generated

-instances

of

different

classes

is

collected,

and

the

running

time

required

by

some

implementation

of

different

algorithms

for

solving

these

instances

is

computed.

The

algorithm

whose

implementation

is,

on

average,

faster

for

most

classes

of

instances

as

the

size

of

the

problem

(number

of

nodes

and

arcs)

increases

is

usually

regarded

as

the

most

efficient,

or

at

least

the

most

promising..

However,

in

many

applications

several

closely

related

instances

of

(MCF)

have

to

be

sequentially

solved,

each

instance

differing

from

the

previous

one

only

for

a

-possibly

small

-fraction

of

the

data,

so

that

reoptimization

techniques

can

be

used

to

speed

up

computations.

In

this

setting,

the

most

attractive

algorithm

is

the

one

which

minimizes

the

total

time

required

to

solve

all

the

instances,

as

opposed

to

the

one

that

just

solves

the

first

instance

"from

scratch"

more

efficiently.

Also,

in

most

of

these

applications

the

size

of

the

instances

to

be

solved

is

not

extremely

large,

either

because

each

(MCF)

problem

captures

only

a

part

of

a

very

large

scale

problem

(e.g.

or

because

the

(MCF)

computation

is

used

within

approaches

for

difficult

combinatorial

problems

(e.g.

which

typically

are

not

of

very

large

scale..

Unfortunately,

no

guideline

is

available

-that

we

are

aware

of

-for

choosing

the

correct

(MCF)

algorithm

in

this

setting.

This

paper

aims

to

be

a

first

step

towards

providing

such

a

guideline

for

cost

reoptimization,

i.e.,

the

case

where

only

(a

subset

of)

the

flow

costs

c

ij

are

allowed

to

change

from

one

instance

to

the

following

one.

Cost

reoptimization

is

required

in

many

applications,

see

e.g.

and

the

references

therein;

most

of

these

applications

are

related

to

Lagrangean

techniques,

where

"complicating"

constraints

that

destroy

the

network

structure

of

the

problem

are

relaxed,

and

a

sequence

of

pure

network

problems

with

changing

costs

is

solved

in

order

to

find

optimal

Lagrangean

multipliers

for

the

relaxed

constraints.

In

other

classes

of

applications

different

data

of

the

problem,

such

as

capacities

or

deficits,

changes

from

on

instance

to

the

following

one;

we

plan

to

investigate

on

some

of

these

applications

in

the

future..

In

the

paper,

we

compare

the

performances

of

four

different

efficient

implementations

of

algorithms

for

(MCF)

under

cost

reoptimization

in

the

context

of

a

"real"

application,

i.e.,

the

solution

of

Multicommodity

Min

Cost

Flow

problems

(MMCF)

through

a

decomposition

approach.

The

results

clearly

show

that,

for

some

classes

of

instances,

the

relative

performances

of

the

codes

doing

"from

scratch"

optimization

do

not

accurately

predict

the

relative

performances

when

reoptimization

is

used,

and

therefore

confirm

the

need

for

a

more

accurate

evaluation

of

the

(MCF)

algorithm

to

be

used

if

performance

is

an

issue.

Incidentally,

the

experiments

also

show

that

the

good

results

obtained

in

for

solving

(MMCF)

by

means

of

a

bundle-based

decomposition

approach

could

probably

be

substantially

improved,

since

the

specific

solver

used

there

seems

to

be

the

worst

suited

to

cost

reoptimization

among

the

four

tested..

The

structure

of

the

paper

is

the

following:

in

Section

we

briefly

describe

the

relevant

details

four

(MCF)

solvers

tested

and

of

our

testing

environment;

in

Section

we

present

and

discuss

the

computational

results

and,

finally,

in

Section

we

draw

some

conclusions

and

outline

some

possible

future

research

issues.

We

have

experimented

about

the

relative

efficiency

of

four

(MCF)

codes

under

cost

reoptimization

in

the

context

of

a

"realistic"

application,

that

is,

the

solution

of

(MMCF)

problems

with

a

cost-decomposition

algorithm.

We

were

able

to

test

different

classes

of

(MCF)

instances

of

varying

size,

showing

how

the

running

time

for

"from

scratch"

optimization

of

an

instance

may

not

always

be

a

good

guide

for

selecting

the

algorithm

to

be

used

in

a

cost

reoptimization

setting.

As

a

general

guideline,

codes

implementing

the

primal

simplex

algorithm

tend

to

be

more

efficient

at

reoptimizing

after

a

change

of

costs

than

those

based

on

a

primal-dual

approach,

and

this

often

overbalance

any

advantage

in

"from

scratch"

optimization

that

primadual

codes

may

have,

especially

if

the

size

of

the

instance

is

not

very

large.

However,

for

some

large

instances

primal-dual

codes

may

become

competitive

even

when

cost

reoptimization

is

taken

into

account..

One

-in

our

opinion

-interesting

finding

of

the

experiments

is

that,

although

some

general

indications

can

be

drawn,

no

algorithm

is

always

the

most

efficient:

the

best

choice

for

the

(MCF)

solver

depends

on

both

the

class

and

on

the

size

of

the

instance.

Hence,

our

experience

shows

that

being

able

to

easily

and

efficiently

test

several

different

(MCF)

solvers

within

a

complex

optimization

code

for

the

solution

of

a

network-structured

problem

may

be

very

important

if

an

overall

efficient

approach

has

to

be

obtained.

This

was

precisely

the

rationale

under

our

proposal

of

the

MCFClass

project

for

a

standard

interface

for

(MCF)

problem

solvers.

As

previously

discussed,

having

the

four

(MCF)

solvers

ported

under

the

MCFClass

interface

was

instrumental

for

being

able

to

quickly

and

fairly

perform

the

comparisons.

Therefore,

we

believe

that

more

efforts

should

be

undertaken

to

provide

standard

optimization

components

that

can

be

easily

exchanged

and

used

for

construction

of

sophisticated

approaches.

This

is

also

confirmed

by

the

existence

of

the

similar

-but

with

a

much

broader

range

-OSI

project

for

a

standard

interface

for

Mixed-Integer

Linear

and

Quadratic

Problems

solvers,

that

is

gaining

momentum

in

the

community.

Although

with

a

much

more

limited

scope,

we

hope

that

the

MCFClass

project

can

provide

a

valuable

tool

for

researches

and

practitioners

alike..

In

the

future,

we

plan

to

run

similar

comparisons

in

other

kinds

of

reoptimization

settings,

e.g.,

capacity

reoptimization

or

deficit

reoptimization.

With

the

better

understanding

of

the

reoptimization

phenomenon

thus

acquired

it

could

become

possible

to

design

and

implement

(MCF)

algorithms

that

be

particularly

suited

for

one

of

the

possible

different

types

of

reoptimization.

Finally,

we

plan

to

bring

forward

the

MCFClass

project

with

other

(MCF)

codes

and

by

designing

standard

interfaces

for

other

common

network

problems

like

the

Shortest

Path

problem,

in

a

bid

to

provide

to

researchers

and

practitioners

a

growing

set

of

standard

optimization

components

that

can

be

easily

exchanged

and

used

for

construction

of

sophisticated

approaches

for

difficult

optimization

problems.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A concurrent rule scheduling algorithm for active rules The use of rules in a distributed environment creates new challenges for the development of active rule execution models. In particular, since a single event can trigger multiple rules that execute over distributed sources of data, it is important to make use of concurrent rule execution whenever possible. This paper presents the details of the Integration Rule Scheduling (IRS) algorithm. Integration rules are active database rules that are used for component integration in a distributed environment. The IRS algorithm identifies rule conflicts for multiple rules triggered by the same event by analyzing the read and write sets of each rule. A unique aspect of the algorithm is that the conflict analysis includes the effects of nested rule execution that occurs as a result of using an execution model with an immediate coupling mode. The algorithm therefore identifies conflicts that may occur as a result of the concurrent execution of different rule triggering sequences. The rules are then formed into a priority graph, defining the order in which rules triggered by the same event should be processed. Rules with the same priority can be executed concurrently. The IRS algorithm guarantees confluence in the final state of the rule execution. The IRS algorithm is applicable for rule scheduling in both distributed and centralized rule execution environments. Active database systems extend traditional databases by supporting mechanisms to automatically monitor and react to events that are taking place either inside or outside of the database system [1, 2] . Active rules form the core of any active database system. An active rule, also known as an Event-Condition-Action (ECA) rule, typically consists of three parts: an event, a condition, and an action. An event describes an occurrence that causes a rule to be triggered. The condition is a query over data sources that is checked when the rule is triggered, declaring the set of circumstances that must exist for the action of the rule to be processed. The action is executed in response to condition evaluation and can be used to modify data, retrieve data, or perform application procedures. Active rules were originally designed in the context of centralized database environments and have been used for integrity constraint maintenance and view maintenance as well as general monitoring and notification of specific database states and activities.. In addition to the design of architectures for the execution of active rules [1] , past research on active rules has focused on the design of rule execution models [1, 3, 4, 5, 6, 7] . A rule execution model determines how a set of rules behaves at runtime. Additional research on active rules has investigated properties of active rule behavior, such as termination [8, 9, 10, 11, 12] and confluence [8, 9, 10, 11, 13, 14, 15] . The termination property guarantees that a set of rules will not result in infinite, cyclic rule execution [8] . The confluence property guarantees that the final result of rule execution does not depend on the order in which rules are chosen for execution [8] .. Active rules currently exist in commercial database systems in the form of triggers [16] . More recently, active rules have proven useful for controlling activities in centralized and distributed workflow systems [17, 18, 19, 20, 21] and for supporting event-based, application integration in distributed environments [22, 23, 24, 25, 26] . Our own research has investigated the use of active rules, known as Integration Rules (IRules), for developing a declarative event-based approach to component integration [27, 28, 29, 30] . Through the support of the distributed rule execution engine that is provided by the IRules environment [31, 32] , an application can automatically respond to events from remote components by testing conditions over distributed components and invoking global transactions that execute over distributed sources. The integration rule processor developed as part of the IRules project has been designed for the integration of components with well-defined interfaces based on the Enterprise Java Beans component model [33] .. The use of rules in a distributed environment such as that of the IRules project creates new challenges for the development of active rule execution models. In particular, since a single event can trigger multiple rules that execute over distributed sources of data, it is important to make use of concurrent rule execution whenever possible. Our work has developed the Integration Rule Processing (IRP) algorithm and the Integration Rule Scheduling (IRS) algorithm. The IRP algorithm is based on an algorithm originally presented in [15] , using execution cycles and levels within cycles to control the nested execution of integration rules in a distributed environment. The results of the IRP algorithm are reported in [32, 34] . The IRS algorithm enhances the IRP algorithm with an approach for scheduling the sequential and concurrent execution of multiple rules triggered by the same event. An important aspect of the IRS algorithm is that it guarantees confluence for concurrent rule execution. This paper presents the details of the IRS algorithm. The algorithm analyzes the read and write sets of each rule in the set of rules triggered by an event to identify rule conflicts. Non-conflicting rules can be executed in parallel. But for any two non-conflicting rules, r 1 and r 2 , in a rule set, if r 2 triggers r 3 , r 1 can potentially conflict with r 3 if r 1 and r 2 are allowed to execute concurrently. As a result, the algorithm makes use of the triggering graph to include the cascaded rules triggered by this initial rule set in the analysis process, assigning priorities to the analyzed rules. The prioritized rules are formed into a priority graph, defining the order in which rules triggered by the same event should be processed. Rules with the same priority can be executed concurrently. Furthermore, the IRS algorithm guarantees confluence in the final state of the rule execution. Confluence for the concurrent execution of rules has not been addressed in past research on confluence analysis. An added benefit of the IRS algorithm is that it is applicable for rule scheduling in both distributed and centralized rule execution environments.. The rest of this paper is organized as follows. Section 2 presents existing research on confluence analysis and compares the IRS algorithm with existing research. Section 3 presents an overview of the IRS algorithm along with assumptions and terminology. Section 4 describes the data access algorithm for conflict analysis of a rule set and the cascaded rules associated with each rule in the rule set. Section 5 elaborates on the priority graph construction algorithm for adding priorities to a rule set based on the conflict analysis described in Section 4. Section 6 illustrates how to analyze priority graphs during rule execution to schedule the sequential vs. concurrent execution of rules. Section 7 proves the correctness of the IRS algorithm, illustrating how the algorithm guarantees confluence for rules that are allowed to execute concurrently. The paper concludes in Section 8 with a summary of the contribution of the IRS algorithm and a discussion of future research. In [8, 9, 11, 13] , confluence analysis is based on the definition of commutativity of rule pairs. Two rules r i and r j commute if, starting from the same initial state, the final state of rule execution is the same regardless of which rule is executed first. Six conditions are defined to determine the commutativity of two rules r i and r j . If r i and r j do not satisfy any of the six conditions, then r i and r j are guaranteed to commute. The six conditions are: 1) r i triggers r j , 2) r i untriggers r j , 3) r i activates r j , 4) r i deactivates r j , 5) reverse i and j in conditions 1-4, 6) r i 's action and r j 's action do not commute. According to the definition in [8] , a rule is untriggered if it is triggered at some point during rule processing, but when it is chosen for execution, the rule is no longer triggered because all triggering conditions were undone by other rules.. Rule r i activates rule r j if execution of r i 's action causes new data to satisfy r j 's condition. Rule r i deactivates rule r j if r i 's action deletes all data that satisfies r j 's condition. The research in [11] produces a less conservative solution. The confluence analysis is based on a propagation algorithm that uses extended relational algebra to determine the affect of one rule over another. The algorithm determines how a query in a rule condition can be affected by the execution of a data modification operation in the action of another rule.. Whereas the work in [8, 9, 11, 13] addresses the theoretical question of how to determine if a set of rules is confluent, the algorithm presented in this paper is a constructive solution, using the theoretical results of past work to provide a practical implementation algorithm for organizing the multiple rules triggered by one event into an execution plan that guarantees confluence. The work in [9] was developed for Starburst but states that the theoretical concepts were never implemented. The IRS algorithm is different since it addresses confluence for sequential and concurrent execution of rules. Past research has only addressed confluence of a rule set where rules are executed sequentially in different orders. The IRS algorithm shows that concurrent rule execution must demonstrate confluence not only for all rule pairs, but also for the cascaded rule sets of each rule pair.. The research in [10] is similar in nature to the research in [8] . Their work defines independence, which is similar to the definition of commutativity. Two rules r 1 and r 2 are independent if the sequential execution of r 1 after r 2 produces the same database state as the execution of r 2 after r 1 . Voort has proven that static detection of independence is decidable. Voort has presented the confluence analysis for set and instance-oriented rule execution. According to [10] , all qualifying objects are processed at the same time in set-based semantics, while one qualifying object is processed at a time in instance-based semantics.. The rule model in [10] is restrictive. The algorithm assumes that the action of a rule cannot modify the data accessed by the condition, which restricts the use of this algorithm.. A different approach for confluence analysis is presented in [14] . Active rules are modeled into conditional term rewrite rules. The database state is encoded as a set of object terms. The update requests from users and event occurrence are represented as message terms. By mapping active rules to conditional term rewrite rules, results on confluence of conditional term rewrite systems are used to analyze the confluence problem of active database rules. The implementation of the algorithm in [14] is complex for even small rule applications, while the IRS algorithm presented in this paper provides simplicity for implementation.. The research in [15] uses execution graphs to analyze confluence. Execution graphs assume the use of confluence tables provided by the work of [12, 14] . An execution graph presents conflict, priority, and triggering relationship between rules. The application designer explicitly specifies the priority relationships among rules. An execution graph allows the designer to visually trace the execution by following the dynamic evolution of the execution graph as nodes enter and leave the graph. Within the execution environment of [15] , the application designer make use of execution graphs to interactively control the flow of execution by dynamically manipulating relationships among execution rules. The IRS algorithm assigns priorities based on the analysis of read/write conflicts. Whereas the work in [15] was designed for use in the interactive resolution of rule confluence, the IRS algorithm was designed for automatic resolution of confluence.

O O B I I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


On Modularity in Infinitary Term Rewriting We study modular properties in strongly convergent infinitary term rewriting. In particular, we show that:• Confluence is not preserved across direct sum of a finite number of systems, even when these are non-collapsing.• Confluence modulo equality of hypercollapsing subterms is not preserved across direct sum of a finite number of systems.• Normalization is not preserved across direct sum of an infinite number of leftlinear systems.• Unique normalization with respect to reduction is not preserved across direct sum of a finite number of left-linear systems.Together, these facts constitute a radical departure from the situation in finitary term rewriting. Positive results are:• Confluence is preserved under the direct sum of an infinite number of left-linear systems iff at most one system contains a collapsing rule.• Confluence is preserved under the direct sum of a finite number of non-collapsing systems if only terms of finite rank are considered.• Top-termination is preserved under the direct sum of a finite number of left-linear systems.• Normalization is preserved under the direct sum of a finite number of left-linear systems.All of the negative results above hold in the setting of weakly convergent rewriting as well, as do the positive results concerning modularity of top-termination and normalization for left-linear systems.

O B O O B I O O O O O O O O B I O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O


Assigning Types to Processes ABSTRACT. In wide area distributed systems it is now common for higher-order code to be transferred from one domain to another; the receiving host may initialise parameters and then execute the code in its local environment. In this paper we propose a fine-grained typing system for a higher-order π-calculus which can be used to control the effect of such migrating code on local environments. Processes may be assigned different types depending on their intended use. This is contrast to most of the previous work on typing processes where all processes are typed by a unique constant type, indicating essentially that they are well-typed relative to a particular environment. Our fine-grained typing facilitates the management of access rights and provides host protection from potentially malicious behaviour.Our process type takes a form of an interface limiting the resources to which it has access, and the types at which they may be used. Allowing resource names to appear both in process types and process terms, as interaction ports, complicates the typing system considerably. For the development of a coherent typing system, we use a kinding technique, similar to that used by the subtyping of the system F, and order-theoretic properties of our subtyping relation.Various examples of this paper illustrate the usage of our fine-grained process types in the distributed systems. BACKGROUND In the distributed computing environments nowadays, it is common for higher-order code to be transferred from one domain to another [12, 30, 31] . This is recognised as dangerous and various schemes have been put forward to ensure the integrity of systems in the presence of such operations. In this paper we propose a new subtyping system which can be used to control the effect of migrating code on local environments. Our investigation is in terms of a higher-order π-calculus in which values, including process terms, can be exchanged along communication channels [3, 37, 46] . We believe that our typing system can be readily adapted to related location based distributed calculi such as [6, 9, 24, 14, 36, 43] .. HIGHER-ORDER PROCESSES The language we consider, λπ v , is essentially a call-byvalue λ-calculus [35] augmented with the π-calculus primitives [29] . Values may be sent and received along communication channels, as in the π-calculus, but functions may also be applied to them, as in the λ-calculus. Thus. is a process which inputs a value of type τ on channel c and applies to it the function f . This process will be well-typed only in an environment in which the channel c has the capability to input values of type τ, written c : (τ) I , and f denotes a function of type (τ ! proc); here, as in [10, 33, 46] , we use proc to denote the type of processes.. As usual we allow as values arbitrary abstractions, but much of the descriptive power of λπ v comes from the ability to form values by abstracting over processes. For example (unit ! proc) is the type of thunked processes; we use this type so frequently that we will abbreviate it to hproci. Values of this type, of the form λ(x : unit):P, will also be abbreviated to hPi. Such values can be exchanged between processes and subsequently executed, by applying the function λy:y(); again for the sake of clarity we use run to denote this function. So in "c?(x : τ) f x" in (1) above, if τ is the thunked type hproci and f is the function run, the process may input a thunked process hPi on channel c and execute it.. In papers such as [3, 28, 33, 34, 42, 46] typing systems have been suggested which ensure that programs written in λπ v -related languages are well-behaved. The main judgements normally take the form Γ`P : proc indicating that the term P is a well-typed process relative to the typing environment Γ.. Here Γ is a mapping from channel names or variables to input/output capabilities or value types; Γ(c) determines the type of values which channel c may transmit/receive. Thus "c?(x : τ) f x" in (1), will be well-typed in any environment Γ which allows c the input capability hproci, assuming of course that f is also a well-typed expression of type hproci ! proc, such as Γ fc:hproci I ; f : hproci ! procg.. However such typing offers limited control to programs over the code which they download for execution. To emphasise this point let us consider an example. First we define the abstraction Fw (called forwarder in [20] ) λx λy ( x?(z : int) y!hzi) which repeatedly inputs some value of a type int on channel x and outputs it immediately on y. If the channels a; b are assigned suitable types then both the values hFw(ab)i and hFw(ba)i have type hproci and thus may be sent along channel c to a process such as c?(x : τ) run x (2) But accepting these processes for execution confers on the incoming code different access rights. In the first case the incoming code is allowed to read from channel a and write to channel b while in the second case these rights are reversed. Typing systems in which code can only be assigned the undifferentiated type proc do not provide any mechanism for limiting the effect of incoming code.. TYPING PROCESSES In this paper we extend the typing systems of [46, 33, 14] by allowing processes to have types which bound the resources which they may use. The basic idea is straightforward. For processes in λπ v we will allow judgements of the form. where ∆ is a finite environment, mapping channel names to capabilities. Intuitively this means that relative to Γ the term P denotes a well-defined process which uses at most the resources in the domain of ∆; moreover their use is in accordance with the capabilities given in ∆. These more discriminating types for processes allow processes to be, in turn, more discriminating in the type of values which they will accept. Thus c?(x : h∆ ab i) run x indicates that it is only willing to accept processes for execution if they at most read from resource a and write to b. Let us denote c!hPi for an output process which sends a thunked process hPi to a channel c. Thus, for example, a process c!hFw(ab)i j c?(x : h∆ ab i) run x is well-typed while c!hFw(ba)i j c?(x : h∆ ab i) run x is not; the (thunked) process hFw(ba)i is not acceptable along c as it does not conform to the interface decreed by the host, ∆ ab .. This ability to constrain the effect of imported code means that host processes can, for example, maintain the consistency of local resources. As a simple example consider the process c? (x : h∆ a i) ( The ability to nest these process types gives even further fine-grained control over code behaviour. For example consider req?(y : h∆ c i) (run y j c?(x : h∆ a i) (run x j a?(z : int)P)) where h∆ c i denotes the type hc : h∆ a i O i. The annotated types ensure that the code downloaded on the request channel req can only access the resource c c can only be used to transmit code which can at most access resource a all communications to a will be serviced by the code a?(z : int)P.. CHANNEL ABSTRACTIONS In λπ v processes are also allowed to download abstracted code; code in which resource parameters may be instantiated by the host process before the code is executed. A simple example is the abstraction Fw used above. However it is difficult to see how to give a type to the abstraction Fw which ensures that R and S are assigned such types. Within our current system of types it would be natural to assign to Fw a functional type of the form. for some process type π. If π is the undifferentiated type proc then both R and S would inherit this uninformative type. Otherwise π must assign some definite capabilities to a and b and assuming that typing is preserved under Subject Reduction these capabilities would be inherited by R and S. That is, they would have the same capabilities on the two resources a and b, contrary to our requirements. Our solution is to introduce a new form of dependent functional type. Here σ is a channel type and we allow the type ρ to contain occurrences of the channel variable x. (These occurrences of x in ρ are bound occurrences in (x : σ) ! ρ.) Thus the abstraction Fw will be assigned the type. where the result type of the process depends on the type of the abstracted variables.. SUMMARY OF RESULTS In this paper we formulate a fine-grained subtyping system for the higher-order π-calculus following the basic ideas mentioned above. This results in a simple, but non-trivial, extension of the IO-subtyping for π-calculus [33] to a higher-order setting. The main technical results can be summarised as follows. First, we design a novel notion of type for the higher-order π-calculus, in which process have types corresponding to interfaces. Because type variables appear both in program terms and in types (in particular the types of processes), the formal definition of what constitutes a valid term and a valid type are interdependent and both in turn require a careful definition of even a valid typing environment. An analogous, albeit somewhat simpler, situation arises in subtyping for the polymorphic λ-calculus [7] . We clarify technical similarities and differences between the two typing systems. Although some tech-niques developed for the λ-calculus are useful in the current setting, novel concepts are required for process types.. Second, we propose a typing system in which many higher-order π-calculus processes can be assigned non-trivial interface types. We prove its soundness (Subject Reduction Theorem) and also establish a Type Safety Theorem, which ensures that no well-typed process can input higher-order code which does not conform the local interface of that process.. Finally we show in this paper that a typing system based on these ideas can be developed for λπ v and moreover it can typecheck many sophisticated instances of programs involving code abstraction and mobility.. OUTLINE OF THE PAPER This paper is a revised and extended version of [47] ; it includes detailed definitions and proofs, as well as more examples omitted from [47] . An application to the distributed higher-order calculus in Section 6 is also new to this paper.. Section 2 introduces the types and syntax of λπ v , together with a reduction semantics for the language; it also contains two example descriptions of systems which illustrates the tractability of higher-order code mobility in λπ v . We also explain the order theoretic property FBC (finite-bounded completeness) over the subtyping relation which will be required to ensure that type inference is coherent. Section 3 proposes the new typing system of λπ v , explaining the various technical points in the formulation of the inference rules. Since channels appear freely in the process types, we use a kinding technique analogous to the subtyping of system F [7] . Section 4 demonstrates its expressiveness by typing the examples introduced in Section 2. In Section 5 we discuss the soundness of the typing system. We prove a Subject Reduction Theorem and an elementary Type Safety Theorem. Section 6 shows one interesting extension of our typing system, to the distributed version of λπ v discussed previously in [46] . Finally Section 7 concludes the paper with a discussion of the limitations of our typing system, further issues and related work. Various auxiliary definitions and many of the proofs are routinely relegated to the appendix. This paper developed a new type inference system for a higher-order π-calculus in which the types of processes take the form of an interface; a mapping between channel names and input/output capabilities. Both the operational semantics of our calculus and its typing system are simple and straightforward extensions of the semantics and type constructions for the π-calculus (e.g. [16, 42, 33, 34, 46] ) and λ-calculus (e.g. [7, 11] ).. In the literature on typed process calculi [16, 33, 34, 42] , including extensions to mobile processes [10, 9, 36, 14, 38, 46] , all processes are typed by a unique constant type, indicating essentially that they are well-typed relative to a particular environment. In contrast, our fine-grained subtypes can be used to manage access rights of distributed code and to provide host protection from mobile code, as we have shown by examples of server-clients models. More generally in our language we can view the process type of some higher-order code as a proof that it will respect the constraints of a particular interface. We believe our typing system offers a basic starting point for the study of various static analysis techniques associated with code mobility, such as those found in [30] .. MORE TYPE CONSTRUCTORS We believe that it will be relatively straightforward to extend our set of types with many of the standard constructs from the literature; these include recursive types [5, 42, 33] , record types [11, 41] , polymorphic types [7, 34] , and dynamic types [2, 36] . A particularly useful extension would be linear/affine types, as in the π-calculus and the linear λ-calculus [26, 6, 16, 45] . This would allow, for example, host sites to further control the access to resources by mobile code, by restricting the number of times a channel maybe used. An extension of our capability based typing systems to more advanced distributed primitives, especially to constructs involving security [1, 15, 19, 44] would be more challenging.. TYPED BEHAVIOURAL EQUALITY Types constrain the behaviour of processes and their environments and consequently have an impact on when their behaviour should be deemed to be equivalent. Typed behavioural equivalences have already been investigated for various process calculi in papers such as [26, 33, 34, 45] . Similar techniques could be applied to our language, resulting in a new typed equivalence, where equalities are influenced by the presence of fine-grained process types. Investigation of such equivalences is an interesting research topic, particularly in its application to the refinement of the context equality of [37] . It is also practically meaningful to establish a bisimulation technique in our subtyping calculus by extending methods for HOπ-calculus in [37] and those for CML in [22] ; we leave this for future work.. TYPE CHECKING For a practical use of a typing system, it is essential that we can check the well-typedness of a system P against a type environment Γ. For this purpose, we can construct an equivalent typing system to`without (SUBX H ,SUB N ) in Figure 7 , to obtain a syntax directed system (in type reconstruction we use the partial meet operator to obtain a process type as mentioned in x 3.2). Using this system, since the subtyping relation is always decidable (Proposition 3.6), we can obtain an algorithm to check the typability of P against Γ, as well as an algorithm to compute ρ such that Γ`P : ρ.. Related to type inference algorithms for the π-calculus in general, [42] showed there is a principal typing scheme for Milner's simple sorting with recursive types [28] and analysed its time complexity. However it is still open whether there is a principal typing scheme (in the sense of [23] ) for the IO-subtyping system, even in the π-calculus [33, 16] . More systematic study of principal typings for various typing systems of the π-calculus [42, 33, 41, 34, 26, 16, 38, 45] as well as related complexity analysis is still required. TYPE LIMITATIONS One limitation of our typing system is that, while name variables in types can be abstracted by channel dependency types (x : σ) ! ρ of the channel λ-abstraction λ(x : σ) P, a similar abstraction is not allowed when we bind name variables by input prefix a?(x : σ) P. The result is that there is a loss of information in many of the types we can assign to processes. A typical example is the process a?(x) b!hx!hvii. In the current system this can only be assigned a process type in which b has the capability to output values of the undifferentiated type hproci.. Clearly some form of channel abstraction would be needed to give a more informative type but it is difficult to see how this might be formulated. One problem here is that, unlike β-application, value reception is nondeterministic. In the composed term a?(x) b!hx!hvii j a!hci j a!hdi the particular channel, c or d which is bound to x depends on which message is delivered to the waiting process. Indeed the residual, after receiving an input, may take one of the. There is a similar loss of information in typing restricted processes, (ν a)P. For example the process (ν a)b!ha!h1ii can be assigned, in an appropriate environment, the type b:h i O ] which intuitively says that b can output a (thunked) process which has the empty interface. This type is of limited interest when used in context. For example consider. Here essentially the only the possibility for τ is the type hproci.. Here we should be able to say that b can output a (thunked) process which contains some unknown channel name of type (nat) O , and the input type associated with b should be able to accommodate such constraints. Some form of existential quantification over types may be appropriate but integrating such a construct into the current type language is a non-trivial task.. RELATED WORK We have already made reference to the extensive literature on typing for the π-calculus and related processes. In developing our fine-grained type system we have been guided by the polymorphic λ-calculus [11, 7] , where type variables play an important role; as with our channel names they may appear, and be bound, both in terms and types. However there is an essential technical difference: channel instantiation in our system can result in dynamic changes to the types annotating a term. Channels are exchanged as values between processes but they also appear as interaction points in the types of processes. On the other hand, type variables of the polymorphic λ-calculus are instantiated by types (say int) whereas in our case channel variables occurring in types are instantiated by channels, not by types. This feature necessitated the development of new concepts of well-formed type, subtyping, well-formed substitution, etc., independent of those developed in the context of the λ-calculus.. Pierce and Sangiorgi [34] recently proposed a polymorphic π-calculus and used a refined typed behavioural equivalence to reason about concurrent abstract data types. Since their polymorphic types are based on those of the polymorphic λ-calculus (that is they abstract over type variables via the operator 9), they are quite different from ours. In particular they do not address the issue of assigning fine-grained types to processes.. For sequential computations, Tofte and Talpin have developed the effect typing system [40] , and Tang and Jouvelot developed its subtyping system [39] . This was recently applied to Facile by Kirli [24] . 1 One may think our dependency types correspond to their region polymorphic types. However, her typing system is different from ours since she adds the original effect system to the functional types; hence all process has a constant type Unit and channels cannot carry nested effects.. More precisely, the effect types in [40, 39] are used to represent the region allocation or effects of values during β-reduction, while our process types are used to represent interaction effects between concurrent processes. Hence an integration of the effect typing system of the λ-calculus and the IO-subtyping system of the π-calculus would have difficulty in expressing the kind of constraints guaranteed by our typing system.. De Nicola, Ferrari and Pugliese studied a subtyping system for a language based on Linda [8] , and showed that it is used to control the mobility of agents. In their language, each located process is equipped with different capabilities (read, input, our, eval and newloc) rather than the unique process type, which is similar to our framework. However their calculus is based on CCS rather than the π-calculus and our form of process types based on IO-subtyping and λ-subtyping are not considered in their formulation. Now by Lemma 3.1 (7) again, we have: Γ`ρfu=xg, as desired.. Channel narrowing: Assume a 6 2 fn(P). Then Γ; a : σ; Γ 0`P : α implies Γ; Γ 0 =a`P : α=a.. Here the proof is by induction on the inference of the judgement Γ; a:σ; Γ 0`P : α, together with an examination of the last inference rule used. We consider two cases.. Suppose the last rule used is (ABS N ); that is P has the form λ(x:σ):Q, α is (x :σ) ! ρ and we know Γ; a:σ 0 ; Γ 0 ; x:σ`Q : ρ. Then by the inductive hypothesis, we have Γ; Γ 0 =a; x: σ=a`Q : ρ=a. However since we are assuming a 6 2 fn(P) we know a 6 2 fn(σ), and hence σ=a = σ. Therefore we have Γ; Γ 0 =a; x:σ`Q : ρ=a. We may now apply (ABS N ) to obtain Γ; Γ 0 =a`λ(x : σ):Q : (x : σ) ! ρ=a as desired.. Suppose the last rule used is (IN); that is P has the form u?(x 1 : τ 1 ; :::; x n : τ n )Q and Γ; a : σ; Γ 0`u ?(x 1 : τ 1 ; :::; x n : τ n )Q : π. Then we have: Γ; a:σ; Γ 0 ; x 1 :τ 1 ; :::; x n :τ n`Q : π and Γ; a : σ; Γ 0` u : (τ 1 ; :::; τ n ) I ] π . First by reasoning similar to the above case, we have a 6 2 fn(τ i ) since a 6 2 fn(P). Then by inductive hypothesis, we have: Γ; Γ 0 =a; x 1 : τ 1 ; :::; x n : τ n`Q : π =a and Γ; Γ 0 =a` u : (τ 1 ; :::; τ n ) I ] π=a. (o-proc). proc tπ = proc proc uπ = π For sort types (but not value, term or channel types) we can ensure that both u and t are total; in all cases of S u S 0 (respectively S tS 0 ) not covered by the above clauses (for example if they are structurally dissimilar or do not satisfy the IO constraint), then we set S uS 0 = ? (respectively S tS 0 = >). PROOF. By induction on why Γ; x : τ; Γ 0`P : ρ and as usual an examination of the last inference rule used. Most cases are straightforward and we outline three examples.. Suppose P has the form Q w and the last inference rule used is (APP N ). Then we have: Γ; x : σ; Γ The case (RES) is also a straightforward use of the inductive hypothesis, noting that (π =a)fV =xg = (π fV=xg)=a whenever x and a are different.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


WS-Naming: location migration, replication, and failure transparency support for Web Services Naming transparencies, i.e., abstracting the name and binding of the entity being used from the endpoints that are actually doing the work, are used in distributed systems to simplify application development by hiding the complexity of the environment. In this paper we demonstrate how to apply traditional distributed systems naming and binding techniques in the Web Services realm. Specifically, we show how the WS-Naming profile on WS-Addressing Endpoint References can be used for identity, transparent failover, replication, and migration. We begin with a discussion of the traditional distributed systems transparencies. We then present four detailed use cases. Next, we provide brief background on both WS-Addressing and WS-Naming. Finally, we show how WS-Naming can be used to provide transparent implementations of our use cases. Most applications bring with them a number of "non-functional" characteristics that are critical for success. For example, the time required to perform an operation, the strength of the authentication mechanism used, availability, the integrity of the data, or the application's ability to continue to function in the presence of faults. These characteristics are often referred to as Quality of Service (QoS), Quality of X (QoX), or Service Level Agreement (SLA) properties. Users, whether they are end-users or an organization that uses the application, want instantaneous response, fool-proof security, absolute data integrity, and non-stop performance. Achieving the desired service level is often difficult or impossible, and trade-offs usually need to be made.. One of the jobs of the systems architect is to provide mechanism with which to develop application implementations that meet the non-functional requirements. Implementing the service levels in single host environments is known to be challenging and responsible for a rich literature [8, 10, 12] , e.g., MAPE loops [24] . A distributed, service oriented architecture such as a Web Services based Grid presents significant additional challenges.. The challenges arise out of the distributed nature of Grids: there may be thousands to millions of Web Service containers, in many different mutually distrustful organizations, scattered across the globe, running on hardware that may fail, running applications and services written by thousands of different organizations. To paraphrase Butler Lampson, "a distributed system is a system in which a machine I've never heard of fails, and I can't get any work done.". If Web Services based Grids are to be successful, standard mechanism must be developed that provides the application developer the ability to cope with the complexity of the underlying environment. Furthermore, these mechanisms should not be monolithic and opaque. Instead, the mechanisms should be "stacked" in the sense that a range of mechanism is available, and that the programmer can choose appropriate mechanism and not "pay" for more than they want. These mechanisms should range from high-level capabilities that take requirements specifications and attempt to enforce those requirements (relieving the programmer from the burden of dealing with them), to simple low-level mechanisms that can be used and combined in a variety of ways by the application programmer [20] . Thus, the application developer has the flexibility to either rely on high-level mechanism, or dive down the stack for a custom solution.. One of the often used mechanisms in distributed systems over the years to simplify application development and deal with the complexity of the environment is the use of multi-level naming schemes to provide naming transparency [5, 15, 17, 18, 22, 23 ]. Examples of multi-level naming schemes are numerous. For example, Unix path names map to inodes. The top level name is a human readable string that often has semantic meaning to the user, e.g., /bio/data/sequence1. The inode number, e.g., 1297, rarely does. Similarly DNS names are mapped to IP addresses: mail.cs.virginia.edu is meaningful, while 128.143.137.19 is not. In both of these two-level naming scheme examples a human readable name maps to an address.. In three level naming schemes human names are first mapped to abstract names. Abstract names are usually location independent and intentionally opaque to the client. Before a client can communicate with a resource named via an abstract name the abstract name must first be resolved, or bound to an address. The advantage of a three level naming scheme is that the client can work with human names and have the infrastructure manage the binding logic.. In this paper we demonstrate how traditional distributed system naming and binding techniques can be applied to Web Services. Specifically we show how the WS-Naming [7] profile on WS-Addressing [4, 9] Endpoint References (EPRs) can be used for transparent failover, replication, and migration. WS-Naming, and naming transparencies in general, provide a mechanism for realizing a variety of use cases.. The remainder of this paper is organized as follows. We begin with a background discussion on distributed systems, the classic transparencies, and the definition of a number of terms. In section 3 we present four use cases that motivate WS-Naming. These use cases, along with the collective experiences of the WS-Naming working group of the Open Grid Forum (OGF), drove the requirements developed in section 4. Section 5 presents the WS-Naming profile. Section 6 illustrates how WS-Naming can be used to realize the use cases. In section 7 we examine WS-Naming with respect to the requirements laid out in section 4. In section 8 we describe our implementation of WSNaming. We conclude with a summary and planned future work. Specifications without implementations are always suspect. Is there some hidden flaw? Is the specification implementable with reasonable complexity and effort? How is the performance? Because these questions need to be answered the OGF requires two separate implementations of a proposed specification or profile before promoting the specification to full recommendation.. The Genesis II [14] team at the University of Virginia has implemented WS-Naming. Genesis II is an open source Grid middleware that is being used as a testbed or a number of specifications. Genesis II is implemented in Java and implements both aspects of WSNaming, EPIs and resolvers. All Genesis II EPRs contain an EPI. Our replicated ByteIO [13] service embeds resolver EPRs into ByteIO resource endpoint EPRs.. Genesis II clients are WS-Naming aware and use the techniques described earlier to rebind stale and invalidated WS-Addressing endpoints. Genesis II clients also use EPIs as cache handles for storing the results of cacheable invocations. In Genesis II a client-side Java proxy object is used to communicate with remote Web Service endpoints. This proxy object acts as a central manager for much of the grid client/server interaction details such as SOAP header manipulation (for WS-Addressing, security, etc.) and SOAP attachment management. It also provides a single point where WS-Naming rebinding takes place. Inside this stub, code around the remote invocation watches for failures that would indicate a communication problem (wrong address, wrong security information, etc.).. Any fault condition that it interprets as resulting from stale binding information causes this code to enact the re-resolution process describe in the preceding paragraphs.. High performance and Web Services are not often associated with one another. There is extensive protocol processing going up and down the Web Services stack that results in significant RPC times even for simple calls. When you add in SSL, authorization checking, and state management via a database, the overhead adds up.. That said, we implemented a simple test to determine the overhead of rebinding in our environment. The equipment is a 1.8 GHZ dual-core Intel running Windows Vista. We instantiated a ByteIO service in one container and replicated it another. A resolver service was located in the same container as the second copy. We then "warmed up" the Java environment -causing the JIT to compile and load classes etc. Next, we called the "ping" operation on the ByteIO endpoint and measured the round-trip time to the primary copy.. We then destroyed the primary copy container, and timed the "ping" operation again. This "re-bind" time below includes the time to detect that the primary no longer exists, invoke the resolver to get a new binding, and call the secondary. Note that the full security stack was in place with both transport and message level encryption, strong mutual authentication, and full access control checks (including verifying X.509 certificates).

O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O