-
SOA架构和微服务架构有什么区别?
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端webui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。把这个核心搞清楚后,再来看下网上找到的对微服务架构的一些定义和阐述:微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。再强调下即:首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键,即我们在进行单个应用组件设计的时候,本身在组件内部就会有很大接口的设计和定义,那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务,而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTPRestAPI的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了HttpAPI的方式进行服务的发布和管理。从这个角度来说,组件超外部暴露的能力才需要发布为微服务,其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑,组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的集成和部署运维就越复杂。即任何一个组件,当他依赖的外部其它应用组件越多的时候,整个集成,部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量,一是增加出错概率。原来谈组件化开发谈的最多的是单个组件的持续集成,包括配置环境集成,自动打包部署,自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路,希望能够实现开发设计到部署运维的一体化。由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性,我们可以用虚拟机,但是当几十个进程都完全用独立的虚拟机就不现实的,而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情,每个Docker是独立的容器刚好又完全做到进程级别的隔离,资源占用率又最小,这些特点刚好满足微服务架构的开发测试和自动化部署。前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台,按照当前微服务架构的整体思路,虽然单个服务的实现和发布仍然是在组件内部完成的,但是这些组件暴露的服务本身的调用情况,服务本身的安全,日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。由于微服务尽量都是通过HTTPAPI的方式暴露出去的,因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构,即可以做为微服务架构下的服务管控平台。对于这种服务管控平台,核心需要讨论的就是服务每次调用本身的消息传递,输入和输出日志是否需要记录,当前就有两种做法,一种是不记录,管理平台只负责服务注册和目录发布,安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成,这种方式下整个架构下获取更高的性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈;另外一种方式就是完全记录,在这种方式下就需要考虑服务管理平台本身的集群化不是,高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力,同时仅仅对核心的需要Log日志的服务进行日志记录,而其它服务只提供服务目录和访问控制即可。
-
SOA和微服务架构有什么区别?
微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端webui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。把这个核心搞清楚后,再来看下网上找到的对微服务架构的一些定义和阐述:微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。再强调下即:首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键,即我们在进行单个应用组件设计的时候,本身在组件内部就会有很大接口的设计和定义,那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务,而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTPRestAPI的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了HttpAPI的方式进行服务的发布和管理。从这个角度来说,组件超外部暴露的能力才需要发布为微服务,其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑,组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的集成和部署运维就越复杂。即任何一个组件,当他依赖的外部其它应用组件越多的时候,整个集成,部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量,一是增加出错概率。原来谈组件化开发谈的最多的是单个组件的持续集成,包括配置环境集成,自动打包部署,自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路,希望能够实现开发设计到部署运维的一体化。由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性,我们可以用虚拟机,但是当几十个进程都完全用独立的虚拟机就不现实的,而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情,每个Docker是独立的容器刚好又完全做到进程级别的隔离,资源占用率又最小,这些特点刚好满足微服务架构的开发测试和自动化部署。前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台,按照当前微服务架构的整体思路,虽然单个服务的实现和发布仍然是在组件内部完成的,但是这些组件暴露的服务本身的调用情况,服务本身的安全,日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。由于微服务尽量都是通过HTTPAPI的方式暴露出去的,因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构,即可以做为微服务架构下的服务管控平台。对于这种服务管控平台,核心需要讨论的就是服务每次调用本身的消息传递,输入和输出日志是否需要记录,当前就有两种做法,一种是不记录,管理平台只负责服务注册和目录发布,安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成,这种方式下整个架构下获取更高的性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈;另外一种方式就是完全记录,在这种方式下就需要考虑服务管理平台本身的集群化不是,高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力,同时仅仅对核心的需要Log日志的服务进行日志记录,而其它服务只提供服务目录和访问控制即可。
-
简单而不失创意的摄影机构VI欣赏
-
CIO学习:SOA应用架构实施要点
CIO学习:SOA应用架构实施要点SOA应用架构实施涉及系统的诸多方面,需要从一开始就对其规划和设计,涵盖基于SOA的软件及系统实施过程、方法和工具、质量、管理、测评等方方面面。SOA应用架构设计可划分如下三个主要阶段:第一阶段,评估和分析业务和IT系统的当前状态。明确对于IT敏捷性、可扩充性、快速响应业务需求变化等方面的需求,评估行业特性和环境,从投入产出、长远战略、风险等方面分析设计SOA应用架构,考虑是否需要采用云计算的平台和服务器资源、如何和自己的IT资源进行整合等。第二阶段,对SOA应用架构进行总体规划和应用实施,确定SOA应用架构的总体框架、实施过程、各方职责以及实施关键点,组织资源进行具体应用实施工作;在此过程中,特别需要用户从多个视角提出业务需求,开展了务分析,并参与完成服务设计。第三阶段,对SOA应用架构的实施效果进行评估,明确是否满足实施前的需求,实施后的IT整体情况和效果,并根据效果调整应用架构的设计。SOA适用性评估SOA在以下一些业务场景中更能发挥作用和优势:企事业单位和政府部门内部IT系统的整合由于业务重组、并购或者内部机制调整,而需要实现组织内的统一管理、协作和信息共享。需要对多个异构的IT系统进行整合,提高组织的整体决策、监控能力或业务流程效率。企事业单位和政府部门之间IT资源的共享和协同为了在业务和市场上合作,需要依赖业务合作伙们提供其IT系统的非核心业务功能或信息。某项服务能力,需要多个组织和单位的IT系统需要共享信息,并联合处理,比如电子政务中的“一站式审批”服务、各级政务资源共享交换平台等从头开始开发新的应用系统SOA将是未来IT新系统构建的主导方法,因此考虑到未来的扩展和重用能力,用户在业务允许的条件范围内,可选择基于SOA来构建新应用系统。基于互联网的一些新的应用模式基于互联网的软件服务化平台和服务,如云计算中的PAASSAAS等模式在信息化建设中,除了自己的IT系统之外,也同时希望集成互联网上的一些软件工具或WEB服务的企事业单位,如采用“软件+服务”策略的单位。但是,也有一些应用场景不适合用SOA来实现,此时采用传统的技术、方法和过程来实施更为妥当,比如下述的一些场景。用户业务涉及敏感和实时性要求较高的系统,如工业控制、杧交易系统事务及安全性要求较高的业务系统。用户的业务系统没有集成的需求当前的IT系统基于统一的平台和编程方法SOA总体框架SOA应用技术参考模型覆盖了SOA应用的构建、运行和管理。SOA应用技术参考模型包括如下9个主要的部分IT基础设施是承载SOA应用的已有运行环境以及未来可配置和扩展的基础环境SOA资源是实现SOA应用所需的应用系统、数据以及现存服务等IT资源,这些资源存在于企业、政府部门以及其他组织机构内,作为SOA应用建设中服务的初始来源。SOA支撑技术与服务是SOA应用的基础技术能力及基础技术服务的总称。业务公共服务是一系列面向行业、领域应用的,可复用的,具有一定业务功能有的服务。行业、领域应用是面向用户的,基于特定行业或特定领域需求的IT系统用户是使用SOA应用的人、系统、设备、及其他服务的总称。质量是SOA应用满足用户需求或期望的程度安全是为了保障SOA应用安全运行的机制和策略总称。治理理针对SOA应用所制定的管控策略和机制,涵盖SOA应用的整个生存周期。
-
阿里架构师的笔记——Oracle、SOA、OSB结构原理
Oracle-SOA-OSB功能分析阿里架构师的笔记——Oracle、SOA、OSB结构原理请点击此处输入图片描述今天介绍下OracleOSB的基础核心概念和核心功能分析,在前面两篇文章里面重点介绍了Oralce官方在线文档中的入门介绍和关键功能Task任务文档说明。今天篇核心原理介绍。对于OSB核心仍然是代理服务,业务服务和中间的业务处理管道三个部分的内容。代理服务(ProxyService)包括了处理请求和可选的响应消息的消息处理逻辑,同时提供给外部消费方可以调用的接口。也就是说代理服务是OSB真正对外保留的接口服务能力。业务服务(BusinessService)实际提供业务处理能力的服务,一个业务系统提供的一个业务处理Service服务就是一个业务服务。而在OSB的业务服务重点则是指将对外部业务服务的引用,外部遗留系统的适配最终映射到OSB上生成一个对应的提供业务能力的服务组件(WrapstheexternalsystemstheOSBcalls)。消息格式和内容转换(MesssageTransformation)消息转换是OSB的一个重要内容,即不同的Inbound/Outbound消息格式之间能够相互进行转换。在OSB12c当前可以提供三种方法进行消息转换,主要包括了:UseXQuery,XSLT,andXPathUsedomainvaluemaps(DVM)Usecrossreferencetables而实际上当前我们使用最多的仍然是XQuery+XSLT进行消息转换。在11g的时候更多的是使用XQuery+XPath代码的方式进行转换和映射,而在12c版本已经增加了XSLT的可视化数据映射能力,这是消息转换这块相对大的一个能力提升。但是采用XSLT的时候会带来一定程度的性能损耗。对于主域值映射和交叉引用表实际在项目中使用的不算多,比如对于DVM还提供了基于Lookup动态映射功能,如果有相关需求场景可以考虑。消息路由和动态路由(RoutingandDynamicRouting)路由是OSB的另外一个重要功能,实际在OSB进行服务封装和设计的时候仍然是在Pipeline中进行设计和完成。路由本身则是通过条件分支判断或者路由表来确定服务请求究竟路由到哪个业务服务上,对于用作路由判断的参数条件可以实际在SOAPHeader中传递过来。其次,动态路由功能也是一个场用的功能,即在设计BusinessServie业务服务的时候,URI端点地址可以通过RoutingOptionsaction进行动态设置和指定。这样就避免了对于ExtenalServie业务服务都需要提前先设计多个BusinessService服务进行映射。在进行服务动态路由的时候,外部多个服务需要遵循相同的WSDL服务契约标准格式。消息增强和丰富(MessageEnrichment)在OSB中的Pipeline管道设计中,对于Action有三种类型:1.RouteAction:路由操作(通过异步操作特性来防止现场阻塞)2.PublishAction:发布操作(发布操作是单向发送。它提供了调用外部服务的方法,但是没有收到响应)3.ServiceCalloutAction(在将请求路由到目标服务之前调用外部服务来丰富请求消息的能力)对于消息的增强和丰富即是通过ServiceCalloutAction操作来完成,即既可以在Proxy代理服务在接收到消息请求后先进行增强在转发和路由到业务服务,也可以是在得到了业务服务的返回后进行消息增强处理后再返回给服务消费方。服务缓冲池(ServicePooling)服务缓冲池更多的是在服务消费方和原始服务提供方之间增加更多的可靠性,可以通过服务池来提供高可用性和服务弹性扩展能力。同时在到目标源服务的网络连接出现短暂中断的时候,通过服务池提供的机制可以设置重试次数和重试时间,自动的发起重试操作。同时可以通过服务缓冲池连接到多个提供通用能力的目标端业务服务,这个时候缓冲池能够提供相应的负载均衡能力,容错能力。当目标节点某个URI节点不能访问的时候可以自动进行故障隔离。同时对于负载均衡算法也支持轮询,随机等多种负载均衡算法选择。服务结果集缓存(ServiceResultCache)对于只读服务调用可以启用服务结果集缓存,在企业结果集缓存的时候注意缓存失效时间的设置,可以使用默认值,也可以使用自己指定的缓存失效时间。OracleServiceBus支持服务缓存,通过完全图形化配置的方式,可轻松调整服务的缓存策略,无需进行代码编写,通过缓存能力,可大幅提升服务的响应效率,并降低数据库的业务查询压力。流量控制(WorkManagerandMessageTrotting)MessageTrotting即OSB服务总线提供的消息节流特性,即在ProxyService和BusinessService之间增加了一个消息缓冲和排队区。我们可以设置最大允许的队列排队数,最大的并发线程数,以及消息的过期时间设置等。消息节流可以很好的起到对目标系统的缓冲作用,即即使出现消费方出现大并发的消息发送调用,我们通过节流和Queue队列仍然可以实现平滑的将服务请求推送的目标业务系统中。这有点类似我们在说传统的消息中间件的时候,当接收到大并发服务请求后的对下游的削峰能力。对于WorkManager流量控制,在百度文库有《OSB-深度使用总结》可以详细参考,可以看到对于MessageTrotting只是对消息的入口进行流控,而对于WorkManager则可以实现消息入和消息出的双向流量控制能力。基本的设置参数仍然是最小,最大的线程并发数,最大的请求排队数等指标。对于资源占比率设置则主要是调整多个服务大并发下的资源优先级分配策略。拆分-合并(Split-Join)使用拆分连接将大消息拆分为许多较小的消息,并并行处理它们,最后再将结果聚合成一个大型的响应消息。即OSB首先将接收到的大消息体按一定的规则拆分为多个子消息,然后再将子消息并行发送大目标系统,对于目标系统返回的多个子结果再进行join合并以返回一个完整的结果给消息发送方。拆分-合并更多的是提升了消息发送和接收相应的性能。遗留系统集成和适配能力对于遗留系统的适配是OSB的一个核心能力,例如对于数据库的适配可以通过JCAAdapter适配器来完成,包括适配到数据库表和具体到对存储过程的适配能力。同时适配器还包括FTP,TCPSocket,FILE文件,JMS,AQ等各种消息和协议的适配。对于JavaEJB组件提供的方法也可以通过OSB提供的EJBTransport适配后将EJB组件中的方法暴露为一个SOAPWebService服务能力。请点击此处输入图片描述Oracle-SOA-OSB技术原理1请点击此处输入图片描述消息交换总线技术是为了实现企业数据共享和应用集成,提供一种基于企业服务总线(ESB)的信息共享交换平台。该技术采用面向服务体系结构(SOA)的设计思想,以信息共享为目标,具有松散耦合的特点,实现了"集中式管理、分布式运行"的工作模式。通过设计标准的适配器组件,实现各种数据库和应用系统之间的数据共享与交换,能有效实现企业中信息共享,并具有良好的可扩展性和可靠性。Oracle的OSB总线包括ESB(EnterpriseServiceBus)和WSM(WebServiceManagement)两大部分,是ORACLE公司的消息交换总线产品。ESB包括MOM,ORBs,RPCs,WebServices功能的新型、综合类型中间件,通过配置集成;WSM包括服务管理,消息跟踪两个部分。使用OSB可以很容易的将企业已有的对外功能集成进来,并且能够集成和开发出来新的功能。ESB服务总线的核心功能在前面很多文档里面有已经介绍过,在这里再做简单总结:服务代理和位置透明ESB的一个重要功能,即将遗留系统或外部接口或服务能力接入到ESB,通过ESB再包一层后形成统一的服务目录朝外部发布,起到服务中介和原始无法位置透明的作用。最简单的服务代理就是仅仅只做服务路由转发,其它啥都不做,因此在OSB消息流绘制最简单的就是重要的pipeline是空的,仅仅只有业务服务和代理服务。协议转换和遗留系统适配接入协议转换是ESB的一个重要功能,其中包括了HTTP,TCP,FTP,JMS,EJB,MQ,FILE,SMTP等多种协议之间转换和适配能力。比如你可以接收一个SOAPWS服务调用请求,并将接收到消息写入到JMS;或者说你也可以通过JCA适配到某一个数据库,将数据库表发布为一个HttpRest查询服务接口。消息格式和内容转换这个一定要和协议转换分开来谈,支持多种消息格式和类型往往就是指的可以通过transform和数据映射功能将XML,JSON,FlatFile,MFL等多种消息格式类型之间进行数据映射和转换。举例来说,你可以服务调用的输入都是HttpRest服务接口,但是输入可以是Json格式,而输出可以转换为XML文本输出。服务路由(包括静态路由和动态路由)路由是ESB中非常重要的仲裁逻辑之一。路由场景是非常普遍的。譬如,针对不同的客户提供不同QoS的场景,执行时需根据客户的类型将其路由到不同执行能力的服务提供者;再比如当响应消息到达ESB时,总是需要将该响应消息送回最初的服务请求者处。路由可分为静态路由和动态路由。静态路由指得是设计时已经明确路由分支的情况,而动态路由的路由分支选择是在运行时动态确定的。不论是静态路由还是动态路由,路由分支的选择一定伴随着一个或一系列决策依据。决策依据可简单如一个If-Else语句,也可以复杂到需要通过多维决策表并通过多次判断才能得到最后的路由分支。Java高级架构二群688583154进群:可免费领取架构师学习资料。进群:获得面试学习资料进群:学习架构最新技能知识进群:了解最新BAT招聘动态数据映射转换(Transform)&内容丰富(ServiceEnrichment)数据映射转换是ESB的另外一个核心功能,举个例子来说我们根据一个标准的WSDL契约要求定义一个代理服务,而对于业务服务则是适配和连接到一个数据库表并返回一个结果集,那么这个WSDL结构就需要和数据库返回结果集的业务服务间进行数据映射和转换。一般而言,大多数ESB产品都提供了多种数据转换的方式,很多产商宣传中力推的都是“拖拽式”可视化映射的转换方式。该功能听起来的确很酷,看上去很直观。但是正如我们前面所说的,ESB是一个偏向技术层整合的组件,业务人员一般不会关心XML是如何转换成SOAP的。所以,对于开发者来说,这种“炫”功能并无太大吸引力。更重要的是,他们可能非常习惯于自己的编程语言,如Java、XSLT、ESQL和PHP等,这些语言操作起来要简单很多。在OSB12C增加了可视化的XSLT数据映射功能,XSLT是一个标准的XML转换语言,使用XSLT实现的转换逻辑可很轻易地在不同ESB产品间移植。几乎所有主流商业ESB产品都支持XSLT的转换机制。对于内容丰富来说,举例来说当接收到消费者的服务调用请求后,我们需要对输入消息内容进行补填再去调用原始的业务服务,也可能是OSB接收到Response返回消息后,我们会进一步补充实例ID,服务状态等信息后再返回给服务消费方,这些都属于内容丰富的范畴。消息处理机制和运行原理请点击此处输入图片描述OSB中的服务包括代理服务(ProxyService)和业务服务(BusinessService)两种。业务服务一般用作将外部已有服务接入到OSB总线上,代理服务的作用是将已有服务进行重新包装和整合,进行服务路由、逻辑处理之后对外发布新的服务。在OSB消息流中,一般都是通过ProxyService对外发布服务的,客户端通过调用在ProxyService中定义好的URL来调用OSB总线上的服务。当客户端调用ProxyService的时候,消息先经过ProxyService传输层(Transport)进入,传输层是有协议的,他可以解析和接入各种传输协议;然后通过绑定层(Binding)对传输层接入的消息及协议进行解析,对消息内容进行解析并且存放到上下文变量中,经过绑定层解析后的消息格式一般是通过SOAP格式进行包装并且附在以后的整个消息流传输过程中,以后的处理节点就通过访问上下文变量来查看、获取、编辑消息内容和消息结构;当然,在绑定层解析之后,消息协议仍然可以访问,绑定层会将协议信息存放在上下文变量中的$inbound变量中。消息输出时候的处理过程与消息输入相反。OSB核心经过Pipeline管道来进行消息路由,转换,映射,异常处理等一系列操作,如下图:请点击此处输入图片描述里面的几个关键组件为:lPipeline表示一个消息流转中批量的处理逻辑lStage可以被认为是一组动作处理的容器lAction是消息流中的逻辑,它用于具体决定如何处理消息lBranch节点可以让流程处理进入具体多个可能的处理路径中的一个在OSB消息流开发过程中,对于各种功能节点都可以使用XQUERY或者XPATH语言对节点属性、处理流程进行配置;而对于消息流的流程控制语句也是使用XQUERY来实现的。对XQUERY和XPATH有个基本的了解是能够进行消息流深入开发的重要基础。XPATH是标准的XML表达式语言,用于标识或定位XML文档中的某一部分,对于很多消息处理节点中的配置参数,都需要使用XPATH语言来表述,如对于DELETE(作用是删除消息中的某个元素或者属性)处理节点,就需要使用XPATH语言来描述删除目标元素;XQUERY是一种用于XML文档的结构化语言,用来描述循环和判断、函数处理、流程处理和控制、构造SOAP消息、处理消息结构和内容等处理命令的一种语言。在OSB上,一般比较复杂的处理逻辑都需要这两种语言来实现。OSB中对消息结构/内容进行转换一般通过XQUERY语言来实现,可以在WORKSHOP中使用可视化界面进行拖拽操作来实现消息格式转换,然后将生成的xq文件上传到控制台即可。OSB中的其它关键术语进一步解释和说明业务服务(BusinessService)业务服务是您要与其交换消息的企业服务的AquaLogicServiceBus定义。使用WSDL(WebServices定义语言)定义业务服务的方式与定义代理服务的方式相同。但是,业务服务的配置与代理服务的配置不同,因为业务服务没有管道。因此,不是由BEAAquaLogicServiceBus管道实现的服务即为业务服务。BusinessService是在OSB中所定义的,用于表示希望与后端交换信息的企业服务。代理服务(ProxyService)代理服务是在WebLogicServer上本地实现的服务的AquaLogicServiceBus定义。可以在WSDL、管道和策略等方面定义代理服务。如果代理服务需要安全凭据,则可以创建代理服务提供程序,以管理这些从AquaLogicServiceBus控制台映射到密钥库条目的安全证书。通过配置代理服务的消息流可以实现代理服务。消息流可包括下列节点:启动、管道对、分支和路由。端点(Endpoint)一个基于资源定位标志符的地址。BusinessService的端点是接入的外部服务的资源地址;而ProxyService是对外发布的新服务的资源地址。注意WSDL地址和端点地址不同,在访问到WSDL后,断点地址在WSDL的Port部分可以看到具体location。消息流(MessageFlow)消息流定义了代理服务的实现。消息流可以包括管道对和下列节点:开始、路由和分支。消息路由、业务逻辑处理、服务编排、服务整合等操作都是在消息流中实现,在OSB开发中,主要工作就是消息流的开发和调试。管道对(PipelinePair)请点击此处输入图片描述通过“编辑消息流”页可以添加管道对节点。管道对节点包含一个请求管道和一个响应管道。消息流可以不包含管道对节点,也可以包含多个管道对节点:代理服务(或对服务的操作)的请求和响应管道,以及可为阶段、管道和代理服务定义的错误处理程序管道。管道可以包括一个或多个阶段,阶段又可以包括操作。阶段(Stage)阶段是操作的容器,如消息路由、日志记录、消息广播、消息传送等操作都可以放到阶段中操作。动作(Action)动作是用户定义的运行时的逻辑步骤,用户需要实现的功能一般通过添加动作节点来实现,OSB已经提供了很多不同类型功能各异的默认节点,方便用户进行消息流开发。路由节点(RouteNode)路由节点是在管道对中的请求和返回之间的交换节点,主要是用于调用业务服务。用于定义消息目标的容器也可以用于执行单向通信,例如使用文件或email作为代理服务中请求处理和应答处理的分界点当Route节点分发了请求消息后,请求处理就认为结束,而当Route节点收到应答消息时,表明应答处理的开始。路由节点一般出现在管道对之后,处于管道对中的请求和应答之间。上下文变量(ContextVariables)上下文变量是消息进入OSB总线之后的存储载体。在消息通过传输层之后,绑定层会自动根据消息协议和消息内容,将其绑定到上下文变量中;当消息要输出OSB之前,OSB会根据需要自动将上下文变量中的消息内容转换成为符合输出协议类型的消息格式。上下文变量主要包括以下结构:l$header:包含SOAP消息的SOAP标头(用于包含SOAP标头的SOAP消息)。header变量对于非SOAP消息类型包含一个空的SOAP头元素。l$body:有下列几种情况:SOAP消息-包含从SOAP信封中提取的部分;非SOAP、非二进制消息-包含包括在元素中的整个消息内容。二进制消息-包含包括在中的对该二进制消息的内存中副本的引用。l$attachments:包含某个特定消息的MIME附件。l$fault:包含在消息处理期间所发生错误的相关信息。OSB中的消息上下文是一组存储消息内容的属性,并提供消息的元信息。Oracle-SOA-OSB技术原理2请点击此处输入图片描述从OSB的功能架构图可以看到,实际的OSB架构包括了消息适配,统一安全管理,配置框架,服务虚拟化,服务管理几个部分的内容。而对于实际的服务封装(代理服务,业务服务,管道)都在服务虚拟化部分里面,功能图上只是列出了基于内容动态路由,消息转换和服务消息链等几个关键点。对于OSB服务总线,基本支持业界常见的各种消息服务接入。WebServiceTransportslHTTP/SOAP,REST,WS-I,WS-Security,WS-Policy,WS-AddressinglSOAPv1.2andv1.1传统的消息lHTTP,JMS,AQ,MQNativetransport,EJB/RMI,Tuxedo,FTP,SMTP,FilelEJB/RMIonWebSphereTransportSDKlEnterprise-specificcustomtransportsJCAAdpaterslBuild-inOracleEBS,DatabaselPeopleSoft,Siebel,JDEdwards,SAP协同工作能力l.NET,TibcoEMS,IBMWebSphere,ApacheAxis,CycloneB2BInterchange,iWay5.5adapters统一安全管理对于服务安全管理,最常说的就是服务的传输安全,消息安全,访问控制安全,数据安全等标准内容。而对于功能架构图里面主要是在强调认证、授权、身份验证,签名/加密几个方面的内容。而对于OSB的安全管理体系,个人认为重点仍然要放在OWSM和安全策略上面。OWSM是用于安全、管理和治理的策略创建的运行时框架。您可以创建策略,将它们附加到服务总线中的服务,并在消息传递生命周期中与OWSM代理一起执行这些策略。OracleWeb服务管理器(OWSM)是服务总线使用的Web服务安全机制。所有新创建的资源,如业务服务和代理服务,都使用OWSM策略来保证安全性。WLS9策略被弃用,不能用于为新的服务总线资源配置安全性。请点击此处输入图片描述服务虚拟化(ServiceVirtualization)强大的服务组装能力基本全部体现在服务虚拟化部分,即实际的服务开发和封装,服务路由和转换等基本都是服务虚拟化的内容,包括我们实际在OSB操作中的业务服务和代理服务的创建,消息流的绘制(管道创建,验证,路由,Split/Join)等操作。具体的服务虚拟化和OSB强大的服务组装能力基本可以参考下图:请点击此处输入图片描述OSB支持的协议(Protocols)和消息格式这是11g里面的一页PPT,对于OSB支持的协议和消息格式相对来说是相对完整,包括了对TCP(Socket)等协议的支持能力。同时对于消息格式包括了对Json,MFL,FlatFile等各种消息格式。请点击此处输入图片描述Proxy消息处理机制这里面需要深入了解,即整个消息处理和运行机制是如何的,具体如下:1.传输层TransportLayer(接收消息)2.绑定层BindingLayer(解包消息,得到真正的消息体)3.代理服务ProxyService(消息处理逻辑)4.绑定层BindingLayer(打包消息,得到真正的消息体)5.传输层TransportLayer(返回和发送消息)BusinessService是在OSB中所定义的,用于表示希望与后端交换信息的企业服务,理解这点相当重要。因为你既可以把外部已有的业务系统提供的WS引入并映射为一个业务服务,也可以在通过JCA等适配后将外部的业务系统能力发布为一个业务服务。Java高级架构二群688583154进群:可免费领取架构师学习资料。进群:获得面试学习资料进群:学习架构最新技能知识进群:了解最新BAT招聘动态消息流的绘制和处理(MessageFlow)对于消息流的绘制重点还是在管道Pipeline上,而管道核心是包括了Request请求处理,调用BusinessService服务,Response返回三个部分的内容。管道真正将以上三个部分衔接为一个整体,也是OSB的轻量服务能力编排的重要体现。通过管道就可以实现消息路由,验证和校验,异常处理,Split/Join等操作。请点击此处输入图片描述消息格式和内容转换(Transformation)lXMLtoXML(XQueryorXSLT)lXMLtoText/Binary(XQuery)lBinarytoBinary(MFL)而实际上当前我们使用最多的仍然是XQuery+XSLT进行消息转换。在11g的时候更多的是使用XQuery+XPath代码的方式进行转换和映射,而在12c版本已经增加了XSLT的可视化数据映射能力,这是消息转换这块相对大的一个能力提升。Oracle-SOA-OSB代理服务封装在进入到osbconsole控制台后,首先通过右键菜单创建一个新项目,在OSBProject可以看到一个完整的已经设计封装完成的代理服务项目的目录和资源结构,具体如下:请点击此处输入图片描述我们首先通过右键菜单创建一个TestProj_Heminglu的新项目出来,然后在这个新项目下创建BusinessServices,ProxyServices,Resources三个子文件夹来分别存放代理服务,业务服务和资源文件信息。在将详细创建过程前,我们先介绍下,在osbconsole控制台点击右键菜单后创建->资源后可以创建的服务和资源类型信息。第一个tab是服务,在服务tab里面可以看到,可以创建代理服务,业务服务和管道。请点击此处输入图片描述代理服务:代理服务是在ServiceBus上本地托管的通用中介Web服务的ServiceBus定义。代理服务通过接口(不一定等同于服务提供程序或服务使用者业务服务的接口)与外部服务进行通信。业务服务:业务服务是在业务处理期间交换消息的企业服务的ServiceBus定义。业务服务的配置包括其接口(服务类型),其用于与服务生成器连接的传输类型和配置,安全要求,消息处理,性能优化和SLA预警规则。第二个Tab是接口,更多的是接口契约,里面包括了WSDL,WADL,方案,WS策略等。其中WSDL是常说的基于SOAPWS的服务接口契约,而WADL则是基于REST服务接口的服务契约。请点击此处输入图片描述Web服务策略框架(WS-Policy)是一个基于XML的可扩展框架,它使用域特定的安全断言扩展Web服务的配置,并指定Web服务的安全要求,期望和功能。在ServiceBus中,WS-Policy的主要用途之一是在代理服务和业务服务中配置消息级安全性。JCA绑定资源允许您创建通过OracleSOASuiteJCA适配器与外部服务交互的业务服务和代理服务。JCA绑定由服务WSDL文档和在OracleJDeveloper中创建的相应JCA文件组成。在OracleServiceBus控制台中,需要将JCA文件上载到JCA绑定资源中才能基于该JCA适配器创建业务服务或代理服务。即JCA绑定主要用于数据库适配方面使用。第三个Tab是转换方面的,里面包括了Xquery和XSLT和MFL,其中Xquery和XSLT主要用于WS服务接口,XML间的数据映射和转换。MFL主要用于二进制消息流的数据映射和转换。请点击此处输入图片描述XQuery资源允许您定义用于在XML,非XML和Java数据类型之间转换数据的映射,以便快速集成异构应用程序。XQuery资源还可以包含XQuery代码段,以便使用XPath查询XML文档并获取数据。可扩展样式表语言转换(XSLT)映射描述XML到XML的映射。使用“创建XSLT文档”对话框可以为ServiceBus项目创建新的XSLT转换。MFL资源:OracleJDeveloper中提供的OracleFormatBuilder允许您定义非XML数据记录的消息结构。定义二进制记录的层次,字段的布局以及字段和组的分组时,该信息将另存为消息格式语言(MFL)文档,之后可以使用该文档执行运行时转换。使用FormatBuilder创建MFL文档后,便可以通过创建MFL资源并将文件上载到该资源将文件导入到OracleServiceBus中。剩余的安全和其它两个Tab不再做进一步介绍,可以创建的基础资源介绍完成后,还是回到刚才代理服务的介绍,我们采用互联网已有的查询天气一个wsdl服务地址进行封装,将其发布为一个代理服务。1.导入WSDL资源文件地址:http://www.webservicex.net/globalweather.asmx?WSDL访问到该WSDL地址和文件后,通过网页另存为,将其存储为一个本地文件globalweather.wsdl文件。创建一个Resource的资源文件夹,然后右键文件夹,点击创建资源->接口->wsdl创建资源,资源名为globalweather.wsdl,然后点击文件上载按钮上传上步存储到本地的wsdl文件。2.创建代理服务在WSDL资源导入完成后,可以开始创建代理服务,代理服务是OSB发布出去的服务。首先创建一个ProxyServices文件夹,然后选中文件夹右键点击创建资源->服务->代理服务创建代理服务。代理服务的创建本身有三种类型,即:lSOAPl类型化/无类型RESTl向导中的类型化REST(带WADL)在这里我们使用SOAPWS代理服务,对于Rest服务接口后续再做进一步详细介绍。代理服务资源名我们定义为GetWeatherInfoSrv_Proxy,对于服务定义为基于WSDl的服务,通过选择按钮,搜索,然后选中到刚才定义和导入的WSDL资源文件。选后对于端口/绑定,我们选择SOAP1.1的版本保留兼容性。对于管道部分checkbox默认选中,这样在代理服务创建完成后会自动创建管道。具体配置完成后的参考界面如下,可以看到配置的详细信息。请点击此处输入图片描述代理服务的创建向导最后一步涉及到端点地址,这个端点URI是可以任意配置的,用于和外部接口交互服务消费者使用的服务接口端点地址。你可以修改这端点地址,比如模式端点地址为:/TestProj_Heminglu/ProxyServices/GetWeatherInfoSrv_Proxy你也可以将前面的项目路径部分去掉,仅仅保留/ProxyServices/GetWeatherInfoSrv_Proxy3.创建业务服务注意我们访问http://www.webservicex.net/globalweather.asmx?WSDL这个地址的时候,在这个文件里面可以看到该WS服务的提供的具体端点地址信息,即soap:addresslocation="http://www.webservicex.net/globalweather.asmx"我们实际调用的外部服务的端点地址信息在创建业务服的时候要使用到。首先还是创建一个BusinessServices的文件夹,然后右键点击创建->资源->服务->业务服务来创建一个业务服务。业务服务资源名定义为GetWeatherInfoSrv_Business,请点击此处输入图片描述传输部分注意端点地址的配置,该端点地址即为外部实际的端点地址。负载均衡算法暂时默认不用修改。请点击此处输入图片描述4.管道和消息流绘制在代理服务,业务服务和资源文件全部创建和配置好,剩下的工作就是打开管道进行消息流的实际绘制,简单来说就是将代理服务和业务服务衔接到一起来。中间涉及到路由,分支或异常处理等。选择ProxyServices目录下面的GetWeatherInfoSrv_Proxy-pipeline文件后,管道基础信息会显示在右边界面上,然后点击右上角的打开消息流小图标,即可以打开消息流绘制界面。在打开消息流绘制界面后,选择到管道节点,可以看到出现的菜单中可以添加管道对,添加路由,添加条件分支等各种选择。通过添加这些内容进行消息流绘制。在这个案例中我们首先要添加路由,即将Proxy代理服务路由到实际提供业务能力的外部业务服务上。请点击此处输入图片描述实际我们要做的事情具体如下:1.选择到管道节点后,在菜单中选择添加路由,增加一个路由节点RouteNode1。2.选择到RouteNode1节点,在出现的菜单中点击编辑路由。3.点击编辑路由后,按如下进行菜单和按钮点击添加操作-》通信-》路由,进入到路由编辑界面。4.在出现的编辑里面种有一个路由到服务,选择服务超链接,进入到服务选择界面5.在服务选择界面中选择我们刚才创建好的业务服务信息。
-
SOA架构干货:来听听架构大师 Martin Abbott 怎么说
SOA架构扩展性的13条最佳实践SOA架构干货:来听听架构大师MartinAbbott怎么说以下内容节选自:世界级软件架构大师MartinAbbott亲研架构秘籍《突破技术领导力》1.尽可能多地使用异步的通信方式同步调用会同时将两种不同服务的可用性捆绑在一起。如果其中一者产生错误或是堵塞,另一者也会受到影响。2.使用用户泳道来隔离错误根据用户划分来创建硬件隔离的“泳道SwimLanes”。这可以防止因为某个客户所产生的问题而影响其他客户,同时有助于诊断问题和代码发布。3.使用多层次的缓存在多个层上尽可能地使用缓存,如数据库前的对象缓存(例如:memcached),或是页面内容缓存(例如:squid),边缘缓存(例如:Akamai)。4.监控应用程序性能首先要站在客户的角度去分析你的程序性能。从外部网络进行监控测试,可以模拟真实的用户体验。同时,还可以根据查询和事务操作上执行次数和耗时数据,来监控程序的内部工作情况。5.复制数据库复制数据库可以帮助还原数据,同时把读取的负载分配到多个实例。6.使用切片(Sharding)技术根据不同服务或(和)用户使用的量级来分割应用和数据库。虽然它会给程序带来一些轻量的复杂度,但在规模上这样做更易于扩展。7.尽可能少的使用关系型数据库RDBMS特性尽可能使用OLTP(on-linetransactionprocessing,联机事务处理)数据库作为存储设备。因为要确保ACID属性,关系型数据库在扩展型方面会有很多挑战。你的交易越依赖关系型数据库系统(RDBMS)提供的功能,那么系统在扩展时你投入的负载就越大。建议从数据库中将主要的业务逻辑(例如存储过程)都移到应用程序或服务内。当系统需要做大规模扩展时,应该通过应用或服务来扩展,而不是通过SQL。8.在服务器上小批量地部署新代码尽可能小批量地在服务器上部署新代码,而不要让整个站点关闭。这要求所有代码都要向后兼容,因为在部署时你会有两个版本的代码同时运行。这种方法可以帮助我们方便地找到应用质量或者L&P测试(负载性能测试)所遗漏的问题,同时最小化对客户的影响。9.在部署前执行负载与性能测试一定要在产品部署前,执行负载与性能测试。虽然这不会发现所有问题(这也是为什么我们需要回滚Rollback的能力),但它很值得做。10.不能回滚注定失败确保所有版本的代码都有回滚能力,在准生产或者QA环境演练,必要时在生产环境中用它来解决客户的问题。如果没有经历过无法回滚代码的痛,还继续冒险地“修改-发布”代码,那么你会在未来某个时刻体会到这种痛苦。11.容量规划/扩展峰值对于每一层、每一个服务,都要清楚它有多大容量。使用扩展峰值(ScalabilitySummits)来规划容量的增长需求。12.问题根源分析确保有强大的学习文化,当问题出现时,一定要确保找到问题根源,才能最终修复问题。13.从一开始就重视质量工作架构质量从一开始设计就要考虑进去,质量不能靠测试来解决。测试只能发现研发过程中带来的问题。
-
SOA规划:央企集团公司SOA实施建设方案(图文)
SOA是一种软件架构,而不是局限于某个技术的组合,它超越了技术范围。SOA的关键是“服务”。W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。SOA规划:央企集团公司SOA实施建设方案(图文)最终结果通常是使用者的状态发生变化,但也可能是提供者的状态改变,或者双方都产生变化”。服务是网络中可用的软件资源。服务提供者通过标准机制提供服务,使用者通过网络有计划地使用服务。服务储备库发布服务所在位置,并在使用者请求服务时定位服务。服务使用者和提供者的角色不是唯一的,服务提供者也可以是使用者,反之亦然。SOA具体的实现有很多,包括WebService,Ses-sionBean,JINI等,但随着WebService技术被越来越重视,其己经成为构建SOA的主要技术。
-
基于SOA和ESB的供应链快速响应系统架构
引言基于SOA和ESB的供应链快速响应系统架构供应链(SupplyChain)上下游企业之间的协同能力成为衡量企业竞争力的重要指标,企业要降低成本、赢得客户,必须对客户订单做出快速响应(QuickResponse,QR)。快速响应机制是以可靠、开放、柔性的系统集成为基础的,通过快速响应集成系统完成信息的及时交换和共享,企业以最快的速度接受客户采购请求、及时向供应商采购完成客户订单生产所需要的原料、及时将生成完成的产品交到客户手中。在采用面向服务架构(ServiceOrientedArchitecture,SOA)的系统集成方式之前,有CORBA、DCOM、COM+、RMI,都是用来实行分布式架构的技术,而且也被证明是不同技术阶段的可行的系统集成方法。但是这些系统有一个共同的缺陷,就是它们要求服务客户端与系统提供的服务本身之间必须进行紧耦合,即要求一个同类基本结构。这样降低了系统的可扩展性和可维护性,系统往往十分脆弱,如果一端的执行机制发生变化,那么另一端便会无法正常运行。这样的系统集成方法难以适应供应链快速响应对信息交换和共享的及时性要求。SOA是一种软件系统架构和软件设计模式,而企业服务总线(EnterpriseServiceBus,ESB)是实现这种架构的一种具体方法。Web服务是实现基于SOA的ESB集成方法的核心,它基于XML、SOAP、WSDL和UDDI等协议。Web服务技术是一个崭新的分布式计算模型,是Web数据和信息集成的有效机制。基于SOA的ESB集成系统的基本单元是服务,这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的,并且可以通过网络查找其地址。服务间通过消息互相调用,通过服务协调,完成一定的业务处理,服务请求者无须知道服务提供者的技术细节。SOA强调通过清晰的系统结构层次,使系统具有良好的通用性和可维护性。SOA从软件体系结构的角度出发改造企业的原有系统或设计新的应用系统,从而支持动态实现将来未知的企业应用集成。ESB为SOA系统提供了一个核心架构,以集中管理各种服务。ESB是SOA、Webservice、XML等技术相结合的产物,是一种分布式的集成框架,是SOA架构概念的具体实现。ESB定义通常如下:它是由中间件技术实现并支持的面向服务架构的一组基础架构功能,支持异构环境中的服务、消息以及基于事件的交互,并且具有适当的服务级别和可管理性。一个ESB提供下述的能力:1)SOA的体系结构;2)采用面向消息的交互方式和XML作为消息表示与转换的标准。ESB是一种新的集成方法,支持企业应用间面向服务的交互,就像PC中硬件的总线,ESB智能地在企业系统间路由数据流,配合和转换各个系统需要的数据信息。ESB作为SOA架构的数据交换HUB,同时为SOA提供一种连通性基础架构,用以连接SOA中的服务。这种模式有助于减少应用接口数量和复杂性,是解决企业之间异构系统集成,实现准确高效的信息交换的有效方法。本文探讨应用基于SOA的ESB系统集成方法来建立一种新型的供应链快速响应集成系统。1.供应链快速响应系统集成条件供应链快速响应系统涉及上游供应商、下游销售商及第三方物流公司,这些合作伙伴的信息系统、单证及数据交换格式都不相同,使用传统系统集成方式大大增加了系统集成的成本和复杂性。为适应激烈市场竞争需要,企业需要引入新的合作伙伴,淘汰不能满足服务要求的合作方,企业供应链始终处于一个动态重组的状态。新合作伙伴的加入,意味着需要协同新的业务流程、集成新的信息系统、处理新的格式数据。企业间业务流程协同,需要有一个开放、松散耦合的信息集成系统来支持。为此,供应链快速响应集成系统应至少满足如下条件:1)支持不同格式数据的统一交换,实现异构系统间的集成;2)尽可能减少对参与供应链快速响应集成系统数据交换的原有系统的修改;3)保持供应链快速响应集成系统的柔性和可扩展性;4)节省企业IT方面的投资。2.基于SOA的ESB模式的系统集成设计2.1基于SOA的ESB模式的系统集成架构SOA摆脱了面向技术的解决方案,朝着面向服务的方向发展。与其他架构相比,SOA更有弹性,使得企业能够对变化做出快速响应,并且利用变化来获得优势,SOA为动态、异构的供应链快速响应系统集成提供了一个理想的构架模式。基于SOA的ESB集成框架定义了一个数据适配器完成数据转换、消息驱动服务的模型。将业务处理逻辑封装成一系列的服务组件,消息处理器接收系统外发送来的请求消息,通过注册中心检索相应的数据适配器完成数据转换,将转换后的数据封装成一定格式的数据消息,调用服务组件,完成数据处理。ESB是实现SOA架构的重要方法,符合SOA的构架特征,包括服务的提供者、服务请求者和注册中心,一般由消息处理层、服务层、数据访问层、数据存储层等构成。本文设计的基于SOA的ESB模式的供应链集成系统架构如图1所示。图1基于SOA的ESB模式的系统集成架构在图1中,该系统主要由以下几个主要元素构成。1)服务请求端。外部应用、服务、代理都可能是服务请求端,服务请求端发送基于XML消息规范的SOAP请求消息到ESB。服务请求端的请求消息包括从业务系统提取的业务数据,如供应商的装箱单信息(最终由服务提供端的服务处理成采购商的报关单),也包括服务请求端在ESB注册中心注册数据适配器号、服务路由等信息。2)消息处理器。消息规范采用XML语言来描述消息,消息处理器取出消息队列中的头信息,根据解析出来的头信息标识,到中心注册查找相应的数据处理适配器、数据映射关系表。3)注册中心。服务注册中心充当信息库,存放着ESB当中可用的Web服务信息、消息路由信息、消息处理配置信息。注册中心根据配置信息,调用相关的数据适配器进行数据转换。4)数据适配器。它将从服务请求端传递过来的消息转换成符合ESB中相应Web服务接口标准要求的数据。5)服务提供端。接收由服务请求端发送、由ESB数据适配器转换后的数据,对这些数据进行相关的处理。是由一些互相独立的、完成逻辑处理的服务单元构成,按服务请求端事先注册的服务路由表顺序执行相关服务,并将处理后的数据发送到ESB的数据输出适配器进行数据转换处理,以消息的形式反馈给服务请求端。2.2基于SOA的ESB模式的集成系统执行机制采用基于SOA的ESB模式的系统集成方法,可以有效地降低被集成系统之间的耦合程度,具有良好的可扩展性、可复用性、可维护性。基于SOA的ESB模式的集成系统执行过程包括服务注册、请求消息发送、消息解析、数据适配器进行数据转换和Web服务处理五个阶段组成,各阶段执行过程如图2所示。图2基于SOA企业服务总线模式的集成系统执行机制图2中,各阶段的执行过程描述如下。1)服务注册阶段。包括服务提供端的注册和服务请求端的注册。服务请求端的注册包括对ESB数据适配器的申请、服务路由定义及数据映射关系的建立。2)请求消息发送。服务请求端发送请求消息到服务提供端,请求端将一个或多个商务文档加载到请求消息中,SOAP请求消息是用XML来编码的。在服务请求端和服务提供端之间的消息交互模式有以下几种:请求/响应模式;会话交换模式;异步消息(AsynchronousMessage)模式;发布—订阅(Rublish/Subscribe)模式。3)消息解析。ESB接收到请求消息后,消息处理器对接收到的消息进行解析,获取请求端注册申请的数据适配器标识,根据标识到注册中心检索具体的数据适配器。4)数据适配器进行数据转换。按照数据映射关系表,数据适配器将收到解析后的数据转换为符合相应Web服务接口标准要求的数据。5)Web服务处理。Web服务接收到经过数据适配器转换处理的数据后,完成业务逻辑处理,并输出相关处理结果消息。3.供应链快速响应集成系统构建供应链快速响应系统涉及采购、运输、通关、收货及对帐等业务流程,快速响应系统的整体执行效率需要各个节点的执行效率来保证。供应链快速响应是建立在及时、高效、准确的信息共享基础上,通过对上下游异构系统的集成,完成信息的交换和共享。如图3,基于SOA的供应链快速响应系统集成是通过参与系统集成的双方互相以消息的形式调用对方的Web服务,服务处理完成后,再将含有处理结果的数据以消息的形式反馈给远程服务调用方。图3基于SOA的供应链快速响应集成系统模型本文以快速通关为例来说明该集成系统:通关环节是供应链快速响应系统的重要一环,很多因素会影响通关效率,造成原料交付的延误,如采购商录入的进口报关数据与供应商实际交货数据不一致、第三方物流服务商提供的相关数据滞后、录入错误等。为避免进口报关环节的差错和延误,采购企业希望从供应商那里获取原始数据,如装箱单数据、发票数据,将这些数据转换为进口报关数据,从而提高进口报关单证的制作效率和数据准确性,避免单证错误,影响海关放行。但每家供应商的系统不同,单证格式也不一样,采用传统的数据交换方式,必然造成采购企业的采购门户平台针对不同供应商的大量定制开发,随着新的供应商加入,系统最终很难维护,甚至无法正常运行。采用基于SOA的ESB模式的系统集成方式,数据适配器可以对供应商的数据进行预处理,将不同格式的装箱单数据或发票数据转换为符合进口报关单EDI报文生成服务接口标准的XML格式数据。以下是基于SOA的ESB模式的快速通关集成系统处理流程。1)供应商在平台上注册数据适配器。按注册中心向导,根据单证类型,注册相应的数据适配器,建立数据字段的映射关系,如发送发票数据,注册Adapt1数据适配器;发送装箱单数据,注册Adapt2数据适配器。注册信息将保存到企业服务总线的注册中心。2)服务请求端(供应商)发送含供应商代码、采购订单号、数据适配器注册编号参数的消息到采购企业门户平台,消息中以XML格式负载发票信息或装箱单信息。3)采购门户平台的服务总线接收到SOAP消息后,对消息进行解析,获取请求端注册的数据适配器号、服务路由及数据信息;4)注册中心根据传递来的数据适配器代码,检索相关注册信息,如数据匹配映射关系,调用相应数据适配器处理数据。5)数据适配器处理完数据后,将发票信息(或装箱单信息)转换为后台服务能接受的统一格式化数据,再调用进口报关单EDI报文生成服务,将由数据适配器转换成统一格式后的数据生成进口报关单EDI报文。系统处理交互如图4。图4生成进口报关单EDI报文的系统交互图由于系统框架的开放性、数据适配器的可配置性以及数据交换标准的统一性,进口企业可以引用供应商发票、装箱单或运单等不同单证信息作为进口报关的数据来源,同时支持Excel、TXT、CSV、XML等不同格式文件之间的数据转换,基于SOA的ESB方法为快速通关业务中异构系统间的数据交换提供了一个理想的系统集成框架,使通关效率得到了显著地提高。4.结语本文分析了当前企业实施供应链快速响应系统集成过程中,实现异构系统之间数据交换和共享时遇到的主要问题。将ESB作为实现基于SOA架构系统集成的具体方法,提出了一个遵循SOA基本原则、应用ESB为系统集成方法的供应链快速响应系统架构,重点对该系统架构组成和执行机制进行了详细说明,并应用此框架解决一个具体应用问题。这种松散耦合的系统集成框架提高了系统的可扩展性和可维护性,SOA和ESB共同为分布式、异构的系统集成提供更高效的、可扩展的平台和工具,使供应链快速响应集成系统的柔性大大提高。