Integrating Workflow-Based Mobile Agents with Cloud Business

INTERNATIONAL JOURNAL ON NEW COMPUTER ARCHITECTURES AND THEIR APPLICATIONS (IJNCAA) 2(4): 511-530 THE SOCIETY OF DIGITAL INFORMATION AND WIRELESS COMMUNICATIONS, 2012 (ISSN: 2220-9085)

511

Integrating Workflow-Based Mobile Agents with Cloud Business

Process Management Systems

Antons Mislevics and Janis Grundspenkis

Department of Systems Theory and Design,

Riga Technical University,

Meza ¼, Riga, LV-1048, Latvia

[email protected], [email protected]

ABSTRACT

While researching integration aspects of

cloud Business Process Management

Systems (BPMS) with on-premises

applications, authors have identified various

scenarios that cannot be effectively

addressed using existing integration

solutions and patterns. Mobile Agents

(MAs) were proposed as the technology

addressing these integration challenges [1].

During the research, existing MA platforms

were analyzed what led to conclusion that

none of them is fully addressing specific

requirements of end-users in BPM scenarios.

As a result, a new approach for designing

and executing mobile agents was proposed.

This approach is based on workflows and

enables end-users having no programming

skills to design MAs what is critical in BPM

scenarios [2]. In addition existing researches

cover different scenarios of how intelligent

agents can be used in BPM space, however

these do not address specific aspects of MA

integration with cloud BPMS, what is

critical for proposed solution. During

analysis of this subject, authors have

identified required integration components,

and are proposing an algorithm that allows

to determine how these components should

be implemented based on technical

specification of cloud BPMS. AgentWF

prototype provides a sample implementation

of all components, and demonstrates how

MA system should be integrated with cloud

BPMS using proposed approach. Proposed

approach is extendable and may be reused

for integrating MAs with cloud systems in

other domains as well.

KEYWORDS

Mobile Agents Systems and Technologies,

Intelligent Agents, SaaS Integration,

Business Process Management Systems,

Agent-Supported Business Process

Management

1 INTRODUCTION

Business Process Management Systems

(BPMS) became more popular in recent

years [64]. Market analysts have

observed this trend especially in service

industries, where human productivity

and effectiveness are critical to process

performance.

Analyzing future of BPMS researchers

and market analysts agree that cloud

computing environments will be widely

used to adopt BPMS applications [10,

30, 31]. As any successful BPMS

implementation relies on solid

integration with existing line of business

(LOB) applications and organizational

data sources, moving BPMS to the cloud

puts the focus on “cloud to on-premises”

integration questions. While researching

integration aspects of cloud Business

Process Management Systems (BPMS)

with on-premises applications, authors

have identified various scenarios that

cannot be effectively addressed using

existing integration solutions and


512

patterns. Mobile Agents (MAs) were

proposed as the technology addressing

these integration challenges [1]. During

the research, existing MA platforms

were analyzed what led to conclusion

that none of them is fully addressing

specific requirements of end-users in

BPM scenarios - also some existing MA

platforms are providing graphical user

interface, it is expected that user creating

MA has at least some understanding of

programming concepts. In majority of

systems programmer’s involvement is

also required to handle MA migrations.

As a result, a new approach for

designing and executing mobile agents

was proposed. This approach is based on

workflows and enables end-users having

no programming skills to design MAs

what is critical in BPM scenarios [2]. In

addition existing researches cover

different scenarios of how agent systems

can be used in BPMS area, however

these do not address specific aspects of

integration with cloud BPMS, what is

critical for proposed solution. During

analysis of this subject, authors have

identified four required integration

components, and are proposing an

algorithm that allows to determine how

these components should be

implemented based on technical

specification of cloud-BPMS.

The paper is organized as follows. The

next section provides an overview of

BPMS concept and implementation

aspects. Typical scenarios of using

intelligent agents in BPMS are presented

in Section 3. Section 4 covers main

concepts of MA systems, provides an

overview of existing MA

implementations and introduces newly

proposed workflow-based MA

development and execution approach.

Architecture of proposed MA solution is

presented in Section 5. This section also

provides in-detail overview of proposed

integration approach and analysis

algorithm used to define integration

components. Finally, a prototype used to

validate proposed architecture and

integration analysis algorithm is

presented.

2 BUSINESS PROCESS

MANAGEMENT SYSTEMS


(BPMS) are used to control, analyze and

manage business processes in

organizations. BPMS help to reduce the

amount of administrative effort and

focus on the processes which add value.

A modern BPMS should provide tools

for defining and executing business

processes, performance meter counters,

management tools and support real time

changes in processes [21]. The system

should also contain a set of tools to

integrate with external systems through

the variety of different protocols.

Besides it should integrate with other

BPMS, and support cross-organization

business processes [22]. In addition, a

modern BPMS should adapt to changes

in the environment [3].

The most common architecture for

implementing BPMS is Workflow-

Oriented BPMS (WBPMS) [3]. WBPMS

is primary focusing on a workflow itself.

BPMS of this kind are also called

centralized, because these systems have

a single process which ensures execution

of the entire business process. Workflow

is the automation of a business process

[4]. A typical workflow consists of the

following elements [5]:

Messages – ensure communication

between employees (e-mails, files,

paper documents, etc.);

Activities – tasks, which must be

completed by employees after


513

receiving a message from the

system;

Business rules – describe logics of

business processes;

Flowcharts – specify how

processes flow in the organization.

Workflow building blocks in WBPMS

are activities. These are used to create

flowcharts and define the flow of work

in the organization. Activities may be

simple, as task activities, or complex, as

calls to external web services (providing

possibilities to integrate with other

enterprise systems or BPMS) [6, 7].

Figure 1 shows common architecture of

a centralized BPMS.

Figure 1. Centralized business process management system (adopted from [3])

WBPMS are straightforward to

implement, and allow organizations to

gain the following advantages [4]:

The system helps to define and

formalize business processes. It

makes clear to everyone what is

happening in the organization and

what role each individual plays;

It is easier to analyze and optimize

processes when they are well

defined;

Complicated business processes

are broken down to simpler parts.

It is possible to analyze and

improve each part separately;

It helps to monitor daily

operations;

It integrates different applications

(which may be even hosted on

different platforms) in order to

ensure the single business process;

It provides personal workspace for

each employee (typically, a

personal workspace contains a list

of actual tasks, and supporting

information – documents, reports,

etc.);

The system separates business

logics of the process from actual

work items. Each employee should

not know each business process in

detail. He should focus on his own

tasks only.

These advantages are obvious and well

describe why BPMS are becoming more

popular. But taking a closer look at

organizations’ business processes

(especially at more complex ones),

opens up the whole set of issues, with


514

which WBPMS cannot deal so well [3,

4, 6, 7, 8, 9]:

1. The system is based upon the

single central workflow server. It

may be inappropriate in scenarios,

where company has multiple

branches in different offices, and

each branch is managing its own

business processes;

2. Insufficient automation: a system

describes the logics of the business

process – a sequence of steps that

should be performed to achieve the

goal, but all tasks are processed by

employees;

3. The system is not flexible enough:

the whole process with all branches

should be defined;

4. No resource management: the

system is not controlling whether

all resources required to complete

the task are available. It assumes

that this was taken into

consideration while planning the

process. That’s why the system is

not adaptive enough;

5. No knowledge of process

semantics: the system has lack of

information about the business

process itself. This information

cannot be used to make situation

appropriate decisions;

6. Lack of well-defined protocols to

exchange information among

systems, and integrate different

BPM systems to support cross-

company workflows;

7. Not trivial error handling: an error

in each step results in an error in

the process. Developers should

predict possible errors and

implement error handlers.

Unhandled exceptions will result in

aborting the whole process. It gets

even more complicated, when

developers have to deal with

parallelism and complex business

logics;

8. Users cannot adjust execution of

the workflow, thus in a non-

standard situation a user cannot

perform some action, which was

not specified while defining the

workflow;

9. Typically centralized systems

provide limited performance,

scalability and reliability;

10. Complicated versioning and

upgrade process.

The majority of these limitations are

obvious and are caused by specifics of

workflow oriented systems and design of

centralized BPMS. To improve

flexibility of the system and make

business processes more adaptable to

changes in external environment, several

alternative BPMS implementation

approaches are proposed. One of them is

Subject Oriented Busness Process

Management (S-BPM). This describes

simplified approach to analyze and

execute business processes that is

radically different from widely adopted

workflow oriented approach [10, 11, 12].

Other modern concept is Social BPM. It

extends formal workflow-oriented

BPMS approach with capabilities of

social technologies – collaboration,

social networks and instant messaging

[10, 13, 14]. Dynamic BPM is another

modern approach that is worth noting. It

combines various methods and

technologies to make business processes

more adaptable, and simplify

implementing modifications in business

processes [10]. Various authors are

proposing intelligent agents as a

technology that may improve flexibility

of BPMS, make processes more

adaptable to changes in external

environment, and also ensure resources

management and automation capabilities


515

[4, 15, 16, 17, 18, 19, 20]. Usage of

intelligent agents in BPM scenarios is

covered in the next section.


agree that cloud computing

environments will be used to adopt

BPMS applications [30, 31]. Market

analysts observe the same trend and pay

special attention to cloud BPM offerings,

expecting that these will achieve

mainstream adoption within two to five

years [10]. As any successful BPMS

implementation requires establishing

solid integration of business processes

with existing line of business (LOB)

applications and organizational data

sources, moving BPM to the cloud puts

the focus on “cloud to on-premises”

integration questions. Similar questions

are addressed in many studies around

integrating cloud Software-as-a-Service

(SaaS) applications with on-premises

systems and data sources [32, 33, 34, 35,

36, 37, 38]. Nevertheless, integrating

BPM cloud applications with on-

premises LOB applications has specific

scenarios and requirements that cannot

be effectively addressed by using

existing technologies and patterns [1],

which are:

Performing complex computations

close to data sources in internal

network (dealing with large

amounts of data);

Performing complex

transformations and computations

with data stored in on-premises

application in internal network (for

security and privacy reasons);

Implementing rapid changes in

integrations (to adapt business

process to changes in the

environment);

Accessing legacy systems and

specific devices that are deployed

on-premises and have no web

services or database interface.

These integration scenarios may be

addressed by using mobile agents (MA)

[1].

3 INTELLIGENT AGENTS IN

BUSINESS PROCESS

MANAGEMENT

There are two scenarios, how agents can

be used in business process

management: agent-supported BPM and

agent-driven BPM. In the first scenario

intelligent agents support business

processes, which are operated by the

BPMS. In the second – agents are

driving the process, encapsulating the

whole logic.

3.1 Agent-supported business process

management

In agent-supported BPM scenario agents

are working with BPMS to support

execution of business processes. Typical

roles of agents in this scenario are [4]:

User interface: the agent helps user

to complete tasks assigned during a

business process (filtering e-mails,

auto-responding to incoming e-

mails, reminding about upcoming

events, etc.);

Autonomous work item

processing: the agent completes

tasks without user interaction;

Interface to external systems: the

agent ensures communication

between BPM system and external

applications.

Figure 2 shows agents of different types

in action. Agent A1 is a user interface,

agents A2 and A3 autonomously process

work items, but agents A6 and A7

represent interfaces to external system.

To enable this scenario, BPMS must


516

provide interfaces for integration with

external systems. Using these interfaces

agents may connect to BPMS to access

data and perform operations.

BPMS

Agents

A1A1 A2A2 A3A3 A6A6 A7A7

Systems and users

Task listTask list Serializedobject

Serializedobject

Serializedobject

Serializedobject

Figure 2. Agent-supported business process management (adopted from [3])

3.2 Agent-driven business process

management

In agent-driven BPM approach agents

are controlling a flow of the process.

Each agent represents a specific part of a

business process. Collaboration of

agents ensures the complete process

[17].

To achieve this, entire business process

must be split into separate functions and

operations. Then an intelligent agent for

each function and operation is

implemented. Each agent is responsible

for one or multiple workflow steps, and

communicating with other agents

decides which step should be executed

next [4]. Agents may be different in

implementation and reasoning

complexity. For example, the simplest

agent may delegate some task to an

employee, wait when the task is

completed, analyse outcome and decide

which workflow steps must be executed

next. This idea is depicted in Figure 3.

Figure 3. Multiagent business process management (adopted from [3])


517

To enable this approach, BPMS must be

implemented in specific way, named

Agent-BPMS architecture [23, 24, 25,

26, 27, 28, 29]. Agent-BPMS is a

distributed system that has no central

workflow processing engine. Distributed

architecture allows to integrate processes

operated in different BPMS [4]. The

BPM system becomes dynamic and

expandable. Separate agents can be

modified, added or removed without

affecting operation of the entire system.

Agent-driven BPM approach allows to

achieve process automation, as

autonomous agents can perform tasks

without human interaction. Besides that,

agents may represent resources, ensuring

advanced resource management

scenarios. They may determine changes

in environment and adapt execution of

the whole business process. Agents may

learn over time, make better decisions

and thus achieve their goals more

effectively. They are focused not on

executing all steps of the process, but on

achieving some business goal. Agents

may autonomously search for better way

to achieve the goal, thus automatically

improving effectiveness of the whole

business process [7]. Figure 4 shows the

idea of agent-driven BPM approach.

BPMS and agents

A1A1

Systems and users

Serializedobject

Serializedobject

A2A2 A3A3 A4A4

Figure 4. Agent-driven business process management (adopted from [3])

3.3 Agents and cloud business process

management systems

In cloud-BPMS scenarios developers

cannot affect architecture and

implementation of BPMS system, thus

cannot implement full agent-driven BPM

scenario. However, cloud BPMS usually

provide various integration interfaces

[36], which may be used to implement

agent-supported BPM scenarios. It also

allows to combine agent-supported and

agent-driven BPM approaches, to ensure

that on some stage business process is

executed in agent-driven mode (for

example, to ensure that sub-process is

adapting to changes in external

environment). Implementing this

scenario requires to combine agent-

supported and agent-driven BPM

approaches. On specific stage of the

workflow a task for an agent is

generated. The agent receives a task (as

in agent-supported BPM scenario) and

collaborating with other agents, initiates

execution of sub-process (as in agent-

driven BPM scenario). When execution


518

of sub-process is completed, agent

completes initially assigned task, and the

execution of the workflow is continued

in BPMS. Figure 5 shows example of

this scenario.

BPMS

Agents

A1A1 A2A2 A3A3 A4A4

Systems and users

Task listTask list Serializedobject

Serializedobject

A5A5 A6A6 A7A7

Figure 5. Combining agent-supported and agent-driven business process management scenarios

The system addressing integration

challenges of cloud-BPMS with on-

premises enterprise systems and devices

proposed by authors [1] is based on

mobile agents (MA) and is implemented

using agent-supported BPM approach. It

also has some aspects of combined

approach, as implementation of MAs is

workflow-based [2]. This means, that

MA may implement sub-process that is

executed using agent-driven approach.

Workflow-based MA approach is

described in next section. Architecture of

proposed MA system and cloud-BPMS

integration aspects are covered in section

4.

4 WORKFLOW-BASED MOBILE

AGENTS

4.1 Concepts of Mobile Agents

Systems

Mobile agents (MA) are self-contained

and identifiable computer programs, that

can move within the network and act on

behalf of the user or another entity. The

following three capabilities are a

foundation for MAs: mobile code,

mobile computation, and mobile state

[39]. Mobile computation involves

moving a computation from one system

to another. Mobile code is the ability to

move code from one system to another

what allows systems to be extremely

flexible. Mobile state is an evolution of

state capture, which allows the execution

state of a process to be captured. State

capture is very useful for long-running

processes, because in the event of

failure, the execution of a process can be

restarted from the last saved state.

Mobile state allows the movement of the

execution state of an agent to another

system for continued execution. Not all

MA systems provide support for state

mobility [39, 40]. The term strong


519

mobility is used to describe systems that

can capture and move execution state

with the agent. In agents that support

strong mobility it is guaranteed that all

variables will have identical values after

moving to another host. Weakly MA

systems usually support the capture of

most of a program’s data, but restart the

program from a predefined program

point and thus require some programmer

involvement at each migration. The

advantage of strong mobility is that the

result of migrating is well defined and

easier to understand.

There are two main scenarios that must

be addressed by MA systems [41]:

creating an agent and transferring an

agent. To create an agent, MA system

creates an instance of the agent class on

a default host, or a host the client

specifies. The agent class specifies the

implementation of the agent. During the

execution MA may request the source

agent system for a transfer to another

host or agent system. To start this

process host or agency on a sender’s side

needs to initiate agent’s transfer:

suspend the agent, identify transferable

agent's state, serialize the agent class and

state, encode it for the chosen transport

protocol, provide authentication info to

the server, and transfer the agent. To

receive an agent destination host needs

to authenticate client, decode the agent,

deserialize the agent class and state,

instantiate the agent, restore the agent

state and resume agent execution.

Serialization is the process of storing an

agent in a serialized form, sufficient to

reconstruct the agent. Deserialization is

the inverted process.

4.2 Existing Implementations

There are three broad approaches to

mobility implementation [39, 40], named

remote evaluation, code on demand, and

mobile agents. In remote evaluation

scenario an application invokes services

on another node by specifying the code,

as well as the input data, necessary to

invoke the service. The code and input

data are sent to the remote node, and the

remote node then executes the code and

sends the output data back to the client.

In code on demand approach code

fragments are requested as they are

needed, and dynamically compiled,

verified and linked into a running

system. In mobile agents approach rather

than simply moving code and input data

(as in remote evaluation scenario), MAs

view a computation as a single entity

and support the migration of a complete

program to another node. MA

infrastructures can be implemented as

extensions to code-on-demand systems

[42, 43, 44, 45, 46], as extensions to

remote evaluation systems, or as new

programming languages [47, 48]. In

general, three targets for MA system

design and implementation exist: using

or creating a specialized language

(language features provide the

requirements of MA systems), as

operating system (OS) services or

extensions (what allows to take

advantage of existing OS features), or as

specialized application software [49].

There are many MA platforms available,

with over 100 such systems

implemented in the last five years.

However, according to researchers the

following may be considered as the most

popular: Telescript, NOMADS,

SafeTCL, D'Agents, JavaSeal, Mole,

Aglets, Lime, Messenger, JADE,

Voyager, TACOMA, Grasshopper,

SPRINGS, MAPNET and

EtherYatri.NET [39, 50, 51]. Analyzing

existing systems researchers conclude

that weak mobility is by far the


520

predominant approach [39]. Java is still

the most popular agent implementation

language, mainly due to both the

popularity of the language and its

support for dynamic loading and

advanced security features [39, 50].

Microsoft .NET is more recent

technology with the Common Language

Runtime, which is also based on a virtual

execution environment and supports the

dynamic loading of programs. .NET is

becoming more popular in recent MA

implementations, however in the overall

picture Java still prevails [39, 51]. The

main advantage of building MA system

on an existing language is that the

existing technology can be leveraged.

This definitely comes at the price of

some conceptual complexity, since the

system designer must deal with inherent

limitations of the language.

Analyzing agent development

experience in existing implementations,

it should be noted that also some

platforms are providing graphical user

interface, it is expected that user creating

MA has at least some understanding of

programming concepts. Details of saving

agent’s state and restarting execution are

also not obvious for end-users with no

technical knowledge. In systems

implementing weak mobility approach

programmers involvement is also

required to handle MA migrations.

To address these issues authors are

proposing the approach for designing

and executing mobile agents, which is

based on workflows [2].

4.3 Workflow-Based Approach

Workflows are considered a standard

mechanism used to develop long running

processes. Recently, workflow platforms

become widely available to developers

as part of software development

frameworks (for example, Microsoft is

providing Workflow Foundation in

.NET Framework [52]). In addition to

features already available in specific

software development frameworks,

workflow platforms provide support for

state persistence, resuming execution

from persistence point and graphical

definition tools. These tools enable users

without programming knowledge to

define complex workflow behaviors.

Authors believe that with minimal

extensions workflow platforms built on

top of popular software development

frameworks may become a solid

foundation for building user-friendly

MA systems.

Agent Designer BPM systemAgent Definition

(*.awfd)1. Create 2. Load to Agent Instance

(*.awfx)3. Start

execution

Figure 6. Agent development process

MA design and initiation process is

organized in three steps (Figure 6):

1. Business analyst defines agent

behavior using special application

Agent Designer (Figure 7).

Application allows defining

sequential agent behaviors as steps

of a workflow. As a result Agent

Definition package is created

(.awfd file);

2. Agent Definition package is then

uploaded to BPMS;

3. BPMS initiates execution of an

agent. At this point Agent Instance

package is created (.awfx file)


521

from previously defined Agent

Definition package.

Figure 7 shows Agent Designer

application developed as part of

AgentWF prototype.

Figure 7. AgentWF Agent Designer application

5 PROPOSED SOLUTION

5.1 Overall Architecture

Overall architecture of proposed MA

solution MA solution is shown on Figure

8. Organization is using a cloud BPM

through an existing internet connection.

Organization’s internal environment

consists of employees, various devices,

business systems, and data storages. To

integrate this internal environment with

cloud BPMS a MA infrastructure should

be deployed in organization. On client

side this requires installing agent

execution environment software on

devices. In addition a highly available

communication proxy (agency) should

be established. This may be deployed as

part of cloud BPM system, part of

organization’s internal infrastructure, or

a separate cloud service. The

communication proxy should provide

agent queue that receives agents and

routes them to appropriate destination

host (BPM, or agent host). The system is

implemented using agent-supported

BPM approach. Agency connects to

BPM system through BPM protocol

handler implemented specifically for this

system. Execution of MA is initiated in

BPMS. MAs are traveling from BPMS


522

to appropriate agent host and back

through agency. While transporting

agents are packaged to special container

(agent package). When the package

reaches destination host it becomes an

agent and runs in the execution

environment.

Cloud BPM

Agency

Agent Queue

HTTPS

Organization

Data storages

SystemsSystems

PeoplePeople

Agent Host(Execution

Environment)

DevicesDevices

HTTPS

Exchangesdata

Exchangesdata

Workswith

Executes

InternetConnection

(HTTPS)

Mobile agentMobile agent

Figure 8. Mobile agent solution to integrate cloud business process management system with enterprise

systems and devices (adopted from [1])

Proposed architecture is based on the

following standards and open

specifications: OPC [53], XML [54],

XML encryption [55], XAML [56, 57],

JSON [58], X509 certificates (signing

and encryption) [59, 60]. It was

developed for integrating on-premises

systems with cloud-BPM systems [1].

However, with minimal adjustments

proposed approach may be reused in

other domains as well. MA system

includes the following components:

(Figure 9):

Agencies – establish

communication between systems

and agent hosts;

Agent Hosts and Executors –

execute MAs on devices;

Protocol handlers – used to connect

to initiating system from agencies;

Mobile agents – agents

implementing strong mobility;

Agent designer – application used

to create MAs in graphical

environment;

Monitoring tools – applications

used to monitor agencies and agent

hosts;


523

BPM extensions – provide

integration capabilities for specific

BPM system (on BPM side).

Relations between these components are

show on Figure 9. The system is

designed the way that all

communications to download and upload

MAs are established from client side

only: agency connects to initiating

system, agent host connects to agency.

Communications between modules may

be established through widely adopted

protocols (for example, http or https).

This allows deploying the system in

highly dynamic environments, or ones

having strict security requirements.

AgentDispatcher(Windows Service)AgentDispatcher

(Windows Service)AgencyService

(Windows Service)AgencyProxy(WCF Service)

BPM system

1. Download runnable agent;2. Upload completed agent.

AgencyDB(SQL Compact)

1. Register new agent;2. Send completed agent to BPM;3. Process execution timeouts.

1. Start new execution session;2. Update execution sessions;3. Close execution sessions,update agent status.

AgentHostService(Windows Service)

AgentDispatcher(Windows Service)

AgentHostDB(SQL Comact)

1. Download agent;2. Upload agent;3. Get information oncanceled or time-outSessions.

1. Register new agent (perform routing);2. Upload updated agents;3. Delete completed/canceled/timed-out agents.

1. Get agent for execution;2. Update agent package after execution;3. Handle complex activities(Delay, MoveToHost).

AgentExecutor(AddInProcess)

1. Initiate executor process for agent;2. Pass read-only agent for execution;3. Process result.

BPM Extensions:- Workflow Actions- Agent Definition store- Agent Instance store

AgencyMonitor(Windows Application)

AgentHostMonitor(Windows Application)

Monitoringagency

Monitoringhost

Protocol Handler

External Network

Internal Network

Age

nt

Ho

st N

etw

ork

Age

ncy

Ne

two

rk

Figure 9. Components of the system (adopted from [1])

5.2 Integration with cloud business

process management system

The following four components are

required to integrate MA system with

cloud-BPMS:

1. Protocol Handler – ensures

communication with specific

BPMS;

2. Agent Definitions Store – stores

agent definitions;

3. Agent Instance Store – stores agent

instances;

4. Workflow Actions – allows to use

MA specific activities while

defining workflow models (for

example, initiate MA execution, or

handle MA execution result).

Figure 10 shows these components and

their relations with agency and agent

designer application.

Protocol Handler is mandatory

component that is required to integrate

MA system with BPMS. To implement

Protocol Adapter developers use

integration interfaces provided by

BPMS. If BPMS is not providing such

interfaces, implementing Protocol

Adapter is not possible. All

communication between agency and

BPMS happens through Protocol

Adapter.


524

BPM system

Agent Definitions Agent Instances Workflow Actions

Agent Designer

Publish agentdefinition View agent

instance

Agency

Download agentdefinition

Upload agentinstance

Get agent executionrequest

Handle completedagent instances

Protocol Handler

Figure 10. Integration with cloud-BPMS

Agent Definitions and Instances Stores

are mandatory components that should

be implemented as extensions to BPMS.

In this case workflow models and

definitions for MAs used in these are

stored in single location (cloud-BPMS).

This also allows to avoid developing

separate mechanism to transfer MA

execution results back to BPMS, as this

is a part of MA instance stored in

BPMS. Agent definitions are stored as

MA package files (.awfd). Agent

instances may be stored as MA package

file (.awfx) or as unpacked collection of

files (this simplifies analyzing MA

execution results, as raw files are

available and handling MA package is

not required).

If storing Agent Definitions and

Instances in BPMS is not possible,

separate storage must be implemented.

This should address the following

requirements:

It allows to store MA package files

(.awfd and .awfx);

It allows to publish MA definitions

developed in Agent Designer

application;

It provides communication

protocols through which agency

may download MA definition

packages and upload MA

instances.

In this scenario it is also required to

implement components that ensure

information exchange between agency

and Agent Definition and Instances

Stores. In addition, it is also required to

implement mechanism that transfers MA

execution result into BPMS.

Agent Workflow Actions allow using

MA specific activities while defining

workflow models. Implementing the

following activities is recommended:

MA initialization, specifying agent

definition and initiation

parameters;

Starting MA execution;

Handling MA execution results.

If BPMS does not provide mechanisms

to extend workflow models with custom

activities, MA integration should be

implemented using existing workflow

activities. For example, integration may

be achieved by using standard workflow

tasks:

To initiate MA execution new task

is created, including agent

initiation parameters in task

description;

When MA execution is completed,

task status is changed to

completed, and agent execution


525

results are included in metadata of

the task.

Figure 11 shows proposed algorithm that

allows to determine how BPMS

integration components should be

implemented based on technical

specification of cloud BPMS.

Analyze features of

the system

Does the system support connections from other systems

via external protocols?

1. Select protocol to be used for interation;2. Implement protocol handler.

Integration is not possible

Yes No

Does the system provide storage options for Agent

Definitions and Agent Instances?

1. Store Agent Definitions and Agent Instances in the system:- Store agent definitions as .awfd package files;- Store agent instances as .awfx package files or in unpacked form;2. Agent execution result may be communicated back to the system natively, as part of Agent Instance.

Yes

1. Implement external storage for Agent Definitions and Agent Instances, that supports:- Storing .awfd and .awfx agent package files;- Uploading .awfd files from Agent Designer; - Communication protocols to perform read/write operations by Agency;2. Implement communication module for Agency to access external storage;3. Decide, how agent execution result will be communicated to the system.

No

Does the system provide options to extend workflow

models with custom actions?

Implement custom workflow actions to:- Initiate mobile agent;- Start agent execution;- Handle agent execution results.

Yes No

1. Decide, how agent execution will be initiated and started using existing workflow actions (for example, by creating a task with specific metadata);2. Decide, how agent execution results will be handled using existing workflow actions (for example, analyzing completion status and metadata of workflow task);3. Implement support for these actions in protocol handler.

Figure 11. Algorithm used to analyse cloud-BPMS integration options

6 VALIDATION OF PROPOSED

ARCHITECTURE AND

INTEGRATION ANALYSIS

ALGORITHM

To validate proposed architecture MA

system prototype called AgentWF was

implemented (see Figure 7) [1, 2]. It is

built on Microsoft .NET Framework 4.0

technology. This allows to use standard

security capabilities (like process

isolation and code access security) to

ensure secure execution of MAs. This

also allows extending solution later

using standard .NET mechanisms. Agent

executors are built using add-in

framework [61]. This allows to ensure


526

security by executing MA in a separate

process with limited permissions. Add-in

framework also provides native

mechanism for versioning agent

executors what will become very

important over time when the format of

agent package will evolve. Workflow

design and execution is performed using

Workflow Foundation 4.0 platform [52].

State persistence services provided by

the platform allow implementing strong

agent mobility. The system is

extendable. Developers can implement

custom Workflow Foundation 4.0

activities that may be used as additional

actions while designing agent behaviors.

To validate proposed cloud-BPMS

integration approach (Figure 10)

integration with SharePoint Online

(Office 365) system was implemented

[62]. Using proposed analysis algorithm

(Figure 11) and SharePoint Online

technical documentation [63] the

following implementation approach was

selected:

Protocol Handler connects to

BPMS using SharePoint Online

web services interfaces;

Agent definitions are stored as

agent package files in SharePoint

documents library;

Agent instances are stored in

SharePoint documents library as

upackaged files (as SharePoint

Online does not provide

mechanisms to handle OPC

packages);

Custom agent workflow actions are

implemented as sandbox

SharePoint Designer Workflow

Actions, what allows these to be

used defining SharePoint Online

workflow models.

Figure 12 shows agent definition and

instance stores in SharePoint Online.

Example of using custom workflow

actions are shown on Figure 13.

Figure 12. Agent instance and definitions stores


527

Figure 13. Using custom workflow activities in SharePoint Designer

7 CONLCUSIONS


(BPMS) became more popular in recent

years, especially in service industries,

where human productivity and

effectiveness are critical to process

performance [64]. Nowadays the most

common architecture for implementing

BPMS is Workflow-Oriented BPMS

(WBPMS) [3], that is primarily focusing

on workflow itself, and has single

process that ensures execution of entire

business process. However, this

architecture has a set of limitations, the

majority of which are caused by

specifics of workflow oriented systems

and design of centralized BPMS. To

improve flexibility of the system and

make business processes more adaptable

to changes in external environment,

several alternative BPMS

implementation approaches are

proposed: among these, Subject Oriented

BPM [10, 11, 12], Social BPM [10, 13,

14] and Dynamic BPM [10]. Various

authors are proposing intelligent agents

as a technology that may improve

flexibility of BPMS, make processes

more adaptable to changes in external

environment, and also ensure resources

management and automation capabilities

[4, 15, 16, 17, 18, 19, 20].


and market analysts agree that cloud

computing environments will be used to

adopt BPMS applications [10, 30, 31].

As any successful BPMS

implementation requires establishing

solid integration with existing line of

business (LOB) applications and

organizational data sources, moving

BPM to the cloud puts the focus on

“cloud to on-premises” integration

questions. Similar questions are

addressed in many studies around

integrating cloud Software-as-a-Service

(SaaS) applications with on-premises

systems and data sources [32, 33, 34, 35,

36, 37, 38]. Nevertheless, integrating

BPM cloud applications with on-

premises LOB applications has specific

scenarios and requirements that cannot

be effectively addressed by using

existing technologies and patterns [1].

Authors propose mobile agents as the


528

technology that may address these

integration challenges [1].

There are two scenarios, how intelligent

agents can be used ith business process

management systems: agent-supported

BPM and agent-driven BPM. In the first

scenario intelligent agents support

business processes, which are operated

by the BPMS. In the second – agents are

driving the process, encapsulating the

whole logic. To enable agent-driven

BPM approach, BPMS must be

implemented in specific way, named

Agent-BPMS architecture [23, 24, 25,

26, 27, 28, 29]. In cloud-BPMS

scenarios developers cannot affect

architecture and implementation of

BPMS system, thus cannot implement

full agent-driven BPM scenario.

However, cloud BPMS usually provide

various integration interfaces [36],

which may be used to implement agent-

supported BPM scenarios. It also allows

to combine agent-supported and agent-

driven BPM approaches, to ensure that

on some stage business process is

executed in agent-driven mode.

MA system addressing integration

challenges of cloud-BPMS with on-

premises enterprise systems and devices

proposed by authors [1] is implemented

using agent-supported BPM approach. It

also has some aspects of combined

approach, as implementation of MAs is

workflow-based [2]. This means, that

MA may implement sub-process that is

executed using agent-driven approach.

The following four components are

required to integrate MA system with

cloud-BPMS: Protocol Handler, Agent

Definitions Store, Agent Instance Store

and Workflow Actions. Authors are

proposing algorithm that allows to

determine how these integration

components should be implemented

based on technical specification of cloud

BPMS. Proposed architecture was

validated by implementing prototype

called AgentWF [1, 2]. It also allowed to

validate proposed cloud-BPMS

integration approach by implmeneting

integration with SharePoint Online

(Office 365) system [62]. During

implementation proposed analysis

algorithm and SharePoint Online

technical documentation [63] were used.

This allowed to select implementation

approach for all required components.

ACKNOWLEDGMENT

This work has been supported by the

European Social Fund within the project

“Support for the implementation of

doctoral studies at Riga Technical

University”.

REFERENCES

1. Mislēvičs, A., Grundspeņķis, J., Mobile

Agents for Integrating Cloud-Based

Business Processes with On-Premises

Systems and Devices, Baltic DB & IS 2012

(in press).

2. Mislēvičs, A., Grundspeņķis, J., Workflow

Based Approach for Designing and

Executing Mobile Agents, ICDIPC12, ISBN

978-1-4673-1105-2, pp. 97-102 (2012).

3. Grundspeņķis J., Mislēvičs A., Intelligent

Agents for Business Process Management

Systems. Infonomics for Distributed

Business and Decision-Making

Environments: Creating Information System

Ecology, Malgorzata Pankowska (Karol

Adamiecki University of Economics in

Katowice, Poland) (2010), 97-131

4. Yuhong, Y., Zakaria, M., Weiming, S.

Integration of Workflow and Agent

Technology for Business Process

Management // The Sixth International

Conference on CSCW in Design, 2001

5. Dejong, P. Going With the Flow, Workflow

Systems, ACM QUEUE (2006)


529

6. Pang, G., Implementation of an agent-based

business process [Diploma thesis]. Institut

für Informatik der Universität Zürich. (2000)

7. Grundspenkis, J., Pozdnyakov, D., An

overview of the agent based systems for the

business process management. Proceedings

of the international conference on computer

systems and technologies

(CompSysTech’06), June 15-16, 2006,

Veliko Tarnovo, Bulgaria, II.13-1 - II.13-6

(2006)

8. Trammel, K., Workflow without fear. Byte,

April 1996. (1996)

9. O’Brien, P. D., & Wiegand, M. E., Agent

based process management: Applying

intelligent agents to workflow. The

Knowledge Engineering Review, 13(2),

161-174. (1998)

10. Dixon J., Jones T., Hype Cycle for Business

Process Management, Gartner Research

(2011)

11. Buchwald, H., Fleischmann, A., Seese, D.,

Stary, C., S-BPM One: Setting the Stage for

Subject-Oriented Business Process

Management, Springer-Verlag (2010)

12. Metasonic: http://www.metasonic.de/

13. Erol, S., Granitzer, M., Happ, S., Jantunen,

S., Jennings, B., Johannesson, P.,

Koschmider, A., Nurcan, S., Rossi, D.,

Schmidt, R., Combining BPM and social

software: contradiction or chance?. J. Softw.

Maint. Evol.: Res. Pract., 22: 449–476. doi:

10.1002/smr.460 (2010)

14. Schmidt, R., Nurcan, S., BPM and Social

Software, Lecture Notes in Business

Information Processing, 1, Volume 17,

Business Process Management Workshops,

Part 9, Pages 649-658 (2009)

15. Delias, P., Doulamis, A., Matsatsinis, N.,

What agents can do in workflow

management systems, Artif Intell Rev,

35:155–189 (2011)

16. Jennings, N. R., Norman, T. J., & Faratin,

P., ADEPT: An agent-based approach to

business process management. ACM

SIGMOD Record, 27, 32-39 (1998)

17. Jennings, N. R., et al., Autonomous agents

for business process management. Applied

Artificial Intelligence, 14, 145-189 (2000)

18. Jennings, N. R. An agent-based approach for

building complex software systems.

Communications of the ACM, 44(4), 35-41

(2001)

19. Jennings, N. R., Sycara, K., & Wooldridge,

M., A roadmap of agent research and

development. Autonomous Agents and

Multi-Agent Systems, 1(1):7, 7-38 (1998)

20. Suh, Y.-H., Namgoong, H., Design of a

Mobile Agent-Based Workflow

Management System, S. Pierre and R.

Glitho (Eds.): MATA 2001, LNCS 2164, pp.

93-102 (2001)

21. Chang, J. F., Business Process Management

Systems, Strategy and Implementation.

Auerbach Publications (2005)

22. Smith H., Fingar P., Business Process

Management The Third Wave / Meghan-

Kiffer Press, 2003, ISBN: 0-929652-33-9.

23. Jennings, N. R., et al., Autonomous agents

for business process management. Applied

Artificial Intelligence, 14, 145-189 (2000)

24. Jennings, N. R., Norman, T. J., & Faratin,

P., ADEPT: An agent-based approach to

business process management. ACM

SIGMOD Record, 27, 32-39 (1998)

25. Jennings, N. R. An agent-based approach for

building complex software systems.

Communications of the ACM, 44(4), 35-41

(2001)

26. Jennings, N. R., Sycara, K., & Wooldridge,

M., A roadmap of agent research and

development. Autonomous Agents and

Multi-Agent Systems, 1(1):7, 7-38 (1998)

27. Goser K., Jurisch M., Acker H., Kreher U.,

Lauer M., Rinderle-Ma S., Reichert M., and

Dadam P. (2006). Next-generation Process

Management with ADEPT2, 2006.

28. Reichert, M., et al., Adaptive process

management with ADEPT2. Proceedings of

the 21st international conference on data

engineering, ICDE 2005 (2005)

29. Goser, K., et al., Next-generation process

management with ADEPT2. Proceedings of

the BPM demonstration program at the fifth

international conference on business process

management (BPM’07) Brisbane, Australia,

24-27 September 2007 (M. Adams & S.

Sadiq, Eds.) (2006)

30. Liu C., Chang J., Yang A., Analysis on

Development Tendency of Business Process

Management, ICICA 2011, Part II, CCIS

244, 2011, 629–636.

31. Scheer A.-W., Klueckmann J., BPM 3.0,

BPM 2009, LNCS 5701, 2009, 15–27.

32. Liu F., Li L., Chou W., Communications

Enablement of Software-as-a-Service (SaaS)

Applications, IEEE Communications

Society, 2009.

33. Scheibler T., Mietzner R., Leymann F., EAI

as a Service – Combining the Power of


530

Executable EAI Patterns and SaaS, IEEE

Communications Society, 2008.

34. Hai H., Sakoda S., SaaS and Integration

Best Practices, Fujitsu Scientific

Technology Journal, Vol. 45, No. 3, 2009,

257-264.

35. Carraro G., Chong F., Software as a Service

(SaaS): An Enterprise Perspective, 2006.

Available from:

http://msdn.microsoft.com/en-

us/library/aa905332.aspx

36. Liu F., Guo W., Zhao Z. Q., Chou W., SaaS

Integration for Software Cloud. In:

Proceedings of the 3rd IEEE International

Conference on Cloud Computing (CLOUD),

2010, 402 - 409.

37. Sun W., Zhang K., Chen S. K., Zhang X.,

Liang H., Software as a Service: An

Integration Perspective. ICSOC 2007, LNCS

4749, 2007, 558–569.

38. Ottinger J., Software as a Service Integration

via Mule [Internet]. Available from:

http://mule.mulesource.org/

39. Suri, N.. Vitek, J., Mobile Agents,

Computational Complexity, 2012, pp. 1880-

1893

40. Fuggetta, A., Picco, G. P., Vigna, G.,

Understanding code mobility, IEEE

Transactions on Software Engineering, 1998

41. Milojicic, D., Breugst, M., Busse, I.,

Campbell, J., et al., MASIF: The OMG

Mobile Agent System Interoperability

Facility, Personal Technologies, vol. 2, Nr.

2, 1998, pp. 117-129

42. Baumann, J., Hohl, F., Rothermel, K.,

Straßer, M., Mole – Concepts of a mobile

agent system, World Wide Web 1, 1998, pp.

123–137

43. Binder, W., Design and implementation of

the J-SEAL2 mobile agent kernel, The 2001

Symposium on Applications and the

Internet, 2001

44. Lange, D., Oshima, M., Programming and

deploying Java Mobile Agents with aglets,

Addison Wesley, 1998

45. Suri, N., Bradshaw, J. M., Breedy, M. R.,

Groth, P. T., Hill, G. A., Jeffers, R., Strong

mobiling and fine-grained resource control

in NOMADS, Agent Systems, Mobile

Agents, and applications, Springer, 2000

46. Truyen, E., Robben, B., Vanhaute, B.,

Coninx, T., Joosen, W., Verbaeten, P.,

Portable support for transparent thread

migration in Java, Proceedings of the Joint

Symposium on Agents and Mobile Agents,

2000, pp. 29–43

47. Suri, N., Bradshaw, J. M., Breedy, M. R.,

Groth, P. T., Hill, G. A., Jeffers, R., et al.,

NOMADS: Toward an environment for

strong and safe agent mobility, Proceedings

of Autonomous Agents, ACM Press, 2000

48. White, J. E., Telescript, Mobile agents,

Manning Pub, 1997, pp. 37–57

49. Farmer, W. M., Guttman, J. D., Swarup, V.,

Security for Mobile Agents: Issues and

Requirements, The MITRE Corporation,

1996

50. Gupta, R., Kansal, G., A Survey on

Comparative Study of Mobile Agent

Platforms, International Journal of

Engineering Science and Technology, Vol. 3

No. 3, 2011, pp. 1943-1948

51. Rama, J., Bishop, J., Towards a mobile

agent framework for Nomad using .NET,

Proceedings of SAICSIT, 2004, pp. 111–113

52. Windows Workflow Foundation:


us/netframework/aa663328

53. Standard ECMA-376, Office Open XML

File Formats, 1st edition, Part 2: Open

Packaging Conventions, December 2006:

http://www.ecmainternational.org.

54. Extensible Markup Language (XML):

http://www.w3.org/XML/

55. XML Encryption Syntax and Processing:

http://www.w3.org/TR/xmlenc-core/

56. Extensible Application Markup Language

(XAML):

http://www.microsoft.com/download/en/deta

ils.aspx?displaylang=en&id=19600

57. XAML Syntax In Detail:


us/library/ms788723.aspx

58. JSON: http://json.org/

59. Internet X.509 Public Key Infrastructure

Certificate and Certificate Revocation List

(CRL) Profile:

http://tools.ietf.org/html/rfc5280

60. Internet X.509 Public Key Infrastructure:

Certification Path Building:

http://tools.ietf.org/html/rfc4158

61. Add-ins and Extensibility:


us/library/bb384200.aspx

62. Office 365: http://www.microsoft.com/en-

us/office365/hosted-solutions.aspx

63. SharePoint Online for Office 365 Developer

Guide: http://msdn.microsoft.com/en-

us/library/hh147180.aspx

64. Sinur J., Hill J. B., Magic Quadrant for

Business Process Management Suites,

Gartner Research, 2010.

Documents

Integrating Workflow-Based Mobile Agents with Cloud Business