SOA 实践：分布式系统设计的艺术

5星 · 超过95%的资源需积分: 9 59 浏览量更新于2024-07-25 收藏 3.21MB PDF 举报

"SOA in Practice - The Art Of Distributed System Design" SOA（Service-Oriented Architecture，面向服务架构）是一种设计分布式系统的方法论，旨在通过将功能分解为一系列可重用的服务来提升系统的灵活性、可扩展性和互操作性。尼古拉·M·乔斯蒂斯（Nicloai M. Josuttis）的著作《SOA in Practice》深入探讨了在实际环境中如何实施和设计SOA。这本书版权属于2007年。 SOA的核心概念是服务，这些服务具有明确的边界，提供特定的功能，并通过标准接口进行通信。服务之间松散耦合，这意味着一个服务的变化不会直接影响到其他服务，允许系统组件独立演化。这种设计方式使得SOA能够适应快速变化的业务需求和技术创新。在《SOA in Practice》中，读者可能会学习到以下几个关键知识点： 1. **服务的定义与设计**：理解服务的基本属性，如服务契约、服务接口、服务实现和服务消费者。如何根据业务需求来定义服务的粒度和边界，以及如何设计服务的API。 2. **服务发现与组合**：学习如何让服务消费者找到并使用服务，包括服务注册、目录和发现机制。同时，探讨如何通过服务组合构建更复杂的应用逻辑。 3. **消息传递与协议**：研究不同类型的通信协议，如HTTP、SOAP、REST等，以及它们在SOA中的应用。理解消息传递模型，如请求-响应、发布-订阅等。 4. **服务治理**：讨论服务生命周期管理，包括服务版本控制、服务质量（QoS）、安全性、监控和故障恢复策略。 5. **数据管理**：探讨在SOA中处理数据的一致性、事务和安全性问题，以及如何利用数据抽象和数据绑定技术。 6. **企业服务总线（ESB）**：理解ESB的角色，它是如何作为SOA基础设施的一部分，促进服务之间的交互，并提供额外的功能，如路由、转换和协议桥接。 7. **案例研究与最佳实践**：通过真实世界的案例分析，了解SOA实施的成功因素和潜在挑战，以及如何避免常见的陷阱。 8. **相关技术与工具**：介绍支持SOA实现的各种技术，如XML、WSDL、UDDI，以及相关的开发工具和框架。除了书籍本身，O'Reilly还提供了多种相关的在线资源，如相关的书籍、文章、博客、样本章节和代码示例，帮助读者深入理解和应用SOA。此外，O'Reilly还举办了一系列的会议，聚焦开放和新兴技术，为开发者提供交流和学习的平台。Safari Bookshelf则是一个在线参考图书馆，程序员和IT专业人员可以在这里搜索和订阅超过1000本书的内容，以便于持续学习和研究SOA及相关技术。通过《SOA in Practice》，读者不仅可以掌握SOA的基础理论，还能获得实践经验，从而在实际项目中成功设计和实施面向服务的架构。

PREFACE xv

In addition, I want to thank my kids, who help me to be well grounded and understand

what really matters. Thanks to Lucas, Anica, and Frederic.

Last but not least, I thank Jutta Eckstein for the role she has played regarding this book

and in my life. Jutta convinced me to go public with my SOA knowledge, gave me incred-

ible support, and makes my life a lot more worth living day by day.

Enjoy your life.

—Nicolai M. Josuttis

Braunschweig, July 2007

2 CHAPTER ONE

In addition, we have to solve the problem of the business/IT gap. This gap is primarily one

of semantics—business people and IT people appear to speak and think in entirely differ-

ent languages. The new approach must bring business and IT much closer than ever

before.

Service-oriented architecture (SOA) is exactly what’s needed. It’s an approach that helps sys-

tems remain scalable and flexible while growing, and that also helps bridge the business/IT

gap. The approach consists of three major elements:

• Services, which on the one hand represent self-contained business functionalities that

can be part of one or more processes, and on the other hand, can be implemented by

any technology on any platform.

• A specific infrastructure, called the enterprise service bus (ESB), that allows us to

combine these services in an easy and flexible manner.

• Policies and processes that deal with the fact that large distributed systems are heteroge-

neous, under maintenance, and have different owners.

SOA accepts that the only way to maintain flexibility in large distributed systems is to

support heterogeneity, decentralization, and fault tolerance.

Sounds like a dream, doesn’t it?

The problem is that you can’t just buy SOA; you have to understand it and live it. SOA is a

paradigm. SOA is a way of thinking. SOA is a value system for architecture and design.

This book will explain the paradigm and value system of SOA, drawing on real experi-

ences. SOA is often explained with brief statements and prototypes, which leads to a

problem illustrated by the infamous “hockey stick function” (see Figure 1-1).

Up to a cer-

tain 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.

Too often, SOA is only partly explained and installed. Just introducing an infrastructure

like Web Services might help up to a certain level of complexity, but this is not enough to

guarantee scalability. The whole architecture, dealing with services, infrastructure, poli-

cies, and processes, must match. Once you understand how to implement SOA, it’s not

hard, but it takes time and courage. (OK, so it is hard.) And a lot of effort is required to

help people understand (beginning with yourself). If you’re not willing to put in the

effort, you will fail.

Before we get into the details, I’d like to provide a foundation for the rest of this book by

talking about the context and history of SOA. The following sections will present some of

the “tales and mystery” of SOA to help you get familiar with SOA.

* Thanks to Gregor Hohpe, who told me about the “hockey stick function” at OOP 2006.

1.1 CHARACTERISTICS OF LARGE DISTRIBUTED SYSTEMS 3

1.1 Characteristics of Large Distributed Systems

SOA is a concept for large distributed systems. To understand SOA, you have to under-

stand the properties of large distributed systems.

First, large systems must deal with legacies. You can’t introduce SOA by designing every-

thing from scratch. You have to deal with the fact that most of the systems that are in use

will remain in use. This also means that establishing SOA is not a project like designing a

new system. It involves changing the structure of an existing system, which means you

have to deal with old platforms and backward-compatibility issues. In fact, SOA is an

approach for the maintenance of large system landscapes.

By nature, all large systems are also heterogeneous. These systems have different purposes,

times of implementation, and ages, and you will find that the system landscapes are accre-

tions of different platforms, programming languages, programming paradigms, and even

middleware. In the past, there have been many attempts to solve the problems of scalabil-

ity by harmonization. And, yes, harmonization helps. Withdrawing old platforms or

systems that are no longer maintainable is an important improvement. But chances are

that your systems will never be fully harmonized. Right before you remove the last piece

of heterogeneity, a company merger, or some other change will open Pandora’s box again.

One reason for the heterogeneity is that large systems and their data have an incredibly

long lifetime. During this lifetime, new functionality that promotes the business is devel-

oped by adding new systems and processes. Removing existing systems and data may

seem to have no business value, but such changes are investments in the maintainability

of your system. Often, these investments come too late, and become incredibly expensive

because the systems are out of control, and all the knowledge about them is gone.

By nature, large systems are complex. For this reason, finding out the right places for and

determining the effects of modifications can be tough. As [Spanyi03] states:

There is no such thing as a “quick fix...“. Organizations are complex business systems,

within which a change in any one component is likely to have an impact on other

components.

FIGURE 1-1

. The hockey stick function

Complexity

Effort

剩余343页未读，继续阅读

jiangdmdr

粉丝: 58
资源: 764

SOA 实践：分布式系统设计的艺术

SOA IN PRACTICE

SOA In Practice

SOA 实践

SOA方法与实践_SOA in Practice The Art Of Distributed System Design（英文版）

Implementing SOA: Total Architecture in Practice

Implementing SOA : Total Architecture in Practice

Wesley.Implementing SOA Total Architecture in Practice Apr 2008

REST实战(REST in Practice)

REST in Practice: Hypermedia and Systems Architecture

面向服务架构（SOA）及其实践

最新资源