BPDM Response Revised Submission 04-08-03

7/30/2019 BPDM Response Revised Submission 04-08-03

1/215

Business Process Definition Metamodel 1

bei/2004-08-03

Date : August 2nd 2004

Vers ion : 1.0.2

Revised Submission to BEI RFP bei/2003-01-06

Business Process Definition Metamodel

Submi t te r s :

International Business Machines

Adaptive

Borland

Data Access Technologies

EDS

88 Solutions

Suppor te rs :


2/215

2 Business Process Definition Metamodel

BEA Systems

BPMI.org

IDS Scheer

Intalio

Popkin Software

Unisys


3/215


Par t I I n t r o d u ct i o n

Tab le o f con ten t s

TABLE OF CONTENTS 3

COPYRIGHT WAIVER 67

SUBMISSION CONTACTS 78

OVERVIEW OF SUBMISSION 910

Guide to the material in this submission 1011

Overall design rationale 1112

Statement of proof of concept 1213

Change History 1213

RESPONSE TO RFP REQUIREMENTS 1415

Mandatory Requirements 1415

Optional Requirements 1920

Issues to be discussed 2021

SCOPE OF THE SUBMISSION 2425

Proposed Conformance Criteria 2627

Proposed Normative References 2728

Proposed List of Terms and Definitions 2728

Proposed List of Symbols 2930

BUSINESS PROCESS DEFINITION METAMODEL 2930

Concepts and Overview 3031


4/215


Conceptual Metamodel Overview 4847

Identified Subset of the UML 49

Semantics 50

Examples & Discussion 62

APPENDIX A: A UML PROFILE FOR BPD WITH A MAPPING TO BPEL4WS 7069

Model-driven business integration 7170

UML profile 7372

Defining a business process 7473

Dependency management 8180

External packages 8584

Data types and interfaces 8786

Properties and correlations 9392

Protocols 9998

Process, state, and ports 103102

Data handling 110109

Basic activities 116115

Activity coordination 128127

Error handling 138137

Example Marketplace 144143

Example Loan approval 147146

Quick reference 158157

UML Profile Definitions 170

APPENDIX B: MAPPING THE BPD METAMODEL TO BPEL4WS 171

BPD metamodel to BPEL4WS Mapping 171

APPENDIX C: MAPPING EDOC TO BPD PROFILE 177

APPENDIX D: MAPPING BPMN TO BPD PROFILE 178


5/215





6/215


COPYRI GHT W AI VER

Copyright 2003 International Business Machines, Adaptive, BEA Systems, Borland, BPMI, Data Access technologies, EDS, Unisys and88 Solutions.

International Business Machines Adaptive, BEA Systems, Borland, BPMI, Data Access technologies, EDS, Unisys and 88 Solutions

hereby grant to the Object Management Group, Inc. a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute thisdocument and to modify this document and distribute copies of the modified version.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of thisdocument does not give you any license to these patents.

Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included

material of any such copyright holder by reason of having used the specification set forth herein or having conformed to any computer

software to the specification.

NOTI CE

The information contained in this document is subject to change without notice.

The material in this document details an Object Management Group specification in accordance with the license and notices set forthon this page. This document does not represent a commitment to implement any portion of this specification in any companies'

products.

WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE OBJECT MANAGEMENT GROUP,INTERNATIONAL BUSINESS MACHINES AND BEA SYSTEMS MAKE NO WARRANTY OF ANY KIND WITH REGARDS TO THIS MATERIAL

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The aforementioned copyright holders shall not be liable for errors contained herein or for incidental or consequential damages inconnection with the furnishing, performance, or use of this material.

The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall

at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks,

trademarks or other special designations to indicate compliance with these materials. This document contains information which is

protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any formor by any means-graphic, electronic or mechanical, including photocopying, recording, taping, or information storage and retrievalsystems-without permission of the copyright owner.

RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c)

(1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.


7/215


OMG and Object Management are registered trademarks of the Object Management Group, Inc. Object Request Broker, UML, Unified

Modeling Language, the UML Cube Logo, MDA, Model Driven Architecture, OMG IDL, ORB CORBA, CORBAfacilities, and CORBAservices

are trademarks of the Object Management Group,

Sub m ission Cont act s

The primary contact person for this submission is Sridhar Iyengar (IBM), any feedback on this submission can be sent to any of thesubmission contacts.

I BM

Jim AmsdenJoachim Frank

Tracy Gardner

Pablo Irassar

Sridhar Iyengar ([email protected])Simon JohnstonStephen White

A d a p t i v e

Pete Rivett ([email protected])

BEA Sys t em sEd Cobb ([email protected])

Yaron Goland

Bor landKarl Frank ([email protected])Randy Miller

BPMI

Layna Fischer ([email protected])

Data Access Techn o log ies

Cory B. Casanave ([email protected])


8/215


EDS

Fred Cummins ([email protected])

I DS Scheer

Georg Simon ([email protected])

I n t a l i o

Ashish Agrawal ([email protected])

Po p k i n So f t w a r eMartin Owen ([email protected])

Un isys

Sumeet Malhotra ([email protected])

8 8 So l u t i o n s

Manfred Koethe ([email protected])


9/215


Overv iew o f Subm iss ion

This document provides a more detailed response to the Business Process Definition Metamodel Request for Proposals. This is the firstrevised submission, and although far more complete than the initial submission it is expected that a further revision will be needed to

complete the definition.

In addition to responses to each of the requirements set out in the RFP, a description of the objectives of the submission is included to

further specify the intent of this submission.

The primary objective of this submission is to provide an abstract model for the definition of business processes either as a stand-alone activity or in the context of a broader business modeling program. This metamodel is positioned both in terms of its role within

the broader context of business modeling as well as in the context of the OMG Model Driven Architecture (MDA) initiative.

We also provide appendices that demonstrate how this metamodel may be used by tools with alternative graphical notations (bymapping the Business Process Modeling Notation, or BPMN, to this metamodel). The UML 2.0 is a perfectly adequate metamodel forcapturing business models and specifically business process definitions; however it is clear that only a subset of UML2 used in

particular ways is useful and so our work is in the form of a constrained subset of the UML. We expect that future revisions will expand

this support by encompassing the work of existing business modeling notations as well as demonstrating the use of the UML notation

for business modeling.

We also demonstrate how this metamodel can be used to generate platform-specific process languages, specifically the BusinessProcess Execution Language for Web Services (BPEL4WS). These mappings act as a validation of the model by ensuring that

metamodel fits the needs of business modelers, and that developed models can be automated and deployed.

Finally, the UML profile introduced in the submission is documented and demonstrated by example; however more detail will be

Business Process Definition Metamodel

Information ResourceProcess

BPMN

Mapped to

Mapped to

UML 2.0 Other

BPEL4WSJ2EE Other


10/215


provided in a revised submission.

Gu i d e t o t h e m a t e r i a l i n t h i s s u b m i s si o n

The metamodel documented in this submission provides a common language, for describing business processes in an implementation

independent manner. This is not to say that the models are abstract from execution details, on the contrary it is our aim to describe

executable processes, these models are intended to be abstract from the detailed implementation (platform) mechanisms. This shared

subset of UML 2.0 also acts as an agreed base for translation to such implementations where required. The adopted UML 2.0superstructure metamodel provides much of what is required for the definition of business processes.

The following semantics are not present in UML 2.0 and are introduced in the Business Process Definition Metamodel:

?? Resource modeling (deferred until later submission)

?? Access control (deferred until later submission)

?? Compensation

?? Annotations for simulation (deferred until later submission)

?? Correlation (routing of incoming requests to the appropriate process instance, deferred until later submission)

?? Observation (audit/monitoring, deferred until later submission)

The specification of the exact UML 2.0 subset in the area of PIM and alternate PSM models is still under development but will becompleted in a revised submission.

The submission contains the following specification details.

UML 2 .0 Pro f i le fo r BPD

The metamodel proposed here is specified as a UML 2.0 profile because, although a specialized notation for Business Process Definitionmay be preferable for some scenarios, there is also value in enabling generic UML tools to both author and consume business models.It will be important for some of the identified roles because they would be transforming from the business models into IT models, such

as transformations from business information models into data models.

UML 1 .5 Pro f i le fo r BPEL4WS


11/215


An existing UML 1.5 profile for automated business processes with a mapping to BPEL4WS is included in Appendix A. This profile will

be updated to meet the requirements of this RFP. The mapping has been implemented and provides a proof of concept for mapping

from a UML-based business process definition language to a specific execution language.

The audience for this model is primarily technical information technology staff realizing processes in runtime software. The profile actsas a UML-based visualization for a language which has no standardized or described graphical notation.

Mapp ing f r om BPD Me tam ode l to BPEL4WS

This identifies a mapping from this profile directly to BPEL4WS.

The audience for the BPD metamodel is business users more concerned with the capture of the business semantics of their processesthan the details of a runtime implementation. This mapping provides a route from the business-level model directly to a runtime

model.

Mappin g f rom EDOC to BPD Metam ode l

This demonstrates that the set of concepts and model elements developed by EDOC are similarly available when using the BPDMetamodel. In this case by mapping from the EDOC profiles to the BPD profile an automated mapping could be developed by a tool

vendor to translate user developed models from EDOC to BPD.

Mapp ing f r om BPMN to BPD Me tamode l

It is also important to understand that the UML notation however is frequently seen as daunting or too technical for businessanalysts and so we expect and encourage others to provide alternate notations for the subset of the UML that we propose here.

One of the submission goals is to make the UML notation less daunting to the business user, primarily by understanding existing

notations. This will be further addressed in later submissions.

In the case of the BPD metamodel we will provide an example mapping from the BPMN notation to the subset of UML we haveidentified. This would provide tool vendors the opportunity to support users requiring a BPMN graphical notation using the standardizedsemantic metamodel we present here.

Overa l l design r a t i ona le


12/215


This submission does not require any changes to the UML 2.0 metamodel though it may make recommendations for improvements to

future versions of UML for better support of this standard. Where possible the submission does not introduce new elements to the UML

language, but identifies a subset of the UML that can be used to describe business process models. However, where concepts need to

be disambiguated a profile is provided to introduce a small set of stereotypes.

This metamodel does address automated business processes, through transformations to process automation languages such as

BPEL4WS. It is also the goal of this profile to model processes that are not intended for automation in this way processes that aresolely implemented through collaborating people.

St a t e m e n t o f p r o o f o f c on c ep t

Substantial parts of the metamodel presented here are based directly on the metamodel underlying products in development at IBM.WebSphere Business Integration (WBI) Modeler1 is a platform-independent business process modeling tool that also provides atransformation to a runtime language (MQSeries Workflow FDML).

IBM is in the process of updating this product line and at the same time integrating with the product lines from the Rational brand.

This update includes a new metamodel, moving from a proprietary base to one based directly upon UML2 and including the experiencefrom Rational in applying the UML to business modeling. This submission describes a subset of the metamodel for that product, someareas are altered to reflect the fact that only a subset has been taken and some associations are therefore not available.

In the area of translation to automated business process languages with the mapping from UML to BPEL4WS; IBM has made a version

of tools to implement this mapping available on the IBM alphaWorks web site 2. This technology can generate BPEL4WS from UML

models in either IBM Rational Rose or IBM Rational XDE. In the future this mapping will be used to define the transformation of modelsfrom the platform- independent WBI Modeler into BPEL4WS.

Chan ge H is tory

Revision Date Comments

2.0.0 August 2004 Revised Submission.?? Introduced Concepts and Overview section based

on an updated version of the whitepaper?? Updated the mapping to BPMN

1.0.2 January 2004 Revised Submission.

1http://www.ibm.com/software/integration/wbimodeler/

2http://www.alphaworks.ibm.com/tech/ettk


13/215


?? Included new co-submitters including BPMI.org.

?? Reorganized to better follow the standard

submission structure.

?? Updated references and included the BR SIG

business modeling white paper.

?? Introduced the stereotype Document to the

profile, describing its relation to Entity.

0.9.1 December 2003 Working Group draft for Revised Submission.

Added Unisys as supporter, correctly placed BEA as

supporter rather than submitter.Added introductory section on principles.

Renamed the modeling view Policyto be Governance in line with the expanded definition

in the IBM Business Rules Submission.Process and Entity now use the meta class Class

(StructuredClass) instead of Component.Updated the diagrams in the examples.Added initial section on organization.

Included Appendix on mapping from EDOC to BPD.Included updated BPMN mapping.

0.9 August 2003 Initial Submission


14/215


Response to RFP Requ i r em ent s

M a n d a t o r y Re q u i r e m e n t s

Mandatory Requirement Resolution

6 . 5 . 1 R equ i r ed M e t am ode l

Responses to this RFP shall provide a

metamodel forming an abstract

language for t he expression of business

process definitions.

Proposals shall depict the solicited

metamodel using UML.

This proposal reuses a subset of the UML 2.0

metamodel and extends UML 2.0 with aBusiness Process Definition package.

UML 1.5 and UML 2.0 profiles of themetamodel are also provided to enable tometamodel to be used with current and future

vanilla UML tools.

6 . 5 . 2 M et am ode l Com pa t i b i l i t y

Proposals shall use the appropriate

elements of existing metamodelsincluding, UML, EDOC, MOF and OCL.

We observe that much of the modeling

capability introduced in EDOC is now directly

supported in UML 2.0. This proposal thereforebuilds directly on UML 2.0.

OCL can be used with this proposal wherever a

side-effect free expression language is

required.

We observe that there is an overlap between

the concepts required to fully specifyexecutable business processes and the

concepts required for service-oriented

architecture. We recommend that SOA is

covered in a separate RFP which is compatiblewith this one.

An appendix to this document describes therelationship between this specification and

EDOC.

6.5 .3 MOF Com pl ian ce The metamodel introduced by this proposal is


15/215



The resulting metamodel shall be MOF-

compliant.

MOF-compliant as it is currently a subset and

profile of UML2 and not a separate metamodel.

6 . 5 . 4 Pr oc edu r a l and r u le - bas ed

f l o w o f c o n t r o l

Proposals shall provide for specificationof process flow based on control flowfrom completed activities to activities

to be initiated as well as initiation of

activities based on rules or pre-conditions.

Comment: We assume this meansActivityNode in the UML 2.0 sense

rather than Activity and is therefore

referring to control flow within a

process.

Comment: The term precondition

should not be used here as it refers tosomething that is not side-effect free.

This proposal supports procedural control flowby reusing the activity and action modeling

elements of UML 2.0.

This proposal will support the initiation ofcontrol based on an expression becoming true

through UML 2.0 AcceptEventActions with

ChangeTriggers and TimeTriggers. The latterprovides the ability to initiate control based onpolicies such as start this process at 11:00amon a Friday.

6 . 5 . 5 Speci f i c a t i on o f Ac t i v i t y

Per fo rmers

Proposals shall provide for thespecification of selection criteria for

performers and resources, includinghuman performers, applications,passive resources and sub-processes.,

The basis for selection shall include

a) Specific resource identity

b) Resource attr ibutes

c) Relationships wit h other

assigned resources

d) Relationships to subj ect mat ter

Tasks may have associated resourcerequirements which are expressed in OCL.

Yes. Resource typesare classifiers that haveinstances with identity. Instance specifications

pinpointing a particular resource may beassociated with a task.

Yes. Resources can have attributes.

Yes. The deployed resources of a process willbe accessible to resource queries.

Example will be included

Yes. Resource requirements can refer toprocess variables, task input objects andconstants.


16/215



e) Combinations of the above. Example will be included

Yes.

6 . 5 . 6 As y nc h r onous and C onc u r r en t

Execut ion

Proposals shall provide mechanisms forspecifying concurrent execution of

activities:

a) A process model shall be able todefine when multiple,

concurrent activit ies are

init iated.

b) A process model shall be able to

define when an activity or

completion of a process depend

on the completion of multiple,

concurrent activit ies. This shall

include init iation of an activity

based on completion of n of m

concurrent activit ies (where n

< = m ).

c) Business processes shall be able

to inv oke processes that

execute asynchronously.

d) The model shall support

specification of t he publication

of events and m essages for

asynchronous delivery.

e) The model shall support receiptof messages from a collaborator

and subscription to events.

Messages and events shall be

received as asynchronous inputs

Yes. The control flow semantics of UML 2.0activities are adopted by the profile.

UML 2.0 join specs provide the abilities to

specify complex joins within a processinstance.

This is the normal case with the implicitcreation semantics adopted by this proposal.

The case where a business process isinstantiated with a synchronous call andcompletes on return is simply a special case.

Synchronous and asynchronous sending ofmessages is supported as in UML 2.0. Point-to-

point and broadcast semantics are supported.

Asynchronous receipt of messages/events is

supported as in UML 2.0.


17/215



to a receiving activity executing

concurrently with other activit ies

in th e process.

6 . 5 . 7 Spec i f i c a t i on o f i n i t i a t i on and

t e r m i n a t i o n

Proposals shall provide modeling

constructs for specifying wh en and how

activit ies and pr ocesses can be in it iated

and terminated:a) Pre or post conditions

Comment: Preconditions andpostconditions in UML do not

alter runtime semantics.

Perhaps this is intended to allow

when conditions that emit atoken when an expressionbecomes true.

Actions for initialization and termination

with consideration of actions required

for abnormal termination, including theinitiation of compensating processes.

b) Propagation of term ination to

active activit ies and sub-

processes.

Initiation and termination of processes is

implicit rather than explicit from the point ofview of a client of the process. This decouplesthe service requester and service provider and

facilitates scenarios where the first of a number

of events will lead to a new instance with the

subsequent events being routed to the existinginstance. Routing event s to existing instances

requires correlation, w hich will be int roduced in

extension of UML 2.0.

Routing not currently described in this revision

a) Supported through UML 2.0AcceptEventActions withChangeTriggers.

b) Initialisation of processes and tasks is

implicit. Exception handling is supportedas defined in UML 2.0. UML 2.0 does notinclude compensation. This proposal

adopts the BPEL4WS semantics forcompensation within a process.

c) UML 2.0 ActivityFinalNodes andException semantics are supported. Thenotion of subprocesses requires a notion

of composition which is providedthrough UML 2.0 composite structures.

Note, we differentiate between embedded sub-processes (StructuredActivityNode) andinvoked/shareable sub-process which are

Activities.

6 . 5. 8 C ho r eog r aph y Supported. Choreography is expressed using

collaborations with roles. The types of the roles


18/215



Proposals shall provide for the

specification of the signals andexchanges performed betweenprocesses to achieve collaboration as

described in 6.2.5.

specify the interfaces provided and required by

the roles. Permissible choreographies arespecified using activity graphs.

Example to be included, specifically to

demonstrate the notion of global processes

6 . 5 . 9 Aud i t Log Gene r a t i on

Proposals shall include provisions in the

metamodel to allow the specification ofbusiness logic related audit log records.

This part of t he metam odel shall

provide for t he specification of:

a) The content of the log record in

relation to t he process definit ion

b) The timing of the log record

emission

Supported. Audit log message types must

include identification and time properties. An

audit action adds identification and timeinformation and sends such events to a logicalaudit service. Audit messages can containproperties that will be populated with

expressions that have access to process

variables.

A MOF identifier is included in the log to enablethe event to be interpreted in the context ofthe business process definition. Information to

identify the process instance is also added.

(Details TBD.)

The audit action automatically adds the currenttime to audit messages.

This is not currently described in this revision

6 . 5 . 10 D i s t r i bu t ed Ex ec u t i on

Proposals shall ensure that the form of

definition does not preclude distributedexecution.

Supported. No assumption is made thatpartners (including sub-components) are in thesame namespace or at the same physical

location. No support is provided for distributingan individual process instance sub-components should be introduced where this is

required.

6 . 5 . 11 P r oc es s D ef i n i t i on im po r t

and ex po r t

Proposals shall support XMI export andimport for exchange of process

Supported. XMI is the default import/exportformat.

At this time there are no metamodel extensio ns


19/215



definitions. and so standard XMI should be sufficient.

6 . 5 .12 N on - N o r m a t i v e N o t a t i on

M app ings

As a proof of concept, proposals shall

provide non-normative m appings to

two recognized business process

modeling languages, e.g.:

BPEL4WS

XPDL

(See section 6.4 for a nonexclusive list

of references to relevant specifications)

A mapping to BPEL4WS is provided.

Reverse mappings from one or more legacyworkflow languages will also be included.

Mappings to other execution languages can bedefined as required.

6 . 5 . 13 Com pa t i b l e Ve r s ions o f

Ex is t i ng Spec i f i ca t ion s

The final, revised submission shall be

based on the most recently adoptedversion of related specifications (e.g.,UML and MOF) that is adopted three

months prior to the final revised

submission deadline for this RFP.

Yes. The final, revised submission will be based

on the most recently adopted versions of

standards, as required.

A profile for UML 1.x will also be provided asthe marketplace will not move completely toUML 2.0 immediately.

Op t i o n a l Re q u i r e m en t s

Optional Requirement Resolution

6 . 6 . 1 Add i t i on a l Non - N o r m a t i v e

M app ings

Proposals may provide additional

mappings to recognized languages for

business process definition,complementing the list of mandatory

mappings requested in 6.5.12.

To be decided.


20/215


6 . 6 . 2 Add i t i ona l Ex ec u t i on

Cons t ra in t s

Proposals may provide for the ability to

model additional execution constraints,

like maximum duration of a process or

activity execution. For these additional

constraints the behavior of constraint

violation should be modeled and its

effect on the pr ocess enactment

described.

None identified at this stage.

I ssues to be d i scussed

Issue to be discussed Discussion

6 . 7 . 1 R ela t i ons h ip t o ex i s t i ng U M L

m e t a m o d e l

Proposals shall discuss the relationship

of m odel elements used for business

process modeling to the existing UML

metamodel to demonstrate consistency

with the UML metamodel.

This proposal reuses the modeling elements

introduced in UML 2.0. Where appropriate

concepts are not directly supported extensionsin keeping with UML 2.0 are introduced.

UML 2.0 Uses Cases may be used fordocumenting the external view and business

value of business processes.

UML 2.0 Activities and Actions are used for the

business process definitions andchoreographies.

UML 2.0 Collaborations and Roles are used to

specify interaction patterns between partners.

UML 2.0 Templates are used to permit the use

of templates in business process definitions.

UML 2.0 Composite Structures and Activities

are used to represent composite businessprocesses.

6.7 .2 Re la t ionsh ip t o Re la ted UML A mapping from EDOC to BPD is included as


21/215


Pr o f i l es , M e t am ode l s and N o t a t i ons

Proposals shall discuss how business

process definitions may be incorporatedwith or complement other UML profiles,metamodels and notations for

specification of business systems,particularly the UML Profile for EDOC.

an appendix.

6 . 7 . 3 M app ing t o Ex i s t i ng Bus ines s

Pr oc ess no t a t i ons and U M L

N o t a t i on

Proposals shall discuss how theproposed metamodel may be mapped

to existing process definition notations

as a demonstration of completenessand compatibility.

Currently the submission includes a mapping

from an existing business modelling notation(BPMN) to the metamodel defined.

UML 1.5 and UML 2.0 profiles corresponding tothe BPD metamodel are a part of this

submission. Instances of the profile can be

expressed using UML Notation with stereotypekeywords or icons. While a tailored notationmay be preferable, this option is available for

creating business process definitions using

generic UML 1.5 and UML 2.0 tools.

6.7 .4 Resource Mode l

Proposals shall describe assumptionsregarding an associated resourcemodel.

An associated resource model must provide thedomain for resource requirement specifications

(6.5.5). We will propose a resource model forthe definition of individual, bulk, resource

types, and roles, which represent a resource'scapability to perform tasks. Roles may bescoped, to account for the dependency of such

capabilities on subject matter.

This is not currently described in this revision

6 . 7 . 5 Re la t i ons h ips w i t h r e l a t ed

OMG spec i f i ca t ion ac t iv i t ies .

Proposals shall discuss how thespecifications relate to the specification

development efforts currently underway as noted in Section 6.4.3.

UML 2.0

Covered above.

Business Process Runtime Interfaces

MOF 2.0 Versioning

MOF 2.0 Queries/Views/Transformation

MOF 2.0 Q/V/T is under definition at the timeof writing. The final expression of mappings


22/215


from this profile to execution languages willuse the QVT formalism assuming that QVT is

sufficiently complete at that time.

CWM Provides a detailed metamodel fordescribing data and information, this should be

supported as an alternate way to describe BPDinformation models.

There is an existing Organizational StructureRFP that should supersede the organization

model presented in this submission.

The Business Rules RFPs should be able todescribe constraints on processes models.

6.7 .6 Cons is ten cy checks

Proposals shall discuss how the

specification supports consistency

checks, particularly between

choreography specifications and a

business process that part icipates in

the choreography.

The proposal defines the conditions under

which an executable process can be said torealize a role in a choreography.

6 . 7 . 7 Ac c es s Con t r o l

Proposals shall discuss how access

authorization for process data,

artifacts, activities in a process, andprocess enactment may be based on

process roles of individuals associatedwith a specific process instance.

Supported. Access control will be consistentwith Resource specification.

6 . 7 . 8 W eb s e r v i c es and

c o l l abo r a t i on s uppo r t

Proposals shall discuss how thespecification supports the definition of

business processes and choreography

for web services and other

collaborations including therelationships with messages,documents, interface specifications,

This proposal adopts an approach that isconsistent with a service-oriented architecture

and can therefore be mapped to web servicestechnologies.

This proposal will not provide a UML profile for

service-oriented architecture but will introduce

modeling elements as required.

If a standard SOA profile is available in a


23/215


participant roles, signatures andmessage exchanges.

suitable timeframe then this proposal willdepend on it.


24/215


Par t I I Subm ission Det a i l s

Scope o f th e sub m ission

This submission looks at the problem of business process definition in context. In the following sections we will describe the problem of

business process definition as a part of a broader activity business modeling. Business modeling is, as the diagram belowdemonstrates, comprised of a set of related disciplines. In many cases an organization is only focused on certain of these areas, for

example business strategy is an area of particular interest right now.

In terms of this submission the scope is restricted to the areas of Process, Automation and Resurces. However it is clear that noprocess model can be complete without addressing information and organization and this submission will present default models in this

area.

?? St ra tegy ; encompasses business goals, strategic objectives and can be used to measure business performance. Note, not inthe scope of this submission.

?? Governance ; includes the modeling of regulatory concerns, policies and rules.

?? I n f o r m a t i o n ; high-level modeling of information sources and includes modeling of business artifacts, such as documents,products, parts, assemblies, etc.

?? Organ iza t ion ; the ability to capture organizational structure. An organization's responsibility (for tasks) and ownership (ofresources) can only be specified in conjunction with other models (Resource, Process). The main purpose of an Organization

Model is to define organizational units (such as companies, project teams, departments, etc.) and their interrelationships. Withthis in place, Resources, Tasks, etc. can then be referenced, and the underlying semantics may defined as ownership of,responsibility for, etc.


25/215


26/215


?? Co r p o r a t e De v e lo p e r responsible for the development and deployment of business applications and business components.

These developers tend to be less skilled in the details of the software platform, and rightly so, their job is to deploy businessvalue through these applications, not know the latest JDK version.

?? D a t a/ I n f o r m a t i o n A r ch i t e ct responsible for the development of data models and a stakeholder in interchange models for

information integration.

The following table reflects the roles (Author, Secondary author, Reviewer) that these actors play in the development of the models

defined in the framework above. This table is organized such that those stakeholders requiring a more abstract/less detailed view areat the top and those requiring less abstraction and/or more detail are at the bottom. We have also highlighted the columnsrepresenting the models relevant to this submission.

Information

Organization

Resource

Process

Automation

Strategy

Governance

Simulation

Financial

Observation

Executives R R R R R

End User R R R

Business Analyst A A R A A A R A

Process Specialist S S A S A R A

Solution Architect R S R A R R

Corporate Developer

Operations Management

Data/Information Architect R

It is our intent to propose a set of views, their contents and a mapping to the MDA framework here. This will be provided in a later

revision.

Proposed Con fo r m ance Cr i t e r i a

At this time no conformance criteria have been identified.


27/215


Pr o p o s e d N o r m a t i v e Re f e r e n c es

Unified Modeling Language: Infrastructure version 2.0 (ptc/03-09-15), January 2003, OMG

Unified Modeling Language: Superstructure version 2.0 (ptc/03-08-02), April 2003, OMG

Business Process Modeling Notation Working Draft (0.9), BPMI.org

Business Process Modeling Notation Working Draft (1.0), August 25th 2003, BPMI.org

BPEL4WS 1.1 http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/

UML Profile for Enterprise Distributed Object Computing Specification (ptc/02-02-05), February 2002

Rational UML Profile for Business Modeling

Unified Modeling Language: OCL 2.0 (ptc/03-08-08), August 2003

Architecture of Business Modeling (br/03-11-01), OMG

Pr o p o s e d L is t o f T er m s a n d D e f i n i t i o n s

Au t om a t ed P r oc ess

A Process that is automated, at least in some part, by a software application or process runtime (such as the WebSphere ProcessChoreographer). An automated process by definition is an executable process.

Bus iness Document

A Business Document models exactly what you would expect a paper document. As such it has no identity (in the Object sense), no

behavior and no state.

Choreography

In implementing a value chain processes communicate between each other. These inter-process communications have to be governedwith a contract that defines the set of messages and the sequencing of messages. This contract is known as the choreography, or

global process.

Executab le Process

A Process that has executable semantics, though this need not be automated as it may be executed solely by people within anorganization.

Managed Process


28/215


The processes described as part of a choreography define, in effect, an interface (sometimes termed an abstract process) which has to

be implemented by some actual process, these implemented processes are the managed processes. A managed process by definition

is an executable process.

Par tner Process

The processes described as part of a choreography are often termed partner processes.

Resource

TBD

Role

TBD


29/215


The following diagram demonstrates the different process notions; the abstract processes Buyer and Seller are partners in a

choreography called Ordering. Two companies agree to implement the choreography and so two managed processes are required.

My Company uses a software automation package to automate the Buyer process whereas Your Company simply executes the Seller

process with an efficient sales force of trained staff.

Proposed L i s t o f Sym bo ls

Currently there are no symbols defined as part of this submission. The appendix mapping BPMN to BPD does however introduce analternate notation.

Bus iness Pro cess Def in i t i on Met am ode l

The adopted UML 2.0 superstructure metamodel provides much of what is required for the definition of business processes. The

following sections identify the subset of UML 2.0 appropriate for business process definition.

The model deals with descriptions of business processes at a level abstract from any implementation technology, even where thatimplementation technology may be humans executing a purely manual process. This does not imply that the model cannot and does

not describe executable processes, simply that it makes no assumptions about the form of the execution. It is certainly true that

current notations such as IDEF0 make no assumptions about the implementation of a process, and neither does the most commonly

Ordering

(Choreography)

Buyer

(Partner)

Seller

(Partner)

My Company Your Company

Buyer(Managed, Automated)

Seller(Managed, Executable)


30/215


used notation, boxes-and-lines. In our case we simply intend to specify a common subset of the standard UML 2.0 superstructure that

can be used to support this level of modeling.

It is worth noting that although the subset of the UML we have identified would provide the user a level of completeness that wouldallow them to specify and execute the complex business models there is no specific requirement that they do so. It is not usually thecase that models specified at this level of abstraction are complete, it is not a requirement that they be complete.

Concep ts and Overv iew

This section introduces BPDM concepts though an example. It also introduces notations that allow to view a process model at varyinglevels of detail, while maintaining consistency with the underlying model and semantics. A formal definition of the metamodel and its

relationship with UML 2.0 will be provided in a further revised submission.

I n t r o d u c t i o n

Business processes are "behavioral building blocks" of a business: They describe the activities a business performs in pursuing its

objectives. They can be broken down into subordinate processes and eventually tasks that are considered atomic. Business processesdo not exist in isolation. In implementing a value chain business processes interact with partners, and these interactions may cross

organizational boundaries.

We therefore model two aspects of a business process: its internal behavior, using a flow model, and its external interactions, using

collaborations and associated protocol specifications. The first view is that of the process execution environment, the second view is

required to connect processes with other components in a service-oriented architecture.

In introducing the modelling concepts, we will use the following example:

A producer of electronics assemblies implements a "Just-in-Time Manufacturing" process: Incoming customer orders areevaluated based on the available manufacturing capacity and the parts inventory: If suffic ient quantities for all parts are

on stock and assembly line time slots are available, an order confirmation is returned to the customer, the assembliesare produced, and finally delivered together with an invoice. If assembly line capacity is not available, the order is

declined. If manufacturing capacity is available but some parts are not, replenishment orders are first issued topreferred suppliers, including a deadline that leaves enough time for production. For parts that the preferred suppliercannot deliver within the allotted time frame, an auction is launched accepting bids from suppliers in the open market. If

all parts can be procured before the production start deadline, the order is confirmed and the assemblies are produced,delivered, and invoiced. Otherwise, the order is rejected.

The internal view(or behavioral view) of a process shows "how it is performed", at the level of detail that the modeler knows orchooses to reveal: it is modeled as a partially ordered set of tasks. Figure 1Figure 1 shows a simple, control-flow only, internal view of


31/215


the Just-in-Time Manufacturin gprocess.3 The meaning of symbols used in the diagram, and their implied semantics, 4 will be defined in

chapter 0 "Operational Processes (Modeling Process Behavior) ".

3 The notation employed in this paper is not normative, but was chosen to provide a clear illustration of the modelling concepts we

would like to support. In particular, it is not the standard notation of UML 2.0.

4 Please note that while our process definitions have well-defined semantics, and hence are executable in principle, this does not implythat they are automated. On the other hand, they may be refined to the level of detail required by an execution engine, for complete

or partial automation.


32/215


Just-In-Time-Manufacturing

check

Readiness

determine ifmanufacturing

capacity andall parts are

available

createConfirmation

manufacturing

capacity available,some parts must

be procured

insufficientmanufacturing

capacity

not all partsprocured

A

all parts

procured

manufacturing


available

A

confirmOrder>Confirmation

to customer

produce

Assemblies

createInvoice

to parts

to invoice

create

Rejection

partsProcurement

+

takeOrder

receiveOrder

fromc

ustomer

declineOrder

sendRejection

tocustomer

andterminate

returnShipment

sendShipment

tocustomer

andterminate

Figure 1: Just-in-Time Manufacturing Process (internal / behavioral view)

The externalview (or collaborative view) of a process shows "how it interacts". It specifies the partner roles that a process expects tocollaborate with, and their interaction protocol. A high-level collaborative view of the Just- in-Time Manufacturingprocess is shown inFigure 2Figure 2. The detailed interaction sequences associated with the collaborations (Order Fulfillment, Parts Provisioning and Open

Auction) are not shown in this overview diagram, but will be introduced in chapter 0 "Process Components".


33/215


Just-in-Time-Manufacturing

: Order

: Shipment

: Rejection

(Customer)

Order Fulfillment

: Confirmation(Supplier)

Parts Provisioning

(Bidder)Open Auction

Figure 2: Just-in-Time Manufacturing process (external / collaborative view)

Process Components

To enable business processes to collaborate with partners it is important for them to be defined in a composable fashion. To this end,we apply the paradigm of service-oriented architecture to business process modeling: We treat a business process as a definition of abehavioral component5 that connects to and interacts with other components (its partners). The internal behavior of a process then

includes tasks that conduct the corresponding partner communications.

A complete solution is modeled as a network of interconnected components interacting via long-running conversations. 6 The same

process can appear in multiple solutions and can be connected to different partners in each case, as long as the "partner roles" theyprovide match those required by the process. The partner interaction protocol is described using the concept of "collaborations".Partner roles and collaborations are introduced in the following sections.

5 The term component is used in this paper to denote the view of a process as a encapsulated behavioral element that can be

connected with other such elements. Connections represent communication channels amongst these. Please note that this is notexactly the "Component" class of UML 2.0.

6 Strictly speaking, instantiations of these components interact via long-running conversations; see section 0 "Process Life-Cycle and

Inter-Process Communication" for a more in-depth description.


34/215


The Just- in-Time Manufacturingprocess engages in three collaborations with partners: order fulfillment (with customers), parts

provisioning (with suppliers), and open auction (with bidders). This is shown in Figure 2Figure 2. In the following sections we

demonstrate how to model the external view of the process, including its partner dependencies and collaboration protocols.

I NTERFACES

The component view of a process states its dependencies on its partners through "interfaces", which define the points of interactionbetween the process and components external to the process. The partners be realized inside or outside thesame organization. In our

Just- in-Time Manufacturingexample, the manufacturing process collaborates with three partner roles: the customer who sends anorder and must receive a response, a set of preferred suppliers who may provide parts, and potentially bidders participating in an open

market auction.7

A graphical view of this is shown in Figure 2Figure 2 where interfaces are show an open boxes containing a list of input messages

(those accepted by the process) and output messages (those sent by the process). Interfaces must be connected to matchinginterfaces on partner components in order to obtain a complete solution.

COLLABORATI ONS

[Remainder of this section omitted in this version. Update required.]

Opera t i ona l Processes ( Mode l in g Process Behavio r )

In this chapter, we describe the fundamentals of modeling process behavior. Just as the preceding chapter on the component view of

processes, this makes intensive use of concepts found in UML 2.0

TASKS AND BLOCKS

The behavioral view of a business process describes the sequencing, input, output, and resource requirements of business tasks.

7 Note that in Figure 1Figure 1 process steps communicating with the customer are shown, while communication with other partnerswhich would become apparent as one refines the procure part from preferred supplierand run auct iontaskshas not been modelled

explicitly.


35/215


Tasks are the basic units of work in a business process. Tasks may be executed by humans or automated, and some may involve

partner communication.

Tasks can be structured into Blocks (revealing subordinate steps to some level of detail). An example of a block is the procure partstask in Figure 1Figure 1. An unblock is atomic from the modeler's point of view, who at some point decides to not further refine its

description.8

TASK I NPUT PI NS AND OUTPUT PI NS

Business tasks may have several input pins(representing alternative ways to provide input and spawn a new execution) and several

output pins(representing alternative outcomes). In Figure 1Figure 1, input pins and output pins are omitted and can be inferred fromincoming and outgoing flows (arrows).

Each task execution consumes an input object from exactly one input pin and produces an output object on exactly one output pin

For example, the check if manufacturing capacity and part s availabletask, which represents a three-way decision, has three possibleoutput pins, whose conditions are indicated in parentheses.

A task can be triggered via any one of its input pins, and upon termination provides output through any one of its output pins.

TASK I NPUT AND OUTPUT

Input pins are typed to indicate the objects that they can accept, output pins are typed to indicate the objects that they produce.Object types can be composite. We will now refine the Just- in-Time Manufacturin gprocess shown in Figure 1Figure 1 by defining each

task's input pins and output pins and specifying the of input and output items. The resulting picture is shown in Figure 3Figure 3.

The chevron arrows on the task boundaries denote input pins and output pins. (Input pins point towards the centre of the task, output

pins point away from the centre.)

Adding object flow detail to the Just -in-Time Manufacturin gprocess will result in the picture presented in Figure 3Figure 3. Some of the

features shown have not been discussed so far:

o The triangles labeled "A" are continuation symbols, providing a convenient way to show where flow continues and

avoid diagram clutter. They are a notational convenience and don't introduce any additional semantics.

8 Few tasks, if any, are really atomic. For automated tasks, machine instructions could be considered the atomic level, but even thosemay be realized as "micro programs". For human tasks, one could consider an action like "sign contract" atomic, but upon closerinspection this involves finding a pen, opening it, pointing it to the paper, moving it, ... Atomicity of a task always depends on the

modeller's view point


36/215


o The cylinders represent repositories for tasks to deposit input / output items. Please refer to section 0 "Repositories"

for additional detail.

o Outcomes marked by small, upright triangles (for example, the "some part unavailable" output set of procure parts)denote exceptions or faults. When one of these is reached, compensation may be triggered for the task that endedabnormally. See section 0 "Exceptions and Compensation" for additional detail.

o Task inputs and outputs always have multiplicity 1 so no multiplicity needs to be specified. Types of the form Object[n] can be used to indicate the passing of collections. Repositories must be used to mediate between pins that take

individual objects and pins that take multiple objects.9

o Flows between pins may map individual parts of the output type to individual parts of the input type. For example,the flow from produce assembliesto the Shipment message has the annotation from items to parts indicating that

the items part of the Assemblies type should be placed in the parts part of the Shipment type.

o The "available" outcomes of the procure part from preferred supplierand run auctiontasks are not wired to any

follow-on tasks, because there is no immediate follow-on activity after a part was successfully procured (see section0 "Block Termination" for further discussion).

9 This approach is based on customer feedback and the complexities of combining pin multiplicity with complex control flow andcomposite inputs and outputs.


37/215


Just-in-Time-Manufacturing

checkavailability

--

determine ifmanufacturing


available

order: Order

order:Order

needParts: Requisition [1..n]

createConfirmation

noWay -- insufficient

manufacturing capacity create

Rejection

ord:Order

rej:Rejection

notAllProcured

AallProcured

order: Order

readyToGo

A

order:Order

confirmOrder

to customer

c:Confirmation

c:Confirmation

produce

Assemblies

create

Invoice

order: Order

ord:

Order

in:

Order

inv:

Invoice

out:

Assemblies

from items

to parts

to invoice

Shipment

parts: Assembly [n]

invoice: Invoice

Assemblies

items: Assembly [n]

parts

procurement

+

order: Order

Orderfrom

Customer

Rejection

toCustomer

isterminating

Shipment

toCustomer

isterminating

{remove}

{copy}

order-

Confirmed

{copy}

{copy}

Confirmation

to customer

getRequisitions:

Requisition[1..n]

Figure 3: Just-in-Time Manufacturing process, after adding task input / output detail

TASK LI FECYCLE

An execution of a task is started when one of its input sets (entry points) receives the input (tokens) it needs.

When execution ends, a task provides output at one of its output sets, which represent the task's alternative exit points or outcomes.Unblocks end "whenever they are done" and the events or time by which this happens are not modeled. Modeling the termination of a

block is described in section 0 "Block Termination".

The procure part from preferred suppliertask in Figure 3Figure 3 has no multiplicity specified for its input and thus will accept part

requisitions only one at a time. If more than one part is out of stock, multiple concurrent executions of this task will be started. (The


38/215


procure partstask represents all procurement activity on behalf of a manufacturing process; it can take any number of part

requisitions and is instantiated only once.)

Note that there is a hierarchy of task executions: Several procurement tasks from preferred suppliers and several auctions may be inprogress within a single procure partsblock. When the latter terminates, all nested procurement tasks and auctions still in progresswill be terminated as well.

BLOCK TERMINATI ON

A block completes when one of its output pins has a complete object, recall that an output pin may have a composite type and the

parts may be provided via multiple flows. Note that an incoming control flow can always be used to prevent early termination.A block may also have a single output pin that does not have any incoming flows (from inside the block). This is the default output pin

and is triggered when all activity has completed inside the block (there are no remaining tokens to trigger further behavior).

In Figure 3Figure 3 the default outcome of the procure partsblock ("all parts available") thus occurs when all executions of the nestedprocurement tasks have ended and no token has reached the output marked "some part unavailable". If the latter happensindicating

that an auction has failed to obtain a part that was unavailable from the preferred supplierthe procure partsblock and allsubordinate procurement activities will be terminated. This outcome is also marked as a fault, which causes it to trigger compensation

for nested procurement tasks that have successfully completed. (See chapter 0 "Exceptions and Compensation".)

Note that the output from the "available" outcomes ofprocure part from preferred supplierand run auct ion is not required. The defaultoutcome ofprocure partswill fire and signal that all parts could be procured, when all procurement activity inside it has ended; there

is no need to "collect and count" tokens reporting individual purchases.

FLOW CONTROL

The semantics of input pins and output pins can be used to model AND and OR conditions for inbound and outbound flow.

Consequently, explicit flow control constructs, such as decision, merge, fork, join, can usually be avoided. In Figure 1Figure 1 and

Figure 3Figure 3, for example, the check if m anufacturing capacity and parts availabletask represents a decision, characterized by its

three alternative outcomes; the create order confirmationand send rejection to customer tasks merge their inbound control flows (twoentry points and two corresponding input sets are modeled), while the send shipment to customer task joins its two inbound flows(only one entry point / input set has been specified); note that the matching fork is provided by the output set of send confirmation to

customer.


39/215


If needed, however, the "classic" decision, merge, fork, and join elements can be modeled explicitly using special-purpose tasks. 10 A

summary of patterns for modeling flow control is presented in Figure 4Figure 4. The first row shows the standard control elements

using the notation of UML 2. The second row shows them using task with input pins and output pins to achieve the same result. 11

... ? ... ... ...

?

Decision Merge Fork Join

Figure 4: Summary of task notation for common flow controls

Note that these approaches can be combined to build tasks with complex input and output flows.

LOOPS

Loops in business processes are usually required to iterate over a set of objects. This is usually modeled by sending individual tokensrepresenting these objects to the task processing them. (As explained in section 0 "Task Lifecycle", multiple executions of a task may

10 This approach is also supported by the observation that decisions in real-world processes require time and effort; the same is true

for "forks" (for example, someone makes copies and distributes them); similarly, a join may be realized by a person tracking thecompletion of several concurrent tasks and triggering subsequent steps only when all are done [...] In all cases, these "control steps"

take time and resourcesand thus can be considered tasks.

11 Control and object flow can be routed in the same manner. For control flow the incoming and outgoing flows would be dashed.


40/215


run concurrently, unless they compete for a shared resource that enforces serialization.) Loops can also be constructed explicitly by

"routing back" control or object flow after a decision.12 Note that it needs to be mergedinto the flow where it rejoins (e.g., enter a task

that is being re-executed via a different entry point) in order to avoid a dead-lock situation.

REPOSI TORI ES

In Figure 3Figure 3, a repository for orders is shown at different places in the diagram (note that the cylinder symbols represent"proxies" or "access points" to a single repository). Orders are stored by the receive order from customer task, and retrieved at later

stages in the flow. The {copy} annotation indicates that the order's content is read, but it remains in the repository for access byfurther tasks (a copy is made and passed out). The {remove} annotation indicates the order's removal from the repository. Task

inputs connected to a repository access it ("pull tokens") when all other inputs in the same input set have received the tokens they

require. The create order confirmationtask in Figure 3Figure 3, for example, will read the order content from the repository wheneither of its two input sets receives a control token (the object input is shared). 13

Repositories are defined for objects of a given type and have a given capacity, which may be unlimited (the default capacity is 1).Tasks deposit tokens by routing them from an output to the repository, and retrieve them by connecting the repository to one of their

inputs.

Deposit operations can either replace the previous content of the repository or add to it. Retrieve operations can either copy or remove

the repository's content. The type of task inputs or outputs connected to a repository must match the type of objects stored in it, andtheir multiplicity range determines how many tokens are stored or retrieved at a time (task inputs retrieve at least their minimummultiplicity, and then take as many tokens as available, up to their maximum multiplicity).

Repositories whose capacity is larger than 1 always keep their tokens in an ordered collection; tokens can be added and removed at its

beginning or its end, which allows to model stack or queue behavior. More selective retrieval algorithms (queries) can be modeled by

adding a boolean constraint to the retrieving input set; it may involve the content of other task input that is present when tokenretrieval is triggered.

12 Note that we do not restrict task interconnection in a process in any way, permitting arbitrary flow graphs. Tokens will move along

the object and control flows that the model defines, tasks will be instantiated whenever one of their input sets has received its required

set of tokens. It is the modeller's responsibility to ensure that this results in the intended behavior.

13 Replicating the object input in two (disjoint) input sets instead of sharing it would have had the same effect, but would have resultedin additional diagram clutter as well as the need to merge the object flows emerging from these two inputs if one ever wanted to

model the internal behavior of the create order confirmationtask.


41/215


Repositories shown within a process (like the one for orders in Figure 3Figure 3) represent temporary storage whose life time is a

single process execution. They are also called process variables. Repositories can also be defined outside of any process context and

then represent permanent datastores, which different process executions can use to share and asynchronously exchange items.

Clearly, if several concurrent tasks try to remove tokens from a repository they may enter in competition and race conditions mayresult.

PROCESS LI FE- CYCLE AN D I NTER- PROCESS COMMUNICATI ON

An execution of a process is started when a "receive" task that has no incoming flow is targeted by inbound communication, and the

incoming request is not correlated with an existing process execution. A shorthand for a receive that can occur at the start of a processis to have object flow from a message (on the boundary of the process) to the next task(s). This approach is used in the Just-in-Time-

Manufacturing example for the initial receive of an Order object through the Customer Interface.

Correlation is discussed in section 0 "Addressing Process Executions (Correlation)".

A process execution is terminated either explicitly on reaching an End node (bullseye) or sending a terminating message (a send via a

message marked as terminating), or implicitly after all token flow and executions of nested tasks have ended. Note that this isanalogous to the termination of a block, explained in section 0 "Block Termination" above. Just like initial receive tasks, terminating

tasks must not be nested within blocks.

The receive order from customertask in Figure 1Figure 1 and Figure 3Figure 3 is an example of an initial receive task. The Just- in-

Time Manufacturingprocess does not contain a terminating task, but ends implicitly after execution of all subordinate tasks has

finished.

The next section describes how requests are routed to a process component, which acts like a "factory" and request broker for its

executions.

PARTNER SELECTION ( ROUTI NG)

[Omitted in this version. Requires updating.]

ADDRESSI NG PROCESS EXECUTI ONS ( CORRELATI ON)

Implicit correlation is the direction of a "response" to a receive task within the process execution that sent the original request. Explicitcorrelation is the routing of an unsolicited request to one or more ongoing executions of a process.

We discuss implicit correlation first. With the component interaction model introduced in chapter 0 "Process Components", whereprocesses exchange unidirectional signals whose sequencing is governed by a collaborative process (protocol), request-response


42/215


correlation must be generalized: The first exchange between two process executions that establishes a collaboration (it must be an

initial request according to the collaboration's protocol) implicitly "binds" two executions threads to the collaboration instance. They

may be represented by executions of the process proper or nested sub-processes. Further execution threads, of potentially other

partners, may join as the collaboration proceeds. All messages issued by these executions in accordance with the collaborationprotocol will be routed to the "partner" executions bound in this way, until the collaborative process has ended. 14 15 Clearly, aninstance of an operational process may participate in several collaborations at the same time.16

To explain explicit correlation, we revisit the Just- in-Time Manufacturingprocess. Note that multiple open auctions may be running

concurrently on behalf of a single manufacturing process. They represent ongoing negotiations for different parts, which bidders must

be able to address individually.

Therefore, the actual auction should be modeled as an independent process that is controlledby the manufacturing process on whose

behalf it was launched. This is shown in Figure 5Figure 5, where we assume that the manufacturing process plays the requester role (arefinement ofrun auctionwould show the pertinent communication tasks).

In the Procurement Auction operational process, in the lower half of Figure 5Figure 5, only the communication tasks are shown. Thethree receiver tasks have the following correlation predicates:

?? The receive part requisit ion from requestertask has no correlation predicate and is the receiver of the initial requestin the Auction Control collaboration protocol. Input received here will spawn a new Pocurement Auction execution.

14 Design issue: In order to enable protocol tracking, a send task needs to specify more information than the partner and type of signal

exchanged ("send X to Y") because the same signal may be permitted in different branches of a collaborative process, and without

additional information it will be impossible to tell which branch was takenwhich undermines protocol tracking.

15 We may be able to avoid "reply tokens" by agreeing that all communication task instances that are spawned by these executionthreads and map to an abstract process of an ongoing collaboration (that is, all potential past and future senders / receivers

participating in the conversation) remain bound to the message exchange prescribed the collaboration protocol, and blocked for any

other communication, until the collaboration instance is finished.

16 Work is needed to precisely define the mapping of "execution threads" in interacting operational processes to a collaboration

instance; ultimately, we must ensure that the question "which instanceof a receive task will get a particular instanceof an inboundsignal" can always be answered. One can easily conceive process models where this is all but clear (e.g. by spawning several receive

tasks after sending).


43/215


?? The receive bid from biddertask has a correlation predicate that matches the part number of an incoming bid with

the one of the requisition that initially spawned the auction. Incoming bids will thus be routed to the auction for that

part.

?? The receive termination signal from requester task matches an order number supplied as part of the terminationsignal with the order number of the requisition. The termination signal thus targets all auctions that are in progress

procuring parts for a particular order.

ProcurementAuction

receivepart requisitionfrom requester

receive

termination signalfrom requester

sendresult

to requester

receivebid

from bidder

PartRequisition

TerminationSignal

Result

Procurement Auction

(Bidder) Bidding

requisition

.....

(no correlation)

bid.partNo =requisition.partNumber

terminationSignal.orderNumber =requisition.orderNumber

:Bid

: Part Requisition

:Termination Signal

:Result

(Requester) Auction Control

Figure 5: Correlation example

In general, a correlation predicate may be associated with individual receive tasks (compare Figure 5Figure 5). Whenever such a task

becomes the target of an inbound request, the predicate is evaluated for all of its existing instantiations. If it evaluates to true for


44/215


exactly one of them, then this task instance will get the inbound request. Otherwise, the user-defined settings for "no correlation

matches" and "multiple correlation matches" determine what happens, as specified in the following table:

At t r ibu t e Set t ing Ef fec t

create new

instance

a new process execution is

started and receives therequest (not for receivetasks defined within a

nested sub-process)

raise

exception

a "no correlation matches"

exception is raised

no c o r r e la t i on m a t c hes

(applies if there is no execution for which the correlation predicate evaluates totrue)

ignore the request is ignored

deliver to all the request is delivered to

all process executions forwhich the correlation

predicate is true

deliver to

any

the request is delivered to

one (arbitrarily chosen)process execution forwhich the correlation

predicate is true

raiseexception

a "multiple correlationmatches" exception israised

m u l t i p l e c o r r e l a t i o n m a t c h es

(applies if there is more than one execution for which the correlation predicate

evaluates to true)

ignore the request is ignored

In the example in Figure 5Figure 5, the no correlation matches setting is "ignore" for the task receiving the termination signals, and"raise exception" for the task receiving the bids. The reason is that termination signals can safely be ignored if no auction is found to

be terminated, while invalid bids should cause an exception notification back to the bidder. The multiple correlation matches settingsfor the two tasks are "deliver to all" and "raise exception", respectively.

EXCEPTI ONS AND COMPENSATION

EXCEPTI ONS


45/215


A task can have one or more exception output sets. Completion via an exception output set indicates an undesired or "fault" outcome:

the task did not complete normally and has not successfully performed its work. The "some part unavailable" outcome of the procure

parts task in Figure 3Figure 3 is an example.

Declaring an output set an exception can be purely informational. When used in conjuncation with compensation, however, additionalsemantics apply, as discussed in the following section.

COMPENSATI ON

[Omitted from this version. Required updating.]

Model l ing Resources RESOURCES

The most straightforward description of a business task is a sentence: Jill approves the order. John delivers the package. etc. Thesesentences have subjects (Jill, John), verbs (approves, delivers), and objects (the order, the package). In business process definitions,we use tasks to describe the "verbs", items to describe the "objects", and resources to describe the "subjects" or actors. In addition,

actors sometimes need collaborators or tools to accomplish a task, which are also modelled as resources.

We differentiate between individual resources, which are discernible and have an identity, and bulk resources, which are provided andused in some quantity. A human worker or employee is a special kind of individual resource, other kinds would be a truck, asledgehammer, a slide projector, a conference room, or a computer system. Examples for bulk resources would be fuel, floor space,

budget, cement, or memory.

Resources, both individual and bulk, are typed (have user-definable attributes) but have three fundamental properties in common:

?? qualificationsthe set of roles they can fulfill

?? availabilitythe set of time slots during which they can be deployed

?? costthe cost of using them, which may depend on usage time and quantity (for bulk resources)

In business process models we allow modelling resource types (e.g., Employee) as well as instances (e.g., John Doe).

ROLES

A role describes a functional capability, which tasks require and resources provide. A rescue task, for example, may require someonein the role of a pilot, something in the role of an "aircraft", and someone in the role of a physician; different people or items may be

qualified to fulfill these roles.


46/215


Oftentimes roles are further qualified by properties of the task at hand: a pilot may have to be licensed for a specific type of airplane,

an expense approver role be further qualified by the amount to be approved and the type of expense request. We use the notion of

"role scope" to describe such instance-dependent restrictions or "down-scoping" of a fundamental qualification which a role represents.

Tasks requiring a role may define a required scope (pilot to fly a B-59 airplane; approver for a $21,000 group travel request, etc.), andresources declare the scope for roles they can play (airplanes they are trained to fly; expense requests they are authorized to approve,etc.).

Roles are different from resource types, although the two are often used interchangeably in everyday language: a "team leader" role

may be fulfilled by a corporate employee, a contractor, or a summer student. Each of these resources may be qualified for the role,

but they have different resource types (some have employee serial numbers, other don't ...)

RESOURCE REQUI REMENTS

Tasks have three ways to specify their resource requirements:

?? require a specific resourceexamples: Dr. William H Smith; the manager of the request submitter

?? require a resource of a specific type, potentially subject to constraints

examples: an employee of dept D27X; a conference room that can seat 20

?? require a role to be fulfilled, potentially specify scope valuesexamples: a pilot for a B-59 airplane; an approver for a $21k travel expense

Furthermore, resource requirement specifications sometimes need to refer to resources used in a preceding task ("... the same userthat performed this preceding step"). This is accomplished by modelling special-purpose task outputs, which emit object tokens

representing the resources employed after task execution has finished. Subsequent tasks may use the information carried by thesetokens to formulate their resource requirements in terms of the resources used by their predecessors.

FM Cred i t Exam ple

Quick Reference


47/215



48/215


Concep tu a l Me tam ode l Overv iew

This section will be updated after discussions at the August 2004 (Montreal) OMG meeting.

This submission has identified a core set of concepts shared among a number of tools and methodologies PIM level and that represent

what we believe to be an agreeable set of terms among the identified audience. We have taken this set of concepts and mapped themto UML 2.0 and developed a profile for UML 2.0 that can be used to model business process definitions well. This profile does identify arequired subset of the UML 2.0 metamodel, but does not explicitly remove anything from the metamodel, thus leaving the full

expressiveness of the UML open to users, tool developers and methodologists. We have also not added new metamodel level elements

and so the end user does not have to learn a new UML and tool vendors should be able to implement the profile without major re-

engineering efforts.

The following is a conceptual model of the concerns addressed by this specification. It acts as an overview and a framework which the

detailed specification completes.

Worker Organization

PartyProcess0..*+subProcesses0..*

Role0..*0..*

+performedBy

0..*0..*Task

0..*0..* 0..10..*

+performedBy

0..10..*

Entity

+producesOrConsumes

Event

+generatesOrReceives

0..1+identifies

0..1Constrainable Rule

0..* 0..*0..* 0..*

CompensationTransaction

0..1+compensatingTask

0..1

Automated

The concepts themselves are relatively simple; we start with a process itself, it is a container for state and behavior and has anexternally visible interface, a set of operations and receptions that it responds to. Once these behaviors are invoked the process may

contain sub-processes (for partitioning model behavior and reusing process classes) and tasks. Tasks may invoke behavior on othertasks and sub-processes in the processes or invoke behavior or send events that are received by processes outside the scope of their

own parent process. Tasks may also identify themselves as having transactional semantics, i.e. an atomic completion of all enclosed

behavior; to support this we also provide compensation activities that can explicitly model the behavior required to undo a completedtransaction in the event of failure in some other part of the process.

In our view the notion of a role is a functional need of a task to be fulfilled by a resource. An organization can be responsible for the

completion of a task by providing a resource owned by the organization to fulfilling the resource need of the task. Obviously tasks are

carried out by people or automated systems. Frequently, these are grouped within organizational structures, such as companies,


49/215


departments, or project teams. To model this we have a Resource model capturing the human and non-human resources in a

business, their qualifications (expressed as the roles they can fulfill), their availability (for example, working hours), and cost

structure. An Organization model serves to group resources, reflecting their employment or ownership. Resource requirements of

process activities are often modeled as roles for which an activity requires resources in order to execute. Alternatively, resourcerequirements may be modeled directly (requesting a specific resource instance) or by specifying a resource type (any instance of thistype will do). Partitions may be used to declare resource requirements, or organizations providing the necessary resources (human

and/or non-). Therefore, when a partition represents a role, this means that this role must be played by some resource in order for

each task in the partition to execute; when it represents a resource (instance), or a resource type, this means that a specific resource,

or any resource of the given type is required; when it represents an organization, this means that this organization is responsible forthe tasks within the partition.

Note, we expect responses to recent RFPs for a complete organization model to supersede this subset of our model.

The UML also provides for the modeling of data flows within processes by using ObjectFlows within and between the activities, we

simply require that these object flows are movements of business entities or business objects, rather than arbitrary data. The UML alsoallows us to model the sending and receiving of events, thus allowing us to decouple processes from each other and also to respond tointernal events in an easy to understand manner.

Finally, many business systems employ business rules technologies to allow them to deploy systems that can be responsive byparameterizing business logic so that changes in environment or policy do not require application or process rewrites but can be

accomplished through the changing of rules. We provide a description of the places where such rules can be expected, existing RFPsare addressing the need to model business rule

Documents

BPDM Response Revised Submission 04-08-03