Overview of lecture series Background Introduction to Szumo Case - - PowerPoint PPT Presentation

▶
overview of lecture series
SMART_READER_LITE
LIVE PREVIEW

Overview of lecture series Background Introduction to Szumo Case - - PowerPoint PPT Presentation

Mar 15, 2023 248 likes •822 views

Overview of lecture series Background Introduction to Szumo Case study Semantic and implementation details Related concurrency models Ongoing and future work Laser 2005 - Summer School on 1 Software Engineering Goal

slide-1
SLIDE 1

Laser 2005 - Summer School on Software Engineering 1

Overview of lecture series

♦ Background ♦ Introduction to Szumo ♦ Case study ♦ Semantic and implementation details ♦ Related concurrency models ♦ Ongoing and future work

slide-2
SLIDE 2

Laser 2005 - Summer School on Software Engineering 2

Goal

Validate the efficacy of Szumo to current software engineering practice

– Is Szumo sufficiently expressive to handle designs of complex systems? – Is Szumo effective in localizing synchronization concerns? – Can Szumo support use of modern OO design techniques (e.g. structural modeling notations, design patterns)?

slide-3
SLIDE 3

Laser 2005 - Summer School on Software Engineering 3

Approach

♦ Designed and implemented a multi-threaded OO web server

– Modeled after Apache – Exemplar of realistic multi-threaded OO design

♦ Tested extensibility/maintainability by adding different types of features

– Authentication – Dynamic content generation – Load balancing

slide-4
SLIDE 4

Laser 2005 - Summer School on Software Engineering 4

Overview of lecture series

♦ Background ♦ Introduction to Szumo ♦ Case study

– A contract-aware web server – Extension tasks

♦ Semantic and implementation details ♦ Related concurrency models ♦ Ongoing and future work

slide-5
SLIDE 5

Laser 2005 - Summer School on Software Engineering 5

Aside on a change in terminology

♦ Yesterday, I used processes and threads as synonyms ♦ Today, I need to distinguish between them

– Process : program running in its own data space (OS process) – Thread : locus of control within a process (lightweight “process”)

slide-6
SLIDE 6

Laser 2005 - Summer School on Software Engineering 6

Web server design: Motivating Example

Logging & Statistics Finalization Content Handlers Content Generation Encryption Libraries Authentication

slide-7
SLIDE 7

Laser 2005 - Summer School on Software Engineering 7

Web server design: Motivating Example

Logging & Statistics Finalization Content Handlers Content Generation Encryption Libraries Authentication web server main dispatches

slide-8
SLIDE 8

Laser 2005 - Summer School on Software Engineering 8

dispatches

Web server design: Motivating Example

Logging & Statistics Finalization Logging & Statistics Finalization Content Handlers Content Generation Content Handlers Content Generation Encryption Libraries Authentication Encryption Libraries Authentication web server main dispatches

slide-9
SLIDE 9

Laser 2005 - Summer School on Software Engineering 9

dispatches

Web server design: Motivating Example

Logging & Statistics Finalization Finalization Content Handlers Content Generation Content Generation Encryption Libraries Authentication Authentication web server main dispatches

slide-10
SLIDE 10

Laser 2005 - Summer School on Software Engineering 10

dispatches

Web server design: Motivating Example

Logging & Statistics Finalization Finalization Content Handlers Content Generation Content Generation Encryption Libraries Authentication Authentication web server main dispatches

slide-11
SLIDE 11

Laser 2005 - Summer School on Software Engineering 11

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-12
SLIDE 12

Laser 2005 - Summer School on Software Engineering 12

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-13
SLIDE 13

Laser 2005 - Summer School on Software Engineering 13

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-14
SLIDE 14

Laser 2005 - Summer School on Software Engineering 14

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-15
SLIDE 15

Laser 2005 - Summer School on Software Engineering 15

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-16
SLIDE 16

Laser 2005 - Summer School on Software Engineering 16

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-17
SLIDE 17

Laser 2005 - Summer School on Software Engineering 17

<<dispatches>>

Web server design: Motivating Example

f1: finalizer c1: content_generator a1: authenticator f2: finalizer c2: content_generator a2: authenticator : logger : content_handler : crypt : web_dispatcher <<process root>> r1: request_handler <<process root>> r2: request_handler <<process root>> :req_handler_pool <<dispatches>>

slide-18
SLIDE 18

Laser 2005 - Summer School on Software Engineering 18

Basic web-server design

REQUEST_HANDLER_POOL SESSION_MANAGER SESSION_OPERATION FINALIZER POST_PROCESSOR

prs prsr_l _list

CONTENT_DISPATCHER

hdlr_selected: BOOLEAN

CONTENT_HANDLER REQUEST_HANDLER

<< p proc rocess ess root > root >> te termin rminat atin ing: BOOLEA BOOLEAN content content_stage: B BOOLEA OOLEAN finish shin ing: B BOOLEA OOLEAN au auth th_st _stage: BO BOOLEAN AN . . . . . . dis ispat atche cher fin finalizer zer hand handler poo pool

{ curr_auth }

* * * *

{ terminating => pool, content_stage => dispatcher, . . . } finishing => finalizer,

AUTHENTICATOR VALIDATOR

cur curr_auth auth authent authenticato tor

*

INBOUND_SOCKET NAME_SERVICES

<< ext << exter ernal > al >>

LISTENER_SOCKET

sta start rt_up _up: BOOL BOOLEAN EAN conne connect ction ion

WEB_DISPATCHER

<< p proc rocess ess root > root >> sta start rt_r _requ equest st: B : BOOLEA OOLEAN poo pool lis liste tene ner

start_request => pool } { listener,

name name_svr

{ start_up=> name_svr}

SESSION

* *

auth_stage => authenticator,

auth_lis _list hand handler

*

{ hdlr_selected => handler }

pro processor essor

{ processor }

slide-19
SLIDE 19

Laser 2005 - Summer School on Software Engineering 19

Overview of lecture series

♦ Background ♦ Introduction to Szumo ♦ Case study

– A contract-aware web server – Extension tasks

♦ Semantic and implementation details ♦ Related concurrency models ♦ Ongoing and future work

slide-20
SLIDE 20

Laser 2005 - Summer School on Software Engineering 20

Extension tasks

♦ Task 1: Authentication

– Added authentication capability – Safely integrated library functions

♦ Task 2: Dynamic content generation

– Provided for user scripting in the same memory space as the web server

♦ Task 3: Load balancing

– Modified web server to dynamically adapt the number

  • f content generators as a function of load
slide-21
SLIDE 21

Laser 2005 - Summer School on Software Engineering 21

Extension tasks

♦ Task 1: Authentication

– Added authentication capability – Safely integrated library functions

♦ Task 2: Dynamic content generation

– Provided for user scripting in the same memory space as the web server

♦ Task 3: Load balancing

– Modified web server to dynamically adapt the number

  • f content generators as a function of load
slide-22
SLIDE 22

Laser 2005 - Summer School on Software Engineering 22

Task 1: Authentication

Purpose: Provide authentication capability

♦ PWD_VALIDATOR: invokes POSIX library’s “crypt” function to validate password ♦ DB_VALIDATOR: uses a third party database engine (which also invokes “crypt”) to authenticate user

VALIDATOR PWD_VALIDATOR DB_VALIDATOR

{ curr_auth }

AUTHENTICATOR

auth_list

*

curr_auth

Convention: We show existing classes and associations in blue and new ones in black

slide-23
SLIDE 23

Laser 2005 - Summer School on Software Engineering 23

char * crypt(…) { . . . } (static vars) bool auth(.. . . .crypt(…). . . } db_rec* query(…) . . . }

C Libraries

(static vars)

. . . . . . . . . a1:AUTHENTICATOR r1: request_handler . . . a2:AUTHENTICATOR r2: request_handler . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR

Problem:

C Libraries need not be thread safe

auth_stage auth_stage <<invokes>> . . . . . . <<invokes>> <<invokes>> <<modifies>>

♦ Example: crypt(…)

– May use static buffers to encrypt the key – Returns a pointer to a static buffer containing the result string

slide-24
SLIDE 24

Laser 2005 - Summer School on Software Engineering 24

Problem: C Libraries are not contract aware

♦ Cannot negotiate for synchronization units ♦ Cannot be negotiated for ♦ Are not protected against data races ♦ Partial solution: External synchronization units

– Szumo Eiffel wrapper for a library module – May be instantiated only once – Other units access library functions only through the singleton wrapper unit

slide-25
SLIDE 25

Laser 2005 - Summer School on Software Engineering 25

Design of VALIDATOR extension

VALIDATOR PWD_VALIDATOR DB_VALIDATOR

{ curr_auth }

AUTHENTICATOR

curr_auth

*

<<external>> CRYPT <<external>> DB_ENG

db_engine

{ db_engine }

crypt

{ crypt } { crypt }

crypt auth_list

slide-26
SLIDE 26

Laser 2005 - Summer School on Software Engineering 26

: db_engine . . . a1:AUTHENTICATOR r1: request_handler auth_stage . . . a2:AUTHENTICATOR r2: request_handler auth_stage . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR : crypt

char * crypt(…) { . . . } (static vars) bool auth(.. . . .crypt(…). . . } db_rec* query(…) . . . }

C Libraries

(static vars)

. . . . . . <<invokes>> <<modifies>> <<invokes>> . . .

Processes now correctly negotiate for exclusive access to library modules (via external units)

. . .

slide-27
SLIDE 27

Laser 2005 - Summer School on Software Engineering 27

: db_engine . . . a1:AUTHENTICATOR r1: request_handler auth_stage . . . a2:AUTHENTICATOR r2: request_handler auth_stage . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR : crypt

char * crypt(…) { . . . } (static vars) bool auth(.. . . .crypt(…). . . } db_rec* query(…) . . . }

C Libraries

(static vars)

. . . . . . <<modifies>> <<invokes>>

Processes now correctly negotiate for exclusive access to library modules (via external units) But …

. . . . . .

slide-28
SLIDE 28

Laser 2005 - Summer School on Software Engineering 28

Remaining Problems

♦ C modules can access one another directly

– E.g., calls to “crypt” are prevalent in other C libraries

  • SQL implementations, WWW password authentication

– As these calls bypass realm membership checks, this would make the application vulnerable to illegal accesses

♦ References to module-local data can escape from the module and vice versa

slide-29
SLIDE 29

Laser 2005 - Summer School on Software Engineering 29

Example: Illegal access vulnerability

If a designer does not know how the database engine implements authentication, she would not know to document the dependence between the external units, DB_ENG and CRYPT.

VALIDATOR PWD_VALIDATOR DB_VALIDATOR

{ curr_auth }

AUTHENTICATOR

auth_list

*

<<external>> CRYPT <<external>> DB_ENG

db_engine crypt

{ crypt } { db_engine }

curr_auth

slide-30
SLIDE 30

Laser 2005 - Summer School on Software Engineering 30

: db_engine . . . a1:AUTHENTICATOR r1: request_handler auth_stage . . . a2:AUTHENTICATOR r2: request_handler auth_stage . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR : crypt

char * crypt(…) { . . . } (static vars) bool auth(.. . . .crypt(…). . . } db_rec* query(…) . . . }

C Libraries

(static vars)

. . . . . . <<invokes>> <<modifies>> <<invokes>> <<invokes>>

This would allow an illegal access to crypt’s static buffer through db_engine’s call to auth(…)

. . . . . .

slide-31
SLIDE 31

Laser 2005 - Summer School on Software Engineering 31

Solution: Extend contract-awareness to library modules

♦ Two Levels of Wrapping

– Top layer: External synchronization unit

  • Translates Eiffel calls and data into C equivalents
  • Provides contract support

– Middle layer: C decorator module containing a wrapper function for each function in the C module

  • Checks for realm membership
  • Copies arguments and return values to prevent pointers from

escaping

– Bottom layer: Original C module

♦ Linker redirects all external calls to library functions to the corresponding wrapper function in the decorator module

slide-32
SLIDE 32

Laser 2005 - Summer School on Software Engineering 32

bool __wrap_auth(…){ . . .__real_auth(…). . . } (static vars) char * __wrap_crypt(…) . . .__real_crypt(…). . . } db_rec* __wrap_query(… . . .__real_query(…). . . } char * crypt(…) { . . . } (static vars)

CRYPT

<< external >> crypt(…): STRING

{ crypt }

crypt bool auth(…){ . . .crypt(…). . . } db_rec * query(… . . . }

Szumo C Decorator Modules C Library Modules

DB_ENG

<< external >> auth(…): BOOL query(...): DB_REC . . . (static vars)

. . . . . .

ext_unit ext_unit (static vars)

slide-33
SLIDE 33

Laser 2005 - Summer School on Software Engineering 33

: db_engine . . . a1:AUTHENTICATOR r1: request_handler auth_stage . . . a2:AUTHENTICATOR r2: request_handler auth_stage . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR : crypt

char * crypt(…) { . . . } (static vars) bool auth(…){ . . .crypt(…). . . } db_rec* query(…) . . . }

C Library Modules

(static vars)

. . . . . . <<invokes>> <<modifies>> <<invokes>>

C Decorator Modules

ext_unit ext_unit bool __wrap_auth(…){ . . .__real_auth(…). . . } (static vars) (static vars) char * __wrap_crypt(..) { . . .__real_crypt(…). . . } db_rec* __wrap_query(..) . . .__real_query(…). . . }

. . . <<invokes>> <<invokes>> . . . . . .

Legal access of crypt through db_eng

slide-34
SLIDE 34

Laser 2005 - Summer School on Software Engineering 34

: db_engine . . . a1:AUTHENTICATOR r1: request_handler auth_stage . . . a2:AUTHENTICATOR r2: request_handler auth_stage . . . . . . p: PWD_VALIDATOR d: DB_VALIDATOR : crypt

char * crypt(…) { . . . } (static vars) bool auth(.. . . .crypt(…). . . } db_rec* query(…) . . . }

C Library Modules

(static vars)

. . . . . . <<invokes>> <<modifies>> <<invokes>> <<invokes>>

C Decorator Modules

ext_unit ext_unit bool __wrap_auth(…){ . . .__real_auth(…). . . } (static vars) (static vars) char * __wrap_crypt(..) { . . .__real_crypt(…). . . } db_rec* __wrap_query(..) . . .__real_query(…). . . }

. . . <<invokes>> <<invokes>> . . . . . .

Access to crypt by r1 is prevented

slide-35
SLIDE 35

Laser 2005 - Summer School on Software Engineering 35

Writing an external synchronization unit

Constructor invokes wrapper’s initialization function For each C function, a wrapper function: ♦ Converts between Eiffel and C datatypes ♦ Invokes the corresponding library function

external synchronization class CRYPT . . . make is external "header: #include %"crypt_decorator.h%"" "body: crypt_initialize((void *)current);" end end . . . crypt( key, salt : STRING ) : STRING is external "header: #include <unistd.h>" "body: { char *key = szumo_str2cstr(_key);" "body: char *salt = szumo_str2cstr(_salt);" "body: return " "body: szumo_cstr2str(crypt(key, salt));" "body: }" end . . . end

slide-36
SLIDE 36

Laser 2005 - Summer School on Software Engineering 36

Writing an external synchronization unit

external synchronization class DB_ENG . . . feature crypt: CRYPT . . . make is do create crypt.make . . . end . . . concurrency crypt end

Additionally: If library module invokes external library functions

♦ Include a contract with the associated external unit(s)

slide-37
SLIDE 37

Laser 2005 - Summer School on Software Engineering 37

Writing a C decorator module is semi- automatic

Instantiate a decorator module template

/* Configuration section. */ static synch_unit* ext_unit; void init_decorator(synch_unit* u) { ext_unit = u; Declare Thread Local Vars; Other Initialization; } /* Wrapper section. */ result_t __wrap_func(t1 arg1, t2 arg2, ...) { result_t result; ASSERT IN REALM(ext_unit); Deep_Import_arg1(arg1); Deep_Import_arg2(arg2); ... result = __real_func(arg1, arg2, …); Deep_Export_result(result); return result; }

slide-38
SLIDE 38

Laser 2005 - Summer School on Software Engineering 38

Writing a C decorator module is semi- automatic

♦ ASSERT_IN_REALM(ext_unit)

– Raises an exception if the unit referenced by “ext_unit” is not in the realm of the process executing the macro

/* Configuration section. */ static synch_unit* ext_unit; void init_decorator(synch_unit* u) { ext_unit = u; Declare Thread Local Vars; Other Initialization; } /* Wrapper section. */ result_t __wrap_func(t1 arg1, t2 arg2, ...) { result_t result; ASSERT IN REALM(ext_unit); Deep_Import_arg1(arg1); Deep_Import_arg2(arg2); ... result = real_func(arg1, arg2, …); Deep_Export_result(result); return result; }

slide-39
SLIDE 39

Laser 2005 - Summer School on Software Engineering 39

Writing a C decorator module is semi- automatic

♦ Deep_Import_argn(argn)

– Copies argument into a decorator-local variable

/* Configuration section. */ static synch_unit* ext_unit; void init_decorator(synch_unit* u) { ext_unit = u; Declare Thread Local Vars; Other Initialization; } /* Wrapper section. */ result_t __wrap_func(t1 arg1, t2 arg2, ...) { result_t result; ASSERT IN REALM(ext_unit); Deep_Import_arg1(arg1); Deep_Import_arg2(arg2); ... result = real_func(arg1, arg2, …); Deep_Export_result(result); return result; }

slide-40
SLIDE 40

Laser 2005 - Summer School on Software Engineering 40

Writing a C decorator module is semi- automatic

♦ Deep_Export_argn_result(result)

– Copies argument into thread-local storage

/* Configuration section. */ static synch_unit* ext_unit; void init_decorator(synch_unit* u) { ext_unit = u; Declare Thread Local Vars; Other Initialization; } /* Wrapper section. */ result_t __wrap_func(t1 arg1, t2 arg2, ...) { result_t result; ASSERT IN REALM(ext_unit); Deep_Import_arg1(arg1); Deep_Import_arg2(arg2); ... result = real_func(arg1, arg2, …); Deep_Export_result(result); return result; }

slide-41
SLIDE 41

Laser 2005 - Summer School on Software Engineering 41

Writing a C decorator module is semi- automatic

♦ Declare Thread Local Variables

– For each function declared in an external unit that returns a reference to the library module’s static data

/* Configuration section. */ static synch_unit* ext_unit; void init_decorator(synch_unit* u) { ext_unit = u; Declare Thread Local Vars; Other Initialization; } /* Wrapper section. */ result_t __wrap_func(t1 arg1, t2 arg2, ...) { result_t result; ASSERT IN REALM(ext_unit); Deep_Import_arg1(arg1); Deep_Import_arg2(arg2); ... result = real_func(arg1, arg2, …); Deep_Export_result(result); return result; }

slide-42
SLIDE 42

Laser 2005 - Summer School on Software Engineering 42

Task 1: Summary

♦ Extended VALIDATOR with two concrete classes, both of which required third party library modules ♦ Developed a semi-automated method for making library modules contract aware ♦ Did not need to make any changes to existing web-server design

slide-43
SLIDE 43

Laser 2005 - Summer School on Software Engineering 43

Extension tasks

♦ Task 1: Authentication

– Added authentication capability – Safely integrated library functions

♦ Task 2: Dynamic content generation

– Provided for user scripting in the same memory space as the web server

♦ Task 3: Load balancing

– Modified web server to dynamically adapt the number

  • f content generators as a function of load
slide-44
SLIDE 44

Laser 2005 - Summer School on Software Engineering 44

Task 2: Dynamic content generation

♦ Purpose: Add a scripting facility for generating dynamic content ♦ Problem: Allow scripts to safely access web- server resources

– E.g., session data, library modules, etc.

♦ Solution:

– Implement web-server resources and script interpreters as synchronization units – Interpreters trigger contracts to negotiate for web- server resources on behalf of a script

slide-45
SLIDE 45

Laser 2005 - Summer School on Software Engineering 45

A scripting language

♦ User scripts are written in an extension of Lua

– A light-weight programming language designed for extending applications – Powerful meta-mechanisms allow for the definition of new Lua features

♦ The extension provides primitives for

– Accessing web-server resources – Declaring a script’s resource needs

slide-46
SLIDE 46

Laser 2005 - Summer School on Software Engineering 46

Accessing web-server resources

Extend Lua with resource proxies

– Lua objects that are visible to user scripts – Bound to web-server resources

mySession SESSION unit associated with the http request being serviced myCrypt External synchronization unit wrapping the POSIX crypt function and its static variables myNameservices External synchronization unit wrapping name services functions in the DNS library

Resource proxy Web-server resource

slide-47
SLIDE 47

Laser 2005 - Summer School on Software Engineering 47

Declaring a script’s resource needs

A new Lua instruction: acquire(r1, r2, …)

♦ Takes a variable number

  • f resource proxies as

arguments ♦ Blocks the script until the designated resources have been acquired ♦ May be invoked once per script Example Lua fragment:

acquire(mySession, myCrypt) if not mySession.get(“auth_flag”) then if myCrypt.crypt(. . .) == . . . . . . end end . . .

slide-48
SLIDE 48

Laser 2005 - Summer School on Software Engineering 48

SZUMO_LUA_INTERPRETER

♦ Encapsulates and provides an OO interface to the LUA interpreter ♦ Declares unit variables that link to the web resources ♦ For each such unit variable u, declares

– A condition variable: acquire_u – A constraint: acquire_u => u

♦ Implements acquire(r1, r2, …)

feature acquire_units ( use_session, use_nameservices, use_crypt: BOOLEAN) is do acquire_session, acquire_nameservices, acquire_crypt := use_session, use_nameservices, use_crypt end SZUMO_LUA_INTERPRETER support function to atomically acquire resource proxies

slide-49
SLIDE 49

Laser 2005 - Summer School on Software Engineering 49

Design of extension to generate content

{ acquire_session=> session, acquire_crypt => crypt, acquire_nameservices => nameservices } * CONTENT_HANDLER SCRIPT_HANDLER SZUMO_LUA_INTERPRETER acquire_crypt: BOOLEAN acquire_nameservices: BOOLEAN acquire_session: BOOLEAN . . . <<external>> CRYPT <<external>> NAME_SERVICES SESSION_OPERATION SCRIPT_INTERPRETER LUA_INTERPRETER_FACTORY SCRIPT_INTERPRETER_FACTORY * 0..1 0..1 0..1 crypt session nameservices *

slide-50
SLIDE 50

Laser 2005 - Summer School on Software Engineering 50

Task 2: Summary

♦ Extended Lua with primitives for a script to access web-server resources and declare its resource needs ♦ Wrapped Lua interpreters in synchronization units capable of reflecting the resource acquisition needs of scripts ♦ Did not need to make any changes to the existing web-server design

slide-51
SLIDE 51

Laser 2005 - Summer School on Software Engineering 51

Extension tasks

♦ Task 1: Authentication

– Added authentication capability – Safely integrated library functions

♦ Task 2: Dynamic content generation

– Provided for user scripting in the same memory space as the web server

♦ Task 3: Load balancing

– Modified web server to dynamically adapt the number

  • f content generators as a function of load
slide-52
SLIDE 52

Laser 2005 - Summer School on Software Engineering 52

Task 3: Load balancing

♦ Purpose: Dynamically adjust the number of Szumo Lua interpreters as a function of demand ♦ Problem:

– Replacement of an existing synchronization unit with

  • ne that has different contextual synchronization

dependencies – Coordination across multiple stages in request handling pipeline

slide-53
SLIDE 53

Laser 2005 - Summer School on Software Engineering 53

New classes in load balancing extension

♦ LUA_BALANCED_FACTORY (content generation stage)

– Replaces LUA_INTERPRETER_FACTORY – During rebalancing, creates or deletes LUA_INTERPRETER

  • bjects to achieve the target number

♦ LOAD_BALANCER (finalization stage)

– Computes estimate for number of interpreters needed as a function

  • f the arrival rate of requests for dynamic content and the average

time to process these requests – At regular intervals, acquires LUA_BALANCED_FACTORY and initiates a rebalancing process

♦ TIME_STAMPER (new: initialization stage)

– Augments a request with a time stamp

slide-54
SLIDE 54

Laser 2005 - Summer School on Software Engineering 54

Design of load balancing extension

{ acquire_session=> session, acquire_crypt => crypt, acquire_nameservices => nameservices } * CONTENT_HANDLER SCRIPT_HANDLER SZUMO_LUA_INTERPRETER acquire_crypt: BOOLEAN acquire_nameservices: BOOLEAN acquire_session: BOOLEAN . . . <<external>> CRYPT <<external>> NAME_SERVICES SESSION_OPERATION SCRIPT_INTERPRETER LUA_BALANCED_FACTORY SCRIPT_INTERPRETER_FACTORY * * 0..1 0..1 0..1 crypt session nameservices POST_PROCESSOR LOAD_BALANCER rebalance: BOOLEAN { rebalance => factory } factory TIME_STAMPER REQUEST_INITIALIZER REQUEST_HANDLER_POOL

initi initialize lizer

slide-55
SLIDE 55

Laser 2005 - Summer School on Software Engineering 55

Task 3: Summary

♦ Coordinated changes in different stages

– Added an initialization stage to log timestamps – Replaced the original factory for Lua interpreters with a factory that adjusts the number of interpreters to a target number – Extended the finalization stage to compute a target number and synchronize with the factory for rebalancing

♦ Except for replacing the factory, did not need to make any changes to the existing web-server design

slide-56
SLIDE 56

Laser 2005 - Summer School on Software Engineering 56

Summary

Case study:

♦ Designed and implemented OO multi-threaded web server ♦ Subjected the design to three extension/maintenance tasks

Corroborated:

♦ Extensions integrate well into the original design ♦ Szumo contracts compliment modern OO design methods ♦ Szumo appears to scale for realistic applications