Friday, August 14, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec Q -- By Mathias Weske

Architecture of Process Execution Environments

So far, this chapter has discussed the modelling of different aspects of a business
process. This section looks into the representation of a business process
management system capable of controlling the enactment of business processes
based on business process models.
The architecture
model contains the Business Process Environment, a Business Process Modelling
subsystem, a Business Process Model Repository, a Process Engine, and
a set of Service Providers. The roles of these constituents of the architecture
model are characterized as follows.
• Business Process Modelling: The business process modelling subsystem
is used for creating business process models, containing information on
activities, their operations, and the structure of the business process. This
architecture subsystem can be realized by business process modelling tools.
• Business Process Environment: The business process environment triggers
the instantiation and enactment of process instances based on process
models.
• Business Process Model Repository: The business process model repository
holds business process models that are created by the business process
modelling component.
• Process Engine: The process engine is responsible for instantiating and
controlling the execution of business processes. It is the core component
of a business process management system. This component is triggered by
the business process environment. It uses process models to instantiate and
control the enactment of process instances. To execute a particular activity
instance, it calls entities that act as providers of the required functionality.
In a service-oriented architecture, service providers are called to execute
individual services that realize business process activities.
• Service Providers: Service providers host application services that realize
business process activities. In the architecture model, service providers
represent an abstract entity that subsumes not only Web service providers
but also knowledge workers that realize particular activities in business
processes. The organizational and technical information that the process
engine needs in order to determine and access the service provider is also
stored in the business process model repository.
These components of the architectural model control the enactment of process
instances. To capture the distributed nature of business process executions,
the components and the service providers are represented by agents that communicate
by sending and receiving messages, i.e., the agents do not share
memory, but are distributed.
Gateways are nodes in a process model that are used to guide the process
flow. Therefore, for each gateway node the process engine needs to perform
some action. This work that the process engine conducts is represented by
a gateway instance, just as the work defined by an activity model is represented
by an activity instance. A property of gateway instances is that the
process engine executes them, whereas activity instances are executed by service
providers, requiring nonlocal communication.
The first event that occurs represents
the occurrence of the initial event in the process model. Let e1 be this
event.
The process engine detects that there is a process model defined for this
event. Therefore, a process instance is instantiated. For each activity model in
the process model, an activity instance is instantiated; for each gateway node,
a gateway instance is created, represented by events i2 through i6. When the
instances are initiated, the AnalyzeOrder activity instance can be started,
resulting in event b2. After the termination of this activity instance in event
t2, the gateway instance is started, represented by event b3.
After the gateway instance terminates in event t3, the process engine can
decide which path to take. In the process instance shown, the advanced check
activity instance is disregarded and the simple check path is taken. Therefore,
the AdvCheck activity instance is skipped, represented by event s5. The SimpleCheck
activity instance is started (event b4) and later terminates in event
t4. Finally, the execution of the gateway instance and the occurrence of the
final event n7 terminate the process instance.
The event diagrams introduced are extended to capture agents involved
in the enactment of process instances. Each agent is represented by a horizontal
line, on which the events that occur in this agent are drawn. Time
proceeds from left to right. In addition to the events directly associated with
the execution of activity instances, the begin and end of a computation and
the sending and receipt of a message are also represented by events. Message events of agents represented by directed arcs connecting the send event with
the corresponding receive event.
The business process environment, the process engine, and two service
providers are the agents represented in the event diagram. Since the operation
of the business process modelling component is not the focus of attention,
these components of the architecture model are not represented as agents in
the event diagram.
When the initial event of the process model occurs in the business process
environment, the process engine instantiates a process instance, including its
activity instances. Then, the process engine determines the first activity instance
to be executed. A service provider is determined for executing this
activity, in the example, Service Provider 1.
The service provider receives this message and starts an AnalyzeOrder
activity instance, marked by event b2. Once that activity instance is completed
(t2), the service provider returns a message to the process engine. This message
typically contains the return value of that invocation. Using this information
and possibly other information, the process engine can evaluate the condition
associated with the gateway node. Based on the decision made by the process
engine on behalf of the gateway, the AdvCheck activity instance is skipped
(skip event s5) and the SimpleCheck activity is started.
In order to realize this process instance, the process engine sends an invocation
message to the service provider responsible for executing the simple
check service. Service Provider 2 receives this message and starts the SimpleCheck
activity, marked by event b4.
Once this activity instance completes in event t4, the service provider
returns a message to the process engine, which then executes the join gateway
node (events omitted). The process instance completes with the final event and by sending the respective message to the business process environment,
informing it about the termination of the process instance.
As will be detailed in the next chapter for more complex workflow patterns,
control flow patterns restrict the ordering of execution events for activities
involved in a business process. For instance, an AnalyzeOrder activity can
only be started after the initial event has occurred, and a SimpleCheck activity
can only be started after the exclusive or gateway has completed, and so on.
The execution semantics of a process instance based on a process model is
described by restrictions on the events and their ordering during the execution
of process instances.

No comments:

Post a Comment