A Micro Workflow Framework for Compositional Object-Oriented

A Micro Workflow Framework for Compositional Object-Oriented Software Development Drago¸s A. Manolescu and Ralph E. Johnson Department of Computer Science University of Illinois at Urbana-Champaign Urbana, IL 61801, USA {manolesc,johnson}@cs.uiuc.edu

1 Introduction For decades workflow technology has been used for process automation. Due to its interdisciplinary nature, researchers with different backgrounds have been adding various features. However, this has produced heavyweight systems with a monolithic architecture. The narrow purpose design of current workflow systems limits their applicability to the applications and domains for which they have been tailored. Consequently, they are difficult to reuse, customize, and integrate with other environments. Recent research helped people obtain better insights into workflow technology, understand its interdisciplinary nature, and realize its potential. However, it also uncovered some interesting problems with current workflow management systems. For example, here are three different aspects: Workflow and object-oriented technology In his summary of trends in workflow products, standards and research C. Mohan reviews a large number of commercial products and research projects [15]. He observes that typically object-oriented technology doesn’t go beyond the implementation of workflow products. Workflow management systems implemented with this technology don’t allow users to tailor the system functionality through object Additional information about this research is available on the Web at http://www.uiuc.edu/ ph/www/manolesc/Workflow/

1

oriented techniques and therefore don’t exploit object-oriented technology to its full potential. Lightweight workflow Current workflow products provide all the functionality that their users may require for workflow management. Besides process enactment, they offer graphical process builders and monitoring tools, workflow repositories, persistence and transaction services, etc. Users have the choice of using the whole package in a monolithic manner or not using it at all. Muth and colleagues [16] recommend that workflow researchers review the current monolithic workflow architectures to facilitate the integration of workflow management into existing environments. Workflow as a developer’s tool Commercial workflow systems attempt to target a wide range of users. They provide visual tools for non-technical users and sometimes open APIs for software developers. Recently we studied three large object-oriented frameworks [17, 1, 6], each of which had a workflow component. However, none of these frameworks employed an off-the-shelf workflow product. Instead, each architect built a custom workflow system that provided exactly the functionality required by his framework and integrated smoothly with the rest of the system. Although existing commercial workflow systems may be adequate for end-users, they are not necessarily appropriate for object-oriented developers. Recent studies observe that workflow covers functionality that should probably be provided by separate components [4]. Consequently, current workflow architectures are heavyweight, difficult to reuse and integrate with other environments. Users have little (if any) control over their features. Additionally, contemporary workflow technology regards object-oriented technology mainly as an implementation technique instead of an architectural style. The convergence of the above problems makes it hard for object-oriented software developers to use existing workflow solutions whenever they require workflow functionality at the object level, within applications.

2 Micro Workflow As a solution for these problems, we have been researching a form of workflow that we refer to as “micro workflow.” One of the main differences between workflow and micro workflow stems from the scale of the process. Workflow involves largescale processes that execute on top of applications. In contrast, micro workflow 2

involves small-scale processes that execute within applications (hence the name micro). An important consequence of the scale difference concerns users. Workflow targets process designers who typically are non-technical users. In contrast, micro workflow targets people who build applications. Non-technical users and software developers have very different requirements. Therefore, workflow and micro workflow have different requirements as well. Another consequence concerns the processing entities on the work tier. Workflow activities involve applications and humans. At a smaller scale, micro workflow involves the objects that make up object-oriented applications. Having humans perform some workflow activities brings in additional concerns that don’t exist in a software-only context. Therefore, while workflow provides the functionality required to interact with people, micro workflow employs a simpler mechanism that interacts with only with objects. This approach separates the interface mechanisms from the core workflow functionality, allowing them to be varied independently.

3 An Example Let’s consider an example that illustrates the idea of micro workflow. This example corresponds to a simplified billing cycle closure process in a telecommunications billing system. In this system, an account object holds agreements. Each agreement object represents a different product that the customer pays for. A customer has the following agreements with his telecommunications provider: a voice line, a data line, and a wireless phone. In addition to these services, the customer also leases a data modem. Therefore, his account object holds four agreement objects. At the end of the billing cycle, the customer care system computes the balance on the account. The system iterates over the customer’s agreements and asks each agreement object for its subtotal. Next the process adjusts the customer’s credit and computes any additional taxes that he may be subject to. Finally, the customer care system prints out a bill. This micro workflow involves three classes of objects: customer, agreement and account. The agreement objects compute the individual charges at the end of the billing cycle. Likewise, the account object computes the total and the customer object computes the taxes. These activities correspond to task logic and are provided by the customer, agreement and account objects. The process logic specifies the 3

actions performed by the domain objects and their order. However, it knows nothing about the application-specific processing that takes place within these objects, e.g., call rating, account balancing or tax computation.

4 Micro Workflow and Workflow Micro workflow is a subset of workflow. Figure 1 shows the hierarchical relationship between them. On the upper side of the diagram, workflow (labeled “Macro”) involves two humans and two workflow applications. The bubble on the lower side of the figure provides an inside view of Application2. There micro workflow (labeled “Micro”) involves two domain objects, Object1 and Object2. Workflow

Macro

Workflow Application

1

Workflow Application

2

Person 1

Person 2

Micro Workflow

Micro

Object1

Object2

Figure 1: Workflow and micro workflow. Micro workflow differs from workflow in several ways. Let’s look at users, processing entities, and build time and run time environments.

4.1 Users Current workflow management systems target non-technical users. Therefore they attempt to reveal only the concepts and aspects that these users understand. 4

Occasionally users have to write Boolean expressions for enabling conditions. But typically workflow systems don’t require any programming experience. Consequently, the trade press (for example [13]) gives high marks to products that make the experience of building and executing workflows as remote as possible from programming. In contrast, micro workflow targets software developers who implement the processcentric part(s) within object-oriented applications. The focus shifts from hiding the technical details to providing an architecture that is easy to understand, use, customize, and integrate with other environments.

4.2 Processing Entities Workflow management systems delegate the process activities to processing entities. Typically workflow involves people and software applications. The interaction with people requires a model suitable for humans. Humans have long response times and their work contribute to making workflow instances longlived. They are also unpredictable for reasons beyond the scope of the workflow system. Additionally, as far as the workflow system is concerned, humans have very limited availability. The workflow reference model [9] and many systems following it accommodate these characteristics with worklists and worklist handlers. At run time, the workflow system accesses the worklist to assign work items. Likewise, the worklist handler provides a means for the workflow user to retrieve worklist items. Depending on the process requirements, the handler can implement various work scheduling policies—e.g., push or pull [15]. The interaction with software applications requires a mechanism to transfer control to and exchange data. Most workflow vendors publish a set of APIs that enables third-party application developers to write workflow-enabled applications or wrap legacy applications into workflow adapters. For example, products from Ultimus [20] and InConcert [10] take this approach. However, in the absence of a common standard, this is a hard problem. Proprietary interfaces make it difficult for applications to work with more than one workflow system. An application that supports several workflow products would have to implement an unreasonable number of APIs. (The OMG is addressing this problem through its current efforts to adopt a standard for a workflow management facility [18].) Micro workflow implements processes at the object level. For the purposes of this paper, the actors are objects within the application. These objects encapsulate the task logic and provide application-specific functionality. This interaction model only requires that the domain objects respond to certain messages (in 5

dynamically-typed languages) or implement a particular interface (in staticallytyped languages). Therefore, micro workflow has a simpler interaction model than workflow systems. Therefore, a workflow management system packages additional components that support human workers and applications. But this functionality makes the system heavyweight, more complex, and buries the core workflow functionality under additional software layers. The simplified micro workflow interaction model yields a reduced footprint and maintains the focus on core workflow functionality. Micro workflow enables its users to mix and match functionality that is beyond its scope (e.g., worklist management) and add it through composition.

4.3 Build Time and Run Time Environments The different users of workflow and micro workflow yield differences between their build time and run time environments. Non-technical users want complete systems that hide all the technical details they’re not concerned with. Existing workflow systems provide feature-rich environments for this type of users. In contrast, developers want to increase their productivity through software reuse. Ideally they should be able to build software by mixing and matching existing parts. But this requires architectures designed for compositional software reuse and components that provide orthogonal features. Micro workflow focuses on core workflow functionality. Separate frameworks, services or components can provide the functionality that micro workflow shouldn’t implement but is required in workflow management systems. This architectural style enables software developers to pick and choose the types of features they would like to provide. For example, they can add build time environments with frameworks that provide structured drawing editors (e.g., Hot Draw [11]) or read process description languages (e.g., WPDL or XML). Developers could also change the run time environment to use a specific transaction service (e.g., TUXEDO) or the type of persistent store (e.g., relational or object-oriented).

5 Workflow and Compositional Software Reuse Compositional software reuse refers to building systems out of existing parts. Workflow relates to compositional software reuse since from a software reuse perspective, workflow acts as the glue that connects the existing parts.

6

The possibility of producing new applications by combining existing pieces of software could have a dramatic impact on the software development process. Berlin [2] and Garlan and colleagues [8] examine this issue. They conclude that due to architectural mismatches compositional software reuse is more difficult than they thought. These mismatches center around the assumptions made by the reusable components about the structure of the application in which they are to be used. One of the common assumptions that causes mismatches is the control model, i.e., which components control the overall sequencing of computations. Activity-based process models [5] provide an explicit representation of the flow of control and offer a behavioral perspective at the global control level. Workflow could provide a consistent control model in object-oriented applications consisting of reusable classes developed independently. But workflow alone doesn’t necessarily ensure a uniform control model. Gregory Bolcer’s PhD thesis [3] examines this problem in the context of using a workflow tool (Teamware [21]) to provide embedded workflow within office automation applications. Bolcer observes a tension between Teamware and the tools necessary for completing the process activities, as these tools assume that they are the components which control the execution. Part of the research presented in this paper concerns with building an architecture that supports compositional software reuse by combining the focus on control of workflow and the benefits of object-oriented technology.

6 An Object-Oriented Framework for Micro Workflow To test the ideas presented here we have been developing a practical object-oriented architecture that allows software developers to implement business processes within applications. This architecture is currently being implemented as an objectoriented framework [12] in VisualWorks Smalltalk. Figure 2 shows the Smalltalk code that builds the top level part of a workflow for the treatment of strep throat. Figure 3 shows a run time interface that enables framework users to monitor and change executing processes. According to our idea of an architecture that provides core workflow functionality and can be extended through composition, this monitoring facility is not part of the framework. Instead, we built it as an add on that software developers can use if they require this functionality. Our framework provides core workflow functionality that software developers can use right away. Additionally, it allows them to change the workflow and execution models through techniques specific to object-oriented frameworks [19]. The framework also enables software developers to add features beyond the workflow

7

strepThroatProcess | examination test update | examination := PrimitiveProcedure sends: #examine: with: #(#patient) to: #doctor result: #patientNeedsTreatment. test := ConditionalProcedure if: [:arg | arg] for: #patientNeedsTreatment execute: self treatmentProcess. update := PrimitiveProcedure sends: #updateRecordsOf: with: #(#patient) to: #nurse. ^examination , test , update

Figure 2: Building a micro workflow in Smalltalk.

Figure 3: A workflow monitoring facility provided as an add-on for the framework.

8

domain through composition. This represents a significant departure from traditional workflow architectures and the way people use workflow. The goals of our research are:

 To promote object-oriented technology from merely an implementation technique to a complete architectural style for workflow management.  To provide a new workflow architecture that offers core workflow functionality and facilitates its integration with other services and frameworks.  To build an object-oriented framework that developers can use and customize to implement workflow functionality within applications.  To demonstrate that core workflow functionality can be extended with features specific to workflow systems through compositional software reuse.

References [1] F. Anderson and R. Johnson. The Objectiva telephone billing system. MetaData Pattern Mining Workshop, Urbana, IL, May 1998. Available on the Web at http: //www.joeyoder.com/Research/metadata/UoI98MetadataWkshop.html. [2] L. Berlin. When objects collide: Experiences with reusing multiple class hierarchies. In ECOOP/OOPSLA’90 Proceedings, pages 181–193, Oct. 1990. [3] G. A. Bolcer. Flexible and Customizable Workflow on the WWW. PhD thesis, University Of California, Irvine, 1998. [4] C. Bussler. Enterprise-wide workflow management. IEEE Concurrency, pages 32– 43, July–September 1999. [5] A. Cichocki, A. S. Helal, M. Rusinkiewicz, and D. Woelk. Workflow and Process Automation—Concepts and Technology. Kluwer Academic Publishers, 1998. [6] M. Devos and M. Tilman. A repository-based framework for evolutionary software development. MetaData Pattern Mining Workshop, Urbana, IL, May 1998. Available on the Web at http://www.joeyoder.com/Research/metadata/ UoI98MetadataWkshop.html. [7] A. Do˘gaç, L. Kalinichenko, M. T. Özsu, and A. Sheth, editors. Workflow Management Systems and Interoperability, volume 164 of NATO Advanced Science Institutes (ASI), Series F: Computer and Systems Sciences. Springer-Verlag, August 1998. [8] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch or why it’s hard to build systems out of existing parts. In Proc. 17th International Conference on Software Engineering, Seattle, WA, Apr. 1995.

9

[9] D. Hollingsworth. The Workflow Reference Model. Workflow Management Coalition, Avenue Marcel Thiry 204, 1200 Brussels, Belgium, 1995. Available on the Web at http://www.aiim.org/wfmc/. [10] InConcert, Inc., Cambridge, MA. Teoss 2000 with TXM Option, Product Data Sheet, 1999. Available on the Web at http://www.inconcertsw.com/. [11] R. E. Johnson. Documenting frameworks using patterns. In Proceedings of OOPSLA’92, 1992. Available on the Web at ftp://st.cs.uiuc.edu/pub/papers/ HotDraw/documenting-frameworks.ps. [12] R. E. Johnson and B. Foote. Designing reuseable classes. Journal of Object-Oriented Programming, June–July 1991. [13] J. G. Kobielus. Workflow Strategies. IDG Books Worldwide, 1997. [14] R. C. Martin, D. Riehle, and F. Buschmann, editors. Pattern Languages of Program Design 3. Software Patterns Series. Addison-Wesley, October 1997. [15] C. Mohan. Recent trends in workflow management products, standards and research, pages 396–409. Volume 164 of Do˘gaç et al. [7], August 1998. Available on the Web at http://www.almaden.ibm.com/cs/exotica/wfnato97.ps. [16] P. Muth, J. Weissenfels, M. Gillmann, and G. Weikum. Mentor-lite: Integrating light-weight workflow management systems within business environments (extended abstract). Available on the Web at http://www-dbs.cs.uni-sb.de/~gillmann/ Publications/Mentor-Lite-Zurich.p%s. [17] J. Oakes and R. Johnson. The Hartford insurance framework. MetaData Pattern Mining Workshop, Urbana, IL, May 1998. Available on the Web at http://www. joeyoder.com/Research/metadata/UoI98MetadataWkshop.html. [18] Workflow management facility specification. OMG Document Number bom/98– 03–01, 1998. Available on the Web at ftp://ftp.omg.org/pub/docs/bom/ 98-03-01.pdf. [19] D. Roberts and R. Johnson. Evolving Frameworks—A Pattern Language for Developing Object -Oriented Frameworks, chapter 26. In Martin et al. [14], October 1997. [20] Ultimus, Inc., Raleigh, NC. Ultimus Workflow Suite 4, Product Guide, July 1998. Available on the Web at http://www.ultimus1.com/. [21] P. S. C. Young. Customizable Process Specification and Enactment for Technical and Non-Technical Users. PhD thesis, University Of California, Irvine, 1994.

10