SOA
SOA 是通过功能组件化、服务化，来实现系统集成、解决信息孤岛，这是其主要目标。而更进一步则是实现更快响应业务的变化、更快推出新的应用系统。与此同时，SOA 还实现了整合资源，资源复用。
SOA 服务的设计标准是粗粒度、高重用、灵活、标准。性能则并非首要考虑因素。
SOA 的两大功能是集成、服务编排(BPEL、BPM)。WF 在 SOA 架构中，实现服务编排的功能。
参考架构：
![image]( "image")
相关资源：
SOA 的基本概念及设计原则浅议
SOA 有哪些基本原则
SOA 设计十大原则
SOA 服务设计原则
再谈SOA集成平台建设必要性
谈基于SOA的应用系统设计和开发
谈基于SOA的消费发布订阅
再谈服务设计
携程旅行网在SOA架构方面的探索
支付宝的SOA实践(程立)
ESB
ESB 是 SOA 的重要实现手段。ESB 实现 SOA 时，它作为中心、媒介，集成的系统将只与它进行交互。而 ESB 实现与各种系统间的协议转换、数据转换、透明的动态路由功能（基于内容）。
在设计 ESB 时，集中的分发模块会影响性能、可伸缩性、容错能力，所以 ESB 要有良好的可伸缩性，支持集群。
IBM 总结了 ESB 的功能，较完整的功能如下：
| 通信 |
服务交互 |
- 路由
- 寻址
- 通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS）
- 发布/订阅
- 响应/请求
- Fire-and-Forget，事件
- 同步和异步消息传递
|
- 服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL））
- 支持替代服务实现
- 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型）
- 服务目录和发现
|
| 集成 |
服务质量 |
- 数据库
- 服务聚合
- 遗留系统和应用程序适配器
- EAI 中间件的连接性
- 服务映射
- 协议转换
- 应用程序服务器环境（例如 J2EE 和 .NET）
- 服务调用的语言接口（例如 Java 和 C/C++/C#）
|
- 事务（原子事务、补偿、Web 服务事务（WS-Transaction））
- 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
|
| 安全性 |
服务级别 |
- 身份验证
- 授权
- 不可抵赖性
- 机密性
- 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））
|
- 性能
- 吞吐量
- 可用性
- 其他可以构成契约或协定的持久评估方法
|
| 消息处理 |
管理和自治 |
- 编码的逻辑
- 基于内容的逻辑
- 消息和数据转换
- 有效性
- 中介
- 对象标识映射
- 数据压缩
|
- 服务预置和注册
- 记录、测量和监控
- 发现
- 系统管理和管理工具的集成
- 自监控和自管理
|
| 建模 |
基础架构智能 |
- 对象建模
- 通用业务对象建模
- 数据格式库
- B2B 集成的公共与私有模型
- 开发和部署工具
|
- 业务规则
- 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy））
- 模式识别
|
而最低要求的 ESB 需要具有的功能：
| 通信 |
集成 |
- 提供位置透明性的路由和寻址服务
- 控制服务寻址和命名的管理功能
- 至少一种形式的消息传递范型（例如，请求/响应、发布/订阅等等）
- 支持至少一种可以广泛使用的传输协议
|
- 支持服务提供的多种集成方式，比如 Java 2 连接器、Web 服务、异步通信、适配器等等
|
| 服务交互 |
|
- 一个开放且与实现无关的服务消息传递与接口模型，它应该将应用程序代码从路由服务和传输协议中分离出来，并允许替代服务的实现。
|
|
相关资源：
面向服务架构（SOA）和企业服务总线（ESB）
C#ESB设计说明书
几种 ESB
ESB企业服务总线
ESB项目需求分析和方案设计浅谈
ESB同步,异步选择,从项目实际出发(电信)
ESB 优缺点
ESB 架构笔记
ESB 简介 - 百度知道
ESB 项目需求分析和方案设计浅谈
NServiceBus
NServiceBus 是 .NET 平台上最受欢迎的一个开源 ESB 框架。有较完善的文档及示例代码。
目前，.NET 平台上开源的 ESB 框架，大多基于消息队列来实现。NServiceBus 同样也使用消息队列机制来实现消息的传递，例如可以使用 MSMQ。由于消息队列天生就是异步传输的，所以 NSB 也同样只支持异步消息，是一种‘发送即忘却’的模式。（As a general purpose communications technology, WCF does not enforce the queued messaging paradigm. NServiceBus does, and the architectural implications are profound.）。
NServiceBus 相对于 WCF 的优势在于：事件驱动的架构（发布、订阅）、更好地支持长时间运行的工作流。
缺点一：只支持异步的消息机制的问题是，无法进行传统的的数据查询。（To allow clients to perform queries, it is best not to use NServiceBus. Messaging is designed for non-blocking operations, and queries are (for the most part) operations for which the user wishes to wait.）
如果一定要使用 NSB 来实现数据查询，那么只能通过 CQRS 来进行系统的设计：
![image]( "image")
缺点二：NSB 的服务可以轻易集成到 WCF 中使用 MSMQ 实现，但是反之则不行。也就是说，已经使用 WCF 开发的服务，是无法使用 NSB 来完成简单的迁移的。（原因也主要是因为 NSB 的异步机制。）
相关资源：
infoq 官方采访介绍：NServiceBus——让创建企业级.NET系统更加容易
NServiceBus---最流行的开源企业服务总线 for .Net
NServiceBus 开源通讯框架（几种通信模式）
NServiceBus 安装与调试
NServiceBus Overview
NServiceBus And WCF
简单DEMO
三篇笔记：1、2 错误处理、3
云计算，及与 SOA 的关系
云计算是一种部署体系结构，而 SOA 则是企业 IT 的体系结构。
SOA与云整合既带来应用和业务流程灵活的虚拟化和节省的费用（云），又带来原有应用的集成应用及业务流程的敏捷重构（SOA）。
上层基于 SOA 进行应用服务的开发，底层基于云计算进行资源整合，包括存储，网络，数据库，服务器等。
目前业界比较多的观点赞同：SOA 与云计算将整合发展。
它们的关系：
- 从产生的背景和原因看，SOA产生的原因是为解决企业存在的信息孤岛和遗留系统这两大问题。云计算产生的原因是企业的信息系统数据量的高速增长与数据处理能力的相对不足，还有计算资源的利用率处于不平衡的状态。
- 从关键的技术和属性看，通过产生背景和原因的分析，SOA和云计算是不同的概念，但是它们却互相联系，又有一定的相似性。从服务角度来看，SOA实现了可以从多个服务提供商得到多个服务（一个服务便是一个功能模块），并通过不同的组合机制形成自己所需的一个服务；云计算实现了所有的资源都是服务，可以从云计算提供商购买硬件服务、平台服务、软件服务等，把购买的资源作为云计算提供商提供的一种服务。
- 从关键技术来看，SOA需要实现业务组件的可重用性、敏捷性、适应改变、松耦合、基于标准；云计算则需要虚拟化技术、按需动态扩展、资源即服务的支撑。
- 从应用场景来看，当企业的业务需求经常改变的时候可以考虑使用SOA；当企业对IT设施的需求经常改变或者无法提前预知的时候可以考虑使用云计算，当有大量的批处理计算的时候也可以考虑使用云计算。
- 从应用的侧重点来看，SOA侧重于采用服务的架构进行系统的设计，关注如何处理服务；云计算侧重于服务的提供和使用，关注如何提供服务。
- 从商业模式来看，SOA可能会降低软件的开发及维护的成本，商业模式是间接的，需要落地；云计算根据使用的时间（硬件）或流量（带宽）进行收费，具有明确的商业模式。
本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/p/3751264.html，如需转载请自行联系原作者
