OOPSLA'96Business Object Workshop III


Fitting the Workflow Management Facility into the Object Management Architecture

Wolfgang Schulze
Dresden University of Technology, Database Group
Dürerstraße 26, 01307 Dresden, Germany
phone: +49 (0) 351 463 8493, fax: +49 (0) 351 463 8259
Wolfgang.Schulze@inf.tu-dresden.de


The OMG Workflow Management Facility RFP

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.

Architectural perspectives of the
OMG Workflow Management Facility

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.

Conceptual positioning

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.

Relationship towards other OMA components

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].

WorCOS - A Prototypical Implementation

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.

Related work

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.

WorCOS architecture layer overview

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.

  • WorCOS Meta-Object-Facility (MOF): Compared to a full-fledged MOF as provisionally proposed in [OMG97b], the services and the meta-metamodel of the WorCOS MOF are both very limited. The WorCOS MOF provides interfaces to create and manage meta-metaobjects, where each one describes one modeling construct of the WorCOS workflow metamodel. The WorCOS MOF does not support management of multiple workflow metamodels. This approach is justified since our aim was to provide only an explicit representation of the WorCOS workflow metamodel that supports long-term evolution of the Workflow Metamodel.
  • 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).

  • WorCOS Workflow Type Repository (WFTR): The WorCOS WFTR provides interfaces for the creation and management of workflow schemas that comply with the WorCOS workflow metamodel. Each workflow meta-object must have a corresponding meta-metaobject. By default, the WFTR supports a set of predefined concepts of the WorCOS workflow metamodel, for example WorkflowMetaObjects. Those WorkflowMetaObjects can be used to register WorkflowFactories that may be located anywhere in the network.
  • 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.

  • WorCOS Workflow Schema Implementation: At the moment, our prototype does not support to automatically generate implementations for workflow schemas as they are specified within the WorCOS WFTR. Hence, object-servers that implement the WorkflowFactory interface for workflow-objects of a given type have to be implemented manually. Once deployed on an arbitrary network-node, they can be registered at the WFTR for future workflow enactment. Each workflow schema may have an arbitrary number of factories that support the creation of workflow-objects complying to the schema.
  • WorCOS Workflow Objects: In WorCOS, workflow instances are realized as workflow-objects which are true distributed objects created and executed on different computer nodes within a network. In contrast to other approaches, there is no generic workflow engine that processes and enacts the workflow schema. To a certain extent, the workflow-functionality is hardcoded into the workflow-objects. The predominant part of this functionality can be inherited from library functions while specialized functionality has to be implemented for every new workflow-type. The library part of the WorCOS workflow objects supports the basic interfaces that are described in [Schu96a] like:
  • Retrieval of schema-related information (type, version,...)
  • Retrieval of instance-related information (initiator, status,...)
  • Interaction of workflow participants: (accept, delegate, cancel,...)
  • Retrieval of workflow-results (interim and final)
  • 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.

    Conclusion

    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.

    Literature

    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


    OOPSLA'96Business Object Workshop III