1
2
3
4
5
6
A Novel Approach for Modeling Business Process
Definitions
Jean-Jacques Dubray
Eigner
200 Fifth Ave
Waltham, MA 02451
Abstract
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
In this paper we introduce a new approach to specify the metamodel of a business
process definition. The concept of message exchanges between two roles
assembled as Business Transaction represents the foundation of our process
definition metamodel. This type of model enables the definition of decentralized
processes which involve business-to-business collaborations, user interactions as
well as application-to-application integration, in a technology neutral way.
Introduction
The “process-oriented” logic of an application has received increased attention in the past
3 years. It was first identified by the initial members of the BPMI consortium1 that this
kind of business logic is locked within applications, most often as hard-to-maintain code,
just like data was locked in the 70s before the development of relational databases.
RDBMS introduced a clear separation of the data and the data management system from
the “model-oriented” business logic of the application. In the past this concept was not
possible because of network bandwidth and the variety of proprietary platforms, data
sources and applications that needed to be integrated. Tremendous progress have been
made in the last few years and it is expected now that business applications will achieve a
new level of development productivity and customization once we can successfully
create a metamodel of the process-oriented logic and develop “business process
management systems” which can execute it.
However, if we want to successfully extract the “process-oriented” logic from the
applications, we must first agree on what needs to be modeled, automated and executed.
Alonso et al2 provide an excellent classification of business processes as administrative,
ad hoc, collaborative and production processes. In this paper, we distinguish at least four
levels of business processes which need all to be supported by such metamodel. These
levels can participate in any of the process categories identified by Alonso. The first level
corresponds to “enterprise processes” which provide a global view of the activities
performed by a value chain to achieve a particular goal. These processes do not show any
boundary and typically span multiple businesses (for instance “make a plane”). Their
automation often requires several business process management systems which cooperate
to achieve a particular goal. The second level corresponds to “executable processes”
which coordinate the actions of employees and the business transactions initiated by
1
2
http://www.bpmi.org
G. Alonso et al “Functionality and limitation of current workflow systems”, 1997
1
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
systems and business partners within the boundary of a single corporation or department
to achieve a particular business goal (for instance “process an order”). Executable
business processes may be executed by a single business process management system.
The state of executable processes is centrally accessible. In the case of enterprise
processes, the state is often distributed and is not physically or even logically centralized
because of corporation boundaries. The third level corresponds to “business process
collaborations” (or collaboration) models the interactions between executable processes.
The last level is called “task” and isolates the interactions between a user or a system and
the business process itself. This level is often related to “workflow” defined as a
succession of user “tasks” handling specific work items.
Several approaches3 have been suggested to define the metamodel of these different
levels. Historically most approaches are based on the concept of “activity” which
represents the lowest level of decomposition of the business process. For instance in
BPML 1.04 everything is an activity including the control flow. An activity represents a
unit of work performed by a user, system or partner. An activity may have some input
and output and some associated actions (pre and post activity). A business process is
merely considered a succession of activities following a specific control flow. When an
activity completes the control flow specifies which activity starts. This approach is
usually very close to the concept of UML activity diagrams (UML v1.x).
The second approach is to consider the states of a company and the actions which are
executed that cause the state to change. This approach is actually not fundamentally
different from the one based on activity. An activity is usually performed to go from one
state to another. These states actually should be called pseudo-states as they do not
represent physical states of the company but rather some partial state that is modified in
isolation within the boundaries of a business process. Typically a transition from a state
to another will be modeled as an Event-Condition-Action (ECA).
These approaches have shown their limits in their ability to model the message flow of
business process as well as providing a good interoperability model between different
BPMS2. For instance, in some cases one has to create a “dummy” activity just to model
the fact that you are waiting on a message. A state or activity based model leads to
business process definitions which are “centralized”. The process merely distributes the
work. In particular it is difficult to associate a direct communication between two
components to a process state change.
In this paper we introduce a simple model which is based on the flow of messages
between roles participating in the business process. The flow of messages between any
two roles is defined as a collaboration.
M. Peleg et al „Modeling biological processes using Workflow
and Petri Net models“, 2001,
http://smi-web.stanford.edu/people/peleg/ModelingBiologicalProcesses_paper_RBA.pdf
4
BPML 1.0 Specification, www.bpmi.org, June 2002
3
2
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
Message Flow, Control Flow and Data Flow
In our model, the fundamental entity of a business process is the “message” and not the
notion of “unit of work”. In other words, a business process at any of the four levels that
we identified can be expressed as an exchange of messages between two or more roles.
Every state change within a company can be associated with the processing of a message.
These messages obey particular a control flow (no control flow being a particular case of
a control flow), and may or may not carry data or binary documents -the data flow
associated with the message flow.
A message is defined between two roles, it has a direction (from role A to role B), it has a
name (usually composed of a verb and a noun) and it may optionally have a payload
made of a primary business document and related attachments. Exceptions may occur
during its realization: technical exceptions (the message could not be received, or the
sequence of the message is incorrect), business exceptions (the message was received but
could not be processed, therefore the respective state could not be reached, or the
message itself signals an exception, such as Reject Purchase Order) and timeout
exceptions (the message did not arrive on time). These exceptions are based on the
semantics of ebXML BPSS5.
Message exchanged may be a) individual notifications not logically related to any other
message exchange, or b) a request message followed by ‘n’ correlated responses. The
responses maybe exclusive (only one response out of several possible) or additive
(received one after another, including several times the same message type). A message
exchange whether it is of type a) or b) is called a business transaction5.
The first step in defining a business process is to identify all the roles and all the possible
message exchange between these roles regardless of the sequence of message exchange.
The second step specifies the data flow, identifying the payload of each message and the
relations between the payloads of different messages, including the transformations.
The third step is to define the possible (or lack of) control flow. We do not believe that
there is only one possible control flow model possible. Control flow may be defined with
a block-structured approach, or with transitions. It is conceivable we also need to be able
to define ad hoc processes including some parts of the control flow that could be defined
dynamically at run-time. The business process definition metamodel should exhibit a
“plug-able” control flow definition. This is only possible if the message flow, data flow
and control flow specifications are independent.
We can envisage other steps such as one step in which “activities” or “transactions” are
defined.
5
ebXML BPSS team area, http://www.ebtwg.org/projects/documentation/bpschema/ppbpschema.html
3
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
Message Flow of an Executable Business Process
The message flow definition is achieved by identifying all roles and all individual
message exchange between the respective roles. In addition, we need to specify a role
which can be identified as “self” which represents the perspective of the process.
Typically, this “role” will be implemented by the business process management system,
while other roles will be implemented by other systems and components. This role is
involved each time services such as transformation or routing is needed to connect the
sender or a message to its received. This model allows for external roles such as buyer,
seller, finance institution… for which specific collaboration agreements are in place.
The important aspect of this model is that when a given message exchange does not need
to be mediated by a business process management system, it can be directly expressed as
an exchange between the two specific roles (between your order entry and billing
components). However, this particular message exchange is integral part of the business
process definition because it changes the state of the process instance. This is a very
important concept which is not well addressed by traditional “centralized” business
process definition where all the message flow is modeled between the different parties
and the process engine (BPML, XLang, WSFL, WfMC).
Figure 1 represents a simple “Process Purchase Order” executable business process based
on the OAGIS6 scenario 40. There are four roles involved in this particular business
process: buyer, supplier, order entry and billing. As we mentioned earlier the “Supplier”
role represents “self” i.e. the perspective of the BPMS. We adopt a simple notation:
 Each role is represented by a swim lane.
 Each box represent a message exchange including a either a notification or a
request/response(s).
 The arrow across the boxes indicates the direction of the initiating message.
 The left side and right of the box are represented within the swim lane of the role
participating in the message interchange.
The scenario features a business partner (buyer). Our model is technology neutral: every
message exchange can be done with a different protocol over various transports
(technical characteristics). In particular it is important to be able with the technologies du
jour (such as Web Services and ebXML) as well as the coming ones. In a previous paper7
we have represented ebXML BPSS business transactions as square box and web service
operations as rounded boxes. We keep this convention here.
The first two business transactions (BTA1 and OpA1) are equivalent; of course they
typically deal with different data formats. They are mediated by the process engine
(represented by the supplier role). Because the message types are different, the process
engine may have the opportunity to apply a transformation to the payload.
6
M. Rowell et al, OAGIS 8.0, 2002, www.openapplications.org
Jean-Jacques Dubray, “A new model for ebXML BPSS Multi-party Collaborations and Web Services
Choreography”, 2002, http://www.ebpml.org/ebpml.doc
7
4
Start
Buyer
Supplier
Order Entry
Billing
(Self)
PO
BTA1
PO
Sales
order
OpA1
OpA2
Invoice
OpA3
Invoice
BTA2
166
167
168
169
170
171
172
173
174
175
176
177
178
Success
Failure
Figure 1 Message Flow of a "Process Purchase Order" executable business process
It may also be possible to route the incoming purchase order from the buyer to a manager
for approval (Figure 2 User interaction modeled as a message exchange). The business
transaction with the manager role is a PO (request) and a PO (response) with the approval
value which would have been added. Alternatively it is also possible to keep the approval
information separate and return an approval response.
When we define the control flow, we would probably define a “choice” control flow that
would decide to directly route the PO to the order entry component or ask for a manager
approval based on an amount value for example.
5
179
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
PO
PO
BTA1
Wit1
PO
AckPO
Sales
order
OpA1
OpA2
180
181
182
183
184
185
186
187
188
189
Figure 2 User interaction modeled as a message exchange
We could also design a scenario where the purchase order may be routed directly to the
Order Entry component (Figure 3) completely bypassing the process engine, without any
transformation. This is not a typical scenario but it is conceivable and supported by our
model.
Buyer
Supplier
Order Entry
(Self)
PO
BTA1
190
191
Figure 3 A direct integration between a B2B message exchange and an EIS component
192
193
194
195
196
197
198
199
200
The business process definition specified as a message flow may also be decomposed in
individual collaborations involving any two roles. These collaborations are important to
identify because the technical binding usually happens at the collaboration level as it is
expected that two roles will often exchange messages with the same technology. Note
that this is not mandatory as several collaborations may be defined between any two
roles. However, it is expected that any binding between a message and a technology will
happen at the collaboration level. Collaboration may have their own “choreography”
specification. This information can be used in two ways: first we could infer the
appropriate control flow (at least assist the user in designing the control flow) or simulate
6
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
the execution of a process definition and verify that it is compatible with the
choreography specifications.
Our model as we define it is a generalization of the ebXML BPSS specification5 which
specifies binary collaborations as a message exchange packaged as business transactions.
The fundamental advantage of this model is to keep the correlation of request and
responses that constitute the same transaction as part of the process definition. Other
approaches like the one of BPML or WfMC based on activity tend to separate request
(coming from a business partner or a component), processing of this request – as a series
of activities performed by users or internal components – and response to the initial
requests assembled during the processing of the request. This kind of separation makes
the binding between a collaboration definition (whether specified by BPSS or a global
model like the one of WSFL8) harder.
The major advantage of this approach is to organize the process definition as a series of
collaborations between components, between components and the process engine itself,
or between business partners and the process engine or directly with components. If the
process engine adds value, for instance by routing or transforming a message, its services
will be used. Otherwise, this process definition model allows for a decentralized
communication directly between two components or a component and a business partner.
This approach leads to greater scalability. Naturally, at the implementation level the
process must be made aware of the message exchange such that the process state can
advance.
Process
initiating
1
Role
1..*
1
CollaborationActivity
BusinessTransactionActivity
BusinessTransaction
1..*
1
1
Collaboration
WSDL
Activity
226
227
Operation
ebXML
ebXMLBusinessTransaction
Figure 4 - UML Class Diagram of a Business Process Definition
8
WSFL specification, IBM, 2001, http://www.ibm.com
7
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
It also makes the BPMS adopt a more passive profile, not distributing work but rather
monitoring that work happen as defined and adding value as a mediator. It is of course
always possible to use a more centralized mode as needed.
Figure 4 represents the UML Class diagram of the message flow of a business process
definition. Green elements correspond to definitions, and yellow elements correspond to
a usage of a definition (a CollaborationActivity is a usage of a Collaboration –Definition
– in the context of a Process). The concept of activity becomes a characteristic of the
message exchange rather than its nature. In particular an activity has a state associated
with it which goes from: started to completed9.
This approach can be used to model all levels of process-oriented logic that we defined in
the introduction. Collaboration are by definition modeled following the same approach
because, we actually took the collaboration definition model and extended to specify an
executable process. An enterprise process being the combination of collaborations and
executable processes may also be modeled the same approach. I will show in a
subsequent paper how “tasks” may also be modeled following the same approach.
This approach simplifies interoperability between different engines as it is likely that a
collaboration activity sharing the same collaboration definition may be used by each
process definition to model its interactions with the other processes.
Finally, this approach also simplifies the notion of process composition, since a “sub
process” may simply be viewed as a new role within the global process definition. Like
BPML, this sub-process maybe “spawned” or “called” based on the nature of the
collaboration that links it to the parent process. But unlike BPML, a sub-process may also
fully “collaborate” with is parent process spanning multiple peer-to-peer data exchanges.
Not that this approach is in a way related to the EDOC specification10. This is no
surprised since there has been a conscious alignment made by design between ebXML
BPSS and the EDOC specification. However, EDOC does not integrate well the concept
of B2B “collaboration”, does not rely on generic business transaction definitions, and
offers very limited control flow specification. EDOC is rather focused on defining a new
architecture for business object components and their composition. Our model introduces
new concepts such as external roles such as “Buyer”, user roles such as “Manager” and
the notion of “Self” which represents the business process management system.
9
WfMC Specification, http://www.wfmc.org
J.J. Halliday et al “Flexible Workflow Management in the OPENflow system”, HP
10
8
271
272
Message flow and Unit of Work
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
BTA1
Mapping
Routing
PO
PO
Wit1
PO
AckPO
OpA1
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
Unit of
Work
Sales
order
Unit of
Work
OpA2
Figure 5 - Relationship between unit of work (a.k.a. activity) and message exchange
The major problem we see in relating in an approach based on “unit work” is that
typically “unit of work” or activities are not homogeneous with respect to the number of
messages they are related to. Here we see that the Order Entry activity is related to four
messages, while the Billing activity is related to only two messages while the process
engine is not really doing any specific work besides mapping and routing messages. It is
conceivable that one could also define activities that are related to many more messages
in particular when forks are used to specify that an activity need to wait on more than one
request to do some work. In this case we could end up having an activity coordinating the
exchange of 6 or more messages.
Typically standards like BPML, XLang or WSFL consider message exchange and
activity at the same level. So a unit of work can only be viewed as a request/response
from the perspective of the process engine. It is then become very difficult to describe
cases like the Order Entry unit of work in Figure 5 where the unit or work coordinates
several business transactions.
In these standards, the control flow is then used to tie together related message
exchanges, therefore establishing a convolution between the message flow and the
control flow.
9
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
Example
Here is an example of an XML definition corresponding to Figure 2.
<?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification
xmlns="http://www.ebxml.org/BusinessProcess"
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation="http://www.ebxml.org/BusinessProcess C:\Projects\EBPML\ebBPMML0.5.xsd"
name="SimpleProcessDefinition"
uuid="5678"
<!-- Business transaction definition -->
<BusinessTransaction name="ProcessBuyerPO_BT">
…
</BusinessTransaction>
<BusinessTransaction name="ProcessPO_BT">
…
</BusinessTransaction>
<BusinessTransaction name="ProcessPO_BT">
…
</BusinessTransaction>
<BusinessTransaction name="ApprovePO_BT">
…
</BusinessTransaction>
<BusinessTransaction name="SynchSalesOrderPO_BT">
…
</BusinessTransaction>
<!-- Process definition -->
<Process name="ProcessOrder" initiatingRoleID="R1" timeToPerform="P5D">
<Role name="Buyer" nameID="R1" type="partner"/>
<Role name="Supplier" alias="Self" nameID="R2" type="process"/>
<Role name="OrderEntry" nameID="R3" type="component"/>
<Role name="Billing" nameID="R4" type="component"/>
<Role name="Manager" nameID="R5" type="user"/>
<CollaborartionActivity name="ProcessBuyerPO_CA" fromRole="Buyer" toRole="Supplier"
collaboration="ProcessBuyerPO_C" timeToPerform="P5D"/>
<CollaborartionActivity name="ProcessPO_CA" fromRole="Self" toRole="OrderEntry"
collaboration="ProcessPO_C" timeToPerform="P1D"/>
<CollaborartionActivity name="ApprovePO_CA" fromRole="Self" toRole="Manager"
collaboration="ApprovePO_C" timeToPerform="P4H"/>
<CollaborartionActivity name="SynchSalesOrrder_CA"
fromRole="OrderEntry" toRole="Billing"
collaboration="SynchSalesOrder_C" timeToPerform="P4H"/>
</Process>
<!-- Collaboration definition -->
<Collaboration name=" ProcessBuyerPO_C" fromRole="Buyer" toRole="Supplier">
<BusinessTransactionActivity name="ProcessBuyerPO_BTA" fromRole="Buyer" toRole="Supplier"
businessTransaction="ProcessBuyerPO_BT" timeToPerform="P1D"/>
</Collaboration>
<Collaboration name="ProcessPO_C" fromRole="Self" toRole="OrderEntry">
<BusinessTransactionActivity name="ProcessPO_BTA" fromRole="Self" toRole="OrderEntry"
businessTransaction="ProcessPO_BT" timeToPerform="P1H"/>
</Collaboration>
<Collaboration name="ApprovePO_C" fromRole="Self" toRole="Manager">
<BusinessTransactionActivity name="ApprovePO_BTA" fromRole="Self" toRole="Manager"
businessTransaction="ApprovePO" timeToPerform="P4H"/>
</Collaboration>
<Collaboration name="SynchSalesOrder_C" fromRole="OrderEntry" toRole="Billing">
<BusinessTransactionActivity name="SynchSalesOrder_BTA" fromRole="OrderEntry" toRole="Billing"
businessTransaction="SynchSalesOrder_BT" timeToPerform="P1H"/>
</Collaboration>
</ProcessSpecification>
10
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
Control Flow
I would like to take the risk to disappoint many by asserting that there is not a single
“magic” control flow which can be used in all situations to model any scenario.
So far there have been two approaches to establishing the model of a control flow:
 Annotated directed graph where the nodes represent the activities (unit of work)
and the edges represent the flow of control and data among the different steps
 Block-structured approach where the units of work are assembled into blocks of
different types (BPML uses All and Sequence to express parallel or serial
execution of the unit of work).
Of course a combination of both approaches is always possible. Blocks are important to
model and demarcate the context of transactions while transitions are easier to use to
model ad hoc or collaborative processes.
These models remain almost always too low level and a “library” of construct need to be
built on top of the basic concepts to enable an effective modeling of business processes.
There is also the semantics of “publish/subscribe” which is very important for modeling
application-to-application integration scenarios which is often overlooked by control flow
specifications such as WfMC, BPML 1.0, WSLF, XLang…
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
PO
PO
BTA1
Wit1
PO
AckPO
Sales
order
OpA1
OpA2
[BusinessFailure]
385
386
387
388
389
390
[Success]
Failure
Success
Figure 6 - Control flow added to the message flow
Our approach is to avoid constraining the user into a given control flow model. In
particular, we may want to use the control flow model of ebXML BPSS5. Its model is
based on a direct graph. However, there are also some particularities that I would like to
11
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
stress. This model offers a semantic called “onInitiation” which is an attribute of a
transition from a business transaction activity. This simply means that upon the request of
a business transaction activity, this transition will fire. This is what allows us to keep the
corresponding business transaction activity “intact” and does not require separating
request, processing and response from a process definition perspective. Figure 6
represents the control flow of the example detailed in Figure 2.
A synchronization bar (in gray) allows us to evaluate a condition expression on the
context of the purchase order and decide whether this particular PO requires approval
from a manager.
This can be expressed simply in XML using the BPSS control flow elements:
<?xml version="1.0" encoding="UTF-8"?>
<ProcessSpecification
xmlns="http://www.ebxml.org/BusinessProcess"
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation="http://www.ebxml.org/BusinessProcess C:\Projects\EBPML\ebBPMML0.5.xsd"
name="SimpleProcessDefinition"
uuid="5678"
<!-- Process definition -->
<Process name="ProcessOrder" initiatingRoleID="R1" timeToPerform="P5D">
<!-- Roles -->
…
<!-- Collaboration activities -->
…
<!-- Control flow -->
<ControlFlow type="ebXMLBPSS " version="1.05">
<Start toBusinessState="ProcessBuyerPO_BTA" />
<Transition fromBusinessState="ProcessBuyerPO_BTA" toBusinessState="Approve_Fork"
onInitiation="true" conditionGuard="Success"/>
<Fork name="Approve_Fork" />
<Transition fromBusinessState="Approve_Fork" toBusinessState="ApprovePO_BTA">
<ConditionExpression expressopLanguage="XPath" expression="//Amount/[@value>=1000]">
</Transition>
<Transition fromBusinessState="Approve_Fork" toBusinessState="ProcessPO_BTA">
<ConditionExpression expressopLanguage="XPath" expression="//Amount/[@value<1000]">
</Transition>
<Transition fromBusinessState="ApprovePO_BTA" toBusinessState="ProcessPO_BTA"
conditionGuard="TechnicalSuccess"/>
<Transition fromBusinessState="ProcessPO_BTA" toBusinessState="SynchSalesOrder_BTA"
conditionGuard="Success"/>
<Failure
fromBusinessState="ProcessPO_BTA"
conditionGuard="BusinessFailure"/>
<Success fromBusinessState="SynchSalesOrder_BTA"
conditionGuard="Success"/>
</ControlFlow>
</ProcessSpecification>
An important point to note is the way this process definition reaches a “failure” end state.
If a purchase order requires approval and a manager rejects this purchase order, the
transition from the ApprovePO_BTA to ProcessPO_BTA would still fire because it is
guarded by a “TechnicalSuccess” condition. This simply means that the work item was
executed without problem regardless of the fact that the PO was approved or not. The
12
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
OrderEntry component should have different business rules that decide whether it will
return an AcceptPO or RejectPO response. In the event that this component a RejectPO
response, this is considered as a “BusinessFailure” of the business transaction. In this
case, the process ends in failure and the last business transaction activity
(SynchSalesOrder_BTA) will not be executed.
This model effectively separates the message flow from the control flow, therefore
enabling the concept of a plug-able control flow specification. Other approaches
including the one of BPML 1.0 require to model a “solicit response” in three activities
related by the control flow in order to correlate the request with the response.
We have not addressed the aspects of exception in details. In the example above, we have
simply used ebXML BPSS exceptions which are divided in three groups: technical failure
(either the request or response could not be processed), business failure (the response
what characterized as negative) and timeout (either the request or the response was
exchange beyond the allowed time).
ebXML BPSS does not specify particular exception paths. If an exception is detected the
control flow will simply continue based on the corresponding transition. The subsequent
business transaction activities are no different from the others. Specification like BPML
1.0 introduces the concept of “compensating transactions” that are executed when an
exception occurs. Again, we believe that there is not a single and ultimate control flow
exception and these kinds of semantics should be handled with a “plug-able” control flow
mechanism.
13
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
Data and document flow
The message flow serves as the basis of the data flow definition as messages may contain
a payload of business documents and binary documents with their metadata. In addition,
it is well established that we need to define a set of “properties” also known as “process
variables” in which specific values of a business document or metadata of a binary
document may be stored and manipulated.
<!-- Process definition -->
<Process name="ProcessOrder" initiatingRoleID="R1" timeToPerform="P5D">
<!-- Roles -->
…
<!-- Collaboration activities -->
…
<!-- Control flow -->
<!—Data flow -->
<DataFlow>
<Property name="POAmount" value="//PO/Amount/@value" />
<Map fromBusinessState="ProcessBuyerPO_BTA" toBusinessState="ApprovePO_BTA"
fromDocument="PO" toDocument="PO">
<Transformation transformationLanguage="XSLT" transformation="map1.xslt">
</Map>
<Map fromBusinessState="ProcessBuyerPO_BTA" toBusinessState="ProcessPO_BTA"
fromDocument="PO" toDocument="PO">
<Transformation transformationLanguage="XSLT" transformation="map1.xslt">
</Map>
</DataFlow>
</ProcessSpecification>
There are other aspects associated to the data flow that we do address in this paper.
Correlation has been first addressed by Microsoft with the XLang specification11, and it is
relatively clear that this approach could be used as the basis of a correlation mechanism
for business transactions.
Transactions have not been addressed in this paper. It is expected that in this case, the
fact that this process model is based on messages and not “activities” could change
significantly the way transactions can be handled.
11
XLang specification, Microsoft, 2001, http://www.gotdotnet.com/XLANG.htm
14
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
Conclusion
We have extended the approach of ebXML BPSS which enables the modeling of peer-topeer business collaboration to be able to model all levels of the process-oriented business
logic found in business applications today. This approach based is based on the concept
of “Business Transaction” which provide for model for request/response between two
roles. Operations of a web service as well as ebXML BPSS business transactions can be
bound seamlessly to a business transaction definition. This concept:
 Allows to specify “decentralized” business process definitions,
 Leads itself to a simple specification of a sophisticated interoperability and
process composition models.
 Requires a simple data and document flow mapping since most of the data and
document flow is already specified as part of the message exchange.
 Simplifies greatly the technical binding since business transaction activities can
easily be related to web service operations and WSDL definitions on one hand
and ebXML business collaboration definitions on the other hand.
 Enables us to use a very basic but efficient notation
Overall these concepts provide a technology neutral process definition model, unlike
some other specification which only focuses on web services.
This concept was also designed with a large number of standard organizations and
consortia in mind such as UMM (Unified Modeling Methodology), RosettaNet12, the
Open Applications Group, STAR XML13. In particular we believe that all the OAGIS6
integration scenarios may be modeled with this approach.
In three subsequent papers, we will provide a detailed description of the application of
this approach to model “tasks” and work items. We will also provide in a general paper
the complete specification of the ebPML Process Definition Language. Finally we will
give implementation guidelines to the business process management systems that will
execute ebPML process definitions.
12
13
RosettaNet consortium, http://www.rosettanet.org
STAR XML working group, http://www.starstandard.org
15
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
Glossary
Actor – A physical partner, system component or user participating in a process instance
Business Transaction – a message exchange between two roles. It is either a notification,
or a request/response message exchange. The response may be one of many possible
responses, or any number of correlated responses.
Business Transaction Activity – the usage of a business transaction within a collaboration
definition.
Collaboration – a series of business transaction activities between two roles.
Collaboration Activity – the usage of a collaboration within a process definition
Process – a series of collaboration activities
Role – represent a logical business partner, system component or user within the process
definition. Roles are resolved at run time into a physical Actor. A process definition
exhibit a special role identified as Self which represents the process instance. A process
which interacts with the later is represented by a separate role.
16