Information Technology Reference
In-Depth Information
1.
Loose coupling.
Every service is atomic, self-describing, accessible, declar-
ative, stateless and composite.
2.
Contracted.
Services in an SOA are represented by a contract that de-
scribes its inputs, outputs, access policies, quality-of-service requirements,
and error-handling procedures.
3.
Discoverable.
Services should be able to be discoverable at the time of
execution.
4.
Addressable.
Services should be uniquely identifiable in a network.
5.
Distributed.
Services in an SOA are separated by geographic and machine
boundaries and, therefore, must be good netizen applications, i.e. they
must be developed with the ability to recover from loss of communication.
6.
Point-to-Point.
At any point in time one consumer uses one and only one
producer.
In particular, the stateless nature of services (1), the pure point-to-point be-
havior (6), and discovery at execution time (3) deserve a closer look. We shall
not go into the details in this topic, but refer to [42, 79] for a more in-depth
discussion of the related issues.
The term “service”, in connection with SOAs, is again often used synony-
mously with “Web service”. However, in general, services in an SOA are not
necessarily Web services in the strict sense. Rather, they simply denote any
software component that is accessible over an arbitrary protocol. Platform in-
dependence, programming-language independence, and the use of WSDL are
not necessary criteria.
4.2 The Origins of Web Services
Efforts towards the development of common standards for the development
of distributed applications have a long history in computer science. Following
the usual terminology in software engineering, technologies which offer an
abstraction layer over the actual communication media are often subsumed
under the general term “middleware”.
Numerous earlier attempts to establish a single standardized middleware
solution in the past either failed completely or were restricted to use within
enterprise boundaries. In particular there has not been vendor-spanning agree-
ment on how such a standardization should look.
In the early 1980s, Birell and Nelson [15] introduced the Remote Pro-
cedure Calls (RPC), the first widespread technology for invoking proce-
dures in distributed systems. The RPC definition was released in an ab-
stract fashion, hiding implementation details from the developer. In com-
bination with a standardized interface description language, RPC offers a
platform- and programming-language-independent mechanism for embedding
distributed procedure calls in applications.
The additional requirements of real-world applications and the wide ac-
ceptance of the object-oriented paradigm have led to various extensions of
Search WWH ::
Custom Search