精华内容
下载资源
问答
  • 作者:人月神话,新浪博客同名简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践对于ESB企业服务总线方面,我准备近期整理几篇文章进行分享...ESB企业服务总线核心功能概述ESB是企业服务总...
    cfda72004d4e9d3121f27801abc00bb7.png

    作者:人月神话,新浪博客同名

    简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践

    对于ESB企业服务总线方面,我准备近期整理几篇文章进行分享。当前虽然在微服务架构下大家讨论更多的是微服务和API网关,但是对于传统业务系统,包括传统企业在进行IT架构转型过程中,为了兼容遗留IT系统,往往仍然需要采用ESB服务总线进行集成和适配。

    ESB企业服务总线核心功能概述

    2b8c232891a04a209d2175103ba3bf62.png

    ESB是企业服务总线(Enterprise Service Bus)的缩写,是中间件技术与Web Service等技术结合的产物,也是SOA系统中的核心基础设施。ESB就是一个服务的中介,形成服务使用者->ESB服务Proxy->服务提供者的生物链,中介的作用在不同应用中各有不同:

    解耦中介 :客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的,交互集成代码提取到了业务逻辑之外,由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService,Http,JMS...),消息转换 (转换、充实、过滤),消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。

    服务中介 :ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证,负载均衡,流量控制,缓存,事务控制,加密传输),服务管理监控 (异常处理,服务调用及消息数据记录,系统及服务的状态监控,ESB配置管理),统一安全管理 (这个有点理想主义)。

    服务编排 :多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。

    从上面可以看到ESB的基本功能仍然是数据传输,消息协议转化,路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA,比如借助SCA和BPEL来实现SOA,当时却很难实现消息协议转化和动态路由。

    ESB在发展过程中有从原有的消息中间件转化为ESB产品的,这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成,以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的,自描述的且能互操作的实体。

    78c26b0df92741a7c56596c35f73b002.png

    对于SOA关注的是服务全生命周期,通过服务实现业务价值。而ESB关注的是服务中介和服务的集成,是SOA的基础设施。SOA有两个核心组件,一个是ESB,一个是BPEL,而ESB是基础设施,BPEL是业务流程驱动下服务的集成和整合。离开了SOA,ESB将失去它所连接的服务,而仅仅是一个总线,同时也将变得毫无价值。

    Bobby做了一个比喻:路是没有任何价值的,除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA,ESB就像一个没人使用的道路。

    做SOA的事情不要先上来建立一个大而全的ESB,相反是关注你的业务问题,找到用SOA的方法来解决业务上的需求,在解决这个问题的过程当中,你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装,动态地解决你变化的业务需求。这是它的价值,只有这样才能使你的业务敏捷起来,随需应变起来。而在服务的组装过程中,你再去考虑利用ESB来把他们连接起来。

    faf91d9d15c2bfa07a5a631100e99145.png

    ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而,SOA 可能还有单独的业务服务目录(business service directory),其最基本的形式可能是设计时服务目录,用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录,因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分;然而,在这样的解决方案变得普遍之前,业务服务目录可能与 ESB 是分离的。

    标准的 ESB 功能

    9eaa627b0a0426341ac613142cee7bc9.png

    上面的许多功能既可以使用专有技术实现,也可以通过利用开放标准实现。然而,使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同,同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因,再加上最近制订和正在兴起的一些相关标准,当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

    支持 SOA 的最低功能的 ESB 实现

    如果在前面确定的功能中只有一部分和大多数 SOA 场景相关,我们可能会问:实现 ESB 所需的一组最低功能由什么构成?为此,考虑最被普遍认同的 ESB 定义的原理:

    • ESB 是一种逻辑体系结构组件,它提供与 SOA 的原则保持一致的集成基础架构。
    • SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
    • ESB 可以作为分布式的异构基础架构进行实现。
    • ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

    因此最低配置的 ESB 功能至少应该包括如下:

    f2f5f5dd366ef1189707cd83e30af854.png

    请注意这些最低功能并不需要使用特别的技术,比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求,但是不必强制要求使用它们。相反,最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现(当然不是所有的情况都这样):

    • URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务总线Bus。
    • SOAP/HTTP 支持请求-响应(Request-Response)通信规范。
    • HTTP 传输协议被广泛地使用。
    • SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。

    然而,这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点(point-to-point)的集成,并不能实现一些 ESB 需要的关键功能:

    目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的,服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。

    虽然这种方法依赖于实现细节,但是它往往并不能使服务实现的替代变得简单;服务请求者代码(也可能是开发工具生成的)通常通过特定地址 的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现,就需要修改应用程序代码并重新部署这些代码。

    当然,在许多甚至是大多数情形中往往需要其他的功能,并且这种需要变得越来越常见。特别地,不管是现在还是以后,下面的需求类型可能会导致更复杂高级的技术的使用:

    • 服务质量和服务级别功能。
    • 高级 SOA 概念,例如服务编排、目录、转换等等。
    • 按需操作环境需求,比如管理与自治功能以及基础架构智能功能。
    • 跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作。

    当前API网关和OpenAPI平台和传统ESB对比

    简单来说API网关就是将所有的微服务提供的API接口服务能力全部汇聚进来,统一接入进行管理,也正是通过统一拦截,就可以通过网关实现对API接口的安全,日志,限流熔断等共性需求。如果再简单说下,通过网关实现了几个关键能力。

    • 内部的微服务对外部访问来说位置透明,外部应用只需和网关交互
    • 统一拦截接口服务,实现安全,日志,限流熔断等需求

    从这里,我们就可以看到API网关和传统架构里面的ESB总线是类似的,这些关键能力本身也是ESB服务总线的能力,但是ESB服务总线由于要考虑遗留系统的接入,因此增加了:

    • 大量适配器实现对遗留系统的遗留接口适配,多协议转换能力
    • 进行数据的复制映射,路由等能力

    对于两者,我原来做过一个简单的对比,大家可以参考。

    aaa1405bc6711e585464635f3cb4717e.png

    ESB总线的功能需求分析

    f9c3a2dff10f015806642974d3c87b5d.png

    关于ESB总线的功能需求,在这里仅仅对核心功能需求进行整理如下:

    服务目录和元数据管理

    ESB总线平台管控应该提供完整的服务目录库,可以通过多个维度对服务目录进行浏览和查询,同时ESB服务总线需要通过数据存储对服务元数据、配置、策略进行统一管理,对于每次服务调用均需要产生服务实例日志信息。对于服务元数据本身包括了服务的编码,名称,类型,版本等基础信息,同时也包括了服务消息输入和消息输出的详细格式信息。

    服务注册和服务接入

    通过服务接入功能,将服务提供方系统开发的服务接入到服务总线上并发布出来,供其它业务系统调用,服务接入也即服务注册和服务封装功能,需要提供简单易用的服务接入操作功能界面,支持手工接入,也支持批量一键接入。

    动态路由和静态路由

    系统需要提供服务动态路或静态路由功能,对于静态路由主要是可以配置和定义静态路由表,服务消费基于路由表进行路由。对于动态路由即可以灵活的配置基于服务消费时候的消息输入参数进行动态的服务路由。

    消息传输

    需提供消息传输的基本功能:服务使用方先调用注册发布在服务共享平台上的服务并以消息形式传入服务调用请求,平台将接收到的调用请求转发给服务提供方,服务提供方完成操作后先将服务响应消息传递给平台,再由平台将服务响应转发给服务使用方,整个过程都是通过消息进行传输。

    异步分发和消息发布订阅

    在实际业务场景中,经常出现“一对多”的情况,ESB平台需要支持异步分发功能,只需在平台中配置异步分发服务,即可实现异步分发功能。同时也支持1对多的消息发布订阅功能。

    协议和消息转换

    对于已经上线稳定运行的重要功能,这些功能使用的数据交换协议可能有很多种,需解决不同的协议的对接,服务共享平台必须支持协议转换功能,服务共享平台需支持在大部分标准协议间进行转换,包括JMS、HTTP(S)、TCP、FTP、POP3/SMTP等。

    为了统一控制及更好地进行日志管理,服务共享平台需要为每一次交易产生的日志编号,需要在消息流中插入一个唯一编号,此时需要用到消息转换功能。因此服务共享平台需要提供消息转换能力,支持在消息传输过程中对消息进行操纵及转换,包括消息元素新增、替换及删除。

    遗留系统适配器

    各业务系统开发的服务需要接入并发布到服务共享平台上,采用的技术可能是Webservice、HTTP、HTTPS、FTP等,服务共享平台必须提供各种标准适配器,能够将按业界开放标准开发的服务注册到平台上。所以平台必须提供各种标准适配器,可以将按照标准协议开发的服务适配接入到平台上,其中包括了数据库,FTP,MQ,JMS,大数据,平面文件,商用ERP套件等各种适配器。

    服务请求过滤及流量控制

    服务共享平台需要支持按预定义的规则对服务调用请求进行过滤,对于未允许使用服务的调用请求可以过滤,从而保证服务数据安全;平台还需要支持对服务进行流量控制,支持对服务分配流程配额,对于超出流量配额的调用进行限制,从而避免某些大流量调用影响整个平台。

    开发工具及语言支持

    服务共享平台必须支持cxf、axis、python soapbox、xfire、.net等服务开发框架、工具及语言,只需根据预先定义的服务契约进行开发,即可顺利接入平台。

    服务监控和运行统计

    服务共享平台必须支持服务监控,可以方便地监控到服务状态,通过详细的输入输出日志,可以快速定位到运行异常服务原因。服务运行统计包括了服务运行次数,运行时长,运行并发量,运行异常错误等多维度的服务运行统计数据信息。

    ESB总线核心架构分析

    c29bf3dab6b37c0d0d0bd807f4fa8c83.png

    基于对开源ESB产品的研究,以及对Oracle和Tibco的ESB总线产品的实施经验积累,对ESB总线的核心产品架构有了进一步的清晰认识,将ESB的核心架构整理为上图,上图中看到的内容也是作为一款完整的ESB服务总线产品所必须要具备的功能。

    首先整个架构体系里面分为三个组件或子系统,即偏开发态的设计器,偏运行态的ESB核心引擎和SOA治理管控平台三个方面的内容。以上三者组合和集成形成一款完整的ESB服务总线产品。对于三者之间的关系可以简单的描述为:

    ESB总线引擎和服务运行环境

    首先对于ESB总线引擎是一个完全相对独立的内容,即常说的ESB的Server端,一个完整的ESB引擎一般都会集成消息中间件的能力。类似ServiceMix的ESB可以看到核心是基于OSGI运行框架下的ActiveMQ+CXF组件来实现基础核心功能。没有设计器和管控平台,引擎也可以独立部署和运行,即可以自己写代码或写配置文件,将开发好的服务包部署到ESB引擎环境里面。

    一个ESB引擎本身也需要部署在application server里面,即引擎可以部署在类似weblogic,jboss或tomcat等各种中间件容器中。而对于很多开源的ESB可以看到引擎本身已经集成了更加轻量的Jetty作为服务运行容器。对于单独的引擎应该是不需要DB数据库的,即ESB服务运行的log日志审计可以存储在服务端的log日志文件中,只有当安装了管控平台后,我们可以在server上部署代理,准实时的将运行日志信息采集和存储或db数据库。

    ESB设计器和服务开发环境

    518396c126af1bd44245faf1b5027028.png

    其次是ESB设计器,设计器是属于开发和设计态的一个内容,重点则是对http,rest,已经服务+DB,消息等各种内容进行集成。当前类似talend和mule等都提供了很强大的服务设计器能力。即我们常说的服务代理,http和soap服务集成,数据库适配,路由,消息集成和适配,分支和条件判断,异常处理,任务作业,组合服务等都是设计器需要支撑的核心能力。

    设计器设计完成后的内容可以导出为部署包,对于部署包则可以部署到ESB服务引擎中。当前的做法主要有两种,一种是在设计器中本身就提供连接到服务器进行远程和自动部署的能力,另外一种做法则是在SOA管控平台里面提供服务部署和管控的能力。

    设计器往往是给服务开发和设计人员使用,目的是为了简化服务的开发和封装,提升开发效率,一个开放的架构模式最好的方式就是脱离了设计器仍然可以通过其他手工方式进行服务的开发和封装,而不是被设计器绑定。而对于设计器本身的输出,一种是转化为了普通的java代码,还有一种方式是设计器的输出为xml配置文件。可以看到对于xml配置文件这种方式更加方便和解耦,在设计器产生部署包或测试运行的时候,设计器端首先是读取xml配置文件的内容再动态生成和部署服务。

    SOA管理治理-覆盖SOA全生命周期

    cccd2657d10454440db4d3708803b5af.png

    最后一个内容是SOA管控平台,主要的作用是实现服务的全生命周期管理,包括服务的元数据管理,服务目录库,服务的申请,服务的开通和鉴权,服务运行日志审计和监控,服务运行分析,服务预警,服务SLA等各种功能。即SOA管控平台提升了对ESB引擎本身的管控和治理能力。

    管控平台本身也是相对独立的内容,可以看到对于管控平台和ESB引擎本身是彻底解耦的,即如果实施了管控平台,则只需要在ESB引擎上启动管控代理和相关的配置参数,在这种模式下ESB引擎本身运行态的运行信息即可以准实时的采集到管控平台中进行存储和统计分析。

    当然,对于管控平台产品的服务权限管控,服务动态路由设置,服务流量控制等内容,也会影响到ESB引擎在运行态的运行。而通常ESB总线的做法则是对于log日志,安全,流量控制等都是ESB总线的inbound和outbound上的可插拔式的拦截器,通过这种组件动态装载和配置启用的模式来彻底实现管控平台和ESB引擎的解耦。

    对于ESB总线产品本身也应该是符合SOA架构的,即需要实现组件化和服务化,实现服务组件本身的动态加载和热部署,当前类似servicemix在这点上的做法是值得借鉴的,即基于karaf+osgi模式来实现一个组件化的运行框架和环境,极大的方便后了整个运行态的动态管控能力。


    欢迎关注@人月聊IT 分享SOA,微服务,DevOps平台规划和建设。

    展开全文
  • ESB是企业服务总线(Enterprise Service Bus)的缩写,是中间件技术与Web Service等技术结合的产物,也是SOA系统中的核心基础设施。ESB就是一个服务的中介,形成服务使用者->ESB服务Proxy->服务提供者...

    ESB是企业服务总线(Enterprise Service Bus)的缩写,是中间件技术与Web Service等技术结合的产物,也是SOA系统中的核心基础设施。ESB就是一个服务的中介,形成服务使用者->ESB服务Proxy->服务提供者的生物链,中介的作用在不同应用中各有不同:

    • 解耦中介:客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的,交互集成代码提取到了业务逻辑之外,由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService,Http,JMS...),消息转换 (转换、充实、过滤),消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。
    • 服务中介 :ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证,负载均衡,流量控制,缓存,事务控制,加密传输),服务管理监控 (异常处理,服务调用及消息数据记录,系统及服务的状态监控,ESB配置管理),统一安全管理 (这个有点理想主义)。
    • 服务编排 :多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或代码级编排)。


    从上面可以看到ESB的基本功能仍然是数据传输,消息协议转化,路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA,比如借助SCA和BPEL来实现SOA,当时却很难实现消息协议转化和动态路由。

    ESB在发展过程中有从原有的消息中间件转化为ESB产品的,这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成,以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的,自描述的且能互操作的实体。

    对于SOA关注的是服务全生命周期,通过服务实现业务价值。而ESB关注的是服务中介和服务的集成,是SOA的基础设施。SOA有两个核心组件,一个是ESB,一个是BPEL,而ESB是基础设施,BPEL是业务流程驱动下服务的集成和整合。离开了SOA,ESB将失去它所连接的服务,而仅仅是一个总线,同时也将变得毫无价值。Bobby做了一个比喻:路是没有任何价值的,除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA,ESB就像一个没人使用的道路。

    做SOA的事情不要先上来建立一个大而全的ESB,相反是关注你的业务问题,找到用SOA的方法来解决业务上的需求,在解决这个问题的过程当中,你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装,动态地解决你变化的业务需求。这是它的价值,只有这样才能使你的业务敏捷起来,随需应变起来。而在服务的组装过程中,你再去考虑利用ESB来把他们连接起来。

    ESB企业服务总线

    ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而,SOA 可能还有单独的业务服务目录(business service directory),其最基本的形式可能是设计时服务目录,用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录,因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分;然而,在这样的解决方案变得普遍之前,业务服务目录可能与 ESB 是分离的。

    标准的 ESB 功能

    通信

    服务交互

    • 路由
    • 寻址
    • 通信技术、协议和标准(例如 IBM® WebSphere® MQHTTP 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 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同,同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因,再加上最近制订和正在兴起的一些相关标准,当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。

    支持 SOA 的最低功能的 ESB 实现

    如果在前面确定的功能中只有一部分和大多数 SOA 场景相关,我们可能会问:实现 ESB 所需的一组最低功能由什么构成?为此,考虑最被普遍认同的 ESB 定义的原理:

    •     ESB 是一种逻辑体系结构组件,它提供与 SOA 的原则保持一致的集成基础架构。
    •     SOA 原则需要使用与实现无关的的接口、强调位置透明性和可互操作性的通信协议、相对粗粒度和封装可重用功能的服务定义。
    •     ESB 可以作为分布式的异构基础架构进行实现。
    •     ESB 提供了管理服务基础架构的方法和在分布式异构环境中进行操作的功能。

    最低的 ESB 功能

    通信

    集成

    • 提供位置透明性的路由和寻址服
    • 控制服务寻址和命名的管理功能
    • 至少一种形式的消息传递范型(例如,请求/响应、发布/订阅等等
    • 支持至少一种可以广泛使用的传输协
    • 支持服务提供的多种集成方式,比如 Java 2 连接器、Web 服务、异步通信、适配器等等

    服务交互

     

    • 一个开放且与实现无关的服务消息传递与接口模型,它应该将应用程序代码从路由服务和传输协议中分离出来,并允许替代服务的实现。

     


    请注意这些最低功能并不需要使用特别的技术,比如 EAI 中间件、Web 服务、J2EE 或 XML。这些技术的使用非常接近也非常符合需求,但是不必强制要求使用它们。相反,最低功能几乎只需简单地使用 SOAP/HTTP 和 WSDL 就可以实现(当然不是所有的情况都这样):

    • URL 寻址和现有的 HTTP 和 DNS 基础架构提供了一个具有路由服务和位置透明性的“总线(bus)”。
    • SOAP/HTTP 支持请求-响应(Request-Response)通信规范。
    • HTTP 传输协议被广泛地使用。
    • SOAP 和 WSDL 是开放、与实现无关的服务通信和连接模型。


    然而,这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点(point-to-point)的集成,并不能实现一些 ESB 需要的关键功能:

    •     目前还没有用于控制服务寻址和命名的管理功能。服务名称通过每个适配器单独进行控制的,服务路由控制则分散在由服务客户端调用的地址、HTTP 基础架构和分配给适配器的服务名称之间。
    •     虽然这种方法依赖于实现细节,但是它往往并不能使服务实现的替代变得简单;服务请求者代码(也可能是开发工具生成的)通常通过特定地址的特定协议直接绑定到具体的服务提供者实现。如果想要用另一个服务实现来替代原来的服务实现,就需要修改应用程序代码并重新部署这些代码。


    当然,在许多甚至是大多数情形中往往需要其他的功能,并且这种需要变得越来越常见。特别地,不管是现在还是以后,下面的需求类型可能会导致更复杂高级的技术的使用:

    •  服务质量和服务级别功能。
    •  高级 SOA 概念,例如服务编排、目录、转换等等。
    •  按需操作环境需求,比如管理与自治功能以及基础架构智能功能。
    •  跨越具有不同所有权的多个网络、多个协议以及多个域的真正意义上的异步操作
    展开全文
  • 企业服务总线ESB

    2011-11-18 15:19:05
    企业服务总线功能列表: 1.1 通过JMS,MQ,XML,Adapter,Socket,FTP等方式,定时/准时/实时地批量处理大数据量,实现数据交换。同时也支持不同环境的应用程序.net、Delphi、PB等配置运行。 1.2 支持多种...
    企业服务总线功能列表:



    1.1 通过JMS,MQ,XML,Adapter,Socket,FTP等方式,定时/准时/实时地批量处理大数据量,实现数据交换。同时也支持不同环境的应用程序.net、Delphi、PB等配置运行。



    1.2 支持多种格式的接收和转换:JMS、MQ、FTP上传下载、文本文件、xml文件、xls文件、csv文件以及各种其它格式(如:EDI、HL7)等。


    1.3 SOA方式,支持用户部署不同开发环境(如:C /.net/VB/VC /PB/Delphi等)的web service 应用,支持SOAP,WSDL,HTTP(S),XML等技术。实现即插即用。



    1.4 SOA方式,支持用户基于J2EE架构的各种应用部署在该平台上,处理客户的各种业务逻辑。实现即插即用。支持直接部署各种存储过程。



    1.5 工作流配置机制允许用户根据客户的业务流程配置各种业务处理应用JOB的执行顺序。



    1.6 通过数据复制,数据ETL等技术,批量处理数据/信息交换,可用于内容管理、决策支持等服务的构建。



    1.7 支持主流数据库,消除各种异构系统间的数据交换壁垒。



    1.8 性能优化设计,对海量数据处理采用内存计算技术,支持邮件发送、日志查询等操作。多种配置模式,使用户应用更方便。



    1.9 支持安全认证和数据加密、压缩传输。



    1.10 即可单个平台部署,也可多个实例以集群方式部署,有统一的平台管理系统管理这些集群实例.有负载平衡模块负责实例的负载平衡。



    1.11 采用了微内核技术和SOA设计,使产品具备如下特点:
    兼容性和通用性高、稳定性强、性能出色、很强的服务保障和性价比高。



    产品应用范围:



    随着信息化的飞速发展,各个企事业单位、政府各机关、集团、公司内部信息化建设越来越完善,而信息化建设的横向、纵向、立体化、网状化发展还存在着很大的不足,而这些不足深深的制约着各个行业、集团企业、政府机关等现代化建设的步伐。同时这些行业、集团企业、政府部门等又不可能将已经完善的信息点的建设用更全面、更完善、更大的系统来代替,不但难度大、周期长、复杂度高,同时投入成本和各种资源也非常巨大,并且对已经投入的信息系统资源也是一种很大的浪费,在时间、成本、效益上来说都不是很好的选择。
    企业服务总线ESB平台的研发,是专门用于解决各个行业、集团企业、政府、金融等内外部信息系统间互联互通、信息共享、信息采集、信息交换、信息落地,消除信息壁垒、实现信息发展的立体化、网状化的平台产品。不但节省了新信息系统的投入,同时也延长了在用信息系统的生命周期,在信息化建设发展中做出重要的贡献。



    企业服务总线ESB平台适合行业:制造业、物流行业、医疗卫生行业、零售、服装纺织行业、金融、邮电、政府部门等。
    展开全文
  • 企业服务总线ESB是什么

    万次阅读 2018-01-17 18:25:14
    在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级...

     在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构,简化SOA构件间的关系,就一定要建设好信息系统的企业级服务总线。

      一、ESB企业服务总线的概念

      二、建立银行的企业服务总线

      三、银行服务总线的标准功能

      四、企业服务总线的架构

      一、ESB企业服务总线的概念

      (一)总线的概念

      在世界的各种类事物里,总需要相互联系和沟通。这些事物包括人与人之间,组织与组织之间,物理设备之间,应用程序与应用程序之间。

      在没有总线的概念前,这些联系与沟通是自然发展建立起来的,一开始通常都呈现为点对点模式:

      点对点的连接方式在连接对象比较少的时候,确实是一种简单和高效的连接方式。但其最大的问题是,当连接对象多的时候,连接路径会以指数方式剧增。连接路径数与连接对象数之间的关系是:

      具体数字看下表:

      可见,点对点的连接方式有以下明显的缺陷:

      如果连接对象比较多,连接路径会非常多。连接拓扑图是一个复杂的多对多的网状结构。

      如果连接对象各自的连接方式有差异,如:对于程序的连接,如果沟通的语言、文字、格式、方法等有差异,则每一个连接方都要同时支持和维护多种连接方式。

      当某一个连接对象的连接方式发生变化,会引起其他所有与之连接的连接方有所变化。

      基于以上几点,在多点互连的情况下,点对点连接方式成本高,可用性和可维护性低。显然不是一个好的连接方式。

      随着技术的发展,另外一种连接方式开始逐步取代点对点的连接方式。这就是总线连接方式:

      与点对点连接方式最大的区别是,总线连接方式把多对多的连接方式变成一对一的方式。所有连接方均与总线连接,然后通过总线再连接到需要连接的对方。这样,无论连接对象有多少,其连接路径数与连接方的数量永远一样。整个连接拓扑图是一个简单的星形结构。

      不同连接对象如果连接方式有差异,可以通过总线完全屏蔽掉,做到对连接对象透明,无需各个连接对象关心。

      总线的连接方式最早在许多硬件设计上得到广泛的使用。如处理芯片数据总线,网络节点的交换机,大型计算机系统处理器与外围存储设备连接的集线器等。通过总线结构,把原来复杂的网状结构变成简单的星形结构,极大提高了硬件的可靠性和可用性。

      (二)服务总线

      随着计算机信息系统的发展,信息系统也越来越庞大、越来越复杂。总线的概念也引入到信息系统的架构建设上。跟随SOA的概念,信息系统的总线通常叫服务总线。其战略层的总线称之为企业服务总线(ESB)。

      关于企业服务总线的概念,业界有许多定义,但一些基本定义是一致的,归纳如下:

      企业服务总线是一个具有标准接口、实现了互连、通信、服务路由,支持实现SOA(Service Oriented Architecture,面向服务架构)的企业级信息系统基础平台。它提供消息驱动、事件驱动和文本导向的处理模式,支持基于内容的服务路由。SOA架构将各应用服务器(包括异构的服务器)上的各种服务连接到服务总线上,支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性,提高了信息系统架构的灵活性,降低企业内部信息共享的成本。

      (三)企业服务总线的功能

      通常认为,企业级服务总线需要具备如下功能:

      1、 服务统一管理

      为整个系统提供一个统一的、标准的、可靠的、可扩展的服务管理平台。

      2、集成服务

      提供基础的服务与定制的服务;支持集成服务模式;支持服务的分解,服务调度和路由,服务封装,服务组合。

      3、公用服务

      提供内置的各种公用服务。例如,认证服务,日志服务等。

      一些厂家提供的企业服务总线产品,还会包括如下一些功能:

      4、服务协议转换

      通过把不同的通信协议转换成标准的报文,屏蔽异构系统的底层技术差异。

      5、服务监控

      提供服务等级管理及流量管理。提供多角度的服务实时监控、报警与交易分析报表。

      6、安全体系

      提供多种安全机制并支持和第三方安全系统的有效集成,提供有效的安全监控机制。

      (四)ESB产品

      企业服务总线是一个相对新的概念,其产品也是一些较新的产品。从目前的应用案例看,能称得上成熟、完善、通用、成功的案例不多。不同的企业服务总线产品,其功能会有所侧重,使用环境也会有所限定。据了解,目前有如下定位为企业服务总线的产品:

      1、IBM

      IBM的相关产品有:WESB、WMB、WDP。

      2、Oracle

      Oracle的相关产品有:OSB、ESB。

      3、Microsoft

      微软的ESB功能是通过一组产品实现。包括BizTalk、.Net等。

      4、开源

      还有一些开源产品,如:Jboss ESB、Mule ESB、ServiceMix/FUSE ESB、Synapse/WSO2 ESB等。

      Jboss ESB架构图

      二、建立银行的企业服务总线

      企业服务总线无论在概念上还是在产品上,到目前为止,还处在成熟阶段。还没有普遍成功的案例。但金融信息系统的发展,切实需要我们实践这个概念。我们可以外购某个相对成熟的产品,通过大量的客户化形成自己的企业服务总线。另外,从发展新一代信息系统的角度,我们可以探讨如何建设自己的企业服务总线。

      假设,我们的事务处理应用系统有两大部分:渠道系统和业务处理系统。渠道系统又有两大类:柜台终端和自助终端,各自有自己的前置服务器。业务系统分为三大系统:个人系统、卡系统、法人系统,各自也是配置在不同的服务器上。每一类渠道都可以访问任一个业务系统,三个业务系统间也会有业务关联。在没有建立总线结构时,它们之间的逻辑连接如下图:

      从图-3可以看出,我们的应用系统被划分为两个层次:渠道层与业务处理层,分别用两个方框来表示。这两层共包含了五个子系统,分别用五个圆圈来表示。这种架构就是前面所说的点对点连接的架构。关系复杂且维护成本高。根据服务总线的概念,我们需要将其改造成为总线架构如下图:

      从图-4可见,应用系统在渠道层与业务处理层中增加了一层、被划分为三层。这一层就是为了实现服务总线而划分出来的。

      从服务总线的定义可知,服务总线承担的功能比较多。在服务总线里,我们可以把相关功能再进行细分。例如把企业服务总线功能中的一些辅助功能如:服务协议转换、服务认证、服务等级管理、服务流量管理等功能分拆到渠道整合去。功能进一步分拆后的服务总线如下图(图-5):

      从图-5可以看出,此时的服务总线包含了两部分,一部分是与各不同的渠道连接,接受各种各样的服务申请。另一部分与业务处理连接,根据接收到的服务申请,进行服务交付。

      从图-3变换成图-5,表面上好像变化不大,但从概念上说,是有了一个质的变化。

      从宏观上,我们把面对过程的计算机处理变成面向服务的计算机处理。图-5中的每一个圆圈,代表的是一种服务,其软件构成是一个服务构件。其中包括了:

      柜台渠道服务

      自助渠道服务

      渠道整合服务

      服务交付服务

      个人业务服务

      卡业务服务

      法人业务服务

      所有这些服务,他们之间的关系是服务申请方和服务提供方的关系。每一个服务构件,一方面接受处于服务流程上游的服务构件的服务申请,为其服务;另一方面,可以向处于服务流程下游的服务构件提出服务申请,要求其为自己服务。

      以上几个构件构成整个应用系统的几大应用板块层次:

      渠道层

      渠道整合层

      服务交付层

      业务处理层

      其中,作为企业服务总线的渠道整合与服务交付,一个对外、一个对内,实现服务总线的一系列功能。在应用系统架构划分时,可以将其划分为同一个层次,也可以把渠道整合与渠道划分为同一个层次。

      在企业服务总线的具体设计上,要注意以下几点:

      (一)渠道整合

      从总线的概念看,渠道整合应该是服务总线的一部分。建立渠道整合服务层,有几个作用。一是如上所述,把一些属于服务总线的辅助功能从服务交付构件剥离,使服务交付构件功能更为单一。二是屏蔽各种各样渠道的物理差异,使服务交付构件仅面对一个服务对象。第三点是最重要的一点,把从各渠道传递上来的服务申请信息,转换成标准的有限的服务要求信息。

      (二)标准服务接口

      从服务总线的概念可知,服务总线提供的是一种统一和标准的服务管理。为了能够做到这一点,服务交付层应该使用统一和标准的协议和报文。

      图-5中红色的连线,使用的就是标准的协议和报文。

      三、银行服务总线的标准功能

      银行信息系统的企业级服务总线只提供有关客户服务的管理功能,如:服务分析、服务分拆、服务转发、服务流程控制、服务路由控制、服务结果返回等,不提供客户服务本身的服务功能。也就是说,所有业务功能全部交给其他业务处理服务去实现。

      1、服务分析

      通常,应用系统的客户通过应用系统的各种人机交互界面,向应用系统提交服务要求。该服务要求通过系统的各种渠道送到系统的渠道整合层。渠道整合层把客户各种各样的服务要求整合为标准的服务申请报文,送到服务交付层。这些标准报文的头部通常都有相应的服务交易代码或功能代码。服务交付层通过对交易代码的分析,就能知道本服务申请的具体服务要求。

      2、服务分拆与转发

      服务交付层知道了客户服务要求的具体内容后,要把服务交给后面的具体服务构件去完成具体的服务。客户服务的构成有许多类型,有简单的服务,有复杂的服务。所谓简单服务,就是一个服务构件就能完成的服务。对于这种服务,服务交付层直接把服务要求转给相应的服务构件去完成。但对于大多数的服务要求,都不是简单服务,其服务需要通过若干个服务构件甚至一些系统外的信息系统共同服务才能完成。这时,服务交付层要把一个客户服务要求拆分为若干个子服务。把子服务有序地分别转发给相应的服务构件去完成。

      3、服务流程控制

      对于复杂服务,一方面,服务交付层要把服务分解成若干个子服务,要按一定的顺序,把这些子服务交给相应的服务构件。由于各子服务之间通常有一定的因果关系。前一个服务的输出往往是下一个服务的输入,所以,服务总线通常还要把上一流程的某些处理结果打包给下一流程。

      另一方面,服务交付层还要控制整个服务流程的走向。因为复杂服务流程比较长,每一个服务环节都会出现一些影响后续服务流程的结果。这些结果包括一些正常的流程选择条件和非正常事件。对于流程选择条件,服务总线根据不同的条件选择不同的流程,让服务正常持续下去。而对于出现的非正常事件,服务流程将不能正常完成。这些事件有些是由于提交的服务要求没有完全符合业务规则,如密码不符或余额不足等;另外也可能是环境的原因,如网络问题等。当某一个服务环节出了意外,整个服务流程也许不能完整走下去。需要转到另外的错误处理流程。

      4、服务路由控制

      服务交付层要把各子服务转发给各服务构件,要知道服务构件的物理位置。根据SOA松耦合的概念,松耦合既包含了软件模块之间的松耦合,还包含了软件与硬件之间、与地理位置的松耦合。应用系统的架构不强求规定哪一项服务配置在哪种机器里,也不强求规定该机器是在本地还是在远程。服务交付层通过解析服务配置表,找到相应构件的名称和位置,把子服务转发给该服务构件。

      5、服务结果打包与最终返回

      除了服务转换间的信息打包外,当所有的子服务返回的结果均为正确时,服务交付层把服务最终结果整理打包返回渠道整合层。相反,只要有某个子服务出现意外,服务交付层马上中断正常的服务流程,根据不同的意外情况,向渠道整合层返回不同的错误代码。

      四、企业服务总线的架构

      (一)宏观架构

      如上所述,建立了上述的服务总线后,解决了信息系统各应用大板块之间的松耦合,实现了宏观的总线架构。下一步,总线结构还可以在大板块内进一步展开。

      随着我们信息系统的各业务处理系统不断发展,其处理不光覆盖了核心银行业务,还包括了客户管理业务、代理业务、内部管理业务等。所有这些业务可以分类组成若干个大的业务板块。其中有一些板块,不光里头包含了许多业务。且板块内部的各种业务相互间关系比较密切,与板块外部业务的关系相对松散。对于这些大的业务板块,如核心银行板块,我们可以在板块内建立总线结构:

      在图-6里,对于核心银行应用,与图-5相比,服务交付由一层变为两层:服务交付与核心银行交付。这种变化,对于包括核心银行里原来的各个服务以及其他所有服务来说,完全是透明的。假设有一个客户服务是代发工资。在图-5的服务交付对应配置表里,配置了两个子服务,先是法人系统的工资转出服务,下一个是个人系统的工资转入服务。但在图-6里,服务交付对应配置表里只配置了一个核心银行服务,先把服务转发给核心银行交付。而在核心银行交付的对应配置表里,配置了两个子服务:法人、个人服务。从这个例子,可以看出服务总线的灵活与方便。

      在图-6里,从概念来说,渠道整合、服务交付以及各板块的交付合在一起,构成整个企业级服务总线。但在物理配置上,各业务板块的服务交付应该靠近各业务板块,或者与各业务板块配置在同一个服务器里。因为在板块内设置服务交付的前提是我们认为该板块内的各种应用是关系密切的,它们之间会有比较多的交互。把板块的服务交付配置在板块内,可以提高效率,减少开销。当然,如果板块内部的应用关系并不密切,我们就未必需要要设置两层的交付。

      多层的服务总线架构与多层的网络架构概念完全一样。众所周知,比较大的网络体系通常会采取三层架构:核心层、汇聚层、接入层,各层通过其节点交换机:核心交换机、汇聚交换机、接入交换机完成多层的数据传递与交换。相对于银行信息系统,如果采取两层的服务总线结构,服务交付相当于核心交换机;核心银行服务交付相当于接入交换机。通过系统的两层总线,完成服务的交付与流程的控制。

      (二)服务交付层的内部架构

      服务交付层的基本架构是由一组结构大致相同的程序组成。这一组程序我们可以把它称之为服务交易引擎。其中每一个程序通常对应一类客户服务,对应一类交易。并对应与该类服务相关的一组子服务、一组程序。而每一组流程相似的交易通常对应一个标准报文。

      服务交付层还有一组与交易相对应的配置表。配置表的内容有完成该交易所需要的各子服务名、子服务物理路由、子服务后续流程条件码、条件码对应后续服务等信息。交易引擎就是通过检索配置表,解释其中内容,以确定交易的具体服务内容。并确定服务构件名、服务构件路由、服务流程、服务返回内容等。

      通过建立完善的企业服务总线,整个信息系统形成一个以服务总线为中心、逐层往外扩展的的星型网络。分散的渠道把各种服务要求分层汇集到渠道整合,服务交付又分层地把服务分解为各子服务,再分发到各个具体的应用,然后汇集各个子服务的处理结果,原路返回服务的提交处。

      ESB注册试用

      LinkESB由厦门明延科技研发,公司十年专注企业服务总线, 我们致力于打造企业共享服务平台提供商,打造企业上下游的生态圈。传统的企业信息化都是围绕内部人员展开,是一个封闭的系统,而未来的企业信息化,不仅服务企业内部,还要保证上下游企业互联互通,同时客户通过手机可以及时查到到业务的进展。我们的解决方案

      1. 业务上以用户为中心

      2. 技术上以服务为中心

      3. 决策上以数据为中心

      解决方案图

      LinkESB自2007年经过多年的行业沉淀,研发了国内外先进的企业服务平台套件,先后应用于海南省电信、海航集团、厦门国际银行、厦门建发股份、夏商集团等大型企业的IT建设中,以及评众联与坤龙云海等全国性的行业互联网平台的应用。综合对比国内外ESB产商,厦门明延科技的LinkESB在各种行业项目中应用最为广泛,值得依赖!

      你是不是万事具备,就差一个程序员了?

      错!

      你其实差的是一整套解决方案

      了解LinkESB企业服务总线请联系我们,我们拥有全套互联网平台建设经验:平台规划+技术服务架构+开发平台+实施方案+运营思路。

      打开LinkESB网站,一分钟注册开发者账号开始试用吧!



    http://news.chinabyte.com/480/14198980.shtml


    展开全文
  • 企业服务总线

    2017-07-05 14:58:30
    简介如今似乎每个人都需要使用企业服务总线 (ESB),但关于其实际好处以及这一术语所涉及的各种概念还有诸多困惑。下面这些语句透露出这种不确定性:“求助!老板说我们需要一个 ESB”或者“我究竟为什么需要 ESB?我...
  • ESB-企业服务总线

    万次阅读 2017-05-18 13:53:08
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以...
  • 关于SOA的概念,你可以找到...从概念的角度,IBM对SOA的定义是最为全面的,既SOA是一种构造分布式系统的方法,它将业务应用功能服务的形式提供给最终用户应用或其他服务。一个体系架构,用开放的标准将软件资产(Asse
  • 本文内容包括:引言调用服务其他集成功能开发企业服务总线结束语参考资料本文不仅仅是为架构师准备的:使用企业服务总线(EnterpriseServiceBus),作为支持面向服务的体系结构(SOA)的基础架构,也将使开发人员能够...
  • ESB即企业服务总线

    千次阅读 2018-08-13 10:10:06
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。  ESB的出现改变了传统的软件架构,可以...
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • 随着面向服务的体系结构(SOA)越来越受到人们的重视,以及Web服务规范系列的复杂性不断增加,对于如雷贯耳的企业服务总线(ESB)之类的术语难免会感到困惑。它是一个产品?还仅是一个营销术语?它是否代表了可以实际使用...
  • ESB企业服务总线

    2009-04-15 10:22:00
    ESB ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 ESB的出现改变了传统的软件架构,...
  • 摘要:本文介绍在银行中常见的企业服务总线应用架构,以及服务总线的集成规则等。在SOA的总线型架构中,服务总线处于总体架构的核心位置,是连接银行不同应用的枢纽,银行的不同应用通过服务总线连接共享服务,服务...
  • 完全国人自主研发原创的智能软件路由器即将...完全国人自主研发原创的智能软件路由器BDS即将发布,附带企业服务总线ESB功能 智能软件路由器 BDS 简要介绍 http://kan.weibo.com/con/3626382295795881  ...
  • 企业服务总线(EnterpriseServiceBus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息,以及基于事件的...
  • Mule是一个以java为基础的企业服务总线(ESB),该集成平台允许开发者在遵循SOA服务导向式架构方法学下快速便捷的将不同应用程序连接在一起交换数据。可以忽略各个应用程序中使用的不同技术,使他们集成在一起。 Mule...
  • ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以...
  • 完全国人自主研发原创的智能软件路由器BDS即将发布,附带企业服务总线ESB功能 智能软件路由器 BDS 简要介绍 http://kan.weibo.com/con/3626382295795881 http://kan.weibo.com/con/3623208964817369 BDS Li....
  • NServiceBus 是一个.Net平台下开源的消息服务框架,这类产品有时也被称作ESB(Enterprise Service Bus)——企业服务总线。NServiceBus也是dotnet世界里面最流行的开源企业服务总线。 NServiceBus 是一个用于构建企业...
  • 作为基础架构的EAI系统,必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的,消息的处理需要各自中间件的私有方式支持,例如API的方式。...这也是ESB中总线(Bus)功能的体现。
  • 同时也介绍了产品的扩展功能功能和一些高级使用技巧。 重点: 日志管理  死信处理 客户端  群集  交易 触发  报告  事件 分段与分组  分发列表  发布订阅  数据转换  用户出口   安全套接...
  • 系统采用最新的SOA架构思想、B/S结构模式,依托企业服务总线实现各业务系统数据交换及共享。数据交换与管理模块采用Web Service接口方式实现业务数据的同步,为建设权威、一致的船舶及港航企业主数据库提供数据基础。...
  • 面向服务的体系架构 SOA Service Oriented Architecture (SOA)是一个粗...企业服务总线 ESB Enterprise Service Bus (ESB)是由中间件技术实现的全面支持面向服务的基础软件平台,是传统中间件技术与XML、Web服务
  • 运行端到端测试结束语下载参考资料第1部分介绍了IBM:registered:WebSphere:registered:EnterpriseServiceBus(ESB)提供的用于构建ESB的关键功能,其中使用了一个贯穿本系列的示例业务上下文,还阐述了...

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 362
精华内容 144
关键字:

企业服务总线功能