Business Object Workshop II

---

Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments

Wolfgang Schulze, Markus Böhm, Klaus Meyer-Wegener
Dresden University of Technology, Database Group
01307 Dresden, Germany
e-mail: {schulze | boehm | kmw}@is2201.inf.tu-dresden.de

Comments:

• Critique by Christopher Spottiswoode

Introduction

After the definition and adoption of basic object services (CORBAservices [OMG95a]), time has come for the Object Management Group (OMG) to address more abstract parts of the Object Management Architecture (OMA). The roadmap for next standardization efforts and the restructuring of its organization clearly show that the OMG is preparing for this challenge: The OMG has introduced four groups of horizontal common facilities: User Interface, Information Management, System Management and Task Management (CORBAfacilities [OMG95b]). The important part of Task Management Facilities shall comprise rule management, object automation, agents and workflow.

The OMG's goal, that "...the Workflow Facility provides management and coordination of objects that are part of a work process [...]" (see [OMG95b], p.5-3) is very vague and leaves much work to be done in order to come to a rigorous definition. Up to now, the OMG has not presented a precise definition of what they understand as a "workflow" in this context. Even worse, the placement of workflow functionality within the OMA is in debate, too. The publications of the OMG BODTF (Business Object Domain Task Force) clearly identify workflows as a special form of business objects, consequently calling them "business process objects". This leads to the effect that they are either located inside a Business Object Facility or under the "applications" section of the OMA but not inside the Task Management Facilities.

We hold the view that the original plan to introduce a dedicated workflow facility is the right choice and its rapid availability is of vital importance for the OMG. The perspective of this workflow facility, a clarification of the functions of workflow objects and their inseparable workflow meta-objects are key issues of this paper.

Our research project WorCOS (Workflow Management based on Components and Object Services) sets out to demonstrate the integration of workflow functionality into OMG-compliant architectures while keeping a maximum of consistency with CORBAservices and CORBAfacilities. We have put special attention to the tight integration of business entity objects and workflow objects.

Statements

In the following, we present a set of eight statements which are related to the issue of workflow objects. All of the statements offer some problem description and/or a critique of current technology. In some cases, we are able to propose a solution while others are beyond our sphere of influence.

Workflow Objects are fractal structures

In accordance to Taylor [Tayl95a] and Jablonski [Jabl94a], we see Workflows as "fractal structures" that can be arbitrarily nested. A workflow may contain any number of sub-workflows and thus can be realized using the recursive "COMPOSITE"-pattern introduced in [Gamm95a].

We consider it an important issue that the leaves of hierarchically composed workflow structures are again workflows. This insight is not well supported by the model of the Workflow Management Coalition (WfMC), because the WfMC has instead adopted the notion of an "activity" [WfMC96a]. One might argue that "activity" and "elementary workflow" are just different terms for the same concept, but this is only partially true. Only when a WFMS treats activities as special workflows it can offer the unlimited range of reusability and flexibility. Only if activities and workflows export a common set of basic functionality, it is possible to make incremental refinements of initial workflow designs by replacing activities with more complex workflows.

Workflow Objects are (CORBA) objects with specific services

We agree with the OMG BODTF that workflows (=business process objects) are a special kind of business objects. While business entity objects represent more static concepts, workflows have a more dynamic character because they represent the flow of work through the business. Up to now, the BODTF has not circumscribed what basic services, what behavior is expected from those workflow objects. Since the behavior is expressed by the set of defined functions, we introduce them in a structured manner. Many of the services that a workflow object exposes depend on its internal state. It is easy to understand that a workflow cannot answer queries about its termination-time until it has actually come to an end. At any time before, the result of such a query would be undefined.

States of Workflow Objects

After a workflow object has been created and parameterized, it can run into different states. We concentrate on describing only "significant" states that give different preconditions for the fulfillment of service requests. The states serve as the structuring criterion for the listing of the workflow services.

Note that the diagram only shows the state-transition of an elementary workflow. The state of a composite workflow consists of a status-vector and is therefore more complex.

Service availability

The following table gives a very compressed list of the most basic services that a workflow object must support during its life-cycle.

The list above can only list the generic services that each workflow object must offer (independent of its type). In WorCOS, different workflow types are also reflected in different interfaces. This means that special workflow types are derived from a generic workflow class. Thus it is possible to extend the interface of basic workflows by type-specific functionality that is only adequate for a special workflow type. As an example, a workflow-object that supports the creation of a research paper might offer a specialized service to retrieve the title of the paper.

To sum up, all of the mentioned services should be offered and realized by the workflow object itself and not by some other infrastructural element. The workflow object gains a life of its own and is visible as an entity throughout a software system. Using a normal CORBA-reference to the workflow object allows any application to integrate the workflow's functionality.

Workflow Meta-Objects are first-class objects

Workflows are always executed according to a given workflow description. It does not matter whether the description is represented as a "set of procedural rules" (see [WfMC96a], p.7) or as a workflow script in some formal language. In all cases, workflow objects should not be seen isolated from their workflow definition. The workflow definition contains information like the workflow's structure, including a description what has to be done and who is in charge to do it. This means that workflow definitions contain information about workflow objects and therefore must be seen as meta-objects. The table below contains a short outline what basic services such a workflow meta-object has to deliver:

Modeling the selection of a suitable actor for a given workflow in today's systems is achieved with very crude mechanisms. In most cases, simple role/group mechanisms are used which are completely inadequate as soon as any complex actor selection policy is required. When actor-selection is done by some specific algorithm (e.g. based on some trading-approach), it is very hard to capture this policy in the workflow description. For this reason, we have additionally introduced meta-objects for actors that describe how the selection is actually to be done.

Workflow Meta-Objects are the key to workflow reuse

Growing exploitation of workflow technology within an organization may quickly lead to the introduction of a vast number of different workflow types. In order to keep the set of workflow types manageable (minimal and structured), it is necessary to reuse existing workflow types. Reuse here means the possibility to build new workflow types by composition of existing ones. This can only be achieved when the workflow designer is provided with mechanisms that allow him to structure, analyze and query previously defined workflow types.

Current WFMS-technology neglects this important aspect of an advanced management of workflow meta-objects. Most striking underpinning of this assertion is that even the WfMC's reference architecture [WfMC96a] still lacks a dedicated architectural component for it. Storage, retrieval and management of "process definitions" are located somewhere inside the "Workflow Enactment Service" but not identified as an entity of its own. We consider a well-founded administration of workflow meta-objects a major concern that has to be addressed by a highly specialized architectural element. This element, which in WorCOS is called Workflow Type Repository (WFTR) offers not only a safe storage of workflow meta-objects but allows for sophisticated retrieval mechanisms based on keywords and complex semantic relationships between different workflow meta-objects. We plan to realize services for the versioning of meta-objects and for the evolution of workflow schemata.

The Workflow Facility can be built using existing CORBAservices

In order to support this statement, we will first make clear what we consider to be elementary services of the workflow facility. We can identify two major subsystems of the workflow facility:

Both subsystems have numerous areas where CORBAservices can ideally be used, but a comprehensive analysis would go beyond the scope of this position paper. For example, typed relationships implemented with the Relationship Service might be used for modeling dynamic interconnections of workflow objects as well as representing relationships with various semantics inside the WFTR (versioning, inheritance, etc.). Another important candidate is the Event Service which can be used for realizing reliable communication between decoupled workflow-participants. Last but not least we must mention the Object Transaction Service which provides mechanisms that allow the creation of workflows that adhere to the ACID-principles. In order to support uniformity and generality, the workflow facility should also make use of CORBAfacilities. Here, the most obvious facility that can support our workflow environment is the Meta-Object Facility which could be a solid foundation for the implementation of WFTRs.

A Workflow Facility should be lightweight

It has been a good tradition within the OMG to keep specifications as lean as possible while at the same time rigorously capturing the core functionality. This principle should be kept up although workflow vendors will try to force existing technology through the OMG's committees.

Today's workflow management systems are mostly based on a component that executes some kind of workflow script in order to enact workflow instances. We call this the "Engine Approach". But whether this component is centralized or distributed (for different architecture models see [Mill95a]), this approach has some notable drawbacks: It is a substantial waste of computing resources, often inefficient and thus hardly suitable for huge-scale, industrial-strength applications. The workflow script has to be interpreted again and again for each and every workflow instance. Since the majority of available workflow products relies on this approach, executing some thousand concurrent workflow instances imposes a great technical challenge for most products. Often it is even infeasible.

Recent announcements of the OMG say that an RFP for a Workflow Facility is planned for 8/96 and it is considered to be sure that the Workflow Management Coalition (WfMC) will submit a response. The WfMC is a consortium consisting of workflow vendors and users that tries to establish a common terminology [WfMC96a] and standards in the area of workflow management. It is very likely (and in some way understandable) that the WfMC will submit its current technology with only minor changes. Within the submission, the existence of a workflow engine will undoubtedly be taken for granted.

In our consideration, this is not satisfactory because of the following reason: In contrast to the OMG's, the specifications of the WfMC are created by reconciliation of the interests of vendors with existing products. Admittedly, the APIs of the WfMC are specified in IDL, but the architectural principles of the OMG were not used as basis for the WfMC reference architecture. Accepting a slightly modified WfMC-proposal as an OMG-standard bears the danger of establishing a heavyweight architecture.

In WorCOS, we introduce an approach of "compiled workflows" that treats workflows just as normal CORBA-objects. To some extent, this eliminates the need for a workflow engine and thus allows for implementations that are lightweight and better manageable. In addition, this opens up the possibility of a seamless integration of workflow functionality into OMA environments, because regarding workflows as independently-developed executables allows for "plug-and-play" integration [Sims96a].

The Workflow Facility shall integrate with Business Objects

The BODTF has made the commendable attempt to work out a concept that is consistent with the rest of the OMG OMA. It can be expected that a variety of business objects will become standardized and that they will be supported by services provided by a Business Object Facility. In order to serve their specific purpose, business objects will have very specialized interfaces. It is easy to predict that companies that establish a business object infrastructure will have a growing demand to invoke their interfaces during workflow enactment. In consequence, this means that current WFM paradigms (including the WfMC's) are in many ways unsuited. Integration must take place with a much finer granularity which means invoking methods of business objects rather than executing monolithic applications.

The Definition of a Workflow Facility is of high priority

Although there is no commonly accepted foundation for a "workflow theory" and workflow technology is in a very early stage, there nevertheless are a number of motives why a workflow facility is strongly needed. Here, we only want to point to the requirement for a uniform interface of workflow-support and a consistent workflow-behavior across multiple applications. Therefore, the most important goal is the elimination of duplicate workflow support in different systems.

But despite those technological motives there exists a political aspect, too. Introducing a standard may hopefully prevent proprietary solutions from becoming established.

Conclusion

We have presented reasons why the OMG should come up with the specification of a workflow facility in the near future. Some important aspects concerning the functionality of workflow objects were introduced together with some corresponding requirements about workflow meta-objects. We have worked out a number of conceptual and technical weaknesses of the WfMC approach and have shown how to avoid them. It has not been our intention to provide just another list of requirements. We are working on a prototype that will cope with the majority of those issues. At the moment, we are in the phase of implementing those concepts and we hope that it can serve as a reference implementation for the ideas presented in this paper.

Acknowledgments

The work described in this paper is partly financed by the Hanns-Seidel-Foundation. Further, we wish to thank IONA Technologies for providing us with a CORBA implementation as part of the OrbixAward96.

---

Literature

Gamm95a Gamma, E. et. al.: "Design Patterns - Elements of Reusable Object-Oriented Software", Addison-Wesley professional computing series, Reading, Massachusetts, 1995

Jabl94a Jablonski S.: "MOBILE: A Modular Workflow Model and Architecture", in: Proceedings of the 4th International Working Conference on Dynamic Modelling and Information Systems, Noordwijkerhout, Netherlands, September 1994

Mill95a Miller J.A., Sheth A.P., Kochut K.J., Wang X.: "CORBA-Based Run-Time Architectures for Workflow Management Systems"; in: Journal of Database Management, Special Issue on Multidatabases, Vol. 7, No. x, 1996

OMG95a Object Management Group: "CORBAservices: Common Object Services Specification", revised edition, March 31, 1995, OMG Document 95-3-31

OMG95b Object Management Group: "CORBAfacilities: Common Facilities Architecture", Revision 4.0, November 1995

Sims96a Sims, O.: "The OMG Business Object Facility and the OMG Business Object", Discussion paper for the CORBAfacilities task group, OMG Document cf/96-02-03

Tayl95a Taylor, D.A.: "Business Engineering with Object Technology", Wiley & Sons, Inc., 1995

WfMC96a Workflow Management Coalition: "Workflow Management Coalition: Terminology & Glossary", Document Number WFMC TC 1011, Issue 2.0, June 1996

Business Object Workshop II