Endeavors: A Process System Integration Infrastructure Gregory Alan Bolcer and Richard N. Taylor Information and Computer Science University of California, Irvine Irvine, California 92717-3425 {gbolcer,taylor}@ics.uci.edu Phone: (714)824-2704 Fax: (714)824-4056 http://www.ics.uci.edu/{~gbolcer, ~taylor, pub/endeavors/}

Abstract -- As projects evolve, possibly differing in size, complexity, scope, and purpose, the development processes that sup- port the project must evolve to reflect these changes. For a distrib- Similar to the Teamware architecture (its predecessor), uted project, maintaining proper communications, coordinating Endeavors allows the object-oriented definition and specialization between project stakeholders, and maintaining managerial control of the activities, artifacts, and resources associated with a soft- become increasingly important and, unfortunately, increasingly dif- ware development process. The specification of processes and ficult. The Endeavors system is an open, distributed process model- objects can be defined hierarchically; an activity can be further ing and execution infrastructure that addresses communication, coordination, and control issues. Complex processes may require (a) sub-divided into sub-activities, or a software development team distribution of people and processes, (b) event-based and intermedi- resource can be further defined to include team member or sub- ate-format integration of external tools, (c) a low entry barrier team resources. Endeavors’ activity networks define the inter- through ease-of-use and incremental adoption, (d) ability to custom- relationships between activities, artifacts, and resources as well as ize and reuse objects, tools, and policies, and (e) dynamic change of sub-networks. Networks include the definition of control flow, runtime processes, objects, and behaviors. Endeavors’ solution architecture achieves these goals through application of five key data flow, and resource assignments, and can be easily defined design strategies: (1) maintaining multiple object model layers, (2) using the graphical network editor. Activity networks can be exe- implementing the architecture as a set of highly componentized, cuted by an interpreter which sends events to particular objects, lightweight, transportable, concurrent elements, (3) providing cus- triggering handlers which define the object’s behavior. A com- tomization capabilities for each layer of the object model, (4) using a plete discussion of Teamware’s object model is found in [33, 35]. reflexive object model to support dynamic change, and (5) allowing dynamic loading and changing of objects including loading of exe- Endeavors differs from its Teamware heritage, however, as sig- cutable handlers, new object types, and extensions. We discuss these nificant extensions and redesign of the architecture were neces- goals and design strategies, describe the architecture, and describe sary to support a variety of new goals. The achievement of these the current status of the project and its relevance to its own develop- ment.1 goals cumulatively form the basis for an open, extendible process Keywords -- open, distributed process technology, architecture infrastructure and will be discussed in detail in section III. • Distribution. Endeavors has customizable distribution and I. Introduction decentralization policies which provide support for transpar- ently distributed people, artifacts, process objects, and execu- Effective software evolution demands that all stakeholders are tion behavior (handlers). In addition, Endeavors processes, as able to participate in a system’s evolution. This requires involve- well as the means to visualize, edit, and execute them, are eas- ment in evolutionary processes, visibility into product and pro- ily downloaded using current and evolving cess state, use of tools and interfaces that are effective for both (WWW) protocols [7, 11]. technical and non-technical users, and mechanisms for facilitat- • Integration. Endeavors allows bi-directional communication ing customization and dynamic change. Endeavors is an open, between its internal objects and external tools, objects, and ser- distributed, extendible process system infrastructure which has vices through its open interfaces across all levels of the archi- arisen from experience with the Teamware process modeling lan- tecture. Implementation of object behaviors in multiple guage [33] and lessons from a variety of other process technolo- languages is supported, allowing them to be described in what- ever programming language is most suitable for integration. gies[3, 10, 14, 17, 20, 21, 22, 27], software architecture [29, 30, 32] and systems integration [6, 24, 31] research. The design of the • Incremental Adoption. Endeavors requires low cost and effort Endeavors system provides key mechanisms for support of distri- to install across all software platforms. All process objects are file () based allowing greater portability across different bution of processes and users, integration of third party tools, machine architectures. Components of the system, including incremental adoption of the technology (leading to a low cost-of- user interfaces, interpreter, and editing tools, may be down- usage entry barrier), customization and reuse of the process sys- loaded as needed, and no explicit system installation is required tem components and process objects, and support for dynamic to view and execute a workflow-style process. change of types and behaviors. • Customization and Reuse. Endeavors is implemented as a layered virtual machines architecture, and allows object-ori- 1. This work was sponsored in part by the Air Force Materiel Command, Rome ented extension of the architecture, interfaces, and data formats Laboratory, and the Advanced Research Projects Agency (ARPA), under contract F30602-94-C-0218. The content of the information does not necessarily reflect at each layer. Because processes, objects, tool integrations, and the position or policy of the Government and no official endorsement should be policies can be used across platforms, processes may be inferred. adapted or evolved through embedding and composition of pro- Fig. 1. Endeavors Workspace including the control panel, views of a network and sub-network, and Message property sheet. cess fragments using cutting, copying, and pasting of activity II. Emphases and Distinguishing Goals representations. • Dynamic Change. Endeavors allows dynamic changing of Fig. 2. Endeavors Coordination Between Distributed Sites. object fields and methods, the ability to dynamically change the object behaviors at runtime, and late-binding of resources Site 1 Site 2 needed to execute a workflow process. Process interpreters are dynamically created as needed. Intranet Intranet In order to achieve these goals, Endeavors employs the key design strategies of (1) maintaining several layered object mod- FL,SL http FL,SL http els, (2) implementing the architecture as a set of highly compo- Svcs.. Svcs. Svcs.. Svcs. nentized, lightweight, concurrent elements, (3) providing customization tools for each conceptual layer of the system, (4) Internet supporting event-based communication between layers and com- ponents including user interface components, (5) reflexively modeling these components in order to keep a dynamically, dis- tributable, customizable internal model of itself, and (6) allowing A. Distribution dynamic loading of objects, behaviors, and user interfaces across the Internet. The details of the Endeavors solution architecture Evolutionary product development typically necessitates a and the mapping of these design strategies to implementation process system that supports distributed activities. Communica- goals is discussed at the end of Section III, leading into an assess- tion and coordination within the development process require the ment of how these goals are handled by related process technol- interactions of stakeholders at distributed locations, both before ogy systems in section IV. and after initial product deployment. Product users may require Because the Endeavors architecture supports componentiza- access to previous development information, processes, and tion, distribution, and incremental adoption, we have been able to infrastructure, allowing them to leverage off the previous devel- reflexively adopt and customize components of the system to aid opment work and rationale. In addition, the differing contexts of in its own development. Section V of this paper will discuss the multiple distributed developers and users necessitates the ability current status of the project, detail the context of the project with to coordinate potentially differing off-the-shelf technologies. For respect to our coordination and control policies, and highlight example, it might be necessary to take a pre-packaged system and some of the benefits. Finally, some launching points for future enhance it for specific needs. Access to the original development work will be discussed. process will help guide the evolutions. Further, evolving a prod- uct repeatedly within an application family allows for leveraging incurring substantial tool integration costs [17]. Endeavors sup- one evolutionary process off of those that proceeded it, thus sav- ports an incremental approach, requiring lower cost and effort to ing time and effort. install and execute processes across all platforms and architec- The Endeavors system provides support for distribution by tures by relying on easily usable technologies that are widely cooperating with evolving WWW, http, and hyperweb protocols, available. The Endeavors architecture is designed as a set of and allowing customizable distribution and decentralization poli- highly componentized, lightweight, concurrent elements which cies. Endeavors integrates various hypermedia technologies such are implemented as applets in the programming language, as access to persistent hyperwebs of development information allowing them to be used across platforms and easily transported through open-hypertext systems such as Chimera [2], integration across the WWW or embedded in pages. Also, Endeavors with uniform resource identifiers (URIs [8]) to access distributed has a file based persistency model, allowing processes and components over the WWW, and the distributed execution mech- objects to be easily transportable. Components of the system, anisms of Python scripts [www.python.org] and Java applets including user interfaces, interpreters, and editing tools, are [13]. Each component of the architecture, including user inter- downloaded as the user needs them. One interesting effect of this faces, interpreters, processes, and object state and behavior, can is that no explicit installation is required to view, change, or exe- be accessed and executed by remote users through a standard http cute a process. This is accomplished similar to how applets are server and may be physically located on distributed machines executed on the WWW: sending both the data (process) and throughout the Internet. Changes to the objects and their state is means to execute the data (interpreter). This allows coordination implemented as an experimental service extension to the http and communication between process participants who simply protocol to support reading and writing to the Endeavors persis- have access to the WWW. It is important to note that support for tent data files managed by the http server if the permissions this is dependent upon the configurability of the browser used. allow. [7] Similar to password protected html pages, access to HotJava’s configurable security management can allow applets to components, objects, integrations, and behaviors can be con- manipulate local objects, while 2.0+ does not. In that trolled using currently available password protection mecha- case execution of some downloaded process objects would have nisms. to take place outside the .

B. Integration D. Customization and Reuse Process support systems must integrate diverse stakeholders Because our approach to process technology involves multiple and development environments. Flexible integration mechanisms stakeholders, different abstractions for the model objects need to provide the ability to evolve the support system in concert with be maintained. As the same level of information hiding and product evolution. The ideal process support system affords prod- behavioral encapsulation may not be appropriate across all stake- uct developers transparent integration with the appropriate exter- holders and sites, Endeavors allows adaptation, specialization, nal systems as needed, desired, or dictated by the work culture. and reuse of process objects. Object data and behaviors are main- Process support systems need to integrate with external systems tained separately as category objects and handlers. The category either through application programmatic interfaces (APIs) or object model is a three-tiered object model that supports separa- through intermediate forms, depending upon the “openness” of tion of object state and behavior, multiple inheritance, dynamic the system. The resulting flexibility will allow product developers declaration of fields and state variables, and better support for to evolve their tool sets for different users and phases of the soft- reuse than the traditional class-instance model (for a more ware product’s lifecycle. detailed discussion, please refer to [33, 34, 35]). For example, a API-based integrations are flexible and may be supported by time-limited activity category may have fields called ‘time- handlers that either (a) provide access to a tool where the project allowed’ and ‘notify-person’ in addition to a message ‘raise- server resides possibly through our use of a cross-language RPC warning’. A specification would allow assignment of these fields mechanism [6, 24], (b) download the tool as an executable applet, to the appropriate values possibly by a non-technical user, and an or (c) support integration with a tool already installed on the cli- instance would be the object that actually receives the message ent side. Currently, Endeavors’ handlers are written as Java and executes the handler. Because processes, objects, tool inte- applets or Python scripts and will eventually support Ada95 [28] grations, and policies can be used across platforms, processes and Tcl. These handlers allow bi-directional calls to Endeavors’ may be adapted or evolved through embedding and composition open interfaces across all levels of the architecture as well as of process fragments by cutting, copying, and pasting of activity external objects, tools, and services, even making calls across representations using the default network editor (see Figure 1.). languages if needed. Stakeholders can then customize the abstraction levels for behav- External tools which do not support an API may be integrated ior and data that are appropriate for their site and their customiza- by writing an object handler that is able to write information to or tion skill and authorization level. For example, technically extract data from an intermediate format the external tool uses. sophisticated stakeholders may customize behaviors while some non-technical personnel may be limited to setting the value of some fields (essentially parameterization). C. Low Entry Barrier, Incremental Adoption In addition to being able to customize the processes and The cost of adopting process technology in the day-to-day objects, the Endeavors system is implemented as a layered virtual activity of developing software has typically been prohibitive, machines architecture and allows customization of its interfaces often requiring large investments of time and training as well as and architectural configuration. Adding new calls to an interface Layered Object Models Fig 3. Endeavors implements a mul- tiple-level virtual machines architec- ture. where each object model builds on top of and extends the object mod- els below it. In addition, each level maintains a set of responsibilities.

java file can be accomplished by subclassing the interface object (see implemented in a model-view-controller style [29, 30] that sup- ‘interface’ objects [13]) and having the layer implement the new ports the dynamic addition of multiple coordinated user inter- interface. Each level contains the infrastructure to allow compo- faces. Similarly, coordinated process interpreters can be nents to broadcast and register for events and to dynamically load dynamically added to execute the control flow of a process that components inheriting from a root class. For instance, the user may involve activities and sub-networks which may be executed level in Endeavors supports dynamic loading of user interfaces as in parallel. The interpreter can be extended in an object-oriented applets and registration and broadcast of events generated from way, and like handlers, interpreters are dynamically loaded and calls to the system level interfaces. This makes it easier to add or executed at the time they are needed based on the topology of the extend user interface components that integrate with the architec- activity network. (Structural consistency of Endeavors architec- ture. tural components is supported by infrastructural components such as the artist manager.) E. Dynamic Change III. Solution Architecture The ability to dynamically change a process definition, the set of views into the process, and the execution model at the time it is A. System Architecture in progress to better fit changing requirements, availability of resources, and the applicability to the current work context, is The Endeavors system architecture is split into user, system, crucial for process evolution. To support this Endeavors allows and foundation levels. Each maintains its own object model, (a) dynamic changing of object fields, methods, and behaviors at interfaces, and responsibilities. runtime, (b) late-binding of resources needed to execute a work- The user level is responsible for maintaining consistent views flow process, and (c) dynamic invocation and loading of new and to users through management of coordinated updates of multiple existing coordinated views. Because object data and behaviors user interface artists and tracking and displaying system level are maintained separately, handlers are dynamically loaded and changes using wrappers and event registration and broadcast. executed at the time a message is received, allowing behaviors to Users, through direct manipulation of the user interface represen- be easily exchanged during execution. For long-running, distrib- tations, can change the underlying system object attributes as uted processes involving multiple stakeholders, the ability to specified by the dialog mapping in the artists. The user level change the data and how objects behave to fit into a work context includes an artist manager to allow artists to be dynamically becomes important. Sharing process objects and networks across loaded over the network and register for broadcast events. sites may not be enough to guarantee the successful execution of The system level maintains the category object model abstrac- an evolution process, due to differences in work cultures. (Main- tions and data structures. The system level also provides object taining structural consistency in the process objects is enforced utilities, including visibility rules enforcement for state variables by the category object model. Maintaining data consistency is not and handlers, packages for easier specification of control and supported directly by Endeavors. Components in the workspace data flow in activity networks, and access to interpreter functions. and tools can register interest for events on interface calls to Interfaces at this level are focussed on programmatically manipu- objects, but what they do on the basis of that information is not lating activity networks, creating new activities, artifacts, and determined or controlled by Endeavors.) Fitting into a work cul- resources, assigning data and behaviors, and sending process ture may also involve dynamically loading and integrating con- level events. text specific views. The top level of the Endeavors architecture is The foundation level maintains a class-metaclass model [35]. TABLE I. Relationship of System goals to Design Strategies. This object model is built on top of the Java object model (the gle-threaded implementations in the same language.) All of the lowest level in the layered architecture) and extends it to support Endeavors components are lightweight and can be used and dynamic declaration of state variables, specification of handlers, incorporated on demand, even sent across networks as needed. and object interface extensions. This level provides support for Events also can be broadcast over the network allowing flexible object persistency and distribution. In addition, the foundation reconfiguration of the architecture and ease of integration of level manages the incremental loading of objects and handlers external tools across platforms, even allowing process and user across the network and external tool integration. The lowest level interface components to be embedded in WWW pages. of the architecture hides the implementation details of the system including the source code responsible for dynamic loading of 3. Customization Tools object handlers written in various programming languages. Each layer of the architecture has a configurable toolset for Development of this architecture was driven by our experience customizing that particular layer. The user level can be custom- with earlier Teamware implementations and several key design ized using a Java version of the Chiron [29, 30] toolset and the strategies. We now detail each of these strategies, discusses how Java Developer’s Kit [13] tools and resources; the system level each is used in the context of the overall architecture. using the Endeavors graphical editors, and the foundation level using distributed programming and data storage tools. Event reg- B. Key Design Strategies istration and broadcast between components, and non-obtrusive 1. Layered Object Models wrapping of data structures and APIs across all layers of the sys- tem (described below), aids in the integration of external tools for Similar to a layered services architecture, Endeavors maintains customizing the system. At the lowest level objects are stored in a set of layered object models where each layer provides an ASCII text format, allowing text-based object manipulation and object model that is more appropriate to the application’s editing. (Consequently, some questions about efficiency arise. domain, in this case the evolutionary workflow process domain. While our initial limited experience is very positive for individual Each layer incrementally builds on the object model of the under- and small work group processes, we remain cautious about lying layer, creating a new level of abstraction. Layers are added claiming specific performance properties with large, centralized until the goals of the system outlined above are supported at the processes.) As mentioned previously, the foundation and system appropriate level. In addition to clean interfaces at each level, level interfaces are open and extendible, and the architecture eas- objects are extendible and reusable within the level they reside ily supports multiple coordinated views allowing incremental and the interfaces themselves are extendible via object subclass- addition of domain-specific user interfaces. ing. Customizations at each level can be made incrementally and in an object-oriented fashion. To date our extensions at any one 4. Event-Based Communication level have had minimal or no effect on other layers. Event-based communication is used within and between all 2. Highly Componentized, Lightweight, Concurrent Elements layers of the Endeavors architecture. Events are mapped across levels of the architecture by the system and foundation level The Endeavors architecture is implemented as a dynamically interfaces. Events can be broadcast over network protocols at changeable set of componentized, lightweight, concurrent ele- these points allowing the architecture to be restructured into a cli- ments. Components support peer-to-peer interactions through ent-server or tiered server model. Event broadcasting and regis- event-based communication and components can register and tration is supported at different levels. Wrapping of data broadcast events without knowing what other components are lis- structures and components for event generation is accomplished tening. Components each contain their own thread of control and by having all objects inherit from the Java class ‘Observable’, the overall architecture lends itself to a high throughput of data which provides an interface that enables components to register and interactivity with the user (at least as compared to prior sin- interest in changes to that object. User interface agents register interest in calls to the system or foundation level APIs. Calls to systems which handle one or more of these goals well for each of these APIs are made through unobtrusive wrappers allowing these criteria. broadcasts and multiple coordinated updates, even across remote Oz [22] is a rule-based process centered execution environ- machines and users. Endeavors process interpreters can register ment. Oz envelopes allow two-way communication with the Oz with foundation levels located on remote machines for events on server through OzScript[23]. Oz manages tools and tool invoca- shared objects such as ‘completion’ events for remote activities, tions on a network using a proxy server and manages the explicit allowing remote coordination between sites. platform dependencies by maintaining information about the ability to run and display tools across platforms and the net- 5. Reflexive Object Model work[31]. Oz also has a sophisticated execution engine (Amber [23]) where at specific points in the rule-execution cycle the exe- Endeavors system components are themselves modelled as cution can be customized. While Oz was originally a monolithic artifacts, allowing the system to keep a dynamically, distribut- system, the system was redesigned to allow a cleaner definition able, and customizable internal model of itself. This is useful as of components, and in fact, the rule processing engine, the object executable processes for developing, installing, customizing, and base (Darkover[23]), and the transaction manager (Pern[19]) can reconfiguring the system can be specified and reused. Similarly, be pulled out and used as separate components. Coordination the activity network interpreter is modelled as an activity object between distributed sites is accomplished using a summit and within the system, allowing it to be sent across networks, auto- treaty mechanism to negotiate and maintain constraints between matically made persistent, and dynamically spawned as needed. sites, and objects within the Darkover object base can be This reflexivity gives the Endeavors system programmatic self- accessed over the WWW (DkWeb[26]). reference for changing its own architectural components, includ- ing user interfaces, activity network structures, resource alloca- Endeavors’ handlers also support two-way communication tions, and distributed communications. Support for dynamic between tools and the internal objects. Endeavors, however, is change and a reflexive object model provide the potential for a designed to support multiple languages for both tool integration self-optimizing process support system. and describing object behaviors. Currently only Java and Python are supported, but experiments have shown support for Ada95 [28] and Tcl can be easily integrated. In addition to supporting 6. Dynamic Loading tool integration and invocation on either the client or server side, Dynamic loading is pervasive in Endeavors, and is supported similar to Oz, Endeavors allows tools to be implemented as by leveraging from Java’s dynamic loading capabilities (the net- applets. These tool applets can be attached to and downloaded work class loader and their applet implementations) and inter- with an executable process, thus avoiding the problem of faces to the network protocols. Process objects are dynamically machine and platform configuration tracking. The Endeavors extensible so that they can be changed on-the-fly in response to interpreter is similar to Amber in that it is a separable component, inevitable changes in the process execution. Object behaviors are but is customizable in an object-oriented manner, rather than dynamically loadable and can be changed during process execu- using a callback approach. Endeavors has taken the idea of com- tion. New data fields and state variables can be dynamically ponentization one step further, splitting the system components declared within an object, and new object types and extensions into very lightweight, concurrent, transportable elements, result- can be created and loaded as needed. The Endeavors user level ing in a more incremental approach to adopting the technology. architecture supports dynamic loading and execution of user To better address the needs of flexible transaction support and interface agents (artists) and can be interchanged during execu- local constraints on process steps through reactive control in tion through dynamic loading and runtime re-registering of Endeavors, we plan to experiment with integrating Pern and events. All components of the system can be sent through net- Amber to address these issues. work protocols and dynamically loaded at remote sites. ProcessWall [18] provides a persistent process state server and maintains a separation between the process language and the C. Relationship of System Goals to Design Strategies state it keeps. The state server is a separate component executing within an environment and provides storage and operations for Table 1 illustrates the relative importance of the various design defining and manipulating the structure of process state. State strategies to the achievement of the system goals. The number of operations are defined using the Tcl language and are dynami- check marks in the figure is an indication of the relative impor- cally loaded as needed. ProcessWall supports semantic concepts tance (more checks implies greater importance). Event-based of precedence, decomposition, and annotations to provide sup- integration and componentization are the two most important fea- port for to resource and product state servers. ProcessWall tures for the system infrastructure. allows integration with broadcast messaging services and various servers can be configured to cooperate across networks. IV. Related Work The Endeavors Foundation level is functionally equivalent to The Endeavors system is modelled after several process tech- the ProcessWall, providing a set of foundational services from nology systems with similar goals. Simply stated the goals of the which to incrementally build and support process services. Like- Endeavors system are to provide a support architecture for distri- wise, the Endeavors Foundation separates process state from the bution, integration, incremental adoption, customization and process language through it’s separation of handlers from the reuse, and dynamic change. To assess how well our system process objects. Interfaces to these objects can be dynamically accomplishes these goals, comparisons are made to current key changed to support new messages, and on the receipt of a mes- sage, the appropriate handler is dynamically loaded and executed. defined by the object model. Endeavors is also reflexive. Endeav- Endeavors differs in that handlers can be downloaded and exe- ors components are modelled as artifacts and may be used within cuted across the network, implemented in multiple languages, their own processes. A good example of this is the Endeavors and changed in an object-oriented fashion using inheritance and demonstration process which is executable from our WWW page specialization. In addition, the Endeavors Foundation component (see section V). In the course of executing the process, architec- could be instantiated or extended to provide separate state servers tural components are added and removed as the result of behav- for product and resource state, but we have not demonstrated this. iors specified in the activities. Interpretation is incremental, and Furthermore, while Endeavors supports multiple programming some simple changes to the process being executed are allowed. languages for behavioral specification, it has not yet been demon- LEU [15] is a commercially developed product which pro- strated to provide state server support for multiple process lan- vides integrated support for process modeling, analysis, and exe- guages as has ProcessWall; the comparison here is based on cution. LEU uses an extended Entity-Relationship [14] diagram conceptual characteristics. to model data which then is managed by a centralized database The SPADE [5] environment shares much in common with server over a local network. Multiple process interpreters access Endeavors. It is composed of a multi-level architecture [12], hav- this database and drive the process by updating users’ agendas ing repository, process enactment, and user interaction levels. and responding to interactions by the user using this tool. In this The user interaction level (user interface and the external tools) is way LEU takes a task-oriented approach to process interaction decoupled from process model enactment. Processes (activities) and couples its agenda view with the task items being executed. are described in a high-level Petri net language, with process Endeavors also takes a multiple process interpreter approach, types described in an object-oriented class hierarchy. Activities spawning an independent interpreter for each process execution are thus reflexive: they can be manipulated as data by other activ- thread of control. Interpreters communicate through separate read ities. Activities can be dynamically instantiated, and multiple and write channels over the http protocol to one or more project slang interpreters invoked for parallel activities (the interpreters servers. Tools and interpreters execute behaviors and manipulate are separate threads of a process engine). Artifacts are imple- process state located on various systems across the network mented as objects in an O2 object-oriented database. Interaction through the Endeavors System and Foundation level interfaces. with external tools is through the Spade Communication Inter- Opposite to LEU, Endeavors offers a decentralized data distribu- face, supporting event-based, O2 based, or API based integration. tion model. Endeavors supports a mixture of both coupled and Endeavors employs object-oriented facilities throughout its decoupled user interaction. System views assume default knowl- architecture, including having networks as first class objects. edge about the activities, artifacts, and resources of a process and Endeavors also includes explicit support for modeling and inter- allow a user to specify the control and data flow between them. acting with resources as objects. Also, Endeavors supports inter- Control flow supports concurrency and conditionals through the action with external tools through its object handler mechanism, branch, merge, fork, and join constructs in the process language. which supports interaction across multiple languages. Endeavors In this way the user interaction is coupled with the constructs of differs most obviously in the repository layer. Rather than the process modeling language, however, a strong separation depending on a centralized OO database, Endeavors adopts a dis- between user interfaces and the process model is supported tributed storage model in which objects can migrate across the through event-based integration and a model-view-controller par- network using standard web protocols. An ASCII representation adigm [29, 30]. In addition, tool integrations are defined as han- facilitates interoperability across differing platforms. While our dler behaviors on a per-Category basis and the ultimate behavior model of object storage lacks the robust features and support of a of the process is dependent upon its specification. In this way, commercial database, the simplicity of a file-based approach has Endeavors supports decoupling of the user interaction from the aided in lowering the cost of adoption. process model as well, in order to provide greater flexibility in Process Wise[4] supports both reactive and proactive process customizing and reusing process components. control and uses the Process Management Language (PML) and WEADELE is based on the integration of Adele and Process Process Control Manager (PCM) to separate the process model Weaver. Adele is a full object-oriented data modeling environ- and process model execution. Process Wise allows incremental ment implemented as an extension of database capabilities to model interpretation and provides support to online modification provide process support in an environment, as well as a high- of the model. An inconsistency between the model and reality level process support language and translation services may trigger a model change, the process model being reflexive. (APEL[10]). Adele can manage multiple schemas simulta- Process Wise is implemented as a client-server, layered architec- neously, and multiple schemas are used to support process evolu- ture and provides persistency through the use of a persistent lan- tion and multiple process views. Adele’s strengths are in data guage. A role and interaction scheduler provides the basis for modeling and software configuration management. Because each executing roles as different threads. The Endeavors architecture schema has dynamic information about its type, changes to the currently maintains no explicit reactive control component. How- schema may result in changes to the state. Adele addresses this ever, because components have the ability to register for and react problem by providing support to manage the simultaneous exist- to system events and state changes, this type of control structure ence of multiple schemas based on the same data. One of the mechanism could be readily added, possibly through extending major requirements of the system is openness. Adele components and overriding the behaviors of the existing interpreter and add- are designed to be integrated with each other using RPC, BMS, ing it as a separate component. Currently the reactive control and procedure calls to the various schema APIs. This is best dem- specifications are stored in the components themselves and onstrated by its integration with Process Weaver. Endeavors also allows dynamic change to types. Similar to Adele, the system creating, and changing category objects and their attributes. Ini- doesn’t attempt to solve data consistency problems but provides tial tests show that the user interfaces, interpreter, objects, and support infrastructure to manage the simultaneous existence of handlers interoperate across Sparc/Solaris (2.3, 2.4, 2.5), multiple objects. Structural consistency of the objects is main- Microsoft Windows NT (3.5.1) and 95, Macintosh (MacOs 7.5), tained by the policies of the Category object model. Components and SGI/Irix (5.2) and in fact various parts were developed across in the workspace and tools can register interest for events on these platforms. Handlers are currently supported using Java interface calls to these objects, and Endeavors places the burden applets without loss of portability. Support for Python handlers is of data consistency on these components (thus arguably “ducking also available but requires the respective installation libraries pre- the issue”). Endeavors interfaces are open, and event-registration installed on the target platform. Support for handlers written in may occur at each layer of its architecture. This allows compo- Ada95 and Tcl is planned. nents to be easily integrated even during runtime through The Endeavors system currently includes an integrated net- dynamic loading and re-registering events. It is important to note work editor, interpreter, and category definition user interfaces that similar to the process objects, architectural components are and requires communication with an http server to manage the responsible for maintaining data consistency. A new tool or user persistent object directories. As the system allows incremental interface that changes the state of an object through an API call adoption, we have made various interfaces available for execu- that other components hadn’t registered for may result in an tion from the WWW and will continue to do so as they become inconsistency. Endeavors, while providing the infrastructure for available. Users can download and execute a demonstration pro- dynamic change, does not address this problem and cannot guar- cess and the various system user interfaces using a Java-enable antee the consistency of arbitrary system and object extensions. web browser from our WWW page at http://www.ics.uci.edu/ Oikos [1] adopts a multiple language approach to process pub/endeavors/demo/. For the final release, the Endeavors instal- specification. Process specifications are written in Limbo which lation, bug reporting, and customization processes will be able to is translated into a process programming language, PE’ta:. PE’ta: be executed from this page as well as support for exchanging pro- takes a blackboard approach to object data, organizing them in a cesses in a marketplace setting [32]. hierarchy useful for specification and some constraint checking at At any given point in time there are 4-7 programmers working specification time. Object data then can be changed by active on the development of the Endeavors system across several dif- objects. Process programs are interpreted by one or more ferent platforms. There is an http project server which manages instances of the PE’ta: interpreter. The process program may use all of the source code, user interfaces, makefiles, compiled some predefined services provided in Oikos, including a product classes, user interface components, and object definitions and repository server, tool repository server, process model and status handlers. Because the components, files, and user interfaces are server, and an actor interaction server. Oikos is built on top of the modelled as artifacts within the Endeavors system itself, develop- EXPO 2.0 virtual machine which provides database management ers have the ability to access and change objects, source code, services and includes event notification upon every request to the and handlers from distributed sites, even using low-bandwidth file system. connections to the WWW such as a modem from home[26]. One Endeavors separates object data and object behavior and unique aspect of the Endeavors system is that as services become allows behaviors to be located separately across the network. available they are integrated into our own development processes. Endeavors supports multiple interpreters and allows a cooperat- For instance, the stable, shared version of the source code is ing process interpreter for each thread of a process program. under revision control and managed by the project server. There Endeavors also embodies the concepts of a tool server, product are explicit check-out and check-in processes for changing this server, process model and status server, and actor interaction version of the source code which are currently hand executed by server, by allowing tools, tool integrations, processes, process the developers. For instance if a developer wanted to check in a objects, interpreters, and even user interfaces to be accessed, source file, they would have to obtain a lock and merge the downloaded, and executed across the network. Endeavors object changes or if they already have a lock on the source code file, persistence is file-based to allow transportability across standard check in the file. Next the compiler is run on the installation network protocols and platforms. In contrast to Oikos, which directory to ensure all changes are compilable, and then the auto- captures requests to the file system, Endeavors events are cap- mated documentation is generated upon a successful compile tured from calls to the interface layers. Since Endeavors doesn’t (using the javadoc tool WWW page generation tool[13]) and have the ability to capture file requests, tools that don’t use placed on the Endeavors web page. The source code is bundled Endeavors’ interfaces to change object data are responsible for up, compressed, and placed in the FTP directory, and the source maintaining consistency and sending change events. However, lines of code (SLOC) are automatically updated and placed on through its integration mechanisms such as support for multiple the web page also. Finally, the demonstration applet is executed languages, integration with network protocols, and its open inter- to ensure that the new compile and changes haven’t broken the faces, external tools can integrate at the appropriate level of existing demonstration. Clearly a simple process such as check- abstraction. ing in a source code can be incrementally evolved to automate repetitive software development tasks. (To view the end-products V. Current Status and Conclusions of this process, please refer to the Endeavors home page at http:// Endeavors is completely written in the Java programming lan- www.ics.uci.edu/pub/endeavors/). guage and supports user interfaces for visually creating activity Our future directions for this work include better support for networks, assigning resources, attaching artifacts, and browsing, analysis, possibly through leveraging third party project manage- ment tools such as Microsoft Project, integration with existing September 1994. and evolving WWW protocols [7, 11], support for rapid genera- [3] Bandinelli, Sergio C., and et al., “Process Enactment in SPADE”, tion of web-based guidance frameworks that include Endeavors European Workshop on Software Process Technology, 1992, pgs system components and activity network control flows embedded 66-82. in the generated html pages, and hypermedia support between [4] Bandinelli, Sergio C., “Report on the Workshop on Software Process Endeavors objects and domain specific or innovative interfaces, Architectures”, Milan, March 20-23, 1995. [5] Bandinelli, Sergio C., Alfonso Fuggetta, Carlo Ghezzi,“Software possibly using VRML[.wired.com] to model virtual team Process Model Evolution in the SPADE Environment”, . IEEE workspaces. Transactions on Software Engineering, Vol 19 No 12, December The ability to share and execute processes on the WWW is 1993. very promising, however, several obstacles remain for scaling [6] Barrett, Daniel J., Lori A. Clarke, Peri L. Tarr, and Alexander E. such an approach beyond individuals or small workgroups to Wise, “An Event-Based Software Integration Framework”, enterprises. Performance and security remain as two open issues. Technical Report 95-048 Computer Science Department, University For example, http, while widely available, doesn’t necessarily of Massachusetts at Amherst, Revised: January 31, 1996. scale well as an efficient and robust mechanism for distributing [7] Berners-Lee, T. and D. Connolly, “HyperText Markup Language agents across the Web [9]. Also, tight control of access to data Specification -- 2.0”, Internet Engineering Task Force, draft and information as well as the security of objects and data sent document, Work in Progress, MIT/W3C, June 1995. across the Web is difficult to guarantee. While our experiences to [8] Berners-Lee, T., “Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of date maintaining data and processes on a small workgroup intra- Objects on the Network as used in the World-Wide Web” Internet net are promising, we realize the limitations of the current tech- Engineering Task Force (IETF), draft document, RFC 1630, CERN, nology. June 1994. In conclusion, Endeavors differs from current process technol- [9] Daigle, Leslie and et al., “Uniform Resource Agents (URAs)”, ogy systems in that its architecture explicitly supports the goals of Internet Engineering Task Force (IETF), draft document, November, distribution of users and processes, rich support for integration of 1995. research and commercial off-the-shelf tools, incremental adoption [10] Estublier, Jacky, “APEL: Abstract Process Engine Language”, of process technology and low-cost to use across machines and University of Grenoble, France, 2nd Process Technology Workshop, platforms, broad support for customization across all levels of the Feburary 20-23 at U.C. Irvine, 1996. architecture, and the ability to dynamically change objects and [11] Fielding, Roy and et al., “Hypertext Transfer Protocol -- http/1.1”, Internet Engineering Task Force (IETF), draft document, April 23, their behaviors. Endeavors’ layered object models as a virtual 1996. machines architecture lends itself to customization and extension. [12] Fuggetta, Alfonso, “Architectural and Linguistic Issues in The implementation of the system as a dynamically configurable Supporting Cooperation and Interaction”, Politecnico di Milano, 2nd set of highly componentized, lightweight, concurrent elements Process Technology Workshop, February 20-23 at U.C. Irvine, allows components to be downloaded and executed as needed 1996. across current WWW protocols. Event-based integration of com- [13] Gosling, James, and Henry McGilton, “The Java(tm) Language ponents allows the architecture of the system to be easily recon- Environment: A White Paper”, Inc. October figured over the network and to incrementally add components to 1995. the system. [14] Gruhn, Volker, “Business Process Modeling in the Workflow Management Environment LEU”, Proceedings of the Entity- Relationship Conference, Manchester, UK, December 1994. [15] Gruhn, Volker and Stefan Wolf, “Software Process Improvement by VI. Acknowledgments Business Process Orientation”, Software Process--Improvement and The authors would like to recognize the hard work and effort of Practice, Pilot Issue, 49-56, 1995. the design and implementation of this system by Patrick Young, [16] Hamilton, Graham and Rick Cattell, “JDBC(TM): A Java SQL API”, JavaSoft White Paper, April 4, 1996. Peyman Oreizy, Art Hitomi, Peter Kammer, Harry Yessayan, [17] Heimbigner, Dennis, “The ProcessWall: A Process State Server Clay Cover, and Mark Walters. In addition we would like to Approach to Process Programming”, Proceedings of the 5th ACM acknowledge the members of the Chiron-2, Chimera, and Web- SIGSOFT Symposium on Software Development Environments, Soft projects at UCI for their exchange of ideas during the devel- ACM Press, 1992. opment of this system. Finally we would like thank Nenad [18] Heimbigner, Dennis, “The ProcessWall: A Process State Server Medvidovic and Kari Nies for their technical support and review- Approach to Process Programming (Revised)”, University of ing this paper. Colorado, Boulder, 2nd Process Technology Workshop, Feburary 20-23 at U.C. Irvine, 1996. VII. References [19] Heineman, George T, and Gail E. Kaiser, “The CORD approach to extensible concurrency control”, Collumbia University Department [1] Ambriola, V. and et al., “Software Process Enactment in Oikos”, of Computer Science, Technical Report CUCS-024095 submitted Proceedings of the ACM SIGSOFT Symposium on Software for publication, February 1996. Development Environments, pp. 183-192, Irvine, California, 1990. [20] Jaccheri, M. L., R. Conradi, “Techniques for Process Model [2] Anderson, Kenneth M. and et al., “Chimera: Hypertext for Evolution in EPOS”, IEEE Transactions of Software Engineering, Heterogeneous Software Environments”, European Conference on 12:19, December 1993, Special issue on Software Process Hypermedia Technology (ECHT’94), Edinburgh, Scotland, Evolution, pp 1145-1156. [21] Junkermann, G. and W. Schaefer, “Merlin: Supporting Cooperation VIII. WWW Related Material in Software Development through a Knowledge-based Environment”, Advances in Software Process Technology. EDCS at UCI, www.ics.uci.edu/pub/edcs/ Publisher John Wiley, 1994. Endeavors, www.ics.uci.edu/pub//endeavors/ [22] Kaiser, Gail E, George T. Heineman, Peter D. Skopp, and Jack J. Teamware, www.ics.uci.edu/Arcadia/Teamware/historical.html Yang,“Incremental Process Support for Code Reengineering: An Chimera, www.ics.uci.edu/pub/chimera/ Update”, Columbia University Department of Computer Science, Chiron, www.ics.uci.edu/pub/chiron Technical Report CUCS-007-96 submitted for publication, Chiron-2, www.ics.uci.edu/pub/c2/ February, 1996. WebSoft, www.ics.uci.edu/pub/websoft/ [23] Kaiser, Gail E., “Talks on OzWeb, DkWeb, Amber, Pern, CORD,” URIs, www.ics.uci.edu/pub/ietf/uri/ Columbia University Department of Computer Science, 2nd Process Apache, www.apache.org Technology Workshop, February 20-23 at U.C. Irvine, 1996. IETF W3, www.w3.org [24] Maybee, Mark J., Dennis H. Heimbigner, Leon J. Osterweil, VRML, www.vrml.com “Multilanguage Interoperability in Distributed Systems: Python, www.python.org EXPERIENCE REPORT” Proceedings of the 18th International Java, www.javasoft.com, java.sun.com Conference on Software Engineering (ICSE-18), March 25-29, Tcl/Tk, www.sunlabs.com/research/tcl/ 1996, pp 451-463. [25] Osterweil, Leon J., Stan Sutton, “Factored Language Architecture (of Julia)”, University of Massachusetts, Amherst, 2nd Process Technology Workshop, February 20-23 at U.C. Irvine, 1996. [26] Skopp, Peter D, “Low Bandwidth Operation in a Multi-User Software Development Environment”, Columbia University Department of Computer Science, Master’s Thesis. [27] Song, Xiping, Leon J. Osterweil, “Engineering Software Design Processes to Guide Process Execution” Proceedings of the 3rd International Conference on the Software Process. Reston, VA, October 1994, pp 135-152. [28] Taft, Tucker S., “Programming the Internet in Ada95”, submitted to Ada Europe ‘96. March 15, 1996. [29] Taylor, Richard N.. and et al, “A Component- and Message-Based Architectural Style for GUI Software”, Proceedings of the 17th International Conference of Software Engineering, Seattle, Washington, April 23-30, 1995. [30] Taylor, Richard N. and et al., “Chiron-1: A Software Architecture for User Interface Development, Maintenance, and Run-Time Support”, ACM Transactions on Computer-Human Interaction, Volume 2 Number 2, June 1995. [31] Valetto, Guiseppe and Gail E. Kaiser, “Enveloping Sophisticated Tools into Process-Centered Environments” Automated Software Engineering, Kluwer Academic Publishers, 1995 [32] Whitehead, E. James and et al., “Software Architecture: Foundation of a Software Component MarketPlace”, Proceedings of the First International Workshop on Architectures for Software Systems in cooperation with ICSE-17, Seattle, Washington, April 24-25, 1995. [33] Young, Patrick S, and Richard N. Taylor, “Process Programming Languages: Issues and Approaches”, 17th International Conference on Software Engineering, Workshop on Software Engineering and Programming Languages, Seattle, Washington, April 23-30, 1995. [34] Young, Patrick S., Richard N. Taylor, “Human-Executed Operations in the Teamware Process Programming System”, Proceedings of the Ninth International Software Process Workshop. [35] Young, Patrick S., “Customizable Process Specification and Enactment for Technical and Non-Technical Users”, Ph.D. Dissertation, University of California Irvine, 1994.