精华内容
下载资源
问答
  • 企业服务总线ESB

    2011-11-18 15:42:33
    企业服务总线功能列表:   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 企业服务总线

    万次阅读 2013-08-24 10:36:41
    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾为@肖俊_David 。 @肖俊_David 恒拓开源架构师,热衷于JAVA开发,有多年的企业级开发经验。曾参和设计和开发基于FuseESB 企业服务总线系统,对...

    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾为@肖俊_David 。

    @肖俊_David 恒拓开源架构师,热衷于JAVA开发,有多年的企业级开发经验。曾参和设计和开发基于FuseESB 企业级服务总线系统,对FuseESB企业级服务总线以及内嵌的Camel/ActiveMQ 有深刻的理解。

    ESB 全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    ESB 相关的开源软件:http://www.oschina.net/project/tag/333/esb

    主要有价值的问题整理如下:

    1、先简单介绍下 ESB 的应用场景吧,相信很多人还是不太了解 。

    肖:一般用在企业内部业务系统比较多,相互之间调用比较复杂,接口的维护花费比较大,并且不同的系统采用了不同的开发平台、传输协议、数据格式等,这种情况下就需要考虑使用ESB了 。

    2、这么庞大的一个系统,设计时候遇到的难题及解决方法是什么?在系统性能上从那些方面优化?

    肖:主要体现在各业务系统数据的整合/ESB路由的安全/流量控制等方面。 性能方面是这些方面的优化:负载均衡/应用服务器集群/缓存/数据库的读写分离/Restful WS/WS接口数据的压缩/消息的异步传输/。具体可以参考此文档http://www.oschina.net/doc/593。

    3、对于大并发的实时交易的系统,选用ESB作为数据总线,其性能如何?在线人数100万,并发1000左右的交易,基于WS与ESB进行对接,中间不介入MQ 。

    肖:根据我们对Fuse ESB的性能测试情况,直接访问WS与通过ESB来访问WS,性能影响不大,当然具体的性能损耗,还与你采用的ESB产品有关!我们目前做的项目,部署了两台ESB,前面通过LVS做负载均衡,调用WS的TPS可以达到 600-800左右。

    4、ESB的具体应用及其担任的角色是什么呢?

    肖:中介、路由转发、格式转换、协议转换、安全控制。

    追问:您好,针对于您说的路由转发,可否再阐述下,

    肖:就是说路由转发的机制,可以是业务人员定义的,由业务人员来定制转发的流程。

    5、ActiveMQ 比较适合哪些企业应用场景?能否举个例子简单说明下,体现使用了ActiveMQ的价值。

    肖:ActiveMQ主要优势体现在消息的异步/推送上, 提供了多种语言的客户端。它可以用于异构系统的整合,如我需要向其它系统推送一个消息,只需要把消息发送到MQ服务器,便可以去做其它事情,MQ服务器来保证其它系统数据的接收;另外,系统包含大量的业务日志数据,也可以考虑使用MQ来异步处理。

    追问:MQ服务器一般采取哪些部署方案呢?对于处理大量业务日志,单台MQ服务器是否足够?

    肖:看机器性能, 我这边性能测试 4核/4G内存/linux,MQ的收发大概可以到5000条/秒。如果有高可用的需求,需要做MQ集群。

    追问:你是说先把日志内容发给MQ,再由MQ发送给日志系统? 

    肖:是的。

    6.请问实际的安全问题是怎么处理的,给点思路,谢谢。

    肖:在ESB的路由程序中,加入安全认证机制。如用户名/密码认证,访问控制认证等。MQ的安全认证,可以通过安全插件来实现。

    追问:谢谢哈,那我还想了解下路由程序的大概作用,是不是就是处理请求,使其匹配业务逻辑的那种? 

    肖:具体可以参考此文档,第二个案例 http://www.oschina.net/doc/593 。

    7.能不能介绍下现在主流的esb产品. 包括商业和开源的?

    能不能重点介绍下fuse产品,要是直接部署使用的话,有什么要注意的. 

    fuse好像是基于osgi的.话说osgi好像比较难搞呀.

    个人能不能提供咨询服务?

    肖:商业主要有 IBM/ORACLE ESB,高达6/700W 的单机许可费。开源的有ServiceMix/Fuse/JBOSS/Mule 等ESB产品。 ServiceMix/Fuse ESB 4.X以后是基于OSGI架构的,提供了很好的扩展性,上手是有点难度。目前很多产品都在往OSGI靠拢,如JBOSS AS 7。 谈不上咨询,大家互相交流学习。

    8.如果所有的服务接口都接入ESB,ESB怎么保证安全服务,如果ESB挂掉,那所有的应用系统也无法服务了,加一些缓存集群是否能彻底解决这样的问题,可否做到我调用一台机器时那台机器挂了,直接将服务切到另一台机?

    肖:可以部署多台ESB集群,在ESB前面可以通过F5/LVS等来做负载均衡,若是LVS,可以通过心跳来检测当前ESB的服务状态,若是一台出现宕机情况,可以把请求转发到其它ESB 。

    9.问个具体点的问题,我做了个实验项目,架构是这样的:webapp+serviceMix,需要在webapp端控制路由的部署和启停。

    部署就是将bundle放到相应的文件夹下了,命令通信还没实现,找了资料(http://svn.apache.org/repos/asf/karaf/trunk/client/src/main/java/org/apache/karaf/client/Main.java)是用ssh实现的,

    不知道除了这个还有没有其他更好的方法。另外,部署不知道还有没有其他方法。

    肖:这种是通过远程SSH,来管理ESB控制台,控制bundle的启动和运行。你可以参考下 Karaf的 webconsole是如何做的bundle管理。

    追问:谢谢,借此机会多问一下,想请问下除了用ssh远程管理esb外,还有没有其他方案可以让web与esb结合,比如在webapp中集成karaf和camel可行不?另外apache ode已经与新版本jboss esb不兼容了,你们是如何做webservice编排的?多谢了~

    肖:ESB 部署bundle,bundle集成Camel,服务编排用Camel 的 EIP 。

    追问:谢谢,个人认为Camel EIP不太适合做服务编排,虽然有java DSL,还是没有BPEL合适。现在在用bpel-g 。

    肖:bpel是基于SOAP协议的,会占用大量带宽。

    10、想问一下开源的esb选择哪个比较好,现在在openESB和WSO2 esb中犹豫,希望得到您的指导。

    肖:这两种ESB我还未使用过:),建议你用主流ESB。

    11、ESB能够提供什么服务,能够帮助解决问题1中的这些问题?为什么要使用ESB?如果不使用,其实没什么问题,对不对?它最大吸引力在哪里?

    肖:1、多系统之间的互相调用会造成网状结构错综复杂 。

          2、接入ESB后,服务都集中在一处调用,原系统如果是以ws公开的服务,经过esb包装之后,可以公开称多种协议适配各种客户系统调用 。

          3、ESB可以统一的进行日志、安全和权限以及SLA治理,很方便进行控制。

          4、ESB作为众多系统的入口,还可以很方便的在一处实现跨系统的流程整合和编排 。

    12、除了 Redhat 和 JBoss 的文档,还有什么好的 Fuse ESB 学习资料吗?

    肖:很多,Fuse ESB集成了很多开源项目,如Karaf/CXF/ActiveMQ/OSGI等,这些你都需要有所了解,去他们的官方有文档,书籍方面 你可以参考 Open Source ESBs In Action不过版本有点老了。

    13、在医院的药品管理系统、挂号系统、医生/护士工作站、财务等各种his系统当中esb可以扮演什么角色?或者说他适用这种环境吗?有木有类似的项目?哈哈,我是业余前端,问得不好还请见谅。

    肖:可以适用,接口都可以接入ESB。

    14、activimq用topic还是queue?对于客户端向ESB发送数据需要返回值的情况,对于activimq 有什么好的解决方法没?

    肖:目前好像还没好的办法,可以创建一个返回队列来实现 JMSReplyTo 。

    other:既然对于请求需要有返回值,这属于RPC的范畴了。可以基于 Camel 做 RPC。

    15、esb对性能是不是有很大影响,刚用,发现速度会差一半.

    肖:看不同的ESB产品 ,Fuse ESB我们做性能测试,性能损耗是很小的。

    16、另外想咨询:
           1、在设计数据变更推送的机制,我们目前是在数据表上加触发器有字段更新写到中间表记录,然后一个定时任务去扫描这个中间表,然后形成特定的发送记录。
           2、ActiveMQ 在大量消息下性能是否可靠?
           3、ESB接入多个系统后,是直接访问源系统的数据库,还是在中间库做一份镜像?如果是直接访问数据库,事务控制等应该怎么做?如果是中间库,如何保证数据的实时性呢?
    肖:大量消息下,消息的可靠性是没问题的,MQ做了大量的工作保证消息的可靠性,如消息存储在文件/客户端的确认机制等,性能上要根据实际的场景调优MQ的性能。 我们是把其它业务系统的核心数据抽取到本地库中,通过Kettle ETL+quartz定时抽取。如果实时性比较高,可以考虑数据库复制,触发器等。

    17、现在项目是不是已经整合到JBoss ESB中了呢?相关的文档都需要从JBoss上下载吗?

    肖:http://www.jboss.org/products/fuse http://fusesource.com/products/enterprise-servicemix/

    18、想问下在ESB中,在多个系统交互时,如何控制数据的一致性呢?遇到异常如何回滚呢?

    肖:事务的补偿机制。

    追问:ESB中有实现事物补偿的么?那些资料可以参考呢?

    19、现在的 ServiceMix 支持部署 WAR 应用了吗?

    肖:支持。

    追问:这个回复过于简单了。OSGI-4.3引入了WAR支持。WAR首先被转换成一个bundle(WAB),然后启动。在这个过程中,很容易出现类库冲突,导致启动失败。详情请参考osgi.cmpn-4.3.0.pdf("OSGi Service Platform Service Compendium")中的"Web Applications Specification"章节 。

    另外,OSGI也有自己的适用场景,如果没有模块化需求,不应该引入OSGI。单纯的WAR项目就没有必要改造成OSGI项目。

    肖:除了 OSGi,模块化还有什么别的选择?SOA? 

    话说 Spring 不支持 OSGi 的原因是什么呢?Hibernate也是用Gradle构建,照样在努力地向 OSGi 靠拢。

    追问:应该是吧。我认为,OSGI 也可以认为是广义上的 SOA . Spring 支持 OSGI 的啊,你是不是看错了?

    肖:InfoQ 上等过 SpringSource 打算放弃支持 OSGi 的新闻。

    在最新的版本里面已经移除了 OSGi 的 manifest 文件,我是从 Maven 官方库里面下的 。

    追问: 你这么一说我也记起来了。之前 Spring 是支持 OSGI 的,动态模块还是 spring 搞出来的。放弃支持是他们的决定吧,我觉得OSGI的复杂性应该是其中的重要因素。

    20、消息能支持多大呢?能否支持10M以上文件推送?

    肖:你指的MQ?

    追问:对, ESB 一般不包括MQ这样的消息中间件吗? 

    肖:可以试试 MQ的BlobMessage;或者把文件拆分然后分组发送。对于太大的文件不建议使用MQ来传输。

    21、关于分布式日志采集,一般说可以采用ActiveMQ/MetaQ等实现。我的疑问是:网络写速度比不上本地文件系统写,实践中怎么解决这个问题?

    肖:分布式日志采集,这里没看懂。是对分布式系统的日志采集?

    22、为什么不把部分接口服务以RESTful方式暴露,看你里面全是webservice。

    肖:是Restful风格的WS。

    23、ESB和RPC(比如Dubbo/Corba/ICE)等适用场景,能介绍一下吗?谢谢。

    肖:ESB和RPC是完全不同的两个概念,PRC是点对点的消息传递,ESB是所有的服务接口都接入到ESB,通过它来转发 。

    24、正好我也是在做ESB,我想请教您,对于Mule ESB 有所了解吗? 或者您是否能提供一点你选用Fuse ESB方案的考虑吗?

    肖:这个是我们ESB技术选型的一部分资料:

    Mule ESB拥有了不错的用户量,且比较容易上手,但其由于其企业版是商业产品,相需要收费,且架构本身并没有成为规范,因此,若在没有源码的情况下大规模使用,一旦出问题,可能需要专业技术团队的支持。另外,Mule之前是没有自己的消息中间件的,且不支持热部署,收购Mule MQ之后才真正成为一个正式成熟的ESB。 

    Fuse ESB很好的支持了JBI规范,其下产品均是由Apache下的著名开源项目组合而成。其中若干框架均已为开源世界广泛应用,比如Apache Camel和Apache ServiceMix,尤其是其中的Apache ActiveMQ和Apache CXF,且ServiceMix 4之后基于OSGi架构,更能迎合企业动态化、模块化的需求。此外,Fuse有丰富的文档支持,加上其主要框架为大多开源人士所熟知,技术上可控性强,风险较小。

    25、问题如下:

           1、同步接口调用,怎么处理?有一些需求要同步返回调用结果。

           2、想涉及一些支付业务的服务,事务怎么处理? 

           如:下订单业务,首先要调用“商品模块服务”查询库存,然后才能决定下单业务是否可以继续,如果库存充足,则要:    
           1)调用“商品模块服务”锁库 。
           2)调用“订单模块服务”保存订单。
           他们之间的事务怎么保证?能否给些思路。

    肖:ESB 只是做了路由转发功能,除了MQ,大部分都是同步的。Camel内部也做了一些事务的保障机制, 若是中间牵扯到了 多系统流程服务的编排,最好定义好发生异常后事务的补偿机制。

    26、能不能多讲一下ESB的应用场景和不适合的应用场景。

    肖:涉及到多系统整合或者服务流程整合,就要考虑是否需要上ESB。

    27、FuseESB 稳定版本是哪个版本?下载时候是 6.0 版本包,怎么官方文档是  7.1 ,还没搞明白。

    肖:7.1是没被收购之前的,现在被redhat收购,改名叫 Jboss Fuse。 

    28、将各种异构的子系统整合,由一个统一的中间件调度服务的架构就可以称作ESB吗?

    肖:这个是ESB的核心功能,还包括服务编排/消息增强/协议转换/格式转换/安全控制/服务质量等。

    29、ESB怎么保证消息的可靠传递?

    肖:如果是JMS消息,ESB中的MQ会持久化该消息到文件或者数据库。若是其它协议的消息,发生异常或者其它自定义状况,ESB会捕获到该状况然后经过处理告诉客户端。

    30、您好,能否比较几种常见的ESB产品(集),mule esb/cordys/Jboss esb/open esb ? 它们分别的适用场合是什么?特别是您对Cordys的看法?

    肖:ESB的功能都差不多,你要更详细的比较:可以去看看 Forrester研究公司(http://www.forrester.com),在2011年第二季度对“企业级服务总线”做了一个详尽的研究报告,比较了IBM、Oracle、Progress Software、Software AG、Tibco、FuseSource、MuleSoft、Red Hat和WSO2等诸多商业和开源厂商的ESB产品。

    31、ESB 对企业部门之间的信息孤岛的破解,是否有帮助,如果有的话,处理策略是什么?

    肖:造成信息孤岛的原因主要是系统之间通讯不畅,把各系统对外的接口都统一连到ESB即可,避免各系统的相互调用造成复杂的网状结构。

    other:n*n 和 1*n ,这种在系统庞大的企业中,是非常有价值的。

    jack:谈到ESB两大主流是Mule和Camel。Mule用户多一点。不过Camel接口更多,而且迭代速度更快。试过Camel+karaf发现对数据库支持这块osgi略差一些。于是采用Camel+spring。使用下来各方面都很出色,推荐此方案。

    32、请问ActiveMQ用的什么版本?怎么整合的?如何保证数据消费的可靠性,有没有出现丢消息或者假死的问题?

    肖:Fuse ESB默认就集成ActiveMQ,未出现你说的现象,不过如果发的太快,收的太慢会出现你说的情况,可以在接收端增加负载来解决 。

    33、esb如何解决多系统的数据一致性问题?例如在转账这种需要跨数据库事务的场合下怎么搞定?

    肖:可以定义流程发生状况的补偿机制,一旦服务流程流转中出现问题,所有执行过的活动都按特定的逻辑进行补偿 。


    展开全文
  • 关于SOA的概念,你可以找到...从概念的角度,IBM对SOA的定义是最为全面的,既SOA是一种构造分布式系统的方法,它将业务应用功能服务的形式提供给最终用户应用或其他服务。一个体系架构,用开放的标准将软件资产(Asse
  • 本文内容包括:引言调用服务其他集成功能开发企业服务总线结束语参考资料本文不仅仅是为架构师准备的:使用企业服务总线(EnterpriseServiceBus),作为支持面向服务的体系结构(SOA)的基础架构,也将使开发人员能够...
  • 企业服务总线ESB是什么

    万次阅读 2018-01-17 18:25:14
    在探讨信息系统的SOA架构概念时,一个非常重要的概念是:企业服务总线(ESB)。可以说,企业服务总线也是SOA的核心构成部分。... 三、银行服务总线的标准功能  四、企业服务总线的架构  一、ESB企

     在探讨信息系统的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


    展开全文
  • 随着面向服务的体系结构(SOA)越来越受到人们的重视,以及Web服务规范系列的复杂性不断增加,对于如雷贯耳的企业服务总线(ESB)之类的术语难免会感到困惑。它是一个产品?还仅是一个营销术语?它是否代表了可以实际使用...
  • 企业服务总线

    千次阅读 2006-06-19 16:34:00
    ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有...
    ESB
    
    Enterprise Service Bus
    ,即
    企业服务总线
    )是传统
    中间件
    技术与
    XML
    、Web服务等技术结合的产物。
    ES
    B提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 
    

          企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如IBM的WebSphere MQ、Tibco的Rendezvous和Sonic Software的SoniCMQ)。ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议,以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。

          企业服务总线(Enterprise Service Bus,ESB)的概念是从面向服务体系架构(Service -Oriented Architecture, SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型,其中的软构件集是以一种定义清晰的层次化结构相互耦合,其中,一个ESB是一个预先组装的SOA实现,它包含了实现SOA分层目标所必需的基础功能部件。

          ESB是传统中间件技术与XML、Web服务等技术相互结合的产物

          计算机技术和软件技术应用于企业已经有30年的历史了,这也是软件技术发展的主要动力,目前它已经进入到一个新的发展阶段。由于各个企业持续的对内外部的整个价值链的业务操作进行流程化和智能化的改进,业务整合有了非常重要的成长。无处不在的IT技术将以前只能想象的事情变成了现实,它可以帮助实现从后台到前台,到合作伙伴,及到客户的业务市场的扩展,这种IT应用整合需求趋势为ESB平台的兴起着重要的铺垫作用。

      ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信与整合。从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的传输能力,并可以提供一系列的标准接口。

    一、企业服务总线(ESB)可以有那些用处

          ESB不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法.

    二、企业服务总线(ESB)的应用特征

          大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构(SOA)是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来,只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务,那么其他应用系统就可以很方便的使用这些功能服务。

           支撑SOA的关键是其消息传递架构-企业服务总线(ESB)。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物,用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务协调运作,实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途:

    电信领域

    ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。

    电力领域

    ESB能够在全方位支持电力行业EMS的数据整合概念,是理想的SCADA系统数据交换平台。

    金融领域

    ESB能够在全方位支持银企间业务处理平台的流程整合概念,是理想的B2B交易支撑平台。

    电子政务

    ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。


    三、企业服务总线(ESB)的结构和功能

          ESB提供了一种开放的、基于标准的消息机制,通过简单的标准适配器和接口,来完成粗粒度应用(服务)和其他组件之间的互操作,能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。InterESB专门用于异构环境,既可以帮助企业迁移到SOA,又能够让企业继续利用现有的已部署的软件投资。

          通过使用ESB,可以在几乎不更改代码的情况下,以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口,并能够在部署环境中支持任何标准。更重要的是,充当“缓冲器”的ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑相分离,从而使得不同的应用程序可以同时使用同一服务,用不着在应用程序或者数据发生变化时,改动服务代码。

     

    四、InterESB的功能特点

          多种通信技术的综合应用

           InterESB利用了多种公认、成熟和可靠的通信技术,来支撑上层数据传输的多种模式。在CORBA以及JMS技术的基础上,InterESB能够同时支持同步通信、异步通信模式。

          在异步模式中,InterESB创新地将多种通信模式融为一体,其中包括目标通信模式(MesSAge Channel)、点对点通信模式(Point-to-Point)、发布/订阅通信模式(Publish-SubsCRibe)、扩展的发布/订阅集群模式(P/S CluSTer),并支持通信过程中的加密、压缩、断点续传等重要保障功能。

          InterESB将上述多种通信方式有机封装成一个整体,并通过CORBA IDL、SOAP、JMS等标准接口方式对外进行发布,从而使得基于InterESB构建的企业应用能够以透明、一致、高效的方式应用不同的底层通信机制。

          高度灵活、可分布部署的信息总线

           在InterESB内部,由部署在不同节点和计算域下的多种消息通信服务实现灵活的企业应用通信功能。同时,InterESB支持对这些通信服务的面向问题领域可不断优化的分布式部署功能,包括有以下三种模式:

           全连接的总线模式,在InterESB内部部署全连接方式的消息服务器;

          集中可拔插方式的总线模式,在InterESB内部部署一台超级转发服务器;

          “雪花状结构”的分布级联方式,在InterESB内部分区域部署多个超级转发服务器。这种模式在大型SOA系统中部署具有很强的动态增长性、可管理性、可维护性和极高的效率。

          便捷、标准的企业应用集成模式

          InterESB提供了简单、快速、基于标准的多点集成功能。InterESB为企业应用开发和集成提供了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。在InterESB中,基于标准的服务成了应用间的集成点。也即围绕服务的所有模式都是以基于标准的技术实现的。这使得InterESB可适应于任何现有系统,并使得系统在集成时不必刻意遵循任何特殊定制。

          InterESB在面向企业应用集成需求时,可以表述为数据传输和应用集成两部分的内容。其中,数据传输涵盖了用户应用系统中的文件数据库、消息、事件、指令等全方位的数据传输内容;应用集成涵盖了数据集成、应用集成、设备集成、协议系统封装等多方面的应用集成内容。


          灵活的适配器技术

           一个设计良好的适配器的作用好比是一个设计良好的SOA服务,它提供了一个抽象层,把应用基础设施的其余部分与各种棘手问题隔离开来。

          通用适配器是InterESB为解决系统之间的连接而开发的可重用的、统一的接口,通过该接口每一个应用系统仅需要与业务整合平台相连,而不需要与每个与之交互的应用系统相连。InterESB适配器一般包括遗留系统适配器、技术标准适配器和适配器开发工具。

          与CORBA、J2EE技术的结合

          InterESB底层基于CORBA分布计算中间件InterBus以及遵照JMS规范的InterMQ消息通信中间件,因此,可以说InterESB与CORBA、J2EE具有天然的结合优势。

          但InterESB并不等同于CORBA。与CORBA技术相比,InterESB继承了CORBA技术的开放标准、分布式架构、组件技术以及高性能,适合于复杂的应用集成等优点;同时,InterESB还提供了CORBA技术所不具备的SOA功能,即:

    InterESB支持更多种技术标准;

    InterESB支持更广泛的互操作性;

    InterESB具有更好的可扩展性;

    InterESB对专有系统的支持;

    InterESB对未来标准的支持。

    通过J2EE支持的MDB/JDO,InterESB也能够很容易的和J2EE应用系统相连接,形成有效的功能集成。

          广泛的平台支持

          InterESB插件式体系结构在每个层次上都是开放式的,这样就可以与现有的基础组件实现透明的互操作,让用户能够对速度、成本和使用技巧方面的因素加以权衡。InterESB能够在忽略传输系统的情况下,使用包括XML和二进制在内的任何格式发送数据,并能够在任何开发平台(C++和Java)上实现,而不是强制所有应用程序都使用相同的开发语言。

          InterESB包括全连接的总线模式、集中可拔插方式的总线模式和“雪花状结构”的分布级联方式。


    五、企业服务总线(ESB)距离实际的企业应用还有哪些不足?

           ESB目前有很多商业方案,也有很多开源产品,例如objectWeb,CodeHaus,Sourceforge都有这样的开源项目.距离真正成熟还有一段距离,另外各家厂商都各自为阵,目前JCP还没有这项技术的草案,标准的指定也还有很长的距离.当然,目前的状态和SOA一样.相信等SOA真正普及的时候,ESB会更加的成熟.

    六、企业服务总线(ESB)技术与革新

      由于更大任务所带来的要求,消息传递技术现在正处于发展之中。为了给当今的实时企业提供其所需的灵活性,就需要一种混合的消息传递模型将 Web 服务的优点与传统的异步消息传送结合在一起。

      传统消息排队中间件将很快被企业服务总线(ESB)技术所取代,从而将消息传递带到新的高度。新的ESB骨干(催生了下一代集成和应用平台产品)将显著改善多数企业的软件基础架构。行业正转向消息传递和ESB,并以此作为核心应用平台基础架构模型,这将标志着一个转折点:围绕企业对其信息资源的使用而触发了新的一轮巨大的革新浪潮;企业都正在利用事件架构。这都将消除最近人们对 IT 在战略性业务区分中可扮演关键角色的所有疑虑。

      简介

      在过去的10年中,竞争压力和日新月异的技术根本地改变了企业的运行节奏。在过去,企业可以根据月底的成批报告来进行决策。现在,实时流程意味着如果原材料在早上出现问题,或者有停电事故发生,那么就会造成下午无法交付和托运成品。于是,企业不得不以越来越快的速度应对突发事件――否则,它就要靠边站了。“零时延企业(zero latency enterprise)”的时代已经来临。

      当今的企业环境正在一点一点的发展以应对这个挑战。异构存储、网络和硬件支持着“孤岛计算”(应用程序与数据相互孤立或者条块分割),这导致环境的利用和管理都过度复杂,并使之变为资源密集型。对于企业所必须面对的大多数关键挑战而言,这种复杂性无疑是一种障碍,这些挑战包括:

      满足对利用多渠道传递大量信息服务的不断增长的需求。

      实时管理基础架构以满足不断变化的业务需求。

      使业务多样化以促进业务灵活地增长,并降低与固定产品线相关的经济风险。

      确保对客户、合作伙伴和雇员的信息服务请求做出快速且高质量的响应。

      在过去几年中,EAI、B2B和应用开发等方面的迅速发展推动了几种关键技术和标准的发展,这些技术和标准又推动了基础架构领域的显著进步:

      XML 作为通用的、自解释的数据交换格式,已经为大多数应用程序所采用。面向 Web 的信息交换以及其后的基础架构,与 XML 一起使 Web 服务的使用成为不可避免的事情。

      Java 已经作为用于服务器端的一个主要技术而被接受,并且J2EE 已经作为应用服务器的标准而被接受。

      企业服务总线在事务性消息交换和实时事件通知领域的使用已经围绕 Java 消息服务(JMS)而被标准化了。

      通过 Java 管理扩展(JMX)标准已经实现了服务器端组件的公共管理框架。

      基础架构必须像业务一样运转

      瞬息万变的市场需要通过多渠道传递大量的信息服务。下一代的企业要求松散耦合的资源能够共享跨越多领域的公共通信和管理基础架构。企业基础架构不得不像有形的业务那样运转,允许对资源进行动态管理以应对客户和合作伙伴的需求波动,同时处理系统资源的供应和可用性变化。企业应用程序也需要一个基于标准的协作模型以最大程度地利用该基础架构。为此,实时企业使用了来自实时基础架构的最好做法和服务器端的网格技术(gridtEChnology)。

      实时企业的组件

      形成实时企业的一些概念与用于定义服务器端网格环境的概念相同,用来描述其核心组件(见表1)的结构类似于GArtner的 5 层网格技术模型。

      一个建立在现有的而且是被广泛采用的技术和开放标准之上的ESB可为服务协作、管理和控制提供一个可适应的分布式架构。ESB支持在企业内部的任何地方进行业务服务的运行时部署,并提供协作和通知服务作为其核心基础架构的一部分。让我们看一下 ESB 技术是如何映射到 Gartner 的 5 层模型的。 

      基础架构资源和虚拟操作系统

      第0层由基础架构资源组成,包括网络、服务器、存储和每台服务器的操作系统环境。第1 层位于基础设施层之上,并建立了一个多资源的分布式操作系统,它支持的功能如进行工作计划、将资源名集成到总体结构中以及确保不同系统间的一致认证。

      尽管Gartner将J2EE 作为一个第 2 层的技术,我们相信分布式 JMX 和一台基于 J2EE 的应用服务器的结合会具有虚拟操作系统的特点。使用对所有组件和服务提供部署和完全 JMX 管理的容器或者微内核,从而允许对服务进行远程激活和管理。

      JMX作为一种技术最初设计用于管理单个代理,如一台应用服务器。JMX通过与JMS 的结合,其范围就可以扩展到管理单个代理、群集或松藕合的联合体(如果您喜欢,亦可称之为超级群集),允许对联合的 ESB 基础架构进行全生命周期和部署管理。由于 JMX 同时也集成了许多传统的管理协议,如 SNMP,因此ESB 基础架构可以为 Java、Web 服务和传统平台提供随需应变的(on-DEMand)的热部署和自我修复(self-annealing)式的基础架构。

      分布式编程模型

      分布式编程模型构成了实时企业的第1层:可在应用程序和服务(无论是内部还是外部)之间进行协作和通知的核心基础架构。ESB提供事件通知、动态路由选择和事务性确保传递;并且使用一个定义明确的过程语言以使应用程序通过一个公共 API 进行活动协调。

      实时企业要求在恰当的时间将正确的数据传递到正确的位置;JMS(Java消息服务)提供事件分布和事务性确保传递的方法。同时也需要智能数据结构(datafabric),它可以在需要的时候在网络范围内进行信息分发,目的是提高吞吐量和降低宝贵的后台系统的负载。该结构的骨干是通过JCache (Java 通用缓冲框架)所形成的。

      一个类似于Linda的元组空间(tuplespace)将消息队列的“一个且只有一个”传递语义与发布/订阅的广播功能和对等系统的松藕合结合到一起。元组空间就如同由无限数目的进程所共享的相连内存。进程可以向该空间中添加元组(本质上就是数据对象),或者从中取出元组来以独占的方式工作――如果需要的话,可以一直处于等待状态,直到匹配对象的出现。进程也可以读取元组而不需要将其从空间中删除。该范例(将消息队列的“一个且只有一个”传递语义与发布/订阅的广播功能和对等系统的松藕合结合到一起)被映射到 Jcache 的顶部,它提供一个该概念的高性能分布式实现。

      这也可以和一个业务流程模型引擎(例如,jBPM:www.jbpm.org)结合起来以提供一套丰富的分布式编程域。进程之间独立工作——从元组空间那里获得适当的输入,并将输出放回元组空间以便进行后续任务。进程在元组上的执行顺序比在传统工作流系统上的执行顺序所受到的约束要少。该模型提供分布式共享内存、通用的群集、并行计算以及分布式工作流和BPM 的基础。

      应用程序

      构成实时企业第3层的应用程序依赖于企业基础架构的资源,以及使用协作编程模型进行相互通信。架构师们已经意识到更松散藕合的和多层组件模型的优越性,而不是开发独立的或简单的两层客户/服务器(C/S)应用程序。为定义、发现和实际执行该模型(例如WSDL、UDDI 以及用于 Web 服务的 SOAP)而采用的标准有助于面向服务架构的实现。

      作为虚拟操作系统基础的J2EE应用服务器为基础架构提供了一个基于事务性的安全服务的集成点。由于分布式ESB 是一个像网格一样的使能技术,所以基于 OGSI 源代码组织定义的 Web 服务接口是一个很自然的选择。OGSI 当前是外化网格技术的事实标准,它允许在一个环境下所书写的网格服务可以很容易地部署在其他环境中。

      此外,ESB可以提供一个基于优化Tete算法的可扩展规则引擎。外化业务规则使得在较低层对迅速变化的业务流程、决策机制进行管理以及使消息过滤和路由选择变得可能,而不需要对基础应用程序进行代码级的改变。它将业务从对缓慢的代码开发周期的依赖中解放出来,允许精通业务的分析师进行必要的变化以支持新产品或法规需求的引进,而无需中断系统的运行。

      “在过去的10年中,竞争压力和日新月异的技术根本性地改变了企业运营节奏”

      管理支持

      实时企业要求服务在宏观和微观两个层面上管理和协调应用程序及其服务。第4层提供了实现安全策略、定义资源使用指南和集成操作流程所需的管理支持。基本功能包括:

      监视:整理事件和统计数据以了解应用程序的性能、资源使用情况和操作行为。它允许对整个基础架构进行模拟、错误判定以及对资源利用进行手动和自动平衡。

      反应协调:需要通过启发分析、动态规则和灵活的工作流对应用程序进行智能管理、控制、自我修复以及微调。通过使用有效的动态拓扑布局(在正确的位置运行正确数量的应用程序)、实时企业管理利用负载,并选择正确的硬件和位置来运行应用程序。

      ESB管理结构将分布式JMX与统计事件收集和对比与用在应用级的基于相同标准的 Java 规范框架进行了结合。这为资源使用、性能监视和警告通知提供了位置透明性、发现、远程控制和统计数据的整理。这些技术允许对在整个实时企业中的智能性资源可视化、协同合作和供应环境进行预言性的决策,从而为 IT 经理和业务经理赋予了洞察力。

      结束语

      使用一个分布式企业服务总线,企业可以通过利用标准以提供灵活实时的“按需服务”基础架构来最大化利用其在硬件和软件的现有投资。该灵活的基础架构包括:

      提供可主动调整 IT 资源的技术,使业务领导可以转变核心信息服务以满足不断变化的市场

      创建一个基于开放标准的统一 IT 基础,它可灵活变化以满足未来的需求。

      降低 IT 基础架构的成本,同时保持高水平的性能。

      这些目标是通过企业消息传递、实时缓冲以及分布式主动管理技术的大量结合而实现的。结果就是一个具有更低总体成本和具有更高应对业务变化能力的IT基础。通过依赖于标准,实时基础架构将不同的技术结合到一个连续的结构中,这个结构提供了快速调整软件和硬件基础架构以满足企业实时业务需求的方法。


    七、ESB的几种模式

          John Reynolds 提出了ESB的几种模式,在选择ESB进行企业应用开发的时候,先要确定自己的业务模型适合于哪一种ESB模式,详见:

    http://weblogs.java.net/blog/johnreynolds/archive/2006/01/soapesb_level_s_1.html

     

          对于Web Service,只有理解了异步服务调用才能真正理解WS的好处。异步调用就是用户发出一次请求,然后过一会回头检查这个请求是否返回了。使用异步调用,用户不需要发出请求后立即等待请求返回,这样就增强了用户体验性。其实现在很多服务,例如邮件服务,消息服务,在线支付都是异步调用的服务。

    八、企业服务总线(ESB)的应用前景

          企业级应用系统一直是中国软件产业发展的主要方向之一,占有至关重要的地位。同时,它也受到整个世界IT发展潮流的影响,当前IT软件领域的主要技术趋势是SOA和ESB,原因是信息技术的不断发展和成熟使各个企业有机会在更大的范围内整合自己的资源,提高经营运行效率。

          二十一世纪信息共享与整合对企业的变革发展日趋重要,而企业对网络环境的依赖及应用创新的追求,将是我们面临的主要挑战。

    展开全文
  • ESB企业服务总线

    千次阅读 2016-02-20 22:02:24
    ESB是企业服务总线(Enterprise Service Bus)的缩写,是中间件技术与Web Service等技术结合的产物,也是SOA系统中的核心基础设施。ESB就是一个服务的中介,形成服务使用者->ESB服务Proxy->服务提供者的生物链,中介...
  • 本文作为ESB系列文章的第一篇,介绍了面向服务的体系结构(service-oriented architecture,SOA)和企业服务总线(Enterprise Service Bus,ESB)的基本知识,ESB的技术沿革,以及ESB与SOA之间的关系。
  • 分析Oracle Service Bus(Oracle服务总线)提供的ESB(Enterprise Service Bus,企业服务总线)和运行服务管理功能,这些功能拥有企业级的可靠性和扩展性,可用来集成和管理企业内部和企业之间的服务交互。
  • ESB-企业服务总线

    万次阅读 2017-05-18 13:53:08
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构,可以...
  • ESB 企业服务总线基本内容概述

    千次阅读 热门讨论 2016-10-09 15:26:18
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。整个架构体系里面分为三个组件或子系统,...
  • 几种ESB(企业服务总线)介绍

    万次阅读 2018-07-16 19:24:45
    ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有...
  • ESB即企业服务总线

    千次阅读 2018-08-13 10:10:06
    ESB全称为Enterprise Service Bus,即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。  ESB的出现改变了传统的软件架构,可以...
  • 系统采用最新的SOA架构思想、B/S结构模式,依托企业服务总线实现各业务系统数据交换及共享。数据交换与管理模块采用Web Service接口方式实现业务数据的同步,为建设权威、一致的船舶及港航企业主数据库提供数据基础。...
  • 通过企业服务总线连接SOA服务

    千次阅读 2008-08-26 13:43:00
    由于众多原因,企业服务总线 (ESB) 是任何企业级 SOA 必不可少的一部分。随着实施面向服务结构体系 (SOA) 这一观念的日渐普及,企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式,则很难有效地...
  • 运行端到端测试结束语下载参考资料第1部分介绍了IBM:registered:WebSphere:registered:EnterpriseServiceBus(ESB)提供的用于构建ESB的关键功能,其中使用了一个贯穿本系列的示例业务上下文,还阐述了...
  • 企业服务总线Enterprise service bus介绍

    千次阅读 2013-06-28 10:27:35
    企业服务总线(Enterprise service bus). 以往企业已经实现了很多服务, 构成了面向服务的架构,也就是我们常说的SOA. 服务的参与双方都必须建立1对1 的联系,让我们回顾一下SOA架构有哪些基本的要求: SOA在相对较粗...
  • 引言场景设计服务提供程序中介模块完成解决方案结束语下载参考资料在本系列文章的前两篇文章中,我们讨论了WebSphereESB的关键功能,并介绍了JMS之间的消息交换,现在,我们通过在混合体中添加Web服务场景,进一步...
  • ESB是Enterprise Service Bus的简称,中文翻译为企业服务总线企业服务总线是一个实现系统间集成和互联互通的重要技术架构,可以理解为是一种消息和服务集成的中间件平台。 这个技术是为了解决什么问题呢? 系统...
  • 企业服务总线项目集成标准

    千次阅读 2016-11-25 21:33:47
    企业服务总线(Enterprise Service Bus,缩写 ESB),是SOA面向服务架构的骨干,在完成服务的接入、服务间的通信和交互基础上,提供安全性、可靠性、 高性能的服务能力保障。采用 SOA 架构,基于ESB总线进行企业异构...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 33,363
精华内容 13,345
关键字:

企业服务总线功能