转载 JBI与ESB SOA

时间 2019-11-17

标签转载 jbi esb soa 栏目微服务繁體版

原文原文链接

业界正在普遍寻求解决 B2B 以及 EAI （企业应用集成）所存在问题的方案。这些方案不一样于基于 JMS 手段的面向消息中间件技术和 Web 服务技术。本笔记归纳地阐述了与 SOA （面向服务体系架构）规范及 ESB （企业服务总线）基础架构有关的 JBI （Java 业务集成）标准。如下第一，二部分转载后整理的。html

一．关于面向服务体系架构java

关于SOA的概念，你能够找到不少的文章从不一样的角度来描述它，不一样的软件提供商也有不一样的定义方式。BEA有流体计算，微软有Indigo 和SOA-building， SAP有ESA。每一个人均可以从不一样的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，好比说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其余服务。SOA包括以下要素:程序员

l 一个体系架构，用开放的标准将软件资产(Asset)化为服务web

l 提供标准的方法来表示软件资产及其交互数据库

l 单独的软件资产做为构造单元，被重复使用来开发其余应用apache

l 将关注点从细节实现转移到应用(application)组装设计模式

l 整合企业外部的应用（B2B）的方式架构

l 开发（如今）和整合（将来）的统一app

本文针对的读者是软件开发人员，站在开发人员的角度，每每但愿软件开发可以知足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让咱们经过回顾软件开发的演化过程来看一看SOA出现的必然性：框架

l 面向机器语言(Monolithic)的开发模式：须要根据不一样平台的机器语言来开发代码。

l 面向过程(Procedure)的开发模式：独立于机器的程序语言(C, Pascal等)使开发过程变得简单了，用过程来表明一个抽象的代码集合，包装重用现成的代码。

l 面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的天然思惟方式。

l 面向组件(Component)的模式：随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是不可逾越的，所以人们以架构运行环境(如.Net，J2ee等)来提供完善的支撑平台，从而把开发者解放出来，更专一于业务核心的开发。而这些业务功能(Business Function) 以组件的形式(DCOM， EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。

l 面向服务(SOA)的模式：当软件的使用范围扩展到更广阔的范围，每每会面对更加复杂的IT环境和更加灵活多变的需求。服务(Service)的概念出现了，人们将应用(Application)以业务服务(Business Service)的形式公布出来供别人使用，而彻底不须要去考虑这些业务服务运行在哪个架构体系上，由于全部的服务都讲着一样的语言。SOA考虑了业务发展的长期性，体现了"变化就是永恒"的思想。SOA的核心体如今企业应用或者业务功能上的"重用"和"互操做"，而再也不把IT与业务对立起来，这能够被视为在IT驱动业务的方向上迈出的重要一步。

咱们注意到，SOA一样也强调重用(Reuse)，可是相对于传统的代码重用，对象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在于业务级的应用，即服务的重用，这与软件的发展规律是相一致的。在软件发展的过程当中，软件重用的对象愈来愈接近咱们的现实生活。经过部件的重用，软件的开发更具效率，而且开始试图用组件表达业务模式。可是，IT人员仍很难对业务人员解释清楚IT结构怎样映射到业务模型上。然而，IT架构与业务模型的弥合是不可避免的方向。现代企业的业务环境所面临的最大挑战就是变化，规则在变，需求在变，而对变化作出最快的反应，尽快地适应变化，成为企业占得先机，成功运做的关键。不少企业的业务环境依赖于他们的IT架构，所以，IT部门每每直接承载了业务变化带来的压力。每个具体的业务变化，都直接反应到对现有的IT平台的要求：要么企业IT架构自己对变化自适应，要么IT架构可以在短期内根据新的业务规则作出调整。这就是SOA架构提出的根本缘由，咱们须要一种更加贴近业务的IT架构，可以直接描绘业务，对那些不懂IT技术的业务领域专家来讲，业务服务倒是他们最熟悉的，也就是说是SOA把软件重用的对象从IT人员上升到了业务人员。所以，咱们能够说SOA与其它的模式相比，最大的进步在于它与业务的关联性，"服务"对应到实际业务。IT经过"服务"与业务发生了密切的关系，业务人员和IT人员均可以专一于业务逻辑的实现，而共同的语言就是"服务"。

但不是什么场合都适用SOA。一般来说，SOA适用于较为复杂的IT架构，常常须要与外部复杂的IT环境交互，而且须要快速地应对频繁发生的业务变化。就像你不可能在控制洗衣机的芯片上使用EJB开发同样，若是你的IT环境规模很小，足以灵活地应对变化，不须要与其余的异构IT环境频繁交互，那么SOA带来的好处就不足以抵消它给你带来的系统复杂性。可是，即令如此，你也并无被彻底排除在SOA的大趋势以外。SOA是如此地倍受瞩目，咱们能够预见到它的迅猛发展，所以即便你的内部IT架构自己并非基于SOA的，你也还有机会参与到将来的SOA架构中去。例如，将你的某个业务以服务的形式发布到某个外部SOA平台上供别人使用，做为第三方SOA平台的一个服务提供者(Service Provider)存在。

在选择SOA的实施方案时，要记住，软件的具体实现技术诸如Web 服务与SOA是两回事，SOA是一个概念，方法学，或者用一个更时髦的词：一种模型。而Web 服务呢？它是一种具体的实现技术，就像EJB同样。SOA ≠ Web服务。不过公平地讲，Web 服务倒确实是目前最适合实现SOA的技术之一，用Web 服务来封装业务服务是个不错的选择。由于Web服务是标准的，WS-I协议保证了来自不一样厂商的Web服务即便运行在不一样的平台上，底层的实现机理不一样也能够顺利交互，这是之前的任何一种技术如CORBA，EJB，或DCOM都不能作到的。并且，Web服务的定义与实现是分开描述的，即松散耦合，所以，能够很方便地替换服务的内在实现而不会对现有的系统形成任何冲击，这也极大地促进了IT架构的灵活性。

对于SOA更进一步的了解，能够参考IBM developerWorks上其余SOA相关的文章(请参见参考资料)，咱们的系列文章将主要讨论ESB，所以再也不此过多地论述SOA了。为了使咱们下面的论述更顺畅，请先牢记典型的SOA架构有哪些基本的要求：

1. SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；

2. 服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关；

3. 灵活的架构 -服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明；

二．关于标准提出的背景(EAI 和 B2B 的若干问题)以及ESB

假定如今已经按照SOA的思想提炼出了各类业务服务，公布出来，一样，你发现其余不少人也作了一样的事情。你们都很振奋，开始踊跃的尝试，我调用你的一个服务，你调个人一个服务。啊哈！你们都SOA了。且慢，那么这个SOA给大家带来了什么好处呢？Ok，如今我能够在J2EE环境里调用.Net的组件了，可是原来没有SOA的时候也能够作到的呀。只要两个节点之间互相承认对方的方式，即便不存在公开/统一的服务界面也能够实现点到点的互联。所以咱们不得不认可，若是咱们只有服务，而服务的请求者和服务的提供者之间仍然须要这种显式的点到点的调用，那么这就不是一个典型的SOA架构。请看图二，服务的参与双方都必须创建1对1 的联系。这样一个结构与我十几年前的那种互联的方式何其类似！可是，还记得咱们上面提到的SOA三个基本要素吗？显然第三点没有作到。

所以，在SOA中，咱们还须要这样一个中间层，可以帮助实如今SOA架构中不一样服务之间的智能化管理。最容易想到的是这样一个HUB-Spoke结构，在SOA架构中的各服务之间设置一个相似于Hub的中间件，由它充当整个SOA架构的中央管理器的做用。请看图三，如今服务的请求者和提供者之间有了一个智能的中转站，服务的请求者再也不须要了解服务提供者的细节。不错！看上去是一个好的SOA结构。事实上，传统的EAI就是经过这样一种方式来试图解决企业内部的应用整合问题。

EAI的目标是支持对现有IT系统的从新利用，经过EAI技术可以将不一样的软件和系统串联起来，延长这些应用系统的生命周期。传统的EAI，每每使用如CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，修改企业资源规划以达到新的目标，使用中间件、XML等方法来进行数据分配。所以，实际上传统的EAI是部件级的重用。很不幸的是，基于部件的架构没有统一的标准，所以，各个厂商都有各自不一样的EAI解决方案，你会看到各类各样的中间件平台。若是EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不一样的中间件之间周旋，来实现合理的互联方式，你不得不考虑各类复杂的可能性。所以，你所见过的大多数传统EAI解决方案都比较笨重。

再回顾一下咱们上面介绍过的SOA的应用场景：复杂的企业级架构。若是咱们选择Hub的模式来构建SOA基础架构，从纯粹逻辑的角度，可能会出现哪些问题呢？首先，整个SOA架构的性能，若是每一个服务的请求都通过中央Hub的中转，那么Hub的负担会很重，速度会随着参与者的增多而越来越慢；其次，这样的系统会很脆弱，一旦Hub出错，整个SOA架构都会瘫痪；最后，这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。所以，这也不是理想的SOA架构。

好了，如今该ESB登场了:

它与前面的Hub结构有什么不一样呢？首先，它比单一Hub的形式更开放，总线结构有无限扩展的可能；其次，真正体现了SOA的理念，一切皆为服务，服务在总线(BUS)中处于平等的地位。即便咱们须要一些Hub，那么它们也是以某种服务的形式部署在总线上，相比上面的结构要灵活的多。这就是ESB，咱们须要给它一个明确的定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它能够做用于：

l 面向服务的架构 -分布式的应用由可重用的服务组成

l 面向消息的架构 - 应用之间经过ESB发送和接受消息

l 事件驱动的架构 - 应用之间异步地产生和接收消息

很不幸，上面的定义看上去很拗口，咱们暂且用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管理的中介。而它与SOA的关系要相对好理解一些：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。能够这样说，ESB是特定环境下(SOA架构中)实施EAI的方式：首先，在ESB系统中，被集成的对象被明肯定义为服务，而不是传统EAI中各类各样的中间件平台，这样就极大简化了在集成异构性上的考虑，由于无论有怎样的应用底层实现，只要是SOA架构中的服务，它就必定是基于标准的。

其次，ESB明确强调消息(Message)处理在集成过程当中的做用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有本身的方言，即各自的消息格式。做为基础架构的EAI系统，必须可以对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大可能是被动的，消息的处理须要各自中间件的私有方式支持，例如API的方式。所以尽管消息处理自己很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统因为集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。若是ESB可以在底层支持现有的各类通信协议，那么对消息的处理就彻底不考虑底层的传输细节，而直接经过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，由于经过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，经过某种中间件平台，如CORBA来链接企业信息孤岛，可是，ESB的概念不只仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。

最后，事件驱动成为ESB的重要特征。一般服务之间传递的消息有两种形式，一种是调用(Call)，即请求/回应方式，这是常见的同步模式。还有一种咱们称之为单路消息(One-way)，它的目的每每是触发异步的事件，发送者不须要立刻获得回复。考虑到有些应用服务是长时间运行的，所以，这种异步服务之间的消息交互也是ESB必须支持的。除此以外，ESB的不少功能均可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，须要经过ESB来提供数据，当服务的请求经过ESB中转的时候，ESB很容易经过事件驱动机制向SOA的基础架构服务传递信息。

关于ESB的总结：

ESB （企业服务总线）为面向服务体系提供了基础架构。经过设计工具定义服务间交互和规则， ESB 为部署和发现服务提供了运行时环境。

在 ESB 的世界中，服务不会直接彼此交互。“ ESB 运行时”做为一个仲裁者在服务间松散的耦合它们。“ ESB 运行时”将实现协议绑定、消息传输、消息处理，等等。

一个服务总线将包括下列关键项：

为服务提供传输绑定

定义和发现已部署服务

在服务间基于规则的路由和编排消息

包括文档传递在内的增值服务等

大部分的 ESB 提供商基于本身的 SOA 提议来开放标准和技术，包括多种 Web 服务标准和协议。他们提供多种调用服务的传输绑定，包括 HTTP 、 FTP 以及JMS 等等。大部分 ESB 用户利用 WS-BPEL （ Web 服务的业务流程执行语言）来了解已部署服务之间是如何实现业务流程的。 ESB 提供商同时也提供服务质量特性，包括容错、故障转移、负载平衡、消息缓冲等等。

三．Java 业务集成

JBI （Java 业务集成）的提出是基于面向服务体系提倡的方法和原则，为了解决 EAI 和 B2B 若干问题的 Java 标准。当前版本（ 1.0 ）是 2005 年 8 月经过的JSR （Java 规范需求） 208 定案。商业和开源界都欢迎 JBI 成为他们 ESB 产品的集成标准。

JBI环境的架构

JBI 定义了基于插件方式的架构，以便服务能融入“ JBI 运行时”环境。 JBI 提供了详细的接口，使服务能与“ JBI 运行时”环境交互。这些服务要为“ JBI 运行时”环境暴露接口，以便“ JBI 运行时”环境为服务路由消息，也即JBI定义了一种环境，在这种环境下，插件组件使用一种直接基于WSDL2.0的服务模型来进行交互。因此，“ JBI 运行时”环境在部署在 SOA 环境中的服务间扮演着仲裁者的角色。

在同一 JVM 中，“ JBI 运行时”核心主要包括以下组件：

组件框架：组件框架把不一样类型的组件部署到“ JBI 运行时”。

归一化的消息路由器：归一化的消息路由器利用标准机制实现服务间消息交换。

管理框架：管理框架基于 JMX 进行部署、管理以及监控“ JBI 运行时”中的组件。

下图为JBI高层架构的视图

JBI环境外面的是服务消费者跟提供者，它们表明了将被JBI集成进来的外部实体。这些外部实体可使用各类不一样的技术来跟JBI环境里的Binding Components来进行通讯。而服务引擎是一个基本的标准化的容器，它用来容纳基于引擎规范所定义的实体(好比说wsdl所定义的服务提供者和消费者)。

组件模型――组件框架(Component Framework)

JBI 在“ JBI 运行时”环境中定义了两种组件：

服务引擎（SE）组件：该组件负责实现业务逻辑和其余服务。服务引擎组件在其内部可以使用多种技术和设计模式。服务引擎组件可提供数据传输和转换这种简单的基础服务，也可实现像 WS-BPEL 实例同样复杂的业务处理。

绑定（BC）组件：绑定组件主要为已部署服务提供传输级绑定。绑定组件有多种类型：

利用标准传输协议与外部系统进行远程通信。

使已部署服务能在同一个 JVM 内部相互调用。

服务间可以使用标准的 WS-I （ Web 服务协同工做组织）规范通信。

JBI 的关键是分离服务引擎和绑定组件，以便业务逻辑不被下面的具体细节所干扰。这种方式促进了体系的灵活性和可扩展性。绑定组件和服务引擎组件在JBI 内部均可以是服务提供者和 / 或服务消费者。

绑定组件和服务引擎组件为“ JBI 运行时”提供接口以便从“ JBI 运行时”接收消息。一样的，它们也利用 JBI 提供的接口来和“ JBI 运行时”通信。

消息传输模型－－归一化的消息路由器（Normalized Message Exchange）

JBI 利用消息传输模型分离服务提供者和服务消费者之间的耦合。消息传输模型利用了 WSDL 。 WSDL 用于描述暴露的服务引擎组件和绑定组件的业务处理。另外， WSDL 也用于定义抽象服务处理的传输级绑定。

JBI 架构中一个关键组件是 NMR （归一化消息路由器，也译做“正规消息路由器”）。 NMR 基于 WSDL 提供了主要的消息传输中枢， NMR 为部署在“JBI 运行时”中的服务引擎组件和绑定组件间的消息传递提供松散耦合。服务须要有聚合业务处理的接口，每一个业务处理由零个或多个消息组成。而一个接口有一个或多个传输级绑定。

基于WSDL的消息模型，示意图以下：