下面我们来解释一下上面的基础体系架构，上面这种体系架构方案，区别于 Microsoft. Net。我们知道J2EE 作为基础的底层架构，结合的门户和集成的框架，它体现了这样一种基本观点：即真正的客户需要的基于开放式标准的架构。这种架构希望确保交互能够全方位地进行，并且不会受到任何专有因素的干扰。因此，标准是为了促使我们考虑的问题：他们的基础设施的开放程度如何？怎样进行连接？
可见，基础J2EE体系架构的职能其实是将这两个要素连接在一起，以便支持用户交互，并将企业基础设施用于提供交互所需的功能。 使任何用户都能够随时随地通过他们自己选择的设备与我的企业进行安全且高度可用的交互。此外，从企业角度讲，我希望使任何用户的交互都遵守我的业务规则，并且具有高度的安全性，从而提高企业资源的安全性，同时为用户信息提供保护。从 IT 基础设施的角度来看，资源可以是人员、信息、数据或应用程序；既可能是打包的应用程序（例如
实现外部应用、实现 Boss的EJB应用），也可能是可以在
其他应用服务器中，甚至是 Microsoft.net 应用程序中运行的自定义应用程序。
该基础体系构架的另一个组件是各功能之间的通信方式，我们称之为通信机制。例如，在 Microsoft.net 中，该机制为 Web 服务。在 WebSphere 中，该机制可能是 Web 服务，也可能是其他选项。
基础设施的开放性问题需要进行两个方面的开放性测试。首先，如果编程模型能够部署在多种操作系统中，可以由独立的标准组织进行修改，并且可以通过多种来源获得，那么我们就认为该编程模型是开放的。如果编程模型通过了上述三项测试，即可被称为开放的。
其次，如果通信机制可以在不同的编程模型之间进行通信，那么我们就称之为开放的。这是一种比较简单的测试。例如，Web 服务实际上就是开放的通信机制。
在目前的业界的理解，通常”业务集成”
将涉及下面的几个领域的功能实现和提供。
消息数据传输机制/Messaging
消息代理/Message Broker
模型和模拟/Modeling and Simulation
人员参与的工作流/Human Workflow
自动处理的流程/Process Automation
监控和管理/Monitoring
因此当企业构建应用程序时，可以在构造方式上进行一定的标准化。这种标准化的方式实际上类似企业基础设施的功能就是进行连接、管理用户交互，并使用户交互能够驱动和访问待执行的操作；当然，这必须遵守业务规则。
这种架构中，企业应只搭建一个基础架构。而在当我们考虑要连接的对象（各类应用）时，可以将连接对象定义为资源，即资源可以是人员、数据、应用程序甚至流程。这种做法的依据是基础架构设施应支持多个用户和多项资源的连接，满足企业不停的业务增长的需求，和逐步的建设。如下图示：
1.3.2 企业服务总线 (Enterprise Service Bus)技术
ESB 是一种体系结构模式，支持虚拟化通信参与方之间的服务交互并对其进行管理。它提供服务提供者和请求者之间的连接，即使它们并非完全匹配，也能够使它们进行交互。此模式可以使用各种中间件技术和编程模型实现。
在 ESB 模式中，服务交互的参与方并不直接交互，而是通过一个总线交互，该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。IBM ESB 模式提供以下几方面的虚拟化：
位置和标识：参与方不需要知道其他参与方的位置或标识。例如，请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者，而不会带来任何干扰。
交互协议：参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由仅理解 Java 远程方法调用 (RMI) 的提供者提供服务。
接口：请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。
（交互）服务质量 (QoS)：参与方声明其 QoS 要求，包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由（如根据工作负载分布标准将请求路由到可用的实现）。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。
因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求，而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务，而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策；应用程序源代码不会受到影响。
ESB 支持许多交互类型，包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理（在复杂事件处理中，可能会观测到一系列事件），以产生一个事件作为该系列中的关系的结果。
下面的图1 对基本 ESB 模式进行了描述。消息流过将各个通信参与方相互连接在一起的总线。某些参与方会调用其他参与方提供的服务；而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如，SIP 可以是 Web 服务端点、WebSphere MQ 队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据：SIP 的要求和功能（例如，提供或需要的接口）、它们希望与其他 SIP 的交互方式（例如，同步或异步，通过 HTTP 或 JMS）、它们的 QoS 要求（例如，首选的安全、可靠交互）以及支持与其他 SIP 交互的其他信息（例如，语义注释）。
将总线插入参与方之间，提供了将它们的交互通过称为中介
的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互，可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。
ESB 模式为 SOA 实现提供了灵活且易于管理的方法。总线透明地插入端点之
以下文章点击率最高
Loading…