levi - srs

SYSTEM REQUIREMENTS SPECIFICATION

Levi – the Native BPMN 2.0 Execution Engine

Version 1.0

Levi | System Requirement Specification i

PROJECT SUPERVISORS

Ms. Vishaka Nanayakkara

Dr. Sanjiva Weerawarana

Mr. Milinda Pathirage

GROUP MEMBERS

Index No Name E-mail

070468D Eranda Sooriyabandara [email protected]

070206B Ishan Jayawardena [email protected]

070138R Keheliya Gallaba [email protected]

060501P Umashanthi Pavalanathan [email protected]

Levi | System Requirement Specification ii

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 iii

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 iv

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 v

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 Requirements Specification 1

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.


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.

http://www.google.com/url?q=https%3A%2F%2Fgithub.com%2F&sa=D&sntz=1&usg=AFQjCNHReqsuKT6C86HcgL4TbSevF24rxQ










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.

Levi | System Requirements Specification vi

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.

http://www.google.com/url?q=http%3A%2F%2Fwww.apache.org%2Flicenses%2F&sa=D&sntz=1&usg=AFQjCNGKpUgfC0uWu7qr01PyApazw6X2sA








Levi | System Requirements Specification vii

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 viii

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