集成架构（精选8篇）
集成架构 篇1
0 引言
随着互联网的发展, Web的出现使得一种围绕Web服务的计算模式成为当前计算机应用的主流模式, 并推动了软件开发、软件应用、应用集成方式的重大变革。为了更好满足现代企业业务敏捷性需求, 就要创建一个业务敏捷的IT架构, 它不仅可以处理当前的业务应用, 还可以满足未来的业务需求。业务敏捷性是指企业对变更快速和有效地进行响应, 并且利用变更来得到竞争优势的能力。该IT架构能够满足这种业务敏捷性, 同时实践必须遵循“业务驱动服务, 服务驱动技术”的原则。
1 计算模式
随着Web的出现, 原有的集中式计算和客户机/服务器模式表现出很多不足, 已经不能适应Web的发展。人们需要利用互联网, 将应用分布到整个Web中, 而不是局限于企业局域网内部, 这就催生了一种更加灵活的多级分布式计算模式, 即浏览器/服务器 (B/S) 模式。它是一种基于Web的协同计算, 是一种三层架构的计算模式:第一层为客户端表示层, 只保留一个Web浏览器, 其运行代码可以从第二层的Web服务器下载到本地的浏览器中执行;第二层为应用服务器层, 由一台或多台Web服务器组成, 处理应用中的所有业务逻辑、对数据库的访问等工作;第三层为数据中心层, 安装数据库服务器, 负责整个应用中的数据管理。B/S模式比较其他计算模式, 体现了用户可以在任何地点使用系统的良好开放性和相同浏览器界面跨平台访问系统的通用性, 有效降低了整个系统的运行和维护成本。
2 Web服务及其体系架构
Web服务 (Web Service) 是一种新型的软件开发模式, 它可以将软件功能模块封转为Web服务, 实现业务级别的重用和集成。Web服务使用标准化的XML消息传递机制作为基本的数据通信方式, 消除使用不同组件模型、操作系统和编程语言的系统之间存在的差异, 使异类系统能够作为计算网络的一部分协同运行。
Web服务的体系结构由3个参与者和3个基本操作构成。3个参与者分别是服务提供者、服务请求者和服务代理, 3个基本操作分别为发布、查找和绑定, 其关系如图1所示。
3 软件体系架构演变
从计算机诞生到现在, 计算机硬件技术和网络技术在发展的同时, 计算机软件也在悄然地发生巨变。这种变化不仅表现在计算机软件的内涵、应用方式上, 同时也表现在软件的设计模式和开发方法上。软件开发思想的演化, 使得在Web流行的今天, 推动了面向服务的体系架构的产生和发展, 使其成为下一代软件体系架构的主流。
3.1 基于组件的体系架构
1991年, 对象管理组织 (OMG) 发布了公共对象请求代理体系架构 (CORBA) , 它是一种标准的面向对象分布式应用程序的标准结构。它的目的是为了简化开发分布式应用程序的复杂性, 用于创建一个基于对象的跨平台的分布式结构。为了实现上述目标, OMG组织制定了OMA (Object Management Architecture, 对象管理体系结构) 参考模型。该模型描述了OMG的规范所遵循的概念化的结构基础, 其核心部分是ORB (Object Request Broker, 对象请求代理) 。基于ORB机制就可以充分利用分布的、可以互操作的对象构造和可以互操作的应用。这种优势是明显的, 用户可以在不了解实现交互细节的情况下, 建立共享资源的应用。
CORBA可以看作一种软件总线, 它希望一个用户的软件系统是由运行在其上的一个个独立的软件组件对象构成。为了解决代码共享和分布应用问题, 微软分别提出了组件对象模型 (COM) 和分布式组件对象模型 (DCOM) , 在微软的系统上, COM/DCOM发挥了应有的作用。但由于协议开发没有跟进, CORBA的思想实现得并不理想。同时由于互联网是一个存在着巨大异构的环境, 伴随着Web服务的出现, 2000年后面向服务的体系架构 (SOA) 随之兴起, CORBA架构逐渐淡出。
3.2 面向服务的体系架构 (SOA)
SOA (service-oriented architecture) 是面向服务的体系结构, 是一类分布式系统的体系结构。这类系统是将异构平台上应用程序的不同功能部件 (称为服务) 通过这些服务之间定义良好的接口和规范, 按松耦合方式整合在一起, 即将多个现有的应用软件通过网络将其整合成一个新系统。
SOA的体系结构仍旧是三层或N层结构 (如图2) , 但对异构平台各层之间的联系, 不是用CORBA或J2EE的方式, 而且用Web的服务协议来实现, 概念简单统一, 目前都是采用嵌入ESB服务总线的平台来实现, ESB是一个中间件群, 确保系统实现服务功能、各种中间件功能及松耦合连接等。另外, 普遍采用BPEL (业务过程执行语言) 来描述用户需求, 由BPM (业务过程管理平台) 来解释执行。
SOA架构的5个层次分别如下 (按照从下到上的顺序) :①可操作系统:表示现有IT资产, 说明IT投资非常宝贵, 应该在SOA加以利用;②服务组件:实现服务, 可能通过使用可操作系统层中的一个或多个应用程序来进行。如模型中所示, 使用者和业务流程并不能直接访问组件, 而仅能访问服务。现有组件可以在内部重用, 或在合适的情况下在SOA中使用;③服务:表示已部署到环境中的服务。这些服务由可发现实体进行治理;④业务流程:表示将业务流程作为服务编排实现的操作构件;⑤使用者:表示用于访问业务流程、服务和应用程序的通道。
SOA的主要优点:①利用现有的资产。方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值, 而不必重新从头开始构建;②更易于集成和管理复杂性。将基础设施和实现发生的改变所带来的影响降到最低限度。因为复杂性是隔离的。当更多的企业一起协作提供价值链时, 这会变得更加重要;③更快地整合和现实。通过利用现有的构件和服务, 可以减少完成软件开发生命周期所需的时间。这使得可以快速地开发新的业务服务, 并允许组织迅速地对改变做出响应和缩短开发时间;④减少成本和增加重用。通过以松散耦合的方式公开业务服务, 企业可以根据业务要求更轻松地使用和组合服务;⑤SOA业务流程是由一系列业务服务组成的, 可以更轻松地创建、修改和管理它来满足不同时期的需要。
Web Service平台是一套标准, 它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言, 在任何你喜欢的平台上写Web Service, 只要我们可以通过Web Service标准对这些服务进行查询和访问。Web Service的目标是即时装配、松散耦合以及自动集成。
Web Service是技术规范, SOA是设计原则。从本质上讲, SOA是一种架构模式, 而Web Service是利用一组标准实现的服务。Web Service是实现SOA的方式之一, 用Web Service实现SOA的好处是:可以实现一个中立平台, 来获取服务, 获取更好的通用性。
3.3 云计算模式的体系架构
3.3.1 云计算技术
美国国家标准与技术研究院 (NIST) 定义:云计算是一种按使用量付费的模式, 这种模式提供可用的、便捷的、按需的网络访问, 进入可配置的计算资源共享池 (资源包括网络、服务器、存储、应用软件、服务) , 这些资源能够被快速提供, 只需投入很少的管理工作, 或与服务供应商进行很少的交互。“云计算”概念被大量运用到生产环境中, 国内的“阿里云”与云谷公司的XenSystem, 以及在国外已经非常成熟的Intel和IBM, 各种“云计算”的应用服务范围正日渐扩大, 影响力也无可估量。云计算可以认为包括以下几个层次的服务:基础设施即服务 (IaaS) , 平台即服务 (PaaS) 和软件即服务 (SaaS) 。IaaS、PaaS、SaaS分别在资源层、平台层、应用层实现。
3.3.2 云计算模式的体系架构
云计算的体系结构由5部分组成 (如图3) , 分别为应用层、平台层、资源层、用户访问层和管理层, 云计算的本质是通过网络提供服务, 所以其体系结构以服务为核心。
云计算体系架构的5个层次分别如下:
(1) 资源层是指基础架构层面的云计算服务, 这些服务可以提供虚拟化的资源, 从而隐藏物理资源的复杂性。物理资源指的是物理设备, 如主机、服务器、网络设备、存储设备等。服务器服务指的是操作系统的环境, 如linux集群等。网络服务指的是提供的网络处理能力, 如防火墙、VLAN、负载均衡等。存储服务为用户提供数据存储能力。
(2) 平台层为用户提供对资源层服务的封装, 使用户可以构建自己的应用。数据库服务提供可扩展的数据库处理的能力。中间件服务为用户提供可扩展的消息中间件或事务处理中间件等服务。
(3) 应用层提供软件服务。企业应用是指面向企业的用户, 如财务管理、客户关系管理、商业智能等。个人应用指面向个人用户的服务, 如电子邮件、文本处理、个人信息存储等。
(4) 用户访问层是方便用户使用云计算服务所需的各种支撑服务, 针对每个层次的云计算服务都需要提供相应的访问接口。服务目录是一个服务列表, 用户可以从中选择需要使用的云计算服务。订阅管理是提供给用户的管理功能, 用户可以查阅自己订阅的服务, 或者终止订阅的服务。服务访问是针对每种层次的云计算服务提供的访问接口, 如相对应用层的访问, 提供的接口可能是Web。
(5) 管理层是提供对所有层次云计算服务的管理功能:安全管理、服务组合及管理等。
3.3.3 云计算平台具有的主要特征
(1) 资源配置动态化。根据消费者的需求动态划分或释放不同的物理和虚拟资源, 当增加一个需求时, 可通过增加可用的资源进行匹配, 实现资源的快速弹性提供;如果用户不再使用这部分资源时, 可释放这些资源。云计算为客户提供的这种能力是无限的, 实现了IT资源利用的可扩展性。
(2) 需求服务自助化。云计算为客户提供自助化的资源服务, 用户无需同提供商交互就可自动得到自助的计算资源能力。同时云系统为客户提供一定的应用服务目录, 客户可采用自助方式选择满足自身需求的服务项目和内容。
(3) 以网络为中心———云计算的组件和整体构架由网络连接在一起并存在于网络中, 同时通过网络向用户提供服务。而客户可借助不同的终端设备, 通过标准的应用实现对网络的访问, 从而使得云计算的服务无处不在。
(4) 服务可计量化。在提供云服务过程中, 针对客户不同的服务类型, 通过计量的方法来自动控制和优化资源配置。即资源的使用可被监测和控制, 是一种即付即用的服务模式。
(5) 资源的池化和透明化———对云服务的提供者而言, 各种底层资源 (计算、储存、网络、资源逻辑等) 的异构性 (如果存在某种异构性) 被屏蔽, 边界被打破, 所有的资源可以被统一管理和调度, 成为所谓的“资源池”, 从而为用户提供按需服务;对用户而言, 这些资源是透明的、无限大的, 用户无需了解内部结构, 只关心自己的需求是否得到满足即可。
4 结语
不同种类的操作系统、应用软件、系统软件和应用基础结构 (application infrastructure) 相互交织, 这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程 (business processes) , 因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化作出快速反应, 利用对现有的应用程序和应用基础结构 (application infrastructure) 的投资来解决新的业务需求, 为客户、商业伙伴以及供应商提供新的互动渠道, 并呈现一个可以支持有机业务 (organic business) 的构架。SOA凭借其松耦合的特性, 以及云计算强大的资源可灵活配置能力, 使得企业可以按照模块化的方式来添加新服务或更新升级现有服务, 以解决新的业务需要, 并通过不同的渠道提供服务, 从而保护了现有的IT基础建设投资。所以, SOA与云计算相结合的体系架构是业务应用集成的最佳实践平台。
参考文献
[1]郝兴伟.Web技术导论[M].第3版.北京:清华大学出版社, 2012.
[2]卢致杰.SOA体系设计方法研究[J].工业工程, 2004, 7 (6) .
[3]魏东.基于SOA体系结构的软件开发方法研究[J].微电子学与计算机, 2005, 22 (6) .
[4]雷万云.云计算企业信息化建设策略与实践[M].北京:清华大学出版社, 2011.
集成架构 篇2
【关键词】面对服务架构消息中间件，业务流程系统的集成方法
【中图分类号】G29【文献标识码】A【文章编号】1672-5158（2013）07-0480-01
一、前言
依据企业信息化发展的阶段模式理论来说，企业在信息化的发展共有四个阶段。其中，引入阶段中，企业会运用一定的信息技术使得在企业内部的一些职能的部门能够将业务的流程实现自动化，当今很多的企业都已完成了这一阶段。集成阶段中，企业会在内部的职能部门间进行系统集成框架的建立和数据管理系统的统一，同时，也需要将计算机的软件系统实现在内部中的集成及综合的利用。这个阶段中，中间件的技术也产生了。在这种技术中最为重要的中间件是消息中间件，它具备跨平台，扩展性好及负载平衡的优点。消息中间件和面向服务架构之间的融合成为中间件技术的一种发展趋势。这样企业就可以及时并方便的对业务进行调整，对流程进行重组。流程的变革阶段中，企业与供应商和分销商这些工作伙伴通过信息和网络的技术使得资源和数据得到共享和整合。现在对于信息技术的运用较为成熟的企业有的完成了流程变革的阶段有的正处于这一阶段，在此之后将会进入战略变革的阶段。
二、 面向服务构架消息中间件
1996年，面向服务架构的概念被提出。它是一种在对象构件的计算模型的基础之上，把不同功能的单元用之前定义好的接口、契约联系起来，从而实现程序和服务上的重复利用的新型体系架构。面向服务架构包括三方面。其中，服务提供者是在根据网络导址这一实体来接受并且执行服务的使用者的要求。服务提供者从根本上来说是一种应用程序或者是软件快，它通过接口和契约来运行。服务注册中心是在服务中发现并支持，它来使得服务提供者找到服务使用者的接口。当下最为普遍的面向服务架构的技术叫做Web Service，这种技术的服务注册中心是通过描述并发现、集成来保存服务的注册的信息，利用简单对象的访问协议消息来达到服务的绑定及调用。中间件系统可以在不同的平台之间实现通信，从而达到在分布式的系统间可靠并且高效率的跨平台的数据传输工作。并且具有屏蔽在各种平台及协议间的性质，从而达到各种应用程序间的协同。现在，最为普遍的消息中间件是由消息服务器和数据的储存库及命名和目录的文档等等组合而成的，同时，采用了客户端和消息服务器这两层架构。其中，消息的服务器可以接收消息和发送消息，它根据查询命名和目录文档来获取每个消息服务器和消息对列等等的信息，这时数据的存储库将会用来保存通信中重要的数据。消息中间件的用户会使用应用程序接口技术来通过消息服务器进行发送消息和接收消息，达到企业的数据集成。近些年来，消息中间件技术发展非常迅速，它的研究的热点及关键的技术包括了系统的架构、负载平衡的技术及计算机的集群技术。在标准及规范上并没有得到统一，因此这种应用是不可以移植的。不同的消息中间件技术也是不能进行相互的操作。当下，消息中间件技术在中间件技术中依然是研究的热点。消息中间件最传统的采用的为客户及消息服务器上网架构，但是通过一系列的设计得到了一种客户、客户端和消息服务器的具有三层架构的消息中间件。其中，消息客户端是一种应用程序用来接受和发送消息。并且在发送端的用户和接收端的用户在使用同一个消息客户端时，它会从用户接受到的消息来直接的转发给那些接收消息的用户。这样的集成构架和转发消息的机制在一定程度上减少了消息服务器进行不必要的作业，同时大大提高了服务器对消息的发送效率。同时，消息服务器也可以使得在不同的计算机的消息客户端间进行消息的转发。面向服务架构的消息中间件是将web服务作为消息中间件的主要功能。并依照面向服务构架的标准在网络上发布，使得用户更方便使用。
三、 业务流程系统的集成方法
消息中间件于面向服务系统架构相结合，这样就产生了一种业务的集成方法。这种业务的集成方法的效率即重用性较高，还具有跨平台的优点。并且它采用了三层的系统架构，依次为服务层，逻辑的实现层及资源管理器。其中服务层是为用户直接的提供发送、接受或者转发的服务。发送和接受这两种服务是对于用户来说是开放的，但转发这种服务不对用户进行开放。消息中间件的功能想要充分的发挥靠的是逻辑实现层和资源管理器的运行。集成服务层的功能的逻辑上的实现靠的是逻辑实现层，它是由消息的客户端、服务器群和命名及数据的储存文件组合而成的。在多台计算机上部署消息客户端及消息服务器，这样就达到了消息中间件的集群的配置，并且在服务器端用负载平衡的算法以达到消息服务器及客户端两者的负载平衡。资源管理器有着发送接收消息、打开关闭消息的客户端或者服务器的功能。
四、 结束语
消息中间件技术作为一种有可靠的信息系统的集成技术，已在企业的信息系统的建设当中被普遍的使用。它在内部的跨平台的数据传输中具有很高的效率。当然，到了企业的信息化步入流程的变革阶段的时候，信息中间件技术会从传统技术转变为面向服务架构的技术。使之更能够适应高效快速的企业的业务流程，更加接近当代企业的需求。同样这种方法，为企业在信息系统的实施过程中及业务流程的集成中提供了一种新的方案。
参考文献
[1] 汪淼军，张维迎，周黎安.信息技术、组织变革与生产绩效——关于企业信息化阶段性互补机制的实证研究[J].经济研究，2006年01期
[2] 陈宏，曹健，旻梁.分布异构环境下的数据集成方法及应用[J].计算机工程，2005年05期
基于混合架构的医院综合集成系统 篇3
我国医疗信息化的建设起于20世纪70年代, 大致分4个阶段[1]:20世纪70~80年代的单机单用户阶段, 此阶段的特征是程序以单机单用户为特征, 服务器以小型机为主, 慢慢过渡到苹果PC;20世纪80年代中期的科室级应用, 此阶段系统实现了局域网内的互联互通, 如住院管理、门诊计价收费系统等, 此时C/S架构慢慢进入视野;20世纪90年代的全院级应用阶段, 此阶段中快速以太网和大型关系数据库日益成熟, 完整的全院级医院管理系统, C/S架构成为主流;21世纪计算机技术进入新的发展纪元[2], 新技术不断为医疗信息化的发展注入新的动力。随着医院规模的快速扩大, 区域医疗逐步进入视野, 特别是近年来全国居民健康档案系统的发展、医疗云系统的探索、远程会诊的应用, 同时由于服务器软硬件水平的提升, B/S架构的医院信息系统 (HIS) 开始慢慢步入主流。
2 我院的信息化建设历程
我院信息化的发展史是中国县级医院信息化建设的一个很好缩影。我院的信息化起始于20世纪90年代中期, 主要以单机单用户为主。随着医院的逐步发展和壮大, 新医院HIS的上线, 实现了科室级的联网, 使得我院的信息化水平, 在同级医院中走在了前列。
然而2008年5·12大地震, 使得大家的辛苦付之东流, 医院也成了一片废墟。但医院以重建为契机, 再次引入全院级的HIS、检验信息系统 (LIS) 、影像存储与传输系统 (PACS) 等, 使得我院的信息化水平进一步提升。
经过地震后3年的发展, 我院的业务量快速上涨, 计算机终端的数量也从初期的100台升至700台左右, 而信息科的人员数量变化不大, 因此每个工作人员都处于超负荷工作状态。HIS的C/S架构的缺点开始暴露:人员维护成本高、终端分布广、升级麻烦, 使得信息科人员疲于奔命, 严重影响了医院各科室的业务发展, 运维效率的提高成为了我们要考虑的重点[3,4]。
医院信息系统中的诸多子系统中, 既有我院自主研发的, 又有第三方软件公司安装的, 且大部分都采用C/S架构, 出现了很多信息孤岛和信息烟囱。为了解决这些问题, 我们设计了一个通用的前台加载器, 将应用程序本身以大对象的方式存入数据库, 用时动态加载。使用了一段时间后, 发现效果并不理想, 主要是360等杀毒软件会进行拦截, 导致加载或升级失败。后来我们采用纯B/S架构, 维护和部署方便了, 但系统反应迟钝, 有时莫名其妙地卡死, 再次登录后先前的工作全部丢失, 又要重新再来。尽管做了特别的优化, 但在医院海量的信息量面前系统响应仍然不及时。特别是一次后台Web服务器故障, 导致前台系统全部瘫痪, 严重影响了业务的正常运转。我们不得不又将相应的应用系统改回C/S, 于是又陷入了先前的恶性循环。
后来我们发现以IE为运行媒介的ACTIVEX架构[5], 不失C/S的速度响应, 也具有B/S的免安装维护, 应用此架构对系统再次进行改造, 取得了一定效果。但由于HIS的特点, 经常都会有新的需求出现, 而每次软件升级后, 插件需要重新安装, 业务科室的人员对具体的业务很精通, 而对计算机相对陌生。软件的升级维护和部署问题制约了我院信息化的进一步发展。
在吸取先前的经验教训, 在上级领导的关心帮助下, 在全科人员的努力下, 经过摸索和研究, 我院的医院综合集成系统[6]出炉, 其既有C/S架构响应时间短、反应速度快的优点, 又结合了B/S架构的免安装、零维护的长处。同时将不同的子系统无缝集成在一起, 既方便了信息科人员的安装和维护, 也方便了全院各科室的使用, 这种混合架构比C/S和B/S更先进[5]。
3 混合结构的实现
3.1 技术原理
根据应用场景, 该架构将业务系统分为2类。对运行速度、响应时间要求严格的系统, 在实现时, 改造为类DLL (Dynamic Link Library, 动态链接库) , 其运行时以IE为媒介, 通过通用的ACTIVEX加载插件进行。这样只要通用的加载插件平台功能不变, 具体的业务系统再变化, 用户使用同样便利, 不需要安装加载插件。而第三方的通用加载插件多种多样, 技术上已经成熟, 国内比较知名的有cbx和WebXone, 我院采用后者。而对于响应时间运行速度要求不严格的系统, 采用传统的B/S架构, 而开发B/S的系统工具有很多选择, 如PHP、ASP等。不管哪种架构, 对用户来说, 就像访问普通的Web应用一样, 唯一的区别是完成的具体业务流程不同, 但响应时间和传统C/S程序一样快。
3.2 系统架构图
混合架构的体系结构, 见图1。
结构说明:由于我院使用的院内即时通讯软件系统ActiveMessenger (AM) 覆盖全院, 而该软件在功能上支持第三方的动态链接, 因此我们将医院综合集成系统链接其中, 全院各科室就像使用QQ一样, 在医院综合集成系统中就可以启动各个子业务系统[7]。
由于AM系统后台使用的是SQL2000数据库, 其用户验证模式为服务器和主机的混合认证, 如果采用二层结构, 需要各科室的主机用户和密码与服务器保持一致, 这样既不安全也不现实。因此我们采用了三层结构。在实际应用中, 三层架构还可保证医护人员不在医院也能进行相应的远程办公。
初次登陆综合业务平台时, 首先会获取当前登陆AM软件用户的工号, 进而动态获取次工号对应的全新视图。通过模块的动态添加和权限的动态设置, 能在后台统一设定前台的用户权限视图, 带来了极大的方便和灵活, 同时由于AM软件的全覆盖, 基本做到了新系统上线的零安装和免维护。
3.3 核心技术
以IE为运行媒介, 以第三方activeX加载插件为基础, 通过软件的DLL改造, 同时使用极具灵活性的三层架构技术, 使得我院综合集成系统的架构体系充分综合了C/S架构和B/S架构免安装、零维护、响应速度快的特点, 同时不会因为单点故障导致整个系统的瘫痪, 动态的适应局域网和广域网。
4 应用效果
医院综合集成系统的成功上线和运行, 使得信息科人员从原有的繁琐工作中解放出来, 能有时间研究新技术, 以便更好地应用于医院信息化[6];医院各科室对信息科的满意度直线上升;系统稳定、好用, 提高了医护人员的工作效率;出现问题能及时处理, 信息科人员的工作压力大大减轻, 实现了运维效率的提升。
我院综合集成系统的成功运行, 为医院今后的信息化建设积累了宝贵的经验, 同时也对医院信息化建设中的信息孤岛和信息烟囱提供了一个解决办法[8]。我们深知, 医院的信息化建设不是毕其功于一役的, 而是一个艰苦而长期的过程, 在今后的工作中还要不断总结经验、不断改进, 使我院的信息化建设跟上医院发展的需要。
参考文献
[1]华永良.试谈中国医院信息化事业发展的激励因素和历经阶段[J].中国数字医学, 2013, 8 (1) :79-86.
[2]吴飚, 彭梦晶.中小医院信息化建设现状和发展趋势[J].中国医疗设备, 2010, 25 (6) :90-92.
[3]王志强.医院信息化建设面临的问题与对策[J].中国数字医学, 2007, 2 (12) :31-32, 35.
[4]言卓.我国医院信息化建设过程中存在问题与应对策略的探讨[J].实用预防医学, 2011, (10) :2022, 2018.
[5]李玉杰, 熊文举, 姜浩娜.基于SOA架构的医院信息系统集成[J].中国数字医学, 2008, (8) :54-56.
[6]许健, 查佳凌, 尤超, 等.医疗信息化集成平台在医院的建设与思考[J].中国医院, 2012, 16 (2) :5-8.
[7]陈功, 沈宫建, 于洁.医院系统集成平台建设内容和方法[J].中国数字医学, 2008, 3 (10) :58-60.
集成架构 篇4
随着校园信息化应用的不断深入,学校内部各系统之间数据信息需要交互才可以很好的配置各部门的工作,但由于历史和现实的原因,目前很多信息系统是异构系统,基于不同的软件和硬件平台,数据格式也不统一,信息缺乏有效共享,应用缺乏有效集成。这种现象不但导致了重复建设、资金浪费严重,还给教学、科研和管理带来了极大的麻烦,“信息孤岛”、新旧信息资源的衔接、历史信息的有效利用、当前不同系统之间的通信、目前已开发的系统与今后将要开发的系统的连接等一系列问题都需要进行科学的分析,校园信息的整合集成已成为目前工作的重点。
2 基于面向服务架构的校园信息集成设计
在实现跨平台数据共享和集成的过程中,要充分考虑到如何尊重历史和现实,保护以往的硬件和软件投资,保证各项工作的连续性;考虑到如何在用户需求改变时,系统功能仍能方便地进行扩展。下面从数据集成、服务集成、流程集成三个方面来具体论述基于面向服务架构的校园信息集成设计,设计架构如图1所示。
2.1 数据集成
学校现有的各类系统中积累了很多原始数据,而数据对于学校来说是至关重要的,无论是招生就业、学籍毕业、教学评定,还是统计分析,一切与日常业务相关的处理都是基于这些基础数据。因此,要做好各类数据的整合共享,在全校信息模型和数据集成的基础上,构建一个合理的数据存储模式,使学校各个应用系统具有合理的数据分布并满足各个应用系统之间的数据交换需求,并为服务集成和流程集成的构建打下基础[1]。从应用的角度可以将结构化数据分为私有数据、部门交换数据、公共数据,实施中要定义具体的数据库、帐号、访问方式、数据映射关系等,兼顾到已有的应用及数据。根据数据集成的要求,考虑到各校信息化建设现状,在结构上,数据中心和其他应用系统是松散耦合的关系,即数据中心的运行不会影响其他系统的运行,同时,某个具体应用系统的运行也不会影响数据中心的正常工作。
2.2 服务集成
目前,很多学校建有专门的邮件系统、OA系统,各职能部门的业务系统,且路径不一、使用繁杂。为给所有用户提供简捷方便的服务,需要倡导一种面向服务的管理,即从学校各部门提供的服务的角度来管理相关的系统,通过对业务层的抽象,给用户一个统一的完整的服务集成,服务集成通过统一信息门户系统实现,其中门户技术、单点登录是构建统一信息门户的重要技术。在Web服务的开发架构之下利用Web服务提供的应用集成中间件,可以与应用业务层相对独立,连通现有的、新建的和将来要建设的各种应用系统。通过整合各种应用系统,用户能够利用统一的界面访问多个应用系统及其信息资源系统和信息资源库。对于那些已无法满足业务新发展的要求但是各部门在前期投入了大量人力和财力且有部分功能仍能使用的遗留系统也可以采用Web服务技术,通过分析遗留系统、根据增值服务定义Web服务功能、实现并发布Web服务、业务移植等步骤来完成。
2.3 流程集成
流程既体现在现有流程的实现上,又体现在校园业务流程的重组上,流程集成是集成的最高阶段,即利用工作流、消息、协同等技术,建立全局的学校业务流程集成。面向服务的架构是流程整合的基础架构,它是一个组件模型,将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来,通过Web服务的技术实现流程集成。面向服务的架构以用户为中心,完全按照用户的需求整合相关的组件资源,当某些提供服务的业务系统发生变化时,不会影响到使用服务的其他业务系统的正确运行。而且新的流程需求产生以后,或者学校业务流程发生了改变,事前的充分设计和各类机制的存在就成了积极的保障,使学校可以适应不断变化的需求。
3 基于面向服务架构的校园信息集成解决方案
校园信息集成的实现是一个复杂的系统工程,它牵涉很多的思想和技术的应用,其中异构信息集成和系统快速重构是两个难题,而面向服务架构和Web服务则是解决这两个问题的关键技术。
3.1 相关技术
面向服务架构(service-oriented architecture,SOA)同以往的C/S或B/S结构相比,最大特点就是有一个灵活且功能性很强的服务层,随着业务流程的改变,可以快速的重构系统[2]。服务是整个SOA实现的核心,遵循SOA观点的系统必须要有服务,这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的,并且可以通过网络查找其地址[3]。
SOA是Web服务的架构。换言之,Web服务实现了面向服务的架构。采用Web服务实现SOA能充分发挥它的服务组件重用性、异构平台的信息集成性,并且由于Web Services通信的简单性使得SOA的实现变得更加容易。因此,由于面向服务的架构思想和Web服务技术的引入,能满足校园信息集成敏捷性、动态性、松耦合、跨平台的要求,是构建校园信息集成的最佳选择。Web服务的架构平台主要有两个:Microsoft.NET平台和J2EE平台。J2EE的Web服务实现一般是通过EJB实现,或把提供Web服务实现的Java应用独立出来;.NET框架中Web服务的实现一般通过.NET Managed Component来实现。
3.2 解决方案
构建校内私有UDDI注册中心,建立内部Web服务项目的索引,这有助于学校内部各部门之间更好地沟通,更好地归类各部门提供的各项服务,并在学校内部使用彼此提供的服务[4]。校内各部门根据学校信息集成方案规划及时提供各类Web服务接口,并通过集成系统统一接口程序中的Web服务注册功能向学校信息中心的私有UDDI注册中心注册。学校信息中心可以根据各部门提供的Web服务、信息集成方案规划,及时更新集成系统统一接口程序。
对于校园信息集成而言,由于原有的各类系统分别采用不同开发工具进行C/S或者B/S模式开发,如果直接采用SSO(Single Sign-On)系统进行改造,则原有应用系统用户认证的设计必须符合其规范,这对已经处于运行期的多个应用系统来说不仅难以实现,而且也会带来很大开销。更多情况下,是采用建立统一的认证中心系统,配合对原有系统认证部分稍作修改,同时由于Web服务是跨平台的,所以也十分适用于实现SSO的服务,可以在学校信息中心提供全校统一的身份认证Web服务(包括用户注册接口、用户认证接口),它是实现校园信息集成的关键。
3.3 实例分析
整个SOA数字化校园的部署及运行体系如图2所示,下面来逐一描述:
1)用户在浏览器界面发出请求,这个请求被发送给运行在服务器中的校园信息集成门户,通过统一接口程序后成功登录系统,并建立合法的会话;
2)门户应用得到由应用服务器提供的Web服务的技术信息,这些技术信息是通过搜索私有UDDI注册中心从而获得的;
3)针对指定Web服务的WSDL(Web服务Description Language,Web服务描述语言)绑定信息作为基于SOAP(Simple Objec Access Protocol,简单对象访问协议)的消息被传递到了门户系统;
4)门户系统调用由应用服务器提供的Web服务,在调用的时候,信息被作为SOAP消息的一部分传入;
5)特定的Web服务的具体实现是由运行在某个应用服务器上的EJB或.NET Managed Component来提供(取决于内部的体系架构),并获得数据中心的数据;
6)这个Web服务响应同样是以SOAP消息的形式出现,同时这个SOAP消息被发送回门户系统;
7)针对最初请求的响应被格式化为XML/XSLT/HTML的形式回传给基于浏览器的客户前端。
该体系的特点是:(1)由Web Services提供统一的对外接口和数据传送等服务;(2)用Web Services实现内部管理系统的封装,这样就屏蔽了分布式系统间的各个异构环境,包括硬件、软件、开发和部署平台等的不同,调用者只需知道调用接口,即可方便地实现各种功能的调用,而无需处理异构环境下复杂的通信细节;(3)使用具有自描述特性XML作为消息传递的标准格式,使用一致的XML Schema作为信息交换的标准结构,实现了异构系统的信息交换和互连;(4)基于SOAP和Web Services,实现了各个分布式系统间的跨平台交互,各个子系统是分散耦合的,这样就克服了传统的紧密耦合的分布式系统的缺点,达到了良好的可扩展性,可以满足灵活多变的业务逻辑需求;(5)系统各个部分之间交互的都是XML数据,使得数据的内容和显示实现了分离,这样用户可以对数据进行灵活的处理和个性化动态显示。
4 结束语
本文提出了基于Web服务的解决方案来进行校园信息集成研究,从使用XML/SOAP进行通讯,使用WSDL进行服务发布,使用UDDI进行服务资源共享,到全面应用面向服务思想进行整体规划,体现了通过Web服务进行资源共享、消除信息孤岛的特征和可行性。
参考文献
[1]祝伟华,杨丹,桑军,等.数字化校园设计与构建方法研究[J].计算机科学,2005(8):97-99.
[2]吴家菊,刘刚,席传裕,等.基于面向服务架构的敏捷供应链信息集成研究[J].计算机工程与设计,2006(19):3545-3547.
[3]李银胜.IBM精品课程Web服务及其应用[R].IBM公司,2006.
集成架构 篇5
关键词：基于SOA架构,油田电网数据,集成,方案设计
引言
随着现阶段人们需求的提升, 各行业间对于电力的需求日益增加, 随着电网行业的日益发展, 采用传统的处理方式进行数据集成已无法实现, 应考虑到整体结构, 从而实现油田电网数据集成工作。我国油田在勘探开发过程中, 对于油田电网系统的开发具有一定的成效, 但是在具体的数据集成方面具有一定的问题, 系统与技术形式具有一定的差异, 鉴于此, 实施基于SOA架构的油田电网数据集成势在必行。
一、SOA架构概述
SOA架构是一个简单的组件模型, 能够将应用程序的不同功能体现出来。在这个架构当中, 其接口是采用中立的方式进行的, 对于该方式具有一定的定义, 在具体的实施过程中, 能够有效的实现独立服务。其在服务的过程中能够将硬件平台、操作系统以及所需要的编程语言进行系统的整合, 从而实现信息的交互[1]。通过这种架构的建立, 能够有效地解决集成油田电网各类数据的分析, 对于运行管理当中的数据能够清晰地分析出来, 从而实现有效的管理工作, 提升企业在生产过程中的经济效益, 促进企业发展。
二、基于SOA架构的油田电网数据集成方案设计
基于SOA架构的油田电网数据集成方案设计主要包括两个方面:首先, 要完善平台功能体系的建立。依据现阶段的油田电网企业来说, 其在进行电网数据集成过程中, 将具体的功能进行了有效的划分, 比如, 发电侧的管理、输电侧的管理、售电侧的管理以及智能决策的有效管理形式等等, 不同形式的功能, 采用的技术形式不同, 所以在设计当中体现架构的针对性特征;其次, 平台架构技术的实施。将功能经过剖析以后, 要有针对性的将架构平台进行技术支撑, 通过有效的技术形式实现油田电网数据集成[2]。油田电力系统具有一定的资源, 如EPR系统、Gis系统、综自系统以及应急系统等等, 组件层通过向各个组件进行封装底层实现技术支撑, 而服务层则是通过组件的不同功能实现技术支撑, 表示层能够将有效的服务提供给专业的技术人员, 以此来实现信息的整个通过数据分析进行有效管理, 完善的管理能够促进企业得到更好的发展。
三、基于SOA架构的油田电网数据集成的运用
基于SOA架构的油田电网数据集成的运用主要体现在以下几个方面:首先, 能够有效地运用到平台数据环境当中。数据服务是在油田电网数据集成的基础上形成的, 通过信息资源的有效规划与运用, 将合理的数据环境呈现出来, 在相关的电力企业当中能够进行有效的应用, 通过运用可以发挥其具体的作用;其次, 在运用方面还可以实现数据资源的有效盘点工作。油田电网数据是比较复杂的, 依据这种复杂的数据进行有效的集成, 需要一定的手段, 而基于SOA架构的形式, 是最为有效的, 其能够确定现有数据, 通过对现有数据进行分析与系统访问, 能够了解支撑该数据的初始数据心事, 从而进行整合与规范, 为企业数据管理提供依据;最后, 实现开发与集成, 可以促进企业效益的提升。该结构采用的是对服务数据对象进行统一扫描的方式, 将扫描的对象进行分析, 从而得出有效的结论, 而扫描对象的种类是多样化的, 如, 数据源信息、数据对象信息、属性等等。该模式建成以后, 对于企业来说具有一定的优势, 能够有效的发挥自身作用, 提高生产质量, 从而促进企业的经济效益的提升。
结束语
对于油田电网企业而言, SOA不仅能够实现企业在处理业务时, 对业务信息进行整合, 还能有效的融合企业经营当中的各项业务, 从而实现企业资源的重组与扩展, 形成更有效的集成架构形式。通过本文的研究, 可以充分的了解SOA架构的形式, 整合各类电网企业的报表, 集成油田电网企业的数据等等, 通过技术方案的设计以及具有运用方法的呈现, 呈现出建成后在企业生产中发挥的作用以及产生的效益。
参考文献
[1]丘裕新.基于SOA架构的电网企业信息系统集成的研究与应用[J].电子技术与软件工程, 2014, 02 (18) :204.
集成架构 篇6
企业应用集成 (EAI) , 是采用一定的方法和工具实现的、组织内部各应用系统之间的集成。EAI通常的应用范围是单一组织的内部, 以区别于跨组织的B2B集成;其次EAI的集成对象是多个应用系统中的数据接口或流程接口, 而非通常属于IT基础设施的系统软件和工具软件;同时EAI拥有一系列专用的方法和工具。
在企业信息化发展初期, 各种不同运行平台、不同架构的信息系统被部署在不同的业务领域, 大量关键业务信息被封闭在这些相互独立的系统中, 随着信息化应用的逐步深入, 一个解决方案形成一个“烟囱”或“孤岛”, 多种异构系统共存几乎是普遍现象, 从而在企业内部产生了进行应用集成的需求, EAI技术随之产生。
EAI技术的产生和发展基本属IT技术驱动、定位于异构环境下多数据源、各种遗留系统间的整合, 侧重于从技术角度去解决信息孤岛问题。
2 SOA
2.1 SOA概念
SOA的概念最早由Gartner公司在1996年提出, 但由于当时的技术水平和市场环境尚不具备实施SOA的条件, 并未受到广泛关注。随着Web服务技术的兴起与组件技术的成熟, 为SOA的研究与发展提供了新契机。SOA逐渐成为近2年信息技术领域最热的话题之一, 但对于什么是SOA, 人们有各种不同的说法。
有人说SOA是一种架构模型, 它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用;还有人把SOA定义为一种IT战略, 它将企业应用中的分散的功能封装成可以共享的基于标准的服务, 这些服务能够迅速地被组合和重用, 以满足业务的需求;多数人则认为SOA是一种应用框架, 它将业务应用划分为单独的业务功能和流程, 即所谓的服务, SOA使用户可以构建、部署和整合这些服务而无需依赖其运行计算平台, 从而提高业务流程的灵活性。
OASIS提出了一个更高层次的定义, SOA是对分布的甚至是跨职能域的一系列功能进行组织和利用的模式, 它提供统一的方法去定义、发现、组合并利用这些功能, 以产生与事先期望及前提相一致的结果。显然OASIS的定义超越了IT领域的范畴, 但也许这才是关于SOA最科学的定义。由此可以发现, SOA的概念和模型适用于任何一种生产者/消费者的组合环境, 包括业务领域和信息技术领域。
2.2 SOA特征和优势
虽然IT界在SOA的定义上存在很多不同角度的尝试, 但对于SOA的以下基本特征还是存在相当程度的共识。
首先, SOA应当具有松耦合、可重用、粗颗粒度、可配置、模块化/组件化和协同工作等特点;其次, SOA必须遵循一系列的标准, 无论是通用标准还是工业标准;再次, 服务应当具有可识别、可编目、可精确定义、可交付、可监控、可跟踪等特点。
由于SOA的以上特点, 显然将会带来以下两大好处。
一方面, SOA将带来更高的灵活性和可扩展性。SOA的灵活性体现在它将业务流程和相关的IT基础设施中的元素看作安全的、标准化的组件 (服务) , 通过对这些组件 (服务) 进行重用和组合, 即可应对不断变化的业务目标和业务优先级。SOA的可扩展性是面向未来的业务系统的, 由于架构的松耦合特性, 可以通过增加少量服务, 以配置的方式在不影响现有应用的前提下, 快速生成新的复合应用。同时这也意味着, 在完成SOA框架的建设后, 现有应用可以逐个改造纳入SOA体系。
另一方面, SOA可以从整体上提高信息化投资的回报率。由于实施SOA后主要的业务作业及IT底层操作被封装为公共服务和共享服务, 这些服务被大量重用在不同的业务应用场景中, 业务应用功能的实现将更多地由开发转为装配, 特别是企业级流程的定义将完全在流程引擎上通过配置而实现, 从而大大降低了在购置或开发应用软件时对相同功能的重复投资, 而且由于松耦合的特点, 大型软件也将变得易于调试。当然由于SOA需要更好的IT治理环境, 从而会导致运维成本的上升, 但如果考虑到企业由此而获得在竞争激烈的市场环境中获得快速应变的能力, 即所谓的业务灵活性, 显然企业管理者将更愿意把资金投向相关的信息化项目。
3 EAI与SOA实施案例分析
3.1 采用EAI方式实现电力营销与财务系统集成
2004年, 江苏电力在与埃森哲公司合作过程中, 对信息系统建设状况进行了评估, 发现原有营销系统与财务系统之间缺乏数据交互, 导致财务不能及时获取准确的应收账款和实收账款的有关信息。鉴于当时财务与营销系统均建成不久且运行稳定, 决定在对原有系统不进行大改动的前提下进行应收与实收账务信息的集成。
该项目于2004年2月启动, 首先进行了需求分析, 明确了7个集成功能点和相关处理流程。在此基础上进行了平台技术选型, 选择了IBM公司的Message Queue和Message Broker作为EAI集成平台, 形成了基于消息传输的HUB式架构, 开发了营销和财务系统与MQ的数据处理接口, 并在Message Broker上通过编程完成了流程定义。同时为便于管理, 通过中间件提供的接口开发了所有流程的监控与管理工具, 可以对信息传递的情况进行实施监控和异常处理。整个开发过程历时5个月, 在试运行半年后在江苏电力13个地市供电公司进行了推广实施。
该项目具有典型的EAI特点, 主要以IT技术为主导, 原有系统基本保持不变, 业务流程基本保持不变, 通过中间件实现了一定程度的松耦合, 可以通过在中间件上的编程进行集成逻辑的调整, 项目周期短。但是技术方案完全基于IBM的特定产品及专有技术。
3.2 采用SOA理念建成信息化应用集成平台
2005年, 江苏电力做出了企业管理向集团化、集约化、精细化、扁平化转变的重大决策。为适应由此带来的管理流程的变化, 江苏电力在信息化“十一五”规划中提出了全面实施SOA的信息化战略。经过认真细致的产品评估选型, 江苏电力选择了BEA作为SOA实施合作伙伴, 基于WEBLOGIC系列产品完成了SOA框架的设计, 并完成了服务总线、服务目录 (服务库) 、流程引擎、流程监控平台的开发部署。同时, 江苏电力确定将35 k V以上电网建设项目的全过程管理为首期实施目标, 组织各有关业务部门的骨干人员进行了数月的流程分析与优化设计。
经过一年多的努力工作, 项目各方初步完成了发展规划、工程、财务、物资、招投标等应用系统在SOA框架下的服务化改造, 并对其他相关系统进行了必要的改造, 实现了一批符合规范的业务服务, 完成了单点登录、统一认证、统一编码等一批公共服务的部署。在此基础上, 通过在流程引擎 (BPM) 上的配置, 较容易的实现了各业务应用的跨部门横向集成, 即企业级业务流程的集成和整合, 基本实现企业信息共享、流程互通和门户集成目标。
从江苏电力SOA一期建设的历程看, SOA项目从决策时起就是一个企业级的项目, 是企业信息化为适应业务管理变化而做出的响应, 业务流程进行了相当程度的调整, 所有相关系统的流程都经过了彻底的分析和改造。项目前期的设计和开发工作相当繁重, 而后期的配置部署则相对容易, 对流程变化的适应性尤为突出。
4 EAI与SOA的区别
由以上案例可以看出, EAI与SOA在项目实施过程中存在如下差异。
4.1 驱动力的差异
EAI主要是从信息技术角度出发去解决应用之间的接口互通问题, EAI的发展也是完全由信息技术发展来推动的。而SOA的理念远远超越了信息技术的范畴, 它首先需要业务应用经过标准化、服务化改造, 面向应用。或者说SOA应该是业务应用驱动的而不是技术驱动的。
这样的说法比较表面, 具体驱动力的差异落实到实施上体现在实施分析对象上的差异。EAI的分析对象是中间件和接口, 主要把中间件的功能实现要求分析清楚, 梳理集成接口技术和数据细节, 采用中间件的功能管理这些原模型和元数据。SOA的分析对象是业务应用“服务”, 分析的立足点是企业业务应用整体。先是建立企业业务应用的构架和模型, 然后分析现有业务应用系统与应用架构和模型的差距, 再分析跨系统应用需求, 也就是梳理应用集成整体需求, 然后建立应用目标模块视图, 定义模块功能, 在采用标准的中间件技术封装模块, 定义服务, 建立服务契约。另外中间件的技术功能通过一个SOA目标架构设计确定部件之间的功能界面, 把各个部件“工具化”, 无法实现工具化的功能尽量设计成面向“应用”的配置模板。通过多层模型把中间件功能“标准化、工具化”, 同时把这些工具通过定制的方法完整、整体地管理起来 (目前的中间件产品尚没有面向应用的管理功能) 。
对于分布式的业务应用, 事实上如果没有业务流程管理 (BPM) 工具的部署配合, SOA实施后的成效就会降低, 跨层级的流程互通实施就比较困难。
4.2 实现方式的差异
EAI的核心是通过接口之间的消息转换, 完成集成。EAI并不倾向于对传统的应用系统进行彻底的改造, 而往往是通过在原系统上附加接口的方式实现集成。应用系统依然保持其固有边界和内部处理逻辑, 在EAI实施中, 应用系统内部的处理过程往往被忽略, 集成工作所关注的主要是接口部分。而SOA则提供了一个统一的框架, 并将每个应用系统拆分为若干服务纳入这一框架中, 通过定义方式把这些服务动态地组成应用, 原应用系统的边界将被打破或调整, 所有的应用被融合为一个整体, 因此SOA的实现是经过一个破而后立的过程, 在“破”和“立”的过程中逐步完成面向服务的架构。如果把应用系统比喻成大石块, EAI是把这些石块直接砌成墙, 而SOA则是把石块按照一定的规则雕琢、切割, 有些“服务”需要打碎做成混凝土灌注“公共服务”, 然后砌成墙。这一差异是面向服务的架构 (SOA) 和面向服务的集成 (SOI) 之间集成实施策略和工作思路上的区别
EAI和SOA在实现对业务流程的实现方式上也迥然不同。EAI本身不定义业务流程, 而是由各个应用系统去实现流程, 再把这些流程以消息传递的方式衔接起来, 很难做到对流程实例的监控和管理。而SOA则可以通过业务流程引擎 (BPM) 实现流程的定义、运行和监控, 服务只是流程环节的实现, 流程不再固化在程序中, 也不再限于某个特定的应用系统, 而可以在整个企业范围内被动态地定义和执行。
4.3 实施范围的差异
从以上分析可以很容易看出两者在实施范围上的差异, EAI的主要工作是在信息技术领域, 而且工作重点主要是接口与集成所用的中间件, 而SOA是业务领域与信息技术领域同步推进, 既涉及业务流程的调整, 又要对应用系统的所有环节进行分析改造。
从企业应用横向看, EAI可以是局部性的项目, 仅限于有集成关系的应用系统, 为了实现企业不同阶段业务集成需求, 一个企业内部会有多种EAI集成方式, EAI集成缺乏整体性。而SOA从设计开始就是全局性的, 一旦实施, 企业信息化的所有方面都将被涉及, 甚至尚未存在的应用系统也将被涵盖在SOA框架之内。
从企业信息化资源纵向看, EAI主要涉及应用系统和中间件, 基本不涉及业务流程和IT基础设施, 而SOA既要实现业务与IT的融合, 又要把大量的IT基础设施作为公共服务纳入统一的框架中。
4.4 最终效果的差异
EAI相对较易实施, 见效较快, 可以完成应用系统在部分功能层面的整合, 而SOA实施难度大、周期长, 一旦成功, 企业可以获得一个灵活而强大的一体化的信息系统。EAI的实施风险比SOA小得多。但是EAI在支持和推动业务改进方面远不如SOA, 特别是在业务发生变化的情况下, EAI很难迅速完成调整, 而SOA则可以迅速满足业务变化带来的新需求, 带来了业务与IT的双重敏捷性。
5 结语
集成架构 篇7
与两级业务运营模式相适应,电信运营商构建了集团、省两级IT运营支撑系统。过去几年,面向带宽型业务、移动业务等全网性业务运营需求,电信运营商采用ESB(Enterprise Service Bus,企业服务总线)实现了两级业务系统的纵向集成,形成了全网两级运营体系。基于ESB服务总线的两级业务集成架构,改变了传统的点对点整合的蜘蛛网化的IT集成架构,一定程度上实现了业务系统的服务集成和能力整合,满足了过去业务发展的需求,但未从根本上解决省与省之间的互联互通、全网服务与数据共享、数据和应用紧耦合等问题。
2013年,国家推进电信市场向民营资本开放,移动转售的IT支撑过程表明,当前的两级IT支撑体系、通信网络分级以及省公司差异化的业务开通激活网络环境难以满足移动及固网业务转租转售、客户自助业务开通等面向移动互联网的实时服务响应需求。为此,迫切需要设计灵活、可扩展的业务集成架构,快速整合内部资源和能力,简化开发,既满足当前业务发展的需要,又能适应企业内部能力向社会开放的趋势,快速响应企业内外部客户需求。
1 集团-省两级系统集成架构现状
面向集团-省两级互联的集成架构如图1,集团/省的业务系统集成到各自的集成平台下,各集成平台负责服务的注册、发布、路由、上报等,集团集成平台同时负责全网服务的上报、下发、运营监控、消息对账等。省内业务系统间的调用通过省集成平台进行服务路由,省与集团间的业务系统通过两端业务系统所属的集成平台进行服务路由,集团集成平台实现全网服务的一点管控[1]。系统接口以Soap(Simple Object Access Protocol,简单对象访问协议)协议封装为Webservice服务注册到集成平台,服务路由信息放到Soap报头中,包含服务编码、服务请求者、消息ID、esb ID等信息,业务报文放在Soap Body中采用XML格式进行传输[2]。
2 转租转售模式下两级集成架构面临的挑战
转租转售和移动互联网对两级集成架构带来了许多不同以往的冲击和挑战:
(1)性能压力大:转租转售场景下,互联网企业在线交易峰值与平时相差10~30倍,而且互联网用户对时延的容忍度低。根据现网运营经验,每秒1 000并发以上,Soap Webservice服务每经过一条ESB总线性能损耗约为0.2秒。转租转售条件下企业内外部客户请求全部基于现有的两级ESB架构,总线负担沉重,既要提升并发量,又要降低响应时延。
(2)接口协议单一:现有的系统集成接口协议单一,对业务支撑欠灵活,面临用户多元化通信与应用需求、转售商灵活多变的业务需求和频繁的应用版本升级等,不能通过快速的服务编排组合实现需求支撑,需要临时开发接口。
(3)架构厚重:必须经过两级总线进行服务调用,未打通省与省之间的直连通道,报文数据格式采用XML格式,浪费了大量的带宽,造成了时延损耗,制约了业务的并发量。
(4)数据访问效率低:现有集成架构未实现数据集成,由服务直接操作底层数据源,如业务开通流程多个对象访问同一数据,会多次操作底层数据源,易造成数据不一致。
(5)数据共享难、数据与应用紧耦合:集团总部与省、省与省间系统众多,接口协议和数据模型和编码不一,接口交互复杂,数据共享必须经过大量的两级数据传递与格式转换,数据同步压力大,需消耗大量的系统资源;同时,数据与业务服务紧耦合,一旦底层数据发生变化,与之关联的应用必须进行调整。
3 转租转售模式下系统集成架构
为了破解两级互联架构面临的难题和保护电信资源的安全,本着资源重用的原则,设计新的系统集成架构:拓展现有的两级互联架构为全网一体化运营的对等集成架构,打通省与省之间的连接通道,并增加互联控制中心和统一访问网关。互联控制中心负责全网服务共享、服务上报与下发、全网服务运营监控、全网消息对账等,并增加一层采用统一访问网关接入的扁平化集成架构。统一访问网关从互联控制中心获取全网共享的服务信息,并管理转售商、合作伙伴、外部应用等,给外来应用分配身份ID和服务访问令牌。转租转售下的系统集成架构如图2。
转租转售商、合作伙伴等第三方企业采用扁平化集成架构经过统一访问网关接入进来。现网的业务系统沿用现有的集成模式,采用对等集成架构,后续逐步将适合对外开放、安全级别低的服务集成到扁平化集成架构中,逐步演进为统一接入的扁平化集成架构。扩充集成平台的服务封装协议,增加HTTP/JSON协议,扁平化集成架构全部采用HTTP/JSON协议服务,对等集成架构下逐步按HTTP/JSON协议接入服务,减少XML数据格式带来的网络开销。
由于在业务开通过程中,网络网元的激活能力比较单一、处理能力有限,需要集成平台实现流量控制和频度控制功能来保护后端网元的稳定运行。因此在扁平化的集成架构中仍保留一级集成平台,由集成平台实现服务流量、频度控制及消息对账等功能。转租转售商、合作伙伴等第三方系统经过统一访问网关进行身份认证并获取服务令牌,集成平台对服务令牌进行鉴权,鉴权通过后,在令牌有限期内由服务提供方集成平台进行服务路由。一次服务访问的过程中仅经过一个集成平台,如服务消费方在A省调用B省的服务时,在对等集成架构下需经过A、B两省的集成平台,扁平化集成架构下,服务调用者经过服务安全认证后可直接向B省的集成平台发起服务调用,而不必经过A省的集成平台进行服务路由,真正实现服务的一点接入、全网访问,减轻两个集成平台带来的性能损耗。业务的异常通过应用来补偿,集成平台只负责路由,不参与业务判断。
各集成平台下的业务集成架构采用服务总线与数据总线双驱动[3],服务总线对服务进行统一管理,减少系统间网状接口,提供服务的全生命周期管理和接口过程监控。数据总线对业务过程中的数据信息进行集中管理,避免各系统对过程数据的重复存储,根据信息变化进行全程管控,同时采用缓存技术将高频数据加载到内存中,提升系统性能[4,5]。业务系统的业务服务统一封装到服务总线,由数据总线实现业务服务对业务系统的数据操作,外部应用通过业务服务调用数据总线的数据操作服务来访问底层数据,从而实现数据和应用分离,如图3。
4 转租转售模式下系统集成关键技术
4.1 双服务总线
为了提升系统性能,减少两级集成架构下重量级服务总线带来的损耗及规避对电信运营商自营业务的影响,引入轻量级的服务总线作为外部服务总线,适应移动互联网时代能力开放需求,原有的服务总线当做内部服务总线,更好地实现内部资源整合和安全管控,双服务总线架构如图4。
外部系统/应用调用企业内部服务及企业内部应用调用外部服务经过外部服务总线;企业内部应用调平台服务和系统内部组件通信经由内部服务总线。两条总线相互独立,不相互嵌套和调用,各自管理各自的服务目录,同时向系统内、外部开放的服务能力在两条总线上都进行注册。
两种不同类型的服务总线都承担服务注册、服务发布和服务监控,内部服务总线还需完成异构系统的协议适配、协议转换、服务鉴权、服务访问流量控制、服务路由、服务审计等操作;外部服务总线仅负责服务鉴权、服务访问频度控制、流量控制,外部应用必须按照外部服务总线的接入标准接入。
外部服务总线和内部服务总线区别如表1。
(1) 外部服务总线设计
转售商的接口调用多是面向网元的操作,如网元查询、网元激活等,并发量大,SOAP协议比较厚重,在高并发情况下处理性能有所下降,RESTful风格的服务对数据的操作信息都封装在HTTP方法(Get、Put、Post、Delete)里,客户端对服务端数据操作信息都在URI里,而且现在互联网企业使用的大多是HTTP/JSON协议服务,因此外部总线借鉴REST架构,使用轻量级、易访问、可扩展的总线架构[6,7]。
外部服务总线结构如图5,它除掉消息端点兼容的内容,只保留服务监控、服务注册、服务鉴权、频度控制、流量控制等功能。服务消费方首先在统一访问网关进行身份认证(如图5中1、2),取得令牌后路由到服务提供方集成平台进行服务调用(如图5中3、4)。对于不需要进行流量控制和频度控制的服务,令牌有效期内首次鉴权通过后可直接进行服务访问(如图5中5),一定程度上实现消息数据和服务数据分离。
外部服务总线采用轻量化集成,不承载消息协议转换、数据格式转换和数据路由等内容,负载均衡在服务提供方实现。
(2) 内部服务总线设计
电信运营商异构系统多,接口协议多种多样,部分场景需要进行协议或数据格式转换,同时对数据安全性要求高,因此内部服务总线采用支持异构系统的ESB总线,服务封装协议保留原有的SOAP/HTTP协议,新增HTTP/JSON协议,新增服务按HTTP/JSON协议封装,减少XML多节点描述造成的带宽浪费。
内部服务总线如图6,是一种完整的企业服务总线,负责应用接口集成。消息端点上进行流量控制、访问频度控制、审计、日志等操作,消息通过总线进行协议转换、数据转换、服务路由等。消息包信息与路由控制信息在一起,产生大量的解析和数据流。服务总线先从报文中解析出消息包进行身份认证(如图6中1),身份认证通过后到服务提供方进行服务鉴权(如图6中2),鉴权通过后将解析出的服务包发给服务提供方(如图6中3)。
内部服务总线服务调用采用标准的SOAP/XML报文或HTTP/JSON报文,承载大量消息协议和数据格式转换,同时负责负载均衡,没有外部服务总线轻便。
(3) 双服务总线架构优势
采用双服务总线设计的“平台+应用”集成架构优势集中体现在以下几个方面:
1全面适应企业内外部的发展要求,快速地整合电信运营商内部的能力并满足移动互联网时代的高响应要求;
2集成架构具有良好的扩展性,外部服务总线采用互联网思路的架构设计,提供了标准接入方式,便于转售商等互联网企业接入;企业内部的异构业务系统可以由服务总线按照内部服务总线的标准接入方式,逐步接入到内部服务总线;
3通过服务编排组合快速支撑应用,满足企业内、外部灵活多变的业务需求,实现企业IT资产的重用;
4保护现有IT资产,采用不同技术集成企业内部业务和外部业务,支持差异化竞争。
4.2 数据总线
数据总线与服务总线一样,不参与业务,对数据进行切分缓存,负责数据采集、数据适配、数据访问操作、数据路由、数据共享及缓存管理等,减少系统间数据副本和数据冗余,避免数据多次搬移转换[8]。数据访问架构如图7。
由于电信运营商的运营支撑系统基本都是面向业务流程的,很容易根据流程ID进行离散存储。另外,Redis支持map、list等多种数据类型,较memcached等其他内存数据库功能更强大,因此采用Redis缓存从数据生产系统采集来的数据。数据总线从数据生产系统采集业务数据,并按数据定义进行切分和数据适配等,按业务规则离散存储到Redis中。数据消费方调用HTTP/JSON协议的数据服务访问数据总线上的数据,当数据在Redis中不存在时,数据总线将从业务系统中进行采集并加载到Redis中,提高数据访问性能。
业务系统或应用通过服务总线上的数据服务来访问数据总线上的数据,不直接操作源数据,由数据代理服务实现底层数据的访问,实现数据和应用的分离。数据缓存在数据总线中实现统一的数据访问入口,数据消费方从缓存中读取数据,减少了数据从数据源的搬移次数,减少了系统间数据的不一致,提升了数据交换效率。
5 结语
集成架构 篇8
随着企业应用集成(EAI)的不断发展,需要有更加有效、灵活的开发和集成模式来适应动态信息系统的要求。面向服务体系结构(SOA)的出现,填补了这一空缺,SOA所具有的松散耦合、面向消息的请求/响应通信方式、关注流程的特点顺应了快速构建柔性集成应用的需要。
面向服务的体系架构(Service-Oriented Archi2tecture,SOA)是一种基于互联网的信息集成体系框架,SOA采用面向服务的软件封装技术,它以服务接口(service interface) 和服务实现(service implementa2tion)的方式呈现,它的3个基本要素是服务描述、服务发现和服务调用。从技术角度讲,它是一个组件模型,XML技术为基础,通过WSDL 协议,使用基于XML格式的Web Service描述语言来描述接口SOA不仅仅是一个软件开发框架而且还是一个业务开发框架,它能够将不同类别、不同平台的服务结合在一起,动态、实时地更新维护一个跨区域的多功能的应用实体。
1 SOA面向服务架构(SOA)
SOA是一种粗粒度、松耦合的服务架构。SOA是服务的集合,服务之间通过标准和精确定义的接口通信。接口是采用中立的方式进行定义的,独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。由此,SOA是一个其所有功能均被定义成精确定义的、可调用的、独立的服务,且能被有序编排构建业务流程的应用架构。
SOA是基于服务的分布式系统设计框架,具备以下几个特点:
① 松散耦合:服务提供者使用标准定义语言定义和公布它的服务接口,接口定义服务消费者和服务提供者之间的调用契约。只要服务接口保持一致,改动调整应用程序的内部功能或结构将对其他部分没有影响;
② 互操作性:基于标准,提供了不同厂商解决方案之间的互操作性,SOA可以使用任何平台之间的功能,而与编程的语言、操作系统和计算机类型等等无关,可以确保各种基于SOA 解决方案之间的集成和互操作性;
③ 位置透明:SOA通过“发布检索”机制提供位置透明性,即服务请求者无需知道服务提供者的实际位置。
SOA体系架构模型为如图1所示。
2 中间件分类
用于EAI的中间件可分为5类:① 远程过程调用类中间件:RPC是基于开发过程集成的分布式应用软件的中间件,它能通过网络调用过程;② 数据库访问中间件:数据库访问中间件能够访问远程数据文件和数据库,它在数据级上集成,并且能通过网络查询或转移数据;③ 面向消息的中间件(MOM):MOM通过使用消息集成不同的应用软件;MOM技术将消息作为集成方式,能够产生、控制、存储和传送消息;MOM对数据一致性和多部处理问题很有效,但是因为消息规范容易更改,因此MOM软件组件集成中的作用不显著;④ 分布式对象技术类中间件(DOT),DOT作为中间件的一种,将面向对象的概念推广到分布式处理中,它能给新的、原有的应用软件提供面向对象的接口,从而实现互相访问;⑤ 事物处理监控器(TPM),它保证事物的完整性,具有如下的功能:回滚、失败后接替、自动重启、错误日志、消除单点失败的复制技术。一个可靠的系统需要集成MOM、DOT和TPM技术,没有一种单一的中间件产品能满足所有企业建立一个可靠的系统的需要,企业必须综合使用中间件以获得高效的EAI解决方案。
3 集成方法和通信模式
集成方法主要有2种:消息传递和接口定义。应用软件集成的设计者必须预先设定消息格式,通过定义的消息格式对消息进行传递,控制系统的业务流程。在接口定义这种方式中,发送器通过接口进行通信,由接口规定应用软件能调用的操作,任何用于处理的数据也都通过接口进行传输。通过这种接口定义,应用软件不会认为调用来自其他应用软件,而将它看成是自身内部的请求,这样,应用软件同其他应用软件的接口调用是透明的。
系统互相作用的方式决定其灵活性,通信模式有2种:同步通信和异步通信。同步通信分为以下几种模式:请求/应答、同步轮询;异步通信分为以下几种模式:消息传送通信、发布/订购通信、广播通信。在同步通信中,请求发送器需要一直等待,直到收到应答才进行下一次发送,这是因为需要应答结果来继续执行。异步通信允许发送器发出请求后继续执行,可能并不需要接收器为请求作应答。
4 基于SOA架构中间件应用集成设计
基于SOA架构的中间件应用集成设计如图2所示,各个功能实体都以服务的形式出现, 在特定的层次上为特定应用程序提供服务。
利用SOA松耦合、面向业务的特点,本文设计了基于SOA的架构,利用WebService 技术实现中间件与业务应用系统的集成,完成二者的松耦合集成。
① 业务应用数据库主要用于存储各个业务应用数据,是各个业务应用的持久化存储的地方;
② 基于SOA架构的系统服务总线,它是整个系统处理的核心,主要由服务总线(SB)、消息传输、数据转换及动态路由等几部分组成,是基础架构服务中的基础核心部分。服务总线是SOA 体系中的基础架构,是在SOA架构中实现服务间智能化集成与管理的中介。各个服务通过总线来互相访问,消息传输、数据转换及动态路由提供服务总线所需的必要服务支持,主要是总线基本服务,如消息分发订阅、队列、数据转换映射服务、动态连接和路由等;通信系统与网络技术
③ 中间件层:采用消息导向的中间件(MOM)和分布式对象技术类中间件(DOT),信息是以消息的形式从一个程序模块传送到另一个或者多个程序模块, 依据各个业务要求,以XML文件格式定义各个传输内容;
④ 服务接口层:服务接口层位于中间件层与应用系统之间。通过业务建模分解业务流程,识别出相关的业务服务,定义消息类型,派生服务接口并实现服务。然后将服务注册到服务库中。服务的请求者可在服务库中查找到该服务。实现服务间的串连以构成企业的关键业务流程。
5 在某地面系统中的应用
利用上述集成方案构建中间件在某应用系统的集成,以实现对集成框架的应用验证。
该系统采用J2EE的架构,消息中间件将系统的业务流程串联起来, 其服务总线由服务总线配置管理服务器、服务总线客户端以及消息中间件3部分组成。其组成如图3所示。
消息配置文件发送功能负责接收服务总线客户端发送的配置信息申请,并返回消息配置信息、服务注册信息,其中消息配置申请包含应用软件标识及消息配置文件版本信息。消息配置信息文件、服务注册信息为服务端生成的xml文件,它来源于数据库中的消息配置信息。
消息配置信息Xml文件为:
< xmlversion="1.0" encoding="gb2312" >
<ConfigFile>
<文件版本号>536</文件版本号>
<消息配置信息>
<消息编号>1</消息编号>
<消息名称>计算服务申请</消息名称>
<业务信息内容>申请信息</业务信息内容>
<消息类型>数据帧</消息类型>
<生命周期>600</生命周期>
<软件发送方>122</软件发送方>
<接收>
<软件接收方>121</软件接收方>
<接收队列>GDJSQQ</接收队列>
<消息中间件消息名称>服务计算消息</消息中间件消息名称>
<IP>10.10.2.90</IP>
<QCU>RWKZFW</QCU>
<端口号>10245</端口号>
</接收>
</消息配置信息>
消息发送、接收功能完成该系统内业务数据的流转以及业务服务的调用。应用软件通过服务总线客户端,调用消息中间件,将业务数据以消息的形式传递到其他的应用软件或服务。当应用软件调用系统中所部署的业务服务时,各应用软件通过服务总线客户端发送服务申请至业务服务,业务服务返回服务结果至应用软件,从而完成服务的调用
6 结束语
SOA为系统应用集成提供了较为理想的集成框架,在应用层通过中间件实现松散的应用集成,能够满足各种信息集成要求,体现了松散耦合、位置透明、协议独立的特点,能够支持随需应变的动态业务需求,较好地解决了传统企业应用系统集成存在的问题。SOA简化了IT的计算环境,其兼容性、互通性以及最终实现的业务系统自主的能力,满足了高度动态的业务系统环境。
摘要：介绍了面向服务架构(SOA)的基本概念和工作原理,以中间件技术为基础,提出了一种基于SOA的中间件应用集成框架,框架采用服务分层模型,具有敏捷性、松耦合、跨平台、分布式的特点,可广泛适应信息系统集成发展的需要,分析了基于SOA的企业应用集成的优点,设计了基于SOA的企业应用集成体系结构,研究了其实现的关键技术,给出了基于SOA架构的中间件应用集成方案,以消息中间件将系统流程集成起来,最后给出了相应的应用案例。
关键词：应用集成,面向服务架构,中间件
参考文献
[1]马华,李建华.基于SOA企业应用集成系统[J].计算技术与自动化,2005(12):87-89.
[2]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机,2006(5):211-213.
[3]王建兴,吕晓华.基于WEB SERVICES的面向服务信集成研究[J].计算机时代,2006(2):1-2.