Foundations of Enterprise Software Deployment - CiteSeerX

Foundations of Enterprise Software Deployment T. Coupaye and J. Estublier DASSAULT SYSTEMES & IMAG LSR Joint Laboratory Actimart Bat. 8, 2 Allée de Roumanie 38610 Gières, France {Thierry.Coupaye,Jacky.Estublier}@imag.fr Abstract While Software Engineering has mainly focused so far on software development, software deployment is now emerging as a new research field. Software or Application deployment is a complex process which covers all the activities that have to be carried out from the end of the development itself on the producer sites to the actual installation and maintenance of the application on consumer computers. This article set up grounds for enterprise software deployment which is the large-scale deployment of complex applications in large companies.

1. Introduction Application (Software) deployment is a complex process which covers all the activities that have to be carried out from the end of the development itself on producer sites to the actual installation and maintenance of the application on consumer computers. Examples of such activities are the packaging of the software on the producer sites, its transfer from producer site to consumer sites, its installation, update and eventually its uninstallation on consumer sites. It is worth noting that until recently software engineering focused on the development and evolution of applications. Very few research works dealt with the delivery, installation and maintenance of applications on consumer sites. Whether this was considered as unimportant or too complex or hardly feasible with respect to available technologies, application deployment was done in a ad-hoc and very poorly automated way (installation scripts basically). The software industry, however, is becoming very sensitive on the subject. The manual approach of deployment is not viable much longer. Dassault Systèmes is one of the world leaders in CAD/CAM solutions. CATIA, its main product, is very large (millions of lines of code) and composed of hundreds of components. Such large-scale deployments are hazardous because:

• applications are more and more complex; they contain numerous components, versions and variants, • applications evolve more and more quickly (a few months between two consecutive released versions), • applications rely on other applications, components or services such as operating systems, middleware, servers (databases, web), editors, compilers, etc. • computing environments have shifted from mainframes to workstations, • coexisting hardware and software targets are more and more numerous (flavors of Unix or Windows). Now, among Dassault Systèmes, clients are very big companies such as Boeing or Chrysler in which CATIA is deployed on thousands of seats. This aspect of largescale deployment, that we call enterprise software deployment, adds on some new hazards. Deployment in this context must satisfy some constraints: • Temporal constraints: the deployment must occur following strict scheduling and synchronization constraints; for example simultaneously on all seats (big bang), or incrementally following well defined paths. • Consistency constraints: the different instances of the application, installed on each seat, are likely to interact with each other. A number of compatibility constraints between the different application versions are to be observed. • Criticality: deploying a vital application on all seats simultaneously is a very risky operation that may hamper the whole company from performing its job. For all these reasons, it is becoming crucial to minimize the deployment time and cost, and to avoid risks of production breaks in consumer enterprises. The software engineering research community with the work on Software Dock [1] seems to show some interest in software deployment. Even so we argue that if there is no tool covering the whole deployment process yet, there are however many domains in computer science related to deployment. Among these technologies are (see Fig. 1):

Software Description Formalisms (SDF) [2,3,4], Organization Description Formalisms [5,6], Software Configuration Managers (SCM) [7,8], Package Managers (PM) [9,10], Content Delivery systems and push technology (CD) [11,12,13,14] , Installation Tools (IT) [15,16,17,18], Application Management Systems (AMS) [19,20,21,22,23] and Configurable Distributed Systems (CDS) [24,25].

Producer

SDF SCM PM LAN

WAN

Enterprise Deployment

CD

ODF

Enterprise

AMS CDS

IT User

LAN

Fig. 1 Enterprise Software Deployment and Concurrent Technologies. Our aim in this article is to set up grounds for enterprise application (software) deployment by stressing that enterprise deployment spans three conceptual layers: the Producer, Enterprise and User layers. Also these grounds could be used for developing deployment infrastructures which would automate as much as possible the deployment activities. Existing technologies only cover one or two of the layers mentioned above (cf. Fig. 1): SDF, SCM and PM focus on activities performed at the producer level. CD and IT deal with the delivery of applications from a producer site to consumer user computers. AMS and CDS deal somehow with the enterprise and user layers but they generally adopt a centralized approach in which the enterprise layer can be considered as the producer layer actually – and thus the enterprise layer is missing in a sense. The enterprise layer is thus the less covered one by existing technologies and research works. Yet, it is of primary importance according to us for two reasons: • Enterprise customized applications: professional applications most often offer capabilities for specific customer extensions, either using an API, or a specific language. This is especially true in the case of Dassault Systèmes. Boeing, for instance, has developed over time many CATIA extensions which size is about the same as the size of CATIA itself. It is at the enterprise level that the producer application and the enterprise extensions are

assembled together to constitute the application that will be actually deployed on user computers. • Large consumer enterprises need to control as much as possible the overall deployment process, especially with respect to scheduling, synchronization and consistency of the deployment activities in order for applications to be always operational and to avoid production stops. The deployment process is based on the organization of the consumer enterprises (teams, positions, projects, etc.) and on deployment policies defined in theses enterprises (likely different ones from one application to another). We see application deployment as a process, which is thus described in terms of activities which represent steps in the process; models and policies which are products that represent data that flows between activities; and resources (humans, hardware and software) needed by the process. The remainder of this article focuses on the enterprise deployment process by describing deployment activities in Section 2 and deployment models and policies in Section 3. These two sections also give pointers to related works and products (See [27] for a more detailed description of related technologies). Finally, Section 4 concludes and introduces the ongoing efforts we are pursuing to develop an enterprise deployment infrastructure.

2. Deployment Process Enterprise deployment can be seen as three interconnected processes since activities are not performed on the same sites: producer, enterprise and user; nor they have the same organizational objectives and responsibilities. The objective of a producer is mainly to pack and advertise what it wants to deliver to its consumers. The goal at the enterprise level is to prepare the physical deployment on the users computers inside the enterprise. The main activities here are the assembly of different components or applications that will form the final application to be deployed; and the specification of deployment policies, which specify when and how the physical deployment will be performed. The objective at the user level is the actual physical deployment, i.e., the assembly and maintenance of an operational version of the application on each user’s computer.

2.1. Producer Deployment The activities presented here (cf. Fig. 2) are under the producer’s responsibility. They represent the link between the application development and the application

deployment. From a producer’s point of view, application deployment covers two activities: release and unrelease. Releasing an application covers the activities that have to be done before the actual transfer of the application to consumers. The release activity has two sub-activities: pack and advertise. Packing an application consists in building a self-contained package that contains the application artifacts, the application model and other information which will be necessary to manage (build, configure, test, activate, etc.) the application after its transfer to consumers. The package should be in an easily transferable form (encoded, compressed, etc.) most commonly used by electronic means.

build & test tools & process

application model

select

configure

2.2. Enterprise Deployment Activities described in this section are carried out at the level of the consumer enterprise. They are preparatory activities to the physical deployment on end users’ computers. This level is crucial for enterprise deployment because it reflects the organizational choices concerning the deployment process in the whole enterprise.

released application package

unrelease

release

as Red Hat’s RPM [9] or HP-UX’s Mkpck command [10]. Installation Tools such as InstallFromTheWeb [15], NetDeploy [16], InstallManager [17] and AutoInstall [18] also provide packing facilities.

SDK

build retire

Push/pull

pack advertise PDS

transfer EDS

released application package

SDK released application package

SDK

Fig. 2 The Deployment Process at the Producer Level

Unreleasing an application is suppressing the producer’s support to consumers for this application. The main activity here is retire. It is assumed that an enterprise deployment infrastructure would provide on the producer’s site an application repository for the storage and retrieval of applications distributed by this producer. When retiring an application, the infrastructure must make sure that this activity is painless to other applications in the repository (they might share some components for instance). Advertise is a sub-activity of both the release and unrelease activities. Advertising is letting know consumers that a new or revised version of an application is released or that support for an application is cancelled. The advertisement can include any form of communication such as telephone, postal mail, etc. In an automated deployment infrastructure, it would for instance make use of e-mails, newsgroups to notify people -- or other notifications (events) to notify parts of the infrastructure itself (agents) on the consumer side. As far as existing technologies (see Fig. 1) are concerned, most producer deployment activities are covered by Software Configuration Systems such as Adele [7] or Clearcase [8]; and Package Managers such

Fig. 3 The Transfer Activity from a Producer’s Site to Consummers’Sites.

The first activity that follows the release of an application is the transfer of this application to consumer enterprises (cf. Fig. 3). As a matter of fact, it is questionable whether this activity is undertaken on the consumer’s site or on the producer’s site. From a technical point of view, in an automated deployment infrastructure, control of the transfer activity from the producer’s site tends to imply the use of a push technology; while control of the transfer activity from the consumer’s site tends to imply the use of a pull technology. We believe transfer would be more likely undergone on consumer’s site not for technological reasons (although crossing firewalls could be a bit of an obstacle) but for more political reasons: large enterprises which deploy complex applications would very likely like to have as much as possible control over the deployment process. Perhaps small enterprises would go for a push technology, especially with small and non critical applications. However, at this point, the important matter is that there exists a transfer activity, which is a real activity as it implies organizational and technical issues.

The transfer activity is of obviously covered by Content Delivery Systems such Poincast [11] or Marimba’s Castanet [12]; and by push technology whose representatives are Softwired’s iBus [13] or TIBCO’s TIB/Rendez-vous [14] for instance. Once the released application package has been transferred on the consumer’s site, the assemble activity begins (see Fig. 2). This activity is one of the most time and effort consuming. It consists in building a complete application – which will be the typical application deployed on end-users machines inside the enterprise. Building blocks or components come from possibly different released application packages coming from possibly different producers – plus extensions developed by the consumer enterprise itself. We believe this activity is crucial to enterprise deployment of complex applications. It is so in the context of Dassault Systèmes: the main application CATIA is already complex (several hundreds of components) and voluminous (several millions of lines of code) by itself – but the extensions developed by consumers can be as huge or even bigger. This is the case with the Boeing Company for instance, which has developed over the years a lot of components devoted to the airplane design and construction. released application package

deployable extensions package

SDK

EDS assemble

unpack

compose

enterprise model

test

enterprise application package

pack

deployment policies

EDS predispose

deployment model

advertise

Fig. 4 The Deployment Process at the Enterprise Level The assemble activity is broken down into four subactivities: unpack, compose, test and pack. After the unpack activity, components of the released application package are available directly. Then starts the compose activity. This is really the core of the assemble activity. It takes a significant amount of time and human resources and cannot be fully automated. It consists in putting together components coming from different sources. This is mainly a “manual" programming activity. Tools provided by the Producer can be useful, not to say indispensable. These tools can be a complete developing environment or Software Development Kit (SDK in the

Figures). Dassault Systèmes provides a complete SDK because CATIA is developed using special programming conventions that need special pre-processors, libraries etc. The result of the compose activity is a complete prototypal or typical application which can then be tested (using the build and test processes that are parts of the released application package) and finally packed (it is then the enterprise application package) again before its transfer to each end-user desktop. The assemble activity specifies what will be deployed in the enterprise. The next activity, the predispose activity, specifies where, when and how it will be deployed. It is probably the activity most characteristic of enterprise deployment (and the less studied so far as well) for it establishes a link between the (options of the) enterprise application and the organization of the enterprise (the enterprise model) – plus a set of deployment policies which control the deployment process. Deployment policies would probably be described as a set of constraints (team A should get a new version of an application before team B, etc.). Its result is a generated deployment model -- at least partly generated and then manually extended -- which specifies for each user (computer), what version of the application he/she will get according his/her position, role and activities, and when according to the team or project he/she belongs to and their relations to other teams (these information are provided by the enterprise model). The deployment model specifies as well the overall control, scheduling and synchronization between all deployment activities in the enterprise; as well as with the control of each specific activity. The deployment model is a process model that can be seen as a scenario that will be interpreted by the deployment infrastructure to perform automatically deployment activities on each end-users desktops. It is our belief that, if feasible, the generation of the deployment model, as well as its interpretation by a dedicated process engine could lead to substantial gains, both in the time required to prepare a deployment, and in the reduction of errors. Then again an advertise activity takes place. This time the advertisement is internal to the enterprise. We can then assume it involves less technical challenges than the advertisement we have seen before– but it can be exactly the same considering the extended (an enterprise along with its producers, sub-contractors, clients) or virtual enterprises (geographically or organizationally dispersed enterprises). Also the deployment model could specify the advertise activity, i.e., describe when and to whom the advertisement should be done. Existing technology provide almost no support for these activities. This is especially true for the predispose activity which is nonetheless the core of large-scale

enterprise software deployment according to us. This is thus at this level that forthcoming works on deployment should focus.

2.3. User Deployment Activities carried out at the enterprise level introduced in the previous section finally come up with a deployable application package which specified what will be deployed; and a deployment model which specifies when, how and to whom it will be deployed. Everything is then ready to actually deploy the application on end users’ computers. Again this part of the deployment (physical deployment) is in fact a set of interrelated activities.

Enterprise application package

on the Software Dock with semantics slightly changed to take into account the enterprise level, which does not explicitly exist in the Software Dock. Update is thus a modification of the deployed application in response to a modification on the Producer Site or the Enterprise Site. Adaptation is a modification of the deployed application in response to a modification on the End User Site. i.e., a modification in the resources available on this computer. The update and adapt activities are special cases of the install activity. The three of them have the same two subactivities: configure and build.

executable application

site model

deployment model

activate

test

deactivate UDS

transfer

dispose

select

unpack

executing application

UDS

deployable application

reconfigure install

configure

update

adapt

uninstall

UDS

executable application

build UDS

Fig. 4 Build-time Activities on User Sites

Some activities are build-time activities (cf. Fig. 5). The first of them is the transfer from the enterprise site to each user’s site. The second activity is dispose. This is a preparatory activity pretty much like the predispose activity at the enterprise level. This activity takes as inputs the deployable application package and the deployment model which have been set up at the enterprise level; and a site model which represent the hardware and software configuration of the considered user desktop computer. This activity has two subactivities: select and unpack. The goal of the select activity is to select the applications options with respect to the site model. For instance, a given option of the application might require at least 64 Megabytes of main memory, while another might work with 32 MB. If the considered target computer has only 32 MG then the second option of the application would actually deployed on this computer. The deployable application can then be installed, updated, uninstalled, etc. We make use of the update and adapt concepts, which have been introduced in the work

Fig. 5 Runtime Activities on User Sites

Other activities are runtime activities (cf. Fig. 6). Activation is all the operations such as launching executables, daemons, etc. that are needed in order to make the application ‘up and running’. Deactivation is the opposite, i.e., the shutdown of the application. The test activity is introduced here as a runtime activity, but of course it can be part of the build time activities since static tests can be done without the whole application running. Finally the reconfigure activity depicts dynamic reconfiguration as described in the configurable distributed systems literature, i.e., addition, removal, update or relocation of components while the application is running. User (or physical) deployment is the part of the overall deployment process that is best covered by existing technologies. Installation Tools provide most build-time activities with the notable exception of the test activity though. Configurable Distributed Systems such as ArchShell [24] or Arunja [25] focus on runtime activities. Application Management Systems such as HP Open View’s Sofware Distributor [19], Novell’s ZENworks [20], Tivoli Enterprise’s Software Distribution [0], Amdahl’s EDM ADS [21], Tivoli

Enterprise [22] and Microsoft’s System Management Server (SMS) 2.0 [23] cover almost all activities. Their purpose is to manage applications deployed on corporate LANs. They are based on highly centralised client/server architecture. Inside a LAN, one server is responsible for application releases and deployments on client computers. Application Management Systems are thus very relevant to enterprise deployment. Still they suffer from serious drawbacks. First, they only cover two levels: enterprise and user -- with the enterprise acting as a producer actually. And then, as a consequence, they offer poor support for deployment policies and models which are described in the next section.

3. Models and Policies Products and resources are the data which flow between activities; and hardware and software resources required by the deployment process. These informations are captured by four models introduced hereafter: the application, enterprise, deployment and user site models.

3.1. Application Models An application model is an abstraction of this application. Besides the application artifacts themselves (files, scripts, documentation, etc. that compose the application), the application model should provide a description of the application architecture which describes the: • components of the application, their versions and options, • compatibilities between versions of components, • constraints (hardware and software), • external dependencies (dependencies with components and applications not provided by the same producer),

•

other miscellaneous information such as contact information, dates of release, etc. The formalism offered to express application models could also allow for an algebra to add, remove or replace components and connectors. This is important since deployment is not only concerned with installation but also with maintenance of an installed application. Among related technologies (cf. Fig. 1), Installation Tools, Application Management Systems and Configurable Distributed Systems offer interesting (with respect to software deployment) application models. Software Configuration Systems and specific System Description Formalisms such as OSD/CDF [2], CIM (MIF/AMS) [3] and DSD [4] offer richer models however. Software variability (multiple versions, multiple

variants) is the less covered aspect except in DSD that is a very solid proposition.

3.2. Enterprise Models An enterprise model is an abstraction of this enterprise that should describe its organization in terms of teams and sub-teams, agents (humans), positions (manager, engineer) and roles (programmer, tester, etc.). This is basically what is proposed by existing organization models such as Actor Dependency [5] and Organization and Process Together [6]. Enterprise models might as well describe projects. The concept of project is becoming central to more and more enterprises. Projects are generally transversal to the ‘static organization’ (teams, positions, roles). Enterprise model might as well describe the process and data-flow used in the organization – which might be useful for deployment. For instance, if the application models indicates that a given document has a new internal format, and the data-flow indicates that this document made by team A must be transferred to a team B within 3 weeks, then a given deployment activity in team B must be realized within 3 weeks after team A. Also something that might be very useful as far as automated deployment is concerned is a link between the organization and the agents’ (users) computers. This kind of information is missing from most existing organization models.

3.3. Deployement Policies and Models Deployment policies represent decisions taken at the enterprise level concerning what should be deployed to whom, and when and how this should be done. As depicted by Fig. 4, we see a deployment model as a process model that is somehow generated based on the application and enterprise models; and some deployment policies. A Deployment model is a scenario that can be interpreted by a deployment infrastructure (that might include a process engine for instance) to perform physical deployment on user desktops. Selection On the one hand, as we have seen before, an enterprise model establishes a link between the organization of the enterprise and the user’s sites. On the other hand, a deployment model should establish a link between the organization of the enterprise and the application, i.e., select and associate a given configuration to a team, a position or a role. By combining the two, a deployment model would then establish a link between a configuration of the application and each user site. The deployment

infrastructure would then know which configuration has to be deployed on each site. Scheduling and Synchronization A deployment model could specify the type of scheduling used in the enterprise. Scheduling policies can be for instance: • Big-Bang: all enterprise sites must switch at the same time; • Incremental: a scheduling is established based on projects, teams, positions, roles or sites. In this case, several synchronization policies between the activities on each site can be established: as soon as possible, by deadlines, etc. • Continuous: each site is autonomous and performs the deployment activities when it wishes to, as long as it satisfies the consistency constraints. Process Control A deployment model could specify different kinds of policies to control the overall deployment process: • Automatic, manual or semi-automatic. In the automatic mode, the deployment process is completely silent and performs automatically the different activities. In the manual mode, it asks for confirmation to the user before performing any activity. In the semi-manual mode, the user can specify which activities can be performed automatically and which must be performed manually. • Recoverable or compensable. In case of crash during a deployment activity, if recoverable, the system. comes back in its previous consistent state; if compensable, the system performs an alternative action. • Simple or recursive. In the simple mode, if an activity fails because some resources are missing, the infrastructure uses the recovery or compensation mechanism as explained above. In the recursive mode, the infrastructure tries to get the missing resources by itself. • Log should be built to keep a trace of the process work or not. • Etc. Activity Control A deployment model could as well specify some finer grained policies to control each individual activity. For instance, activities can be activated or deactivated (update and adapt for instance if the enterprise does not want to deploy each revision of the application). Another example would be to describe specific options. For instance, if the advertise activity should make use of e-mails, newsgroups or both; if the transfer activity should use push or pull technology, etc. Installation Tools and Application Management Systems offer some basic deployment policies. This is however, according to us, one crucial point with respect

to enterprise deployment that is very poorly covered by existing technologies. This is presicely the distinction we make between deployment incarnated by the Software Dock and other technologies and enterprise deployment we introduce in this article.

3.2. Site Models Sites models are abstractions of end users desktop computers on which applications will be physically deployed. They can be used by a deployment infrastructure to adapt the deployment model defined at the enterprise level to each individual desktop. Site models should exhibit hardware and operating system information such as the kind of processor, processor frequency, available memory and disk space, operating system, version, etc.; and software information such as general tools available (editors, compilers, etc.) and already deployed components and applications. The latter is of primary importance because some components may be shared by distinct applications, their update or removal should thus be very cautious. Already Application Management Systems such as HP’s Open View [19], Novell’s Zen [20] or Amdahl ADS [21] define ad-hoc site models and formalisms to register and query site information. Microsoft and Tivoli propose (Application Management Specification), a AMS1 format that shall be used by all kind of application management systems on Windows NT platforms. A part of AMS is dedicated to site description (hardware configurations are described by more than 200 parameters!). It is foreseeable that site models will be largely available on every platforms (Windows, Unix, etc.) in a near future. The question here is to know if these models will be adequate to deployment infrastructures or is the latter will have to offer ad-hoc models and formalisms.

3.2. Conclusions and Ongoing Works We aim at taking application deployment covered by existing technologies and emerging researches a step further in order to tackle enterprise application deployment. Characteristics of enterprise deployment are the followings: • It must be able to deal with complex applications, which are made of multiple components coming from multiple producers including the consumer 1

AMS is a superset of the Distributed Management Task Force’s (DTMF) MIF (Management Information Format). Both AMS and MIF should become part of the emerging standard CIM (Common Information Model) from the DTMF (see http://www.dmtf.org).

enterprise itself. These components are assembled at the enterprise level in order to construct the actual application that can be then tested and validated before its actual physical deployment in the enterprise. • The deployment process should make use of the organization of the enterprise in terms of teams, positions, roles, projects, etc. • The deployment process should allow for the specification of deployment policies and used for configuration selection, scheduling and synchronization. This article aims at defining the foundations of enterprise application deployment. It did not say anything about the development of environments capable of supporting enterprise application deployment. Our mid to long term purpose is of course to develop such an infrastructure. It will probably be based on an existing tool (an Installation Tool or an Application Management System) for physical (user) deployment support, the Apel tool [26] for enterprise deployment process modeling and support, and active repositories for storing the different models: application, organization, deployment, user site. The infrastructure will reflect the three layers of enterprise deployment. It will be made of three main components: a Producer Deployment Server, an Enterprise Deployment Server and a User Deployment Server (PDS, EDS and UDS respectively), which will communicate through the network. Be that as it may, we believe the design of such an enterprise deployment infrastructure requires an special design effort for it must offer industrial qualities such as reliability and robustness (the infrastructure should preserve the integrity of deployed applications by offering recovery or/and compensation mechanisms for instance), security, trackability and scalability -- which are not addressed by existing technologies that claim to support application deployment.

4. References [1] R. S. Hall, D. Heimbigner, A. van der Hoek, and A.L. Wolf. “ The Software Dock: A Distributed, Agent-based Software Deployment System“, Technical Report CU-CS-832-97, Department of Computer Science, University of Colorado, 1997. [2] A.van Hoff, H. Partovi, and T. Thai. “The Open Software Description Format (OSD)”. Microsoft Corp. and Marimba Inc, August 1997, (http://www.w3.org/TR/NOTE-OSD.html). [3] Distributed Management Task Force. “Common Information Model (CIM) Specification. Version 2.0”, March 1998, (http://www.dmtf.org/spec/cim_spec_v20/).

[4] R.S. Hall, D. Heimbigner, and A.L. Wolf. “Specifying the Deployable Software Description Format in XML”, SERL Technical Report CU-SERL-207-99, Software Engineering Research Laboratory, Department of Computer Science University of Colorado, March 1999. [5] E. S. K. Yu and J. Mylopoulos. “Modelling Organizational Issues for Enterprise Integration, Proc. Int. Conf. On Enterprise Integration and Modelling Technology”, Turin, Italy, October 1997. [6] C. B. Seaman and V. R. Basili . “OPT: Organization and process Together”, Proceedings of CASCON'93, IBM Centre for Advanced Studies, Toronto, October 1993. [7] J. Estublier and R. Casallas. “The Adele Configuration Manager”, Configuration Management, Wiley, 1994, pp.99134. [8] Rational Software Corp. “ClearCase Product Summary”, White Paper, 1999, (http://www.rational.com/products/clearcase/prodinfo/media/cc prodsum.pdf). [9] M. Ewing and E. Troan. “The RPM Packaging System”., Proc. of the First Conference on Freely Redistributable Software, Cambridge, MA, USA, February 1996. [10] C. Staelin. “Mkpkg: A Software Packaging Tool”, HP-UX Tech. Report, January 14, 1997. [11] Pointcast, Inc. (http://www.poincast.com).

“Poincast”,

1998,

[12] Marimba, Inc. “Introducing Castanet”, Technical White Paper, 1999, (http://www.marimba.com/products/castanet.htm). [13] Softwired, Inc. “Developing Publish/Subscribe Applications with iBus”, Technical White Paper, 1999, (http://www.softwired-inc.com/ibus). [14] TIBCO Software Inc. “TIB/Rendez-vous”, White Paper, 1999, (http://www.rv.tibco.com/whitepaper.html). [15] InstallShield. “InstallFromTheWeb Version 2.0”, White Paper, 1999, (http://www.installshield.com). [16] Open Software Associates. “NetDeploy 4 Technical Specification”, White Paper, 1999, (http://www.netdeploy.com). [17] Wise Solutions, “InstallManager”, White Paper, 1999, (http://wisesolutions.com). [18] 20/20 Software. “AutoInstall”, White Paper, 1999, (http://www.twenty.com). [19] Hewlett-Packard. “HP OpenView Software Distributor Quick Reference”, Technical White Paper, February 1996.

[20] Novell, Inc. “ZENworks”, (http://www.novell.com/products/nds/zenworks).

1999,

[21] Amdahl, Inc. “Desired State Software Management”, White Paper, 1999, (http://www.amdahl.com/aplus/deploy/edmlit.htm). [22] Tivoli Systems, Inc. “Tivoli Software Distribution”, White Paper, 1999, (http://www.tivoli.com/o_products/html/swdist_ds.html). [23] Microsoft Corp. “Systems Management Server Version 2.0 - Technical Comparison of Systems management Server 2.0 and Novell’s Z.E.N.works 1.1”, 1999, (http://www.microsoft.com/smsmgmt/exec/sms_zen_comp.asp).

[24] P. Oreizy, M. M. Gorlik, R. N. Taylor, D. Heimbigner, G. Johnson, N. Medvidovic, A. Quilici, D. S. Rosenblum, and A. L. Wolf. “Self-Adaptive Software”, Technical Report, UCI-ICS98-27, Department of Information and Computer Science, University of California, Irvine, August 1998. [25] S. K. Shivastava and S. M. Wheater. “Architectural Support for Dynamic Reconfiguration of Large Scale Distributed Applications”, Proc. of the 4th Int. Conf. On Configurable Distributed Systems, IEEE Computer Society, May 1998, pp.10-17. [26] S. Dami, J. Estublier, M. Amiour. “APEL: a Graphical Yet Executable Formalism for Process Modeling.”, Automated Software Enginnering (ASE), March 1997. [27] T. Coupaye and J. Estublier. “Enterprise Software Deployment: Foundations & Related Technologies”. Technical Report RR-1023-I-LSR-11, LSR-IMAG, October 1999.