Defonds 的专栏

在现实世界中，SOA 常常是失败的。确保 SOA 成功的最好的实践是熟悉 SOA 的设计模式和成功案例。一个成功案例SOA 是解决数据管理问题的一个强大工具。在你的企业里是否存在数据不一致的问题？将存在这种问题的数据实体的 CRUD (Create、Read、Update 和 Delete) 都封装在同一个服务中。这是对你的数据进行集中控制和方便访问的一个简单办法。我们这个成功案例就是这样 - A

RPC vs SOAP无论在商业、政治、人际关系，甚至在拯救生命的过程中，通信在任何领域都是至关重要的。通信被证明最重要的另一个领域是计算机网络。如果没有合适的通信手段，一个典型的服务请求者和服务提供者就无法达成。在互联网领域中，有一个叫做 Web Service 的事物。它主要适用于网络中两台电子设备之间的简单通信。截至目前来讲 Web Service 中最常用的就是 RPC (Remote P

灯光、音乐、白色礼服、领带、高雅的房间。这是什么？对于人类来讲回答这种问题很简单 - 这是因为我们人类的大脑能够很好地对事件的识别和解释进行适配。但是在技术的世界里，复杂事件处理 (Complex Event Processing，CEP) 仍然是一个具备挑战的新兴领域。事件是什么？事件就是改变。被称为事件监视器的工具被用来检测时间、状态、位置、水平等方面的改变。先设置一个临界值 - 突破这些临界

乍看之下 SOA 的安全似乎没有什么特别之处。毕竟，它 (和其它架构场景一样) 涉及相同的基本主题，如认证、授权、身份、信任、机密性、完整性以及策略管理。尽管如此，SOA 架构其实更加难以进行安全把控 - 足以让安全分析师累成狗。1. 安全不能够违反 SOA 设计原则SOA 服务是可以服用的、松耦合的、可以发现以及可协同的。安全不能够妨碍 SOA 的 9 大设计原则。2. 遗留的安全模型SOA 常

SOA 架构设计原则曾经被深受误解。SOA 设计原则实际上只是一系列经久考验的针对服务设计的最佳实践。《SOA 指南》系列搜集到的关于 SOA 的资源包括概述、设计原则以及安全最佳实践。范围工具基础SOA 图解一张图来帮你理解 SOA。SOA 市场打造你自己的企业级 SOA 市场。SOA 解惑一些误导的澄清。现实世界里的 SOASOA 理想愿景之外的一面。大 SOA世界上最大的 SOA。设计最佳实

SOA 曾经一度是技术领域中最难以理解的一个概念。SOA 似乎让很多人感到困惑 - 一般来讲这是由于人们认为它拥有几乎神奇的力量。事实上 SOA 是一个很简单的概念：SOA 由诸如 C++ 和 Java 之类的面向对象语言里的设计原则演化而来。SOA 将这些个设计原则使用于提升到企业级应用。它为企业级应用建立了一个可重用的服务库，库里的服务彼此之间是松耦合的。SOA 已经成为企业级应用架构师们最喜

SOA 解惑SOA 不是一种技术，它是一种设计方法。最近一段时间我碰到了很多关于 SOA 的具有误导性的文章。尤其是，有些人混淆了 SOA 和诸如 BPM、ESB 以及复合事件处理 (CEP) 之类的技术之间的关系。这些困惑其实是没有必要的，因为 SOA 和这些技术之间的关系非常简单。SOA 和 ESB9 个 SOA 设计原则之一就是服务之间要松耦合。ESB 是实现 SOA 服务之间解耦的最常见的

Web Service 安全 (WSS) 是对 SOAP 协议的一个安全加固。WSS 允许对 SOAP 消息进行签名和加密。它还允许给 SOAP 消息附加安全令牌。可以扩展的体系结构WSS 拥有一个可以扩展的体系结构，能够支持可插拔的签名格式以及加密算法。WSS 还支持各种安全令牌，包括 X.509 证书、Kerberos 认证、用户名/密码、SAML 安全标记以及自定义令牌。WSS 并不保证安全

每个人都知道 SOA 的安全将会是一个挑战。但是为什么呢？经常会使 SOA 安全复杂化的 9 个要素：遗留应用的安全将服务和应用松耦合跨组织界限操作的服务动态的信任关系组合服务形形色色的新老技术混杂需要不断地遵循越来越多的标准列表解决方案的灵活性和可以定制性的要求1. 遗留应用的安全封装了遗留应用的 SOA 服务必须要考虑到遗留应用的安全模型。很多遗留应用有着硬编码的、专有的安全模型。2. 将服务

SOA 设计原则可以追溯到 2004 年。从那以后，SOA 是典型的以服务编制 (orchestrated，译者注：orchestrated 在字面上翻译为 "管弦乐编曲"，而管弦乐演奏是由一名乐队的指挥来统一的进行指挥和控制，是为 "编制") 为核心。也就是说，SOA 适用于驱动预定义的业务处理。这种老的服务模型，通常被称为 SOA 1.0，忽视了静态业务模型以外的事件。因为一切都需要进行提前建

SOA 安全实现起来可以是非常容易的 - 前提是你选择的方式要正确。松耦合的、可发现的、可共用的安全工具一个简单的工具：WS-Security 对 web services 进行了加强，为 SOA 安全提供了你需要的一切：访问控制、加密、信任、传输安全以及不可抵赖。消息示例WS-Security 将时间戳、授权、凭证、令牌、签名以及加密信息添加到 SOAP 消息头里面。SOAP 消息的 body

SOA 其实针对业务和集成服务的一系列设计原则。这些 SOA 设计原则保证了服务的高灵活性和高可复用性。SOA 是一个广泛部署的、成熟的架构方法。也正是由于它如此流行，也产生了一些常见的谬论：1. SOA vs ESB关于 SOA 和 ESB 有几种常见的误解：SOA 和 ESB 是互相竞争的两种技术SOA 和 ESB 是一个意思ESB 是 SOA 所必需的事实上 SOA 和 ESB 是互补的。E

SOA 具备能够帮你打破技术孤岛、简化技术栈、缩减成本并提高质量等巨大潜力。尽管如此，经常会有一些政治障碍影响 SOA 策略的实现：技术孤岛对彼此的行为几乎没有可见性部门之间相互竞争，几乎没有去进行服务共享的动力预算问题 - 谁来为共享服务买单？企业级架构团队曾经使用各种办法来打破这些孤岛并进行服务复用：为通用服务创建相关负责部门行政强制：强制大家去共享自己的服务合作：鼓励大家去共享自己的服务但是

SOA 服务具备清除边界和技术差异的能力。这给我们带来了一个灵活和可定制的架构，但是同时也带来了大量的安全挑战。以下是 SOA 安全的相关的一些方面：SOA 的安全不仅仅是一个技术问题 - 对于任意 SOA 安全解决方案来讲都会面临业务和技术两方面的问题。SOA 安全不仅要考虑到服务层面，而且还要兼顾组织和基础设施层面。原文链接：Soa Security From 50000 Feet，发布日期：

SOA 和 mashup - 两种驱动更快/更廉价服务开发的架构模式。它们都被用于构建可复用的服务 - 但是它们之间有哪些区别呢？SOA 其实是一套由 9 大设计原则组成用于构建高可复用服务的设计方法。如果我们根据这 9 大设计原则来对 mashup 进行评估的话，结果会怎样呢？√ 服务协同mashup 常常是基于诸如 XML、HTTP、REST、Web Services、RSS 以及 Atom

SOA 行为失败的原因有很多，但是最重要的一个原因是 - 缺乏服务复用。很难对 (上述案例的) 未来做出预测。如果你今天没有对自己的服务进行 SOA 化治理的需求，那么这种需求也就永远不会提上日程。按理来说对服务进行 SOA 化设计才应该是优先级高的需求。原文链接：This Is What Soa Failure Looks Like，发布日期：2011 年 2 月 18 日。作者简介John S

这 10 个 SOA 设计模式是如此之重要，其应用是如此之广泛，以至于它们都有些显而易见了。1. 服务无关服务无关实现对多种业务通用的逻辑。将服务无关的逻辑分离成离散的服务以方便服务的重用和整合。原则：复用，服务整合2. 服务无关的声明服务无关的服务应该显式声明它们是服务无关的。这样对于后续的设计者和架构者来说能够清楚哪些服务是被设计用来进行重复使用的。原则：复用，服务整合3. 服务无关的事务服务

面向服务的架构 (SOA) 设计要尽可能地简单。在设计一个 SOA 服务的时候要谨记这 9 大设计原则：1. 标准服务契约服务要遵循一个服务描述。2. 松耦合服务之间的依赖最小化。3. 服务抽象服务将自己的业务逻辑封装起来，对外部世界是隐藏的。4. 服务复用业务逻辑切割成多个服务以实现复用的最大化。5. 服务自治服务应该有对它们封装的逻辑的控制权。6. 服务无状态理想情况下，服务应该是没有状态的。

RPC vs Web Service使用 SOAP 协议创建 Web Service 需要使用两个备选方案：文档型 SOAP 协议或者 RPC SOAP 消息协议。RPC 指的是远程过程调用，它是一种协议，指定的程序通过它可以去请求指定的位于另一台远程主机上的另一个应用中的服务。在使用 RPC 的时候，无需去了解该应用的网络细节。一个指定的过程调用指的是作为子程序调用甚至函数调用。在使用 RPC