Introduction

The Programming Systems Lab at Columbia University has investigated cross-organizational process modeling and enactment (workflow) since 1993, that is, for about six years. This position paper serves as a retrospective, and a brief sketch of planned future directions. As such, it is not intended to advance the state of the art: We already presented numerous results in previous publications, and of course hope to contribute further as our work continues.

Our early research was confined primarily to software engineering applications, such as collaborative projects involving multiple departments or locations of the same company with different local practices, or even different companies, e.g., in subcontracting or consortia relationships. We also studied medical care plans jointly with Columbia Presbyterian Medical Center and of course addressed simple co-authoring, e.g., for manuals and papers. We initially assumed, to simplify the problem, that each organization employed the same process system, i.e., different instances of the identical process engine, but autonomously devised distinct local process (workflow) models. Our goal was to enable each participating organization to autonomously devise its own proprietary process, but we were not concerned at that time with interoperability of distinct workflow management systems.

Two or more organizations, or (possibly) geographically dispersed sites within the same organization, agreed upon shared subprocesses, called treaties. The remainder of their local processes could be entirely private; only this subset was visible to other cooperating sites. Treaty import/export was accompanied by particular permissions regarding which sites could apply the subprocess tasks to data (of the types parameterizing those tasks) owned by which other sites. Local data schemas did not have to match exactly, but their structures had to be compatible with respect to the attributes referenced in the shared task definitions. Treaties were not necessarily symmetric although they could be; one treaty might describe truly collaborative work while another treaty described activities of one party on another's behalf. The same site could operate within multiple treaties at the same time, with different cohorts, without any "leakage" of process information to partner sites with respect to a different treaty.

Treaties were enacted in summits, by definition, initiated implicitly whenever any treaty subprocess task happened to involve data items from two or more sites (treaty tasks could also operate on purely local data without interaction with other sites). During a summit, any prerequisites and consequences to the cooperative workflow task were performed by each local site on its own data according to its own local process, whereas the task itself operated according to the shared subprocess and permissions. Multiple shared tasks could be linked (through consequence relationships) together in a composite, with any necessarily local activities implicitly interleaved.

This international alliance metaphor was implemented in the Oz process-centered software engineering environment, where process models were specified by rule sets. Each rule consisted of a condition, an action, and one or more possible effects (any of these three parts could be omitted). The basic idea was that a user-requested task (action) could not be performed unless its prerequisites (conditions) were already satisfied or could potentially be satisfied semi-automatically by backward chaining to other rules whose effects might fulfill the conditions. Analogously, after a task completed, its actual effect (out of the several possible, specified a priori to address known exceptional cases) forward chained to other rules whose conditions now became satisfied. In the special case rule chains specified as atomic all-or-nothing, if the consequences could not themselves be completed semi-automatically (again possibly involving prompted user interactions), then the entire chain was rolled back as if it had never occurred.

We used nominally multi-site, actually multi-process but within a LAN, Oz-based processes internally in our day to day work for several years. Oz was also deployed outside for education and research purposes, for instance, by the Naval Research Lab High Assurance Center, there to warranty that developed software met security constraints. Feedback from these efforts led to a variety of minor changes in the alliance concept, more major changes in the realization. For instance, originally all treaties were pairwise, albeit with the capability for an importing participant to re-export to another potential participant. One-shot N-ary treaty administrative operations were added later for pragmatic reasons, although binary treaties laid under the covers and still afforded the greatest flexibility and security.

Oz was succeeded by OzWeb starting in 1995. OzWeb followed the same approach to allied processes, but in addition to the native objectbase and file system could utilize foreign data resources. For instance, OzWeb could apply workflow automation and constraints to Web accesses to arbitrary remote websites – including those the environment had zero control over, such as http://www.nsf.gov. The environment could, however, introduce its own application-specific external hyperlinks and other attributes on top of any combination of those entities, since these materials reside in a private add-on database imposed via an intermediary HTTP proxy. HTTP proxies are conventionally used for caching and firewalls, but can also intercept all GET, PUT, etc. requests for special processing - such as our imposition of workflow constraints. Our goal here was to determine how easy it might be to apply workflow to a user's Web browser activities. This turned out surprisingly easy, no need for CGI-bins, Java applets, or anything else more complex than configure each browser to use a proxy that asked Oz for the URL rather than checking its cache.

Beyond Process

More recently, we began to address a limitation of the alliances embodied in Oz - namely that they were specific to process. Oz had no particular support for negotiating a common ground for database schemata and object instances, tool characteristics and running application program instances, concurrency control policies and distributed transactions, etc. Of course, in the operational Oz system all of these were supported, in some manner, but on an ad hoc basis, not according to the international alliance metaphor or any other clean model. For instance, Oz required that all data types referenced in a treaty subprocess happened to already be defined in identical or at least structurally compatible form at each allied site. Ditto regarding tools, transaction models, even authorized userids: everything except the local process outside the common treaty subprocess had to be effectively homogeneous.

Obviously, this was a serious restriction, making the prototype system impractical for true multi-organization application. But, to be fair, it was a good start: As far as we know, Oz was the first software engineering environment that supported any process or workflow interoperability at all. Oz was preceded on paper by Heimbigner’s ProcessWall and various proposals at WfMC, which in principle supported heterogeneity of diverse process systems enacting, in effect, the same process or portions thereof. But there were no implementations at that time, and, apparently, implementation still lags to this day.

Our new approach to alliances among all the configurable components of a workflow management system, or indeed any other kind of distributed information system, is to institute treaties and summits directly among the comparable components. For example, several transaction managers supporting distinct concurrency control policies might agree to a treaty specifying how summits would enact distributed transactions over data sets whose members are governed by different policies. Or, as another example, two or more database systems might agree on either a common subschema or a type translator for converting among the data types of shared entities. Knowledge bases might agree on ontology servers.

Such alliances can be supported by our new TreatyMaker toolkit. Each kind of treaty is realized by a new extension of the toolkit's built-in treaty class, which defines services and state for use during the life-time of treaty instances. A given treaty is effected by an object of this subclass, exported by one participant and imported (and thus automatically replicated) by all the others. Summits are realized via the methods of this object. The alliance semantics are thus determined by the code (written in Java).

TreatyMaker is very flexible and open, compared to Oz, but leaves too much to the ingenuity of the application programmer using the TreatyMaker toolkit. In contrast, Oz treaties were purely declarative - and could be applied to existing process modules with no new "programming" of any sort. This is a typical tradeoff. Therefore, we are developing a repository of TreatyMaker "design patterns" for common cases likely to arise in our intended application domains - mostly software engineering environments and other kinds of workflow and collaborative work systems. Such "design patterns" are already reflected in JPernLite, our Web-based transaction monitor supporting extended transaction models for collaborative workflow applications.

Discussion

The basic concept behind our International Alliance metaphor is that each site or organization is like a country – it has its own laws and customs for conducting its own internal affairs. However, it might voluntarily enter agreements with other nations, e.g., for mutual defense or trade. Within such agreements, each party has to specify what it will and will not do, under which circumstances, in response to relevant stimuli from other participants. Otherwise, it is free to go about its business as it sees fit. Treaties are constructed dynamically, at any time during operation, and the same site could be party to multiple treaties with the same or a different cohort of other sites. If the requirements from other participants to a given treaty became too onerous at some point, any participant can unilaterally cancel its involvement in a treaty. In Oz and OzWeb, however, revocation could not be performed while an actual summit, a multi-organization operation, was in progress. This is obviously too restrictive, particularly for long-duration interactions, and has been ameliorated in our more recent TreatyMaker.

We do not have sufficient experience yet to say whether this model is adequate for, say, commercial subcontracting relationships. Or for more unusual commercial partnerships such as the timely AOL-Netscape-Sun deal, or for open source software engineering applications like Apache, Linux and Mozilla. But it intuitively makes sense, and allows for maximum flexibility. A particular treaty might include truly gross restrictions, but each party can just say no. Our support for the ability to pull out at any time from a pre-negotiated agreement, however, might not quite match legal regulations. Specification of allowable treaty termination as part of the treaty itself is left for future work

TreatyMaker 2.0 is written in Java, runs on Java 2.0 (JDK 1.2) and is available for free download from http://www.psl.cs.columbia.edu/software/download/. Oz and OzWeb were written in C for Solaris 2.5, with OzWeb accessible from any Web browser. Oz and OzWeb are no longer supported, but can be obtained by sending email to marvelus@cs.columbia.edu.

References

Dennis Heimbigner. The ProcessWall: A Process State Server Approach to Process Programming. Fifth ACM SIGSOFT Symposium on Software Development Environments, December 1992, pp. 159-168.

Jingshuang Yang and Gail E. Kaiser. JPernLite: Extensible Transaction Services for WWW. IEEE Transactions on Knowledge and Data Engineering, Mar/Apr 1999, in press.

Gail E. Kaiser, Stephen E. Dossick, Wenyu Jiang, Jack Jingshuang Yang and Sonny Xi Ye. WWW-based Collaboration Environments with Distributed Tool Services. World Wide Web, Baltzer Science Publishers, 1:3-25, January 1998.

Israel Z. Ben-Shaul and Gail E. Kaiser. Federating Process-Centered Environments: the Oz Experience. Journal of Automated Software Engineering, Kluwer Academic Publishers, 5(1):97-132, January 1998.

Gail E. Kaiser, Israel Z. Ben-Shaul, Steven S. Popovich and Stephen E. Dossick. A Metalinguistic Approach to Process Enactment Extensibility. Fourth International Conference on the Software Process: Improvement and Practice, December 1996, pp. 90-101

Wenke Lee, Gail E. Kaiser, Paul D. Clayton, and Eric H. Sherman. OzCare: A Workflow Automation System for Care Plans. Journal of the American Medical Informatics Association: 1996 AMIA Annual Fall Symposium, Hanley & Belfus, Inc., Symposium Supplement, October 1996, pp. 577-581.

Israel Z. Ben-Shaul and Gail E. Kaiser. Integrating Groupware Activities into Workflow Management Systems. In Seventh Israeli Conference on Computer Systems and Software Engineering, June 1996, pp. 140-149.

Israel Ben-Shaul and Gail E. Kaiser. A Paradigm for Decentralized Process Modeling. Kluwer Academic Publishers, Boston, 1995.

Israel Z. Ben-Shaul and Gail E. Kaiser. A Paradigm for Decentralized Process Modeling and its Realization in the Oz Environment. In Sixteenth International Conference on Software Engineering, May 1994, pp. 179-188.

Israel Z. Ben-Shaul and Gail E. Kaiser. A Configuration Process for a Distributed Software Development Environment. In Second International Workshop on Configurable Distributed Systems, March 1994, pp. 123-134.