应用集成架构

应用集成架构（共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

企业应用集成 (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 结语

应用集成架构 篇4

1 基于Web的信息集成系统

20世纪80年代后期, 随着计算机技术、网络技术、信号处理技术和控制技术的迅速发展, 工业过程控制系统开始突破自动化孤岛模式, 出现了信息集成和信息综合利用:集控制、优化、调度、管理、经营于一体的综合自动化新模式。目前国外实施综合自动化技术的大型工业企业已占很大比例。工业综合自动化技术是实现企业信息化和自动化的重要手段, 它通过将企业的生产过程控制、优化、运行、计划与管理作为一个整体进行控制与管理, 提供整体解决方案, 以实现企业的优化运行、优化控制与优化管理, 从而成为提高企业竞争力的核心高技术。以现场总线与工业数据通信为纽带, 以实时数据库为核心, 采用开放技术, 实现异构环境的信息集成, 形成以完整工业过程为对象, 进行基础自动化控制、信息化及管理一体化。实践证明, 采用先进适用的综合自动化技术所产生的效益是十分巨大的, 它不仅能提高产品的质量和价值, 同时改变企业的经营手段, 提高市场反应能力, 全面增强企业竞争力。

2 网络信息集成系统的网络构架

网络信息系统集成的过程, 是为实现某一应用目标而进行的基于计算机、网络、服务器、操作系统和数据库等的大中型应用信息系统的过程, 是针对某种应用目标而提出的全面解决方案的实施过程, 是各种产品设备进行有机组合的过程。该过程可以包括技术咨询、方案设计、设备选型、网络建设、软硬件系统配置、应用软件开发以及售后服务、维护支持和培训等一系列活动。实现一个系统最重要的问题之一是合理地确定体系结构。所谓体系结构是指构成系统的层次和这些层次之间的关系。网络信息系统集成可用四层结构描述其工作。自下而上各平台的主要内容如下:

2.1 环境平台层

主要包括网络到达的数字中的结构化布线系统, 网络机房系统的设计和供电系统的设计等内容。

2.2 网络平台层

网络平台目前一般应采用Internet技术, 即在信息高度集中的地方建立LAN, LAN间可通过WAN互连起来形成Internet, 并可能要考虑Intranet与Internet相连或通过WAN技术形成Extranet。采用Internet具有较好扩充性的子网互联结构, 可使网络具有更可靠、更安全、扩展性及交互性更强的特点, 应使用成熟的网络操作系统、适当的服务器和网络设备等。

2.3 信息平台层

该层主要采用数据库技术、Web技术、电子邮件技术、群体技术、网管技术和分布处理技术。此层的作用是: (1) 能直接为用户提供多种Internet/Intranet通用服务; (2) 为应用程序开发提供支持平台, 使用户未来系统的发展工作更为快捷、可靠。数据库管理系统采用如Oracle、SQL Server等软件。Web系统被认为是存储在Internet/Internet计算机中彼此关联的文档集合。用户通过Web可访问相关的站点、浏览文本和图形、接收视频和音频信息 (超媒体信息) 。群体系统能够增强分布或交互处理和协调工作的能力, 通过该系统及其提供的快速开发能力, 能将各个相关的工作部分联系在一起, 从而提高群体的整体工作效率。

2.4 应用程序层

位于该层的应用系统体现了具有用户专门应用要求的信息系统的存在价值。对这些应用系统应根据用户应用需求而选择, 用户可考虑自行设计和实现。

网络信息系统集成的这4个层次较全面地覆盖了完成设计和管理实施网络信息系统的全过程。

3 企业信息集成系统应用

企业信息化就是企业的计算机网络化、信息数字化和系统的集成化, 进而实现企业管理的自动化和生产过程的自动化。某纸业集团在企业信息化建设过程中取得了显著成绩, 其建立的计算机网络信息集成系统是一个成功的案例。而计算机网络系统是该系统的物理基础, 可以说, 企业不建立计算机网络系统, 企业信息化就是一句空话;当然, 如果企业不开发各种应用系统, 不进行系统集成, 实现各种资源共享, 那么计算机网络就是一种摆设, 发挥不了作用。因此, 企业如何在计算机网络系统的基础上, 开发生产过程控制系统和管理信息系统, 并进行无缝集成, 实现数据实时交换和共享以及各类系统的优化运行, 就是影响企业效益和核心竞争力的关键问题。

3.1 设计思路

该纸业集团计算机网络信息集成系统的设计思路是:坚持坚定的一把手工程, 坚持企业整体利益优先的原则, 坚持科学的集成方法, 坚持扎实细致的工作。所谓科学的集成方法, 指系统集成要遵循流程型化工制造企业系统集成的规律, 即分层集成, 自下而上的集成顺序, 以应用范围确定集成的跨度, 集成数据与以计算机网络和以产品系统中集成的数据为系统集成的基础。分层集成指公司的计算机网络信息集成系统分为基础层和高层。基础层是企业的执行系统 (含生产过程控制系统) 和各种管理信息系统;高层指对基础层进行纵横集成后的总系统。基础集成可以产生直接的经济效益和提高效率, 如集成的财务系统可以提高资金的周转率;集成的物资系统可以减少流动资金的积压, 并使生产持续进行, 从而直接提高经济效益;集成的产品生产系统可以提高该产品的市场竞争力。

3.2 系统评价

该集团信息化集成系统实现了系统全方位的集成, 不但TG-ERP系统内部数据完全集㈥成, 而且能够灵活提取生产指挥系统相关计量仪表及控制点的数据, 避免了人工输入数据的缺陷, 为系统实现成本核算和对关键工艺的分析打下了坚实的数据基础, 而且还能够与集团的办公自动化系统实现灵活的数据交换, 同时实现了远程信息查询收集、合同审批、信息发布等功能。该系统功能完善, 运行稳定, 建成以来大大提高了企业的经济效益和企业的核心竞争力。

4 结束语

基础层集成可以产生直接的效益或提高效率;高层集成即对基础层进行纵横集成, 可实现集团企业集成制造、集中管理并提高核心竞争力的目标。这样就将建立企业信息系统和系统集成的目标与集团企业的经营目标和战略统一起来, 达到自然应用, 水到渠成的效果。遵从规律, 客观集成, 事半功倍。遵循分层集成、自下而上的集成顺序, 以应用范围确定集成的跨度、数据和网络的集成原则, 以产品系统集成中的数据为系统集成的基础等都遵循了流程型化工制造企业信息系统集成的客观规律。事实证明, 遵循规律、客观集成可以取得事半功倍的效果。

参考文献

[1]王丽侠, 楼玉萍, 吕君可, 等.基于Web服务的电力信息集成系统[J].计算机技术与发展, 2009, 19 (5) :173-175, 179.

[2]郑伟, 陈进平, 付祥, 等.基于Web服务的企业信息集成应用研究[J].现代机械, 2010 (1) :70-72.

应用集成架构 篇5

为有效地解决这些问题, 使企业IT系统具备扩展性强和随时支持业务流程变化的基础功能, 成功实施企业应用集成、整合将是必要的措施。本文提出了事件驱动的业务过程和服务驱动的松耦合动态集成相结合的EDSOA企业应用集成参考模型。

1 企业应用集成及应用架构介绍

1.1 企业应用集成简介

企业应用集成 (Enterprise Application Integration, EAI) 的概念最初仅指企业内部不同应用系统之间的互连, 以期通过应用整合实现数据在多个系统间的同步和共享[1]。伴随着企业应用集成EAI技术的不断发展, 它所被赋予的内涵变得越来越丰富。现在EAI的概念已经扩展到业务整合 (Business Integration) 的范畴, 不仅要提供底层应用支撑系统间的互连, 同时还要实现存在于企业内部应用与应用之间、本企业和其他合作伙伴间[2]端到端的业务流程的管理, 包括用户互动、应用整合、B2B整合、自动化业务流程管理、企业门户以及对所有应用系统和流程的管理监控等方方面面。

1.2 面向服务体系结构

面向服务的体系结构 (Service Oriented Architecture, SOA) 建立在分布式计算技术的基础上, 可以基于现有的系统投资来发展, 而不需要彻底重新创建系统。这种体系结构本质上是动态的, 它提供对服务的登记、发现和调用的支持。SOA的软件开发人员可以将企业应用系统以服务的形式通过网络发布, 即任何服务应用程序都可以同其他位置的基于服务的应用系统交互, 并充分考虑服务的重用。

1.3 事件驱动体系架构

事件驱动体系架构 (Event-Driven Architecture, EDA) 是一种设计和构建应用的方法, 其中事件触发消息在独立的非耦合模块之间传递。事件源通常发送消息到中间件或消息代理, 需要者可订阅这个消息。由于事件消息用发布订阅方式通过消息代理传输, 一个事件便可传送给多个需要者。EDA和SOA之间主要的区别是:在SOA中, 发布者和需要者只有一对一的关系;而在EDA中, 事件发布者最终可以传送消息给基于订阅规则的任何数量的消费者。也就是说信息在两个系统间交互时, 根本不需要知道对方的详细信息。上述特点能很好地满足企业的应用需求, 如跨部门的应急联动系统或联合监管协同服务等应用[3]。

2 基于事件驱动的SOA (EDSOA) 企业应用集成模式架构

2.1 事件驱动型SOA

所有业务都是事件驱动的, 事件驱动型SOA为组织提供了响应这些实时业务动态所需的能力。它结合了面向服务的架构 (SOA) 的请求-响应模式和事件驱动架构的事件发布-提交模式。前者对服务事件的支持允许设计人员将应用程序设计映射到业务问题, 后者通常由事件和请求/响应组成。服务和事件处理的结合产生了更好的敏捷性和快速的信息性响应。

EDSOA的目标是对SOA进行扩展, 从而使解决方案能够以极快的速度从海量数据流中迅速标识出有价值的事件。它把专门化实时系统的数据流管理和复杂事件处理的功能变为应用程序的一部分。用户和系统能够获得最高到微秒级的状态图, 并且能够及时获知需要特别关注的一些改变。之所以有这样的优势, 一方面, 是因为SOA提供了一种集成框架, 可将来自多个系统的数据集合在一起, 并且当企业对请求进行响应时, SOA可以提供与某种系统的集成, 从而为企业提供帮助;另一方面, 不像SOA的请求/响应系统, 要求请求者必须明确发送请求信息, 而一个事件驱动架构提供一个机制去动态响应事件。在一个EDA系统里, 事件产生者发布事件, 事件消费者接受事件, 所以EDA极大地改善了企业对各种看似无关的事件的响应能力, 而这些事件往往会对企业造成影响。通过提供即时过滤、聚集和关联事件的功能, EDA能够以极快的速度检测有可能对企业造成威胁或为企业提供商业机遇的事件和模式, 并且为企业提供对此做出即时反应的能力。企业通过使用全面的数据提要和确切的事件定义, 能够快速做出反应并应对出现的挑战。

2.2 EDSOA应用集成参考模式

在企业应用集成领域, 企业一直面临削减成本和最大限度地利用现有技术的难题, 但与此同时, 他们还必须不断地努力, 以期更好地服务客户, 更快地响应企业战略重点, 从而赢得更大的竞争力。从信息的整合再到功能与流程的整合, 从企业内部的应用整合到跨企业边界的整合, 企业整合的需求不断变化和丰富。在当前激烈竞争的环境下, 一个成功的企业在IT构建上需要解决下列问题:

(1) 如何实现应用系统的快速构建、迁移和伸缩, 以满足不断变化的市场需求。

(2) 如何能够让已有的多种应用系统无缝集成起来。

(3) 如何设计现代IT架构, 使系统不仅功能强大和可靠, 而且还有强大的灵活性和可扩展性, 以满足不断增长的新需求。

通过对事件驱动SOA架构的分析可知, 事件驱动SOA架构可以解决以上这些问题, 基于此, 本文提出了完整的基于事件驱动SOA架构的企业应用集成参考模式, 如图1所示。

图1中的各个功能实体都以服务的形式出现, 是在特定层次上为特定应用提供服务的基础设施。实体服务可以是具有内部完整功能闭环的应用系统且对外提供特定功能的服务单元。

整个体系结构中的服务由以下几层构成: (1) 企业服务总线 (Enterprise Service Bus, ESB) , 这是SOA体系中的基础架构, 各个服务通过总线来互相访问; (2) 应用服务层, 这一层主要是指需要集成的企业各个应用系统和数据存储库; (3) 总线接入层, 这一层提供了适配器[4,5]服务, 支持多种主流应用的接入协议, 这样使用户可以访问各个应用服务, 并通过消息机制使各种应用接入ESB, 使用ESB的各种服务; (4) 核心服务层, 提供多种企业服务总线所需的必要服务支持, 在这一层提供总线基本服务, 如消息分发/订阅、队列、目录服务以及数据转换/映射服务等; (5) 业务支持层, 这一层侧重在业务支持上, 通过通用、标准的对象和服务模型, 可以在这一层上定义可重用的和基于企业界标准的业务流程, 同时, 还提供统一的用户交互服务, 包括手机银行、网上银行和传统银行网点。建立在企业服务总线之上的用户交互服务可以很小巧, 并关注于各自交互的特点。

该集成框架基于面向服务技术, 通过各类适配器服务接口将企业应用封装成统一的应用服务, 然后发布到目录服务中心, 并通过企业服务总线中的基础核心服务, 如统一数据格式和消息传递等, 来实现各个应用系统间的通信交互。在该集成框架中, 应用服务既可以是已有的旧应用, 也可以是新开发的应用。该集成平台是连接各类应用的桥梁, 采用的是松耦合方式, 即任何应用都以独立服务的形式连接到系统中来, 方式灵活, 简单快速, 真正实现了“即插即用”。

当在该框架下需要进行过程集成和业务集成时, 首先通过业务流程定义服务, 并根据事件驱动的模型将已经注册的应用服务在一定的规则下组成相应的业务流程链。业务集成模型的实现是由集成引擎调用应用服务的接口实现数据的存取, 并通过消息引擎在各个应用服务间传递路由数据, 实现定义的业务流程。

业务系统可以从SOA和EDA中受益匪浅, 因为当事件发生时EDA能触发事件消费者, SOA服务可以快速地从相同的消费者中访问、查询。系统需要快速的响应性, 当事件触发时这个系统必须能快速决定必须的动作。到事件结束, 事件应该被发布和消费, 而且事件要穿越SOA所有的边界, 包括整个体系结构和物理层。图2演示了事件被激发并穿越体系结构的所有层。

在图2的环境中, 一个事件能被定义为任何系统的平台的、组件的、业务的或应用进程的变化。事件可能是高层的业务事件或底层的系统事件。因为事件能被传送和接收, 订阅事件的应用程序和服务能对这些变化作出响应[6]。

可以看出SOA完全可以提供一个灵活松耦合的可扩展的基础集成服务平台, 比较完善地实现数据集成和应用集成。而且随着事件驱动架构的介入, 可以顺利地实现企业业务流程的建模和集成, 最终实现企业应用集成的最高层次, 即过程集成。

2.3 EDSOA模式在企业应用集成中的结合应用

信息系统应用集成在近两年成为企业信息化建设的热点。应该说EAI建设是企业对其信息系统建设的一个总结。从EAI建设的驱动力来说, EAI是为了解决企业内的“蜘蛛网”、“信息孤岛”等问题而产生的。企业通过建设EA系统, 有效地降低了接口数量, 并且在各个信息系统之间架起了沟通的桥梁。EAI为许多企业疏通了脉络, 提高了信息系统的整合能力。

由于企业行业化、协同工作与动态电子商务以及实时企业与业务流程自动化的需要等这些商业发展因素的驱动, 企业应用集成越来越成为人们关注的焦点。事件驱动的SOA的好处是很明显的。通过实现具有实时反应能力的企业, 事件驱动的SOA能够通过提高客户满意度、有效地管理意外事件和提高竞争的灵活性等措施增加企业的收入。通过提高价值链的可见性和减少获取客户的成本, 事件驱动的SOA还能够降低运营成本。因此, 通过更快的产品投放市场时间和更优越的技术支持和服务, 企业的市场领先地位将得以提高等。

事件驱动的SOA创建了把流程、方式和商业逻辑应用到原始数据中的基础。它把SOA请求/响应的范例与事件驱动的结构的发布/订阅模式结合在了一起。事件驱动的SOA还允许设计者描绘旨在解决商业问题的应用程序。这一般包括事件和请求/响应的互动。通过把面向服务和事件处理与商务流程管理、商务活动监视和企业服务总线等技术结合在一起, 事件驱动的SOA创造了极大的灵活性。

3 结束语

基于事件驱动SOA架构的企业应用集成体系结构将减少集成那些完全不同系统所需的时间, 并通过快速开发和组件重用来快速部署服务。从高度集成环境中的多个事件源捕获、关联和汇集事件的能力可确保企业对变化的业务情况进行预测并快速作出响应。相信新技术与新业务流程的相互融合, 将为我国企业在管理与业务模式上的创新提供机遇, 也会为“实时企业”的理念、管理模式、相关技术以及相应的支撑管理软件在我国企业的应用实践提供良好的基础。

摘要：针对在当前企业应用整合中存在的集成平台缺乏灵活性和适应性、扩展性较差、互操作性不高等问题, 本文提出了事件驱动的业务过程和服务驱动的松耦合动态集成相结合的EDSOA企业应用集成模式。该体系架构具有松耦合、行业支持和高度可集成能力等优势, 可满足企业行业化、协同工作与动态电子商务以及实时企业与业务流程自动化的需要, 也可以方便地实施EAI。

关键词：企业应用集成,面向服务的软件架构,事件驱动架构,业务整合

参考文献

[1]柴晓路.EAI和Web服务轻松进行企业应用集成[EB/OL].http://www.ccw.com.cn/htm/center/app/02-2-28-2.asp, 2002-02-28.

[2][美]Fred A Cummins.企业集成[M].杨旭, 等, 译.北京:机械工业出版社, 中信出版社, 2003.

[3]Global Research Partners.Event-driven Architecture:The Next Big Thing[C].Gartner Application Integration and Web Services Sum-mit, 2004.

[4]Jeff Sutherland, W J Van den Heuvel.Enterprise Application Inte-gration Encounters Complex Adaptive Systems:A Business Object Perspective[C].Proceedings of the35th Hawaii International Con-ference on System Sciences (HICSS′02) , 2002.

[5]David S Linthicum.The Evolution of Adapters[J].EAI Journal, 2002 (12) :36-40.

应用集成架构 篇6

关键词：C/S架构,集成方案,百度地图

0引言

地图能直观地展示有超媒体特性的地理空间数据及属性数据, 使用百度地图API可以在应用中显示百度地图图片、进行地点搜索、路线查询和交通流量显示等操作, 且面向公众服务类网站是免费的[1], 是做地图集成的一个不错选择。

毕业实习是高校教学体系中一个不可缺少的组成部分和不可替代的重要环节, 影响毕业实习与设计质量的关键因素包括实习基地、指导教师、学生及教学组织[2]。 实习基地是高等院校培养学生实践能力、提高学生科研水平、增强学生创新意识的重要场所[3], 也是教师开展科研、 推广先进科技成果、提高实践教学质量的重要依托和有效途径[4]。为加强实习基地建设, 增进学校和实习基地之间的交流与合作, 我们在毕业设计与毕业实习管理系统中实现了实习基地管理模块。

实习基地管理模块采用C# 语言、Winform技术实现, 是典型的C/S结构。为了能直观展示实习基地的地理分布, 帮助指导教师亲临实习基地, 需要在系统中集成地图。

1集成方案

百度地图针对不同的开发平台, 提供了多种API。针对网页地图应用提供了JavaScript API和Flash API, 针对手机地图应用提供了Android SDK和iOS SDK, 针对服务端地图应用提供了静态图API和Web服务API[5]。但目前并没有提供桌面版API, 因此, Winform应用程序只能间接调用百度地图API, 经研究, 有3个可行方案, 下面分别阐述。

1.1使用静态图API结合Web服务API

静态图API根据所设定的参数, 通过标准HTTP协议, 返回PNG格式的地图图片。在Winform程序中, 可以使用PictureBox控件显示地图图片。用户可以指定图片的尺寸、地图的显示范围 (包含中心点和缩放级别) , 还可以放置一些覆盖物在地图上, 以生成符合需求的地图图片[6]。以下示例包含北京市静态地图图片的网址:

它将返回中心点位于北京的地图图片, 图片的尺寸为640×460, 缩放级别为11。

Net平台下, 可以使用System.Net.WebClient类来下载地图图片, 使用该类的DownloadDataAsync方法异步下载可避免下载过程中界面操作被阻塞[7]。以下代码实现了地图图片的异步加载功能:

仅获得地图图片显然功能有限, 可以使用Web服务API, 以获得额外的功能。

百度地图Web服务API为开发者提供http接口, 即开发者通过http形式发起检索请求, 获取返回json或xml格式的结果数据。用户可以基于此开发C#、Java、C+ +、JavaScript等语言的地图应用[8]。Web服务API目前包括如表1所示的功能。

可以结合静态图API和Web服务API, 实现基本的地图功能。但是这个方案非常麻烦, 基本的地图漫游、缩放等功能都必须自行实现。

1.2使用Flash API

使用ShockwaveFlash控件嵌入SWF, 在SWF中使用百度地图Flash API。百度地图Flash API是一套由Ac- tionScript3.0语言编写的应用程序接口, 它能够在Flex/ Flash和Mobile Flex/Flash项目中快速构建地图应用。 百度地图Flash API包含了基本的地图接口, 提供地图浏览、漫游、缩放等基本功能, 支持自定义控件和卫星图等图层操作、坐标转换等功能[9]。相对于静态图API方案, 它封装了更多的功能, 调用起来更为方便。

本方案的难点在于Flash的ActionScript与宿主程序的相互调用。例如在实习基地列表中点击某个实习基地时, 在地图中应同步跳转到该实习基地;在地图上下文菜单中点击“添加实习基地”时, 宿主程序应显示相应的对话框。

ActionScript与宿主程序的相互调用是通过flash.ex- ternal.ExternalInterface类来实现的, 涉及到两个方面的问题, 一是从Flash的ActionScript脚本中调用宿主程序中的函数, 这是通过调用ExternalInterface.call方法来实现的;另一方面是从宿主程序中调用ActionScript脚本, 这是通过ExternalInterface.addCallback方法来注册Ac- tionScript函数的, 指示其能够为宿主程序所调用[10]。

宿主程序中, 通过捕获ShockwaveFlash控件的FlashCall事件, 来处理ActionScript对宿主程序中的函数调用, 该事件会传入一个request参数, 该参数是一个XML格式的字符串, 包含被调用的方法名以及相关参数信息。返回给Flash的值通过ShockwaveFlash控件的SetReturnValue方法来实现。

宿主程序调用Flash中的ActionScript函数, 则是通过ShockwaveFlash控件的CallFunction方法来实现的。

这些函数调用的参数都是XML格式的字符串, 例如:

处理XML格式的参数字符串将是一件比较麻烦的事。Adobe提供了一个示例程序, 该程序封装了一套类库, 主要包含两个类, 一个是ExternalInterfaceSerializer类, 用于调用参数的序列化和反序列化;另一个是Ex- ternalInterfaceProxy类, 用于简化C# 与ActionScript的相互调用[11]。

1.3使用JavaScript API

使用WebBrowser控件嵌入HTML, 在HTML中使用JavaScript API。 百度地图JavaScript API是一套由JavaScript语言编写的应用程序接口, 它能够帮助您在应用中构建功能丰富、交互性强的地图应用, 包含了构建地图基本功能诸如展示 (支持2D图、3D图、卫星图) 、平移、 缩放、拖拽等的各种接口, 提供了诸如本地搜索、路线规划等数据服务。本方案可以利用其实现的各种功能, 无须自行编码实现, 调用起来非常方便。相对于Flash API, 目前JavaScript API提供的功能更多, 平台兼容性更强。本方案的难点也在于JavaScript与宿主程序的相互调用。

宿主程序要调用HTML网页的JavaScript脚本, 可以通过WebBrowser控件的Document属性的Invoke- Script方法来实现。 例如, 可以通过以下代码来调用JavaScript来实现地图平移到指定的经纬度:

反过来, HTML网页中的JavaScript要调用宿主程序中的函数, 则相对麻烦一些。首先, 需要通过以下两个属性, 对C#宿主类进行标记, 以通知.NET Framework需要完全信任并且使C# 类暴露给COM, 从而暴露给JavaScript:

然后, 需要对WebBrowser.ObjectForScripting属性设置一个实例, 该实例由宿主应用程序实现并且可由HTML文档的JavaScript脚本访问。就本例而言, 将其设置为BMapControl对象本身即可:

现在, 在JavaScript脚本中, 可以通过window.exter- nal属性获得ObjectForScripting, 进而通过该对象调用适当的方法。例如, 可以在JavaScript脚本中通知宿主程序地图被点击, 并将经纬度参数传递给宿主程序:

经过以上准备工作, 就可以顺利地在C# 和JavaS- cript之间相互调用了[12]。

2系统分析与设计

2.1系统分析

实习基地管理模块要求能对实习基地进行增、删、改、 查等基本维护操作, 能在地图上添加实习基地。在实习基地列表中选中某实习基地时, 自动在地图上漫游至该实习基地, 能利用百度地图的一些先进功能如公交线路查找、 测距等。

2.2系统设计

系统采用.Net Winform技术实现, C/S架构。C/S架构的应用程序相对于B/S架构的应用程序能利用更多的本地资源, 反应更快, 用户体验更好。

通过前述各种可行方案的讨论, 决定采用功能更强的JavaScript API集成百度地图。

使用MySql作为后台数据库。MySql是一款成熟的开源关系数据库, 应用相当广泛, 经过FaceBook等大型应用的考验, 性能满足要求。

数据持久层采用Entity Framework。Entity Frame- work是微软最新的ORM数据持久框架, 它将数据封装成面向对象的业务实体, 使之更具现实含义;封装数据库访问功能, 屏蔽不同数据库方言对软件开发的影响, 便于不同数据库系统迁移[13]。

实习基地 (InternshipUnit) 的数据表设计如表2, 与百度地图对接的字段信息为经度 (Longitude) 和纬度 (Lati- tude) 。数据库设计完毕之后, 使用Visual Studio的Enti- ty Framework设计器生成数据模型, 便可以使用面向对象的方式来访问数据库了。

3实现

实习基地管理模块主要由3个界面组成。

3.1主界面

如图1。左侧区域用于浏览实习基地, 并提供增删改等功能按钮;右侧区域用于展示地图, 地图上会显示实习基地的标记, 单击标记会显示该实习基地的详细信息, 包括地址、电话、简介等, 并且提供路线搜索、附近信息搜索等功能。在左侧实习基地列表中选中某个实习基地, 右侧地图会自动漫游到该实习基地, 非常方便。

3.2实习基地信息编辑界面

如图2。该界面用于添加、修改实习基地信息。其中名称是必填的, 其它字段可以不填。经纬度信息一般不直接录入, 而是在地图中设置。

3.3选择实习基地界面

如图3。可以在地图中找到实习单位所在位置, 右击, 会弹出“添加实习基地标记”菜单, 点击该菜单, 弹出 “选择实习基地”对话框, 选择一个实习基地, 便在地图上添加一个标记。添加实习基地标记, 实际上就是设置实习基地的经纬度信息, 也可以在地图中拖动现有的实习基地标记以修改经纬度信息。

4结语

应用集成架构 篇7

关键词：EAI,Web Services,认证,授权,SSO,RBAC

0 前 言

电子商务和信息技术的迅速发展对不同企业级的应用系统之间的开放性和互操作性提出了更高的要求,为了使这些系统之间能够无缝地进行协作,企业应用系统集成(Enterprise Application Integration,简称EAI)应运而生。

传统的EAI解决方案由于缺少统一的标准,在集成系统之间的互操作性上存在很多无法克服的问题。基于XML技术的Web Services的出现,极大地提高了企业级的应用系统之间的互操作性。Web Services提供了一个分布式的计算技术,用于在Internet或者Intranet上通过使用标准的XML协议统一的封装行为和数据来展现商业应用服务。但是基于Web Services的解决方案还缺少有效的方法在集成环境中保证合法用户访问授权资源。本文介绍了一种基于Web Services的应用系统集成的安全体系结构WSSA-EAI(Web Services Security Architecture For EAI),它结合了SSO的认证机制和RBAC的授权机制,提供了一种统一的且便于维护的EAI安全机制。

1 EAI及其需要解决的主要问题

1.1 EAI

EAI通过硬件、软件、标准和业务过程的结合,实现两个或多个企业系统之间的无缝集成,使它们能够统一运作[1]。EAI解决方案可以分为五个层次[2]:用户交互、应用连接、业务流程整合、构建整合和信息集成。本文中所讨论的问题属于应用连接层EAI的范畴。

建立高效的EAI需要面对两个主要问题[3,4]:

(1) 不同应用系统之间的互操作性 不同业务系统所在主机和应用平台的差异性、实现技术的差异性、数据访问的差异性等,导致不同业务系统之间或不同数据访问之间的接口多样化。EAI需要一种统一的方法处理不同应用系统之间的访问。

(2) 一体化的安全问题 应用系统的安全策略主要包括认证和授权两个方面,不同业务系统都有自己对信息和功能访问的安全策略,因此用户在访问集成系统的时候需要多次认证和授权。EAI需要一个统一的安全访问机制支持不同的安全策略。

1.2 互操作性问题的考虑

在传统的EAI解决方案中,由于应用系统的互操作性实现上的限制,导致了要成功实施一些好的集成策略往往显得力不从心[5]。传统的EAI解决方案采用开发、使用消息中间件来实现没有互操作性系统之间的通信,但基于分布式对象技术的消息中间件,如CORBA、DCOM、EJB等,无论是开发还是发布实现起来都相当复杂,并且缺少灵活性和普遍适用性[6]。

基于XML技术的Web Services是使用标准的Internet协议执行分布式计算的软件组件[7],基于它的EAI解决方案使用标准的XML消息实现异构系统之间的通信,这种宽松的通信机制有助于消除许多传统的EAI解决方案难以克服的互操作性问题。另外,Web Service 采用面向服务的体系结构SOA(Service Oriented Architecture),如图1所示。该架构主要由三个参与者(服务提供者、请求者和服务注册库)和三个基本操作(发布、查找、绑定)构成。Web Services是自包含、自描述、模块化的应用,它可以在Web中被快速地描述、发布、查找以及通过Web来调用。

1.3 安全问题的考虑

近年来,企业级应用系统内部的安全问题已经讨论得十分广泛,各种成熟的认证和授权机制也已经得到了大量的应用,但是如何将这些安全机制作用于企业级应用系统之上,保证集成系统之间的数据访问的安全性,仍然缺少明确的结论,需要进一步的研究[8,9]。

SSO(Single Sign On)指的是网络用户访问应用服务时作一次身份认证,随后就可以对所有被授权的网络资源进行无缝的访问。SSO可以让用户更加简单地访问集成系统,并且提高用户访问的安全性[10]。现实中人们提出了多种具体的SSO解决方案,如Broker-Based SSO方案、Agent-Based SSO方案、Token-Based SSO方案、Agent and Broker-Based SSO方案和基于网关的 SSO 方案等等[11]。Broker-Based SSO是应用最为广泛的方案之一,它有一个集中的认证和账号管理,Broker负责维护用户访问控制的权限。

RBAC是当前企业级应用系统内部非常流行的授权机制,它被证明优于传统的自由决定的和强制的访问控制机制[12],如图2所示。它的基本思想是将权限授予角色而不是直接授予用户,用户通过角色分派来得到操作权限从而实现授权。由于角色在系统中具有相对于用户的稳定性,并具有更为直观的理解,从而大大减少系统安全管理员的工作复杂性和工作量。

在WSSA-EAI中部署基于SSO和RBAC机制的全局的认证和授权服务,不仅达到了对EAI的访问控制目的,并且简化了用户访问集成系统的认证操作。这些基于Web Services的安全服务维护起来也十分方便。

2 WSSA-EAI

WSSA-EAI本身专注于构建EAI的安全框架。其中,完整的传输通道和数据传输本身的安全性问题可以通过采用诸如SSL和PKI[13,14]等技术来解决。

2.1 体系结构

如图3所示,在WSSA-EAI的集成环境EVE(EAI Virtual Environment)中提供了三种类型的服务:业务服务、安全服务和信息共享服务。业务服务则是将各种集成系统的功能通过Web Services封装并提供使用;安全服务主要负责访问集成系统的认证和授权;信息共享服务提供前面两种服务的发布、查找和绑定。EVE主要由WSP、AES(Authentication Server)、AOS(Authorization Server)和UDDI Server几种类型的结点构成。

(1) WSP(Web Services Provider)

WSP代表集成到EVE中的应用系统。WSP提供应用系统的Web Services的访问接口,应用系统的各种功能必须按照EVE的要求用Web Services进行封装。登录到EVE的合法用户通过WSP提供的接口访问应用系统。EVE的业务服务由WSP结点提供。

(2) UDDI Server

UDDI Server是EVE环境的集成信息的发布和检索中心。应用系统以Web Services的方式集成在EVE环境中,UDDI Server提供这些Web Services的描述信息的发布和查找。用户在访问WSP之前,可以通过UDDI Server查找需要的访问信息。UDDI Server负责提供EVE的信息共享服务。

(3) AES

AES是EVE中提供安全机制的核心结点之一。它提供集中的用户认证,为合法用户分配一个身份令牌。用户只需要登录一次就可以使用身份令牌访问多个WSP。AES负责提供EVE的安全认证服务。

(4) AOS

AOS是EVE中提供安全机制的另外一种核心结点。用户在使用身份令牌访问WSP之前,必须经过AOS检查该用户是否具有访问某个WSP的权限。EVE的安全授权服务由AOS提供。

2.2 工作机制

下面介绍WSSA-EAI的几个关键结点的工作机制:

(1) AES

AES不仅提供了用户认证的功能,它还提供了登录用户的Session管理的功能,Session用来保存认证登录用户的信息。

图4描述了用户认证的工作机制,用户向AES发送认证请求,通过认证后AES为用户分配一个身份令牌并且将用户信息保存在Session中。

由于用户可能需要访问多个应用系统,仅仅用传统的借助HTTP和HTTP cookies的Session管理是不够的。所以AES需要实现一个自己的Session管理,提供简单的信息保存和超时功能。

(2) AOS

AOS提供授权功能,它的授权机制使用角色来映射应用系统的访问权限。基于角色的访问控制方法把对用户的授权分成两部份,用角色来充当用户行使权限的中介。这样,用户与角色之间以及角色与权限之间就形成了两个多对多的关系。角色是一组访问权限的集合,一个用户可以是很多角色的成员,一个角色也可以有很多个权限,而一个权限也可以重复配置于多个角色。

在WSP的发布过程中,一方面WSP需要在AOS上配置授权用户和角色之间的映射关系,另一方面WSP需要为它提供的访问接口分配角色,然后用户才可以在WSSA-EAI的环境中访问WSP。

图5描述了角色检查的工作机制,登录用户使用身份令牌访问WSP,WSP将身份令牌和访问接口的角色作为参数发送给AOS进行权限检查,AOS先从AES获取身份令牌对应的用户信息,然后通过角色管理来检查用户是否拥有访问接口的角色,即用户是否有权访问WSP的接口,最后将检查结果返回给WSP。

实际上,WSSA-EAI有两种角色管理策略:一种是由AOS来集中管理角色;另一种由每个WSP自己管理,即WSP自己维护用户和权限之间的关系,直接从AES获取身份令牌对应的用户信息。前者的主要优点是可以提供多个系统的角色集成,减少由于角色的重复定义带来的额外操作;后者的主要优点是对于每个独立的WSP,角色管理非常灵活,可以随时由WSP自己控制访问权限,还可以集成不支持RBAC的系统。这两种方式对于具体的WSSA-EAI的实现来说都是十分重要的,可以优势互补,具体使用哪种方式应该由WSP来决定。

(3) WSP

WSP在用Web Services对应用系统的访问接口进行封装的时候,需要将用户的身份令牌添加到原有访问接口的参数列表中,这样用户登录后只需要使用身份令牌访问WSP。在发布的时候WSP还需要配置访问权限。

图6描述了用户访问集成系统的整个流程。

· 用户向UDDI Server发送查找请求,查找需要访问的应用系统的Web Services的描述信息。

· UDDI Server向用户返回查找结果。

· 用户向AES发送认证请求。

· AES向用户返回一个用户的身份令牌并且将认证用户的登录信息保存起来。

· 用户向WSP发送应用系统的访问请求,访问请求中包括用户经过认证后的身份令牌。

· WSP向AOS发送验证授权的请求,验证请求中包括被访问接口的角色信息和用户的身份令牌。

· AOS向AES发送获取用户令牌对应的用户信息的请求。

· AES返回用户信息给AOS。

· AOS验证用户是否有权访问应用系统,然后将验证结果返回给WSP。

· WSP检查验证授权的结果,如果用户没有权限访问应用系统,WSP将会拒绝用户的访问,如果用户是合法访问者,WSP将应用系统的访问结果返回给用户。

可见,用户访问EVE环境中的应用系统不仅仅是用户访问WSP结点的简单过程,而是WSP、AES、AOS和UDDI Server多个结点间相互协作的复杂过程。

3 结束语

本文介绍了一种新型的基于Web Services的EAI安全体系架构WSSA-EAI,它不但有助于解决异构系统的互操作性问题,并且将原来作用于系统内部的访问控制机制提高到系统集成的高度,为EAI的安全问题提供了一些借鉴。基于WSSA-EAI的方案比较适用于类似于学校、企业内部等具有统一的用户管理的内部集成,这样可以保证多个WSP所涉及到的用户的一致性,便于集成的实施。

WSSA-EAI在安全性上具备以下几个特点:

· SSO认证机制减少了用户安全信息的数量和操作的次数,有助于减少安全信息由于频繁操作导致丢失的可能性。

· 在用户访问集成系统的过程中,在EVE中仅仅传递用户的身份令牌,减少了伪造安全信息的可能性。

· Session管理机制确保了所有的身份令牌都是在EVE中产生的。

应用集成架构 篇8

传统信息运作方式虽然大大推进了企业生产力, 但又反作用于信息技术, 促使企业内外部商务信息的大规模集成。从面向过程到面向服务的4个关键阶段可以看出, 程序语言发展的过程实质为逐步降低耦合性的过程, 也是接口与接口实现逐渐分离的过程 (见表1) 。

在Web Service的基础上发展起来的面向服务架构 (Service-Oriented Architecture, SOA) 的思想将企业应用看作一些可跨越企业边界、自我描述、实现某一特殊功能的服务集合。通过标准化的机制, 能够将这些服务注册于公共数据库中, 并能被感兴趣的请求者发现;服务者和请求者之间能够进行动态绑定和直接交互, 实现一定的企业功能逻辑 (SOA模型如图1所示) 。而作为SOA的一种实现手段, Web服务以其完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集成性等特点, 能够良好地满足SOA应用模式的需求。

2从BPM到SOA的跃迁

商务流程管理 (Business Process Management, BPM) 在SOA之前出现并已成功实施。早期企业通常会建立各业务部门相对独立且相互之间缺乏协同的流程系统。随着部门分工理论的没落, 各方面的困难使BPM产品一度丧失了竞争优势。而如今, 缺乏灵活性、

高昂的变革成本、以IT为中心的传统应用等因素又促使BPM市场急剧增长。同时, IDC提出流程企业应进化到2.0阶段, 使用SOA的思想方法和技术架构组装企业的BPM, 而BPM的重新崛起在很大程度上又推动着SOA的发展。

在商务流程自动化 (BPA) 、异构系统的无缝整合 (EAI) 、企业流程建模分析 (BPM的核心) 和监控企业活动以实现流程持续改进 (BAM) 等每个BPM的应用场合中, SOA都扮演着至关重要的角色。要从BPM迁移到SOA, 跨越信息技术与业务之间的鸿沟, 需引入一个服务层, 该层包含支持特定业务域的服务线、可跨多个业务域共享的可复用技术服务以及Web Services平台, 允许以各种独立于底层服务和技术平台的方式定义和利用服务。从技术层面看, SOA和BPM结合的方法主要有以下两种:

(1) BPEL+WSDL。先定义好一个BPEL流程, 然后将其纳入到SCA容器。在定义构件时, 可使用子元素的process属性指明这个可执行的BPEL流程的目标名称。

(2) BPEL应用SCA的某个构件。例如, 一个BPEL的变量声明可以包含一个SCA的扩展, 表明这个变量代表了一个SCA构件的属性。

3基于SOA的商务系统信息集成应用建模

某国内知名IT企业ABC公司内部先后实施了由不同厂家提供或自主开发的办公自动化、企业资源计划、决策支持、电子分销、供应链管理等相对独立的商务子系统。随着业务的不断进展, 以及与其他企业的海量信息流通, 需要部署一个基于SOA的商务系统门户集成方案。

考虑到业务需求, 通过集成中间件平台对各商务系统的流程与ERP核心子系统进行实时无缝的链接, 使企业内部整体的商务流程更加完整和流畅。此外, 通过集成中间件平台集成ABC公司与其供应商Z公司之间的异构ERP系统, 使整个供应链的商务流程更加完整和流畅。

集成后的SOA架构应用模式为:OA系统首先根据内部登录人员的配置信息确定用户身份并给予相应权限, 根据此权限范围内的工作流程和列表提供流程表单。用户需在表单上填写与流程控制、ERP系统相关的参数及其他字段信息。工作流引擎根据流程定义文档控制流程执行, 当流程流转到某个需要调用Web Ser-vice的活动时, 发送SOAP请求信息给服务提供者。Web Service利用数据访问逻辑组件操作数据库表。以采购申请为例 (图2为采购流程定义) , 用户调用ERP的采购管理Web Service的“采购信息保存”方法, 将采购的物料编号、采购数量、价格范围、供应商等信息存储到ERP的数据库。服务提供者实现服务之后, 将包括单据编号和状态等信息的SOAP返回信息传回OA系统。工作流引擎根据WSDL文档解析该SOAP返回信息, 将它自动存入流程表单并将表单传送给服务器, 然后根据工作流控制数据和组织/角色模型将流程表单传递给下一个执行者, 并同时发送E-mail通知。

4结 语

基于SOA架构的BPM可使企业机构快速部署和改变流程, 有助于满足跨越系统、地域和组织界限的端到端商务流程需求, 使企业具备敏捷的商务竞争优势。下一步面临的问题是:如何持续改进BPM流程, 识别出最有价值的商务流程模型去实施企业级SOA;在此基础上, 如何逐步积累经验, 更深入广泛地推广BPM应用。实践表明, 在影响项目成功实施的各种因素中, 除了在战术层面需要能正确实施BPM和SOA的混合分步部署的系统架构师以外, 管理理念与组织协调等人为方面的难题远大于技术难题。因此, 要成功部署SOA, 企业不能仅关注技术, 更应把持续改进流程作为先进的管理理念和必不可少的长期商务战略。

参考文献

[1]罗鸿, 王忠民.ERP原理、设计、实施[M].北京:电子工业出版社, 2003:45-60.