向服务架构(SOA)和企业服务总线(ESB)
基于SOA的企业服务总线研究
基于SOA的企业服务总线研究随着数字化转型的趋势不断发展，企业内部各系统之间信息传递的效率和可靠性成为了企业发展的关键问题之一。
因此，企业服务总线（ESB）就应运而生了。
ESB是一种基于服务导向架构（SOA）的架构风格，它为企业内部各应用系统之间的消息传递和协作提供了一种标准化、可靠性高、性能强的解决方案。
一、SOA的概念和特点SOA是一种设计理念和架构风格，它将软件系统划分为多个互相独立的模块，每个模块都是一个可重用的、完整的、自包含的服务。
这些服务通过标准协议和接口进行交互，从而实现各应用系统之间的信息共享和协作。
SOA的特点包括：1. 服务重用：SOA将应用系统按照“服务”进行划分，每个服务都可以被多个应用系统共享和重用，从而提高了系统的可维护性和扩展性。
2. 标准化协议：SOA采用标准化的协议和接口进行服务的发布和调用，如SOAP、REST等。
3. 松耦合：SOA中的服务是独立的、低耦合的，因此不会影响其他服务的运行或修改。
4. 面向业务：SOA的设计和实现以业务需求为中心，强调业务的敏捷性和灵活性。
二、企业服务总线的作用和架构企业服务总线（ESB）是一种基于SOA的架构风格，它是作为中间件存在的，用于统一管理企业内部所有的服务。
ESB的作用包括：1. 协议转换：ESB在各应用系统之间进行消息传递时，能够实现协议格式的转换，使得不同协议的系统之间也能通信。
2. 数据转换：ESB能够将不同格式的数据进行转换，使得各系统之间的数据传递更加高效和可靠。
3. 服务路由：ESB能够将消息传递到目标服务中，从而实现应用系统之间的消息传递和协作。
ESB的架构一般包括以下组件：1. 消息总线：ESB的核心组件，负责消息传递和协调各服务之间的通信。
2. 服务注册中心：用于管理所有服务的注册和发现，实现服务的可发现性和可用性。
3. 数据转换引擎：负责在消息传递过程中进行协议格式的转换和数据的转换。
4. 安全管理：负责对ESB的安全管理，包括身份认证、授权和访问控制等。
ESB——企业服务总线没有神话
ESB——企业服务总线没有神话ESB——企业服务总线没有神话在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（SOA）的相关问题、如何让企业服务总线（ESB）作为构建企业SOA框架的主干问题等。
其中，许多人质疑ESB的意义所在，从中也体现出当前IT群体普遍对ESB存在一定的误解。
在诸多的专题研讨会上，企业架构师们探讨着许多问题，比如面向服务架构（SOA）的相关问题、如何让企业服务总线（ESB）作为构建企业SOA框架的主干问题等。
其中，许多人质疑ESB的意义所在，从中也体现出当前IT群体普遍对ESB存在一定的误解。
下面便是笔者总结人们最关心的10个ESB的问题。
误区1：ESB只是EAI换了个名字许多IT架构团体在搭建SOA的同时仍然受到一个问题的困扰：“ESB和EAI到底有什么不同？”ESB是一种用于构建企业SOA的基础设施，它比传统的EAI代理的用途更为广泛。
根据福里斯特研究所的报告，ESB可以提高连通性、增加灵活性促进发展、并加强对重要资源的控制，从而帮助企业实现SOA 的价值。
ESB不仅可以用于处理以往依靠EAI工具进行的集成项目，还可以用于建立企业间的B2B关系。
ESB可以提供EAI所能提供的功能，但其基本架构是不同的：这个架构促进了企业从传统的集成方式转向协调服务交互。
EAI通常是采用星形架构以独立应用的形式实现的。
ESB提供的功能与EAI代理相同--连通器、应用适配器、根据规则进行的消息路由和数据转换引擎--但是这些功能是面向SOA的，它们分布于整个服务总线并寄存在可独立部署的服务容器中。
这使我们可以有选择性地部署所需的集成代理功能，不会产生冗余。
ESB容器模型的这种分布式特性使以事件驱动服务的形式按需添加到SOA中的集成组件具有独立的可扩展性。
为了使集成代理能够从真正意义上支持SOA并成为真正意义上的ESB，我们需要把它的基本功能分散到组成部件中，然后才能将各个组件独立地部署到总线中，并使它们协调运作。
企业服务总线(ESB)系统管理规范课案
NCDJZD-XX0302-2015-01企业服务总线（ESB）系统管理规范第一条本标准规定ESB企业服务总线管理过程的基本要求和准则，包括ESB企业服务总线平台的管理、ESB业务服务的管理。
第二条本标准适用于ESB企业服务总线管理人员、服务接口提供者、服务接口消费者。
第三条本规范可能需要引用其他文件，下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
南车电机ESB服务接口技术规范第四条术语和定义（一）SOA 面向服务架构(Services-Oriented Architecture)（二）服务本规范所指服务都是SOA服务。
服务是提供使用者封装的可执行代码单元。
它的服务只能通过已发布接口（包括交互标准）进行访问。
也可以连接到其他构件以构成一个更大的服务。
（三）服务接口服务接口是指一个能够重复执行功能模块，服务接口被定义为一组接口和完成特定的功能，提供给服务消费者使用。
服务消费者不需要知道服务接口实现的详细信息，服务消费者通过接口调用服务。
（四）服务消费者是一个应用程序，一个软件模块或需要一个服务的另一个服务。
它发起对治理中心的服务的查询，通过传输绑定服务，并且执行服务功能。
服务消费者根据接口契约来执行服务。
（五）服务提供者服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。
它将自己的服务和接口契约发布到服务治理中心，以便服务使用者可以发现和访问该服务。
（六）SAM 软件资产管理系统（Software Asset Management），应用系统与服务接口的注册、变更和使用的信息系统。
（七）ESB服务接口规范IT治理的一种特殊化，将IT治理中针对于服务组件、服务和业务流程的治理，重点关注服务生命周期的管理，实现服务的规划、组装、部署与管理。
（八）软件资产软件资产指IT建设中产生的软件系统，通常意义上是数据模型、服务接口、UI服务、组件。
ESB+SOA+WebService
1、ESB 描述为由中间件技术实现并支持SOA 的一组基础架构功能。
ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。
为了达到此目的，需要将多种功能集中起来并加以分类2、企业服务总线（Enterprise Service Bus，ESB）的概念被表述为SOA 基础架构的关键组件3、大部分对SOA 的描述所适用的原则是很有用的：（1）利用显式的与实现无关的接口来定义服务。
（2）利用强调位置透明性和可互操作性的通信协议。
（3）封装可重用业务功能的服务的定义。
4、ESB 为SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。
5、ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。
然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。
Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过ESB 调用服务，然后再次通过ESB 将业务流程公开为客户端可用的其他服务。
然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术ESB 分离的技术。
7、被普遍认同的ESB 定义的原理：1）ESB 是一种逻辑体系结构组件，它提供与SOA 的原则保持一致的集成基础架构。
2）SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
3）ESB 可以作为分布式的异构基础架构进行实现。
4）ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。
8、企业服务总线（ESB）是面向服务构架（SOA）的基础设施。
soa名词解释
“soa”名词解释1、“soa”的概念SOA（Service-Oriented Architecture，面向服务的架构）：是一种在计算机环境中设计、开发、部署和管理离散模型的方法。
SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。
在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。
这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。
二、soa的特征·可重用：一个服务创建后能用于多个应用和业务流程。
·松耦合：服务请求者到服务提供者的绑定与服务之间应该是松耦合的。
因此，服务请求者不需要知道服务提供者实现的技术细节，例如程序语言、底层平台等等。
·明确定义的接口：服务交互必须是明确定义的。
Web服务描述语言（Web Services Description Language，WSDL）是用于描述服务请求者所要求的绑定到服务提供者的细节。
WSDL 不包括服务实现的任何技术细节。
服务请求者不知道也不关心服务究竟是由哪种程序设计语言编写的。
·无状态的服务设计：服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。
服务不应该依赖于其他服务的上下文和状态。
当产生依赖时，它们可以定义成通用业务流程、函数和数据模型。
基于开放标准：当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准．采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。
三、soa设计原则·明确的接口定义：接口需满足稳定、明确、封装性等要求。
·自包含与模块化：实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
SOA、ESB、BPM的关系
SOA、ESB、BPM的关系
SOA
SOA（Service-Oriented Architecture）面向服务的架构，其中的Service是灵魂，是核心。
SOA的目标是构建一个松散耦合的系统架构，可以将企业的应用程序及资源包装为一个个的商业服务，按照特定的合约及规约来请求和使用服务。
ESB
企业服务总线（ESB-Enterprise Service Bus）本质上是一个以消息通信为中心的底层基础设施，它负责治理企业的所有应用服务，以连接为导向，为服务请求者与服务调用者搭建起沟通的桥梁。
包括服务连接、数据转换、事件转换、服务路由等功能。
企业服务总线是保障SOA有效落地的底层基础设施，没有ESB，SOA就只会是一片飘在天上的云彩，最终会烟消云散。
因此企业要基于SOA的架构方法论和思想去搭建智慧IT生态群落，就首先要搭建好底层的基础设施。
BPM
业务流程简单来说就是业务的处理流，或者说业务的流转过程。
这里重要的不是“流程”这两个字，而是“业务”这两个字。
在企业内部，核心业务如下：
产品和服务的设计与开发
产品和服务的市场营销与销售
产品和服务的交付
客户服务管理。
ESB与SOA的关系
ESB与SOA的关系一、ESB和SOA一直是没有明确概念的两个缩略词ESB----企业服务总线，像一根“聪明”的管道，用来连接各个“愚笨”的节点。
为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务互联互通。
SOA----面向服务架构，实际上强调的是软件的一种架构，一种支撑软件运行的相对稳定的结构，表面含义如此，其实SOA是一种通过服务整合来解决系统集成的一种思想。
不是具体的技术，本质上是一种策略、思想。
可以明确的说SOA就是一种服务集成思想，它的不同实现方式可能差别很大，目前SOA最常见的实现方式是SCA和JBI。
二、ESB究竟是什么IBM、Oracle等认为ESB是连接服务的一种模式，但一些开源组织和其他厂商认为ESB是一种产品，并且提供了ESB连接解决方案的实现，这种实现可以认为是中间件，也可以认为是组件工具。
对此，我个人的观点更偏向前者，ESB是一种模式，ESB的实现方式也很多，可以称之为ESB产品。
当然在不同场合ESB的含义也不同，需要鉴别。
三、为什么ESB总和SOA黏在一块通常，这两个名词总不分家，谈论的话题中“你中有我，我中有你”。
为什么是这样的呢？ESB是SOA吗？两者之间究竟有什么微妙的关系呢？带着疑问，继续往下看：首先，ESB不是SOA。
SOA的最常见的实现方式方式是SCA和JBI，而SCA的实现需要ESB，相反JBI则不需要ESB，可以参看JBI 和SCA分析解读的文章。
其次，因为IBM和Oracle（收购了BEA和SUN的牛X公司）都推崇SCA模式的SOA，因此SCA实际上已经成为SOA的事实标准，说道SOA，最先想到的就是SCA模式了。
最后，ESB是SCA架构实现不可缺少的一部分，ESB产品脱离了具体的应用外，没有任何意义。
ESB的作用在于实现服务间智能化集成与管理的中介。
通过ESB可以访问所集成系统的所有已注册服务。
四、ESB的特点ESB是一种在松散耦合的服务和应用之间标准的集成方式。
SOA体系架构下企业服务总线ESB技术的探讨
４５ ０） ３ ０ ３
要】 简要 介 绍 了 Ｓ Ａ ￣ 向服 务 的 结 构）企 业服 务 总线 概 念 Ｅ Ｂ基 本概 念 功能 ， 后 探 讨 企 业 服 务 总 线 的 实现 Ｏ（ ， Ｓ 最
２２ 企 业 服 务 总 线 的 功 能 ．
决 这 些 问题 ， 功 实 施 企 业 应 用 的 整 体 集 成 ， 每 一 个 企 业 必 须 解 决 成 是
的棘 手 问 题 。
Ｅ Ｂ作 为 中介 必 须有 两 方 面 的 考虑 。 酋先 ， 必 须 了 解 被 它 中 介 Ｓ 它
的两 个 端 点 ：） 务 的 请 求 者 以 及 请求 者 对服 务 的要 求 ；） 务 的 提 供 １服 ２服 目前 Ｅ Ｂ是 Ｓ Ａ 集成 中最 普遍 采 用 的 方 法 。 Ｅ Ｂ是 传 统 中 问 件 Ｓ Ｏ Ｓ 者 和 它 所 提 供 服 务 的 描述 。其 次 ， 必 须具 有 某 种 机 制 能 够 完 成 中 介 它 技 术 与 ＸＭＬ、ｅ ｗ ｂ服 务 等技 术结 合 的产 物 ，可 提 供 比 传统 中 间件 产 品 的任 务 。我 们 把这 两类 考 虑 归 纳 为 Ｅ Ｂ的 两 个 基 本功 能 ： 衙 向服 务 Ｓ 即 更 为 廉 价 的 解 决 方 案 。对 业 而 ， 用 Ｅ Ｂ 中 问件 系统 作 为 企 业 级 采 Ｓ 的元 数 据 管 理 功 能 和 中 介 功 能 。 信 息 系 统 整 合 方 案 中 的 中枢 技 术 ，可 以无 须 添 加 任何 软 硬 件设 备 ， 就 Ｅ Ｂ足 传 统 中 间 件 技 术 与 Ｘ 、 ｂ服 务 等 技 术 相 互 结 合 的 产 Ｓ ＭＬ Ｗｅ 能 把 过 去、 有 和 未 来 的 Ｉ 统 整 合 在 企 业 级 的 信息 应 用框 架 下 ， 现 Ｔ系 并 物 ，Ｓ Ｅ Ｂ的 出现 改 变 了传 统 的软 件 架 构 ，可 以 提供 比 传统 中 间件 产 品 且 能 为 企 业 提 供 实 时 、 容 量 的信 息 通 信 和 实 时 控 制 、 理 和分 配 消 大 管 更 为 廉 价 的 解 决方 案 ，同时 它 还 可 以消 除 不 同应 用之 问 的技 术 差 异 ， 息 传 递 的 能 力 让 不 同 的应 用 服 务器 协 调 运 作 ．实 现 了不 同服 务 之 间 的通 信 与 整合 。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
学习和研究在企业中实施面向服务架构(SOA),简单回顾SOA和ESB，重点关注微软在SOA领域的相关指导和.NET社区的相关开源的解决方案，和大家一起来探讨如何在企业里实现SOA，期望有实施SOA经验的同学发表意见。
一、SOA的历史1996年，Gartner最早提出SOA。
2002年12月，Gartner提出SOA是"现代应用开发领域最重要的课题"，SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM、等厂商看到了它的价值，纷纷跟进。
SOA 的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业(Real-Time Enterprise，这是Gartner为SOA描述的愿景目标)。
而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。
SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范。
这个定义决定了SOA的广泛性。
SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。
SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。
SOA鼓励使用可替代的技术和方法(例如消息机制)，通过把服务联系在一起而非编写新代码来构架应用。
经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。
SOA也不仅仅是一种开发的方法论--它还包含管理。
例如，应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。
其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。
SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。
企业环境中单个应用程序是无法包容业务用户的(各种)需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。
通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。
其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。
服务是从业务流程的角度来看待技术的--这是从上向下看的。
这种角度同一般的从可用技术所驱动的商业视角是相反的。
服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。
相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。
企业流程(enterprise process)是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。
流程定义了同业务模型进行交互操作的专门方法。
例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。
服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。
理解业务流程是定制服务的关键所在。
二、SOA 的描述所适用的原则利用显式的与实现无关的接口来定义服务。
利用强调位置透明性和可互操作性的通信协议。
封装可重用业务功能的服务的定义。
图 1说明了这些原则。
注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。
图 1: SOA 的原则为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。
启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。
从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。
然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。
这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。
三、ESB是什么？根据维基百科的ESB定义，ESB有如下特性：它是面向服务架构的实现。
它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）。
它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含标准安全模型，用于ESB的认证、授权和审计。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它包含基于模式（schema）的验证，用于发送和接收消息。
它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
它支持队列，在应用临时不可用时用来保存消息。
它由（地理）分布式环境中的选择性部署应用适配器组成对于其中一些厂商（IBM、微软）来说，ESB是将一系列能力联结在一起的一种模式，而其他厂商认为ESB是一种产品。
在2005年，微软Identity Platform 的产品经理Rich Turner写道：ESB[产品]是一根聪明的管子，用来连接各个愚笨的节点。
[……]Web Service的途径让节点本身也变得聪明，减少了对底下聪明管道的需要，并确保了跨越任何平台与设备的开放的通讯。
四、如何用.NET技术建立完整的SOA环境微软发布了一个名为“真实世界里的面向服务架构（SOA）”的电子书。
这本书表达了微软对面向服务架构的观点，并包括了数个展示如何用微软产品和技术实现SOA的真实案例。
书中解释到，SOA的功能型架构本身是松散的，即每个服务本身可以作为企业的IT资产存在、也可以作为生产流程中的处理环节存在，但总体上他们提供了一个完整的视图，而且与独立应用不同，这个视图的内容不是分层的、而是平的，借助这个视图可以提供如下可重用能力：消息机制服务工作处理流程服务数据服务用户体验服务主体身份的识别、认证、授权服务还有通盘的管理能力所有这些能力用微软的产品描述就是下图：与强调SCA、SDO等公共标准的Java平台不同，微软平台相应的封装也不是通过商用服务器平台完成，而是更多地借助WCF实现；其中最为重要的ESB角色重则由BizTalk担当，轻则由用户通过扩展WCF + WF完成；至于服务的治理，相对更为统一，与Windows平台其他产品无异，向下借助统一的WMI体系，配合MOM和System Center对SOA的基础平台部分进行治理，向上借助WS_Management 协议对服务进行集中管理。
实施SOA集成在所难免，各企业集成的方式大概主要有3种：购买某厂商的SOA套件，这样无论是组成上的兼容性还是技术支持都有保证，代价就是花费不菲；集成多种开源的服务器产品和开发框架，显性成本上很划算，但技术实施的成败的风险比较大；更多依赖操作系统自带的产品，根据IT范围的大小，选择少量的商业产品或开源服务器产品，兼容性风险比全部开源产品要小，成本上也比全盘采购商业套件廉价。
《SOA in the Real World》里更多倡导的就是这第三条道路。
微软还赞助了一个针对北美500家拥有1000名员工，或超过这个数字的企业的综合应用平台的研究。
其目的旨在确定哪种软件平台被用于构建关键任务的应用，以及什么是首选供应商的关键组件平台等。
五、开源的.NET ESB项目介绍企业级服务总线:是开源的企业级服务总线，采用的协议是MS-PL。
主要包含了MSMQ消息队列机智,SOAP消息收发,ROUTER服务路由,WCF,WSE消息扩展(消息加解密,压缩),还有WF工作流。
开源的通信框架NServiceBus :NServiceBus 是一个用于构建企业级 .NET 系统的开源通讯框架。
它在消息发布/订阅支持、工作流集成和高度可扩展性等方面表现优异，因此是很多分布式系统基础平台的理想选择。
，它能够帮助开发人员在搭建企业.NET系统时避免很多典型的常见问题。
同时，该框架也提供了一些可伸缩的关键特征，比如对发布/订阅的支持、集成的长时间工作流及深入的扩展能力等。
据作者说，其本意是为构建分布式应用软件创建一个理想的基础设施。
Mass Transit -- .Net Service Bus:Mass Transit是一个.NET平台上的用于构建松耦合应用程序的服务总线框架,这个服务总线支持YAGNI原则(YAGNI原则，就是通过重构提取公因式当出现一次时，不分层，以后业务复杂了，马上抽象出一个层次来，分层是依赖倒置原则和模版方法模式的应用。
)。
通过一套严密的关注点,Mass Transit和应用程序之间的接触最小化和清晰的接口.。