FACILITATING BUSINESS PROCESS MANAGEMENT

WITH HARMONIZED MESSAGING

Shazia Sadiq, Maria Orlowska

School of Information Technology and Electrical Engineering

The University of Queensland, Australia

Wasim Sadiq, Karsten Schulz

SAP Corporate Research Centre Brisbane, Australia

Keywords: Business Process Management, Workflows, Middleware Integration, Messaging

Abstract: Process communication is characterized by complex interactions between heterogeneous and autonomous

systems within the enterprise and often between trading partners. An overwhelming number of initiatives

and proposals are underway to provide solutions for process specification and communication. However, the

focus is often on defining APIs and interfaces rather than the semantics of the underlying message

exchange. We see a great potential in the enhancement of current messaging infrastructure, in its new role in

facilitating complex, long running interactions for dynamic and collaborative processes operating in

decentralized environments like the web. In this paper, we primarily present a vision for a technology aimed

at providing a level of harmonization to multiple messages to form a single custom definable backbone. We

will provide the foundation framework for the harmonized messaging technology and identify fundamental

issues for the specification of such complex interactions.

This work is part of a project jointly funded by the Australian Research Council, SAP Corporate Research and The

University of Queensland

1 INTRODUCTION

Tremendous developments in data storing,

processing and communication over the last two

decades have made unprecedented impact on how

most companies operate, develop future business

strategies and deal with day-to-day operations.

Commonly available networking and expansion of

the access to the Internet have changed the way we

reason about system architectures, with integration

becoming an obvious and preferred option.

The research efforts and development paths

pursued by many academic groups and system

vendors, targeting heterogeneous system integration,

have not been easy and have not always delivered

effective and practical results which could make a

real impact on how the future solutions are to be

constructed. Many lessons have been learnt from

these research outcomes. They outline the clear

boundaries of feasibility when dealing with building

new applications out of existing and

useful/deployable components (Colomb &

Orlowska, 1994). These conclusions are not only

related to the technological aspects of integrated

structures, such as the middleware, but also to

semantic issues of terms used across multiple

systems. In particular, the need for a complete and

extensible ontology that expresses the basic concepts

that are common across a variety of domains,

became apparent, forming a new research direction

over the last few years (see e.g.

www.cs.rmit.edu.au/fedconf/odbase/2002/ )

Workflows Management Systems (WFMS)

delivered effectively in the area of process

enforcement, offering a clear separation of business

process logic from component applications involved

in process execution, thereby responding to the well-

established need for application integration. It is an

observed phenomenon that a new IT solution often

Sadiq S., Orlowska M., Sadiq W. and Schulz K. (2004).

FACILITATING BUSINESS PROCESS MANAGEMENT WITH HARMONIZED MESSAGING.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 30-36

DOI: 10.5220/0002634900300036

 SciTePress

triggers additional, and even more advanced user

requirements, which probably would not be

discovered if the current systems functionality

would not be so widely available. This pattern can

be clearly observed in the context of workflows

technology evolution.

In Figure 1, we show building blocks of process-

enabled enterprise systems. Just as the DBMS

provided a means of abstracting application logic

from data logic, the WFMS provided a means of

abstracting coordinative process logic from

application logic. Clearly, every generation has

provided additional functionality through supporting

systems. Although, workflow technology has

delivered a great deal of productivity improvements,

it has been mainly for pre-defined static and

repetitive business processes, that required basic

level of coordination between human performers and

some application components. More recently

business process management (BPM) has been used

as a broader term to reflect the fact that a business

process may or may not involve human participants

and may also cross organizational boundaries

through messaging infrastructures. The role of

business process management systems must now be

extended to provide additional functionality to

support configurable, coordinative and collaborative

processes and a much more sophisticated level of

integration (desirable characteristics of current

business process management systems). This need

arises from expanding business requirements for

cross-organizational process communication.

Examples of such processes can be found:

• in globalization of many manufacturing

companies where different product parts are

developed at different locations by different

organizations,

• in a new wave of e-commerce applications

where a great deal of outsourcing is the norm,

• in financial services with emerging subsidiary

agencies sharing work practice,

• and recently, in new non-traditional application

domains for business process technology such as

e-learning, where cross-organizational units offer

new educational services that would greatly

benefit from integration.

•

• Only an integration technology that offers rapid

and easy integration procedures, requiring only

minimal IT expert intervention, can be

successful at multiple and diverse,

geographically spread e-business environments.

The great challenge for IT specialists now is to

find a functionally rich and technically feasible

balanced solution for this overall complex

problem of integration taking into account

technological and semantic limitations.

Figure 1: Building Blocks of Process-Enabled

Enterprise Systems

2 CURRENT TECHNOLOGY

SOLUTIONS AND RESEARCH

DIRECTIONS

There is currently a drive towards advancement of

the technologies surrounding the e-business domain

(See e.g. 3rd VLDB Workshop on Technologies for

E-Services TES'02, and Workshop on Web

Services, e-Business, and the Semantic Web

(WES):In conjunction with CAiSE'02)

Businesses are increasingly moving towards

extensive automation of their private and public

processes. This automation takes the form of

complex interactions between heterogeneous and

autonomous systems within the enterprise and often

across multiple organizations. Controlling these

complex interactions in order to effectively manage

collaborative business processes is known to be a

critical yet difficult problem using current

technology solutions. Consequently, the areas of

consideration are multi-faceted ranging from

security, reliability and transactionability, quality of

service guarantees, process validation, optimisation

to semantic integrity of terminology used. The

industry is currently flooded with initiatives and

proposals towards e-business standards. These

standards encompass trading partner agreements,

business process specification, application

integration, and network protocols.

Integration technologies such as brokers,

application adapters, portals and messaging are

fundamental elements of a collaborative business

process environment. For this wide-spread enterprise

FACILITATING BUSINESS PROCESS MANAGEMENT WITH HARMONIZED MESSAGING

application integration (EAI) and/or business to

business (B2B) integration to become a reality, we

need common architectures and open standards to

support it. B2B protocols attempt to establish a

common language between businesses, so that

collaborations (which occur between two business

partners) can take place without the need for pair-

wise negotiation of integration. Such protocols are

message centric by definition, describing the formal

message exchange necessary for an interaction to

take place between two business partners. B2B

protocols have been an active area of research

(Bussler, 2002) with two of the predominant

solutions in this area being RosettaNet

www.rosettanet.org and ebXML www.ebxml.org.

An alterative area of active research for enabling

automated inter-business interaction, and facilitating

system integration is obviously web service

technology (www.webservices.org). Web service

technology’s potential in the area of integration and

interoperation has generated great interest, with

initiatives from leading software vendors such as

Hewlett-Packard, IBM, Microsoft, SAP, Oracle and

Sun Microsystems. Web services are seen as a

means of integrating applications, promoting

interoperability and facilitating process management

over decentralized environments. The loose coupling

and dynamic binding characteristics of web services

are the main justifications towards achieving the

above.

The web service architecture is described by a

Web Services Stack (Kreger, 2001), however the

most appropriate stack structure remains a debated

issue, with a number of alternative architectures

offered by various consortiums and leading vendors.

Despite this disagreement, moves have been made

towards standardization, with a general consensus

existing concerning the underlying protocols

necessary in the architecture such as the Web

Services Definition Language (WSDL) Universal

Discovery Description (UDDI) and Simple Object

Access Protocol (SOAP). WSDL, UDDI and SOAP

however, are not alone enough to facilitate complex

and meaningful interactions with and between web

services, which would allow private and public

processes to harness the full potential of this

technology. Currently, many organizations are

attempting to address this problem, with proposals

intended to extend the basic web service

functionality primarily at the level which is often

referred to as the orchestration or choreography

layer of the web services stack (Uldell, 2002). These

extensions are aimed at capturing more meaningful

semantics than simply service invocations, enabling

the modelling and implementation of business

processes in the web service context. Prominent

initiatives in this area include WSCI, and

BPEL4WS. In addition, the importance of this area

is being recognized by emerging products (see e.g.

Collaxa http://www.collaxa.com/home.index.jsp).

An essential component of the next generation of

distributed architectures is message oriented

middleware (MOM). MOM provides the basic

means for target applications to communicate in a

distributed environment. Messaging middleware

however is not a new technology.

The past decade's move from client/server to

Web applications has intensified the need to move

information in real-time between disparate systems

and in a more controllable manner. In response to

these new developments, a set of Web-native

asynchronous messaging technologies has emerged

to take over where their legacy predecessors fall

short. These include products based on standard

implementations such as the Java Messaging Service

(JMS) or those that span multiple standards and

platforms.

In its new role, MOM has gained increasing

deployment and has already delivered great benefits

for communication between disparate systems, and

as a grass roots component of the web services

stack. In spite of the move from propriety networks

to open standards, the fundamental functionality of

MOM has not changed substantially. Looking at

currently available solutions, we see that the focus of

MOM has been primarily to deliver Security

(authorization, digital signatures, non-repudiation);

Reliability and Serializability (guaranteed delivery

in the proper order); and Scalability (high volume

and speed). The technology is driven by mainly two

dispatch models.

One is point to point, where message exchange

takes place between a sender and one recipient. This

is often based on queuing methods, such as the

IBM’s WebSphere MQ series (http://www-

3.ibm.com/software/ts/mqseries/). A second dispatch

model is publish-subscribe, which is used for

content dissemination to multiple recipients or

subscribers. Some essential enhancements to basic

messaging technology have been proposed, for

example in content-based routing which provides a

dynamic model, using the contents of the message to

filter messages to appropriate subscribers, see e.g.

Elvin (Arnold & Segall, 1997), Gryphon (Strom et

al, 1998), READY (Gruber et al, 1999).

3 HARMONIZED MESSAGING

Our vision of a new integration platform that would

provide universal sub-process connectivity has roots

in principles of messaging systems. The messaging

features that are imperative to the success of private

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

and public process communication in the web

context are clearly lacking in current messaging

technologies (see section 2). We aim to extend and

integrate messaging paradigms and use them as key

enabling technology for business process

management.

We believe that the next generation of messaging

technology will extend current ability to

communicate between partners, individual users, and

autonomous, private and often automated business

processes, in a web-centric environment. The

provision of a level of harmonization to multiple

messages often originating from different sources

will form a single custom definable backbone of

newly formed message streams. Such a technology

would present a new and simple way of enterprise

application integration/communication with

substantial degree of outsourcing capabilities, B2B

connectivity and collaborative business process

management. We call this next generation of

messaging: “Harmonized Messaging Technology”

(HMT).

This research problem, as any integration

problem where heterogeneous sources provide

components, is very challenging. Any solutions

offered must not only deal with data integration, but

also structure of hidden sub-processes, providing

interfaces to external partners without violating

privacy or security rules and at the same time

offering new functionality to all involved.

Even shallow inspection of the problem indicates

some serious difficulty. To better position this

complex problem, we base our framework on a set

of assumptions that define the scope of the problem

addressed in this paper.

Our first assumption is that business process

activities are mostly automated as is typical of B2B

environments and web service based architectures.

Our second assumption is that we are aware

about the existence of the components. The issue of

dynamic search and discovery of services is beyond

the scope of this paper.

Under these assumptions and as further

motivation for HMT consider a simple scenario

where multiple business partners are engaged in a

common process. A merchant organization places

orders to two separate manufacturers. Order delivery

by shipment partner needs to be synchronized within

and between the two orders. That is, shipment is to

take place not only when the entire quantity of one

order has arrived, but is to wait for the arrival of the

second order items as well. Orders and shipment

requests can be seen as electronic messages routed

through a messaging middleware. However, current

messaging functionality (publish/subscribe, point-to-

point) does not directly meet such advanced, yet

obvious requirements.

WFMSs provide an effective means of

coordinating business activities with well-defined

dependency relations (sequence, choice, fork etc).

We can use underlying coordination principles of

WFMSs to satisfy coordinative communication

requirements. Such an approach is being explored in

web service orchestration standards like BPEL4WS.

However, workflow systems do not possess effective

means to deal with collaborative form of message

communication.

Figure 2: Coordinative and Collaborative Message

Communication Approaches

The difference between coordinative and

collaborative messaging requirements is depicted in

Figure 2. In coordinative messaging paradigms the

order of message communication between

participants is defined using workflow like

constructs. In collaborative communication

paradigm the exchange of messages between

participants is depicted by linking them up with

communication channels. We propose to merge

coordinative and collaborative messaging paradigms

to effectively satisfy and manage a wide variety of

complex business process requirements. We believe

that this merger will serve the essential requirements

of current business process management systems.

4 ASPECTS OF HARMONIZED

MESSAGING

In this section we will establish the need and

motivation behind harmonized messaging by

presenting a number of cases where specialized

messaging functions are required. These cases are

intended to present a definition of what is meant by

harmonization. Some of these cases can be

(partially) met by existing messaging and workflow

solutions. However, it will become clear that

achieving a combined and extended functionality,

within a single technology, is the requirement of

current business interactions, and the objective of

harmonized messaging.

There are several aspects of messaging which

impact on, and define the scope for message

harmonization. We identify below seven aspects of

FACILITATING BUSINESS PROCESS MANAGEMENT WITH HARMONIZED MESSAGING

harmonized messaging, as a list of our minimum

requirements. However, there is no restriction on

extending this list, if business semantics warrant.

The power of the proposed technology lies in

providing a generic specification mechanism for the

rules and constraints which describe these

interactions.

Coordination

Messages often represent a step in a business

transaction or process. Coordinating the flow of

messages can take the form of most, if not all,

activity coordination structures in workflow/process

management. HMT can facilitate coordination

through multi-step complex routing specifications.

For example:

• Wait for message from A and B to arrive before

sending to C.

Temporal

Temporal constraints represent a critical aspect

of business events. Time driven messages may

depend on absolute time e.g. 2.00 PM on Friday, as

well as relative time e.g. every 4 hours. Example of

time driven messaging can be:

• Keep collecting messages from A and B until a

specific time and then send them to C.

• Wait to send message to B until 3 hours after

receiving message from A.

Correlation

Messages from a single (or even multiple)

senders may be linked in terms of the content they

carry. Correlation can include associating or relating

a new message with a previously received message,

for example:

• Associating or relating a new message with a

previously received message, for example

multiple items of a single purchase order.

• Invalidating a previously received message.

Batching

The need for batching messages is clear from the

above. Batching or grouping may be required due to

message coordination, correlation or time

dependencies. The definition of the batch may thus

encompass many properties, for example:

• Deliver all messages on a given topic from a

given sender at a given time, rather than one a

time as they arrive to the message server.

Filtering

This is essentially sending messages to interested

parties based on message contents (content based

routing). However, advanced filtering may be

required, which takes into consideration a

combination of conditions such as content, time,

sender and others. For example

• Send a message to either B or C depending on

contextual condition.

Transformation

Message transformation may be required for

conformance to formatting restrictions, or for

ensuring that recipients are sent relevant data only.

For example

• Extract essential data on date/time for a shipment

order and send a FYI message to the customer

Composition

The is a very powerful aspect of harmonized

messaging and is also illustrated further in Figure 3.

Composition basically entails extraction of relevant

data from one or more incoming messages and

composing together a system generated message.

For example

• Extract relevant data from A, B and C

respectively and compose message D

Obviously the above functions are to be provided

over and above traditional messaging functions like

queuing and publishing/subscribing. Furthermore, it

is important to note that coordination requirements

are but a part of the overall set of requirements.

Thus, where typical workflow modelling constructs

such as sequence (multi-step), and synchronization

may be applicable, they cannot satisfy the larger

scope of requirements necessary for harmonized

messages. Interestingly, workflow constructs can

then be considered as a special case. A language to

support the specification of harmonization

requirements must additionally at least provide time

related, content dependent and existential conditions.

Considerations into the expressability and

limitations of such a language, is a major research

challenge, and remains an open question at this time.

5 TECHNOLOGY FRAMEWORK

The aspects above identify extensions to various

aspects of messaging. In the overall solution, these

aspects will be manifested through ‘Harmonization

Rules’. The harmonization rules can be defined as a

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

conjunction of a number of different requirements as

represented by the classes above. Clearly, multiple

rules originating from multiple independent parties

may carry some semantic or executable conflicts.

Ways to identify them prior to deployment must be a

part of the overall HMT solution.

Below we will introduce concepts that are

fundamental to the harmonized messaging, and

building blocks for the technology framework:

Collaboration Space

The most fundamental concept in HMT is that of

a Collaboration Space. The concept of a

collaboration space is similar to a database space,

where users, privileges, data and methods may be

defined. In HMT, the collaboration space will

similarly contain information on three key aspects:

• Participants specify the parties involved in a

specific message interaction definition.

• Rules and constraints model the harmonization

requirements using the specification language.

• Message Templates define the structure to which

Messages being exchanged must conform to.

Clearly, at any given time there would be several

messages of one or more defined message template

type being exchanged by multiple participants

within a collaboration space. We call these message

objects. In simple terms, message objects that arrive

in the system may or may not trigger predefined

rules. If and when a rule evaluates to true,

subsequent (system generated) messages are

composed and dispatched. Figure 3 illustrates the

concept of message harmonization for Composition

of messages as given in the previous section. Note

that not all aspects of harmonized messaging can be

graphically shown, as they may involve expressions

with content and time. Thus the real power of the

technology resides in the specification of complex

rules that capture the behaviour of business

interactions.

Figure 3: Message Harmonization

in a Collaboration Space

In order to manage and harmonize message

objects as discussed above, there needs to be a

Harmonized Messaging Management System

(HMMS). The architecture of an HMMS is

obviously a highly specialized and complex issue,

and is beyond the scope of this paper. However, we

present below a brief description of its essential

components.

Interaction Modeler

The interaction modeller provides a toolset to

establish collaboration spaces, identify the

associated participants and message templates, and

in particular to model rules and constraints needed

by the collaboration space to support exchange of

messages. For the latter to effectively take place, the

interaction modeller must be equipped with a

language to express the conditions that govern the

harmonization requirements, which as mentioned

above will range from basic messaging models such

as queuing, publishing and subscribing, to typical

coordination structures as found in workflow

models, to complex expressions for correlation and

batching, the ability to understand expressions with

time and content, and the ability to transform and

create new messages.

Harmonization Engine

The Harmonization Engine is the core driving

force for the system supporting essential

functionality. This engine is primarily responsible

for managing the collaboration spaces defined

within the HMMS. Minimal features of the engine

will include: Access to a persistent storage facility

(HMT databases identified below); Management of

concurrent users building message streams;

Exception handler dealing with unexpected

behaviours; and Transactionability in order to offer

guarantee of completeness of execution

HMT Databases

The HMT framework will be supported by a

number of underlying databases essential for the

persistent storage and data management of various

aspects. These consist of:

• Message Store - Message store allows reliable

and persistent of messages. A relational DBMS

can serve the purpose. The messages need to be

stored in the message store while in transition

from one participant to another and/or awaiting

harmonization rules to be triggered.

• Participants Repository - To store information

about participants, processes and other objects

FACILITATING BUSINESS PROCESS MANAGEMENT WITH HARMONIZED MESSAGING

that need to exchange messages. It will also store

participant profiles (including at least

registration information, privileges, and

requirements).

• Rules and Constraints - The harmonization

engine needs rules and constraints within a

collaboration space to effectively manage and

route the messages. The rules and constraints

repository maintains this information both for

design time and run-time.

• Message Catalogue – Similar to a system

catalogue in a DBMS, the message catalog stores

template definitions for message objects.

• System Log – Will be required to record all

system events to provide reliability and

transactionability.

HMT Gateway

The messaging gateway provides interfaces to

participants to register and connect to the

infrastructure and to send messages to and receive

messages from the collaboration space. A

dispatcher sub-component will evaluate

identification and routing information to correctly

position the messages within the collaboration

spaces.

6 CONCLUSIONS

HMT is intended to provide a platform for cross

organizational process interactions in a web-centric

environment. HMT is not aimed at invoking

applications or monitoring people (it is not a

workflow management system). We have primarily

presented a vision for this next generation of

messaging technology aimed at facilitating complex

business process interactions, typically found in

current e-business environments.

Currently, there is substantial interest in the

industry from vendors, standards bodies, as well as

research communities in this immensely important

area. The HMT differs from these approaches since

it builds upon message interactions as its core

building block. It offers to extend the simple

messaging approaches by adding additional process-

oriented extensions. The key contribution of this

approach is to effectively merge message-oriented

and process-oriented approaches for achieving both

inter and intra enterprise application integration. We

believe HMT can also play a key rule in web

services based enterprise application architectures.

HMT holds many interesting and challenging

research questions. We hope that the open questions

identified in this paper will also motivate other

researchers working in this area, to pursue solutions

to these questions.

REFERENCES

Colomb, R.M & Orlowska, M.E. Interoperability in

Information Systems. Information Systems, 5(1),

pp.37-50, 1994.

Heather Kreger (2001) Web Services Conceptual

Architecture (WSCA) 1.0. IBM Software Group May

2001.

Bussler, Christoph. The Role of B2B Protocols in Inter-

Enterprise Process Execution. 3rd VLDB Workshop

on Technologies for E-Services TES'02

http://gkpc14.rbg.informatik.tu-darmstadt.de/tes02/

Jon Uldell. Orchestrate Services. Info World. July 2002.

http://www.infoworld.com/article/02/07/05/020708pl

weborch_1.html

Arnold D. and Segall B.. Elvin has left the building: A

publish/subscribe notification service with quenching.

AUUG97 Technical Conference. 1997. Brisbane,

Australia.

Robert Strom, Guruduth Banavar, Tushar Chandra, Marc

Kaplan, Kevan Miller, Bodhi Mukherjee, and and

Michael Ward Daniel Sturman, Gryphon: An

Information Flow Based Approach to Message

Brokering. International Symposium on Software

Reliability Engineering '98, 1998.

R. E. Gruber, B. Krishnamurthy, and E. Panagos. The

architecture of the READY event notification service..

IEEE International Conference on Distributed

Computing Systems Middleware Workshop. 1999.

ICEIS 2004 - DATABASES AND INFORMATION SYSTEMS INTEGRATION