Ever since it has been published in 1995, the Common Facilities part [OMG95a] of the Object Management Architecture (OMA) had a placeholder for an architectural component that "provides management and coordination of objects that are part of a work process" - the Workflow Facility. In January 1997, the Object Management Group (OMG) established a workgroup to create and issue a Request For Proposals (RFP) for this Workflow Facility. After several meetings and intensive discussion, the group adopted a draft of the RFP [OMG97a] at the OMG Technical Meeting in March 1997 (Austin/Texas). This draft has been presented to the OMG Architecture Board for approval at the OMG Meeting in Stresa/Italy. With some minor modifications, the final RFP [OMG97d] has been issued on May, 9th 1997. The appointment of a workgroup to issue a Workflow Management Facility RFP overturned the Workflow Management Coalition’s initiative [Work96a] to submit their non-object-oriented technology through a fast-track process (RFC) without further discussion.
Essentially, the Workflow Management Facility RFP has two key requirements: Submissions shall provide a semantic definition of a workflow metamodel and specify a set of interfaces for workflow enactment. The RFP states that the Workflow Management Facility "defines interfaces and their semantics required to manipulate and execute workflow objects and their metadata" (see [OMG97a], p.1). This means that the OMG starts from the assumption that in a CORBA environment, each workflow instance is realized as an individual object that exposes an interface.
This section will try to identify the position of the Workflow Management Facility in two ways: First, we approach the conceptual position considering current attempts to resolve boundary and overlap problems with other existing or envisioned CORBAfacilities. Afterwards, we show some perspectives of the (re-)use of established OMG technology.
Currently, the OMG is very active in finding the right boundaries between the Meta Object Facility (MOF), the Business Object Facility (BOF) and the Object Analysis and Design Facility (OA&DF). It has been decided to take the MOF as a foundation and reference point for all other facilities and this means that the Workflow Management Facility also has to integrate into this overall picture. The following figure shows this layered approach, well known from IRDS (see [ANSI88a, Byrn96a]).
Figure 1: Fitting the Workflow Facility into a 4-layer architecture model
The MOF exposes a set of interfaces to create and manipulate arbitrary metamodels. The MOF’s own meta-metamodel (shown as light-grey box), that is hard-coded in the MOF implementations, provides the modeling constructs to achieve this functionality.
Since the MOF is expected to manage all kinds of metamodels that are relevant inside the OMA, it should be capable to represent the workflow metamodel of the Workflow Management Facility as well. In other words, if a submission for the Workflow Management Facility introduces a workflow metamodel containing modeling-concepts like "workflows", "activities" or some control-flow-constructs, they all must be representable as instances of the MOF’s meta-metamodel. Reasons for this requirement are: support for application development, interoperability between different facilities and runtime discovery of metamodels. In order to enable the desirable degree of semantic interoperability among different workflow management and development tools, the workflow metamodel has to be precise, concise and internally consistent.
Current drafts for MOF submissions are mostly based on the requirement to define the CORBA Object Model and both the BOF metamodel and the OA&DF metamodel. Admittedly, this is a tough task, but those metamodels focus mostly on structural aspects. In addition to that, workflow metamodels not only introduce the dimension of time, but also other aspects that may pose some difficult challenges towards the MOF’s meta-metamodel. Figure 2 shows five of the most important modeling aspects of workflow metamodels (see [Jabl96a, Bußl96a]) and tries to relate them with some of the MOF-types that could be used to model the respective aspect. The names for the MOF modeling concepts are taken from the JMOF proposal [OMG97b].
Only for very simple workflow metamodels is it possible to find adequate representations of all aspects. For example, it must seriously be doubted that the provided meta-metamodel is capable to model the variety of prescriptive control-flow dependencies and descriptive execution constraints found in comprehensive workflow metamodels (see [Atti93a, Jabl94a]).
Figure 2: Representing a workflow metamodel using the proposed JMOF meta-metamodel (see [OMG97b])
According to the usual 4-layer-architecture, below the metamodel layer comes the model layer, which in our case is the place for workflow schemas. A workflow schema is a specification of how workflows of a given type should be executed. An example could be a workflow schema for travel-reimbursement. According to the terminology used in the Workflow Management Facility RFP, a workflow schema is a composition of related meta-objects that together represent the semantics of workflows. The variety of different types of meta-objects depends on the richness of the workflow metamodel. Hence, providing interfaces to create and manipulate workflow schemas is one of the major requirements of the Workflow Management Facility.
Finally, on the lower two levels there are two ways to implement the workflow instances. The first solution is the "classical way", where a generic workflow engine is employed to interpret the workflow schema at runtime in order to create and enact workflow instances. An alternative approach implements workflow instances as distributed objects. Different types of workflow objects need specific workflow object-servers that implement exactly the specified services. Hence, the workflow schemas may serve as a basis to generate skeleton implementations. Considering the 4-layer-architecture, both approaches are equally valid.
A major requirement for all new OMG specifications is that they have to adhere to the principle of service orthogonality. This means that they must make use of existing OMA components instead of duplicating functionality. The Workflow Management Facility provides a lot of starting points where existing parts of the reference architecture can possibly be applied. We can only sketch a small number of possible applications:
The Event Management Service can be used to propagate changes of state of workflow instances and to synchronize the worklists of workflow participants. The Life Cycle Service will be required to realize the creation, migration or replication of workflow objects in a compliant manner. The Relationship Service is a good candidate to realize any kind of runtime relationship between workflow objects. A simple example for such a relationship is execution-sequence between different parts (sub-workflows) of workflow. The Transaction Service may provide atomic updates of sets of meta-objects within workflow schemas as well as runtime-support for transactional activities during workflow enactment. For a comprehensive examination of the applicability of CORBAservices and CORBAfacilities see [OMG97c, Schu97a].
Two years before the OMG started thinking about concrete requirements for workflow-management within the OMA, the WorCOS project (Workflow Management based on Components and Object Services) has been established. Right from the start, our goal was to design and implement an OMA-compliant workflow-management service, which complies with the design-goals given by the OMG (see [OMG95b]). Many things that we have learned through this experience have been carried into the final RFP document.
There are a number of projects that make use of CORBA technology for the implementation of workflow-management-systems in one way or another. In most cases, the ORB is just the means to an end. It is employed in its role as a generic middleware (see e.g. [Bern96a]) – to overcome heterogeneity of hardware and operating systems and to provide an easy way to interconnect components on different nodes using RPC-style communication. Very few researchers have realized the potential of CORBAservices and there is only a small number of projects actually implementing workflow-management-functionality with them.
VORTEL (see [Böhm95a, Bapa96a]) is a typical example of the first category, where DEC’s ObjectBroker was used to create interoperability between the following workflow management products, each running on a different platform: FlowMark (IBM), Linkworks, (DEC) and CORMAN (FhG). DOPAS, a CORBA-wrapped ObjectStore-Database was used to create a centralized registry for workflow-schemas and workflow instances.
MENTOR [Wodt95a] uses an ORB to wrapper existing applications in order to execute them as workflow applications during workflow enactment. However, the main focus is on partitioning workflow schemas and supporting workflow enactment with the well-known functionality of a TP-Monitor (Tuxedo).
Both, the METEOR [Krish94a] and the METEOR2 project [Shet96a, Mill97a] focus on supporting wide-area workflows having transactional behavior. Their prototypes OrbWork and NeoWork (see [Das97a]) work out different styles of workflow runtime-architectures. But again, CORBA is only treated as just one implementation alternative. No special attention is given to the potential use of CORBAservices.
BPAFrame (see [Schi96a, Mitt96a]) is a multi-use agent-based framework which has been applied to build a workflow-management system. Notably, it makes use of an OMG-compliant EventService (OrbixTalk) in order to synchronize worklists of different workflow-participants and it exploits the CORBA Dynamic Invocation Interface (DII) to invoke operations on business objects during workflow enactment.
The architecture of our WorCOS prototype conforms to the layered approach introduced in the previous chapter – all four layers are covered. The following paragraph describes all layers, beginning from the top-level. When we started out with the design, there was no perspective for a specification of the Meta-Object-Facility, so we decided to build our own lightweight Meta-Object-Facilty that fulfills some of our needs.
The capabilities of the meta-metaobjects are very ascetic: they only provide a name and a brief description for their corresponding modelling construct with a set of descriptive terms. In addition to that, it is possible to define basic relationships between them. Each meta-metaobject retains a queryable list of all meta-objects that use it. For example, a meta-metaobject for the concept of an "activity" could be asked about all activities that are defined on the model layer (workflow schema-level).
An implementation of the WorCOS WFTR (see [Weis96a]) has been realized successfully with SunSoft’s CORBA-implementation NEO and actually makes extensive use of NEO’s rich set of implemented CORBAservices like Naming, Relationship, LifeCycle and Events. In addition, an OMG-compliant implementation of the Collection Service [OMG96a] is used.
This kind of architecture supports extensibility on two levels. New modeling concepts can be "plugged" into the workflow metamodel using the WorCOS MOF interfaces to create new meta-metaobjects and to register object-factories that create the corresponding part of the workflow schemas. Dynamic extension is also possible at the workflow schema implementation level. Each workflow schema may have an arbitrary number of implementations that can be realized using any kind of language on arbitrary platforms. New implementations are registered at runtime at the WorCOS WFTR. In theory, the only prerequisite is a CORBA2.0-compliant ORB and that the required interfaces are supported. But our implementation experiences during the last months have shown that current Object Request Brokers still have difficulties implementing the Internet-Inter-ORB-Protocol (IIOP) which is required for this kind of interoperability.
By the end of 1997, two fundamental cornerstones for domain-oriented facilities of the OMA will be finished: The Meta Object and the Object Analysis & Design Facility. The positioning of these facilities influences and defines the position of the Workflow Facility within the reference architecture. We have shown that it is possible to smoothly integrate the Workflow Facility using the 4-layered-approach. The OMG workflow workgroup will have the obligation to find a reference model for the Workflow Facility that ultimately defines the boundaries and the dependencies towards other CORBAfacilities. This reference model would be a good guidance for potential submitters and during the assessment of the proposals, it could serve as a foundation to find the right evaluation criteria.
We have proposed a conceptual model for the OMG Workflow Management Facility that potentially covers all of the aspects of the RFP. The model is generic since it does not make many assumptions about the workflow metamodel. With the possibility to customize the workflow metamodel, it is also extendable. And finally, runtime-scalability is supported, because the number of workflow-servers, that is workflow schema implementations, may be adjusted with respect to growing requirements.
ANSI88a American National Standard X3.138-1988: Information Resource Dictionary System; American National Standardization Institute, New York 1988
Atti93a Attie P., Singh M., Sheth A., Rusinkiewicz M.: "Specifying and Enforcing Intertask Dependencies", in: Proceedings of the 19th International Conference on Very Large Data Bases (VLDB), August 1993.
Bapa96a Bapat A. et al.: "The VORTEL Project", De.Te.Berkom-Projekt Vorgangsbearbeitungs-Teleservice (VORTEL) - 6.Meilenstein: Final Report, The VORTEL consortium, Berlin 1996
Bern96a Bernstein Ph.A.: "Middleware: A Model for Distributed System Services" in: Communications of the ACM, February 1996, Vol. 39, No.2, pp.86-98
Bußl96a Bußler C.: "Specifying Enterprise Processes with Workflow Modeling Languages". In: Concurrent Engineering: Research and Applications. Special Issue: Application of Enterprise Modelling Languages for Concurrent Engineering. Vol. 4, Nr. 3, September 1996
Böhm95a Böhm M., Deiters W., Friedrich M.; Lindert F.; Schulze W.: "Workflow Management as Teleservice", in: The international Journal of Computer and Telecommmunications Networking, "Computer Networks and ISDN Systems", Elsevier Publishing, 28 (1996), pp.1961-1969
Byrn96a Byrne B.: "IRDS Systems and Support for Present and Future CASE Technology" in: Proceedings of CAiSE’96 DC, W4, Heraklion, 1996
Das97a Das S.; Kochut K.; Miller J.; Sheth A.; Worah D.: "ORBWork: A Reliable Distributed CORBA-based Workflow Enactment System for METEOR2", Technical Report UGA-CS-TR-97-001, Department of Computer Science, University of Georgia, February 1997
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
Jabl96a Jablonski S., Bußler C.: "Workflow Management – Modeling Concepts, Architecture and Implementation", International Thomson Publishing, Bonn, 1996
Kris94a Krishnakumar N., Sheth A.: "Managing Heterogeneous Multi-system Tasks to Support Enterprise-wide Operations", Technical Report TR-CS-94-002, LSDIS Lab, Department of Computer Science, University of Georgia, September 1994.
Mill97a Miller J.A, Palaniswami D., Sheth A., Kochut K., Singh H.: "WebWork: METEOR2’s Web-based Workflow Management System", Technical Report UGA-CS-TR-97-002, University of Georgia, Department of Computer Science
Mitt96a Mittasch Ch., Irmscher K., Ziegert Th., Lodderstedt T., Müller S., Sommerfeld K.: "User Services in BPAFrame - a Framework for Workflow-Management-Systems", IFIP World Computer Congress, Canberra, Sept. 1996, In: Terashima, N.; Altman, E. (Eds.): Advanced IT Tools, Chapman & Hall, S. 303-310, 1996
OMG95a Object Management Group, "CORBAfacilities: Common Facilities Architecture", Revision 4.0, November 1995
OMG95b Object Management Group, "Object Management Architecture Guide", Third Edition, June 13, 1995, R.M. Soley (ed.), John Wiley & Sons, Inc., New York
OMG96a Object Management Group, "Object Collection Service", second revised version, OMG-Document orbos/96-05-05, adopted October 30th, 1996
OMG97a Object Management Group, "Workflow Facility RFP", Revised Draft approved by Workflow Workgroup on March 14th, 1997, OMG Document cf/97-03-14
OMG97b Object Management Group, "Joint Meta-Object Facility Proposal", Proposal to the CFTF RFP-5 by Unisys, IBM, Oracle, SSA and ICL, January 14th, 1997, OMG Documents cf/97-01-13 to cf/97-01-19
OMG97c Object Management Group, "Towards an OMG-style Workflow Facility", Presentation by Wolfgang Schulze to the Common Facilities Task Force, OMG Technical Meeting, Tampa, January 14th, 1997, OMG Document cf/97-01-22
OMG97d Object Management Group, "Workflow Management Facility RFP", issued on May 9th, 1997, OMG Document cf/97-05-06
Schi96a Schill A.; Mittasch Ch.; "Workflow Management Systems on Top of OSF DCE and OMG CORBA" in: Distributed Systems Engineering Journal, December 1996
Schu96a Schulze W.; Böhm M.; Meyer-Wegener K.; "Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments", OOPSLA’96, Workshop on Business Object Design and Implementation, San José, CA, October 6th, 1996
Schu97a Schulze W.: "Objektorientierte Implementierungstechniken für Workflow-Management-Systeme in OMA-konformen Architekturen" in: Workflow-Management: Entwicklung von Anwendungen und Systemen, Editors: Jablonski S, Böhm M., Schulze W., dpunkt-Verlag Heidelberg, 1997, (in German)
Shet96a Sheth A., Kochut K., Miller J., Worah D., Das S., Lin C., Palaniswami D., Lynch J., Shevchenko I.: "Supporting State-wide Immunization Tracking using Multi-Paradigm Workflow Technology" in: Proceedings of the 22nd Intl. Conf. on Very Large Databases (VLDB96), September 1996, also available as Technical Report UGA-CS-TR-96-001, Department of Computer Science, University of Georgia
Weis96a Weise D.: "Verwaltung von Vorgangstypen in einem Repository als Basisdienst einer objekt- und dienstorientierten Workflow-Architektur", Master’s thesis (Diplomarbeit) at the Dresden University of Technology, October 31st, 1996, (in German)
Wodt95a Wodtke D., Weissenfels J., Weikum G., Kotz-Dittrich A.: "The Mentor Project: Steps Towards Enterprise-Wide Workflow Management", Proceedings of the 12th IEEE International Conference on Data Engineering, 1996
Work96a Workflow Management Coalition: "Workflow Facility Specification", Document Number WFMC-TC-2101, Working Draft, November 1st, 1996