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.