Adaptive

Parameter

Passing

Cristina

Videira

Lopes

Northeastern

University

College

of

Computer

Science

Boston

MA

USA

Tel

-LRB-617-RRB- 373 5204

Fax

-LRB-617-RRB- 373 5121

email

crista@ccs.neu.edu

February

Abstract

Parameter

passing

is

one

of

the

main

problems

in

distributed

object-oriented

applications

Passing

objects

by

global

reference

is

very

inefficient

since

the

proliferation

of

global

references

implies

an

increasing

number

of

cross-context

invocations

Passing

objects

by

copying

them

to

the

remote

context

is

usually

a

better

policy

The

problem

with

pass-by-copy

is

that

the

underlying

system

ca

n't

predict

exactly

how

much

of

the

object

graph

will

be

used

in

the

remote

context

Therefore

there

may

be

performance

losses

due

to

either

copying

in

excess

or

copying

too

little

This

paper

presents

an

adaptive

graph-based

solution

to

the

problem

of

parameter

passing

in

distributed

object-oriented

applications

The

solution

presented

here

makes

use

of

graph

directives

for

the

purpose

of

optimizing

the

copying

of

objects

which

are

passed

as

parameters

in

remote

invocations

These

specifications

are

done

using

a

very

simple

graph

traversal

language

-LCB-

GOOP

The

resulting

parameter

passing

scheme

can

be

made

optimal

for

every

situation

in

the

applications

Category

research

Topic

distributed

systems

Supported

by

the

Portuguese

Foundation

for

Research

Science

and

Technology

-LRB-

JNICT

-RRB-

Introduction

Parameter

passing

is

one

of

the

main

problems

in

distributed

object-oriented

applications

The

coexistence

of

different

address

spaces

-LRB-

contexts

-RRB-

that

share

objects

and

pass

them

around

in

method

invocations

is

a

double-edge

sword

On

the

one

hand

sharing

objects

is

one

of

the

basic

purposes

of

distribution

and

the

object-oriented

languages

offer

very

appealing

programming

models

for

developing

software

applications

in

general

On

the

other

hand

the

existence

of

a

network

and

the

necessity

of

accessing

remote

objects

makes

it

impossible

to

maintain

the

modularity

of

the

object

models

without

severe

performance

losses

Object-oriented

operating

systems

and

programming

languages

have

been

forced

to

compromise

between

these

two

opposite

directions

To

illustrate

the

problem

consider

the

following

object

invocation

o.m

-LRB-

p

-RRB-

where

o

is

the

invoked

object

m

is

the

invoked

method

and

p

is

a

reference

to

some

object

When

object

o

is

remote

to

the

calling

context

what

exactly

should

be

passed

for

parameter

p

On

the

extreme

two

radically

different

approaches

can

be

made

The

first

approach

is

to

prevail

modularity

Objects

are

identified

by

global

references

-LCB-

unique

object

identifiers

that

exist

above

each

particular

address

space

When

passed

as

parameters

only

the

global

references

are

passed

and

any

subsequent

invocations

to

those

parameters

result

in

remote

invocations

back

to

the

context

where

the

objects

execute

The

second

approach

is

to

prevail

performance

Because

objects

passed

as

parameters

are

highly

likely

to

be

invoked

in

the

remote

context

copying

the

objects

to

the

remote

context

is

an

obvious

optimization

so

that

subsequent

invocations

to

the

parameters

are

performed

on

the

local

copies

Between

these

two

approaches

there

are

many

possibilities

Several

distributed

programming

languages

and

systems

have

proposed

interesting

solutions

Emerald

-LSB-

-RSB-

for

example

provides

a

set

of

primitives

to

define

different

parameter

passing

semantics

objects

can

be

passed

by

reference

by

visit

or

by

migration

and

the

parameter

passing

mode

is

defined

by

the

programmer

along

with

the

object

invocation

Distributed

Smalltalk

-LSB-

-RSB-

and

COOL

-LSB-

-RSB-

are

two

other

distributed

programming

languages

that

also

provide

explicit

object

location

control

associated

with

parameter

passing

More

recently

most

implementations

of

CORBA

-LSB-

-RSB-

support

parameter

passing

both

by

global

reference

and

by

copy

when

objects

are

passed

by

copy

all

their

subobjects

are

copied

to

the

remote

contexts

very

much

like

the

standard

Remote

Procedure

Call

model

-LSB-

-RSB-

Other

distributed

systems

make

this

issue

transparent

to

the

programmer

and

implement

algorithms

that

try

to

optimize

parameter

passing

and

object

replication

in

the

absence

of

any

semantic

knowledge

about

the

applications

The

pure

object-model

applied

to

distributed

applications

without

any

kind

of

optimization

is

unfeasible

for

any

practical

purposes

and

does

not

scale

-LCB-

the

proliferation

of

global

references

is

very

inefficient

since

it

implies

an

increasing

number

of

cross-context

invocations

Passing

objects

by

copying

them

is

usually

a

better

policy

The

problem

with

pass-by-copy

is

that

the

operating

system

does

n't

know

what

parts

of

the

object

will

be

used

in

the

remote

context

By

using

a

pessimistic

approach

this

may

result

in

copying

the

whole

object

graph

from

one

context

to

another

In

many

of

the

application

situations

only

a

small

portion

of

the

object

graph

is

actually

used

in

the

remote

context

Therefore

a

better

solution

is

to

copy

only

some

part

of

the

object

graph

and

delay

the

copying

of

other

necessary

parts

to

some

point

in

the

future

when

they

are

actually

accessed

Ideally

however

we

would

like

to

send

in

only

one

message

all

the

parts

that

are

used

in

the

remote

context

and

only

those

parts

This

paper

presents

an

adaptive

graph-based

solution

to

the

problem

of

parameter

passing

in

distributed

object-oriented

applications

The

solution

presented

here

makes

use

of

graph

directives

to

specify

the

copying

strategy

for

objects

which

are

passed

by

copy

in

remote

invocations

These

specifications

are

done

using

a

very

simple

graph

traversal

language

GOOP

-LCB-

Graph

Object-Oriented

Patterns

The

resulting

parameter

passing

scheme

can

be

made

optimal

for

every

different

situation

in

the

applications

This

paper

does

n't

try

to

solve

the

problems

arising

from

having

several

replicas

of

the

objects

in

many

address

spaces

It

solely

focuses

on

the

optimization

of

parameter

passing

in

remote

invocations

The

Case

Against

Well-Intentioned

Operating

Systems

A

lot

of

research

has

been

done

on

programming

languages

and

operating

systems

for

distributed

The

goal

of

all

this

research

is

to

ease

the

task

of

the

programmers

With

this

goal

in

mind

many

of

these

systems

fall

on

a

common

mistake

they

hide

the

distribution

issues

from

the

programmer

This

argument

has

been

recently

referenced

in

the

literature

for

clustering

of

objects

Clustering

presents

roughly

the

same

kinds

of

problems

as

parameter

passing

since

it

has

been

introduced

as

an

optimization

for

the

coexistence

of

the

processes

address

spaces

and

the

secondary

storage

address

space

The

work

presented

by

Tsangaris

and

Naughton

in

-LSB-

-RSB-

suggests

that

clustering

can

bring

a

certain

amount

of

benefits

for

all

applications

up

to

a

certain

point

at

that

point

any

default

clustering

this

paper

we

use

the

term

operating

system

to

refer

to

any

kind

of

run-time

support

for

distributed

applications

either

a

complete

operating

system

or

a

platform

running

on

top

of

an

operating

system

policy

implemented

by

the

operating

system

will

result

in

good

performance

for

one

application

but

it

will

be

bad

for

many

others

M.

Day

in

-LSB-

-RSB-

proposes

that

objects

be

clustered

in

groups

that

may

be

specific

to

an

application

or

user

and

that

can

be

computed

at

fetch

time

The

same

argument

has

also

been

made

either

implicit

or

explicitly

for

synchronization

in

concurrent

and

distributed

object-oriented

applications

Works

such

as

CEiffel

-LSB-

-RSB-

and

Sina

-LSB-

-RSB-

along

with

the

works

presented

by

FrOElund

and

Agha

-LSB-

-RSB-

Lopes

and

Lieberherr

-LSB-

-RSB-

and

Masuhara

et

al.

-LSB-

-RSB-

suggest

that

the

programmers

should

be

given

the

chance

to

define

synchronization

strategies

rather

than

being

imposed

with

some

default

policy

implemented

by

the

system

The

work

on

open

implementations

and

metaobject

protocols

by

Kiczales

-LSB-

-RSB-

calls

for

frameworks

with

a

dual-interface

to

object

behavior

the

ordinary

base-level

program

and

the

meta-program

that

customizes

the

underlying

system

The

reasons

for

this

opening

of

the

implementation

is

again

the

inability

of

the

underlying

system

to

adapt

optimally

to

each

application

's

needs

With

respect

to

distributed

applications

we

think

that

the

role

of

the

operating

system

should

be

to

provide

the

basic

mechanisms

for

object

distribution

without

imposing

any

rigid

policies

Distributed

applications

exist

because

the

overall

behavior

of

collaborating

execution

components

is

somehow

more

appropriate

than

having

one

single

execution

component

At

the

level

of

the

operating

system

the

aim

for

transparency

should

not

hide

from

the

programmers

the

multiplicity

of

the

environment

Instead

distribution

aspects

including

the

performance

optimization

that

comes

from

copying

parameters

between

contexts

should

be

defined

and

refined

by

application

experts

since

only

they

know

what

's

best

for

their

specific

case

The

challenge

then

is

to

find

high-level

constructs

that

allow

the

programming

of

distribution

policies

and

optimizations

Overview

of

Our

Approach

The

goal

of

our

work

is

to

abstract

the

distribution

issues

so

that

they

can

be

controlled

by

the

programmer

without

making

him/her

aware

of

the

low-level

implementation

details

We

describe

our

approach

as

taking

one

step

back

from

the

state-of-the-art

but

going

one

step

up

We

go

back

from

the

powerful

operating

systems

and

languages

that

try

to

solve

parameter

passing

as

transparent

as

possible

to

the

programmer

what

we

need

from

the

operating

system

is

a

run

time

support

for

remote

invocations

that

takes

arbitrary

packing/unpacking

routines

for

the

parameters

We

go

up

one

level

of

abstraction

from

classes

GOOP

is

based

on

class

graphs

in

which

the

vertices

represent

classes

and

the

edges

represent

relations

between

classes

The

units

of

software

are

not

classes

but

class

subgraphs

class

graphs

contain

much

more

information

about

the

application

than

single

classes

The

overview

of

our

approach

for

the

purpose

of

this

paper

can

be

seen

in

Fig.

The

application

is

defined

in

two

separate

building

blocks

the

basic

behavior

implemented

by

class

graphs

and

class

implementations

and

the

parameter

passing

optimization

block

which

describes

the

parameter

passing

optimizations

in

terms

of

subgraphs

program

Object-Oriented

program

Object-Oriented

program

BehaviorBasic

BehaviorParameter

passing

Scheme

Parameter

passing

Scheme

-LRB-

class

graphs

class

impl

-RRB-

-LRB-

class

graphs

class

impl

-RRB-

GOOP

levelOOlevel

Figure

Separating

parameter

passing

schemes

from

programs

The

remainder

of

this

paper

is

organized

as

follows

Section

presents

the

basic

concepts

of

GOOP

programs

Next

in

section

we

discuss

some

particular

characteristics

of

distributed

applications

and

describe

the

extensions

in

GOOP

graphs

as

a

result

of

those

special

characteristics

Both

sections

and

serve

as

the

basis

for

section

in

which

we

describe

the

solution

for

adaptive

parameter

passing

in

remote

invocations

present

some

examples

and

discuss

the

consequences

Then

in

section

we

analyze

some

related

work

Finally

section

summarizes

and

concludes

this

paper

Basics

In

this

section

we

describe

the

basics

of

GOOP

our

graph

language

without

considering

any

aspects

of

distribution

The

concepts

described

here

are

a

subset

of

the

Demeter

System/C

-LSB-

-RSB-

GOOP

uses

the

same

class

graphs

as

Demeter

As

for

the

class

implementations

GOOP

uses

C++

methods

directly

instead

of

the

Demeter

propagation

patterns

Class

Graphs

The

structural

aspects

of

GOOP

applications

are

described

by

class

graphs

where

vertices

represent

classes

and

edges

represent

relations

between

classes

Detailed

information

about

the

GOOP

class

graphs

can

be

found

in

-LSB-

-RSB-

Very

briefly

class

graphs

in

general

contain

four

kinds

of

vertices

and

two

kinds

of

edges

ffl

Vertices

-LCB-

Hexagon

abstract

class

-LCB-

Square

concrete

class

-LCB-

Hexa-square

collection

class

-LCB-

Ellipse

terminal

-LRB-

primitive

-RRB-

class

ffl

Edges

-LCB-

Single

line

from

A

to

B

A

knows-of

B.

Full

line

indicates

mandatory

knowledge

-LRB-

exactly

one

-RRB-

dashed

line

indicates

optional

knowledge

-LRB-

zero

or

one

-RRB-

-LCB-

Double

line

from

A

to

B

B

is-a

A

-LRB-

subclass

relationship

-RRB-

Fig.

shows

a

class

graph

for

a

Library

System

application

According

to

this

class

graph

the

class

Book

for

example

knows-of

objects

of

classes

Title

Author

Publisher

Subject

Year

ISBN

and

Copy

List

class

CheckBook

is

a

subclass

of

class

Operation

and

has

two

subclasses

of

its

own

which

are

CheckOut

and

CheckIn

opsop_codeOperation_ListOperationInvalidSearchUserShowUsersSearchBookS

howBooksExituidUser_ListUserPhonesPhoneAddressStatusBook_ListBookCopy

ListCopyHomePhoneWorkPhoneFaxCheckedOut_ListCheckedOutISBNYearTitleAut

horPublisherSubjectLibrarySystemusersbooksfnamelnamearea_codenumbernum

berstreetaptzipcitystatequotanborrowertapsnyCheckBookCheckInCheckOutLi

bs_ListothersStringStringStringNumberNumberNumberNumber

Figure

Class

graph

for

a

Library

System

application

Our

system

includes

a

graphical

user

interface

to

define

such

class

graphs

GOOP

uses

textual

descriptions

of

class

graphs

For

the

purpose

of

this

paper

the

internal

representation

is

irrelevant

and

we

will

use

the

graphical

representation

Class

Implementations

The

class

implementations

in

GOOP

are

written

in

C++

-LSB-

-RSB-

Below

follows

an

example

of

the

implementation

of

the

operation

search

book

This

example

does

n't

introduce

anything

new

-LCB-

we

include

it

here

because

we

will

analyze

it

as

a

concrete

example

throughout

the

paper

Only

the

important

methods

are

shown

at

class

SearchBook

it

asks

for

a

key

and

prints

out

the

search

result

in

all

the

other

classes

it

searches

for

a

book

given

a

key

One

important

remark

is

that

if

such

book

is

found

it

comes

as

an

output

parameter

and

only

some

parts

of

it

will

be

printed

out

namely

the

title

the

author

and

the

ISBN

int

SearchBook

-LRB-

LibrarySystem

lib

-RRB-

-LCB-

String

key

new

String

-LRB-

-RRB-

Book

book

new

Book

-LRB-

-RRB-

cout

Enter

key

cin

key

if

-LRB-

lib

-LRB-

key

book

new

Number

-LRB-

-RRB-

-RRB-

NOTFOUND

-RRB-

cout

No

matches

were

found

n

else

book

-LRB-

-RRB-

Only

title

author

and

ISBN

-RCB-

int

LibrarySystem

-LRB-

String

key

Book

b

Number

first

-RRB-

-LCB-

if

-LRB-

books

-LRB-

key

b

-RRB-

FOUND

-RRB-

return

FOUND

if

-LRB-

first

-RRB-

return

NOTFOUND

Only

the

root

library

does

this

return

-LRB-

others

-LRB-

key

b

new

Number

-LRB-

-RRB-

-RRB-

-RRB-

-RCB-

int

-LRB-

String

key

Book

b

Number

first

-RRB-

-LCB-

-LRB-

this

-RRB-

LibrarySystem

lib

while

-LRB-

lib

-LRB-

-RRB-

-RRB-

if

-LRB-

lib

-LRB-

key

b

first

-RRB-

FOUND

-RRB-

return

FOUND

return

NOTFOUND

-RCB-

Code

Generation

The

GOOP

compiler

implements

the

function

generate

-LRB-

GxC

-RRB-

OOP

that

is

it

takes

a

class

graph

and

a

set

of

class

implementations

and

produces

a

complete

object-oriented

program

-LRB-

in

C++

-RRB-

GOOP

simply

needs

to

generate

the

C++

class

definitions

For

example

the

class

definition

generated

for

class

LibrarySystem

will

be

class

LibrarySystem

-LCB-

books

users

ops

others

public

int

-LRB-

String

Book

Number

-RRB-

-RCB-

Class

Graphs

for

Distributed

Applications

In

building

distributed

applications

we

want

to

be

able

to

provide

more

information

to

the

underlying

system

so

that

optimizations

can

be

made

In

particular

we

want

to

define

which

objects

serve

as

remote

entry

points

in

the

global

object

graph

of

the

application

These

objects

unlike

all

the

others

may

be

remotely

invoked

and

play

a

special

role

in

the

application

both

from

the

programmer

's

perspective

and

from

the

operating

system

perspective

At

the

same

time

we

also

want

to

define

which

objects

always

execute

in

the

same

context

so

that

invocations

are

always

local

This

knowledge

of

the

application

distribution

intentions

allows

several

optimizations

both

by

the

programmer

and

by

the

GOOP

compiler

For

this

purpose

GOOP

extended

the

basic

class

graphs

To

Be

or

Not

To

Be

a

Server

The

capacity

to

respond

to

remote

invocations

is

a

very

important

characteristic

of

the

objects

and

is

fundamental

for

distributed

object-oriented

applications

Entities

that

have

this

characteristic

can

be

thought

of

as

servers

-LCB-

using

the

Client/Server

terminology

-LRB-

and

for

lack

of

a

better

word

-RRB-

In

fact

they

provide

the

remote

services

corresponding

to

their

interfaces

In

distributed

object-oriented

applications

should

all

objects

provide

remote

services

transparently

or

should

there

be

a

distinction

between

server

objects

and

data

objects

as

the

previous

Client/Server

systems

suggested

From

the

operating

system

's

perspective

there

is

a

distinction

between

objects

that

may

be

invoked

remotely

and

those

which

may

not

Server

objects

introduce

an

overhead

in

the

system

both

in

terms

of

extra

code

-LRB-

stubs

marshaling

routines

etc

-RRB-

and

in

terms

of

performance

-LRB-

remote

invocations

complexity

of

garbage

collection

etc

-RRB-

Making

a

distinction

between

server

objects

and

data

objects

allows

certain

optimizations

at

the

OS

level

because

data

objects

are

always

invoked

locally

can

be

recycled

by

some

local

mechanism

and

do

n't

require

any

extra

functionality

for

the

purpose

of

remote

invocations

Many

systems

support

this

distinction

either

by

implementing

two

different

object

abstractions

-LRB-

for

example

Argus

-LSB-

-RSB-

-RRB-

or

by

inheritance

from

different

system

classes

-LRB-

for

example

the

CORBA-compliant

systems

-RRB-

Having

two

different

object

abstractions

breaks

the

uniformity

of

the

object

model

and

implies

that

server

objects

be

handled

differently

from

data

objects

Defining

server

characteristics

by

inheritance

or

by

any

other

mechanism

that

preserves

uniformity

of

the

objects

is

a

much

more

elegant

solution

since

it

allows

server

object

references

to

be

passed

around

in

method

calls

as

ordinary

data

object

references

But

it

's

from

the

applications

perspective

that

the

distinction

is

truly

important

The

design

of

a

distributed

application

will

certainly

result

in

identifying

objects

which

play

the

role

of

servers

and

objects

which

are

less

important

from

a

distribution

point

of

view

For

example

in

the

Library

System

application

shown

in

Fig.

instances

of

the

LibrarySystem

class

are

the

obvious

candidates

for

servers

in

the

sense

that

they

are

the

entry

points

for

all

the

information

in

each

of

the

libraries

At

the

same

time

it

does

n't

make

much

sense

to

perform

remote

invocations

on

instances

of

classes

SearchUser

ShowUsers

etc

-LCB-

these

operation

objects

should

be

available

in

every

context

anyway

As

for

the

rest

of

the

classes

it

's

up

to

the

designers

of

the

distributed

version

of

this

application

to

define

whether

direct

remote

invocations

should

be

allowed

or

not

In

summary

-LRB-

-RRB-

being

a

server

or

not

is

a

design

decision

specific

to

each

distributed

application

that

may

have

important

effects

on

the

peformance

and

-LRB-

-RRB-

server

objects

and

data

objects

should

however

be

handled

in

exactly

the

same

way

at

the

programming

level

Remote

Vertices

Following

the

previous

discussion

we

extended

the

GOOP

class

graphs

with

the

concept

of

remote

vertex

A

remote

vertex

indicates

that

instances

of

that

class

provide

remote

services

i.e.

they

are

server

objects

However

from

the

programming

language

point

of

view

they

look

exactly

the

same

as

ordinary

data

objects

there

is

no

difference

in

implementation

of

their

methods

they

can

be

instantiated

deleted

passed

as

parameters

in

method

invocations

etc.

In

the

Library

System

example

we

choose

to

define

the

LibrarySystem

class

as

a

remote

vertex

The

representation

of

the

new

graph

can

be

seen

in

Fig.

-LRB-

only

the

interesting

subgraph

is

shown

-RRB-

opsOperation_ListOperationUser_ListUserBook_ListBookusersbooksLibs_Lis

t

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

LibrarySystemothers

Figure

LibrarySystem

as

remote

vertex

Remote

vertices

are

represented

with

a

double

line

There

are

no

restrictions

to

being

a

remote

vertex

all

types

of

vertices

can

be

made

remote

When

an

abstract

class

is

made

a

remote

vertex

all

its

subclasses

inherit

the

ability

to

provide

remote

services

The

GOOP

compiler

generates

stubs

and

marshaling

routines

for

each

of

the

remote

service

methods

This

is

the

most

interesting

contribution

of

this

paper

and

will

be

explained

in

the

next

section

Remote

Method

Invocations

and

Adaptive

Parameter

Passing

This

section

explains

our

solution

for

optimizing

parameter

passing

on

remote

invocations

We

call

our

approach

adaptive

parameter

passing

because

it

is

based

on

succinct

graph

specifications

-LCB-

graph

directives

-LCB-

that

define

class

subgraphs

without

referring

to

all

of

their

vertices

and

edges

In

a

separate

file

and

for

each

class

corresponding

to

a

remote

vertex

in

the

graph

the

programmer

defines

its

interface

along

with

the

graph

specifications

for

the

parameters

Default

Consider

the

class

graph

represented

in

Fig.

-LRB-

along

with

Fig.

-RRB-

and

the

class

implementation

for

the

operation

search

book

presented

in

section

In

the

implementation

of

this

operation

for

class

Libs

List

there

are

method

invocations

to

objects

of

class

LibrarySystem

that

may

result

in

remote

calls

since

class

LibrarySystem

is

defined

as

a

remote

vertex

When

a

remote

call

occurs

objects

passed

as

parameters

may

be

copied

between

contexts

copying

implies

marshaling

the

object

graph

which

is

reachable

from

the

given

object

into/from

the

RPC

message

according

to

the

mode

of

the

parameters

In

the

search

book

example

we

want

the

parameters

of

types

String

and

Number

to

be

input

parameters

and

the

parameter

of

type

Book

to

be

an

output

parameter

So

in

the

parameters

passing

scheme

we

define

SERVER

LibrarySystem

OPERATION

int

-LRB-

IN

String

key

OUT

Book

book

IN

Number

n

-RRB-

This

interface

specification

is

separated

from

the

class

implementation

and

it

instructs

the

GOOP

compiler

for

the

purposes

of

generation

of

packing/unpacking

routines

Using

the

above

specification

and

under

a

pessimistic

approach

the

subgraph

involved

in

the

marshaling

of

the

second

parameter

is

the

one

shown

in

Fig.

That

is

the

Book

object

eventually

returned

from

the

remote

call

will

bring

all

the

other

objects

which

are

reachable

from

it

uidUserPhonesPhoneAddressStatusBookCopy_ListCopyHomePhoneWorkPhoneFaxC

heckedOut_ListCheckedOutISBNYearTitleAuthorPublisherSubjectfnamelnamea

rea_codenumbernumberstreetaptzipcitystatequotanborrowertapsnyNumberNum

berNumberNumberStringStringString

Figure

Default

subgraph

involved

in

the

marshaling

of

a

Book

object

Copying

all

the

objects

accessible

from

the

parameter

object

is

very

inefficient

considering

that

the

application

uses

the

returned

book

simply

to

print

out

its

title

name

and

ISBN

The

list

of

book

copies

along

with

the

correspondent

information

about

borrowers

and

all

the

other

books

they

are

borrowing

is

a

useless

overhead

for

this

specific

situation

Therefore

this

is

an

obvious

case

for

optimization

Graph

Directives

for

Copying

Minimization

Fig.

presents

our

solution

In

the

interface

specification

the

objects

to

be

copied

by

the

underlying

system

are

defined

in

terms

of

graph

directives

that

identify

a

particular

subgraph

of

the

whole

class

graph

This

particular

traversal

directive

asks

for

all

paths

from

Book

to

Title

Author

and

ISBN

but

only

the

ones

that

bypass

the

edge

that

goes

from

Book

to

Copy

List

The

result

is

the

subgraph

shown

in

Fig

-LCB-

compare

this

graph

with

the

default

graph

of

Fig.

Unless

otherwise

stated

the

immediate

parts

that

are

of

primitive

types

-LRB-

String

Number

etc

-RRB-

are

always

included

in

the

subgraph

SERVER

LibrarySystem

OPERATION

int

-LRB-

IN

String

key

OUT

Book

book

IN

Number

n

-RRB-

book

TRAVERSE

FROM

Book

BYPASSING

Book

TO

-LCB-

Title

Author

ISBN

-RCB-

Figure

Specification

for

passing

the

Book

parameter

BookISBNTitleAuthortanNumberString

Figure

Optimized

subgraph

involved

in

the

marshaling

of

the

Book

object

Our

graph

language

is

a

subset

of

the

graph

language

used

for

propagation

patterns

in

the

Demeter

system

-LSB-

-RSB-

The

formal

syntax

definition

of

traversal

directives

is

given

in

appendix

A

and

the

formal

semantics

is

based

on

the

work

by

Palsberg

et

al.

-LSB-

-RSB-

Basically

the

language

contains

primitives

to

define

the

source

vertex

the

target

vertices

and

primitives

for

path

constraints

such

as

bypassing

The

meaning

of

these

primitives

is

intuitive

The

source

vertex

and

the

set

of

target

vertices

define

a

subgraph

of

the

class

graph

containing

all

possible

paths

from

source

to

target

The

path

constraint

primitives

select

only

some

of

those

paths

bypassing

excludes

a

set

of

edges

through

demands

for

a

set

of

edges

via

demands

for

a

set

of

vertices

Note

that

in

the

traversal

specification

of

Fig.

we

need

the

bypassing

primitive

to

avoid

the

cycle

path

that

goes

from

Book

to

Book

again

via

fCopy

List

User

CheckedOutg

As

another

example

suppose

that

in

some

generic

method

M

attached

to

class

LibrarySystem

we

want

to

pass

a

parameter

of

type

User

from

which

we

will

only

access

the

titles

of

its

corresponding

checked

out

books

A

possible

optimization

for

this

parameter

would

be

SERVER

LibrarySystem

OPERATION

t

M

-LRB-

IN

User

user

-RRB-

user

TRAVERSE

FROM

User

BYPASSING

Book

borrower

TO

-LCB-

Title

-RCB-

The

subgraph

corresponding

to

the

graph

directive

above

is

shown

in

Fig.

uidUserStatusBookCheckedOut_ListCheckedOutTitlefnamelnamequotatNumberN

umberStringString

Figure

Optimized

subgraph

involved

in

the

marshaling

of

the

User

object

As

third

and

final

example

we

show

how

adaptive

parameter

passing

can

behave

as

a

filter

for

passing

objects

depending

on

their

types

Consider

the

graph

in

Fig.

which

represents

a

list

of

things

things

can

be

of

types

A

B

or

C.

Suppose

that

in

the

remote

execution

of

an

operation

do

-LRB-

List

of

things

lot

-RRB-

the

programmer

knows

that

only

A

things

will

be

accessed

-LRB-

for

example

Thing-objects

will

be

invoked

for

method

M

which

is

empty

for

all

but

for

A

Thing-objects

-RRB-

We

can

optimize

the

parameter

passing

by

defining

List_of_thingsThingA_thingB_thingC_thingA_rest_graphB_rest_graphC_rest

graph

Figure

Graph

for

a

list

of

things

the

following

interface

SERVER

Xpto

OPERATION

void

do

-LRB-

IN

lot

-RRB-

lot

TRAVERSE

FROM

VIA

A

Thing

The

effect

of

this

optimization

traversal

is

that

only

the

A

rest

graph

will

be

copied

to

the

remote

context

Marshaling

Routines

Based

on

the

graph

directives

given

by

the

programmer

the

compiler

generates

optimized

marshaling

code

Below

we

show

the

code

associated

with

the

GOOP

specifications

in

Fig.

in

pseudo-code

search

book

params

in

-LRB-

inbuf

key

n

-RRB-

key.pack

unpack

-LRB-

inbuf

-RRB-

n.pack

unpack

-LRB-

inbuf

-RRB-

search

book

params

out

-LRB-

outbuf

book

-RRB-

book.pack

unpack

search

book

-LRB-

outbuf

-RRB-

pack

unpack

search

book

-LRB-

outbuf

-RRB-

Book

author.pack

unpack

search

book

-LRB-

outbuf

-RRB-

title.pack

unpack

search

book

-LRB-

outbuf

-RRB-

isbn.pack

unpack

search

book

-LRB-

outbuf

-RRB-

pack

unpack

search

book

-LRB-

outbuf

-RRB-

Author

a.pack

unpack

-LRB-

outbuf

-RRB-

pack

unpack

search

book

-LRB-

outbuf

-RRB-

Title

t.pack

unpack

-LRB-

outbuf

-RRB-

pack

unpack

search

book

-LRB-

outbuf

-RRB-

ISBN

n.pack

unpack

-LRB-

outbuf

-RRB-

The

exact

implementation

of

the

packing

and

unpacking

of

parameters

depends

on

the

underlying

support

for

remote

calls

The

pseudo-code

shown

above

represents

the

generic

algorithm

for

marshaling

the

parameters

in

the

search

book

operation

and

it

suggests

that

the

marshaling

of

an

object

depends

on

the

operation

that

is

being

invoked

Constraints

on

Graph

Directives

When

generating

an

object-oriented

program

from

the

two

building

blocks

as

shown

in

Fig.

we

require

the

traversal

specifications

to

be

compatible

and

consistent

with

the

class

graph

and

we

require

the

traversal

graph

to

be

a

subclass-invariant

subgraph

of

the

class

graph

The

notions

of

compatibility

consistency

and

subclass-invariance

are

tied

to

the

concept

of

traversal

graph

which

represents

the

set

of

paths

to

be

traversed

Intuitively

they

can

be

understood

as

follows

ffl

Compatibility

the

traversal

graph

contains

at

least

one

path

from

source

to

target

ffl

Consistency

the

traversal

graph

contains

no

more

paths

than

the

ones

specified

by

the

traversal

directives

ffl

Subclass-invariance

if

classes

A

and

B

are

in

the

traversal

graph

and

B

is

a

subclass

of

A

in

the

class

graph

then

the

traversal

graph

must

include

the

inheritance

edge

that

goes

from

A

to

B

These

three

conditions

ensure

the

correctness

of

the

marshaling

routines

in

the

sense

that

the

resulting

marshaling

code

matches

the

intentions

behind

the

traversal

specification

If

consistency

or

subclass-invariance

are

violated

the

marshaling

routines

will

accept

object

graphs

that

go

beyond

the

programmer

's

intentions

This

incorrectness

however

does

not

restrict

in

any

way

the

correct

execution

of

the

invoked

operation

it

simply

does

n't

implement

the

optimization

exactly

as

the

programmer

wants

Compatibility

is

the

simpliest

of

these

rules

and

it

can

be

checked

very

easily

The

other

two

rules

are

more

complex

but

there

are

also

algorithms

which

we

have

implemented

to

detect

if

they

are

violated

or

not

We

will

not

go

into

details

here

since

the

detailed

explanation

of

these

three

rules

can

be

found

in

-LSB-

-RSB-

Encapsulation

and

Open

Implementations

Adaptive

parameter

passing

is

an

application-oriented

optimization

for

parameter

passing

in

remote

invocations

We

assume

the

optimizations

rely

on

the

knowledge

of

the

programmers

about

the

application

they

are

developing

For

example

the

interface

defined

in

Fig.

was

based

on

the

knowledge

that

the

method

short

print

used

only

specific

parts

of

the

Book

object

This

suggests

that

the

principle

of

encapsulation

is

broken

In

order

to

do

optimizations

the

programmers

must

know

how

the

operations

are

implemented

which

parts

of

the

objects

they

need

This

may

be

viewd

as

a

serious

limitation

for

the

optimization

we

propose

because

it

breaks

the

fundamental

abstraction

of

object-oriented

programming

-LCB-

encapsulation

With

respect

to

this

issue

we

include

our

approach

in

the

line

of

research

for

open

implementations

as

recently

proposed

by

Kiczales

-LSB-

-RSB-

and

many

other

researchers

The

abstraction

and

encapsulation

principles

of

object-oriented

programming

languages

are

very

appealing

for

developing

applications

but

we

think

that

there

is

a

basic

discrepancy

between

those

principles

and

the

reality

of

day-to-day

programming

where

performance

is

an

issue

Therefore

and

for

the

particular

problem

of

parameter

passing

in

remote

invocations

we

open

the

implementation

that

is

we

maintain

all

the

abstractions

for

the

class

implementations

but

we

allow

the

programmer

to

perform

some

optimizations

at

a

higher

level

of

abstraction

and

according

to

his/her

knowledge

of

the

implementations

In

the

adaptive

optimization

we

propose

the

programmer

is

not

confronted

with

implementation

details

all

the

time

and

the

optimization

scheme

is

made

using

a

very

simple

and

intuitive

graph

language

to

define

object

structure

We

think

the

simplicity

of

our

solution

and

the

benefits

that

it

brings

in

terms

of

performance

justifies

the

violation

of

the

encapsulation

principle

Concluding

Remarks

Performance

Adaptive

parameter

passing

is

an

application-oriented

alternative

to

any

default

operating

system

's

policy

regarding

the

copying

of

objects

from

one

context

to

another

We

view

it

as

an

application

optimization

that

reduces

remote

invocation

time

and

garbage

collection

and

minimizes

object

replication

Adaptiveness

Adaptiveness

comes

from

two

different

perspectives

On

the

one

hand

from

the

execution

point

of

view

parameter

passing

on

remote

calls

adapts

optimally

to

the

application

particular

needs

On

the

other

hand

from

the

software

evolution

point

of

view

the

fact

that

graph

directives

identify

a

subgraph

without

referring

to

all

of

its

vertices

and

edges

makes

those

directives

robust

and

adaptable

to

changes

in

the

class

organization

Scalability

Although

we

have

only

experimented

with

small

to

medium

size

applications

we

think

adaptive

parameter

passing

will

scale

to

very

large

distributed

applications

First

of

all

we

strongly

believe

that

only

a

small

percentage

of

classes

in

any

distributed

application

will

serve

to

instantiate

objects

which

are

remotely

accessible

-LRB-

servers

-RRB-

Second

the

complexity

introduced

by

graph

directives

is

minimal

the

graph

language

is

extremely

simple

and

it

is

only

used

in

situations

that

require

optimization

Open

Problems

At

this

point

we

are

not

addressing

the

issue

of

what

happens

when

either

the

client

-LRB-

for

OUT

parameters

-RRB-

or

the

service

provider

-LRB-

for

IN

parameters

-RRB-

need

more

of

the

object

than

what

's

specified

in

the

optimization

traversal

As

far

as

this

discussion

goes

we

can

either

assume

that

the

underlying

system

has

some

mechanism

of

fetching

the

missing

parts

or

impose

that

the

traversal

specification

be

correct

in

the

sense

that

it

must

include

the

object

's

subgraph

that

will

actually

be

used

in

the

remote

context

There

is

however

one

important

aspect

that

must

be

considered

which

is

related

to

the

mode

of

the

parameters

For

IN

parameters

the

programmers

can

make

good

optimizations

since

they

know

what

parts

of

the

IN

objects

will

be

used

in

the

implementation

of

the

services

But

for

OUT

parameters

the

programmers

of

the

server

classes

may

not

know

which

parts

of

the

objects

will

be

used

by

the

clients

and

this

may

be

an

obstacle

for

optimization

Prototype

Implementation

We

have

developed

a

small

prototype

for

GOOP

which

consists

of

a

compiler

taking

as

inputs

a

class

graph

the

class

implementations

and

the

parameters

specifications

for

the

remote

services

The

result

is

a

C++

program

together

with

proxy

classes

and

stub

routines

All

the

extra

code

for

remote

method

invocation

is

specific

for

the

underlying

system

Currently

we

are

using

GOOP/RT

a

very

simple

system

developed

for

the

purpose

of

testing

these

ideas

GOOP/RT

is

an

object

server

that

provides

a

remote

invocation

service

on

C++

objects

executing

on

the

same

address

space

it

uses

the

IK

Remote

Procedure

Call

library

-LSB-

-RSB-

and

runs

on

top

of

UNIX

Related

Work

This

work

is

integrated

in

a

much

larger

project

that

targets

the

engineering

of

distributed

objectoriented

applications

-LSB-

-RSB-

Therefore

it

shares

the

same

conceptual

ideas

and

the

same

implementation

strategy

of

synchronization

patterns

-LSB-

-RSB-

It

also

shares

the

basic

class

graphs

and

graph

algorithms

with

Demeter

-LSB-

-RSB-

The

formal

semantics

of

graph

directives

is

based

on

the

work

by

Palsberg

et

al.

-LSB-

-RSB-

The

motivation

behind

this

work

is

basically

the

same

as

the

motivation

for

reflective

systems

-LSB-

-RSB-

and

open

implementations

-LSB-

-RSB-

Both

lines

of

research

call

for

application-oriented

customizations

of

the

underlying

system

In

reflective

systems

that

customization

is

made

by

meta-objects

which

control

the

access

to

the

the

base-level

objects

and

can

perform

several

kinds

of

meta

functions

such

as

synchronization

of

processes

or

migration

of

objects

In

particular

the

work

in

-LSB-

-RSB-

describes

a

mechanism

for

object

location

control

using

meta-level

programming

that

has

some

similarities

with

adaptive

parameter

passing

In

the

cited

work

method

invocations

may

result

in

migration

of

objects

between

contexts

that

is

in

moving

objects

from

one

context

to

another

and

the

policy

-LCB-

not

the

mechanism

-LCB-

for

migration

is

implemented

by

metaobjects

not

by

some

default

system

's

algorithm

However

in

the

reflective

systems

literature

we

did

n't

find

any

references

to

the

particular

problem

of

parameter

passing

optimization

We

believe

that

such

optimizations

can

also

be

made

in

reflexive

systems

but

they

will

have

to

include

some

mechanism

for

describing

groups

of

classes

at

the

meta-level

The

work

described

in

-LSB-

-RSB-

uses

Composition

Filters

to

abstract

object

interactions

in

a

distributed

environment

through

first

class

objects

called

Abstract

Communication

Types

-LRB-

ACT

's

-RRB-

This

work

also

calls

for

reflection

upon

message

send

's

and

receive

's

so

that

ACT

's

be

able

to

implement

coordinated

behavior

constraint

solvers

distributed

algorithms

etc.

The

implementation

of

the

Sina

language

for

distributed

computation

always

passes

parameters

by

copying

them

to

the

remote

contexts

However

no

reference

is

made

in

the

literature

of

Composition

Filters

to

any

possible

optimization

of

the

copying

process

In

fact

the

prototype

proved

to

be

very

inefficient

and

they

are

considering

another

implementation

that

uses

pass-by-global-reference

with

optimizations

being

made

by

the

compiler

whenever

Our

work

also

has

commonalities

with

work

on

a

very

different

line

of

research

which

consists

of

the

object-oriented

analysis

and

design

methodologies

Most

of

the

methodologies

presented

so

far

are

conversation

with

members

of

the

Composition

Filters

research

team

based

on

graphs

of

objects

or

classes

that

describe

object

interactions

at

the

design

phase

Examples

are

the

Booch

method

-LSB-

-RSB-

OMT

-LSB-

-RSB-

Objectory

-LSB-

-RSB-

and

many

others

GOOP

class

graphs

can

be

seen

as

design

graphs

but

we

use

them

directly

as

program

text

Design

methodologies

usually

do

n't

consider

any

optimizations

of

the

applications

The

adaptive

parameter

passing

scheme

proposed

in

this

paper

handles

optimization

at

a

very

high

level

of

abstraction

so

that

it

could

be

considered

as

part

of

the

design

of

distributed

applications

Conclusions

All

the

solutions

proposed

so

far

for

the

problem

of

parameter

passing

in

distributed

object-oriented

applications

delegate

to

the

operating

system

the

responsibility

of

copying

the

objects

between

contexts

In

the

absence

of

any

semantic

knowledge

about

the

applications

the

best

the

underlying

system

can

do

is

either

to

copy

the

entire

object

graph

which

is

reachable

from

the

parameter

objects

or

to

implement

some

generic

algorithm

that

tries

to

optimize

the

number

of

objects

to

be

copied

In

any

case

the

result

can

never

be

optimal

for

all

applications

and

there

may

be

severe

performance

losses

due

to

either

copying

in

excess

-LCB-

parts

of

the

object

graph

which

will

never

be

accessed

by

the

remote

context

-LCB-

or

copying

too

little

-LCB-

extra

messages

will

be

necessary

We

have

presented

an

adaptive

graph-based

solution

to

the

problem

of

parameter

passing

in

distributed

object-oriented

applications

Our

solution

makes

use

of

graph-directives

written

by

the

programmer

for

the

purpose

of

optimizing

the

amount

of

objects

which

are

copied

between

contexts

Graph

directives

are

specified

in

a

high

level

language

that

describes

subgraphs

of

classes

without

referring

to

all

of

them

The

resulting

parameter

passing

scheme

is

adaptable

to

changes

in

the

class

organization

and

performance

can

be

made

optimal

for

each

particular

application

Acknowledgements

I

would

like

to

thank

all

members

of

the

Demeter

research

team

at

Northeastern

University

for

their

valuable

comments

on

applying

the

concepts

of

Adaptive

Software

to

distributed

applications

In

particular

Professor

Karl

Lieberherr

for

his

inspiring

remarks

and

his

careful

revision

of

this

paper

Many

thanks

to

Lodewijk

Bergmans

for

his

input

on

Composition

Filters

I

also

would

like

to

thank

the

members

of

the

IK

research

group

at

INESC

Portugal

for

making

the

IK

RPC

available

to

GOOP/RT

References

-LSB-

-RSB-

M.

Aksit

K.

Wakita

J.

Bosch

L.

Bergmans

and

A.

Yonezawa

Abtracting

Object

Interactions

Using

Compositions

Filters

In

Guerraoui

Nierstrasz

and

Riveill

editors

ECOOP

Workshop

on

Object-Based

Distributed

Programming

pages

-LCB-

Springer-Verlag

-LSB-

-RSB-

J.

K.

Bennet

The

Design

and

Implementation

of

Distributed

Smalltalk

In

OOPSLA

Proceedings

pages

-LCB-

Orlando

Florida

October

-LSB-

-RSB-

Lodewijk

Bergmans

Mehmet

Aksit

Ken

Wakita

and

Akinori

Yonezawa

An

object-oriented

model

for

extensible

concurrent

systems

the

composition-filters

approach

Memoranda

Informatica

-LRB-

-RRB-

December

-LSB-

-RSB-

A.D.

Birrell

and

B.J.Nelson

Implementing

remote

procedure

calls

Technical

Report

Xerox

October

-LSB-

-RSB-

Grady

Booch

Object-Oriented

Design

With

Applications

Benjamin/Cummings

Publishing

Company

Inc.

-LSB-

-RSB-

Mark

Day

Object

Clusters

May

Be

Better

Than

Pages

In

Workshop

on

Workstations

Operating

Systems

pages

-LCB-

Napa

California

October

-LSB-

-RSB-

Margaret

Ellis

and

Bjarne

Stroustrup

The

Annotated

C++

Reference

Manual

Addison-Wesley

Reading

Massachusetts

-LSB-

-RSB-

Svend

FrOElund

and

Gul

Agha

A

language

framework

for

multi-object

coordination

In

Oscar

Nierstrasz

editor

Lecture

Notes

in

Computer

Science

pages

-LCB-

ECOOP

SpringerVerlag

July

-LSB-

-RSB-

Sabine

Habert

Laurence

Mosseri

and

Vadim

Abrossimov

COOL

Kernel

Support

for

ObjectOriented

Environments

In

OOPSLA

ECOOP

Proceedings

pages

-LCB-

Ottawa

Canada

October

-LSB-

-RSB-

Walter

L.

H?ursch

and

Cristina

V.

Lopes

Separation

of

Concerns

Technical

Report

Northeastern

University

Boston

USA

February

-LSB-

-RSB-

Ivar

Jacobson

Mangus

Christerson

Patrik

Jonsson

and

Gunnar

Overgaard

Object-Oriented

Software

Engineering

A

Use

Case

Driven

Approach

ACM

Press

Addison-Wesley

-LSB-

-RSB-

Eric

Jul

Henry

Levy

Norman

Hutchinson

and

Andrew

Black

Fine-Grained

Mobility

in

the

Emerald

System

ACM

Transactions

on

Computer

Systems

-LRB-

-RRB-

-LCB-

february

-LSB-

-RSB-

Gregor

Kiczales

Towards

a

new

Model

of

Abstraction

in

Software

Engineering

In

Proceedings

of

the

Int

l

Workshop

on

New

Models

for

Software

Archtecture

Reflection

and

Meta-level

Architecture

November

-LSB-

-RSB-

Karl

J.

Lieberherr

Ignacio

Silva-Lepe

and

Cun

Xiao

Adaptive

object-oriented

programming

using

graph-based

customization

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

May

-LSB-

-RSB-

Karl

J.

Lieberherr

and

Cun

Xiao

Formal

Foundations

for

Object-Oriented

Data

Modeling

IEEE

Transactions

on

Knowledge

and

Data

Engineering

-LRB-

-RRB-

-LCB-

June

-LSB-

-RSB-

Barbara

Liskov

Distributed

Programming

in

Argus

Communications

of

the

ACM

pages

-LCB-

March

-LSB-

-RSB-

Klaus-Peter

L?ohr

Concurrency

annotations

for

reusable

software

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

September

-LSB-

-RSB-

Cristina

V.

Lopes

and

Karl

Lieberherr

Abstracting

process-to-function

relations

in

concurrent

object-oriented

applications

In

Mario

Tokoro

editor

Lecture

Notes

in

Computer

Science

pages

-LCB-

Bologna

Italy

July

ECOOP

Springer-Verlag

-LSB-

-RSB-

Cristina

Videira

Lopes

IK

RPC

User

's

and

Reference

Manuals

INESC

Lisboa

Portugal

March

-LSB-

-RSB-

Pattie

Maes

Concepts

and

Experiments

in

Cmputational

Reflexion

In

Proceedings

of

ACM

OOPSLA

pages

-LCB-

-LSB-

-RSB-

H.

Masuhara

S.

Matsuoka

T.

Watanabe

and

A.

Yonezawa

Object-oriented

concurrent

reflective

languages

can

be

implemented

efficiently

In

Andreas

Paepcke

editor

OOPSLA

pages

-LCB-

Vancouver

Canada

October

ACM

Press

-LSB-

-RSB-

Hideaki

Okamura

and

Yutaka

Ishikawa

Object

Location

Control

Using

Meta-level

Programming

In

Mario

Tokoro

editor

Lecture

Notes

in

Computer

Science

pages

-LCB-

Bologna

Italy

July

ECOOP

Springer-Verlag

-LSB-

-RSB-

OMG

The

Common

Object

Request

Broker

architecture

and

specification

December

-LSB-

-RSB-

Jens

Palsberg

Cun

Xiao

and

Karl

Lieberherr

Efficient

implementation

of

adaptive

software

ACM

Transactions

on

Programming

Languages

and

Systems

-LSB-

-RSB-

James

Rumbaugh

Michael

Blaha

William

Premerlani

Frederick

Eddy

and

William

Lorensen

Object-Oriented

Modeling

and

Design

Prentice

Hall

-LSB-

-RSB-

Ignacio

Silva-Lepe

Walter

H?ursch

and

Greg

Sullivan

A

Demeter/C

Report

C++

Report

SIGS

Publication

February

-LSB-

-RSB-

Manolis

Tsangaris

and

Jeffrey

Naughton

On

the

performance

of

object

clustering

techniques

In

Michael

Stonebraker

editor

ACM

SIGMOD

Int

l

Conference

on

Management

of

Data

pages

-LCB-

ACM

Press

-LSB-

-RSB-

Cun

Xiao

Adaptive

Software

Automatic

Navigation

Through

Partially

Specified

Data

Structures

PhD

thesis

Northeastern

University

A

Grammar

for

GOOP

Graph

Directives

hDirectiveExpressioni

from

hFixedVertexi

-LSB-

hPathConstraintExpressioni

-RSB-

f

via

hVertexSelectori

-LSB-

hPathConstraintExpressioni

-RSB-

g

-LSB-

-LRB-

to

hVertexSelectori

-LSB-

hPathConstraintExpressioni

-RSB-

-RRB-

-LRB-

to-stop

hVertexSelectori

-RRB-

-RSB-

hPathConstraintExpressioni

-LRB-

through

hEdgePatterni

f

hEdgePatterni

g

-RRB-

-LRB-

bypassing

hEdgePatterni

f

hEdgePatterni

g

-RRB-

hVerticesEdgePatternsi

hVertexSelectori

-LRB-

hEdgePatterni

f

hEdgePatterni

g

-RRB-

hEdgePatterni

hConcreteEdgePatterni

hAbstractEdgePatterni

hCollectionEdgePatterni

hInheritanceEdgePatterni

hConcreteEdgePatterni

hVertexSelectori

hLabelSelectori

hVertexSelectori

hAbstractEdgePatterni

hVertexSelectori

hVertexSelectori

hCollectionEdgePatterni

hVertexSelectori

hVertexSelectori

hInheritanceEdgePatterni

hVertexSelectori

hVertexSelectori

hVertexSelectori

hAnyVertexi

hFixedVertexi

hVertexSeti

hAnyVertexi

hFixedVertexi

identifier

hVertexSeti

-LCB-

hFixedVertexi

f

hFixedVertexi

g

-RCB-

hLabelSelectori

hAnyEdgeLabeli

hFixedEdgeLabeli

hLabelSeti

hAnyEdgeLabeli

hLabelSeti

-LCB-

hFixedEdgeLabeli

f

hFixedEdgeLabeli

g

-RCB-

hFixedEdgeLabeli

identifier

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 B 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 B I O O O O O O O O O O B 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

adaptiveness
distribution
open implementations
remote invocation


SFU-CMPT-TR

Resolving

URNs

with

Java

and

JavaScript

Serban

Tatu

and

Marius

Scurtescu

Simon

Fraser

University

Burnaby

B.C.

Canada

-LCB-

statu

mas

-RCB-

@cs

sfu.ca

Abstract

This

paper

presents

a

solution

allowing

authors

of

HTML

documents

to

make

use

of

Uniform

Resource

Names

-LRB-

URNs

-RRB-

instead

of

Uniform

Resource

Locators

-LRB-

URLs

-RRB-

We

describe

the

design

and

implementation

of

a

client-server

architecture

for

URN

resolution

based

on

Java

applets

and

CORBA

servers

The

process

is

carried

out

transparently

for

the

user

of

such

documents

by

a

scheme

using

JavaScript

This

scheme

takes

over

the

resolution

of

links

in

the

browser

and

redirects

it

to

the

client

applet

which

in

turn

obtains

the

resolution

information

from

the

CORBA

server

The

main

advantage

of

this

approach

is

the

easiness

of

integration

with

the

current

browser

technology

pages

containing

URN

's

can

run

in

any

browser

supporting

Java

and

JavaScript

Introduction

The

de-facto

standard

for

naming

resources

in

the

Internet

world

today

is

the

Uniform

Resource

Locator

-LRB-

URL

-RRB-

URLs

designate

physical

locations

for

documents

represented

in

various

formats

which

are

to

be

delivered

to

browsers

by

HTTP

servers

There

are

numerous

problems

associated

with

the

use

of

URLs

and

the

fix

for

these

problems

is

subject

to

ongoing

research

by

different

scientific

communities

The

commonly

adopted

scheme

is

the

URN

model

in

which

the

names

for

resources

do

not

contain

explicit

information

about

their

location

thus

offering

persistence

to

the

documents

they

identify

This

paper

presents

an

approach

to

the

problem

of

URN

resolution

of

URNs

embedded

in

HTML

documents

that

exploits

the

power

of

Java

and

JavaScript

We

have

built

a

prototype

resolution

server

that

allows

authors

of

documents

under

its

jurisdiction

to

use

URNs

instead

of

URLs

in

their

documents

When

a

document

is

loaded

into

a

Web

browser

the

links

will

be

automatically

mapped

to

actual

URLs

when

the

user

attempts

to

follow

them

The

advantage

of

this

approach

is

that

the

documents

will

no

longer

be

dependent

on

their

location

and

will

be

able

to

move

freely

around

the

Web

without

changing

their

names

provided

the

resolution

scheme

is

informed

about

the

move

The

resolution

part

of

the

scheme

relies

on

the

use

of

a

distributed

network

of

CORBA

servers

that

export

the

necessary

interfaces

for

mapping

of

the

URNs

into

resolution

information

This

resolution

information

does

not

necessarily

have

to

be

in

the

form

of

URLs

although

this

was

the

approach

used

to

validate

our

implementation

The

servers

find

each

other

using

the

CORBA

Naming

Service

-LSB-

-RSB-

which

allows

them

to

be

located

anywhere

on

the

net

The

following

scenario

illustrates

the

behavior

of

the

resolution

service

and

of

the

documents

it

serves

An

information

provider

-LRB-

e.g.

a

university

library

-RRB-

has

made

available

an

infostructure

consisting

of

a

hierarchy

of

hyperlinked

HTML

documents

An

author

of

a

document

-LRB-

e.g.

a

professor

publishing

a

technical

report

-RRB-

will

store

the

document

somewhere

in

the

hierarchy

Upon

storing

the

document

a

URN

is

issued

for

it

-LRB-

a

unique

persistent

string

conforming

to

the

URN

syntax

-LSB-

-RSB-

and

requirements

-LSB-

-RSB-

-RRB-

The

registration

information

will

be

stored

in

a

database

that

allows

mappings

from

URNs

to

URLs

and

vice-versa

As

URNs

are

only

being

issued

upon

request

not

all

the

URLs

in

the

infostructure

will

get

to

be

represented

by

URNs

The

maintainers

of

the

infostructure

will

also

run

a

special

program

that

replaces

all

the

registered

URLs

and

unmapped

URNs

in

the

document

with

JavaScript

function

calls

that

take

the

URNs

as

parameters

and

return

the

resolution

information

The

replacement

service

is

provided

as

an

added

convenience

for

those

authors

who

choose

not

to

quote

URNs

in

their

work

or

for

already

existing

documents

AWeb

browser

loads

the

page

containing

the

technical

report

and

attempts

to

follow

a

link

It

is

here

that

the

resolution

service

comes

into

action

the

JavaScript

function

will

call

upon

an

applet

that

queries

the

server

for

the

mapping

of

the

URN

If

for

instance

the

resolution

information

consists

of

a

URL

the

applet

will

force

a

load

of

the

document

into

the

browser

The

user

of

the

browser

is

ideally

unaware

of

the

resolving

process

charter

of

the

URN

Working

Group

can

be

found

at

Internet

Engineering

Task

Force?s

home

page

is

available

at

The

URN

Framework

The

URN

framework

is

described

in

a

series

of

documents

produced

by

the

URN

Working

of

the

This

section

is

provided

in

order

to

establish

the

common

terms

and

eliminate

confusion

about

the

exact

tasks

each

module

in

our

prototype

is

supposed

to

accomplish

The

keyword

terms

appear

in

italics

The

URN

syntax

as

documented

in

-LSB-

-RSB-

is

as

follows

urn

<nid>

<nss>

where

urn

is

an

identifier

establishing

that

this

is

a

URN

<nid>

naming

authority

id

This

is

a

name

assigned

to

the

name-issuing

authority

For

instance

in

the

world

of

printed

information

there

are

naming

schemes

such

as

ISBN

ISSN

or

SICI

URNs

assigned

by

these

authorities

could

be

like

urn

isbn

<nss>

namespace

specific

string

This

is

a

unique

string

within

a

namespace

-LRB-

specified

by

the

<nid>

part

-RRB-

that

identifies

the

object

In

the

above

example

the

<nss>

part

is

the

string

The

URN

Resolution

Information

There

are

two

types

of

information

that

can

be

obtained

through

resolution

location

information

and

characteristics

Location

information

can

be

in

the

form

of

a

URL

or

a

list

of

URLs

-LRB-

if

the

document

is

replicated

-RRB-

while

the

characteristics

take

the

form

of

URCs

-LRB-

Uniform

Resource

Characteristics

-RRB-

For

this

project

we

will

assume

that

the

URC

consists

of

a

set

of

string

pairs

describing

different

attributes

of

the

document

The

URN

Resolution

Process

There

are

two

parties

involved

in

the

resolution

process

A

Resolver

Discovery

Service

-LRB-

RDS

-RRB-

It

is

the

white

pages

of

the

URN

scheme

Given

a

URN

it

locates

a

resolver

that

is

able

to

return

the

requested

information

The

RDS

is

a

distributed

system

that

passes

around

the

<nid>

part

of

the

URN

among

its

different

nodes

until

a

node

is

found

that

knows

an

appropriate

resolver

A

Resolver

This

is

the

service

that

knows

how

to

handle

the

<nss>

part

of

the

URN

It

may

provide

the

information

needed

all

by

itself

or

it

may

contact

a

child

resolver

-LRB-

the

<nss>

OREDO

UHJLVWU

ffFDQ?EH?GLVWULEXWHG

ffUHWXUQ?UXOH?RU

UHVROYHU?VHUYLFH?UHIHUHQFH

ffDSSO

UXOH?WR?GHWHUPLQH

VHUYHU

VHUYHU

ffUXOH

UHVROYHU

VHUYLFH

UHVROYHU

VHUYLFH

Figure

The

URN

Resolution

Process

part

may

be

hierarchical

itself

to

allow

different

naming

schemes

to

be

grandfathered

into

a

name

space

-RRB-

Given

this

background

information

the

resolution

process

goes

according

to

the

following

flowchart

-LSB-

-RSB-

Approaches

to

URN

Resolution

One

of

the

most

important

proposals

for

the

resolution

of

URNs

using

the

above

scheme

and

framework

is

-LSB-

-RSB-

The

system

proposed

there

would

use

DNS

for

generating

resolver

references

The

rules

for

used

for

discovering

the

resolvers

are

embedded

in

a

new

DNS

resource

record

called

NAPTR

-LRB-

Name

Authority

PoinTeR

-RRB-

These

rules

map

URN

strings

to

domain

names

The

contention

against

this

system

is

that

although

DNS

is

an

example

of

a

successful

distributed

system

its

use

for

identifying

networked

resources

in

addition

to

computer

systems

would

render

it

inefficient

since

the

number

of

resources

exceeds

by

far

the

number

of

systems

A

different

prototype

system

was

built

as

part

of

the

InfoMesh

initiative

-LSB-

-RSB-

This

system

is

implemented

as

a

large

distributed

database

using

replication

groups

as

its

nodes

The

replication

groups

consist

of

servers

responsible

for

resolving

parts

of

the

namespace

identifiers

The

replication

groups

are

arranged

in

a

B-Tree

structure

for

increased

look-up

efficiency

-LSB-

-RSB-

System

Architecture

Our

system

has

a

three-tiered

architecture

as

Fig.

shows

Grouped

by

tier

the

modules

are

as

follows

Client

Tier

It

consists

of

a

JavaScript

function

and

a

Java

applet

attached

to

the

document

loaded

into

the

browser

The

JavaScript

function

is

responsible

for

intercepting

the

user

's

clicks

on

the

links

and

forwarding

them

to

the

applet

The

applet

contacts

the

server

part

and

obtains

the

desired

mapping

for

the

URN

submitted

Server

Tier

It

consists

of

a

minimal

Resolver

Discovery

Service

-LRB-

RDS

-RRB-

in

the

form

of

a

server

implementing

the

SFU

naming

authority

responsible

for

receiving

the

mapping

requests

and

locating

an

appropriate

resolver

plus

the

set

of

resolver

servers

responsible

for

providing

the

desired

mapping

The

RDS

server

receives

a

request

from

the

Java

applet

locates

the

proper

resolver

passes

it

the

request

and

sends

the

result

back

to

the

applet

This

approach

deviates

from

the

recommendations

stated

in

-LSB-

-RSB-

in

that

the

RDS

server

acts

as

a

proxy

for

the

resolvers

by

passing

resolution

information

back

to

the

applet

We

introduced

this

deviation

for

performance

and

security

reasons

the

applet

makes

only

one

connection

instead

of

two

and

since

applets

by

default

can

connect

only

to

the

servers

they

come

from

we

avoid

security

problems

arising

when

the

resolvers

are

located

on

different

machines

than

the

RDS

server

Making

the

RDS

server

responsible

for

funneling

resolution

information

to

the

applet

does

not

impede

on

the

overall

performance

of

the

scheme

because

this

server

only

gets

hits

from

those

browsers

showing

documents

containing

resolution

applets

pointing

to

this

particular

server

Data

Tier

It

consists

of

a

database

or

any

other

form

of

persistent

storage

It

is

not

important

how

the

resolver

will

generate

the

results

for

the

mapping

-LRB-

if

it

does

not

need

a

storage

mechanism

then

this

tier

is

nonexistent

and

the

mapping

is

computed

by

the

resolver

-RRB-

-LRB-

:-LRB-

KLOG

-RRB-

ODW

-RRB-

LOH

Figure

System

Architecture

A

typical

interaction

goes

according

to

the

following

scenario

The

applet

receives

the

request

for

mapping

and

contacts

the

RDS

server

passing

it

the

URN

The

RDS

server

locates

an

appropriate

resolver

The

resolver

parses

the

<nss>

part

of

the

URN

and

sees

if

it

can

resolve

it

itself

or

it

has

to

contact

a

child

resolver

-LRB-

the

resolver

might

actually

consist

of

a

hierarchy

of

resolvers

-RRB-

The

<nss>

may

traverse

a

couple

of

resolvers

until

the

final

one

is

reached

The

final

resolver

computes

the

results

-LRB-

by

either

pulling

them

from

some

data

storage

or

computing

them

based

on

some

algorithm

-RRB-

Finally

the

results

arrive

back

at

the

RDS

server

which

passes

them

back

to

the

applet

causing

the

desired

page

to

be

loaded

Implementation

This

section

describes

the

implementation

of

the

system

and

how

its

components

communicate

There

are

four

components

the

JavaScript

code

the

resolution

applet

the

RDS

Server

and

the

resolver

The

Syntax

of

the

URNs

We

chose

to

have

a

namespace

for

SFU

with

two

subspaces

lib

and

cmpt

The

first

one

is

used

to

point

to

items

in

the

library

and

the

second

one

to

point

to

items

in

the

Computing

Science

department

The

format

of

the

lib

URN

is

sfu

lib

<code type>

<code>

where

<code type>

can

be

CN

-LRB-

Call

Number

-RRB-

ISBN

or

ISSN

and

specifies

the

type

of

the

<code>

<code>

the

code

of

the

pointed

item

semantic

specified

by

<code type>

The

format

of

the

cmpt

URN

is

sfu

cmpt

<type>

<code>

where

<type>

and

<code>

can

be

one

of

the

following

pairs

type

code

U-SFraser-CMPT-TR

year-number

U-SFraser-CMPT-MSc

user

id

U-SFraser-CMPT-PhD

user

id

HomePage

user

id

Examples

urn

sfu

lib/CN/QA

urn

sfu

urn

sfu

urn

sfu

cmpt/U-SFraser-CMPT

urn

sfu

cmpt/HomePage/statu

The

JavaScript

Code

Because

of

the

lack

of

support

for

URNs

in

current

browsers

we

decided

to

use

a

combination

of

JavaScript

and

Java

in

the

HTML

pages

using

URNs

Hyperlinks

will

be

implemented

as

usual

using

the

A

HREF

tags

but

JavaScript

is

used

to

intercept

a

click

on

these

links

resolve

the

associated

URN

to

a

URL

using

a

Java

applet

and

based

on

this

URL

fetch

the

specified

page

A

hyperlink

has

the

form

A

HREF

javascript

-LRB-

urn

-RRB-

anchor

text

</A>

When

the

user

follows

this

URN

hyperlink

the

-LRB-

-RRB-

function

gets

called

this

function

will

resolve

the

URN

by

calling

a

method

of

the

applet

and

loading

the

page

pointed

to

by

the

returned

URL

The

Resolution

Applet

Pages

augmented

with

support

for

URNs

contain

a

Java

applet

which

acts

as

a

URN

resolver

for

the

embedded

JavaScript

code

The

applet

uses

the

RDS

server

to

resolve

URNs

The

RDS

server

runs

on

the

same

machine

as

the

Web

Server

which

provided

the

page

containing

the

applet

In

this

way

there

are

no

security

concerns

regarding

the

communication

between

the

applet

and

the

RDS

Server

A

method

called

resolveURN

-LRB-

-RRB-

is

provided

in

the

applet

which

is

called

by

the

JavaScript

code

to

resolve

a

URN

The

argument

is

the

URN

to

be

resolved

and

the

return

value

is

the

corresponding

URL

if

any

The

applet

maintains

a

cache

with

resolved

URNs

and

it

first

tries

to

look

up

the

requested

URN

in

this

cache

If

the

lookup

results

in

a

miss

the

RDS

server

is

used

to

resolve

to

URN

The

caching

of

the

resolution

information

inside

the

applet

might

be

thought

not

to

be

a

very

fortunate

idea

since

the

applet

can

not

receive

invalidation

calls

from

the

server

However

in

practice

this

is

an

acceptable

loss

of

consistency

since

the

applets

are

expected

to

be

short-lived

The

RDS

Server

The

RDS

server

listens

in

an

infinite

loop

for

requests

from

resolution

applets

For

each

request

it

starts

a

new

thread

which

deals

with

the

request

The

request

is

parsed

and

a

reference

to

a

resolver

object

is

retrieved

from

the

cache

or

it

is

obtained

through

a

CORBA

name

binding

process

A

method

of

the

resolver

object

is

called

to

resolve

the

request

and

the

result

is

passed

back

to

the

applet

The

Resolver

It

consists

of

another

server

exporting

a

resolution

interface

Part

of

the

CORBA

IDL

code

is

given

below

module

UrnResolution

-LCB-

exception

declarations

typedef

sequence

<string>

StringList

a

generic

URC

type

struct

-LCB-

string

name

string

value

-RCB-

typedef

sequence

finally

the

resolver

itself

interface

UrnResolver

-LCB-

mapping

functions

StringList

-LRB-

in

string

urn

-RRB-

raises

-LRB-

UrnException

-RRB-

hughes.com.au

string

-LRB-

in

string

url

-RRB-

raises

-LRB-

UrnException

-RRB-

-LRB-

in

string

urn

-RRB-

raises

-LRB-

UrnException

-RRB-

generic

functions

to

get/set

server-specific

properties

such

as

cache

size

thread

pool

size

database

connections

etc.

void

setProperty

-LRB-

in

string

propName

in

string

propValue

-RRB-

raises

-LRB-

UrnServerException

-RRB-

string

getProperty

-LRB-

in

string

propName

-RRB-

raises

-LRB-

UrnServerException

-RRB-

notification

function

to

tell

the

object

to

invalidate

its

cached

data

void

clearState

-LRB-

-RRB-

raises

-LRB-

UrnServerException

-RRB-

-RCB-

-RCB-

How

exactly

the

methods

in

the

interface

are

implemented

is

dependent

upon

the

resolver

We

chose

a

resolver

service

that

relies

on

a

relational

database

for

the

storage

of

mappings

The

database

is

a

simple

engine

freely

available

on

the

Web

called

for

which

a

minimal

JDBC

driver

is

also

freely

The

resolver

keeps

an

internal

cache

and

a

pool

of

database

connection

to

minimize

the

hits

on

the

database

JavaScript

to

Resolution

Applet

Communication

The

JavaScript

function

doing

the

resolution

invokes

a

method

from

the

applet

resolveURN

-LRB-

-RRB-

passing

the

URN

to

be

resolved

as

a

string

and

the

return

value

is

a

string

representing

the

URL

if

the

resolution

succeeded

or

an

empty

string

otherwise

Resolution

Applet

to

RDS

Server

Communication

The

communication

between

the

applet

and

the

RDS

Server

is

done

using

sockets

Since

the

communication

protocol

is

very

simple

there

is

no

need

to

implement

the

communication

as

CORBA

remote

method

calls

-LRB-

making

the

applet

a

CORBA

client

requires

the

ORB

classes

to

be

loaded

into

the

browser

which

would

increase

the

time

needed

to

load

the

applet

-RRB-

When

the

applet

receives

a

request

from

the

JavaScript

code

it

creates

a

request

string

opens

a

socket

to

the

RDS

Server

sends

the

request

and

reads

the

result

The

result

is

parsed

and

passed

back

to

the

JavaScript

code

The

machine

running

the

RDS

Server

is

assumed

to

be

the

one

from

which

the

applet

was

downloaded

-LRB-

the

applet

code

base

-RRB-

The

communication

port

is

hard

coded

in

both

the

applet

and

the

RDS

Server

To

optimize

de

communication

between

the

applet

and

the

RDS

Server

the

socket

could

be

kept

open

by

the

applet

and

it

should

be

closed

only

by

the

RDS

Server

after

a

time-out

period

The

applet

s

home

page

can

be

found

at

should

check

then

if

the

socket

is

still

open

and

reopen

it

if

necessary

RDS

Server

to

Resolver

Communication

The

communication

between

the

RDS

Server

and

a

resolver

is

done

using

implementation

of

the

CORBA

standard

-LSB-

-RSB-

The

RDS

Server

parses

the

request

string

received

from

the

applet

and

loads

the

resolver

object

based

on

the

URN

<nid>

The

actual

communication

is

a

method

call

for

this

resolver

object

-LRB-

-RRB-

in

our

case

because

is

the

only

type

of

service

requested

by

the

applet

The

resolver

knows

how

to

handle

the

following

types

of

requests

-LRB-

more

types

are

defined

in

-LSB-

-RSB-

-RRB-

Type

Description

Resolver

Method

URN

to

URL

URN

to

URLs

URL

to

URN

URN

to

URC

The

argument

passed

to

the

resolver

object

is

the

actual

<nss>

string

and

the

response

is

a

list

of

URLs

If

there

are

more

than

one

URL

returned

by

the

resolver

then

the

first

one

using

the

HTTP

protocol

will

be

sent

to

the

applet

At

this

point

the

RDS

Server

returns

only

one

URL

for

each

URN

even

though

it

might

receive

a

list

of

URLs

from

the

resolver

It

could

return

a

list

to

the

applet

and

the

applet

in

combination

with

the

JavaScript

could

display

a

list

of

choices

as

an

HTML

page

Conclusion

This

project

proposes

a

viable

solution

enabling

authors

of

HTML

documents

to

embed

URNs

directly

into

their

HTML

documents

The

scheme

can

be

integrated

into

current

Web

spaces

and

does

not

require

changes

in

protocols

or

browser

technologies

The

system

does

not

resolve

the

broken

link

problem

-LRB-

it

is

not

the

purpose

of

URN

systems

to

do

that

-RRB-

but

it

provides

a

separation

of

resource

names

from

their

locations

thus

reducing

the

possibility

of

broken

links

and

allowing

for

better

maintenance

of

Web

spaces

We

are

assuming

that

the

maintainers

of

the

infostructure

will

periodically

update

the

resolution

records

with

the

latest

locations

of

the

documents

A

number

of

issues

arise

that

are

yet

to

be

studied

with

regard

to

the

performance

of

the

system

since

the

RDS

Server

acts

as

a

pipe

between

the

resolvers

and

the

resolution

applet

it

could

use

a

cache

to

store

resolver

references

associated

with

namespace

identifiers

However

if

this

solution

is

to

be

adopted

an

invalidation

mechanism

becomes

necessary

in

order

to

ensure

the

cache

consistency

because

the

resolver

references

might

become

invalid

or

worse

become

associated

with

a

different

namespace

This

can

be

solved

by

sending

the

full

URN

to

the

resolver

and

rely

on

it

to

check

the

appropriateness

of

the

namespace

identifier

Under

no

circumstances

should

the

RDS

Server

cache

URN

resolution

information

because

it

would

require

an

overly

complicated

and

inefficient

invalidation

scheme

References

-LSB-

-RSB-

Object

Management

Group

CORBA

Naming

Service

Specification

Available

at

ftp

-LSB-

-RSB-

Daniel

R.

and

Mealling

M.

Resolution

of

Uniform

Resource

Identifiers

using

the

Domain

Name

System

RFC

June

Available

at

ftp

-LSB-

-RSB-

Daniel

R.

A

Trivial

Convention

for

using

HTTP

in

URN

Resolution

RFC

June

Available

at

ftp

-LSB-

-RSB-

Moats

R.

URN

Syntax

RFC

May

Available

at

-LSB-

-RSB-

Orfali

R.

and

Harkey

D.

Client/server

programming

with

Java

and

CORBA

John

Wiley

Sons

ISBN

-LSB-

-RSB-

Orfali

R.

Harkey

D.

and

Edwards

J.

Instant

CORBA

John

Wiley

Sons

ISBN

-LSB-

-RSB-

Slottow

E.C.

Engineering

a

Global

Resolution

Service

M.Sc

Thesis

MIT

June

Available

at

s.pdf

-LSB-

-RSB-

Sollins

K.

and

Masinter

L.

Functional

Requirements

for

Uniform

Resource

Names

RFC

December

Available

at

-LSB-

-RSB-

Sollins

K.

Supporting

Longevity

in

an

Information

Infrastructure

Architecture

In

Proceedings

of

the

SIGOPS

European

Workshop

Available

at

-LSB-

-RSB-

Sollins

K.

Requirements

and

a

Framework

for

URN

Resolution

Systems

Internet

Draft

Available

at

eq-frame.html

-LSB-

-RSB-

Sollins

K.

Architectural

Principles

of

Uniform

Resource

Name

Resolution

RFC

Available

at

ftp

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 B 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 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 B 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 B O O O O O O O O O O O O B O O O O O O B 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 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 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 B 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 B 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 O O O O O O O O O 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 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 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 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 B 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 B O O O O O O O O O O B O O O O O O O O O B O O O O O O B 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 B O O B 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 B 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 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 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 B O O O O O B 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 B 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 B O B O O B O O O O B O B 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 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 B 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 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 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 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 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 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 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