市场主流ESB的产品比较较全精修订
- 格式:docx
- 大小:201.65 KB
- 文档页数:11
ESB典型功能1.基于服务的支持1) 适配器技术总线产品基于适配器框架技术,实现了统一的客户化应用服务接口,支持大多数主流的数据库、消息中间件产品和通信协议,并提供扩展开发以便支持非标准的信息连接要求。
实现对各种数据源、信息源以及各种应用系统的无缝衔接。
●应用适配器:Email 、MQ 、Tuxedo 、SAP 、Oracle Database 、DB2 、MS SQLServer等。
●协议适配器:JDBC、HTTP、Socket、LDAP、EJB、XML、JMS、FTP、Web Service、RMI、Telnet、CORBA等。
●主机适配器:CICS、IMS(SNA)等。
2) 服务封装总线可实现对不同技术、语言、应用提供的功能接口进行标准服务化封装。
并提供图形化、模版化开发工具,指导用户快速、准确的进行服务开发,从而最大化减少了人为因素,减轻了开发人员的负担。
多种辅助开发工具(如生成、打包、部署等功能),实现了帮助用户快速地进行业务服务建模。
仿真的通用适配器与消息代理环境,实现了用户在开发过程中进行便捷的集成测试。
3) 多通道服务接入总线提供多种基于标准协议的接入方式,包括SOAP/HTTP、JMS/MQ、Socket 等,保持技术的中立性。
无论业务应用使用何种编程语言与开发平台,都可通过标准协议方式实现总线服务的接入与访问。
1同一服务可同时对外暴露多种协议接入方式,便于不同的服务使用者进行灵活选择。
4) 服务组合总线产品可以实现多个服务的组合,组合成新功能的服务,来满足业务需求的新增和变更。
服务组合的构建是一项时间和资源的投资,它必将在面向服务的业务应用程序方面带来巨大的回报。
对这些面向服务的应用程序可以加以修改以满足企业不断变化的业务需求。
5) 协议转换总线产品支持多种协议格式,可实现不同协议间的自由转换,满足不同业务应用的需要。
上图展现了总线在服务提供者与服务使用者质检的协议转换过程与方式,产品支持多渠道通讯方式,即同一服务可同时对外暴露多种协议接入方式,便于不同的服务使用者进行灵活选择。
国内市场主流专业的工作流(bpm)软件分析、比较及推荐目前国内外的工作流系统层出不穷,行业标准多种多样,虽然工作流主要功能国内比较知名的工作流软件基本上都具备,但功能的侧重点各不相同,增加了企业对工作流或BPM选型难度,本人选用目前国内市场主流专业的工作流软件,从概念、工作流引擎、工作流过程建模工具、流程操作、工作流客户端架构、流程监控、表单设计器以及与应用程序的集成等方面进行分析和比较,帮助企业对工作流或BPM产品的选型。
一、概述:工作流的思想最先起源于西方国家,一开始的目的主要是为了简化工作流程,为繁琐的工作提供依据。
随着需求的不断延伸以及人们对企业信息化思想的不断普及,工作流越来越受到企业内部的使用推广,当然,工作流能满足的需求也在不断的优化。
工作流概念起源于生产组织和办公自动化领域,是针对日常工作中具有固定程序活动而提出的一个概念,目的是通过将工作分解成定义良好的任务或角色,按照一定的规则和过程来执行这些任务并对其进行监控,达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。
尽管工作流已经取得了相当的成就,但对工作流的定义还没有能够统一和明确,不同学者从不同角度对工作流做出了不同的定义。
Georgakopoulos给出的工作流定义是:工作流是将一组任务组织起来以完成某个经营过程:定义了任务的触发顺序和触发条件,每个任务可以由一个或多个软件系统完成,也可以由一个或一组人完成,还可以由一个或多个人与软件系统协作完成。
IBM Almaden Research Center将工作流定义为:工作流是经营过程的一种计算机化的表示模式,定义了完成整个过程需要的所有参数;这些参数包括对过程中每一个步骤的定义、步骤的执行顺序和条件、步骤由谁负责以及每个活动所需要的应用程序等。
1993年工作流管理联盟(Workflow Management Coalition,WfMC)作为工作流管理的标准化组织而成立,标志着工作流技术逐步走向成熟。
Primeton ESB v6.3.0.0版本发布说明欢迎使用 Primeton ESB v6.3.0.0 产品并提出宝贵意见,您可参见联系方式与我们联系。
1. ESB v6.3.0简介Primeton ESB是普元基于多年对大型企业的IT建设及分布式计算和应用集成能力的认识和技术积累而推出的服务整合产品,是部署和实现 SOA 的理想工具,支持协议转换、消息转换、消息路由、服务编排、服务注册、服务查找、服务监控等功能。
ESB v6.3.0产品主要包括 ESB Server、ESB Studio、ESB Console、ESB SSM、ESB SAM五个部分。
1.1. ESB Server(ESB 运行环境)ESB Server是整个业务逻辑运行的核心。
不依赖于J2EE容器,提供了多协议的支持, 为服务运行提供了高性能、高健壮、高可靠的运行环境以及方便的扩展机制,为 Primeton ESB 融入企业 IT环境提供了有效支撑及管控手段。
1.2. ESB Studio (ESB 开发环境)ESB Studio是集设计、开发、调试、部署、发布于一体的集成开发环境,提供对ESB Module (ESB 业务逻辑运行组件)全生命周期的管理。
在 ESB Studio 中,以工程的形式组织了 ESB 开发的资源,提供相应的向导、视图和编辑器等工具供开发人员在开发过程中可视化地开发各种业务逻辑, 并提供了强大的调试及团队开发功能。
1.3. ESB Console(服务治理环境)ESB Console主要提供:运行Module 管理、运行参数配置、以及监控 ESB 的运行情况等功能。
通过Console系统,开发人员及运行管理人员对建立在ESB之上的系统进行诊断。
用户只需通过 Web 界面即可管理系统的各项运行参数,用更少的维护成本确保系统正常发挥作用。
1.4. ESB SSM(服务状态监控)ESB SSM(Service State Monitor)提供了对 ESB Server运行时数据的存储、分析等功能。
Enterprise Service Bus (ESB Product Evaluation ComparisonsPrepared by Robert WoolleyOctober 18, 2006U TAH D EPARTMENT OF T ECHNOLOGY S ERVICES Office of the Chief Technology Officer1 State Office Building, 6th FloorSalt Lake City, Utah 84114October 18, 2006Copyright © 2006 State of UtahAll Rights ReserveC ONTENTSExecutive Summary (5Introduction (6Problem (9Premise (9ESB Characteristics (10Key ESB Bene fits (11SOA/ESB Governance (13Reality (14Alternative Solutions (15Evaluation Scope and Architectural Premise (17Product Comparison Information (20Vendor Profiles (22Architecture Premise Alignment (25Department of Technol ogy Services ESB Comparisons (27 Financial Analysis and Cost Recovery (32Conclusions (34Appendix 1: Scenario/Use Case Based Product Comparisons (35 Criteria and Capabilities (36Integration Scenario Evaluation (37Design, Development, and Deployme nt Evaluation (40 Management and Monitoring Evaluation (41Architecture Evaluation (43Product Viability (46Company Viability (48Definitions (50References (56Enterprise Service Bus: Product Evaluation ComparisonsE NTERPRISE S ERVICE B US :P RODUCT E VALUATION C OMPARISONSE XECUTIVE S UMMARYPrepared by Robert WoolleyOctober 18, 2006企业服务总线(ESB 是一种有效的基础组件服务导向架构(SOA 。
ESB企业服务总线概述一、ESB概述企业服务总线,即ESB全称为Enterprise Service Bus,指的是传统中间件技术与XML、Web服务等技术结合的产物。
ESB 提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。
面向服务的体系结构已经逐渐成为IT集成的主流技术。
面向服务的体系结构(service-oriented architecture,SOA)是一种软件系统设计方法,通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。
二、ESB技术详解ESB提供了一种开放的、基于标准的消息机制,通过简单的标准适配器和接口,来完成粗粒度应用(服务)和其他组件之间的互操作,能够满足大型异构企业环境的集成需求。
它可以在不改变现有基础结构的情况下让几代技术实现互操作。
通过使用ESB,可以在几乎不更改代码的情况下,以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口,并能够在部署环境中支持任何标准。
更重要的是,充当“缓冲器”的ESB(负责在诸多服务之间转换业务逻辑和数据格式)与服务逻辑相分离,从而使得不同的应用程序可以同时使用同一服务,用不着在应用程序或者数据发生变化时,改动服务代码。
图、ESB技术实现方案基本功能:服务的MetaData管理:在总线范畴内对服务的注册命名及寻址进行管理。
传输服务:确保通过企业总线互连的业务流程间的消息的正确交付,还包括基于内容的路由功能。
中介:提供位置透明的路由和定位服务;提供多种消息传递形式;支持广泛使用的传输协议。
多服务集成方式:如JCA,Web服务,Messaging ,Adaptor 等.服务和事件管理支持:调用服务的记录、测量和监控数据;提供事件检测、触发和分布功能;扩展功能:面向服务的元数据管理:他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求,以及服务的提供者和他所提供的服务的描述;Mediation :它必须具有某种机制能够完成中介的作用,如协议转换;通信:服务发布、订阅,响应请求,同步异步消息,路由和寻址等;集成:遗留系统适配器,服务编排和映射,协议转换,数据变换,企业应用集成中间件的连续等。
/developerworks/cn/websph ere/zones/esb/faq/常见问题及解答IBM ESB 产品之间的比较及应用场景: 第 1 部分,IBM ESB 产品之间的比较企业服务总线ESB 的介绍企业应用的发展概述在介绍企业服务总线之前,有必要花一些笔墨来介绍企业应用架构的发展和变迁。
企业级应用架构的发展经历了以下几个阶段:独立应用系统EAI 阶段SOA 阶段独立应用阶段20 世纪60 到70 年代,企业应用处于独立应用系统阶段,当时的企业应用是一种用来替代重复性劳动的简单设计,其目的是用计算机代替孤立的,体力性质的工作环节,将相关联的企业信息或数据管理起来。
这些系统大部分是独立的系统——有独立的数据库、应用服务器、用户界面。
因此有时候这类应用也叫“竖井型”的应用。
但是,随着业务和信息的不断扩展,独立应用系统渐渐不能满足企业对IT 的需求,表现在大量的信息冗余,因为在建立一个新的应用的时候需要重新建立一套数据库;功能的重新设计,相似的功能存在于多个系统中;例如,客户信息在一个公司中可能有多个拷贝分别存在于多个数据库中,不同时期建立的应用系统所使用的技术也会不同。
对于获取客户资料这样的功能,必然存在于多个系统中,而且在不同的系统中其实现方式可能是Java/J2EE、Delphi、C/C++。
EAI 阶段20 世纪80 到90 年代,一些公司或集成商意识到应用集成的价值和必要性。
EAI 是一种将多个不同平台、用不同方案建立的异构的应用集成的一种技术和方法。
它的目标包括以下几个方面:各个分离的系统间的相互通讯,消除信息孤岛,实现信息的共享。
从功能的角度来看,EAI 包括信息接收、转换、翻译、路由、传播和业务流程管理。
从架构上看有两种方式:Hub/Spoke 方式和Bus 方式。
图 1 所示的Hub/Spoke 结构使用一个中心代理(Hub)和多个适配器(Spoke)将Hub 和应用连接起来。
流开源ESB产品来源:网络在开源ESB家族中涌现出很多优秀的开源ESB,比如,Mule,Apache ServiceMix,Open [url][/url]ESB,Apache Synapse等。
为了大家更好地了解它们,我作了简要地介绍。
Mule它是一个轻量级的消息框架和整合平台,基于EIP(Enterprise Integeration Patterns,由Hohpe 和Woolf编写的一本书)而实现的。
Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑。
UMO可以是POJO,JavaBean等等。
它支持20多种传输协议(file,FTP,UDP,SMTP,POP,HTTP,SOAP,JMS等),并整合了许多流行的开源项目,比如Spring,ActiveMQ,CXF,Axis,Drools等。
虽然Mule没有基于JBI来构建其架构,但是它为JBI容器提供了JBI适配器,应此可以很好地与JBI容器整合在一起。
而Mule更关注其灵活性,高效性以及易开发性。
从2005年发表1.0版本以来,Mule吸引了越来越多的关注者,成为开源ESB中的一支独秀。
目前许多公司都使用了Mule,比如Walmart,HP,Sony,Deutsche Bank 以及CitiBank等公司。
官方网站:/Apache ServiceMix它是JBI规范的一种实现。
它包涵了许多JBI组件,这些组件支持多种协议,比如JMS,HTTP,FTP,FILE等。
同时也实现了EIP,规则和调度。
自从JBI被JCP接收后,2005年末Apache ServiceMix才被Apache作为其卵化项目,到2007年9月,它已经成为Apache 的顶级项目。
ApacheServiceMix 也整合了其他的开源项目,比如Apache ActiveMQ,Apache CXF,Apahe Camel,Apache ODE以及Apache Geronimo。
市场主流E S B的产品比较较全SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#综述介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点:ESB产品一览表包括商业和开源:类型产品公司商业OracleServiceBus(OSB)Oracle OracleEnterpriseServiceBus(ESB)WebSphereEnterpriseServiceBusIBM WebSphereMessageBrokerWebSphereDataPowerSonicESB ProgressActiveMatrixServiceBus TIBCO开源Mule MuleSoft ServiceMix/FUSEESB Progress Synapse/WSO2ESB WSO2甲骨文的OSBOracleServiceBus(OSB)的架构图:主要逻辑层:底层消息服务总线的安全,消息Broker,服务管理。
优点:易用性开发工具从WebConsole迁移到Eclipse,支持图形化拖拽和便于调试在studio上直接集成测试功能,比如studio能提供直接发送和接收SOAP,JMS消息的功能,无需借助第三方工具,如SoapUI和编写JMS客户端代码。
性能提升嵌入OracleCoherence(企业级的内存数据网格)产品,在特定场景下为服务调用提供缓存,性能提升80%。
Cache机制为静态响应信息提升性能。
静态响应信息是指在一段时间内不会发生变化的信息,如天气预报,手机套餐,人民币汇率等,这些数据变化的周期通常是1天,1月。
实现手段:采用比较成熟的开源Memcached或者轻量级的JCACHE管控能力增强采用自动化的生命周期服务治理,从服务设计、开发、部署和运行期的整个服务生命周期内和EnterpriseRepository产品进行自动同步,无需人工干预。
缺点:依赖于Weblogic重量级的统一消息格式:通过反编译OSB的源码,可以看出OSB将各种协议(HTTP,WS,JMS…)接入的消息统一转换为SOAPMessage,再通过XqueryEngine对SOAPMessage进行XML操作。
以下场景其缺点可立即显现:1.HTTP下的大数据包2.JMSObject类型的大数据包(最新版本OSB才支持JMSObject类型,之前只支持JMSText类型依据:对大数据包进行XML操作比较耗CPU将大的Object转换为XML是个繁重的操作IBM的WMBWebSphereMessageBroker(WMB)的优点和趋势:简化开发/部署架构去掉configurationmanager,开发工具/应用可以直接和broker交互。
易管理为管理员提供专用的管理工具--WebSphereMessageBrokerExplorer,可以管理本地和远程的broker和queuemanager,同时提供了监控broker性能和消息流的功能。
简化开发流程将常用的消息流场景进行了模板化,推出了基于模式的开发方式,用户只需要配置相关参数即可。
提供的模式分为两类:内置(built-in)和自定义(user-defined)。
WMB7.0架构:WMB开发/部署架构的变迁:去掉configurationmanager,开发工具/应用可以直接和broker交互。
Broker的配置信息保存在File中,可以不依赖于DB。
统一安全机制,queuemanagersandbrokers均采用MQqueue的授权机制。
V6中采用的安全机制是由ConfigurationManager提供的AccessControlLists(ACLs)来管理授权的。
统一publish/subscribe机制,MessageBrokerV7直接采用WebSphereMQV7的publish/subscribe机制,因此去掉了以前版本中使用publish/subscribe时所需的UserNameServer。
WMB提供了基于模式的开发,将常用的场景模式化,比如服务穿透场景。
不使用基于模式开发一个服务穿透的场景所需步骤:1.创建并配置业务服务2.创建并配置代理服务3.在代理服务中关联业务服务如果采用模式开发,其步骤:1.创建服务穿透模式并配置业务服务和代理服务优点:开发方式模式化简化开发方式,减低了使用门槛,减少了使用中出现的概率。
开发方式的转变由自底向上转变为自上而下。
自底向上根据使用场景,逐个一步一步地开发组件,最后进行组装。
自上而下根据使用场景选择特定的模式,用户只需要配置参数(比如队列名称,WSDL地址等)即可。
缺点:重量级的架构传统的EAI架构,必须依赖于WMQ。
笨重的ESQLESQL是WMB用于处理消息流的一套特有的扩展SQL的语言,功能很丰富,语法比较多,但学习门槛较高。
相比直接通过java方法操作消息,显得格外笨重。
开源Mule优点:社区活跃度在开源ESB中,活跃程度最高,用户量大,不断推出新版本。
易用性“让一切变得更简单”是Mule的宗旨。
2次重构核心架构、推出接入云应用,消息流,基于模式的配置以及热部署;MuleIDE3.0,将支持图元拖拽,简化开发。
扩展性增加一个新协议非常简单,只需实现5个接口类即可。
异常处理框架异常策略设置级别:model和service异常处理方式:1.将异常路由到指定的目的地2.根据异常类型过滤异常,并路由到指定目的地3.设置重试次数4.当采用了事务时,可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。
管理性推出MuleManagementConsole(收费),管理、部署和监控应用。
文档文档非常丰富,降低了使用门槛。
基于模式的配置基于webserviceproxy模式的webservice的穿透场景的配置(配置非常简单,3个属性)<ws:proxyname="muleWsProxy"inboundAddress缺点:集群非常弱1.只能配置一个主实例和一个从实例2.不支持flow和基于模式的配置3.某些路由会丢失或者获得重复的消息MuleIDE目前的IDE只提供XML级别的编辑,还不能实现图元的拖拽稳定性开源项目的通病,需要在测试场景下进行验证ServiceMix优点:无缝集成CXF,ActiveMQ,Camel和ODE因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品JBI的优势组件BC,SE可以在任何JBI容器(比限于ServiceMix)中直接运行,复用性强基于OSGi具备OSGi的优势:模块化,热部署,易扩展基于Karaf提供了非常丰富的命令,管理、部署和监控ServiceMix问题:JBI2.0太复杂且规范发展缓慢IT巨头Oracle,IBM投了反对票,目前只有几家小公司投支持票。
已被主流中间件厂商抛弃,没有受到业界的青睐由于JBI的复杂性所致,其架构并非轻量级缺少IDE的支持必须手写大量的XML配置文件缺少governor的支持ServiceMix4只是借助Flex的webconsole管理OSGi的bundle 学习门槛高用户文档和相关资料比较少ServiceMix迁移到OSGiJBI2.0中增加了对OSGi的支持;ServiceMix4.x完全基于OSGi,ServiceMix3.x继续前行Apache孵化新项目CamelKarafSynapse/WSO2ESBSynapse发展缓慢发展缓慢,新版本中没有增加比较有亮点的功能特性WSO2ESB发展迅速对Synapse增加了企业级特征:1.基于WSO2的Carbon平台(OSGi框架)2.支持集群、负载均衡和failoverrouting3.支持流量控制和数据缓存还增加了外围产品:1.WSO2GovernanceRegistry,服务注册产品2.WSO2ESBmanagementconsole,ESB管理控制台3.WSO2CarbonStudio,开发ESB的studio基于Axis借助于Axis的特性,能非常好的支持ws规范,ws-*。
因此非常适合WebService的场景。
基于WSO2的Carbon平台Carbon是WSO2的基础平台,它是一个OSGi框架,几乎WSO2的都基于它。
支持集群集群中节点间的通信框架基于ApacheTribes(组通信框架)相关信息持久化在内嵌的Derby中支持一个主节点和多个从节点failoverrouting在集群环境中,所有的请求只能被主节点接收,从节点只能作为备份节点。
支持流量控制在单个ESB实例或者集群中,可以在服务级别配置流量控制。
当请求数超过阀值时,ESB将被拒绝访问。
实现机制:借助组件ThrottlingMediator支持数据缓存集群中的各个ESB实例共享缓存的数据。
当一个请求被ESB实例1处理完后返回响应信息,当再次向ESB实例1或者集群中其他的ESB实例发送该请求时,直接从缓存中取出原来的响应信息。
实现机制:借助组件CachingMediatorWSO2GovernanceRegistry开源中最优秀的服务注册项目WSO2ESBmanagementconsole创建和管理各组件(接入层、中介层和接出层);图形化地方式统计系统资源(CPU,内存);图像化统计ESB中各组件(接入层、中介层和接出层)接收发送消息的大小以及响应时间;记录系统日志、SOAP日志;图形化显示消息的流向文档丰富WSO2提供了非常丰富的文档:安装手册开发手册管理员手册部署手册…大量的使用实例缺点:架构不够清晰显得有点臃肿、不简洁、不够优雅扩展性差新增一个协议/transport非常困难组件比较凌乱对多种协议(HTTP,WebService,JMS,FTP,EMAIL)的支持,部分依赖于Axis2,部分依赖于synapse普元ESB国内非常成熟的ESB产品,在电信、金融领域大量应用,性能卓越。
真正意义上实现了服务从开发、部署、执行、监控、优化的全周期管理!可靠的总线架构,可快速部署并支撑业务系统。
业务化的服务注册与管理,并可实时监控接口服务调用情况。
强大的环境融合与协议适配能力。
优点:高性能:根据具体业务,可实现个性化的流量控制、IP拦截、报文校验等特性。
在中国电信OIP集成平台中,支撑了以CRM、BOSS为核心的50多个应用系统。
在上海移动ESB集成平台中,目前日均交易量9000万笔,峰值TPS达到了6000。
高扩展:开放的API接口,使得ESB产品更加容易和企业内部现有的系统有机的融合在一起,譬如:与现有安全系统的融合、与现有IT网管系统的融合业务化:丰富的QoS质量指标,完备的日志信息和方便的进程管理机制,同时还可以依托服务运行的轨迹信息形成跨部门的业务流程的监控。