SOA may turn out to be little more than a
technological fire drill if we are ambivalent about the roles and responsibilities of legacy software
in our existing and future organizational strategies; if we fail to tie together past, present, and future
software development initiatives; and if we disregard the contributions of previous generations
of architectures to today??™s business operations. Indeed, the idea of properly bridging new and old
software technologies is a novel one. But what about establishing a more holistic view of the
technological inventory that we have been building up for years? Can we treat all our software
1
2 Ch. 1 Introduction
assets equally in terms of their analysis, design, and architectural value propositions? Can we
understand their collaborative contribution to our environment without being too concerned about
their underlying languages and implementation detail? Can we name these assets services? Can
we conceive of them as service-oriented entities? Are they not built on similar SOA strategies
and principles?
This book introduces service-oriented modeling mechanisms that will enable us to conceive
software products that we have been constructing, acquiring, and integrating during the past
few decades as service-oriented constituents. These entities??”either legacy applications written in
languages such as COBOL, PL1, Visual Basic, Java, C++, C#, or diverse empowering platforms
and middleware??”should all take part in an SOA modeling framework.
Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25