-
Notifications
You must be signed in to change notification settings - Fork 9
/
upgrades-ajmani.bib
1839 lines (1740 loc) · 89.3 KB
/
upgrades-ajmani.bib
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
%% This was last synced with
%% http://www.pmg.lcs.mit.edu/~ajmani/papers/upgrades.bib
%% on 2019-01-14
% The latest version of this file can be downloaded at:
% http://www.pmg.lcs.mit.edu/~ajmani/papers/upgrades.bib
%
% This document, written by Sameer Ajmani (ajmani AT csail.mit.edu), is an
% annotated bibliography of publications about software upgrades in
% distributed systems. You are free to use this bibliography for academic
% purposes. The annotations are my own interpretation of the work unless
% otherwise noted; please credit the authors of any annotations you use.
% I've done my best to be accurate in both the annotations and the
% references, so please notify me of any errors or omissions!
%
% Note: you'll need \usepackage{url} in your LaTeX document to handle the
% \url commands in this bibliography.
@inproceedings{ajmani06modular,
author = "Sameer Ajmani and Barbara Liskov and Liuba Shrira",
title = "Modular Software Upgrades for Distributed Systems",
booktitle = "European Conference on Object-Oriented Programming (ECOOP)",
month = jul,
year = 2006,
location = "Nantes, France",
category = "Automatic Software Upgrades",
categories = "Automatic Software Upgrades",
abstract =
"Upgrading the software of long-lived, highly-available distributed
systems is difficult. It is not possible to upgrade all the nodes in a
system at once, since some nodes may be unavailable and halting the
system for an upgrade is unacceptable. Instead, upgrades must happen
gradually, and there may be long periods of time when different nodes
run different software versions and need to communicate using
incompatible protocols. We present a methodology and infrastructure
that make it possible to upgrade distributed systems automatically while
limiting service disruption. We introduce new ways to reason about
correctness in a multi-version system. We also describe a prototype
implementation that supports automatic upgrades with modest overhead.",
downloads = "
http://pmg.csail.mit.edu/~ajmani/papers/ecoop06-upgrades.ps ps;
http://pmg.csail.mit.edu/~ajmani/papers/ecoop06-upgrades.pdf pdf",
}
@phdthesis{ajmani04automatic,
title="Automatic Software Upgrades for Distributed Systems",
author="Sameer Ajmani",
school= "MIT",
month = sep,
year = 2004,
XXXnote = "Also as Technical Report MIT-LCS-TR-",
category = "Automatic Software Upgrades",
categories = "Automatic Software Upgrades; IRIS",
abstract=
"Upgrading the software of long-lived, highly-available distributed
systems is difficult. It is not possible to upgrade all the nodes in a
system at once, since some nodes may be unavailable and halting the
system for an upgrade is unacceptable. Instead, upgrades may happen
gradually, and there may be long periods of time when different nodes
are running different software versions and need to communicate using
incompatible protocols. We present a methodology and infrastructure
that address these challenges and make it possible to upgrade
distributed systems automatically while limiting service disruption.
\par
Our methodology defines how to enable nodes to interoperate across
versions, how to preserve the state of a system across upgrades, and how
to schedule an upgrade so as to limit service disruption. The approach
is modular: defining an upgrade requires understanding only the new
software and the version it replaces.
\par
The upgrade infrastructure is a generic platform for distributing and
installing software while enabling nodes to interoperate across
versions. The infrastructure requires no access to the system source
code and is transparent: node software is unaware that different
versions even exist. We have implemented a prototype of the
infrastructure called Upstart that intercepts socket communication using
a dynamically-linked C++ library. Experiments show that Upstart has low
overhead and works well for both local-area and Internet systems.",
downloads=
"http://pmg.csail.mit.edu/~ajmani/papers/phdthesis.ps ps;
http://pmg.csail.mit.edu/~ajmani/papers/phdthesis.pdf pdf"
}
@Article{brewer01lessons,
author = "Eric A. Brewer",
title = "Lessons from Giant-Scale Services",
journal = "IEEE Internet Computing",
month = jul,
year = "2001",
annote = "Discusses tradeoffs in the design of giant-scale services
that allow for graceful degredation of service under load and failure
and support for online evolution. Advocates automatic upgrade
systems, and describes three approaches: fast reboot (everyone at
once), rolling upgrade (round-robin), and big flip (partition the
system, then upgrade each partition). Insists that these systems need
a safe and fast way to roll back to the old version, since new
versions tend to be buggy. Mentions that many systems use a staging
area where the new software is set up alongside the old software
before going live --- makes switchover (in either direction) easy.",
}
@Misc{swg,
key = "Star Wars Galaxies",
title = "Star Wars Galaxies Multiplayer Online Game",
note = "\url{http://starwarsgalaxies.station.sony.com/}",
annote = "A multiplayer online game that requires clients to
version sync with the server before logging in.
Presumably, the server kicks off all clients (requiring
them to resync) when a new version is deployed.",
}
@InProceedings{solarski02towards,
author = "Marcin Solarski and Hein Meling",
title = "Towards Upgrading Actively Replicated Servers
on-the-fly",
crossref = "dependable02",
annote = "Upgrades a replicated server by upgrading each replica
in turn. Assumes that (1) multiple upgrades do not
interleave, (2) version v+1 offers a compatible
interface to version v, (3) there exists a mapping from
version v's state to version v+1, and (4) clients only
use extensions offered by v+1's interface after all
replicas are upgraded. Upgrades are scheduled by
totally ordering the replicas (using some replica
identifier). Assumes full compatibility between
different versions, so doesn't need to convert messages
between versions (i.e., no simulation mode).",
}
@TechReport{rsync,
author = "Andrew Tridgell and Paul Mackerras",
title = "The rsync algorithm",
institution = "Australian National University",
year = 1996,
number = "TR-CS-96-05",
NEEDaddress = "",
month = jun,
}
@Misc{redhat-update,
title = "{R}ed {H}at up2date",
key = "Red Hat",
note = "\url{http://www.redhat.com/docs/manuals/RHNetwork/ref-guide/up2date.html}",
}
@Misc{paula-specifying,
author = "Virginia C. de Paula and G. R. Ribeiro Justo and P. R.
F. Cunha",
title = "Specifying Dynamic Distributed Software
Architectures",
URL = "http://citeseer.ist.psu.edu/473045.html",
}
@Misc{pai03codeen,
author = "Vivek Pai and others",
title = "{CoDeeN}",
url = "http://codeen.cs.princeton.edu/",
annote = "A CDN deployed on PlanetLab that upgrades its nodes
about twice a week, causing only about 20 seconds of
downtime per node. New versions are simply scp'd to the
nodes and the software is restarted to use the new
code. Versions are typically backwards-compatible; on
the rare occasions when a new version is incompatible,
version numbers are used to distinguish new calls from
old ones (which are rejected).",
}
@Misc{marimba,
title = "Mar\'{\i}mba",
key = "Marimba",
note = "\url{http://www.marimba.com/}",
annote = "A commercial system for ``managing software on
desktops, laptops, servers, and devices.''",
}
@InProceedings{liu02using,
author = "Chang Liu and Debra J. Richardson",
title = "Using {RAIC} for Dependable On-Line Upgrading of
Distributed Systems",
crossref = "dependable02",
annote = "A RAIC controller provides a static interface to an
array of similar or identical components. The RAIC
automatically handles failover and recovery of
components. Thus, RAIC can support component updates by
allowing new versions to be added to the component
array. If the new version of a component is faulty
(e.g., raises an exception), RAIC intercepts the fault
and redirects the call to an older version of the
component. Furthermore, different callers can use
different versions of the components. It is not clear
whether this system avoids state divergence between
components of different versions.",
}
@InProceedings{hofmeister92surgeon,
author = "C. Hofmeister and E. White and J. Purtilo",
title = "Surgeon: {A} Packager for Dynamically Reconfigurable
Distributed Applications",
crossref = "iccds92",
annote = "Describes a way to package an upgrade to software
components in a distributed system. Packaging analyzes
interface bindings, determines how components should be
integrated, generates interface software to connect
components, and creates configuration commands to build
the application. A ``catalyst'' module on each node
actually runs reconfigurations using a package (cf. the
UL). Packaging may require component participation to
save the state, transform state, restart the component,
or delay upgrades until a suitable point (so that
consistency can be maintained). The authors categorize
the kinds of components that can be reconfigured
without any such participation: these are those modules
that neither require state transfer, nor special
initialization, nor synchronization with other
modules.",
pages = "164--175",
}
@InProceedings{hauptmann96online,
author = "Steffen Hauptmann and Josef Wasel",
title = "On-line Maintenance with On-the-fly Software
Replacement",
crossref = "iccds96",
annote = "Supports replacement of modules, called ``actors'', in
the Chorus real-time OS. Actors can contain several
threads and provide an interface composed of several
communication ports. The replacement approach does not
depend on specially-written apps; instead, app code is
modified to make the app replaceable. The authors claim
that most of this modification can be done
automatically. Modifications include (1) adding a
thread to run the replacement, (2) adding state
capture/restore functions at exchange points (places
where threads can block), (3) addings handlers for
aborted system calls, (4) adding instructions to
restore the call stack after replacement.",
pages = "70--80",
}
@Misc{gnucleus,
title = "The {Gnucleus} Open-Source {Gnutella} Client",
note="\url{http://www.gnucleus.com/Gnucleus/}",
key = "Gnucleus",
annote = "A peer-to-peer file sharing system that deploys
upgrades eagerly: nodes version sync on eahc
communication, so if one node upgrades, it causes each
node it talks to upgrade (epidemic dissemination).",
}
@Misc{emc-oncourse,
title = "{EMC} {O}n{C}ourse",
key = "EMC OnCourse",
note = "\url{http://www.emc.com/products/software/oncourse.jsp}",
annote = "A commercial ``application that enables secure,
reliable, automated distribution of files between
systems across IP networks.''",
}
@InProceedings{dislis02improving,
author = "Chryssa Dislis",
title = "Improving Service Availability via Low-Outage
Upgrades",
crossref = "dependable02",
annote = "Gives an industry perspective (Motorola, Inc.) on the
importance of upgrading software without interrupting
service, and suggests (common sense) techniques for
minimizing downtime. For example, preparing the system
for the upgrade, taking backups in case roll-back is
needed, minimizing user interaction (since this is
typically slower than automated actions and reduces
error), etc. Note that the full paper is not available
yet.",
}
@InProceedings{cook02reliable,
author = "Jonathan E. Cook and Navin Vedagiri",
title = "Reliable Upgrading through Multi-Version Execution",
crossref = "dependable02",
annote = "Allows multiple versions of a function to exist
simultaneously, and uses an arbiter to dispatch calls
dynamically to different versions of a function. Keeps
the old version around to protect the system from
errors introduced by a new version, until the new
version is deemed safe.",
}
@Misc{cisco-essentials,
title = "Cisco {R}esource {M}anager",
key = "Cisco Resource Manager",
note = "\url{http://www.cisco.com/warp/public/cc/pd/wr2k/rsmn/}",
annote = "A commercial, web-based management system that
supports software upgrades for ``Cisco switches, access
servers, and routers.''",
}
@InProceedings{chaudron02upgrade,
author = "M. R. V. Chaudron and F. van de Laar",
title = "An Upgrade Mechanism Based on Publish/Subscribe
Interaction",
crossref = "dependable02",
annote = "Advocates the use of publish/subscribe as an
interaction style for upgradeable component-based
systems. Publish/subscribe induces less coupling than
request-response (e.g., RPC), since components do not
have to interact synchronously and do not have to know
each other. Therefore, components can be replaced
(more) easily; a configuration manager (CM) manages
these replacements. Authors do not consider upgrades
that require state transfer between components or
upgrades to the CM.",
}
@InProceedings{bloom92reconfiguration,
author = "Toby Bloom and Mark Day",
title = "Reconfiguration in {A}rgus",
crossref = "iccds92",
annote = "Defines a correctness condition for reconfiguration:
``continuation abstractions are preserved or invisibly
extended by a replacement.'' That is, module (guardian)
replacements must be backward (upward) compatible and
must continue the behavior of the original module
(e.g., by transferring the old module's state).
Reconfiguration quiesces the modules to be replaced;
client transactions on those modules abort. The authors
describe two kinds of upgrading infrastructures:
system-supported replacement (SSR) and
application-level replacement (ALR). SSR requires hooks
in the Argus system to allow replacement and an
additional indirection on handler calls. ALR requires
participation by designers of modules and clients of
modules to support upgrades.",
pages = "176--187",
}
@InProceedings{bidan98dynamic,
author = "C. Bidan and V. Issarny and T. Saridakis and A.
Zarras",
title = "A Dynamic Reconfiguration Service for {CORBA}",
crossref = "iccds98",
URL = "http://citeseer.ist.psu.edu/bidan98dynamic.html",
annote = "Defines a Dynamic Reconfiguration Manager (DRM) that
coordinates reconfigurations in Aster, a CORBA-based
distributed system. Builds on reconfiguration work in
Polylith (Hofmeister and Purtilo, 1993). Like that
work, the DRM passivates links between objects before
reconfiguring them and transfers state to initialize
new versions. The authors define formal consistency and
efficiency constraints for reconfiguration, and argue
that their reconfiguration algorithm is optimally
efficient (i.e., causes minimal disruption).",
pages = "35--42",
}
@InProceedings{bialek02architecture,
author = "Robert P. Bialek",
title = "The Architecture of a Dynamically Updatable,
Component-based System",
crossref = "dependable02",
annote = "Combines dynamic component architectures (e.g., CORBA,
EJB, DCOM) with dynamic software updating (e.g., Gupta
and Jalote, Hicks) to create an architecture that
supports both structural reconfigurations and non-stop
updates to component implementations. Defines an
``update descriptor'' as a set of requests to add,
remove, and/or update objects in the system, along with
the replacement implementations (much like a
package).",
}
@Misc{battle.net,
key = "Battle.net",
title = "{Battle.net} Multiplayer Online Game Server",
note = "\url{www.battle.net}",
annote = "A game server system that requires clients to version
sync with the server before allowing them to set up
games with other clients. This ensures that clients in
the same game are version-synced, but also enables
Battle.net to upgrade without interrupt existing
games.",
}
@InProceedings{barbacci92durra,
author = "M. Barbacci and others",
title = "Building Fault-tolerant Distributed Applications with
{Durra}",
crossref = "iccds92",
annote = "Durra describes an application as a set of components
(application tasks and communication channels), a set
of alternative configurations showing how these
components are connected at runtime, and a set of
conditional configuration transitions that take place
at runtime. A ``cluster'' is a physical grouping of
components at a node; a ``cluster manager'' is
responsible for starting and terminating application
processes and links, for passing messages between
components, for monitoring reconfiguration conditions,
and for carrying out reconfigurations. The Durra
runtime requires that processes be quiescent before
reconfiguring; Durra relies on processes to declare
themselves quiescent explicitly by making a call to
their cluster managers. If a process does not quiesce
in a timely manner, the cluster manager times out.
While Durra tolerates component failures, it does not
tolerate cluster failures.",
pages = "128--139",
}
@Misc{apt-howto,
title = "{APT} {HOWTO}",
key = "APT",
howpublished = "\url{http://www.debian.org/doc/manuals/apt-howto/}",
}
@InProceedings{soules03system,
author = "Craig A. N. Soules and Jonathan Appavoo and Kevin Hui
and Robert W. Wisniewski and Dilma Da Silva and Gregory
R. Ganger and Orran Krieger and Michael Stumm and Marc
Auslander and Michal Ostrowski and Bryan Rosenburg and
Jimi Xenidis",
booktitle = "Proc. of the Usenix Technical Conference",
title = "System Support for Online Reconfiguration",
year = "2003",
annote = "Implements dynamic interposition and hot-swapping for
components in the K42 operating system. In the common
case, nothing is interposed; interposers installed
dynamically by modifying a call indirection table.
Interposition can add wrappers to a component that can
take action before and after each call to the
component, like a profiler. Interposition also enables
hot-swapping: an interposed Mediator blocks new calls
to the component, lets the old calls drain, transfers
state to the new component, then unblocks the calls.
This scheme depends on the fact that requests to a
component are short-lived, and this kind of component
change is called Read-Copy Update (RCU).",
}
@InProceedings{mccamant03predicting,
author = "Stephen McCamant and Michael D. Ernst",
booktitle = "10th European Software Engineering Conference and the
11th ACM SIGSOFT Symposium on the Foundations of
Software Engineering",
title = "Predicting problems caused by component upgrades",
address = "Helsinki, Finland",
pages = "287--296",
month = sep,
year = "2003",
}
@Article{appavoo03enabling,
author = "Jonathan Appavoo and Kevin Hui and Craig A. N. Soules
and Robert W. Wisniewski and Dilma M. Da Silva and
Orran Krieger and David J. Edelsohn Marc A. Auslander
and Ben Gamsa and Gregory R. Ganger and Paul McKenney
and Michal Ostrowski and Bryan Rosenburg and Michael
Stumm and Jimi Xenidis",
title = "Enabling autonomic behavior in systems software with
hot-swapping",
journal = "IBM Systems Journal",
volume = "42",
number = "1",
year = "2003",
}
@InProceedings{ajmani03scheduling,
author = "Sameer Ajmani and Barbara Liskov and Liuba Shrira",
booktitle = "HotOS-IX: Ninth Workshop on Hot Topics in Operating Systems",
title = "Scheduling and Simulation: How to Upgrade Distributed
Systems",
year = "2003",
month = may,
}
@Article{weiler02automatic,
author = "Robert K. Weiler",
title = "Automatic Upgrades: {A} Hands-On Process",
journal = "Information Week",
year = "2002",
URL = "http://www.informationweek.com/story/IWK20020321S0011",
annote = "Weiler argues that fully automatic upgrades are
dangerous, since automatic upgrade mechanisms often
introduce incompatibilities in the system. Part of the
problem is that each vendor develops and deploys their
own automatic upgrade system, and systems from
different vendors don't work together (e.g., to detect
and resolve dependencies and incompatibilites).
Standards for automatic upgrade systems would help
address these problems by allowing different vendors'
systems to interoperate. Another thing that could help
is a log of all changes made to a PC's configuration
and a record of when problems occur. This helps users
identify bad upgrades; these upgrades can be removed if
they support ``automatic restoration'' (i.e.,
rollback).",
month = mar,
}
@Article{rauch02optimizing,
author = "Felix Rauch and Christian Kurmann and Thomas M.
Stricker",
title = "Optimizing the distribution of large data sets in
theory and practice",
journal = "Concurrency and Computation: Practice and Experience",
volume = "14",
number = "3",
publisher = "John Wiley & Sons, Ltd",
pages = "165--181",
month = apr,
year = "2002",
url = "http://www.cs.inf.ethz.ch/CoPs/ccpe2002/ccpe2002.pdf",
annote = "[rauch] The problem of installing multiple operating
systems on our 128-node cluster motivated us to do this
study on the distribution of large data sets (basically
hard-disk partitions).",
}
@InProceedings{peterson02blueprint,
author = "L. Peterson and D. Culler and T. Anderson and T.
Roscoe",
booktitle = "In Proceedings of the 1st Workshop on Hot Topics in
Networks ({HotNets}-I)",
title = "A Blueprint for Introducing Disruptive Technology into
the {Internet}",
year = "2002",
URL = "http://citeseer.ist.psu.edu/peterson02blueprint.html",
month = oct,
note = "PlanetLab",
}
@Unpublished{microsoft02managing,
author = "Microsoft Corporation",
title = "Managing Automatic Updating and Download Technologies
in {Windows} {XP}",
year = "2002",
note = "\url{http://www.microsoft.com/WindowsXP/pro/techinfo/administration/manageautoupdate/default.asp}",
}
@Misc{ghemawat02google,
author = "Sanjay Ghemawat",
title = "{Google}, {Inc}., personal communication",
year = "2002",
personal = "Sanjay explained how Google updates its software: they
have several (5?) data centers, and DNS directs clients
to each of them. To upgrade a data center, they change
DNS to point to the other ones, upgrade it, then change
DNS back.",
}
@InProceedings{brown02rewind,
author = "A. Brown and D. A. Patterson",
booktitle = "10th ACM SIGOPS European Workshop",
title = "Rewind, Repair, Replay: Three {R}'s to Dependability",
year = "2002",
address = "Saint-Emilion, France",
month = sep,
}
@Unpublished{ajmani02review,
author = "Sameer Ajmani",
title = "A Review of Software Upgrade Techniques for
Distributed Systems",
year = "2002",
note = "\url{http://www.pmg.lcs.mit.edu/~ajmani/papers/review.pdf}",
month = aug,
}
@Unpublished{ajmani02distributed,
author = "Sameer Ajmani",
title = "Distributed System Upgrade Scenarios",
year = "2002",
note = "\url{http://www.pmg.lcs.mit.edu/~ajmani/papers/scenarios.pdf}",
month = oct,
}
@InProceedings{truyen02consistency,
author = "E. Truyen and W. Joosen and P. Verbaeten",
booktitle = "Proceedings of the International Conference on
Software Maintenance ({ICSM}'02)",
title = "Consistency Management in the Presence of Simultaneous
Client-Specific Views",
publisher = "IEEE Computer Society",
pages = "501--510",
month = Oct # "~3--6,",
year = "2002",
abstract = "This paper is about client-specific
customization of systems that implement an on-line
Internet service in the presence of simultaneous
client-specific views. The problem is that each client
must be able to customize the running system for use in
its own context, without impacting the service behavior
that is delivered to other clients. To solve this, we
propose to customize the system on a per client request
basis, where the system itself consists of a stable
core and several extensions that are injected into the
core as needed. However, this approach brings on its
own several consistency management problems that must
be dealt with in order to make the approach viable. We
give an overview of these problems and present a
management architecture that deals with these
problems.",
}
@Article{wills01open,
author = "Linda Wills and others",
title = "An open platform for reconfigurable control",
journal = "IEEE Control Systems Magazine",
year = "2001",
URL = "http://citeseer.ist.psu.edu/wills01open.html",
annote = "Uses real-time CORBA to implement component-based
control systems, and uses a publish-subscribe
communication bus to loosen component coupling (and
make reconfiguration easier). Components specify input
and output ports along qith QoS constraints (priority,
sample rate, execution time). Reconfiguration can
create components, change port connections, and alter
QoS constraints. Authors propose to use common
controller design patterns to support common
reconfigurations. Cites Oreizy et al. as main previous
work.",
month = jun,
}
@InProceedings{tewksbury01live,
author = "L. A. Tewksbury and L. E. Moser and P. M.
Melliar-Smith",
booktitle = "{IEEE} Intl. Conf. on Software Maintenance ({ICSM})",
title = "Live upgrades of {CORBA} applications using object
replication",
year = "2001",
annote = "Uses replication of CORBA objects to support upgrades
without interrupting service. Rather than allowing the
system to exist in a hybrid state (i.e., where
different objects are at different versions), the
upgrade executes an ``atomic switchover'' that changes
all objects from one version to another. Reliable,
totally-ordered multicast ensures atomicity. If the
upgrade changes an objects' interface, all clients that
use that interface must also be upgraded at the
switchover. Furthermore, all affected objects must be
quiescent when the switchover occurs. The system uses
wrapper functions to loosen this quiescence requirement
(i.e., by translating old calls to new ones). The
system provides an ``upgrade preparer'' tool that
automatically generates wrapper functions and state
transformers given the old and new versions of an
object's code. This work follows that of Kramer and
Magee, Hofmeister and Purtilo, and Bidan et al.",
address = "Florence, Italy",
month = nov,
pages = "488--497",
}
@Misc{liskov01software,
author = "Barbara Liskov",
title = "Software Upgrades in Distributed Systems",
year = "2001",
note = "Keynote address at the 18th ACM Symposium on Operating
Systems Principles",
month = oct,
}
@InProceedings{hicks01dynamic,
author = "Michael W. Hicks and Jonathan T. Moore and Scott
Nettles",
booktitle = "{SIGPLAN} Conf. on Programming Language Design and
Implementation",
title = "Dynamic Software Updating",
year = "2001",
URL = "http://citeseer.ist.psu.edu/article/hicks01dynamic.html",
annote = "[by Steven Richman] Hicks et al. implement a dynamic
update system in a C-like imperative language. Their
system allows for data transformation during an
upgrade. An upgrade consists of dynamically-linked code
and optional state transformer functions. An upgrade's
type safety is guaranteed with a proof-carrying typed
assembly language (it is unclear why the type analysis
cannot be carried out at compile time). New code is
attached to old code by relinking references. A tool
automatically generates simple state transformer
functions based on code changes, minimizing programmer
work. The programmer is required to specify a single
quiescent point in the application at which upgrades
can safely occur, and this point cannot change across
versions. An upgrade happens atomically at the
specified time. The authors apply their upgrade system
to a single-threaded event-driven web server that is
amenable to quiescence identification, but it is not
clear that update timing can be specified easily in
multithreaded or more complex applications. In general,
update timing is an important and difficult problem in
systems that seek to upgrade running applications
mid-execution.",
pages = "13--23",
}
@InProceedings{duggan01typebased,
author = "Dominic Duggan",
booktitle = "Intl. Conf. on Functional Programming",
title = "Type-Based Hot Swapping of Running Modules",
year = "2001",
URL = "http://citeseer.ist.psu.edu/duggan01typebased.html",
pages = "62--73",
}
@Misc{almeida01transparent,
author = "Joao Paulo A. Almeida and Maarten Wegdam and Marten
van Sinderen and Lambert Nieuwenhuis",
title = "Transparent Dynamic Reconfiguration for {CORBA}",
year = "2001",
URL = "http://citeseer.ist.psu.edu/almeida01transparent.html",
annote = "Uses ORB extensions to intercept requests and thus
passivate objects for reconfiguration. Request
interceptors queue requests made during a
reconfiguration. A ``reconfiguration manager'' handles
the creation and deletion of objects, state transfer
(and translation), and object passivation. A ``location
agent'' provides indirection between clients and server
objects; this allows clients to locate objects that
migrate during a reconfiguration. The main differences
between this and Bidan et al. are (1) support for
re-entrant invocations, (2) support for atomic
replacement of multiple objects, and (3) greater
transparency using ORB extensions.",
}
@Misc{almeida01approach,
author = "Joao Paulo Almeida",
title = "An approach to dynamic reconfiguration of distributed
systems based on object-middleware",
year = "2001",
URL = "http://citeseer.ist.psu.edu/article/almeida01approach.html",
annote = "See ``Transparent Dynamic Reconfiguration'' (Almeida
et al.) for details. This paper provides more
comparisons with related work.",
month = may,
}
@InProceedings{truyen01dynamic,
author = "E. Truyen and B. Vanhaute and W. Joosen and P.
Verbaeten and B. N{\o}rregaard J{\o}rgensen",
booktitle = "Proceedings of the 23rd International Conference on
Software Engeneering ({ICSE}'01)",
title = "Dynamic and Selective Combination of Extensions in
Component-Based Applications",
publisher = "IEEE Computer Society",
pages = "233--242",
month = May # "~12--19,",
year = "2001",
abstract = "Support for dynamic and client-specific
customization is required in many application areas. We
present a (distributed) application as consisting of a
minimal functional core - implemented as a
component-based system, and an unbound set of potential
extensions that can be selectively integrated within
this core functionality. An extension to this core may
be a new service, due to new requirements of end users.
Another important category of extensions we consider,
are n on-functional services such as authentication,
which typically introduce interaction refinements at
the application level. In accordance to the separation
of concerns principle, each extension is implemented as
a layer of mixin-like wrappers. Each wrapper
incrementally adds behavior and state to a core
component instance from the outside, without modifying
the component's implementation. The novelty of this
work is that the composition logic, responsible for
integrating extensions into the core system, is
externalized from the code of clients, core system and
extensions. Clients (end users, system integrators) can
customize this composition logic on a per collaboration
basis by 'attaching' high-level interpretable extension
identifiers to their interactions with the core
system.",
}
@InProceedings{ritzau00dynamic,
author = "Tobias Ritzau and Jesper Andersson",
booktitle = "{Java} for Embedded Systems Workshop",
title = "Dynamic Deployment of {Java} Applications",
year = "2000",
annote = "\textsc{JDrums}: Uses lazy upgrades to convert classes and
objects to new versions. An upgrade consists of a class
converter that converts static class data and an object
converter that converts instances. The system uses a
modified JVM to keeps old versions of classes and
objects around so that old references continue to
work. Does not comment on the problem of state
divergence between different versions of the same
object. Uses Jini to deploy upgrades in distributed
systems, but has no mechanism to synchronize or
otherwise schedule distributed upgrades. Converter
routines cannot call methods of old or new objects --
they can only copy and convert object state.",
address = "London",
month = may,
}
@InProceedings{rauch00partition,
author = "Felix Rauch and Christian Kurmann and Thomas M.
Stricker",
booktitle = "Proceedings of the IEEE International Conference on
Cluster Computing 2000",
title = "Partition Repositories for Partition Cloning---{OS}
Independent Software Maintenance in Large Clusters of
{PCs}",
address = "Chemnitz, Germany",
month = nov,
year = "2000",
url = "http://www.cs.inf.ethz.ch/CoPs/publications/#cluster2000",
annote = "[rauch] In this paper we looked at the problem of
minimizing the amount of data to archive (or upgrade)
multiple versions of installations in a multi-use
cluster.",
}
@Unpublished{microsoft00rolling,
author = "Microsoft Corporation",
title = "Windows 2000 Clustering: Performing a Rolling
Upgrade",
year = "2000",
url = "http://www.microsoft.com/windows2000/techinfo/planning/incremental/rollupgr.asp",
note = "(No longer available)",
annote = "Describes how to maintain service while upgrading a
cluster of NT or Windows 2000 servers with a new
service pack. Servers are upgraded one-at-a-time, and
resources and clients automatically fail over and fail
back between nodes in the cluster, even when those
nodes are running different versions (i.e., the cluster
is in mixed mode).",
}
@InProceedings{malabarba00runtime,
author = "Scott Malabarba and Raju Pandey and Jeff Gragg and
Earl Barr and J. Fritz Barnes",
booktitle = "European Conf. on Object-Oriented Programming",
title = "Runtime support for type-safe dynamic {Java} classes",
year = "2000",
annote = "[by Steven Richman] Malabarba et al. bring dynamic
classes to {Java} by modifying the virtual machine and
adding a dynamic class loader. Type correctness is
checked when an upgrade in compiled. Specifically,
their compiler guarantees that the set of new and
changed classes comprising an update forms a complete
upgrade if the changes are applied atomically. In their
implementation, upgrades occur in an atomic global
update, but objects are transformed lazily, as in our
persistent object base. A quick initial marking phase
tags all reachable objects that need to be upgraded,
and any subsequent references to marked objects trap to
an upgrader that suspends all threads and brings the
objects up to date. No general state transformation
facility is provided; fields are simply copied from old
objects to new objects and new fields are initialized
to default values.",
}
@Article{lerner00model,
author = "Barbara Staudt Lerner",
title = "A model for compound type changes encountered in
schema evolution",
journal = "ACM Transactions on Database Systems",
volume = "25",
number = "1",
year = "2000",
url = "http://citeseer.ist.psu.edu/staudtlerner96model.html",
annote = "Excellent related work on schema evolution systems.
Focus is on identifying (inferring) steps in schema
evolution from before and after definitions (i.e., does
an intelligent diff to infer refactorings). Also
generates derivation functions to initialize new state
from old values (i.e., state transform functions).",
pages = "83--127",
}
@InProceedings{senivongse99enabling,
author = "Twittie Senivongse",
booktitle = "Intl. Symposium on Dist. Objects and Applications",
title = "Enabling Flexible Cross-Version Interoperability for
Distributed Services",
year = "1999",
annote = "Describes how to use mappers to enable cross-version
interoperation during distributed upgrades. Argues that
this interrupts service less than systems that
atomically upgrade all clients and servers that use a
changing interface. Describes a UI that guides the
evolver (upgrader) through automatic generation of
mapper (simulation) code. Restricts autogenerated
wrappers to 1-to-1 mapping from old method calls to new
ones (in general, the wrapper could call multiple
methods on many different servers). Categorizes the
supported kinds of interface evolution, including
subtyping. Also discusses chains of mappers, backwards
mappers (new-to-old), propagation of supertype changes
to subtypes, and optimizations (like deprecating old
mappers).",
address = "Edinburgh, UK",
}
@InProceedings{hall99cooperative,
author = "Richard S. Hall and Dennis Heimbigner and Alexander L.
Wolf",
booktitle = "Intl. Conf. on Software Engineering",
title = "A Cooperative Approach to Support Software Deployment
Using the {Software} {Dock}",
year = "1999",
URL = "http://citeseer.ist.psu.edu/hall99cooperative.html",
pages = "174--183",
}
@InProceedings{wohlstadter02framework,
author="Eric Wohlstadter and Brian Toone and Prem Devanbu",
title="A framework for flexible evolution in distributed heterogeneous systems",
booktitle = "International Workshop on Principles of Software Evolution",
address="Orlando, Florida",
pages="39--42",
year=2002,
isbn="1-58113-545-9",
}
@InProceedings{devanbu99security,
author = "P. Devanbu and M. Gertz and S. Stubblebine",
booktitle = "{ICSE} Workshop on Software Engineering over the
Internet",
title = "Security for Automated, Distributed Configuration
Management",
year = "1999",
annote = "Identifies security issues for automatic software
management and a research plan to address them.
Integrity must be guaranteed for the software being
shipped from vendor to user, the user's configuration,
and messages from user to vendor that describe
configurations. Authentication is needed to identify
software vendors and licenced software users. Privacy
protections are needed for software components (because
of their intellectual property value) and for software
configurations (because they may reveal sensitive
data). Finally, delegation is needed, e.g., to let
administrators delegate configuration control to
vendors and to let vendors delegate configuration
checking to a testing lab.",
month = apr,
}
@InProceedings{cook99highly,
author = "Jonathan E. Cook and Jeffery A. Dage",
booktitle = "Intl. Conf. on Software Engineering",
title = "Highly Reliable Upgrading of Components",
year = "1999",
annote = "Maintains and runs multiple versions of a component
simultaneously to avoid introducing errors at upgrades.
For example, suppose version 1 of a component has a
method whose input is any nonnegative number, and
suppose version 2 accepts any number. Then, this system
uses version 2's output for nonpositive numbers and
uses version 1's for positive numbers (the idea being
version 1 probably works fine for positive numbers, but
version 2 might be broken). The system monitors version
2's output on positive numbers and records statistics
on whether it makes any errors. The upgrader can
examine these statistics to determine whether version 1
can be removed in favor of version 2. This work does
not seem to address the problem of state divergence
between components (i.e., since version 2 sees some
requests that version 1 does not, version 2's state may
diverge from version 1's).",
address = "Los Angeles, CA",
}
@Unpublished{barnes99rpm,
author = "Donnie Barnes",
title = "{RPM} {HOWTO}",
year = "1999",
note = "\url{http://www.rpm.org/RPM-HOWTO/}",
month = nov,
}
@InProceedings{wrembel98object,
author = "Robert Wrembel",
booktitle = "13th International Symposium on Computer and
Information Sciences (ISCIS)",
title = "Object-Oriented Views: Virtues and Limitations",
address = "Antalya",
month = nov,
year = "1998",
URL = "http://citeseer.ist.psu.edu/wrembel98objectoriented.html",
URL = "http://citeseer.ist.psu.edu/524487.html",
annote = "A survey of techniques for supporting object-oriented
views. Relevant to upgrades because simulation objects
for different versions act like different views on the
state of a node.",
}
@InProceedings{oreizy98architecture,
author = "P. Oreizy and N. Medvidovic and R. N. Taylor",
booktitle = "Intl. Conf. on Software Engineering",
title = "Architecture-based runtime software evolution",
year = "1998",
annote = "Supports runtime software evolution by adjusting
``connectors'' between components dynamically.
Connectors are themselves components that regulate
communication and abstract the underlying mechanisms.