搜索
ESB企业服务总线解决方案科技股份有限公司目录页ESB架构简介ESB架构体系12ESB实施方法论成功案例34第一章ESB架构简介过度页什么是ESB与传统架构的区别ESB架构简介第一节什么是ESB正文·第一章ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB全称为EnterpriseServiceBus，即企业服务总线。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。ESB架构简介第二节与传统架构的区别正文·第一章为什么选择ESB呢？ESB不涉及底层编程接口服务之间通过简单、精确定义的接口进行通讯松散耦合服务架构ESB架构简介第二节正文·第一章传统的点对点调用方式（Point-to-Point）与传统架构的区别ESB架构简介第二节正文·第一章应用OSB企业服务总线应用应用服务安全市场物流研发金融销售人力资源ESB接入后的调用方式与传统架构的区别ESB架构简介第二节正文·第一章应用之间点对点的连接实现简单、基本的信息交互和数据传递传统架构基于消息传递的模式通过企业服务总线实现服务的整合集中和流程实现借助标准的接口灵活地连接，实现真正的随需应变ESB构架面向服务体系架构与传统架构的区别第二章ESB架构体系过度页企业服务总线角色职能企业服务总线整体结构全方位支持能力ESB架构体系第一节企业服务总线角色职能正文·第二章ESB在请求方与服务之间发挥的作用：形状=传输协议颜色=数据格式企业服务总线（ESB）是用于集成应用和服务的灵活的连接基础设施。第一节正文·第二章ESB架构体系安全性消息处理可见性组合服务传输层传输SDK门户WS客户端BPELJava服务服务服务服务转换发现/验证消息流建模服务调出测试浏览器传输安全性WS-Security控制台安全性策略报表SLA监视信息板开放式界面企业服务总线适应性服务消息处理嵌入式服务管理适应性转换丰富的组合环境同类最佳的分布式运行时企业服务总线角色职能第二节正文·第二章ESB架构体系企业服务总线整体架构第二节正文·第二章ESB架构体系企业服务总线整体架构•路由•寻址•通信技术、协议和标准（例如JMS、HTTP和HTTPS）•发布/订阅•响应/请求•同步和异步消息传递•消息和数据转换•提供位置透明性的服务路由和定位服务•多种消息传递形式•支持广泛使用的传输协议•身份验证•授权•不可抵赖性•机密性•安全标准•服务接口定义（例如，Web服务描述语言（WebServicesDescriptionLanguage，WSDL））•支持替代服务实现•服务目录和发现•数据库•服务聚合•遗留系统和应用程序适配器•EAI中间件的连接性•服务映射•协议转换•应用程序服务器环境（如J2EE和.NET）•服务调用的语言接口（如Java/C/C++/C#）•性能•吞吐量•可用性常用功能通信消息处理安全性服务交互服务级别集成第三节全方位支持能力正文·第二章提供应用到应用的连接可能很复杂HPSunpSerieszSeriesInteliSeries移动设备发布/订阅异步消息传递同步RPCRPGWebServicesJMSFTPHTTPWebSphereMQTCP/IPSMTPMulticast系统平台编程模型编程语言传输协议标准和消息格式错误恢复与事务完整性XMLCOBOLCopybookEDI-X.12ACORDEDI-FACTebXMLAL3HIPAAHL77SWIFTFIXCustomFormatsWord/Excel/PDFESB架构体系第三章ESB实施方法论过度页ESB项目特征ESB项目实施过程ESB实施方法论第一节ESB项目特征正文·第三章一需要连接多个系统需要与银行、IT。多个业务部门以及第三方沟通写作涉及人员多二多个系统需要分阶段实施完成，以降低风险，一般实施周期在两年左右实施周期长三连接的每个系统都要执行一个完整的过程，系统较多时，上线频度较大上线频度大四人员的业务能力要求高，需要熟悉多种业务，才能完成接口分析、标准制定工作系统稳定性和性能至关重要，对人员的技术能力要求非常高项目经理要有极强的协调、推动能力人员综合素质要求高ESB实施方法论第二节正文·第三章ESB项目实施过程计划阶段1采用统一规划，迭代式开发，分步实施的策略；仔细制定各系统边界，以防需求蔓延；合理选择第一批上线系统，保证进度，增强客户信心；合理规划现场、基地工作，降低项目成本；易导致ESB项目失败的主要因素：–系统定位不清–对项目支持力度不足–项目进展急进12345ESB实施方法论第二节正文·第三章ESB项目实施过程需求分析2需求分析阶段特点偏重于与其他系统的集成架构分析侧重于接口的分析和MBSD的服务定义，最终形成银行的服务规范需求分析在整个项目中迭代多次，持续时间长注意事项：把对ESB产品功能的需求在第一批上线系统的需求分析阶段就分析完成，并充分考虑未来其他系统接入时的报文、协议格式等ESB实施方法论第二节正文·第三章ESB项目实施过程需求分析2对各系统提供的接口文档进行业务分析,分析了解各种交易完整的业务含义,审核接口文档中的错误疑点整理分析接口文档对相近或相似的服务进行统一,并与服务总线上的服务进行匹配,考虑评估是否建立新的服务或场景服务归纳分析按照接口文档交易的输入输出字段与原有服务的字段进行对比分析,合并或新建服务,同时对字段进行标准化.服务规范文档整理ESB实施方法论第二节正文·第三章ESB项目实施过程开发阶段3集成架构•ESB的功能决定了ESB项目的特征，面临多个系统的接入，合理的集成架构对项目将起到决定性的作用。•关键指标：总交易吞吐量；交易响应时间等接入系统的接口数量、通讯方式、报文格式•接入系统的接口数量直接决定了开发工作量的大小•ESB产品是否支持接入系统使用的通讯方式、报文格式，决定了是否需要开发新的适配器客户要求的功能是否产品已支持影响开发阶段的关键因素ESB实施方法论第二节正文·第三章ESB项目实施过程开发阶段3开发阶段-工作量分布前期重点在于产品的监控、流水、日志、冲正等功能开发后期重点在于接入系统的新渠道开发及交易配置和联通性前期开发工作量大；后期开发工作量小，但交易配置、联调工作量大建议：应在第一批系统上线时就完成80%以上的开发工作，并把该部分工作在基地完成ESB实施方法论第二节正文·第三章ESB项目实施过程开发阶段3开发阶段-开发内容新的适配器开发•包含对新的通讯协议和报文类型的支持监控内容的配置•各行对监控的要求不同，需要根据要求配置总线的数据采集和BAM的展示（包含生成监控报告）客户要求的功能是否产品已支持•对每个接口都需要配置报文，测试交易的联通性功能差异的开发或修改•对内置服务，比如流水和冲正，客户可能会有不同的需求；也会有部分功能产品未提供，需要项目组现场开发ESB实施方法论第二节正文·第三章ESB项目实施过程开发阶段3开发阶段-开发模型1第一批次中，设计及编码可在基地完成，同时现场执行接口分析；此过程要求现场与基地建立顺畅、及时地沟通渠道2第一批次中，尽可能收集银行后期接入系统使用的通讯协议和报文格式；并把客户的功能需求尽可能收集完整3第一批系统上线后，基地开发人员可减少甚至撤出，后期的项目工作将主要是确定接口，测试交易联通性。因此，此后工作建议现场项目组全部完成ESB实施方法论第二节正文·第三章ESB项目实施过程测试及上线4•明确测试范围，哪些是产品组执行（保证），哪些是项目组执行•性能、稳定性测试是重中之重•功能测试偏重于交易联通性测试•测试主要工作是组报文、发送报文并接收响应第四章成功案例过度页PICC渠道平台跨省平台成功案例第一节PICC渠道平台正文·第四章项目背景PICC信息系统包含了几十个子系统，这些系统之间存在着错综复杂的接口调用关系。现存子系统间存在着近百个接口，接口方式也是多种多样，包括数据库直连、数据库同义词、WebService、Socket连接等，同时，子系统之间进行交互用到的数据结构也不统一，往往在调用多个接口时需要进行不同的数据封装及数据转换。技术架构OSB（OracleServiceBus）是策略驱动的中介层，它处理消息，根据要求路由和转换消息，OSB提供了多协议、多传输方式、动态报文转换、服务路由等组件能够满足各系统对接要求，它通过JMS或HTTP等的传输协议接收消息，并用相同协议或另一指定的传输协议发送消息。成功案例第一节PICC渠道平台正文·第四章中科软科技股份有限公司JMS、ODI、Webservice、BAMAdapterBusinesActivityMonitoring服务提供系统用户浏览器展示渠道系统服务接入权限验证消息转换服务路由服务日志错误处理OracleServiceBus服务注册服务审批服务通知接口管理平台权限认证接口库渠道管理平台系统架构图成功案例第一节PICC渠道平台正文·第四章总体架构渠道平台根据OSB（OracleServiceBus）技术功能，将平台划分7个模块，包括：报文加密、权限校验、消息转换、服务路由、服务日志、错误处理、缓存机制模块。OracleServiceBus的轻量级、无状态、高性能架构扮演“中间人”角色。支持智能消息代理，监控和管理服务；它在企业基础架构中添加一个可扩展的动态路由和转换层，并管理服务生命期：配置和供应服务、监控服务的运行。OracleServiceBus以“配置”为中心，由策略驱动，实现了“服务使用者”和“服务提供者”之间的松耦合配合。PICC渠道平台支持相应的WebService类型的服务调用功能，服务平台本身使用javaEE、XML、WebService等技术。渠道平台对外支持XML、XMLSchema、WebService、WSDL、SOAP、HTTP/HTTPS、JMS等标准的技术。成功案例第二节跨省平台正文·第四章项目背景2010年2月4日，中国保险行业协会（以下称中保协）与全国各财险公司总公司共同召开了行业车险信息平台项目专题会议，会议决议建立行业车险信息共享平台。“平台”建立有助于规范全行业行为，为全行业数据积累提供基础，是提高中国保险业精细化经营管理水平、规范市场、服务大众的重要举措。技术架构跨省平台的开发具有很大的难度，根据跨省平台开发的目的，需要构架一个统一的业务平台和业务规范、持和满足保险公司代位求偿相关的业务需求、实现投承保全行业全国数据联网。经过对比各个公司的产品优劣势，充分考虑跨省平台的需求，我们选择了WMB（WebSphereMessageBroker）作为我们的开发产品，为跨省平台提供更加稳定、更加高效、更加健壮的技术服务。成功案例第二节跨省平台正文·第四章系统架构图成功案例第二节跨省平台正文·第四章总体架构企业服务总线WMB（WebSphereMessageBroker）为各省提供安全控制、系统监控、异常处理、格式校验、发布订阅、动态路由、系统管理、日志记录、格式转化、服务查找、服务注册等功能。企业服务总线ESB是实现系统应用整合的关键部件，作为保险协会IT应用整合架构的核心基础平台，其设计需遵循如下原则：可靠性和高可用性健壮性和稳定性高性能易于扩展原则易于监控和管理工作顺利心想事成万事如意