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.