This document summarizes key points from the first chapter of a book on service-oriented architecture (SOA). It discusses how SOA is needed to address issues with scalability and flexibility in increasingly complex distributed systems. SOA provides reusable services, an enterprise service bus for interoperability, and loose coupling between services. However, implementing SOA also requires defining policies, processes, and governance to manage the distributed architecture. Web services are one technical approach but are not sufficient on their own. In practice, a successful SOA must be tailored to an organization's specific needs and supported long-term.

1. Book Author: Nicolai M. Josuttis
Chapter One: Motivation
IT-Slideshares http://it-slideshares.blogspot.com/

2. 1.0 Introduction
 Social Market economy is being replaced by a global
market economy
 The key is flexibility (maintainability tradeoff)
 Processes and Systems are becoming more complex with
heterogeneity that lead to decentralization.
 Old ways of dealing with scalability and distribution failed
to work (no longer centralization, harmony, control)
 Business/IT gaps due to semantics (different meanings)
 SOA is what needed (scalable, flexible, understandable)
 Services: self-contained business functionalities
 Infrastructure: Enterprise Service Bus (ESB) - flexible
 Policies and Processes: deal with management changes

3. 1.0 Infamous Hockey-Stick
SOA is often explained with brief statements and
prototypes, which leads to a problem illustrated by the
infamous “hockey stick function”. Up to a certain
level of complexity, the amount of effort required is
low, and things look fine. But when this level of
complexity is exceeded, the amount of effort required
suddenly begins to rise faster than the benefit you
gain, and finally, things collapse. Just introducing an
infrastructure like Web Services might help us to a
certain level of complexity, but this is not enough to
guarantee scalability. The whole architecture, dealing
with services, infrastructure, policies, and processes,
must match.

4. 1.1 Characteristics of Large
Distributed System
 SOA has characteristics of large distributed system
 Large system deal with ‘Legacies’ (old platforms, back-ward compatibility …)
 Heterogeneous, decentralized, fault-tolerant ?
 Different programming languages
 Different platforms
 Different design/programming paradigms
 Different middlewares
 Can harmonization of heterogeneous systems help in this constant changing
world ?. (depends on the frequencies of changes)
 Different owners (teams, departments, budgets, schedules …). Organizations
are complex business systems, within which a change in and one component is
likely to have an impact on other components.
 May contain redundancy intentionally to manage runtime penalties.
 Managed redundancy is not so bad to avoid bottlenecks
 Need master of data sources where all redundancy derived from it.

5. 1.2 The Tale of the Magic Bus
 Buses represent high interoperability. The idea behind
them is that instead of creating and maintaining
individual communication channels between different
systems, each system only has to connect to the bus to
be able to connect to all other systems
 N x (N-1)/2 connections in n systems reduced by factor
of (n-1)
 Enterprise Application Integration Bus (EAI bus)
replaced by Enterprise Service Bus (ESB).

6. 1.2.1 The Tale of the Magic Bus

7. 1.3 What can we learn from the
Tale of the Magic Bus
 There is no ‘Magic Bus’ without careful control of
service dependencies and interactions  chaos
 ESB represents high interoperability that simplifies
connectivity but it will fail if it has unstructured
design
 Why do we replace global variable with procedures ?
 Or Using modules/components instead of business
object model ?
 Lesson learnt:
 Need structures provided by technical and
organizational rules and patterns.

8. 1.4 History of SOA
 1994- Alexander Pasik: coined the term SOA to stress
“server orientation” in Client/Server concepts
 1996- Gartner analysts, Roy W. Schulte
 Web Services is NOT SOA and vice versa
 2000- Microsoft’s web services bring SOA to
mainstream
 2K+: Other vendors participation: IBM, Oracle, HP,
SAP, and SUN. (B2B hype)
 Booch: SOA strategy requires time and effort.

9. 1.5.1 SOA in five slides: Slide 1 SOA
 Service-oriented architecture (SOA) is a paradigm for the
realization and maintenance of business processes that
span large distributed systems.
 It is based on three major technical concepts
 A service is a piece of self-contained business functionality
that bridges IT/Business gap. E.g
 Simple service: store/retrieve customer data
 Complex service: business process of customer’s order
 An enterprise service bus (ESB) is the infrastructure that
enables high interoperability between distributed systems,
platforms, technologies for services.
 Loose coupling is the concept of reducing system
dependencies. NOTE: Loosely coupled distributed systems
are harder to develop, maintain, and debug.

10. 1.5.2 Slide 2 Policies and Processes
 Distributed processing requires collaboration from
every functional units of the company
 Roles, Policies, and processes, Lifecycle…etc must be
set and requires lot of efforts
 Setting up the appropriate policies and processes
usually takes more time than working out the initial
technical details.
 Implementing model-driven service development
policy

11. 1.5.3 Slide 3: Web Services
 Web Services are one possible way of realizing the
technical aspects of SOA. (Note: there are more
important things than technical aspects)
 Web Services inherent issues
 Not yet mature to guarantee ‘interoperability’
 Insufficient to achieve loosely coupling approach
 Web Services therefore should ‘not’ be the final
standard for system integration. (Only use in specific
infrastructure aspects)

12. 1.5.4 SOA in Practice
 In theory, theory and practice are the same. In practice, they
are not.
 General business cases and concepts might not work as
well as expected when factors such as performance and
security come into play
 You will have to build your specific SOA—you can't buy it.
To craft it, you'll need time and an incremental and
iterative approach
 Whether you introduce SOA is not what's important. The
important thing is that the IT solution you introduce is
appropriate for your context and requirements.
IT-Slideshares http://it-slideshares.blogspot.com/

13. 1.5.5 Slide 5: SOA Governance and
Management Support
 You need a central team that will determine general aspects
of your specific SOA. Balance governance
 You need the right people. Large systems are different from
small systems, and you need people who have experience
with such systems
 First things first. Don't start with the management of
services. You need management when you have many
services.
 You need support from the CEO and CIO. SOA is a strategy
that affects the company as a whole. You need money for
the long run. Cutting SOA budgets when only half of the
homework is complete is a recipe for disaster.