Preconditions and Postconditions:

Mapping of heterogeneous data is important in

any enterprise application
middleware. It provides the technical basis

for integrating services with each
other, so that the results returned by one

service can be used by follow-up
services.
The next level addresses the questions, about

under what conditions a
certain activity can be executed, and what the

result of an activity execution
is, i.e., preconditions and postconditions of

activities. Interestingly, in business
process modelling, preconditions and

postconditions are already captured. In
event-driven process chains, for instance,

preconditions and postconditions are
represented by events, although in a

relatively informal fashion.
For example, if the arrival of an order

message triggers an activity to
store the order, then an event order arrived

is connected by control flow to
a function store order. The outgoing edge of

this function is connected to an
event order is stored. The order arrived event

characterizes the precondition
of the function, This type of informally

specified precondition and postcondition of a

function
in a business process is suitable for

fostering the understanding of process
models by human stakeholders. To be usable for

composing services realized
by software, the preconditions and

postconditions need to be specified in a
more precise way.

Ontologies and Data Mappings:

Semantic service specifications are required

that are based on domain ontologies.
Domain ontologies can be considered to be data

models that all process
participants have agreed upon. Ontologies in

computer science are characterized
as data models that represent a set of

concepts within a domain and the
relationships between those concepts.
A domain ontology is always associated with a

set of stakeholders, who
need to agree on the domain ontology. An

ontology has been described in
Gruber (1993) as an explicit specification of

a conceptualization The domain ontology shown

can be used to integrate services provided
by software systems. In an enterprise

application integration scenario, typical
systems to integrate are customer relationship

management systems, or CRM
systems, and enterprise resource planning

systems, or ERP systems. For instance,
the full name data field of the customer

relationship management system is
mapped to the Name concept in the domain

ontology. Since the street address
is stored in two fields of the enterprise

resource planning system data structure,
the field Strasse is mapped to StName, and

Hausnummer is mapped to
the Number concept of the ontology.
If the data fields of the application systems

are mapped to the domain
ontology, then a mapping of the data can be

achieved automatically at run
time. Assume that there is a service of the

customer relationship management
system that returns a parameter of data type

Cust 234. This data can be fed
into a service that takes a parameter of data

type Adr32 if the appropriate
data mapping is performed.If there is a domain

ontology in place and the data structures of

the systems
are mapped to the domain ontology, then this

data mapping can be
performed automatically.

Static and Dynamic Service Binding;

The dynamic discovery of services is

illustrated by a set of examples in the
context of a composite application in the

travel domain. The travel application
allows customers to select trips, make

reservations, and confirm reservations by
providing credit card information. In order to

allow this, the travel application
invokes a credit card withdrawal service

provided by a bank.
This example is used to explain different

types of service matchmaking
and service binding, namely static binding and

dynamic binding; service composition
based on semantics will be discussed

afterwards.
In static binding, the service is bound to the

application at development
time. In the travel application example shown

in Figure 7.16, the service
invocation in the travel application is

represented by a rounded rectangle
marked CCW for credit card.
There are three service providers that have

implemented a credit card
withdrawal service, all of which can be used

by the travel application. These
providers are BankA, BankB, and BankC,

representing any institutions that
provide such a service. (The services provided

by the organizations are depicted
by small circles, as with interfaces in UML.)
The question that developers face now is which

of the three implementations
of the credit card withdrawal service should

they decide to use? And
when should this decision be made? The former

question is subject to existing
legal contracts between the organizations

involved as well as to costs associated
with using a particular credit card withdrawal

service implementation.
The latter question can be reformulated to the

question about when to bind
the credit card withdrawal service

specification to the service implementation.
In a static binding, the external service

implementation is bound to the
travel application at development time. This

means that the use of the credit
card withdrawal service by BankB is hardcoded

in the travel application.
Today�s Web services technologies provide

valuable information for coding
this integration. Service specifications in

the Web Services Description Language
provide the information on how a particular

service is invoked. Based
on the textual and technical description of

the service, the developer of the
travel application can provide the mapping of

the internal variables to the
data that the external service requires.
Ambiguities in service description are

effectively resolved by the programmer
of the travel application by the designing of

an interface to the external service. This

type of static binding is appropriate in

environments where the
service landscape is relatively static.

Advanced Service Composition by Example in business management architectures:

This section introduces advanced service

composition by an example. Our example
is from the call centre domain, where phone

calls by customers come in
and call centre agents serve these calls using

software systems, in particular, an
enterprise resource planning system and a

customer relationship management
system. These systems realize services that

make up a service composition
used by the call centre agents.
The scenario is described as follows. In a

call centre environment a customer
calls to request certain information. Using

the phone number of the incoming call, the

customer relationship management system gets

hold of the
customer address. This address information

is�after suitable data mapping
is performed�fed to the enterprise resource

planning system that provides
information on the customer calling the call

centre agent. This domain ontology allows us

to specify a service having a phone number
as input and an address as output, so that the

contact information returned is
not just any contact information, but the

contact information for the customer
with the specified phone number.
This information is required for a precise

specification of the service; otherwise
the relationship between input and output data

is imprecise. Another
service might exist that also has a phone

number as input and an address as
output, that returns the address of the phone

provider for the specified phone
number instead. Syntactically, service S3 is

equivalent to service S1 with regard to input
and output data, but instead of returning a

customer�s address it returns the
address of the phone provider supplying the

specified phone number. Such a
difference of functionality is not visible in

syntactic definitions, but can be
represented and distinguished by semantic

specifications. CRM system with the service
S2 provided by the ERP system is shown. In

this way, these services can
participate in a business process, shown in

the upper part of that figure. The
semantic information can be used to decide

whether two services actually match

semantically, so that they can be sequentially

executed in the context
of a given business process.

Data-Driven Processes: Case Handling:

Case handling aims at balancing process

orientation with data orientation to
control the execution of business processes.

The motivation can be derived
from business process reengineering, because

one of its main goals is to overcome
the fragmentation of the work in

organizations.
The introduction of this fragmentation of work

was useful in manufacturing
since the early days of industrialization,

where it led to massive increases in
productivity, because highly specialized

workers perform isolated pieces of
work with high efficiency. Once the worker has

finished a piece of work, the
manufactured artefact is handed over to the

next worker in line.
The fragmentation of work has been transferred

to the information society.
Workers are expected to conduct a single piece

of work in a highly efficient
manner, without a complete picture on the

contribution of the work to the company�s

goals. To control the combination of the

fragmented work, complex
organizational structures have been invented.
With the presence of information technology,

the role of workers has
changed. Now the knowledge worker is at the

centre, responsible for conducting
and organizing her work. The knowledge worker

is highly skilled, so
she can conduct a broad range of activities

required to fulfil business goals of
the company. An insurance claim, for example,

can be processed by a single
person, so that handover of work can be

avoided. Only in specific, seldom
occurring cases is expert support required.
Case handling takes into account this active

role of the knowledge worker
by accepting her expertise and experience to

drive and control the case. Since
traditional workflow technology prescribes the

activities and their execution
ordering, there is little room for knowledge

workers to deviate from the prescribed
process. As a result, traditional workflow

technology appears too restrictive
in these settings.
However, there is still support that flexible

business process management
systems can provide. Since knowledge-intensive

business processes typically
are centred on data processed in the context

of a particular case, the handling
of data requires specific attention.
A case is a product that is manufactured, and

at any time knowledge workers
should be aware of the overall case. Examples

of cases are the evaluation
of a job application, the verdict on a traffic

violation, the outcome of a tax
assessment, and the ruling for an insurance

claim. To illustrate the basic ideas of case

handling, consider the activities A and
B of a business process that are ordered by

control flow A ! B. As a result,
B can only be enabled (and therefore can only

start) after A has terminated.
This type of ordering constraint is a key

ingredient of business process
management in general and workflow management

in particular. While in
many business process scenarios this

traditional workflow approach is adequate,
in knowledge-intensive domains, where an

active role of the knowledge
worker drives the process, more flexible

approaches are required.
For instance, assume that A does not create

its data on termination, but
while it runs. Assume further that B can start

working once data values
created by A are available. Then, B can start

working on these data, while
A creates the remaining data values. In this

case, the control flow constraint
between A and B restricts a useful execution

ordering, in which B starts
working before A completes.
One could argue that the level of granularity

of the modelled activities
might not be adequate. If the generation of

each data value is represented by
a single activity in a business process, then

the same process instances can
be achieved. However, since the number of

activities would become very high,
complex process models that are hard to

understand and maintain would
result.

Degree of Structuring in business process management architectures:

If the business process model prescribes the activities and their execution
constraints in a complete fashion, then the process is structured. The different
options for decisions that will be made during the enactment of the process
have been defined at design time. For instance, a credit request process might
use a threshold amount to decide whether a simple or a complex credit check
is required, for instance, 5000 euros. Each process instance then uses the
requested amount to decide on the branch to take.
Leymann and Roller have organized business processes according to dimensions
structure and repetition. They coined the term production workflow.
Production workflows are well structured and highly repetitive. Traditional
workflow management system functionality is well suited to supporting production
workflows.
If process participants who have the experience and competence to decide
on their working procedures perform business process activities, structured
processes are more of an obstacle than an asset. Skipping certain process activities
the knowledge worker does not require or executing steps concurrently
that are ordered sequentially in the process model is not possible in structured
business processes.
To better support knowledge workers, business process models can define
processes in a less rigid manner, so that activities can be executed in any order
or even multiple times until the knowledge worker decides that the goals of
these activities have been reached. So called ad hoc activities are an important
concept for supporting unstructured parts of processes.

Case handling is an approach that supports knowledge workers performing
business processes with a low level of structuring and, consequently, a high
level of flexibility. Rather than prescribing control flow constraints between
process activities, fine-grained data dependencies are used to control the enactment
of the business process.

Business processes in Degree of Repetition work through control:

Business processes can be classified according to their degree of repetition.
Examples of highly repetitive business processes include business processes
without human involvement, such as online airline ticketing. However, business
processes in which humans are involved can occur frequently, for example,
insurance claim processing. If the degree of repetition is high, then investments

in modelling and supporting the automatic enactment of these processes pay
off, because many process instances can benefit from these investments.
At the other end of the repetition continuum, there are business processes
that occur a few times only. Examples include large engineering efforts, such
as designing a vessel. For these processes it is questionable whether the effort
introduced by process modelling does in fact pay off, because the cost of
process modelling per process instance is very high.
Since improving the collaboration between the persons involved is at the
centre of attention, these processes are called collaborative business processes.
In collaborative business processes, the goal of process modelling and enactment
is not only efficiency, but also tracing exactly what has actually been
done and which causal relationships between project tasks have occurred.
This aspect is also present in the management of scientific experiments,
where data lineage is an important goal of process support. Since each experiment
consists of a set of activities, an increasing fraction of the experimentation
is performed by analyzing data using software systems. The data
is transformed in a series of steps. Since experiments need to be repeatable,
it is essential that the relationship of the data sets be documented properly.
Business processes with a low degree of repetition are often not fully automated
and have a collaborative character, so that the effort in providing
automated solutions is not required, which lowers the cost.