Advanced Service Composition:

So far, business process activities have been

described by simple terms. What
is actually meant by these terms, like

AnalzyeOrder, is determined by the
reader. The intention of the terms used by the

process designer and the semantics
associated with these terms by the process

participants is, hopefully,
similar.
To improve the understanding of business

process diagrams at a nontechnical
level, textual explanations are associated

with business process models,
expressed in, for instance, event-driven

process chains. In case there are
ambiguities in a process model or certain

process parts are not clear, the
process participant can ask the process

designer about the intended meaning.
The process designer will explain the

rationale, and the process participant
will comprehend. In some cases, these

discussions might lead to a refinement
of the process model, since the process

participant might have identified an
unclear and ambiguous part in the process

model.
In this book we are very much interested in

business processes that are
enacted in software. Services can only be

composed in a correct way, if they
operate on the same domain concepts. For

instance, a service that returns
customer data can be combined with a service

that takes customer data as
input. In this case, they both operate on the

same domain concept, i.e., the
customer.
As discussed in Section 7.3, WSDL provides a

syntactic interface description
language, detailling the data types of input

and output parameters. Since
the Web services that contribute to a service

composition have most likely
been developed independently of each other,

the data types of these services
will, in most cases, not match.
Typically, these syntactic differences are

identified and the resulting problems
are solved by system architects and software

developers, using, for instance,
data mapping techniques. If compositions

involving many services need
to be developed, considerable overhead can be

expected due to heterogeneous
data types used by the Web services.
A simple example shows that syntactic

integration is not sufficient for
integrating services with each other. We

assume that a certain product needs
to be purchased and that there are two

services that return the price of the
product. Assume also that the product can be

identified by a unique product
identifier.
A price-finding application invokes the

services with the identifier of the
desired product. Both services return values.

Assume the textual descriptions
of these services indicate that the services

return the price in euros. Note that
this information about the currency is not

available from the return parameter
price of the service in WSDL file.
Even parameter names like europrice do not

help much, since the user of
the service cannot be sure that the price is

really in the euros currency.
There might be additional semantic differences

in the data returned by
services. Assume that one service returns 120

and the other service returns
118. Since the concept of price is not agreed

upon by the providers of the
services, the following issue might occur. The

price 120 includes value-added
tax, VAT, while the price 118 does not.
As a result, the price that appears to be

lower turns out to be higher
because it does not include VAT. Due to the

different semantics of the return
parameters, the price-finding application

returns a wrong result. This problem
is due to the missing semantics comparability

of the two services. Since at a
software layer there are few options for

asking the service provider about the
exact semantics of their services�as at the

application process level�this is
a severe problem.

Data Dependencies in Properties of Business Processes:

Application data are an integral part of

business processes. Data can be created,
modified, and deleted during the execution of

business processes. Since
business processes consist of a set of

activities that are related, these activities
operate on an integrated set of application

data.
Data in business process models has two

aspects, both of which need to
be covered:
� Data that activity instances manipulate by

invoking applications or services.
� Data dependencies between process

activities.
The former issue is dealt with in the

operations subdomain. In service-oriented
systems architectures, for instance, the

parameters of service invocations are
specified, so that data can be communicated

correctly with software systems
at run time.
At the process level, data dependencies

between process activities is typically
described by data flow. An example of data

flow in a business process in
the financial sector is given. A credit

approval business process contains activities
to enter a credit request, to assess the risks

of granting the credit, and
to inform the customer about the decision made

by the financial institution.
The activities of this process model operate

on case data, in particular,
the credit request. The credit request can be

represented by a record data
type with fields for the name and address of

the credit requester, the amount
requested, and other information, such as the

risk related to granting the
credit.
There are data dependencies between the

activities mentioned. The Collect
Credit Info activity is the first activity

performed. Only when this data
is available, can the risk be assessed in the

Assess Risk activity, the final
decision be made(Decide), and the requestor be

notified (Notify). Therefore,
the ordering of the activities in the business

process is strongly related to the
data dependencies of the activities.
The process model is illustrated in Figure

6.1, using a graph-based process
language that explicitly represents input and

output parameters of activities
This diagram shows that data dependencies have

implications on the ordering
of activities in the process: the Assess Risk

activity can be started only
when the credit information is available.

Since this data object is provided as
output parameter CreditInfo of the Collect

Credit Info activity, this activity
needs to complete before the risk can be

assessed, implying an ordering
between these activities.
These considerations hold only if it is

assumed that an activity instance
requires its input parameters at the start. If

this constraint is relaxed and
input parameters can be consumed after an

activity instance has started,
then in a process with a data flow A ! B, B

can actually start before A
terminates. At some point�when the input

values are required�B needs to
wait for A to deliver the required data.
This assumption can also be relaxed at the

producer side of data. If we
allow activities to generate data while they

are running, then the generated
data can be taken by the follow-up activity,

so that activities can execute
concurrently, realizing a data value stream

between them.
While most workflow management systems assume

that input data is available
up front and that only on completion, does an

activity instance write
output data values, some approaches, for

instance, the BPMN, relax this assumption.
The use of data dependencies for process

enactment control will be discussed
in more detail in the context of case handling

in Section 7.5, where
data dependencies�and not the process

structures�are the driving force for
process control.

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.