Levi - SRS

SYSTEM REQUIREMENTS SPECIFICATION
Levi – the Native BPMN 2.0 Execution Engine

Version 1.0
PROJECT SUPERVISORS
 Ms. Vishaka Nanayakkara
 Dr. Sanjiva Weerawarana
 Mr. Milinda Pathirage
GROUP MEMBERS
Index No Name E-mail

070468D Eranda Sooriyabandara 070468d@gmail.com
070206B Ishan Jayawardena udeshike@gmail.com
070138R Keheliya Gallaba keheliya.gallaba@gmail.com
060501P Umashanthi Pavalanathan umashanthip@gmail.com
Levi | System Requirement Specification i

REVISION HISTORY
Date Version Description Authors

Oct/29/2010 Draft Draft version All members
Nov/01/2010 0.9 Pre-final All members
Nov/04/2010 1.0 Final All members
Levi | System Requirement Specification ii

TABLE OF CONTENTS
1. Introduction ………… ................................................................................................................................................. 1

1.1 Purpose ……….................................................................................................................................................... 1
1.2 Scope ………… ..................................................................................................................................................... 1
1.3 Target Audience ............................................................................................................................................... 1
1.4 Document Overview....................................................................................................................................... 1
2. Overall Description ..................................................................................................................................................... 2
2.1 Product Perspective ....................................................................................................................................... 2
2.2 Product Functions ........................................................................................................................................... 2
2.3 User Classes and Characteristics .............................................................................................................. 2
2.5 Assumptions and Dependencies ............................................................................................................... 3
2.6 Usage Patterns of BPMN ............................................................................................................................... 3
2.6.1 Private (Internal) Business Processes ........................................................................................ 3
2.6.2 Public Processes ................................................................................................................................... 4
3. Specific Requirements ............................................................................................................................................... 8
3.1 Use-case Report ............................................................................................................................................... 8
3.1.1 Use Case 1 ............................................................................................................................................... 9
3.1.2 Use Case 2 ............................................................................................................................................ 10
3.2 Process Execution Conformance Requirements ............................................................................. 13
3.2.1 Process Instantiation and Termination ................................................................................... 14
3.2.1.1 Process Instantiation ....................................................................................................... 14
3.2.1.2 Process Termination ........................................................................................................ 14
3.2.2 Activities ............................................................................................................................................... 14
3.2.2.1 Sequence Flow Considerations .................................................................................... 14
3.2.2.2 Activity ................................................................................................................................... 15
3.2.2.3 Task ......................................................................................................................................... 16
3.2.2.4 Sub-Process / Call Activity ............................................................................................ 16
3.2.2.5 Ad-Hoc Sub-Process ......................................................................................................... 16
3.2.2.6 Loop Activity ....................................................................................................................... 16
3.2.2.7 Multiple Instances Activity ............................................................................................ 17
3.2.3 Gateways .............................................................................................................................................. 17
3.2.3.1 Parallel Gateway (Fork and Join) ................................................................................ 17
3.2.3.2 Exclusive Gateway (Exclusive Decision and Exclusive Merge) ..................... 17
3.2.3.3 Inclusive Gateway (Inclusive Decision and Inclusive Merge) ......................... 18
3.2.3.4 Event-based Gateway (Exclusive Decision (event-based)) ............................. 18
3.2.3.5 Complex Gateway (related to Complex Condition and Complex Merge) ... 19
3.2.4 Events .................................................................................................................................................. 19
3.2.4.1 Start Events.......................................................................................................................... 19
3.2.4.2 Intermediate Events ......................................................................................................... 19
3.2.4.3 Intermediate Boundary Events ................................................................................... 19
3.2.4.4 Event Sub-Processes ........................................................................................................ 19
3.2.4.5 Compensation Event ........................................................................................................ 20
3.2.4.6 End Events ........................................................................................................................... 20
3.2.4.6.1 Process level end events ............................................................................. 20
3.2.4.6.2 Sub-process level end events .................................................................... 20
Levi | System Requirement Specification iii

3.3 Non-functional Requirements................................................................................................................. 20
3.3.1 Usability ................................................................................................................................................ 20
3.3.2 Reliability ............................................................................................................................................. 21
3.3.2.1 Error handling .................................................................................................................... 21
3.3.2.1.1 Compensation handler ................................................................................ 21
3.3.2.1.2 Operational Semantics ................................................................................. 21
3.3.3 Performance Requirements ......................................................................................................... 22
3.3.4 Supportability .................................................................................................................................... 23
3.3.5 Design Constraints ........................................................................................................................... 23
3.3.6 On-line User Documentation and Help System Requirements ...................................... 23
3.3.6.1 Documentation ................................................................................................................... 23
3.3.6.2 Web site / Blog ................................................................................................................... 24
3.3.6.3 Mailing lists .......................................................................................................................... 24
3.3.6.4 Version control & Source Code .................................................................................... 24
3.3.6.5 Issue tracking ...................................................................................................................... 24
3.3.6.6 Real-time chat ..................................................................................................................... 24
3.3.6.7 Features and Requirements List ................................................................................. 25
3.3.7 Reusing Components....................................................................................................................... 25
3.3.7.1 JACOB ..................................................................................................................................... 25
3.3.7.2 WSO2 User Management Component....................................................................... 25
3.3.8 Interfaces.............................................................................................................................................. 25
3.3.8.1 User Interfaces ................................................................................................................... 25
3.3.8.2 Hardware Interfaces ........................................................................................................ 27
3.3.8.3 Software Interfaces .......................................................................................................... 27
3.3.8.4 Communications Interfaces .......................................................................................... 28
3.3.9 Licensing Requirements ................................................................................................................ 28
3.3.10 Legal, Copyright, and Other Notices ....................................................................................... 28
3.3.11 Applicable Standards .................................................................................................................... 29
4. Supporting Information ......................................................................................................................................... 30
4.1 Definitions, Acronyms, and Abbreviations ........................................................................................ 30
4.2 References .................................................................................................................................................. 30
Appendix A …………… ................................................................................................................................................. vi
Levi | System Requirement Specification iv

TABLE OF FIGURES
Figure No Description Page No
2.1 Example of a private business process ......................................................................................... 4

2.2 Example of a public process .............................................................................................................. 4
2.3 An example of a collaborative process .......................................................................................... 5
2.4 An example of a choreography ......................................................................................................... 6
2.5 An example of a Conversation diagram ........................................................................................ 6
3.1 A simple business process ................................................................................................................. 8
3.2 The Purchaser process and its collaborations with other service provider
processes .................................................................................................................................................. 9
3.3 Incident Management with human-driven and system-driven pools .............................11
3.4 This rather simple diagram is all we have to show to the account manager ..............12
3.5 This is the only part of the whole collaboration we will execute in Levi ......................13
3.6 Multiple outgoing Sequence Flows ...............................................................................................14
3.7 The Lifecycle of a BPMN Activity ...................................................................................................15
3.8 The Parallel Gateway ..........................................................................................................................17
3.9 The Exclusive Gateway ......................................................................................................................17
3.1 The Inclusive Gateway .......................................................................................................................18
3.11 The Event-Based Gateway ................................................................................................................18
3.12 The Complex Gateway........................................................................................................................29
3.13 Sample Web User Interface for deploying a BPMN process ................................................26
3.14 Sample Web User Interface for a user to manage his tasks assigned by the
Process Execution Engine ................................................................................................................27
Levi | System Requirement Specification v

1. INTRODUCTION
1.1 Purpose
This System Requirements Specification describes the software functional and nonfunctional
requirements for the project Levi - the native BPMN 2.0 execution engine. This document is
intended to be used by the members of the project team and the supervisors, both internal and
external, who will participate in the design and implementation phases of the project and verify
the correct functionality of the system. Unless otherwise specified, all requirements mentioned
here are of high priority and committed for the project submission.
1.2 Scope
Levi is a native BPMN 2.0 execution engine, which can be used to execute business process
models that conform to the BPMN 2.0 specification. And most importantly, it will serve as a
proof of concept for exploring the possibilities of using Apache ODE (Orchestration Director
Engine) and JACOB (Java Concurrent Object Framework) to execute BPMN 2.0 processes. This
engine will be capable of deploying, persisting, navigating, and executing business processes
claiming BPMN 2.0 execution conformance. The major objective of BPMN 2.0 standard is to
provide a high level overview of business processes and their execution to the business people
who do not have much technical expertise. We allow businesses to have automated, efficient
process flows and eventually increase their productivity by facilitating the execution of these
modeled business processes in Levi.
1.3 Target Audience

This System Requirements Specification document is a reference for all the internal mentors,
external mentors, and all the academic staff members of University of Moratuwa who are
involved in supervising and evaluating the projects carried out for the module CS 4200 - Project.
Furthermore, this document will serve as a reference for all the contributors engaged in this
project and the projects associated with it.
1.4 Document Overview

Section 2 provides an overall description of the project including product perspective, product
functions, user classes and characteristics, issues and constraints, assumptions and
dependencies, and finally about usage patterns of BPMN.
Specific requirements for the project is categorized and defined in Section 3. This section
contains use case report, process execution conformance requirements, and non-functional
requirements such as usability, reliability, performance requirements, user documentation,
interfacing requirements, etc.
Section 4 contains supporting information such as definitions, acronyms, abbreviations and
references. Appendix A contains the details of Apache License.
Levi | System Requirements Specification 1

2. OVERALL DESCRIPTION
2.1 Product Perspective
The primary goal of BPMN 2.0 is to provide a notation that is readily understandable by all
business users, from the business analysts that create the initial drafts of the processes, to the
technical developers responsible for implementing the technology that will perform those
processes, and finally, to the business people who will manage and monitor those processes.
Thus, BPMN 2.0 creates a standardized bridge for the gap between the business process design
and process implementation. In this context, Levi, the native BPMN 2.0 execution engine will
provide a comprehensive execution environment for enterprise level business workflow
management.
The execution model used by Levi consists of different stages where each stage is responsible of
a precise, predefined task. In the initial stages it converts the supplied business process model
into an executable intermediate format that is understandable internally, and then in the final
stage, it executes this model by employing the concepts such as orchestration, choreography
and intermediate web services invocation layer. In addition to that, Levi’s internals are designed
in such a way that it possesses the ability to be expanded to support choreography modeling
conformance, process modeling conformance, better error handling and debugging
methodologies.
2.2 Product Functions

The following are the key features of Levi:
a. Detecting and recognizing the input BPMN 2.0 process model
b. Mapping the process model to an internal object model using XMLBeans
c. Persistence Management
d. Handling concurrent execution of processes
e. Execution of BPMN 2.0 constructs using a web services layer
2.3 User Classes and Characteristics

Levi targets the business community, especially business analysts and managers who are
seeking to improve process efficiency and quality of their enterprise. Business users can model
and execute business processes in the areas of Customer Relationship Management, Supplier
Relationship Management, Logistics, Supply Chain Planning, Financial Accounting, Project
Management, Human Resources and others. Since the users are considered as having
considerable experience in the workflow domain, the users are not considered as novice
computer users. As the open source practice, Levi’s source code will be made available to the
public, so the interested developer level users can customize and further enhance the code base
to fit their requirements.
2.4 Issues and Constraints

a. Since this engine is based on Apache ODE and JACOB, ODE’s virtual process machine,
there is a higher risk of inheriting most of the complexities and shortcomings of their
architecture. Since BPEL being the process execution language of Apache ODE, and

BPMN 2.0 being that of Levi, they have many fundamental differences. For instance,
BPMN 2.0 XSD makes heavy use of inheritance, unlike in BPEL. Because of this reason,
the existing XSD parser of ODE cannot be reused. Therefore, it will be required to write
an XSD parser for Levi anew.
b. The BPMN 2.0 standard consists of a number of constructs for business process
modeling and only a subset of that fall into the executable category. Due to this, the
project’s scope limits itself to a proof of concept scenario as only a subset of the
executable components will be implemented.
c. This project is at an experimental level that explores the web services domain and the
business process modeling domain. Hence a considerable amount of research and study
has to be carried out in this project, making the unique challenges of being one of the
first native BPMN engines in the BPM sphere.
2.5 Assumptions and Dependencies

a. It is assumed that the user of Levi will use a suitable editor which complies with BPMN
2.0 modeling conformance, to model a business process in BPMN 2.0, which, in turn, can
be fed as the input to Levi.
b. Levi’s architecture heavily depends on the JACOB framework and other other reusable
components of Apache ODE, as will be elaborated in the coming sections of this
document. Since ODE depends on the Java Runtime, indirectly, Levi will require the user
to have the Java Virtual Runtime installed.
2.6 Usage Patterns of BPMN

Business process modeling is used to communicate a wide variety of information to a wide
variety of audiences. BPMN is designed to cover many types of modeling and allows the creation
of end-to-end business processes. The structural elements of BPMN allow the viewer to be able
to easily differentiate between sections of a BPMN Diagram.
There are three basic types of sub-models within an end-to-end BPMN model:
a. Processes (Orchestration), including:
i. Private non-executable (internal) Business Processes
ii. Private executable (internal) Business Processes
iii. Public Processes
b. Choreographies
c. Collaborations, which can include Processes and/or Choreographies
i. A view of Conversations
2.6.1 Private (Internal) Business Processes

Private business processes are those internal to a specific organization. These processes have
been generally called workflow or BPM processes (see Figure 2.1). Another synonym typically
used in the Web services area is the Orchestration of services. There are two (2) types of private
Processes:
a. Executable
b. Non-executable.

An executable process is a process that has been modeled for the purpose of being executed
according to the semantics defined in Chapter 13 and 14 of the BPMN 2.0 standard. These will
be one of the most important usage patterns that are capable of being executed in Levi. Of
course, during the development cycle of the process, there will be stages where the process does
not have enough detail to be “executable.”
Figure 2.1 - Example of a private business process
A non-executable process on the other hand is a private process that has been modeled for the
purpose of documenting process behavior at a modeler-defined level of detail. Thus,
information needed for execution, such as formal condition expressions are typically not
included in a non-executable process.
If a swim lanes-like notation is used (e.g., a collaboration, see below) then a private business
process will be contained within a single pool. The process flow is therefore contained within
the pool and cannot cross the boundaries of the pool. The flow of messages can cross the pool
boundary to show the interactions that exist between separate private business processes.
2.6.2 Public Processes
Fig. 2.2 Example of a public process
A public process represents the interactions between a private business process and another
process or participant (see Figure 2.2). Only those activities that are used to communicate to the
other participant(s) are included in the public process. All other “internal” activities of the
private business process are not shown in the public process. Thus, the public process shows to
the outside world the message flows and the order of those message flows that are needed to
interact with that process. Public processes can be modeled separately or within a collaboration
to show the flow of messages between the public process activities and other participants. Note
that the public type of process was named “abstract” in BPMN 1.2.

2.6.3 Collaborations
Figure 2.3 - An example of a collaborative process
A Collaboration depicts the interactions between two or more business entities. A collaboration
usually contains two (2) or more pools, representing the participants in the collaboration. The
message exchange between the participants is shown by a message flow that connects two (2)
pools (or the objects within the pools). The messages associated with the message flows can
also be shown. The collaboration can be shown as two or more public processes communicating
with each other (see Figure 2.3). With a public process, the activities for the collaboration
participants can be considered the “touch-points” between the participants. The corresponding
internal (executable) processes are likely to have much more activity and detail than what is
shown in the public processes. Or a pool may be empty; “black box.” choreographies may be
shown “in between” the pools as they bisect the message flows between the pools. All
combinations of pools, processes, and choreography are allowed in a collaboration.
2.6.4 Choreographies
A self-contained choreography (no pools or orchestration) is a definition of the expected

behavior, basically a procedural contract, between interacting participants. While a normal
process exists within a pool, a choreography exists between pools (or participants).
The choreography looks similar to a private business process since it consists of a network of
activities, events, and gateways (see Figure 2.4). However, a choreography is different in that
the activities are interactions that represent a set (1 or more) of message exchanges, which
involves two (2) or more participants. In addition, unlike a normal process, there is no central
controller, responsible entity or observer of the process.

Figure 2.4 - An example of a choreography
2.6.5 Conversations
Figure 2.5 - An example of a Conversation diagram
The conversation diagram is a particular usage of and an informal description of a collaboration

diagram. However, the pools of a conversation usually do not contain a process and a
choreography is usually not placed in between the pools of a conversation diagram. A
conversation is the logical relation of message exchanges. The logical relation, in practice, often
concerns a business object(s) of interest, e.g., “Order,” “Shipment and Delivery,” or “Invoice.”

Message exchanges are related to each other and reflect distinct business scenarios. For
example, in logistics, stock replenishment involves the following type’s scenarios: creation of
sales orders; assignment of carriers for shipments combining different sales orders; crossing
customs/quarantine; processing payment and investigating exceptions. Thus, a conversation
diagram, as shown in Figure 2.5, shows conversations (as hexagons) between participants
(pools). This provides a “bird’s eye” perspective of the different conversations which relate to
the domain.
2.6.6 Diagram Point of View
Since a BPMN diagram may depict the processes of different participants, each participant could
view the diagram differently. That is, the participants have different points of view regarding
how the processes will apply to them. Some of the activities will be internal to the participant
(meaning performed by or under control of the participant) and other activities will be external
to the participant. Each participant will have a different perspective as to which are internal and
external. At run time, the difference between internal and external activities is important in how
a participant can view the status of the activities or trouble-shoot any problems. However, the
diagram itself remains the same.
Figure 2.3 displays a business process that has two points of view. One point of view is of a
Patient, the other is of the Doctor’s office. The diagram shows the activities of both participants
in the process, but when the process is actually being performed, each participant will only have
control over their own activities. Although the diagram point of view is important for a viewer
of the diagram to understand how the behavior of the process will relate to that viewer, BPMN
will not currently specify any graphical mechanisms to highlight the point of view. It is open to
the modeler or modeling tool vendor to provide any visual cues to emphasize this characteristic
of a diagram.
2.6.7 Understanding the Behavior of Diagrams

Throughout this document, we discuss how sequence flows are used within a process. To
facilitate this discussion, we employ the concept of a token that will traverse the sequence flows
and pass through the elements in the process. A token is a theoretical concept that is used as an
aid to define the behavior of a process that is being performed. The behavior of process
elements can be defined by describing how they interact with a token as it “traverses” the
structure of the process. However, modeling and execution tools that implement BPMN are not
required to implement any form of token.
A start event generates a token that must eventually be consumed at an end event (which may
be implicit if not graphically displayed). The path of tokens should be traceable through the
network of sequence flows, gateways, and activities within a process.
Note – A token does not traverse a message flow since it is a message that is passed down a
message flow (as the name implies).

3. SPECIFIC REQUIREMENTS
3.1 Use-case Report
The origin of BPMN was in the field of process descriptions that can be performed by the
process engine (such as Levi) of a workflow or business process management system (BPMS).
But by its design, BPMN is intended to make it possible to create technical as we as business-
level models. Hence, the type of non executable process models comes into the play. BPMN is
supposed to be a common language of both business experts and IT experts.
Furthermore, as it is mentioned in the BPMN 2.0 specification, an executable process is a
process that has been modeled for the purpose of being executed according to the semantics
defined in Chapter 14 of the specification. Of course, during the development cycle of the
process, there will be stages where the process does not have enough detail to be “executable.”
A non-executable process is a private process that has been modeled for the purpose of
documenting process behavior at a modeler-defined level of detail. Thus, information needed
for execution, such as formal condition expressions are typically not included in a non-
executable process.
Therefore, every BPMN 2.0 model need not be executable in an execution engine like Levi. As
long as a process model conforms to the Process Modeling Conformance class as defined in the
OMG specification BPMN 2.0, it is considered as a valid process model. Normally, for instance,
these non executable business processes fall in to the category of the models those focus on
organizational aspects of business processes.
In BPMN 2.0, we can use pools and message flows for explicitly modeling collaborations
between participants, and we can (de-)compose process models with sub-processes and call
activities. By using a pool, we can represent a process in a business. By using lanes within a pool,
we can represent different entities (different people, departments etc.) of the business involved
in the process. For example, in the following process model, the process "Post a Job" is
represented with a pool that consists of two lanes, namely, Business Department and Human
Resources. See Figure 3.1.
Figure 3.1- a simple business process
In the scenario, the business department and the human resources department are involved in
the process of “Post a Job”. The process starts when an employee is required. The business
department reports this job opening. Then the human resources department writes a job
posting. The business department reviews this job posting.
An important fact about this process model(and similar processes in general) is that we used
only one pool and different lanes for the departments involved in this process, which
automatically means that we blank out the communication between those departments: We just
assume that they are communicating with each other somehow. If we had Levi driving this
process, it would assign user tasks and therefore be responsible for the communication
between those two departments. If we do not use Levi, but want to model the communication
between the departments involved explicitly, we would have to use a collaboration diagram for
that purpose.
3.1.1 Use Case 1

Consider an e-tender (the "Purchaser" process) which sends a request for quote to multiple
service providers (e.g., warehouse storage) in a marketplace. The "Purchaser" Process sends out
requests to each service provider and anticipates their response through three Choreography
Activities. Figure 3.2 depicts this scenario modeled using BPMN 2.0.
Figure 3.2- the Purchaser process and its collaborations with other service provider processes
The responses of the three service providers merge at a single point in the process, called a
"Complex Gateway" to model the requirement that when 66% responses have arrived, an
assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the
assessment reports that the reserve amount indicated by the customer cannot be met, a new

iteration of the tender is made. A key issue is to ensure that the responses should not be mixed
across tender iterations. A Terminate End Event ensures that all Activities are terminated, when
a tender has been successful.
One can model the Purchaser process using a BPMN 2.0 modeling tool and execute it in Levi.
When modeling such processes, the person who models the process must consider all the
necessary interactions with external entities (e.g. the service requests that are sent to the
external service providers) and include them in the process definition appropriately, to make
the model executable. However, that level of modeling is not directly indicated with BPMN 2.0
diagrams, rather, that is a responsibility of the editing tool.
3.1.2 Use Case 2

If we imagine we are realizing a project for automating the incident management process, we
could decide which parts of it should be actually executed in a process engine, and which parts
should remain human-driven.
In this scenario we decided that the account manager should not be bothered with web forms or
task lists, he should just send an email if he wants to report a customer's problem, and receive
an email when the process has completed. See Figure 3.3.

Figure 3.3- Incident Management with human-driven and system-driven pools

The same idea applies for the software developer: Let us assume the 2nd level support agent
sits in the same room as the developers. Maybe it is more efficient if the support agent just
walks over to the developer and talks about the issue, rather than playing some time consuming
ping-pong-game with task assignments. Therefore, we want to keep this part of the incident
management human driven as well: no process engine driving the collaboration between 2nd
level support and software developers. But we do want the assignment of tickets to 1st and 2nd
level support agents by a trouble ticket system, which now takes the role of the process engine
and therefore is modeled in a dedicated pool. See Figure 3.3
Figure 3.4- This rather simple diagram is all we have to show to the account manager
That system can actually receive and parse emails sent by the account manager and opens a
ticket for it. If the 1st level support agent decides that this is a 2nd level issue, he does so by
documenting his decision and completing the assigned task “edit 1 st level ticket”. The trouble
ticket system then routes the ticket to the 2nd level support agent. When that agent has finished,
he may be declared the issue to be fixed in the next software release. Then the trouble ticket
system makes a service call on the product backlog system, a new feature we have introduced
with our process engine: The entry does not have to be inserted manually any more. In the end,
the trouble ticket system will send an email to the account manager, containing the results of
the incident management, and close the ticket. See Figure 3.4. The account manager can then
explain the solution to the customer based on the information in the ticket.

Figure 3.5- This is the only part of the whole collaboration we will execute in Levi
As mentioned previously, we can hand over the modeled process engine pool (i.e. "Trouble
Ticket System") to Levi for execution, while we can show the other pools separately to our
process participants, the support agents or the account manager, and discuss their involvement
in the collaboration based on those simplified views on the same, consistent collaboration
model. This gives us the opportunity to talk with both Business people and IT people about the
same process model, without overburdening business people with too complex diagrams or IT
people with too inaccurate process models.
3.2 Process Execution Conformance Requirements

To be completely compliance with the BPMN 2.0 Process Execution Conformance, the Levi
Engine
a. MUST fully support and interpret the operational semantics and Activity life-cycle
specified in Section 14.2.2 of the BPMN 2.0 Beta 2 specification.
b. MUST support import of BPMN Process diagram types including its definitional
Collaboration as specified in Table 10.1 of the specification.
c. MUST fully support and interpret the underlying metamodel.
d. Non-operational elements listed in Section 14 of the specification MAY be ignored by
Levi Engine.
e. Is not expected to support and interpret Choreography models and support Process
Modeling Conformance.
f. Is not required to support graphical syntax and semantics defined in this
specification. It MAY use different graphical elements, shapes and markers, then
those defined in this specification.
The following elements are nonoperational, in the context of BPMN 2.0 specification, which MAY
be ignored by the Levi Engine. Elements for which only a conceptual model is provided and the
details needed to execute them are not specified, are called non-operational elements.
a. Manual Task
b. Abstract Task
c. DataState
d. IORules
e. Ad-Hoc Process
f. ItemDefinitions with an itemKind of Physical
g. the inputSetWithWhileExecuting attribute of DataInput
h. the outputSetWithWhileExecuting attribute of DataOutput
The Levi Engine should follow the execution semantics stated below to be compliant with the
BPMN 2.0 Process Execution Conformance.
3.2.1 Process Instantiation and Termination
3.2.1.1 Process Instantiation

A Process instance can be instantiated in any of the following ways:
a. When one of its Start Events occurs. A new Process instance is only created if there is no
already existing process for the particular conversation the start event belongs to
b. Via an Event-Based Gateway or a Receive Task that has no incoming Sequence Flows
and its instantiate flag set to true
Each Start Event that occurs creates a token on its outgoing Sequence Flows, which is followed
as described by the semantics of the other Process elements.
3.2.1.2 Process Termination

A Process instance is completed, if and only if the following three conditions hold:
a. If the instance was created through an instantiating Parallel Gateway, then all
subsequent Events (of that Gateway) MUST have occurred.
b. There is no token remaining within the Process instance.
c. No Activity of the Process is still active.
For a Process instance to become completed, all tokens in that instance MUST reach an end node
(i.e. the node without outgoing Sequence Flows).
3.2.2 Activities
3.2.2.1 Sequence Flow Considerations

a. If an Activity has no incoming Sequence Flows, the Activity will be instantiated when the
containing Process or Sub-Process is instantiated. Exceptions to this are Compensation
Activities, as they have specialized instantiation behavior.
b. Activities can also be source of Sequence Flows. If an Activity has multiple outgoing
Sequence Flows, all of them will receive a token when the Activity transitions to the
Completed state. Thus, multiple outgoing Sequence Flows behaves as a parallel split.
c. Multiple outgoing Sequence Flows with conditions behaves as an inclusive split. A mix of
multiple outgoing Sequence Flows with and without conditions is considered as a
combination of a parallel and an inclusive split as shown in the figure below.
d. If the Activity has no outgoing Sequence Flows, the Activity will terminate without
producing any tokens and termination semantics for the container is then applied.
Figure 3.6 - Multiple outgoing Sequence Flows

3.2.2.2 Activity
The Lifecycle of a BPMN Activity is shown in the figure below. The description is specified in
Section 13.2.2 of the BPMN 2.0 specification.
Figure 3.7 - The Lifecycle of a BPMN Activity

3.2.2.3 Task
Task execution and completion for the different Task types are as follows:
a. Service Task: Upon activation, the data in the inMessage of the Operation is assigned
from the data in the Data Input of the Service Task the Operation is invoked. On
completion of the service, the data in the Data Output of the Service Task is assigned
from the data in the outMessage of the Operation, and the Service Task completes. If the
invoked service returns a fault, that fault is treated as interrupting error, and the
Activity fails.
b. Send Task: Upon activation, the data in the associated Message is assigned from the data
in the Data Input of the Send Task. The Message is sent and the Send Task completes.
c. Receive Task: Upon activation, the Receive Task begins waiting for the associated
Message. When the Message arrives, the data in the Data Output of the Receive Task is
assigned from the data in the Message, and Receive Task completes. For key-based
correlation, only a single receive for a given CorrelationKey can be active, and thus the
Message matches at most one Process instance. For predicate-based correlation, the
Message can be passed to multiple Receive Tasks. If the Receive Task’s instantiate
attribute is set to true, the Receive Task itself can start a new Process instance.
d. User Task: Upon activation, the User Task is distributed to the assigned person or group
of people. When the work has been done, the User Task completes.
e. Manual Task: Upon activation, the manual task is distributed to the assigned person or
group of people. When the work has been done, the Manual Task completes. This is a
conceptual model only; a Manual Task is never actually executed by an IT system.
f. Business Rule Task: Upon activation, the associated business rule is called. On
completion of the business rule, the Business Rule Task completes.
g. Script Task: Upon activation, the associated script is invoked. On completion of the
script, the Script Task completes.
h. Abstract Task: Upon activation, the Abstract Task completes. This is a conceptual model
only; an Abstract Task is never actually executed by an IT system.
3.2.2.4 Sub-Process / Call Activity

A Sub-Process is an Activity which encapsulates a Process which is in turn modeled by
Activities, Gateways, Events, and Sequence Flows. Once a Sub-Process is instantiated, its
elements behave as in a normal Process.
3.2.2.5 Ad-Hoc Sub-Process

An Ad-Hoc Sub-Process or Process contains a number of embedded inner Activities and is
intended to be executed with a more flexible ordering compared to the typical routing of
Processes. Unlike regular Processes, it does not contain a complete, structured BPMN diagram
description—i.e., from Start Event to End Event. Instead the Ad-Hoc Sub-Process contains only
Activities, Sequence Flows, Gateways, and Intermediate Events.
Operational semantics of Ad-Hoc Sub-Process is specified in the Section 13.2.5 of the BPMN 2.0
specification.
3.2.2.6 Loop Activity

The Loop Activity is a type of Activity that acts as a wrapper for an inner Activity that can be
executed multiple times in sequence.

Operational semantics of Loop Activity is specified in the Section 13.2.6 of the BPMN 2.0
specification.
3.2.2.7 Multiple Instances Activity

The multi-instance (MI) Activity is a type of Activity that acts as a wrapper for an Activity which
has multiple instances spawned in parallel or sequentially.
Operational semantics of Multiple Instances Activity is specified in the Section 13.2.7 of the
BPMN 2.0 specification.
3.2.3 Gateways
3.2.3.1 Parallel Gateway (Fork and Join)

On the one hand, the Parallel Gateway is used to synchronize multiple concurrent branches
merging behavior). On the other hand, it is used to spawn new concurrent threads on parallel
branches (branching behavior).
Figure 3.8 – The Parallel Gateway
Operational Semantics of Parallel Gateway is specified in Table 13.1, of the section 13.3.1 of the
3.2.3.2 Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)

The Exclusive Gateway has pass-through semantics for a set of incoming branches (merging
behavior). Further, each activations leads to the activation of exactly one out of the set of
outgoing branches (branching behavior).
Figure 3.9 - The Exclusive Gateway
Operational Semantics of Exclusive Gateway is specified in Table 13.2, of the section 13.3.2 of
the BPMN 2.0 specification.

3.2.3.3 Inclusive Gateway (Inclusive Decision and Inclusive Merge)
The Inclusive Gateway synchronizes a certain subset of branches out of the set of concurrent
incoming branches (merging behavior). Further on, each firing leads to the creation of threads
on a certain subset out of the set of outgoing branches (branching behavior).
Figure 3.10 - The Inclusive Gateway
Operational Semantics of Inclusive Gateway is specified in Table 13.3, of the section 13.3.3 of the
3.2.3.4 Event-based Gateway (Exclusive Decision (event-based))

The Event-Based Gateway has pass-through semantics for a set of incoming branches (merging
behavior). Exactly one of the outgoing branches is activated afterwards (branching behavior),
depending on which of Events of the Gateway configuration is first triggered. The choice of the
branch to be taken is deferred until one of the subsequent Tasks or Events completes. The first
to complete causes all other branches to be withdrawn.
When used at the Process start as a Parallel Event Gateway, only message-based triggers are
allowed. The Message triggers that are part of the Gateway configuration MUST be part of a
Conversation with the same correlation information. After the first trigger instantiates the
Process, the remaining Message triggers will be a part of the Process instance that is already
active (rather than creating new Process instances).
Figure 3.11 - The Event-Based Gateway
Operational Semantics of Event-based Gateway is specified in Table 13.4, of the section 13.3.4 of
the BPMN 2.0 specification.

3.2.3.5 Complex Gateway (related to Complex Condition and Complex Merge)
The Complex Gateway facilitates the specification of complex synchronization behavior, in
particular race situations. Details are specified in the Table 13.5 and Section 13.3.5 of the BPMN
2.0 specification.
Figure 3.12 - The Complex Gateway
3.2.4 Events
3.2.4.1 Start Events

a. For single Start Events, a new Process instance each time the Event occurs. Sequence
Flows leaving the Event are then followed as usual.
b. If the Start Event participates in a Conversation that includes other Start Events, a new
Process instance is only created if none already exists for the specific Conversation of
the Event occurrence.
3.2.4.2 Intermediate Events

a. For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting
starts when the Intermediate Event is reached. Once the Event occurs, it is consumed.
3.2.4.3 Intermediate Boundary Events

a. For boundary Events, handling first consists of consuming the Event occurrence. If the
cancelActivity attribute is set, the Activity the Event is attached to is then cancelled; if
the attribute is not set, the Activity continues execution. Execution then follows the
Sequence Flow connected to the boundary Event.
3.2.4.4 Event Sub-Processes

a. Event Sub-Processes allow handling an Event within the context of a given Sub-
Processes or Process. An Event Sub-Process always begins with a Start Event, followed
by Sequence Flows.
b. An Event Sub-Process cancels execution of the enclosing Sub-Process, if the
isInterrupting attribute of its Start Event is set; for a multi-instance Activity this cancels
only the affected instance. If the isInterrupting attribute is not set, execution of the
enclosing Sub-Process continues in parallel to the Event Sub-Process.
c. An Event Sub-Process can optionally retrigger the Event through which it was triggered,
to cause its continuation outside the boundary of the associated Sub-Process. In that
case the Event Sub-Process is performed when the Event occurs; then control passes to
the boundary Event, possibly canceling the Sub-Process

Operational semantics of Event Sub-Processes is specified in Section 13.4.4 of the BPMN 2.0
specification.
3.2.4.5 Compensation Event

Compensation is concerned with undoing steps that were already successfully completed,
because their results and possibly side effects are no longer desired and need to be reversed. If
an Activity is still active, it cannot be compensated, but rather needs to be canceled. Cancellation
in turn can result in compensation of already successfully completed portions of an active
Activity, in case of a Sub-Process.
Compensation Event can be a Sub-Process (for a Sub-Process or Process) or an associated
Compensation Activity (for any Activity). A compensation handler performs the steps necessary
to reverse the effects of an Activity. In case of a Sub-Process, its Compensation Event Sub-
Process has access to Sub-Process data at the time of its completion (“snapshot data”).
Compensation is triggered by a throw Compensation Event, which typically will be raised by an
error handler, as part of cancellation, or recursively by another compensation handler. That
Event specifies the Activity for which compensation is to be performed, either explicitly or
implicitly.
Operational Semantics for Compensation Event is specified in Section 13.4.5 of the BPMN 2.0
specification.
3.2.4.6 End Events
3.2.4.6.1 Process level end events

a. For a “terminate” End Event, the Process is abnormally terminated—no other ongoing
Process instances are affected.
b. For all other End Events, the behavior associated with the Event type is performed.
3.2.4.6.2 Sub-process level end events

a. For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a
multi-instance Sub-Process, only the affected instance is terminated—no other ongoing
Sub-Process instances or higher-level Sub-Process or Process instances are affected.
b. For a “cancel” End Event, the Sub-Process is abnormally terminated and the associated
transaction is aborted. Control leaves the Sub-Process through a cancel intermediate
boundary Event.
c. For all other End Events, the behavior associated with the Event type is performed.
3.3 Non-functional Requirements

In addition to fulfilling functional requirements, a system is supposed to work and perform
under additional constraints and conditions which make the application useful for real world
use cases. Levi is no exception to this rule. Since this application is involved with web services
and distributed computing areas several concerns which are typical to web services domain
have to be considered of.
3.3.1 Usability
a. Since we target business analysts to use Levi, it does not need a specific technical
knowledge to use it. But the user must have a thorough knowledge on business process
modeling and have to have a good understanding of the BPMN 2.0 notation.
b. For a normal business analyst who is not familiar with BPMN 2.0 may take some time to
learn BPMN 2.0 to use this. But if the user have a good understanding then he can use
this straight forwardly.
c. Under the project scope we will cover the execution of the modeled business process. So
the users can use any of the BPMN 2.0 modeling tool to model a process and use Levi to
do the execution.
3.3.2 Reliability
This should be very reliable system because a single error in this can be causes pretty much
damage to the user enterprise. There are some reliability facts we need to care about as detailed
below.
3.3.2.1 Error handling

It is highly necessary to have an error handling mechanism because occurrence of a single error
can made the whole process a mess. So it is needed to have an error handling system which
cares about all the possible errors.
If error occurred within the process which is not acceptable in the process it need to be undoing
steps that were already successfully completed, because their results and possibly side effects
are no longer desired and need to be reversed. This process is called as compensation.
Also we care about when to compensate, because if an Activity is still active, it cannot be
compensated, but rather needs to be canceled. Cancellation in turn may result in compensation
of already successfully completed portions of an active Activity, in case of a Sub-Process.
Compensation is triggered by a throw Compensation Event, which typically will be raised by an
error handler, as part of cancellation, or recursively by another compensation handler. That
Event specifies the Activity for which compensation is to be performed, either explicitly or
implicitly. Compensation is performed by a compensation handler.
3.3.2.1.1 Compensation handler

Compensation handler is a set of Activities that are not connected to other portions of the BPMN
2.0 model. A compensation handler performs the steps necessary to reverse the effects of an
Activity. In case of a Sub-Process, its Compensation Event Sub-Process has access to Sub-Process
data at the time of its completion. There are two types of compensation handler,
a. Compensation Event Sub-Process (for a Sub-Process or Process)
Compensation Event Sub-Process is contained within a Process or a Sub-Process and can
access data that is part of its parent, snapshot at the point in time when its parent has
completed. Also this can in particular recursively trigger compensation for Activities
contained in that its parent.
b. Compensation Activity (for any Activity)
Compensation Activity can be done only by boundary Event and in this is perform a
"black-box" compensation of the original Activity. Here are some of the Operational
Semantics that Compensation handler need to comply with, as in the BPMN 2.0 Spec.
3.3.2.1.2 Operational Semantics

a. A Compensation Event Sub-Process becomes enabled when its parent Activity
transitions into state Completed. At that time, a snapshot of the data associated with the
parent Activity is taken and kept for later usage by the Compensation Event Sub-

Process. In case the parent Activity is a multi-instance or loop, for each instance a
separate data snapshot is taken, which is used when its associated Compensation Event
Sub-Process is triggered.
b. When compensation is triggered for the parent Activity, its Compensation Event Sub-
Process is activated and runs. The original context data of the parent Activity is restored
from the data snapshot. In case the parent Activity is a multi-instance or loop, for each
instance the dedicated snapshot is restored and a dedicated Compensation Event Sub-
Process is activated.
c. An associated Compensation Activity becomes enabled when the Activity it is associated
with transitions into state Completed. When compensation is triggered for that Activity,
the associated Compensation Activity is activated. In case the Activity is a multi-instance
or loop, the Compensation Activity is triggered only once, too, and thus has to
compensate the effects of all instances.
d. Default compensation ensures that Compensation Activities are performed in reverse
order of the execution of the original Activities, allowing for concurrency when there
was no dependency between the original Activities. Dependencies between original
Activities that default compensation must consider are the following
e. A Sequence Flow between Activities A and B results in compensation of B to be
performed before compensation of A.
f. A data dependency between Activities A and B, e.g., through an IORules specification in B
referring to data produced by A, results in compensation of B to be performed before
compensation of A.
g. If A and B are two Activities that were active as part of an Ad-Hoc Sub-Process, then
compensation of B must be performed before compensation of A if A completed before B
started.
h. Instances of a loop or sequential multi-instance are compensated in reverse order of
their forward completion. Instances of a parallel multi-instance can be compensated in
parallel.
i. If a Sub-Process A has a boundary Event connected to Activity B, then compensation of B
must be performed before compensation of A if that particular Event occurred. This also
applies to multi-instances and loops.
3.3.3 Performance Requirements

Performance of the Levi Engine will rely on how the input model is converted into an object
model; the object model is mapped with BPMN 2.0 constructs and then how the navigation and
execution of the process happens. Since external web service invocations will take place when
executing the business processes, performance of such web service invocations also will
attribute to the performance of the Levi Engine.
Execution time is the major performance attribute of a BPMN engine like Levi. It is always
desired to minimize the execution time in order to achieve high performance. The XSD of the
input process model is to be converted to Java Object model using XML Beans. This conversion
should be real time, using minimum possible amount of time and resources. The model is

persisted for future usage and hence the persistence mechanism should be efficient. Mapping
with BPMN 2.0 constructs and then the event generation should be performed utilizing least
amount of resources and avoiding delays.
3.3.4 Supportability
Currently the BPMN 2.0 specification is in its beta 2 version. The OMG (Object Management
Group) and BPMI (Business Process Management Initiative) are leading the effort of finalizing
the specification of BPMN 2.0. The Levi Engine will be implemented based on the latest possible
version of the specification available at the period of implementation and will get updated to the
final version of BPMN 2.0 when it is available. Also it is expected that the Levi Engine will
support the additions to the BPMN 2.0 specification in the future and provide supportability in
the long run. The goal is to provide the users of Levi Engine with up to date support of the
specification.
3.3.5 Design Constraints

There is some design constraints identified, which might affect the implementation of Levi
Engine, such as the following:
a. Not all activities of a business process can be modeled and executed
Real world business processes in an enterprise might have a wider scope including
processes which need physical actions or activities of the employees. But only part of
these processes can be implemented using an automated system like Levi Engine.
Therefore it is a constraint that only the executable part of a business process can be
automated using the Levi Engine
b. Only a subset of the executable BPMN 2.0 constructs will be implemented in the Levi
Engine
Since this project serves as a proof of concept for implementing a BPMN 2.0 engine
based on Apache ODE, only the basic subset of the BPMN 2.0 constructs are expected to
be implemented in the initial versions of the Levi Engine. The subset to be implemented
is yet to be decided at the completion of the literature survey. We are planning to
implement small subsets of the BPMN 2.0 constructs during each iterations of the
implementation phase and finally the complete set of constructs in the future versions.
3.3.6 On-line User Documentation and Help System Requirements

3.3.6.1 Documentation
Since the users are considered as having considerable experience in the domain of business
process modeling, the users will not be treated as novice computer users. But instructions on
setting up the environment, installing and configuration of the project will be provided.
For all the BPMN constructs that will be implemented there will be online guides demonstrating
each feature in a sample scenario, for users to get a thorough understanding of each stage of
process model execution, starting from deployment, configuration and status monitoring. An
online wiki will be maintained for users to add tutorials, articles, help guides on BPMN and LEVI
project, as support for new BPMN constructs and other features are been added to the system.

3.3.6.2 Web site / Blog
Primarily we are hoping to use this as a centralized, one-way conduit of information from the
project out to the public. The web site will also serve as an administrative interface for other
project tools. But at a minimum, the project will offer one RSS feed on the front page off website,
for sending out major announcements such as releases and security alerts.
Furthermore, web site will provide a development status page, listing the project's near-term
goals and needs, a history of past releases, with feature lists, so visitors can get an idea of how
the project defines "progress" and how quickly it makes progress according to that definition.
So the people will be able to know how the project is doing. In the initial stage, they will be able
to know the gap between the project's promise and current reality. Later in a mature stage, they
will be able to know how actively it is maintained, how often it puts out new releases, how
responsive it is likely to be to bug reports, etc.
3.3.6.3 Mailing lists

Separate user and developer forums will be maintained using open source tools for list
management and archiving. Usually this will be the most active communications channel in the
project, and the "medium of record."
3.3.6.4 Version control & Source Code

Since this project is based on open source methodology the software will be downloadable as
source code in standard formats.
We will use git and gitHub (https://github.com/), a combination of technologies and practices
for tracking and controlling changes to project Levi's files, in particular to source code,
documentation, and web pages. This will enable developers to manage code changes
conveniently, including reverting and "change porting". It will help everyone to watch what's
happening to the code.
3.3.6.5 Issue tracking

The issue tracking system also will be maintained in GitHub for users and developers to report
software bugs, enhancement requests, documentation changes, and pending tasks.
It will enable developers to keep track of what they're working on, coordinate with each other,
and plan releases, and furthermore enable everyone to query the status of bugs and record
information (e.g., reproduction recipes) about particular bugs.
3.3.6.6 Real-time chat

Many projects offer real-time chat rooms using Internet Relay Chat (IRC), forums where users
and developers can ask each other questions and get instant responses. So Project Levi will also
be maintaining the IRC channel ##levi at Freenode (http: //freenode.net/) functioning as a
place for quick, lightweight discussions and question/answer exchanges. We will always try to
archive these completely, within infrastructure, privacy and other constraints.

3.3.6.7 Features and Requirements List
There will be a brief list of the features the software supports (if something isn't completed yet,
it will still be listed, but we will put "planned" or "in progress" next to it), and the kind of
computing environment required to run the software.
3.3.7 Reusing Components
3.3.7.1 JACOB
Apache ODE’s JACOB framework is developed to implement the BPEL constructs and this
framework provides the mechanism necessary to deal with two key issues in implementing
BPEL constructs like Persistence of execution state and Concurrency. Because of these key
issues also applied in implementing BPMN 2.0 constructs we can use Apache ODE’s JACOB
framework directly for the implementation.
3.3.7.2 WSO2 User Management Component

In a typical business process, various tasks are assigned to different entities of the business (i.e
the entities involved in the process. e.g. human users, departments, etc.) and when the process
progresses through its execution, each of these tasks must be completed properly and once each
of these tasks gets completed, the process must be make known about that. At the
implementation level, Levi handles this by using external signals. Once a completion signal
receives, Levi continues execution to the next level in the process. If the process involves human
users, user management becomes a major requirement that Levi needs to address. For this
purpose, Levi uses the WSO2 Identity Server’s user management component in order to fulfill
the requirements such as user profiles, roles assignments and permissions.
3.3.8 Interfaces
3.3.8.1 User Interfaces

Users will be provided with a set of Web User Interfaces to interact with Levi. First of all we
assume business managers will use a BPMN 2.0 compliant modeling tool and come up with an
executable Business Process. Then he can deploy that process in the engine using Levi web UI. It
will provide him with feedback on whether the deployment was successful or not. Furthermore
these administrators will be able Configure, Manage and Monitor the already deployed
processes using this UI.

Figure 3.13 - Sample Web User Interface for deploying a BPMN process
Potential participants of a workflow, e.g.: Management Executives in a certain department of the

organizations, will get to see tasks in his domain and will be able assign it to himself, mark it as
completed etc. There will be more functionality available for him such as monitoring ongoing /
completed tasks and exploring different lanes of execution etc.
Although these sample instances cover most of the scenarios that will arise in this proof-of-
concept engine, more UIs will have to be designed in the next stages of implementation of the
project, as and when it is necessary to demonstrate certain functionality and interact with the
engine

Figure 3.14 - Sample Web User Interface for a user to manage his tasks assigned by
the Process Execution Engine
3.3.8.2 Hardware Interfaces

The system does not directly depend on a specific hardware interface other than on a working
network interface. Even the network interface is utilized by the internal components of ODE , at
the end, the entire system runs on top of the Java Runtime Environment abstracting out all the
hardware dependent details from the system.
3.3.8.3 Software Interfaces

Following are the software interfaces that will be used for the implementation of Levi Engine:
Eventhough Levi runs on Java Virtual Machine (JVM) it won't map BPMN workflow to Java, and
instead it will use JACOB, and will make use of interfaces in that framework for transaction and
concurrency.
For maintaining persistence, Levi will use DAO pattern, implemented using OpenJPA
(supporting then any database with transactional support and BLOB data types), and we can
replace this with other persistence mechanism as and when it is needed. Currently it is
suggested to use MySQL or anyother relational database as our data persistence interface.
Since BPMN 2.0 XSD makes heavy use of inheritance, the parser must be capable to understand
xsi:type attributes. So to overcome this XMLBeans interface will be used to generate a Java
Object model from the process model's XSD. Then this model will be used as OModel and
XMLBeans as a parser.
Reusable WSO2 carbon components such as User Management Component and front-end UI
bundles will function as interfaces for basic user management, authentication and reporting.

It will run in a servlet container or a JBI container, and not standalone. For this, it will use an
integration API, that has two implementations, the AXIS2 Integration (for servlet container), and
JBI Integration (for JBI container).
Furthermore it will use Apache ODE's existing interfaces like Rampart for ensuring WS-Security,
WS-Reliable Messaging, WS-Addressing and WS-Eventing. Apache Log4j, Abdera, Xerces, Maven
and some other java-based utilities will be used for providing interfaces for logging, publishing
feeds, manipulating XML and build automation.
3.3.8.4 Communications Interfaces

Primarily, the HTTP and HTTPS protocols will be used in Levi to facilitate communications
between the execution engine and external web services. Together with WSDLs and XML
Schema, SOAP will provide the mechanism for exchanging XML-based messages between them
and requesting information from endpoints.
It will have an API for users to handle deployed BPMN process and running instances. Main
interfaces will be ProcessManagement and InstanceManagement. In the first working prototype
it is planned to use Axis 2 (via AXIS2 Integration Layer), and get those interfaces published as
Web Services. And in the future it is planned to support JBI, with the same WSDL interfaces
provided as native JBI endpoints.
Furthermore for demonstration purposes, this API will be exposed via a Web UI as described in
User Interfaces section, to have interactions through a web browser.
3.3.9 Licensing Requirements

Project Levi will be licensed under the Apache License, one of the most liberal and business
friendly OSI-approved licenses available. Because of the Apache License, anyone can use or
modify Levi without any repercussions for the redistribution of changes. This will be a critical
point for many businesses that will use Levi in a strategic manner.
As developers of Project Levi, we will not mind it if a commercial company used our software in
their products. We don’t expect them to open source their software (which would be necessary
if we will release this software under GPL license), but we would like them to give us credit in
their documentation. This is precisely what the Apache license does.
The Apache license basically says that you can use and modify the software as long as you
include an appropriate attribution in the documentation that is distributed as part of the
software. For a comprehensive description of this license and what it covers, please refer
Appendix A
3.3.10 Legal, Copyright, and Other Notices

As it is made required by the Apache Software License, following two files will be there at the
root of every source code directory.
a. LICENSE - A file required by legal purposes; will contain the licenses of all
libraries used by Levi
b. NOTICE - Another required file for legal purposes; it contains copyright
information of all libraries used by Levi
The following notice, with the fields enclosed by brackets "[]" replaced with our projets
identifying information will be added to every source file, enclosed in the appropriate comment
syntax for the file format. A file or class name and description of purpose will be included on the
same "printed page" as the copyright notice for easier identification within third-party archives.

Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0. Unless required by applicable law or agreed to
in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the
specific language governing permissions and limitations under the License.
3.3.11 Applicable Standards

The ISO/IEC 6592 guidelines for the documentation of computer based application systems will
be followed.

4. SUPPORTING INFORMATION
4.1 Definitions, Acronyms, and Abbreviations
BPMN 2.0 : Business Process Model and Notation version 2.0 beta
BPDM : Business Process Definition Metamodel
BPEL : Business Process Execution Language
BPEL4People : WS-BPEL Extension for People
BPM : Business Process Modeling
UML : Unified Modelling Language
RDF : RDF Vocabulary Description Language 1.0
SOAP 1.2 : Simple Object Access Protocol
UDDI : Universal Description, Discovery and Integration
URI : Uniform Resource Identifiers
WSBPEL : Web Services Business Process Execution Language
WSDL : Web Services Description Language
XML : eXtensible Markup Language
XPath : XML Path Language
XSD : XML Schema Definition
4.2 References
[1] T. Allweyer, BPMN 2.0 - Business Process Model And Notation, BoD, 2010.
[2] M. Havey, Essential business process modeling, O'Reilly Media, Inc., 2005.
[3] Business Process Model And Notation (BPMN) Specification, Version 2.0 - Beta 2, May 2010
http://www.omg.org/spec/BPMN/2.0/
[4] OMG Group, “BPMN 2.0 by Example,” OMG Group, vol. 0, May 2010.
http://www.omg.org/spec/BPMN/2.0/examples/PDF
[5] Bruce Silver. “BPMN 2.0 Status Update”, blog, 5 Oct. 2010,
http://www.brsilver.com/2009/07/06/bpmn-20-status-update-2/
[6] BPEL 2.0 Standard , 5 Oct. 2010, http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
[7] OASIS , 5 Oct. 2010, http://www.oasis-open.org
[8] BPM FAQs , 5 Oct. 2010, http://www.bpmodeling.com/faq
[9] ODE-793 , 5 Oct. 2010, https://issues.apache.org/jira/browse/ODE-793
[10] ODE-794 , 5 Oct. 2010, https://issues.apache.org/jira/browse/ODE-794
[11]Process Modeling Notations and Workflow Patterns, paper by Stephen A. White of IBM
Corporation (2006) http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf
[12] Decker, G., Kopp, O., Leymann, F., Weske, M.: BPEL4Chor: Extending BPEL for modeling
choreographies. In: ICWS 2007, IEEE Computer Society (July 2007)

[13] Wohed, P., WMP van der Aalst, M. Dumas, AHM ter Hofstede, and N. Russell: On the
Suitability of BPMN for Business Process Modelling. Technical report, Queensland University of
Technology (QUT), http://www.bpm.fit.qut.edu.au/projects/babel/docs/BPMN-eval-
BPM06.pdf, 2006.
[14] Russell, N.: Workflow Resource Patterns. Beta, Research School for Operations Management
and Logistics, 2005.
[15] Russell, N., W.M.P. van der Aalst, A.H.M. ter Hofstede, and D. Edmond: Workflow Resource
Patterns: Identification, Representation and Tool Support. Proceedings of the 17th Conference on
Advanced Information Systems Engineering (CAiSE 05), 3520:216–232.
[16] Kloppmann, M., D. Koenig, F. Leymann, G. Pfau, A. Rickayzen, C. von Riegen, P. Schmidt, and
I. Trickovic: WS-BPEL Extension for People– BPEL4People. Joint white paper, IBM and SAP, July,
2005.
[17] Wohed, P., WMP van der Aalst, M. Dumas, AHM ter Hofstede, and N. Russell: Pattern-based
Analysis of BPMN-An extensive evaluation of the Control-flow, the Data and the Resource
Perspectives. BPM Center Report BPM-05-26, BPMcenter. Org, 2005.
[18] Aalst, WMP van der and A. Kumar: A reference model for team-enabled workflow
management systems. Data & Knowledge Engineering, 38(3):335– 363, 2001.

APPENDIX A
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction, and distribution as
defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is
granting the License.
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are
controlled by, or are under common control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the direction or management of such
entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by
this License.
"Source" form shall mean the preferred form for making modifications, including but not
limited to software source code, documentation source, and configuration files.
"Object" form shall mean any form resulting from mechanical transformation or translation of a
Source form, including but not limited to compiled object code, generated documentation, and
conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or Object form, made available
under the License, as indicated by a copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or
derived from) the Work and for which the editorial revisions, annotations, elaborations, or
other modifications represent, as a whole, an original work of authorship. For the purposes of
this License, Derivative Works shall not include works that remain separable from, or merely
link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work
and any modifications or additions to that Work or Derivative Works thereof, that is
intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an
individual or Legal Entity authorized to submit on behalf of the copyright owner. For the
purposes of this definition, "submitted" means any form of electronic, verbal, or written
communication sent to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems, and issue tracking
systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and
improving the Work, but excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a
Contribution has been received by Licensor and subsequently incorporated within the Work.
Levi | System Requirements Specification vi

2. Grant of Copyright License. Subject to the terms and conditions of this License, each
Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-
free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display,
publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or
Object form.
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor
hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made, use, offer to sell, sell,
import, and otherwise transfer the Work, where such license applies only to those patent claims
licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or
by combination of their Contribution(s) with the Work to which such Contribution(s) was
submitted. If You institute patent litigation against any entity (including a cross-claim or
counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the
Work constitutes direct or contributory patent infringement, then any patent licenses granted
to You under this License for that Work shall terminate as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works
thereof in any medium, with or without modifications, and in Source or Object form, provided
that You meet the following conditions:
(a) You must give any other recipients of the Work or Derivative Works a copy of this
License; and
(b) You must cause any modified files to carry prominent notices stating that You changed
the files; and
(c) You must retain, in the Source form of any Derivative Works that You distribute, all
copyright, patent, trademark, and attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative
Works that You distribute must include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not pertain to any part of the
Derivative Works, in at least one of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or documentation, if provided along
with the Derivative Works; or, within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents of the NOTICE file are for
informational purposes only and do not modify the License. You may add Your own
attribution notices within Derivative Works that You distribute, alongside or as an
addendum to the NOTICE text from the Work, provided that such additional attribution
notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional
or different license terms and conditions for use, reproduction, or distribution of Your
modifications, or for any such Derivative Works as a whole, provided Your use, reproduction,
and distribution of the Work otherwise complies with the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution

intentionally submitted for inclusion in the Work by You to the Licensor shall be under the
terms and conditions of this License, without any additional terms or conditions.
Levi | System Requirements Specification vii

Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate
license agreement you may have executed with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade names, trademarks,
service marks, or product names of the Licensor, except as required for reasonable and
customary use in describing the origin of the Work and reproducing the content of the NOTICE
file.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor

provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including,
without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT,
MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for
determining the appropriateness of using or redistributing the Work and assume any risks
associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including
negligence), contract, or otherwise, unless required by applicable law (such as deliberate and
grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for
damages, including any direct, indirect, special, incidental, or consequential damages of any
character arising as a result of this License or out of the use or inability to use the Work
(including but not limited to damages for loss of goodwill, work stoppage, computer failure or
malfunction, or any and all other commercial damages or losses), even if such Contributor has
been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative

Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty,
indemnity, or other liability obligations and/or rights consistent with this License. However, in
accepting such obligations, You may act only on Your own behalf and on Your sole
responsibility, not on behalf of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability incurred by, or claims asserted
against, such Contributor by reason of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
Levi | System Requirements Specification viii

Levi - SRS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Levi - SRS

Transféré par

Droits d'auteur :

Formats disponibles

SYSTEM REQUIREMENTS SPECIFICATION

Levi – the Native BPMN 2.0 Execution Engine

 Ms. Vishaka Nanayakkara

 Dr. Sanjiva Weerawarana

 Mr. Milinda Pathirage

Index No Name E-mail

070206B Ishan Jayawardena udeshike@gmail.com

070138R Keheliya Gallaba keheliya.gallaba@gmail.com

060501P Umashanthi Pavalanathan umashanthip@gmail.com

Levi | System Requirement Specification i

Date Version Description Authors

Levi | System Requirement Specification ii

1. Introduction ………… ................................................................................................................................................. 1

Levi | System Requirement Specification iii

Levi | System Requirement Specification iv

Figure No Description Page No

2.1 Example of a private business process ......................................................................................... 4

Levi | System Requirement Specification v

1.3 Target Audience

1.4 Document Overview

Levi | System Requirements Specification 1

2.2 Product Functions

2.3 User Classes and Characteristics

2.4 Issues and Constraints

Levi | System Requirements Specification 2

2.5 Assumptions and Dependencies

2.6 Usage Patterns of BPMN

2.6.1 Private (Internal) Business Processes

Levi | System Requirements Specification 3

Figure 2.1 - Example of a private business process

2.6.2 Public Processes

Fig. 2.2 Example of a public process

Levi | System Requirements Specification 4

Figure 2.3 - An example of a collaborative process

A self-contained choreography (no pools or orchestration) is a definition of the expected

Levi | System Requirements Specification 5

Figure 2.5 - An example of a Conversation diagram

The conversation diagram is a particular usage of and an informal description of a collaboration

Levi | System Requirements Specification 6

2.6.6 Diagram Point of View

2.6.7 Understanding the Behavior of Diagrams

Levi | System Requirements Specification 7

Figure 3.1- a simple business process

3.1.1 Use Case 1

Levi | System Requirements Specification 9

3.1.2 Use Case 2

Levi | System Requirements Specification 10

Levi | System Requirements Specification 11

Levi | System Requirements Specification 12

3.2 Process Execution Conformance Requirements

3.2.1 Process Instantiation and Termination

3.2.1.1 Process Instantiation

3.2.1.2 Process Termination

3.2.2.1 Sequence Flow Considerations

Figure 3.6 - Multiple outgoing Sequence Flows

Levi | System Requirements Specification 14

Figure 3.7 - The Lifecycle of a BPMN Activity

Levi | System Requirements Specification 15

3.2.2.4 Sub-Process / Call Activity

3.2.2.5 Ad-Hoc Sub-Process

3.2.2.6 Loop Activity

Levi | System Requirements Specification 16

3.2.2.7 Multiple Instances Activity

3.2.3.1 Parallel Gateway (Fork and Join)