A Generic Feedback Mechanism for Component-Based Systems

u n i v e r s i t y _ _ P h D T h Es i s G L A S G O W

---A Generic Feedback M echanism for

C om ponent-B ased Systems

by

Karen Vera Renaud

Submitted for the degree of

Doctor o f Philosophy

University o f Glasgow

June 2000

All rights reserved

INFORMATION TO ALL USERS

The qu ality of this repro d u ctio n is d e p e n d e n t upon the q u ality of the copy subm itted.

In the unlikely e v e n t that the a u th o r did not send a c o m p le te m anuscript

and there are missing pages, these will be note d . Also, if m aterial had to be rem oved,

a n o te will in d ica te the deletion.

uest

ProQuest 13818553

Published by ProQuest LLC(2018). C op yrig ht of the Dissertation is held by the Author.

All rights reserved.

This work is protected against unauthorized copying under Title 17, United States C o d e

M icroform Edition © ProQuest LLC.

ProQuest LLC.

789 East Eisenhower Parkway

P.O. Box 1346

Computers have been integrated into all spheres and occupations and the need for users to easily understand how to use each computer application has become

paramount. The end-user should not be expected to decipher cryptic messages or to understand the inner functioning o f the computer itself. W ith computer-users

spanning all walks of life, there is a need for a change in the mind-set of software developers in making their product more user-friendly.

In addition, software systems of the future will increasingly be built from independent encapsulated software components and will often be distributed over various sites.

This new paradigm brings a new realm of complexity for the end-user, especially with respect to the increased possibility of failure, so th a t in addition to the non­ trivial task of interpreting the general functioning of an application, the user will be expected to deal with the results of perplexing errors too. The nature of component-based systems makes the provision of support for handling errors far more difficult due to the independent and diffuse nature of the creators of the individual parts making up these systems.

Other factors with respect to application use also need to be addressed. For example, it is a rare user who is able to spend 100% of his or her tim e concentrating on interaction with the computer, w ithout distractions of some sort interrupting. It is even rarer to find an application which is not prone to occasionally unintelligible error messages or breakdowns. Few applications are designed with these realities in mind and when problems do occur, or users are interrupted, they often find it difficult to recover and to resume their primary task. It is also difficult for applications to tailor the provided feedback according to the specific needs of different end-users or the

differing roles within which they function.

This dissertation will highlight the role of feedback in increasing the interpretability of an application and in alleviating the effects of interruptions, errors and breakdowns. Rather than expecting feedback to be provided by programmers, this dissertation will

argue th a t feedback can be enhanced in a distributed component-based system by separating the feedback concern from the basic functional concern of the application

and executing the application within a generic feedback enhancing framework. The feedback concept is examined in depth and the role of feedback in enhancing under­ standing of applications, and in alleviating the effects of disturbances in our working

day, is explored. The concept of a generic framework for enhancing feedback has

I was assisted and supported by many people throughout the production of this dissertation, and during the course of the accompanying research. I would like to single some out for special

thanks:

* M y supervisor, Richard Cooper, for his support, m otivation, astute comments and insights,

unfailing patience, and for his unswerving faith in me.

* M y husband, Leon, for encouraging me in this endeavour, and for his love and understand­

ing. W ith o u t his support I would not have embarked on this journey of discovery.

* M y sons, Gareth, Ashley and Keagan, for putting up with the side-effects of my efforts to get a PhD so graciously and for being such outstanding young men.

* Huw Evans, for his friendship, wicked sense of humour, and painstaking attem pts at refining my prose.

* Malcolm Atkinson, for his support and for constructive comments on drafts of this disser­ tation.

* Ela Hunt, Phil Gray, Ray W elland, Stuart Blair and Susan Spence, for spending tim e

discussing my work with me and for their extremely helpful comments.

* Rosemary McLeish, for her friendship and for proof-reading this dissertation.

* M y family in South Africa: M om & Dad, Basil & Leonie, Wendy, Felicity, Ken & Joan, Lynn and Bernice. They supported us from afar, and we could not have borne the separation w ithout their love and assistance (and regular emails).

* Vera and Ian McCulloch, our adopted Scottish "family” . They gathered us under their

wing and made us feel at home. Dankie, en Weereens Dankie. * Neill Bogie, for being brave enough to test my prototype.

* The Association of Commonwealth Universities, and the Foundation for Research and Development in South Africa, who provided the funding for this research.

* The University of South Africa, for allowing me an extended period of absence to undertake

the research necessary to do this degree, and for financial assistance too. Thanks to the Head of Departm ent, Paula Kotze, for her continued support.

* BEA Systems, who donated the use o f their Tengah Server for the duration of this research.

I

Prologue

1

1 In t r o d u c t io n 2

1.1 Thesis S t a t e m e n t ... 2

1.2 T h e S h o rtfa ll in A p p lic a tio n F e e d b a c k ... 2

1.3 Feedback in C om ponen t-B ased S y s t e m s ... 4

1.4 P o te n tia l S o lu t io n s ... 5

1.5 R oad M a p ... 6

I I Summary of Background Material

7

2.1.1 W h a t are C o m p o n e n ts ? ... 10

2.1.2 How are com ponents d iffe re n t fro m o b je c ts ? . ! ... 13

2.2 T h e C o m ponen t R u n tim e E n v ir o n m e n t... 15

2.2.1 F ro m T w o -tie r to T h re e -T ie r A r c h it e c t u r e s ... 15

2.2.2 T h e M id d le , o r Business-Logic, T i e r ... 18

2.2.3 F ro m a C o m p o n e n t-F ra m e w o rk M id d le T ie r to C o m p o n e n t-O rie n te d M id d le w a r e ... 19

2.2.4 M o v in g to N T ie rs — T h e Im p a c t o f th e W o rld W id e W eb ... 22

2.2.5 S u m m a r y ... 24

2.3 T h e E v o lu tio n o f C o m p o n e n ts ... 24

2.3.1 C om ponents E m bedded w ith in a Process ... 25

2.3.2 C om ponents in D iffe re n t P ro c e s s e s ... 27

2.3.3 C om ponents on D iffe re n t M a c h in e s ... 27

2.4 P ro m in e n t C o m p o n e n t M o d e l s ... 29

2.4.1 T h e O M G ’s C o m p o n e n t M o d e l ... 31

2.4.1.1 A r c h i t e c t u r e ... 31

2.4.1.2 M id d le -T ie r A r c h i t e c t u r e ... 33

2.4.1.3 E x a m p l e ... 33

2.4.2 S un’s C o m p o n e n t M o d e l... 34

2.4.2.1 A r c h i t e c t u r e ... 34

2.4.2.2 M id d le -T ie r A r c h i t e c t u r e ... 35

2.4.2.3 E x a m p l e ... 36

2.4.3 M ic ro s o ft’s C o m p o n e n t M o d e l ... 36

2.4.3.1 A r c h i t e c t u r e ... 37

2.4.3.2 M id d le -T ie r A r c h i t e c t u r e ... 39

2.4.3.3 E x a m p l e ... 39

2.4.4 S u m m a r y ... 40

2.5 C om ponent-B ased D e v e lo p m e n t... 42

2.5.1 A D iffe re n t A p p r o a c h ... 43

2.5.2 C om ponen t Sources ... 44

2.5.3 B enefits o f U sin g C om ponen ts ... 45

2.5.4 S u m m a r y ... 46

2.6 R e v ie w ... . 47

2.6.1 T h e good news a b o u t c o m p o n e n t s ... 47

2.6.2 Reasons fo r ca u tio u s acceptance o f c o m p o n e n ts ... 48

2.7 C onclusion ... 49

3 Q u ir k s 51 3.1 I n t r o d u c t io n ... 52

3.2 A n a lysis o f Q u i r k s ... 53

3.3 W h y Q u irk s are Im p o rta n t ... 54

3.4 System Crashes and B r e a k d o w n s ... 56

3.5 H u m a n E r r o r ... 63

3.5.1 T h e N a tu re o f E r r o r ... 63

3.5.2 P erform ance Levels and L ik e lih o o d o f E rro rs ... 65

3.5.3 D e te c tin g E r r o r s ... 66

3.5.4 E n a b lin g User U n d e rs ta n d in g o f E r r o r ... 68

3.5.5 R ecovering fro m E r r o r ... 69

3.5.6 S u m m a r y ... 73

3.6 I n t e r r u p t i o n s ... 73

3.6.1 N a tu re o f I n t e r r u p t i o n s ... 74

3.6.2 T h e C o m p o s itio n o f an I n t e r r u p t ... 77

3.6.3 D ealing w ith I n te r r u p tio n s ... 78

3.6.4 S u m m a r y ... 81

4.2 P urpose o f F e e d b a c k ... 85

4.3 W h y give F e e d b a c k ? ... 86

4.4 W h e n m u st Feedback be G iven? ... 88

4.5 W h a t is G ood Feedback? ... 89

4.5.1 E xa m p le s o f In a d e q u a te o r B ad F e e d b a c k ... 91

4.5.2 L is t o f D esirable Feedback Features... ... 93

4.5.3 P r o v is o s ... 94

4.5.4 D iffe rin g User R o l e s ... 96

4.6 Feedback F o r m a t ... 96

4.6.1 T e x tu a l versus G ra p h ic a l F e e d b a c k ... 96

4.6.2 W h a t Does V is u a lis a tio n D o ? ... 98

4.6.3 R e s t r ic t io n s ... 98

4.7 Feedback fo r Q u i r k s ... 99

4.7.1 B r e a k d o w n s ... 100

4.7.2 H u m a n E rro r ...100

4.7.3 I n t e r r u p t i o n s ... 100

4.7.4 C o n c l u s i o n ... 101

4.8 S u m m a r y ...102

I I I Addressing Feedback Needs in Component-Based Systems

103

5.1.1 T r a d itio n a l W ays o f P ro v id in g F e e d b a c k ... 105

5.1.1.1 G uid e lin e s fo r P rogram m ers ... 105

5.1.1.2 C om prehensive O n lin e M anuals ... 106

5.1.1.3 A Feedback A p p lic a tio n P ro g ra m m e r I n t e r f a c e ... 106

5.1.1.4 S u m m a r y ... 106

5.1.2 W h y Feedback P ro v is io n is (E ven M o re ) D iffic u lt in C om po n e n t-B a se d S y s te m s ... 106

5.1.3 W h y E r r o r R ecovery is (E ven M ore) D iffic u lt in C o m ponen t-B ased Systems ... 107

5.1.4 C o n c l u s i o n ... I l l 5.2 T h e Proposed S o lu t io n ... I l l 5.3 F ir s t M ech a n ism — S ep a ra tio n o f C o n c e r n s ...113

5.3.1 S eparate S p e cifica tio n o f C o n c e r n s ... 113

5.3.2 O rth o g o n a lity o f C o n c e rn s ... 115

5.4.2 Second P erspective — S ystem -Level M o n it o r in g ...117

5.4.3 F irs t A p p ro a c h — Invasive T r a c k i n g ... 118

5.4.4 Second A p p ro a ch — N on-invasive T r a c k i n g ... 119

5.4.5 S u m m a r y ... 120

5.5 T h ir d M echanism — T h e V is u a lis a tio n ... 120

5.5.1 V is u a lis a tio n o f User In te ra c tio n w ith an A p p lic a t io n ...120

5.5.2 V is u a lis in g E x e c u tio n o f S o ftw a re ... 121

5.5.3 V is u a lis in g D i a lo g u e ...121

5.5.4 V is u a lis in g serial p e rio d ic d a t a ... 121

5.5.5 In te ra c tin g w ith th e V is u a lis a tio n ...122

5.5.6 C o n c lu s io n ...122

5.6 C o n s o lid a tio n ...122

5.6.1 B enefits o f th e Proposed A p p r o a c h ... 123

5.6.2 L im ita tio n s o f the P roposed A p p r o a c h ... . 124

5.6.3 S u m m a r y ... 124

IV HERCULE — Design and Implementation

125

6.1.1 Design P r in c ip le s ...127

6.1.2 Accessing H E R C U L E ...129

6.1.3 R e quired A p p lic a tio n F e a t u r e s ... 130

6.1.4 A n d T h u s ... 132

6.2 F a c ilita tin g HERCULE’s O b s e rv a tio n F u n c t io n ... 132

6.2.1 T h e “ M in im a l Im p a c t P ro x y ” Design P a t t e r n ... 134

6.2.2 T h e U ser-Interface P r o x y ... 136

6.2.3 T h e C o m p o n e n t P r o x ie s ...140

6.3 F a c ilita tin g HERCULE’s E x p la n a to ry F u n c tio n ... 142

6.4 HERCULE’s A r c h it e c t u r e ... 143

6.4.1 C o m m u n ic a tio n m o d u le s ...143

6.4.2 C o n t r o lle r ... 144

6.4.3 T h e W in d o w M a n a g e r ... 145

6.4.4 T h e Server P ro x y M a n a g e r ...149

6.4.5 T h e D is p la y C o n t r o lle r ...152

6.4.6 H ercule C o m p o n e n ts ... 152

6.5 A p p lic a tio n A c t iv it y V is u a lis a tio n ... 153

6.5.2 V is u a l R e p r e s e n ta tio n ... 156

6.5.3 L a y o u t ...157

6.5.4 C u s to m is a tio n ...159

6.6 C o n c lu s io n ...161

7 Im p le m e n t a t io n 163 7.1 P ro to ty p e A p p l i c a t i o n ...164

7.2 O b s e rv in g U ser-Interface A c t i v i t y ... 165

7.2.1 Java P la tfo rm -In d e p e n d e n t U se r-In te rfa ce M e c h a n is m ...166

7.2.2 In s e rtin g th e P r o x y ...167

7.2.3 T h e U ser-Interface P r o x y ... 168

7.2.4 W a tc h in g User A c t i v i t y ...170

7.2.5 M a in ta in in g and using th e in te rn a l im age o f th e G U I ... 172

7.3 O b s e rv in g Server C o m m u n ic a tio n ... 173

7.3.1 T h e E n te rp ris e Java Beans C o m p o n e n t M o d e l ... 173

7.3.2 U sin g P roxies to In te rc e p t C o m m u n ic a tio n ... 176

7.3.2.1 In s e rtin g th e P r o x ie s ... 176

7.3.2.2 Sending th e re p o rts to H E R C U LE ... 179

7.3.3 U sin g th e re p o rts generated b y th e proxies ... 179

7.4 T h e D e s c rip to r T o o l and P ro x y G e n e r a t o r ...: ...179

7.4.1 T h e D e s c rip to r T o o l . . 180

7.4.2 T h e P ro x y G e nerator ... . . 182

7.5 T h e R u n tim e Feedback T o o l ... 183

7.6 A p p lic a tio n A c t iv it y V is u a lis a tio n ...184

7.6.1 C h a ra c te ris tic s o f V is u a lis a t io n ...184

7.6.2 In te r a c tiv ity o f th e D i s p l a y ...185

7.6.3 E x te n s ib ility o f th e D i s p l a y ...187

7.7 C o n clu sio n ... 191

V Epilogue

192

8.2 P re lim in a ry E v a lu a tio n R e s u lt s ...196

8.2.1 User N e e d s ... 197

8.2.1.1 F e e d b a c k ...199

8.2.1.2 Q u irk s ... 200

8.2.2 C om ponen t-B ased System D evelopm en t and M a in te n a n c e ... 203

8.2.2.1 P ro g ra m m e r Needs ...203

8.2.3 P erform ance I m p a c t ... 205

8.3 C onclu sio n ... 206

9 C o n c lu s io n 2 0 7 9.1 R e ite ra tio n o f Thesis S ta te m e n t...207

9.2 S u m m a ry o f R e s e a r c h ...207

9.3 Thesis C o n t r i b u t i o n ... 209

9.4 F u tu re Research ... 210

V I Appendices and Bibliography

212

A

Glossary

213

Prologue

What we call the beginning is often the end And to make an end is to make a beginning

The end is where we start from.

T S Eliot. 1944

Baruch Spinoza

Tractatus Politicus (1677) c h .l, sect 4

chapter 1

Introduction

1.1

T hesis S tatem en t

I s u b m it th a t feedback can be enhanced in a d is trib u te d com ponent-based system b y exe­ c u tin g the a p p lic a tio n w ith in a generic feedback enhancing fra m e w o rk. I fu rth e r s u b m it th is s u p p o rts the user: fir s tly in u n d e rs ta n d in g th e a p p lic a tio n , secondly in recovering fro m er­ rors, and th ir d ly in re b u ild in g m e n ta l co n te xt a fte r in te rru p tio n s . T h e fra m e w o rk s ta n d a rd ­ ises feedback p ro visio n , s im p lifie s a p p lic a tio n code, allow s continuo us p o s t-im p le m e n ta tio n re finem ent o f e x p la n a to ry messages and prom otes reuse.

1.2

T he Shortfall in A p p lication Feedback

T h e feedback p ro v id e d b y a p p lic a tio n s in general use is ty p ic a lly p a tch y — o fte n inadequate and som etim es even m isleading. Users o fte n have great d iffic u lty in a sce rta in in g e x a c tly w h a t the a p p lic a tio n is d o in g w ith th e ir in p u ts and consequently struggle to b u ild u p an in te rn a l m o d e l o f how th e y s h o u ld in te ra c t w ith th e a p p lic a tio n .

T h e im m e d ia c y o f th e reactions o f com puters, com bined w ith th e fa ct th a t such reactions are n o t ra n d o m b u t considered (h a v in g been designed by a h um an p ro g ra m m e r), lead people to consider th e co m p u te r to be a p u rp o s e fu l social o b je c t [Suc87]. Therefore the c o m p u te r a p p lic a tio n can be th o u g h t o f as fu lfillin g the same role as a conversational p a rtic ip a n t

[PQS96].

P a rtic ip a n ts in a h u m a n -to -h u m a n conversation do n o t m e re ly take tu rn s , b u t in m any ways c o lla b o ra te in th e conversation. T h e speaker expects a level o f feedback w h ic h is essential in gauging th e liste n e rs’ re a ctio n to w h a t is b e in g said, th e ir u n d e rs ta n d in g o f th e c u rre n t su b je ct, th e ir opinion s, em otions and m uch m ore. T h is could be referred to as in d ic a tin g the liste n e rs’ “ state o f m in d ” and feedback can be considered to p la y a c ru c ia l role in assisting th e speaker in in te rp re tin g th is state. T h e speaker’s in te rp re ta tio n o f th is state w ill p la y an im p o rta n t role in steering th e conversation in one d ire c tio n o r anothe r. D u rin g th e discourse in fo rm a l “ rules” o f conversation between tw o people are developed. In the same way, a p p lic a tio n feedback assists the user in u n d e rs ta n d in g th e in te ra c tio n “ ru le s” o f the a p p lic a tio n .

In g a in in g an u n d e rs ta n d in g o f a p p lic a tio n in te ra c tio n rules, th e user ofte n gets lit t le as­ sistance, since a p p lic a tio n s fre q u e n tly do n o t e x p la in them selves a p p ro p ria te ly . In e x tric a b ly b o u n d u p w ith th is is the re la te d d iffic u lty o f p e rce ivin g th e relevant aspects o f th e cu r­ re n t state o f the a p p lic a tio n . T h e c o m p u te r’s fu n c tio n in g a nd in te rn a l state are co m p le te ly im p e rc e p tib le , m a kin g its tru e n a tu re even m ore o f a m y s te ry th a n i t should be.

W h a t we need to fa c ilita te b e tte r co m m u n ic a tio n between th e a p p lic a tio n p ro g ra m and th e end-user is, firs tly , a way fo r th e a p p lic a tio n to e x p la in th e in te ra c tio n rules to the end-user and, secondly, a m e th o d o f m a kin g relevant a p p lic a tio n state m ore available and p e rce p tib le . These tw o requirem ents can be term ed the “ in te r p r e ta b ility ” p ro b le m .

F u ll in te rp re ta b ility is d iffic u lt to achieve, since there is a fu n d a m e n ta l m ism a tch and p e re n n ia l m is u n d e rsta n d in g between end-users and a p p lic a tio n program m ers. T h is m is­ m a tch is exacerbated by th e fa c t th a t a p p lic a tio n program m ers produce a p p lic a tio n s w h ich m ust com m unicate w ith a person a b o u t w h o m th e p ro g ra m m e r can make very few in fo rm e d assum ptions. E conom ic re a litie s m ake i t infeasible to develop an e n tire a p p lic a tio n fo r a specific user and consequently a p p lic a tio n s are p roduced fo r a “ generic” user. T h e re is a tendency to generalise th e a p p lic a tio n interface to sa tisfy a ll the needs o f generic users, yet th is g e n e ra lity makes it d iffic u lt fo r in d iv id u a l users, w ith v a s tly d iffe re n t levels o f experience and in d iv id u a l requirem ents, to u n d e rsta n d the a p p lic a tio n ’s ra tio n a le .

T h e feedback channel, w h ic h is so v ita l to h u m a n -to -h u m a n in te ra c tio n , can be u tilis e d to enhance the in te rp re ta b ility o f th e a p p lic a tio n b y conveying relevant in fo rm a tio n a b o u t th e a p p lic a tio n ’s e xpectatio ns and u n d e rs ta n d in g of, and response to , the user’s in s tru c tio n s . Feedback is ro u tin e ly used to in d ic a te e ith e r a c o n firm a to ry response, o r to give in fo rm a ­ tio n a b o u t the fu n c tio n o f some user-interface com ponent — b y means o f co lo u r changes, balloons, icons etc.

since hum a n discourse is in c re m e n ta l and conversants w ill ty p ic a lly refer to so m e th in g th e y have p re v io u s ly said. H u m a n -to -a p p lic a tio n in te ra c tio n seldom fosters th is ty p e o f re fe rra l, w h ic h co u ld p o te n tia lly be ve ry w e ll catered fo r by an enriched m o d e l o f feedback.

F u rth e rm o re , a p p lic a tio n p rogram m ers are o fte n u n re a lis tic a b o u t th e th e user’s w o rk in g e n viro n m e n t and seldom cater fo r th e effects o f events w h ich w ill in te rfe re w ith th e use o f the a p p lic a tio n . Such events can d is ru p t th e s tra ig h tfo rw a rd e xecution o f a task and in te rfe re w ith a user’s co n ce n tra tio n . These events, w h ich w ill be referred to as q u irks, could be system breakdow ns, various types o f in te rru p tio n s to a p p lic a tio n use o r hum an errors. A p p lic a tio n s o fte n m ake no concession to th e in e v ita b ility o f q u irk s and seldom give assistance in re b u ild in g m e n ta l co n te xt a fte rw a rd s o r fa c ilita te u n d e rs ta n d in g o f the cause in the case o f an erro r.

1.3

Feedback in C om p on en t-B ased System s

C om ponent-based th re e -tie r systems are th e la te st p a ra d ig m s h ift in th e softw are engineer­ in g in d u s try . I t is w id e ly believed th a t fu tu re co m p u te r systems w ill be b u ilt fro m software com ponents. U n fo rtu n a te ly , th e y present new problem s and o p p o rtu n itie s w h ic h cannot be ignored. W hereas in te r p r e ta b ility is a ve ry real p ro b le m in tr a d itio n a l m o n o lith ic ap­ p lic a tio n s , i t becomes an even bigger p ro b le m in com ponent-based a p p lic a tio n s due to the independent and d is jo in te d n a tu re o f the p ro g ra m m in g a c tiv ity which, produces th e in d iv id ­ ua l com ponents used to b u ild th e system , a nd also due to the “ b la c k -b o x ” n a tu re o f said com ponents. T h e d is trib u te d n a tu re o f these systems increases th e p ro b a b ility o f errors and breakdow ns, once again re d u cin g in te rp re ta b ility .

T h e developers o f th e d iffe re n t com ponents used to b u ild a com ponent-based a p p lic a tio n w ill seldom com m unicate w ith one an o th e r. T h e a p p lic a tio n w ill generally be co n stru cte d fro m pre-developed com ponents and the developer o f th e fro n t-e n d a p p lic a tio n w ill m erely be given interfaces to these com ponents s p e c ify in g the c o n tra c tu a l re s p o n s ib ilitie s and fu n c­ tio n a lity o f the com ponent.

T h e developers therefore ca n n o t enhance th e feedback p ro v id e d b y the com ponen t, since th e y have no c o n tro l over th e im p le m e n ta tio n d e ta ils and have to accept th e feedback p ro ­ vid e d by the com ponent, w h atever its q u a lity . T h e developer w ill also have great d iffic u lty in a n tic ip a tin g a ll th e possible e rro r s itu a tio n s w h ich could arise fro m th e use o f a server com ponent. T h e e n ca p su la tio n p rin c ip le w h ic h drives com ponent-based developm ent gives system engineers th e fle x ib ility to be able to change th e im p le m e n ta tio n o f a com ponent d u rin g the life tim e o f th e system . T h is cou ld p re c ip ita te a w hole new range o f errors, h ith ­ e rto unsuspected, w h ic h w ill p ro b a b ly be re p o rte d to the user in a ll th e ir te ch n ica l verbosity, reducing the user’s u n d e rs ta n d in g o f the system and perhaps necessitating in te rv e n tio n by specialists.

th e a p p lic a tio n s is lik e ly to m ean a w id e r range o f users. These systems are designed to s u p p o rt m a n y d iffe re n t styles o f fro n t-e n d a nd to be m ade a vailable on th e in te rn e t, whereas sta n d -a lo n e lo c a l d e ploym en t was p re v io u s ly th e norm .

1.4

P o ten tia l Solutions

P ro g ra m m in g a p p lic a tio n s in com ponent-based systems is no easy ta sk [Jam 99b]. T h e c u rre n t appro a ch to p ro v id in g feedback is an e x p e c ta tio n th a t th e p ro g ra m m e r w ill p ro g ra m th is in a d d itio n to b u ild in g code w h ic h copes w ith a ll th e c o m p le xitie s o f th e d is trib u te d system . T h is approach appears to be flaw ed, as evinced b y c u rre n t standards o f feedback w h ic h do n o t alw ays meet th e requirem ents. I t is also n o t econom ically v ia b le to meet reasonable sta n d a rd s fro m w ith in each a p p lic a tio n . T h is approach also leads to inconsisten t p ro v is io n o f feedback m a kin g i t d iffic u lt fo r the user to fin d and assim ilate feedback w hen h a v in g to use several a p p lica tio n s.

C u rre n t approaches to enhancing the in te r p r e ta b ility o f th e system re ly h e a vily on e ith e r p a p e r o r o n lin e m anuals. T h e b enefits o f th is approach are lim ite d since research has shown th a t users seldom co n su lt m anuals, p re fe rrin g to fa m ilia ris e themselves w ith an a p p lic a tio n b y using i t [C R 87].

A n a lte rn a tiv e approach, described in th is d is s e rta tio n , is th a t feedback be p ro v id e d by a generic fe a tu re , p ro d u ce d independently o f th e a p p lic a tio n im p le m e n ta tio n . T h is approach necessitates tre a tin g the p ro v is io n o f feedback as a separate concern. T h is w ell-established tech n iq u e has been successfully a p p lie d in se p a ra tin g several n o n -fu n c tio n a l ch aracteristics fro m th e m a in concern o f a p p lic a tio n program s, b u t has h ith e rto n o t been a p p lie d to the p ro v is io n o f feedback. S eparatin g feedback p ro v is io n fro m the a p p lic a tio n makes th in g s easier fo r th e p ro g ra m m e r and provides a m echanism fo r a u g m e n tin g the feedback pro vid e d b y th e a p p lic a tio n itself.

T h e re are m a n y approaches to achie vin g separation o f concerns [H L95]. O ne approach, a p p lic a tio n tra c k in g , requires th e least e ffo rt fro m th e p ro g ra m m e r and was thus the ap­ pro a ch chosen. I t is also th e least invasive way o f a chieving th e re q u ire d sepa ra tio n o f concerns. A p p lic a tio n tra c k in g is w id e ly used fo r m any purposes, b u t once again has n o t h ith e rto been used to augm ent a p p lic a tio n feedback.

A p ro to ty p e im p le m e n ta tio n o f th is p ro p o sa l has been im p le m e n te d , in o rd e r to test the v ia b ilit y o f the scheme. T h is p ro to ty p e has been evaluated in term s o f the o rig in a l feedback needs id e n tifie d a t th e outset o f th e research.

1.5

R oad M ap

T h e d is s e rta tio n has been d iv id e d u p in to d iffe re n t sections:

• P a rt I contains th is in tro d u c tio n .

• P a rt I I p rovides th e backgroun d lite ra tu re in com ponent-based system s, q u irk s and feedback. C h a p te r 2 provides an overview o f com ponen t m odels, com ponent-based systems and com ponent-based developm ent. C h a p te r 3 explores th e n a tu re o f q u irk s — those events w h ic h in te rfe re w ith o u r s tra ig h tfo rw a rd use o f a p p lic a tio n s . C h a p te r 4 exam ines th e n a tu re and fo rm a t o f feedback, w ith a tte n tio n b e in g give n to th e role feedback can p la y in a lle v ia tin g the negative effects o f q u irks.

• P a rt I I I describes th e p ro b le m being addressed, proposes a s o lu tio n , discusses th e techniques used in th e s o lu tio n and enum erates th e advantages and lim ita tio n s o f th e proposed s o lu tio n . T h is discussion c o n s titu te s C h a p te r 5.

• P a rt I V describes th e design (C h a p te r 6) and im p le m e n ta tio n (C h a p te r 7) o f th e fra m e w o rk p ro to ty p e w h ic h was developed in o rd e r to test the proposals m ade in P a rt I I I .

• P a rt V evaluates th e p ro to ty p e (C h a p te r 8), concludes, sum m arises th e c o n trib u tio n s o f th is d is s e rta tio n and discusses fu tu re w o rk (C h a p te r 9).

Summary of Background Material

Read, every day, something no one else is reading. Think, every day, something no one else is thinking. Do, every day, something no one else would be silly enough to do.

It is bad for the mind to continually be part o f unanimity.

Christopher Morley

you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking a t it. A .A M ilne The House at Pooh Corner. (19 28 ) ch.6

chapter 2

Software Components

T h is thesis proposes a generic feedback m echanism su ita b le fo r a p p lic a tio n s b u ilt o u t o f com ponents. T h e re fo re th is ch a p te r w ill in tro d u c e softw are com ponen t concepts, since these fo rm an in te g ra l p a rt o f th e research discussed in th is d is s e rta tio n . Section 2.1 describes so ft­ ware com ponents. A ty p ic a l co m p o n e n t ru n tim e in fra s tru c tu re is discussed in Section 2.2. Section 2.3 discusses th e e v o lu tio n o f com ponents. Section 2.4 describes th e th re e p ro m in e n t co m p o n e n t m odels, and Section 2.5 gives a b r ie f overview o f th e process o f com ponent-based developm ent. Section 2.6 review s m a te ria l presented in th is chapter, w h ile th e fin a l section concludes.

2.1

W hy C om p on en ts, and W h at are T hey?

th is dream a re a lity.

C om ponents are th e la te st a tte m p t b y the in fo rm a tio n technology w o rld to s im p lify the p ro d u c tio n and m anagem ent o f softw are systems, a ta s k w h ich is n o to rio u s ly d iffic u lt to accom plish. B rooks [BF95] argues th a t th is is due to fo u r p ro p e rtie s o f softw are systems:

1. C om plexity — softw are systems can e xist in a large n u m b e r o f d iffe re n t states w h ich have to be visualised, described and tested by a developer. T h is increases w ith scale because o f th e added c o m p le x ity generated b y o b je cts in te ra c tin g w ith in th e system.

2. C o n fo rm ity — due to th e n a tu re o f th e h u m a n in s titu tio n s and systems to w h ich softw are systems m ust conform .

3. C hangeability — no o th e r k in d o f system is s u b je ct to as m any pressures fo r change as a softw are system . T h is is because softw are is perceived to be easily changeable, and because user requirem ents o fte n change w ith tim e .

4. In v is ib ility — Softw are is very d iffic u lt to visualise, m a k in g i t very d e m andin g fo r hum ans to u n d e rsta n d its fu n c tio n com prehensively.

O b je c t o rie n ta tio n was in it ia lly hailed as the s o lu tio n to these problem s [Cox90], b u t fa ile d to address th e m s ig n ific a n tly o r to reduce softw are developm ent tim e as m uch as was a n tic ip a te d [ 0 ’C99]. O b je c t o rie n ta tio n on its ow n has n o t m ade m uch o f a difference to p ro g ra m m e r p ro d u c tiv ity . ' A n y C r f T p ro g ra m m e r w ill re a d ily a tte s t to th is . T h e advent o f Java has m ade a difference, since i t , hid^s a lo t o f the c o m p le x ity in h e re n t in o th e r o b je c t-o rie n te d languages. I t w o u ld be m ore accurate to say th a t pure o b je c t-o rie n te d languages have m ade a difference to p ro g ra m m e r perform ance and p ro d u c tiv ity . However, even w ith Java, software developm ent rem ains a com plex task.

Software vendors are w e ll kn o w n fo r ju m p in g on th e band-w agon and h a ilin g the latest in n o v a tio n as th e s o lu tio n to a ll problem s. T h e aggressive m a rk e tin g o f CASE to o ls is an exam ple o f th is . T h e im p o rta n t fa ct overlooked by, o r perhaps convenie ntly ignored by, softw are developm ent to o l vendors in th e ir quest fo r p ro fits is th a t no single in n o v a tio n can be the cure fo r a ll softw are developm ent d iffic u ltie s , ju s t as no one m edical b re a k th ro u g h can be the answer to a ll h e a lth problem s.

Some have h a ile d the advent o f com ponents as b e in g th e “ one best w ay” o f developing softw are [SW 98]. O th e rs advise c a u tio n [Cha99c, 0 ’C99]. I t is im p o rta n t to bear in m in d th a t c o m p u tin g is a re la tiv e ly new science, and th a t th e softw are developm ent process needs to evolve s ig n ific a n tly before we can feel we have a rriv e d a t a su fficie n t u n d e rs ta n d in g o f the process to cla im th a t the one best way o f developing softw are systems has been found.

Machine X

Application Linked Library

rj/c

Functiory Calls

System Calls

Interprocess Communication

Application

Operating System

Network Communication Application

| Operating System j

Machine Y

Figure 2.1: Different modes of Operation [Cha96]

T h e section heading posed the question: “ W h y should anyone use com ponents?” . One m a jo r reason is in te ro p e ra b ility in th e presence o f in cre a sin g ly heterogeneous contexts. T h e scenario presented in F ig u re 2.1 dem onstrates d iffe re n t ways in w h ic h an a p p lic a tio n com ­ m unicates w ith d iffe re n t types o f en titie s. I f a lib r a r y is b eing used,, i t w ill be accessed v ia fu n c tio n calls. O p e ra tin g system fu n c tio n s w ill be invoked by means o f system calls. C o m ­ m u n ic a tio n w ith o th e r a p p lic a tio n s is achieved by means o f interprocess c o m m u n ic a tio n i f the a p p lic a tio n is on th e same m achine, p ro b a b ly in v o lv in g the use o f th e sockets m echa­ nism . C o m m u n ic a tio n is achieved by means o f a rem ote procedure ca ll i f th e a p p lic a tio n is on a n o th e r m achine. C o m m u n ic a tio n w ith o th e r a p p lic a tio n s , as w e ll as w ith lib ra rie s , can u s u a lly o n ly happen i f b o th have been im p le m e n te d using th e same language.

C om ponents p ro v id e th e means fo r c ro ss-p la tfo rm and cro ss-a p p lica tio n fu n c tio n a lity . T h e com ponent in fra s tru c tu re offered by the p ro m in e n t com ponent m odels (to be discussed in la te r sections) enables a p ro g ra m m e r to make use o f th e fu n c tio n a lity w ith in o th e r a p p lic a ­ tio n s, lib ra rie s and th e o p e ra tin g system a ll in e x a c tly th e same way. M u c h o f th e c o m p le x ity is h idden , and in a d d itio n , w ith tw o o f th e c u rre n t com ponen t m odels, the im p le m e n ta tio n language is no longer an issue.

T h e re are o th e r benefits w h ic h m ake com ponents a ttra c tiv e . T h e m ost im p o rta n t o f these are th e ir re u s a b ility and th e ir a p p ro p ria te size fo r re c o n s tru c tio n , m a rk e tin g and assembly.

2 .1 .1 W h a t a r e C o m p o n e n t s ?

here:

“ A softw are com ponen t is a u n it o f c o m p o s itio n w ith c o n tra c tu a lly specified interfaces and e x p lic it c o n te x t dependencies only. A softw are com ponen t can be deployed in d e p e n d e n tly a nd is s u b je c t to c o m p o s itio n by t h ir d p a rtie s .1” [Szy98]

“ Softw are o b je cts p ro v id in g some ty p e o f k n o w n service, o r specification s capable o f c re a tin g such objects, th a t can be used in c o m b in a tio n w ith o th e r com ponents to b u ild systems v ia a w e ll-d e fin e d in te rfa c e .” [Kar98]

“ A n id e n tifia b le piece o f softw are th a t describes and delivers a m e a n in g fu l service th a t is o n ly used v ia w e ll-d e fin e d interfaces” [SW 98].

“ A s ta tic a b s tra c tio n w ith p lu g s ” [N T 9 5 ].

“ A way o f packaging u n its o r m odules o f softw are th a t makes th e m such th a t th e y co u ld fo rm some p a rtic u la r k in d o f p lu g s ta n d a rd .” [W D 9 8 ].

“ A com ponen t is a softw are m o d u le th a t publishes o r registers its interfaces” [Har98].

“ A coherent package o f softw are th a t can be developed in d e p e n d e n tly and de­ live re d as a u n it, and th a t defines interfaces b y w h ic h it can be composed w ith o th e r com ponents to p ro v id e and use services” [D W 98].

M o st o f these d e fin itio n s emphasise th re e im p o rta n t features: interfaces, a set o f offered services, and reuse. Perhaps m ore h e lp fu l th a n a d e fin itio n w o u ld be a lis t o f th e required and desirable p ro p e rtie s o f com ponents. C om ponen ts should, w ith o u t a d o u b t [SW 98, C ot98, Szy98, H G 99]:

• be accessed o n ly v ia interfaces, w ith each interface b eing a subset o f the f u ll c o n tra c t the com ponent has w ith clients. T h is im p lie s th e use o f an interface d e fin itio n language — b o th to enable th e co m p o n e n t user to discover p ro p e rtie s o f th e com ponen t, and to enable th e com ponen t developer to advertise services p ro v id e d b y the com ponent;

• have e x p lic it co n te xt dependencies — fo r exam ple, i f a co m ponen t needs to access a re la tio n a l database, th e c o n te x t dependencies w o u ld in clu d e in fo rm a tio n a b o u t th e s tru c tu re o f th e tables i t requires. L o c a tio n dependence is a n o th e r exam ple o f a c o n te x t dependency;

• be adequ ately docum ente d — an essential p a rt o f th e w o rk described here;

• have a u n iq u e id e n tity ;

lrThis definition was first formulated at the 1996 European Conference on Object-Oriented Programming

• be custom isable;

• be a u n it to be m anaged b y a c o n ta in e r — i.e. be m ore th a n ju s t an executable b in a ry . I t m ust derive m any o f its p ro p e rtie s fro m the co n ta in e r, a n d use fa c ilitie s p ro v id e d by the co n ta in e r. I t m ust obey th e rules o f th e co n ta in e r, and w ill have s ta n d a rd ways o f sending events to the c o n ta in e r [P ri99]. T h e services ty p ic a lly p ro v id e d b y a c o n ta in e r in c lu d e th re a d in g , tra n sa ctio n s, s e c u rity and persistence [G u t9 9 ].

D esirable ch a ra cte ristics in clu d e , b u t are n o t lim ite d to:

• possession o f a f u ll d e s c rip tio n o f possible exceptions w h ic h c o u ld be th ro w n , and e x p la n a tio n s fo r these;

• th e p o te n tia l fo r th e d y n a m ic discovery o f s u p p o rte d interfaces;

• m in im u m co n te x t dependencies;

• re u sa b ility.

T h e last tw o desirable ch a ra cte ristics w ill always c o n flic t w ith each o th e r. A com ponen t is m ost useful i f i t can p e rfo rm its fu n c tio n w ith o u t any re s tric tin g co n te xt dependencies, o n ly re ly in g on e x te rn a l services general enough to be p ro v id e d by any com ponent containe r. To achieve th is , th e com ponen t w o u ld have to have a ll re q u ire d softw are b u n d le d w ith it , b u t th is ty p e :o f o v e r-in fla te d softw are produces e x a c tly th e type o f p ro b le m th a t com ponents were m eant to solve.

I f a com ponent needs to m ake use o f a secondary piece o f softw are, it sh o u ld ra th e r request th a t service as a co n te x t dependency, so th a t th e com ponen t o n ly encloses softw are to execute its p rim e fu n c tio n a lity . T h is makes th e com ponen t e m in e n tly reusable since th e p rim e fu n c tio n a lity is p ro b a b ly specialised enough, and th e com ponen t lig h tw e ig h t enough, to be used in o th e r contexts as w ell. However, th is reliance on e x te rn a l services makes the com ponent m ore d iffic u lt to house because o f th e increase in c o n te x t dependencies [Szy98].

For exam ple, consider a d esktop b u tto n , w h ic h is an e m in e n tly reusable o b je c t. A p a rt fro m the obvious re q u ire m e n t o f th e o p e ra tin g system , i t requires th e existence o f a co n ta in e r w ith in w h ich i t w ill be displayed. I t w ill expect to in h e rit some o f its p ro p e rtie s fro m its containe r. T h e b u tto n w ill p ro b a b ly derive its backg ro u n d c o lo u r fro m th e co n ta in e r, fo r exam ple. A lth o u g h i t allow s o th e r com ponents to re g iste r an in te re st in events executed on it, i t requires th e existence o f an e ve n t-p ro p a g a tin g m echanism w h ic h w ill in fo rm i t o f user actions. T h e b u tto n can change its appearance and be ta ilo re d fo r any n u m b e r o f purposes in th e user interface o f m ost a p p lic a tio n s .

T h is section has given d e ta ils o f ch a ra cte ristics th a t can be expected fro m softw are com ponents. T h e fo llo w in g section w ill shed some lig h t on how com ponen ts are d iffe re n t fro m objects.

2 .1 .2 H o w a r e c o m p o n e n t s d i f f e r e n t f r o m o b je c ts ?

T h u s fa r th e ch a ra cte ristics o f com ponents have been discussed. Some have c ritic is e d the com ponent m odel as s im p ly b e in g th e o b je c t m o d e l rephrased [ 0 ’C99]. C e rta in ly com ­ ponents have m any features o f tr a d itio n a l objects, so perhaps th e best w ay to s ta rt th is discussion is b y lo o k in g a t th e accepted n o tio n o f an o b je ct.

In the early days o f o b je c t o rie n ta tio n people were confused a b o u t th e m eaning o f objects too, and i t was o n ly a fte r some tim e th a t th e key concepts o f o b je c t tech n o lo g y were d is tille d and u n iv e rs a lly accepted. T h e accepted o b je c t m o d e l tenets are [Tay99]:

1. Objects — executable softw are representa tions o f re a l-w o rld objects.

2. Messages — a u n ive rsa l c o m m u n ic a tio n m echanism th ro u g h w h ic h o b je cts in te ra c t w ith one a nothe r.

3. Classes — tem plates fo r d e fin in g s im ila r objects.

T h e key m echanisms o f o b je c t technolo gy are [Tay99]:

1. P o lym o rp h ism — the a b ility to im p le m e n t the same message in d iffe re n t ways to s u it d iffe re n t o b je c t types.

2. E ncapsula tion — the m echanism fo r packaging re la te d d a ta a nd procedures to g e th e r w ith objects. T h e a im o f th is m echanism is th a t objects should fu n c tio n as a b la ck box, h id in g the in fo rm a tio n and m echanism s fo r o p e ra tin g on th e enclosed in fo rm a tio n .

3. In h e rita n ce — a s p e cia lisa tio n m echanism w hereby one class can m ake use o f in fo r­ m a tio n and messages defined w it h in a generalised class.

T h e o b je c t-o rie n te d c o m m u n ity has had d iffic u lty w ith th e la tte r tw o m echanism s. E ncap­ s u la tio n was n o t e q u a lly w e ll-s u p p o rte d by a ll o b je c t-o rie n te d languages2, and m ost la n ­ guages’ u n d e rsta n d in g o f enca p su la tio n d id n o t exte n d to a llo w in g a p p lic a tio n s developed using o th e r languages to use th e ir objects.

T h e re la tiv e d e s ira b ility and p a rtic u la r n a tu re o f in h e rita n c e caused a great deal o f debate in academ ic circles [Szy98]. Some o rganisatio ns, such as M ic ro s o ft, argued th a t m u ltip le im p le m e n ta tio n in h e rita n c e was a recipe fo r disaster. C + + allow s m u ltip le im p le m e n ta tio n in h e rita n ce , so th a t th e p ro g ra m m e r’s life is m ade e x tre m e ly d iffic u lt b y unexpe cted side- effects o f such in h e rita n ce . Im p le m e n ta tio n in h e rita n c e can also be regarded as a v io la tio n o f encapsulation.

2The fr ie n d function in C + + is a direct violation of the spirit of encapsulation, and Java allows p u b lic

Q u ite a p a rt fro m these problem s is th e g enerally acknowledged fa c t th a t o b je cts th e m ­ selves are to o fine-g ra in e d to be deployed in d epe ndently, because o f th e ir lo g ic a l c o u p lin g w ith o th e r objects [ 0 ’C99]. T h is lim its the re u s a b ility o f ob je cts, and makes th e m d iffic u lt to use in d e p e n d e n tly in a d is trib u te d e n viro n m e n t. However, i t is possible to id e n tify a group o f objects w h ic h c o lla b o ra te w ith each o th e r in p ro v id in g some piece o f fu n c tio n a lity , and w h ic h fo rm a ty p e o f u n it, w h ic h w o u ld be m ore su ita b le fo r indepe ndent deploym en t. T h is c o lla b o ra tio n can be deployed in d epe ndently, as a separate com ponent.

In a tte m p tin g to d is tin g u is h o b je cts and com ponents, some key issues emerge — objects are fine -g ra in e d , w h ile com ponents are coarse-grained. O b je cts m ust be im p le m e n te d in an o b je c t-o rie n te d language, whereas com ponents can be developed in any language. O b je cts do n o t always s u p p o rt encapsu lation, b u t the very n a tu re o f com ponents enforces encapsu­ la tio n b y the m a n d a to ry use o f interfaces. F in a lly , objects are h ig h ly dependent en titie s, whereas com ponents are designed to have a considerable measure o f autonom y. H a n [Han98] id e n tifie s some characteristics w h ich , he argues, d is tin g u is h com ponents fro m objects, w ith o n ly com ponents ha vin g the fo llo w in g characteristics:

1. s tru c tu ra l constraints w h ich w ill specify th a t c e rta in co m p o sitio n s o f a ttr ib u te in ­ stances are n o t p e rm itte d ;

2. operation al constraints w h ich specify perm issib le o p e ra tio n p a tte rn s;

3. events w h ic h can be fire d by th e com ponent.

4. m u lti-in te rfa c e s w h ich specify a n um ber o f roles th e com ponen t can play.

5. n o n -fu n c tio n a l p ro p e rtie s such as security, perform ance, a nd re lia b ility .

I t is d iffic u lt to agree w ith th is lis t. Java objects generate events, and in h e rit fro m m u ltip le interfaces. N o n -fu n c tio n a l p ro p e rtie s m entioned in p o in t 5 are n o t generic com ponent char­ a cteristics, b u t ra th e r requirem ents enforced on b e h a lf o f th e com ponen t by th e con ta in e r w ith in w h ic h i t is housed. S tru c tu ra l and o p e ra tio n a l c o n s tra in ts fa ll in to the same cate­ gory. T h e com ponent has co n te xt dependencies, w h ich in c o rp o ra te a ll these requirem ents, a lth o u g h these are n o t p ro p e rtie s o f th e com ponent its e lf, since o b je cts to o can have these c o n stra in ts and n o n -fu n c tio n a l requirem ents. T h is lis t is th e re fo re n o t useful in d ra w in g a d is tin c tio n between com ponents and objects. W h ile com ponents and objects can be seen to share H a n ’s p ro p e rtie s, th e tru e difference w o u ld appear to be th a t whereas o b je cts have to im p le m e n t th e co n stra in ts them selves, com ponents can expect m a n y o f the c o n s tra in ts to be a p p lie d by th e ir containe r.

Before c o n tin u in g to the n e x t section, w h ic h w ill discuss th e com ponent ru n tim e e n vi­ ro n m e n t, i t is necessary, in th e interests o f c la rity , to define th e te rm com ponent.

A c o m p o n e n t is a coherent, opaque, u n it o f software, accessible on ly via one o r m ore interfaces cooperatively d efining the f u l l c o n tra ctu a l duty o f the compo­

nent, w hich is independently deployed in a co n ta in e r enforcing and supplying the

contextua l requirem ents o f the component.

2.2

T he C om ponent R untim e Environm ent

In the n o t to o d is ta n t past, a ll a p p lic a tio n s were m o n o lith ic and ra n on w h a t users deemed to be “ p o w e rfu l” and expensive m a in fra m e com puters. Users connected to these m a in fra m e com puters v ia “ d u m b ” te rm in a ls . T h e m ainfram es were good a t ru n n in g such a p p lica tio n s, and were n o t re a lly tu n e d to re a c tin g speedily to m any requests fro m te rm in a ls . T h e m ono­ lith ic a p p lic a tio n s were m e re ly th e a u to m a tio n o f hand processing systems [B F97]. W it h the advent o f th e P erso n a l C o m p u te r (P C ), a p p lic a tio n s were s im p ly moved fro m th e m a in ­ fram es to th e P C . M o o re ’s la w 3 ensured th a t th e PCs in it ia lly had no d iffic u lty in keeping u p w ith ever g ro w in g a p p lic a tio n resource dem ands.

However, th e g ro w th o f th e n e tw o rk and co m m u n ica tio n s in d u s try , th e increasing de­ m ands o f a p p lic a tio n s , and th e d iffic u lty o f sh a rin g d a ta between users, changed the way people th o u g h t o f a p p lica tio n s, and the p o s s ib ility o f harnessing a p o w e rfu l co m p u te r in th e backg ro u n d to handle databases, fo r exam ple, led to the advent, in th e e a rly 1970s, o f client-server, o r tw o -tie r, systems. T h e fo llo w in g section w ill discuss th e ch a ra cte ristics o f these systems; and describe th e ir m etam orphosis in to th re e -tie r systems.

2 .2 .1 F r o m T w o - t i e r t o T h r e e - T i e r A r c h i t e c t u r e s

T h e tw o -tie r a rc h ite c tu re separates a d is trib u te d a p p lic a tio n in to tw o colle ctio n s o f processes — clients w h ich handle user in te ra c tio n , and servers w h ich manage resources. T h e fo rm o f in te r-a p p lic a tio n in te ra c tio n before th e advent o f these systems was fa c ilita te d by means o f Inter-P rocess C o m m u n ic a tio n (IP C ). T h e IP C m echanism operates on a b y te level, and th e p ro to c o l fo r c o m m u n ic a tio n m u st be agreed u p o n b y b o th p a rtic ip a n ts , b o th o f w h o m were p ro b a b ly im p le m e n te d in th e same language [Szy98]. In client-server systems, clients could, as an a lte rn a tiv e to IP C , co m m u n ica te w ith the server using a Remote Procedure C a ll (R P C ) [BN84] m echanism . T h is m echanism places stubs on th e clie n t and server m achines. W h e n th e c lie n t a p p lic a tio n makes a c a ll to th e c lie n t s tu b , i t w ill m a rsh a l th e param eters and send th e m to the server stub. T h e server stu b receives the param eters, unm arshals them , and sends th e m to th e server fo r processing. T h e c lie n t is unaware o f th is process and follow s local c a llin g conventions in using th e procedure. T h e m a rs h a lin g and u n m a rs h a lin g process is responsible fo r conversions to d iffe re n t fo rm a ts on d iffe re n t machines. R P C sim p lifie s

a ll levels o f c o m m u n ic a tio n (in-process, inter-process and in te r-m a c h in e ) b y m a kin g th e ir m echanism th e same — th e re m o te procedure c a ll [Szy98].

T h e re are tw o types o f servers — stateless o r s ta te fu l [Cor91]. T h e stateless server does n o t m a in ta in any in fo rm a tio n a b o u t clients between calls. A n exam ple o f th is is a W eb server. A s ta te fu l server “ rem em bers” c lie n t in fo rm a tio n fro m one m e th o d in v o c a tio n to the n e xt. Stateless servers are m ore fa u lt to le ra n t th a n s ta te fu l ones, since a c lie n t can s im p ly keep resending a request t i l l th e server responds. T h e c lie n t o f a s ta te fu l server needs to re b u ild server co n te x t a fte r a crash, and th is could cause th e clie n t to fa il. However, s ta te fu l servers operate in a w e ll-u n d e rs to o d p ro g ra m m in g p a ra d ig m , and are m ore e fficie n t [Cor91].

In clie n t-se rve r systems, as show n in F ig u re 2.2, m any clients use th e same server on a re q u e st-re p ly basis. These a rch ite ctu re s enable clients to have so p h istica te d user interfaces and d a ta v is u a lis a tio n tools on th e ir desktop co m p u te r, and share d a ta w ith o th e r clients by means o f p o w e rfu l database servers a t th e server level [B F97].

User

User Interface

Client Application

Figure 2.2: T h e Client Server 2 -T ie r Architecture

I f th e logic is located in th e server, o fte n a database server, i t becomes tig h tly lin k e d to th e a c tu a l d a ta source, and i t is d iffic u lt to use d a ta fro m o th e r sources as w ell. I t is also fa r to o easy to overload th e server, d e gradin g p erform ance and a ffe c tin g response tim es to a ll clients. I t is d iffic u lt to p ro vid e a re lia b le service due to th e d iffic u lty o f lo a d -b a la n cin g w ith th is a rc h ite c tu re .

O fte n th e logic was s p lit u p between th e c lie n t and th e server, and i t was ve ry d iffic u lt to reuse any o f th e c lie n t code i f th e server ty p e changed. I f a d iffe re n t ty p e o f fro n t-e n d were needed (fo r exam ple, a to u ch -to n e phone access fro n t-e n d ), a w hole new a p p lic a tio n had to be w ritte n . I t is also w e ll-n ig h im possible to in te g ra te legacy system s in to a con ve n tio n a l client-server system . In sum m ary, c lie n t and server processes are to o tig h t ly coupled.

User Interface

Client Application Client

Machine

Logic

Server

Machine Components

Data

Database Database Database

Figure 2.3: T h e 3-T ier Architecture

T h e th re e -tie r a rc h ite c tu re , show n in F ig u re 2.3, was developed to a lle v ia te these p ro b ­ lems, w ith the business logic b eing s itu a te d in a m id d le tie r, betw een th e clie n t a p p lic a tio n and th e d a ta tie r. T h e m id d le tie r does n o t make assum ptions a b o u t how a resource, such as a co lle ctio n o f data, is stored, b u t s im p ly expects i t to be p ro v id e d b y a low er tie r. T h e user interface tie r deals d ire c tly w ith th e m id d le tie r, a nd relies on th is tie r to in te ra c t w ith the low er tie r and to c o n tro l access to a ll shared resources. T h is new a rc h ite c tu re makes i t m uch sim p le r fo r d iffe re n t types o f c lie n ts to share business logic and resources.

advantage o f th is approach is th a t th e clie n t becomes th in n e r, w it h m ost o f th e business logic b e in g lo ca te d in th e m id d le tie r. T h is m in im ise s th e cost o f ow n e rsh ip o f large num bers o f c lie n t systems [Dol98].

T w o o f the three tie rs in th is m odel are w e ll u n d e rsto o d — th e c lie n t a p p lic a tio n , and the low er (d a ta ) tie r. However, th e m id d le tie r is re la tiv e ly new, and w ill be described in the fo llo w in g section.

2 .2 .2 T h e M i d d l e , o r B u s in e s s - L o g ic , T i e r

T h e move to in c o rp o ra te a m id d le tie r was a lo g ica l response to th e problem s o u tlin e d in th e p revious section. However, w hen i t came to p la n n in g the in fra s tru c tu re , and th e p ro v is io n o f the re q u ire d m id d le -tie r fu n c tio n a lity , th in g s were n o t as s tra ig h tfo rw a rd . I t was necessary to share resources, such as d a ta sources, and business logic, between d iffe re n t clients, and also to have a s tru c tu re w h ich was fle x ib le enough to respond to changes in business rules w ith o u t great d iffic u lty .

T h e p a ra lle l developm ent o f in d e p e n d e n tly deployable com ponents, w h ic h were a via b le a lte rn a tiv e to fin e ly -g ra in e d tig h tly -b o u n d objects, m ade i t possible fo r th e business logic to be encapsulated in the fo rm o f m id d le -tie r com ponents. (T h e com ponen t e v o lu tio n process is described in Section 2.3.)

T h e use o f m id d le -tie r com ponents enables sh a rin g between d iffe re n t types o f a p p lica ­ tions, and th e size and encapsulated n a tu re o f th e com ponents makes th e m easier to upgrade in a w o rld o f ever-changing business rules.' In a d d itio n , instead o f ty in g th e business logic exclu sive ly to one ty p e o f d a ta source, com ponents co u ld be m ade fle x ib le enough to lin k to any available d a ta sources.

Since com ponents are essentially evolved objects, the th re e -tie r a rc h ite c tu re requires the c lie n t to co m m unicate w ith these com ponents in an o b je c t-o rie n te d m anner — i.e. v ia m e th o d invocation s. In th is new a rc h ite c tu re , therefore, th e R P C m echanism is h id d e n fro m the p ro g ra m m e r, and replaced b y a rem ote m e th o d in v o c a tio n p ro to c o l, because R P C does n ot d ire c tly s u p p o rt m e th o d in vo ca tio n s [Szy98]4. A system o f proxies is used to a llow th e c lie n t to invoke m ethods on a surrogate p ro x y o b je c t in e x a c tly th e same way as m ethods are invoked on lo ca l objects. T h e p ro x y o b je c t su p p o rts th e same in te rfa ce as the m id d le -tie r com ponent. T h e c lie n t p ro g ra m w ill request services fro m th e m id d le -tie r com ponents by means o f locally-based m e th o d invo ca tio n s, and receive replies in th e fo rm o f re tu rn values.

A l l com ponents need to be housed w ith in containers, w h ic h can p ro v id e essential services re q u ire d by th e com ponents, such as, fo r exam ple, life -cycle m anagem ent, and a d m in is tra ­ tio n fu n c tio n s . A n in fra s tru c tu re p ro v id in g such services is called a fram ew ork? .

4 Method invocations require two things not provided by RPC: runtime inspection of the class of the

receiving object to choose the method to be invoked; and the inclusion of a reference to the receiving object

as a m ethod parameter [Szy98].

5Lewandowski defines a framework as being “ a large design p a tte rn c a p tu rin g the essence o f one specific

T h e o b je c t-o rie n te d c o m m u n ity o rig in a lly used th e co n stru cts o f o b je c t o rie n ta tio n to p ro vid e an o b je c t-o rie n te d fra m e w o rk to house m id d le -tie r com ponents, g iv in g b ir t h to com­ ponen t fra m e w o rks6. T h e com ponen t fra m e w o rk provides s u p p o rt fo r the com m on fu n c tio n ­ a lity w h ic h is re q u ire d by a ll com ponents. Specific com ponents can p ro v id e specific so lutions, and m ake use o f th e fra m e w o rk to p ro v id e com m on features such as co m m u n ic a tio n and life-cycle m anagem ent. T h e fra m e w o rk imposes ce rta in standards, and allow s com ponents to be “ plugged in ” , to a llo w th e m to in te ra c t w ith groups o f o th e r com ponents and the co n ta in e r its e lf in a s ta n d a rd way[Szy98].

Fram ew orks proved to be a su ita b le idea fo r ta k in g care o f some o f the “ w irin g ” problem s o f com ponents, b u t had th e ir lim ita tio n s w hen p ro v id in g fo r o th e r special needs, w h ich became clear as people gained experience in th e use o f th re e -tie r com ponent-based systems. T h e m id d le tie r o f an a p p lic a tio n co u ld be se rvicing hundreds o r thousands o f co n cu rre n t users, and th e types o f problem s to be d e a lt w ith could be [RS99]:

• H ow are clie n t requests to be load balanced?

• H ow can system u p tim e be guaranteed in th e face o f system breakdow ns and necessary a d m in is tra tio n ?

• Is i t possible to ensure th a t d a ta in the lower tie r rem ains consistent w hen b eing used by m u ltip le users?

• H ow are clie n t requests tra n sfe rre d to o th e r machines in th e case o f a fjailure?

• H ow w ill clients be a u th e n tic a te d and a u th o rise d to p e rfo rm secure operations?

T h e o b je c t-o rie n te d c o m m u n ity have had no h is to ry o f d ealing w ith these types o f problem s, and in o rd e r to solve th e m , th e y tu rn e d to the database in d u s try . T h e fo llo w in g section describes th e s o lu tio n to th is pro b le m .

2 .2 .3 F r o m a C o m p o n e n t - F r a m e w o r k M i d d l e T i e r t o C o m p o n e n t - O r i e n t e d M i d d l e w a r e

T ransaction Processing M o n ito rs (T P M s ), such as I B M ’s C IC S [G R 93], have vast e x p e ri­ ence in dea lin g w ith th e issues n o t d e a lt w ith b y com ponent fram ew orks — in th e co n te xt o f database systems — and th e obvious s o lu tio n to d ealing w ith these issues fo r m id d le -tie r com ponents is to give com ponen t fram ew orks special T P M c a p a b ilitie s. T P M s are very

system or subsystem [FHLS99]. They describe a framework as being implemented as a set of abstract classes

which define the core functionality of the framework, together with concrete classes for specific applications.

Froehlich et al. point out that frameworks are intended to provide a generic solution for a set of similar

problems, with applications providing a specific solution for a specific problem.

6 “A dedicated and focused architecture, usually a few key mechanisms, and a fixed set of policies for