基于SOA的数据集成

基于SOA的数据集成（精选10篇）

基于SOA的数据集成 第1篇

数据集成就是将分散的各种不同的数据源中的数据在逻辑上或是物理上进行集成,使用户能够以透明的方式访问数据,为用户提供全面的数据共享。集成使得数据在整体上保证了一致性、提高了数据共享的效率,解决了原本信息孤岛造成的大量的冗余数据和垃圾数据等问题。用户访问数据的方式的透明性指数据集成系统提供一种统一的方式,让用户只关心要访问的数据和访问数据的方式,而不必关心数据集成系统如何访问数据。图1描述了数据集成一般结构。

常见的数据集成方法主要有:联邦数据库、中间件集成方法和数据仓库方法。

联邦数据库是一种将各种数据源的数据视图集成为全局模式,以便用户能透明地访问各种数据源的数据的模式集成方法。此方法描述了共享数据的结构、语义及操作。模式集成的过程中要处理原异构的数据模式到虚拟的数据源视图(全局模式)的映射问题和如何处理用户在全局模式上的查询请求。用户提交的请求被数据集成系统从虚拟的数据源视图(全局模式)转换成各个数据源的本地视图来处理。可以用全局视图法和局部视图法构建这种映射。

根据集成度可以将联邦数据库系统分成紧密耦合联邦数据库系统和松散耦合系统联邦数据库系统。不同耦合程度的系统各有优缺点。

数据仓库是把各个异构数据源中的数据副本存储在一起,合成一个数据库,数据的变化不能实时反映出来,并且需要定期更新。

中间件模式通过在各种异构的数据源和应用程序之间提供一个统一的数据逻辑视图来隐藏底层的数据细节,同时向用户提供数据访问的统一接口。这种模式适用于异构数据源多且高度自治经常变化的Web环境。

SOA是面向服务的组建模型,应用程序的业务逻辑被发布在Web上,称为服务,客户可以通过网络调用。这些服务采用中立的、独立于平台的方式实现,具有松耦合性。服务之间及服务与客户之间的数据交换采用通用的方式。基于SOA规范的数据集成系统可以方便地使用标准化的借口对异构数据源进行访问,使数据得以共享,系统的灵活性和重用性得到很大的提高。

实现SOA最常用的方式是Web Service,它使用超文本传输协议(HTTP)、简单对象访问协议(SOAP)等标准的通信协议,使用可扩展标记语言(XML)来描述数据、使异构平台之间数据交换和共享变得平稳和无障碍,使用Web服务描述语言(WSDL)、通用发现、描述和整合(UDDI)规范给服务提供者一种构建在异构平台(不同协议和不同编码方式)上的Web服务请求基本格式和发现、分析和整合服务的基本格式。

文中采用SOA架构,使用Web Service为实现技术,HTTP、SOAP通信协议,XML作为数据处理和传输协议,提出了一种基于SOA的数据集成方法。

1 基于SOA的数据集成框架

1.1 体系结构

整个系统由客户层、应用层和数据服务层等3层构成,如图2所示。

1.1.1 客户层

用户通常通过浏览器使用HTTP等协议和Web服务器交互,向Web服务器发送数据访问请求,并接受Web服务器接发回的结果,通过浏览器向终端用户展示。

1.1.2 应用层

在接受到用户通过Web服务器发送的服务请求之后,转发发给相应的服务转换器。应用层由数据汇总、服务解析和服务中心(服务注册库)等3部分组成。

1.1.3 数据服务层

将应用层传递过来的数据访问请求和处理通过服务转换器转换成对各种异构数据源的访问,并将响应数据传递给应用层。数据服务层由各种异构的数据源和相应的数据源组成。

1.2 系统流程

当企业的业务逻辑发生变化或需要提供新的功能时,只需要往数据服务层添加新的服务,可以通过以下步骤完成:(1)在服务中心注册新的服务。(2)客户通过浏览器发出数据访问请求(以XML文档的形式)。(3)Web服务器在接收到客户发过来的请求后,将请求转发给应用层的服务解析模块进行解析,在服务中心(服务注册库)中检索可以提供该服务的数据服务器,然后向数据服务层的服务转换器转发,服务转换器在接收到转发过来的服务请求后,转换成针对特定数据源的具体操作方法和步骤,最后将响应结果向上提交给应用层的数据汇总模块(在提交之前,数据被转换成了XML格式),最终经由Web服务器将相应数据返回给用户的应用程序。

2 关键技术及实现

2.1 数据源转换为XML文档

目前,绝大多数的数据源都采用的是关系数据库,因此,将从数据源中产生的数据结果(关系表)转换成XML文档是本系统中的关键技术之一,下面给出了将关系表中的数据转换成XML文档的方法,以订单表为例:

对于关系表结构的转换,可以将关系表名作为XML文档的根元素,关系表的字段作为子元素,并将字段的类型和大小作为字段元素的子元素;对于表中数据的转换,可以将关系表名对应XML的根元素,定义特定标记作为其子元素,字段值作为对应元素的文本值,加入订单表中有字段:订单编号、商品名、交货日期、和价格,XML文档内容如下:

2.2 采用Web服务实现SOA

建立在开放标准和独立平台之上的Web服务(Web Services)是实现SOA最流行的方法。它是部署在网络上的一组具有标准接口的组件,通过基于XML技术规范的语言进行描述、由URI(同一资源标识符)进行标识和展示给使用者。

Web服务的体系结构构建在3个角色(Web服务提供者、Web服务请求者、Web服务注册/代理)和角色间的3个基本动作(发布、发现、绑定基础之上。服务提供者向客户(或其他服务)提供服务(服务生产者);服务请求者就是客户(服务消费者);服务注册中心是一个向客户展示服务的平台,这个平台将服务请求者和相应的服务联系在一起,充当管理者的角色。图3描述了Web服务体系结构中的的3个角色及3个动作之间的关系。

3 结语

基于SOA架构、Web Service技术和XML规范,提出了一种新的数据集成方案,该方案解决了传统企业信息系统中的信息孤岛问题,使得在企业业务的更新和添加新的业务逻辑之后更加方便地更新企业信息系统和底层数据源,实现了异构平台下数据共享,降低了系统的耦合性。随着对SOA、XML、Web Service规范和技术的进一步深入研究,此框架会将得到完善,并会被更广泛地应用到企业信息系统中。

摘要：随着企业的发展、信息化技术在企业的大量运用,过去不同时间、不同地点、采用不同技术建立的局部的应用系统越来越多,成为一个个信息孤岛。以SOA、Web Services、XML等技术为支撑的数据集成系统,可以实现一个资源共享的统一的数据平台,解决信息孤岛问题。

基于SOA的数据集成 第2篇

基于产品数据集的设计、制造和测量的集成途径

描述了产品设计、制造和测量的集成过程;介绍了作为产品定义基准的产品数据集:阐述了运用CAD系统进行建模的`方法、数控加工以及数字化测量过程.

作 者：苏迪 范玉青 Su Di Fan Yuqing 作者单位：北京航空航天大学机械学院刊 名：航空制造技术 ISTIC英文刊名：AERONAUTICAL MANUFACTURING TECHNOLOGY年，卷(期)：“”(11)分类号：V2关键词：产品数据集 集成技术 制造 测量

论SOA在系统集成中的应用 第3篇

摘 要:系统集成是Web Service和SOA的主要应用领域,集成技术主要用于解决数据库爆炸和信息孤岛问题。集成通过自适应技术来整合IT信息资源,发挥IT的整体作用,集成技术包括了连接、管理、规范和整合企业内外的信息。随着Web Service和SOA的不断成熟,一种基于SOA的集成框架ESB也日趋完善。ESB融合了EAI和B2B的优点,采用ESB可以使系统集成更方便、更经济。

关键词:SOA 系统集成 Web Service ESB

中图分类号:TP303文献标识码:A 文章编号:1673-8454(2009)17-0081-04

一、概念

系统集成泛指连接、管理和组合各种企业内和企业间的系统,使集成后的系统能以统一的方式互联互操作以支持业务过程的自动化技术。将两个或者两个以上的系统进行集成时主要涉及组织、角色、任务和过程的定义和管理。系统集成的主要工作有集成方案的确定,集成功能范围的划分,工作流系统的创建改造,数据格式的规范,组织模型的统一等。

SOA(Service-Oriented Architecture),一般翻译为“面向服务的体系结构”,它是一种良好分布式软件架构模型,它将不同的功能单元(服务)通过单元之间的接口和契约联系起来。接口采用中立的方式进行定义,独立于实现服务的硬件平台、操作系统和编程语言,使得构建的服务可以以一种统一和通用的方式进行交互。所以,SOA是将软件组织在一起的抽象概念。

二、系统集成

系统集成是一种新兴的服务方式,指在企业范围内外,将多个应用系统的过程、软件、标准、数据库和硬件集成在一起,使集成后的系统成为一个无缝运作的系统。系统集成的本质就是最优化的综合统筹设计,对一个大型的综合计算机网络系统,系统集成所要达到的目标——整体性能最优,即所有部件和成分合在一起后不但能工作,而且全系统是低成本的、高效率的、性能匀称的、可扩充的和可维护的系统。一般的系统集成包括业务过程集成、应用集成、数据集成和功能集成。通过集成可以增进与客户的关系,增强供应链间的联系,改善内部流程,减少市场周期等。我们经常把系统集成分为:表示集成、数据集成和功能集成(如图1所示),另外API集成是所有集成的基础。系统集成实现的关键在于解决系统之间的互联和互操作性问题,它是一个多厂商、多协议和面向各种应用的体系结构。这就需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、建筑环境、施工配合、组织管理和人员配备相关的一切面向集成的问题。

目前系统集成的领头公司主要有:IBM、EBA、Microsoft、Sybase等,它们都很好地实现自己的系统集成的解决放方案。

三、SOA的关键技术

与SOA相关的技术很多,主要有XML、Web Service、CORBA(DOM、EJB)、ESB、SOAD、BPM(EAI、B2Bi)等。

1.SOA

SOA是目前IT领域的热点,它是具有分布、协作、共享特征软件的首选体系结构。

SOA的关键是“服务”的概念,W3C将服务定义为:“服务提供者完成一组工作,为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化,但也可能使提供者的状态改变,或者双方都产生变化。”

Service-architecture.com将SOA定义为:“本质上是服务的集合。服务间彼此通信,这种通信可能是简单的数据传送,也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

Looselycoupled.com将SOA定义为:“按需连接资源的系统。在SOA中,资源被作为可通过标准方式访问的独立服务,提供给网络中的其他成员。与传统的系统结构相比,SOA规定了资源间更为灵活的松散耦合关系。” 它是一种架构模型,可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

Gartner则将SOA描述为:“客户端/服务器的软件设计方法,一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处,在于它着重强调软件组件的松散耦合,并使用独立的标准接口。”

SOA支持将业务功能单元作为连接服务或可重复进行集成,在需要时可通过网络访问这些服务或任务。SOA是一种松散耦合和粗粒度的服务结构,它将服务组合成各种应用程序,提高了代码的重用率、方便地复用各种应用资源,使业务更加灵活和便利,增加功能的同时减轻了工作量。SOA原型的一个典型例子就是CORBA(公共对象请求代理体系),随着Web Service技术的成熟,SOA也有了进步,主要体现在以XML为基础的技术上。在Web Service中通过WSDL来描述接口,这样系统的动态性、灵活性、自治性就会有很大的提高。

SOA的主要组件结构如图2所示。SOA是通过http传递的SOAP消息。SOAP(简单对象访问协议)是一种基于XML文本的通信协议,它是一种轻型的分布式计算协议,在分布式环境中交换信息。Http允许SOAP利用Web服务器、代理服务器和防火墙等进行投资,达到简单、可扩展的目的。

2.XML

XML(Extensible Markup Language)可扩展标记语言,是一套定义语义标记的规则,也是元标记语言,用于定义其他与特定领域有关系的、语义的、结构化的标记语言的句法语言。XML具有简明有效、易学易用、开放、国际化、标准高效、可扩展等特点。它是一种简单、灵活的标准格式,为基于Web的应用提供了一个描述数据和交换数据的有效手段。使用XML有以下好处:使搜索更有意义,开发灵活的Web应用软件更简单,可实现不同的数据集成,适用于多种应用环境,方便客户端的数据处理和计算,数据标准满足个性化要求,局部数据可随时更新,与现有的Web发布机兼容,可扩展性高和有良好的压缩性能。

3.Web Service

Web Service是由URI标识的软件应用,其接口和绑定可以用XML来定义和描述并且可以被发现,与其他软件通过基于Internet的协议以XML消息交换方式直接交互。Web Service是实现SOA的具体方式之一,它是架构在XML和Internet之上的分布式计算技术。Web Service是系统集成中用来解决应用程序之间相互通信的技术,同时也是描述一系列操作的接口。在Web Service中需要一系列标准的支持,例如WSDL、UDDI、SOAP等,这些标准在角色、操作和构件三者之间起连接作用,如图3所示。

(1)WSDL(Web Service Description Language)包含文档或面向过程消息的端点操作信息的XML格式网络服务描述,可以绑定描述与SOAP、HTTP GET/POST和MIME技术。

(2)UDDI(Universal Description,Discovery and Integr-ation,统一描述、发现和集成)是一个规范,可以用于以Web Service为基础的信息注册,是一个公用的可接入集合,以登记的形式将信息登记出来以便可以发现这些服务。

(3)SOAP(Simple Object Access Protocol)是一种轻量级的编程,常用于没有控制中心、分布式的环境中交换信息,它以XML为基础,一般由信封、编码规则、远程过程调用和应答规则、捆绑方式组成。

4.CORBA、DOM、EJB

CORBA是Common Object Request Broker Architecture的缩写,简称公共对象请求代理体系,它由国际对象,管理组织OMG指定。在该环境下开发的软件既可面向对象又具有可重用性、可移植性及可操作性等特点。CORBA是一种分布式计算标准,其主要分三层:对象请求代理、公共对象服务和公共设施。CORBA是一种应用于开发和配置分布式应用的服务器端中间件模型规范,包括:抽象构件模型、构件容器结构和构件的配置以及打包规范。

5.ESB

ESB(Enterprise Service Bus)采用SOA原则,在大粒度服务级别通过事件驱动和基于XML的消息引擎,以与实现无关的方式集成企业应用的新型标准。它使用许多可能的传递消息协议来负责适当的控制流甚至还可能是服务之间所有消息的传输,相当于计算机的系统总线。模块(服务)都以松耦合连接到BUS上,以此方式来提高服务效率,ESB主要有智能路由(Routing)、传输(Transformation)和事件(Event)组成,如图4所示。

6.SOAD

SOAD(Service-Oriented Analysis and Design,面向服务的分析与设计),是专门为面向服务的体系结构范型设计的软件建模和开发方法,它建立在早期包括面向对象的分析和设计以及业务过程管理在内的过程开发基础之上。所有的设计方法都提倡信息隐藏、抽象和关注点分离。但是SOAD加入了对服务仓库、服务编排和企业服务总线的设计方法。SOAD是以架构为中心,以用例和业务过程驱动,迭代式开发方法。

四、基于J2EE的系统集成解决方案

不管是C/S还是B/S结构的系统软件,最终的目的只有一个——对各种服务的集成。软件技术发展到今天,EIS的集成出现了两大主流,即SUN的J2EE方案和MS的.NET方案,他们要做的都是将不同的服务进行集成后统一接口暴露给客户端。J2EE并非一个产品,而是一系列的标准。J2EE(Java 2 Enterprise Edition)技术的基础是Java 2平台,它提供了对EJB、Servlet、JSP、XML等技术的全面支持,其最终目标是成为一个支持企业级应用开发的体系结构,简化企业解决方案的开发、部署和管理等复杂问题。事实上,J2EE已经成为企业级开发的工业标准和首选平台。J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制。

J2EE平台通过新的JAX-RPC1.1 API提供完整的Web服务支持,这种API很好地支持基于Servlet和企业Bean的服务端点。JAX-RPC1.1基于WSDL和SOAP协议提供了与Web服务的互操作性。J2EE平台也支持Web Services for J2EE规范(JSR 921),它定义了Web服务部署需求并利用了JAX-RPC编程模型。J2EE1.4平台有以下优点:提供了一个多层应用程序模型,这意味着应用程序的不同部分可以运行在不同的设备上。J2EE结构定义了一个客房机层,一个中间层(由一个或多个子层组成),以及一个EIS层。基于容器的组件管理,J2EE基于组件开发模型的中枢容器(Container)概念,容器提供了组件服务的运行时(Runtime)环境,组件可以期望它们的服务在任何J2EE平台上都有效。所有的EJB容器提供对EJB组件的事务和生命周期管理的自动支持,并支持对EJB的查找或其他的服务。容器还提供对企业信息系统的标准化访问。J2EE1.4平台升级新增加的技术大部分和Web服务相关。在J2EE1.4平台下,开发、部署、发现Web服务变得非常方便。J2EE1.4提供了Web服务总框架,如图5所示,主要包括了:Web Services for J2EE、JAX-RPC、SAAJ、JAXR、Connector Architecture1.5等,其中JAX-RPC是J2EE1.4平台中Web服务的核心技术。除此之外,J2EE还声称支持WS-I Basic Profile1.0。

在J2EE平台下,Web服务器通过两种方式访问J2EE应用程序,一种是携带一组类型参数(最初的Web服务版本)的RPC风格调用(同步和异步),这种类型的服务调用非常类似传统的方法调用,使用在分布式对象和RPC实现中;另外一种则是消息传递风格调用(同步和异步),这种类型的服务调用类似传统的消息系统。客户在访问JAX-RPC API创建的Web服务,JAX-RPC就使用Servlet来实现相应的Web服务。Web服务的客户也可以通过Bean的服务端点接口访问无状态会话Bean。如果不采取消息的同一规范,则Web服务的客户不能访问其他类型企业的Bean。

五、总结

SOA将应用程序不同的功能单元,通过组件(服务)之间接口和契约联系起来,甚至将不同的应用系统整合成一个功能强大、服务性能强的系统。其接口采用中立的方式进行定义,我们一般称之为松耦合。松耦合的系统有很好的灵活性,当整个应用程序的每个组件的内部结构和实现逐个发生改变时,它能继续存在。接口独立于硬件、操作系统和编程语言,使得系统中的服务可以统一和通用的方式进行消息传递和交互。通过使用基于XML的语言WSDL来描述接口,相应的服务已经转到更动态且灵活的接口系统。以SOA为基础的系统集成很好地解决了信息孤岛的问题。

参考文献:

[1]全国计算机技术与软件专业技术资格(水平)考试办公室,2006年下半年试题分析与解答.北京:清华大学出版社,2007.

[2]张友生.系统分析师技术指南[M].北京:清华大学出版社,2007.

[3](美)科拉夫兹格,(美)本克,(美)斯拉姆著,韩宏志译. Enterprise SOA中文版——面向服务架构的最佳实战[M].北京:清华大学出版社,2006.

[4]梁爱虎.SOA思想、技术与系统集成应用详解[M].北京:电子工业出版社,2007.

[5]毛新生.SOA 原理·方法·实践[M].北京:电子工业出版社,2007.

[6]Stephen R.Schach.面向对象与传统软件工程[M].北京:机械工业出版社,2006.

[7]史济民等.软件工程——原理、方法与应用[M].北京:高等教育出版社,2002.

[8]喻坚,韩燕波.面向服务的计算:原理和应用[M].北京:清华大学出版社,2006.

基于SOA的数据集成 第4篇

MIS系统已经成为企业提高信息化程度的重要依托, 但是因为缺乏统一的规划和设计, 这些MIS系统在扩展和完善的过程中采用了不同的技术, 甚至数据库, 操作系统和设计语言都可能不同, 这样就带来了数据交换和数据同步的问题。通常我们把这些MIS系统称为“信息孤岛”, 数据同步和一体化成为解决问题的重要途径。

SOA是一种架构模型, 它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。SOA具有以业务为中心、灵活的适应变化、重用IT资源, 提高开发效率和更强调标准四个特点。因此, 它是适用于解决企业业务应用中的实际问题, 如分布式业务服务的通信, 信息资源整合等。

Web Service是现在最适合实现SOA的技术, 具有完好的封装性、松散耦合、使用协议的规范性、使用标准协议规范、高度可集成等特点, 非常适合于异构环境。

XML是一种面向应用的互联网标记文档包含内容和结构的语言。XML是可扩展的、平台独立的和容易在网络上传输, 所以它非常适合于描述数据同步和数据库集成的信息。

基于SOA的数据同步与集成解决方案

1解决方案的架构

基于SOA的Web Services体系结构有三个部分:services provider, services r egistry, services consumer。该解决方案可以被分为三层体系结构 (图1中所示) :应用层, 服务层和数据层。数据层包含各种需要集成的MIS数据库。服务层是解决方案的核心, 包括Web服务封装, 组成, 注册, 发现, 调用和数据映射模块。应用层包括应用程序客户端系统和信息门户。

2各层的功能

应用层包括应用程序、网站和客户端。该层中, 用户或客户端通过应用程序或网站发送SOAP服务请求。

服务层是为不同的用户提供统一的数据访问接口, 并完成以下功能:数据传输, 在services provider和services consumer之间进行数据交换, Web Service的注册功能, 发现和调用, 在XML和XML之间动态数据交换。

根据MIS系统集成的需求, 数据层API函数或ADO.NE T连接数据库, 然后封装成Web Service的数据, 其中包括Web服务描述 (WSDL) 和服务数据。Web服务描述定义地址, 传输协议, Web Service的接口。Web Service单元是基本实体, 基本服务不能再分割, 也不能包含其它服务。

网站和SSO的实现

网站是基于Web的应用程序, 主要是提供个性化的显示, 单点登录 (SSO) , 不同来源的内容集成和信息存储。

1跨域SSO

异构MIS系统也许在不同的域, 每个系统都有自己的认证机制, 也没有可供参考的授权信息。因此, 跨域单点登录的实现是必要的。

SSO自动授权是建立在所有分散用户帐号的集中管理系统的信任关系之上。因为所有的用户信息存储和管理是在统一模式下完成, 所有的工作管理员需要做的就是在一个统一的用户信息数据库添加、修改或删除用户。

2统一身份认证

统一身份认证 (UIA) 中 (如图2中所示) 的原理是, 在对话中当用户访问认证保护的资源, UIA服务器将生成一个称为令牌的验证凭证, 其中包含用户的身份信息和一个随机数, 从而使用户能够访问异构资源, 无需重新验证。

2.1域认证程序

一, 浏览器访问应用服务器A。

二, 应用服务器A发现没有用户登录, 然后将浏览器重定向到统一登录页面, 用户输入登录信息。

三, 登陆页面发送认证要求给身份认证服务器, 服务器调用认证Web Services。

四, 身份认证服务器生成令牌, 它记录在数据库中, 然后验证浏览器的用户令牌如果是有效的, 否则重定向到登录页面。

五, 浏览器访问应用服务器A的令牌。

六, 应用服务器A发送请求给身份认证服务器授权令牌。

七, 身份认证服务器响应身份验证信息到应用服务器A。

八, 如果验证是有效的, 应用服务器A显示浏览器请求的资源, 否则重定向到登录页面。

2.2跨域认证程序

(1) 浏览器访问应用服务器B;

(2) 应用服务器B按照自己的身份验证机制, 如果没有找到用户的登录信息, 则发送请求到身份认证服务器验证登录信息;

(3) 身份认证服务器执行数据库查询操作和响应令牌信息发送到应用服务器B, 否则重定向到登录页面;

(4) 应用服务器B将显示用户请求的资源。

Web服务封装

1支持MIS系统编程接口 (API) 的封装

根据服务标准, 第一, 封装功能组件到Web服务组件, 然后用WSDL描述服务和写入从XML文档提取的数据。整个过程可以分为以下几个阶段:API函数库引用, Web Services对象声明, Web服务方法声明, 调用API函数操作数据库和释放本地应用程序对象的引用。

2封装访问MIS系统的Active X数据对象 (ADO)

封装ADO访问Sql Server或者ORACL数据库是通过Data Set组件的Write Xml方法, 方法由Sql语言的基础上提取数据, 然后辨别XML文档。

异构数据同步和整合

数据同步的过程是将应用系统的数据当前状态和另一个的异构系统相关的数据保持一致, 这个过程忽略数据操作的细节。目前, 数据同步没有标准的定义, 本文所述数据同步是指可以实现在异构平台多数据库的数据一致性的技术方法, 可以分为单向数据同步和双向数据同步。

1数据同步

1.1单向数据同步

数据流从一个数据库到另一个数据库是单向的。在这个过程中, Node B只需要对Node A进行查询操作, 不涉及插入, 修改和删除。换句话说, Node A是主域和Node B是从域, 数据流不冲突。数据同步操作发生时, Node A的数据已经改变了。

1.2双向数据同步

Node A和Node B的数据流是双向的。这包括两种模式, 一种是Node A上需要Node B上的数据, 反之亦然。但Node A与Node B的数据必须是独立的, 并在不同方向的数据流没有交集, 数据操作只包含查询, 修改, 删除, 不涉及插入。另一种是Node A和Node B操作修改、删除、插入, Node A和Node B可以运行相同的数据, 这可能使数据不一致的, 因此在该模式中, 数据不匹配是关键的问题, 需要采取措施来防止数据冲突。

2数据同步和集成的双XML交换模型

2.1双XML交换模型

本文提出了一种双XML交换模型, 实现基于Web Service的数据同步和整合。主要是通过Web Service从源数据库将数据抽取到源XML文档, 并通过映射规则将数据映射到目标XML文档, 最后, 将目标数据写到目标数据库。

2.2 XML的映射规则

将所需的数据封装成XML格式的Web Service需要一个将XML源文档转换到目标文档的映射文档。XML文档映射结构可分为四个部分 (如图4所示) :源XML结构信息, 目标XML结构信息, 映射规则和映射规则的条件。

<synchronization>:用户定义的映射规则。“ID”属性值, 映射规则的名称, 可用于查找所需的映射规则。

<source>:描述源数据表结构。

<goal>:描述目标数据表的结构。

<dataschema>:“Name”属性值描述数据库的方法。

<mapping>:此项定义源字段和目标字段之间的对应关系。“源”的属性值等于源字段的名称, “目标”的属性值等于目标字段的名称。“ispropertymatch“定义源字段映射字段, 如果当前字段是映射字段, 则属性值为“是”, 它需要检查源表的内容是否存在选择更新操作或者插入操作。

<conditions>:此项定义了一个重要条件。

基于上述映射规则, XPath和XQuery查询语言通过查询过程的可执行功能将Web Service的XML文档转换成统一结构的XML文档, 以满足复杂的查询要求。

目标XML文档是一种联合数据集, 可以映射和转换到关系数据库和封装成粗粒度的服务和UDDI中心注册联盟的数据集。

UDDI中的Web Service操作

1 Web Service模型建立

在Web服务模型的建立之前需要确认模型文件是否存在。如果基于WSDL的Web Service存在, 则记录名称和关键键, 否则, 创建一个新的模型接口, 具备一个统一资源定位的WSDL文件名称和索引。

2转换规则

源模型 (图3) 的业务模式包含各种类模型。在此模型中的元素主要是类。

3 Web Service的注册

注册可以通过编程或用户界面实现。本文利用微软UDDI.NET SDK编程工具。

4 Web Service的发现

进度的查询可以分为以下几个步骤:创建调查对象并设置调查URL参数, 声明Find Business对象并设置查询服务名称和性质, 获得Web Service Business List对象然后搜索Business Info, Service Info Business Service, 该Binding Template反过来, 最后获得Access Point对象和调用Get Text () 方法来获取URL Web Service。

5 Webservice的调用

调查后, 服务请求得到给定的URL, 然后调用Web Service, 它通过使用SOAP消息通过防火墙, 最后绑定到应用程序流来实现数据交换。在实际应用中, 有必要建立一个代理类, 可以交流给定的网络服务。为了使用代理类, 必须生成一个CS文件并添加到应用程序项目。

实例

假设以下实例, 补贴信息系统 (系统A) 需要同步学生基本信息, 学生信息系统 (系统B) 。系统A和B连接UDDI服务器可以通过SOAP或WSDL XML消息服务组件同时发送和接收的XML消息。

当数据更新时, 数据库触发器被触发。Web Service服务器将数据封装成Web Service, 然后在UDDI注册中心发送消息到消息队列。应用系统访问Web Service的URL获取XML文档, XML映射文件处理后, 应用系统将数据写入到目标数据库。整个数据过程显示在图3, 图4中显示XML文档映射。

结论

基于SOA的数据集成 第5篇

摘要：依据数据集成的理论与方法，采用Mediator/Wrapper中介器法，设计开发了基于XML的水上项目异构数据集成系统，实现对水上项目各异构数据源中数据的集成查询，并在此基础上进一步开发了用于我国各水上项目国家队在线交流和协同工作的协同办公和专家研讨厅功能模块，为各训练队实现信息共享和在线沟通提供了便捷的应用系统。水上项目国家队数据库网络管理平台有效解决了水上项目国家队的“信息孤岛”问题，对提高我国水上项目训练和管理的信息化水平提供了有效的支持。

关键词：水上项目；数据集成；数据库；XML

中图分类号：G80-058 文献标识码：A 文章编号：1006-2076（2015）01-0001-07

Abstract：This study， based on the theory and method of data integration and using the Mediator/Wrapper meditator， has designed and developed a heterogeneous data integration system for water events based on XML， and realization of the integrated query of the data. On this basis， we have developed international online communication and coordination and expert discussion modules to provide a convenient database application system for information sharing and training. The database management platform has solved the problem of "Information Island" efficiently and provided efficient support for improving the information level of the training and management of aquatic events.

Key words： aquatic events； data integration； database； XML

水上运动项目（皮划艇、赛艇、帆船帆板和激流回旋等）是奥运会的“金牌大户”。近年来，我国水上项目运动成绩取得了重大突破，这些突破与其训练和管理的科学化是分不开的。在当前信息技术快速发展的形势下，我国水上运动项目的信息化建设也取得了明显进展，并对各单项的训练、科研和管理工作发挥了重要作用。但由于各单项运动项目业务与功能的不同，各运动项目队已建成的信息管理系统的数据源往往彼此独立、相互封闭，大量训练数据难以在系统之间交流、共享和融合，从而形成了“信息孤岛”。如何将这些异构的数据源集成起来，联通“信息孤岛”，实现有效的信息查询，成为当前迫切需要解决的问题。

本研究正是为了有效整合水上项目各训练队信息管理系统数据库，集成现有的大量异构数据资源，解决我国水上运动项目“信息孤岛”问题而展开的。研究从信息标准化入手，通过数据集成和协同工作的理论和方法，开发了一套集水上运动项目数据集成、协同工作和多媒体管理为一体的训练管理平台，从而有效解决水上项目国家队数据库管理和相关人员沟通困难的难题。

1 我国水上项目信息系统现状分析

1.1 运动项目信息管理系统构建的异构性

目前，国家体育总局水上运动管理中心主管的项目主要有皮划艇、赛艇、激流回旋和帆船帆板等。近年来，在各国家队的信息化建设中，各运动项目已经建成了各自的科学化训练管理信息系统，但这些系统都是由不同单位在不同时间进行建设的，各训练管理系统的开发语言和数据库结构表现出很大的差异（如表1）。这种差异致使大量科研、训练数据难以在系统之间交流、共享和融合，无法进行数据的深入挖掘。

1.2 协同工作的需求日趋强烈

当前，各水上项目国家队的信息系统多为数据库管理模式，用户只能根据数据库结构录入、编辑和查询数据信息，无法满足用户间协同办公的需求。随着水上运动各项目对协同办公要求的不断提高，大多训练队不仅需要解决日常办公、业务管理、信息交流等常规协同的功能，在即时沟通、数据共享等方面也提出了更进一步的需求。

1.3 多媒体资料难于存储和管理

比赛录像是水上运动项目训练重要的资料数据，但录制的图像信息量较大，一般信息系统难于存储，同时录像资料的检索也是一个难题，如何将大量的比赛录像数据存储起来，同时提供方便、易用的查询和播放平台是当前水上运动项目信息化建设需要解决的难题。

2 水上项目国家队数据库网络管理平台主要功能模块设计

水上项目国家队数据库网络管理平台以水上运动项目数据库集成、用户在线协同工作和多媒体资料管理为目标，以数据库标准化解决方案为基础，向用户提供了数据库综合管理、协同办公、本地专家研讨厅、比赛录像管理和用户设置5种主要的功能模块，如图1所示。各模块的功能描述如下：

2.1 数据库综合管理

数据库综合管理是整个平台的核心内容，它是一个通用的数据库管理框架，通过简单的配置，即可实现跨数据库、跨服务器的可视化数据管理。通过数据库综合管理模块可以实现水上项目各异构数据库信息的有效集成，并完成数据的浏览、打印、导入、导出和联合查询等功能。数据库综合管理包括数据库连接配置、数据信息查询、数据信息编辑、数据打印输出和数据库权限管理5个功能模块。

2.2 协同办公

协同办公是提升水上项目内部公文处理的主要应用模块。它以“平台化”的结构实施资源整合，将“人与人协作”的业务集中统一处理、统一服务，并提供更便捷的业务开发方式，来提升水上项目内部对业务处理的响应速度。协同办公模块提供了接收公文、发送公文、通知公告、已发公文、流程设置和模板设置6个子功能模块。

2.3 本地专家研讨厅

本地专家研讨厅是依据计算机支持的协同工作（Computer Supported Cooperative Work，CSCW）技术设计的信息实时交流与共享模块，它包括电子白板，音、视频数据交流，文本交流和专家列表4个子功能模块。

2.4 比赛录像管理

比赛录像管理模块是依据运动员、教练员平时察看录像信息的需求而设计的，模块包括添加比赛录像、观看比赛录像和删除比赛录像等功能，这为用户在线分享多媒体资料提供了方便。

2.5 用户设置

水上项目国家队数据库网络管理平台为每一个需要使用本平台的人员提供了一个平台帐号和密码，用户可以通过自己的帐号和密码登录平台。用户设置是维护系统登陆正常运行的基础保障模块。用户设置模块提供对当前系统使用者的姓名、性别、职业、专业、联系方式等基本信息管理，同时可以设置使用者的使用权限。用户设置模块包括添加用户信息、修改用户信息和删除用户信息3个子功能模块。

3 水上项目国家队数据库网络管理平台的系统结构设计

3.1 系统总体结构设计

水上项目国家队数据库网络管理平台的总体体系结构如图2所示，系统通过统一的数据访问接口，向本地和远程的水上项目各训练信息系统进行访问。统一数据访问接口可以屏蔽底层物理位置、数据逻辑结构等细节，使上层应用系统能方便地通过它提供的标准对数据库进行各种操作，在此基础上，进一步开发各种

应用功能模块，实现我国水上运动项目各信息系统的数据集成和协同工作。

3.2 数据集成系统的体系结构

水上项目数据集成系统是我们自行设计开发的异构数据集成系统，系统采用了Mediator/Wrapper（中介器法）体系结构进行设计。系统使用XML Schema建立公共模型，采用标准的XML格式进行信息交换，系统的体系结构如图3所示。

水上项目国家队数据库集成系统的系统结构由数据层、中间层和应用层三层结构组成，各层结构的主要功能如下：

3.2.1 应用层

水上项目国家队数据库集成系统的应用层为终端用户提供统一的全局查询界面，教练员、管理者等可以通过应用层的浏览器进行查询操作。各数据源返回的数据经过系统中间层集成处理后以XML的形式返回，应用XSLT（eXtensible Style sheet Language Transformations，可扩展样式表语言转换）显示在用户查询结果浏览器页面中。

3.2.2 中间层

中间层是水上项目国家队数据库网络管理平台实现异构数据集成的主要业务逻辑。中间层包括公共模型模块、注册器、查询处理器和结果集成器等多个部分。中间层的首要任务是构建公共模型，公共模型的建立是整个异构集成系统的运行基础，为查询分解和结果合成提供参考。然后，中间层接收到应用层的查询请求后，生成XQuery全局查询，查询处理器根据公共模型中的映射关系将全局查询分解为对应各数据源的子查询，并将各子查询文档包装为SOAP消息，通过调用相应的Web服务，传送到对应的数据源包装器。最后，在包装器中由查询转换器将XQuery子查询转换为局部数据源可识别的查询语句，并执行具体查询任务。结果集成器接收由各数据源返回的XML形式的结果片段，合并后返回给应用服务器，并按应用层用户所需的样式在浏览器中显示。

3.2.3 数据层

数据层包括包装器（Wrapper）和异构数据源两部分，包装器用于将不同的数据源转换为一个公共的数据模型，数据源是水上项目国家队数据库网络管理平台各异构数据源的集合。数据源可以是关系数据库、面向对象数据库、半结构化的XML文档以及HTML文档等。

4 系统关键技术与核心功能的设计与开发

4.1 平台主界面开发

水上运动项目训练管理信息系统采用框架式结构设计开发。用户主界面按左右分栏，左侧为导航栏，提供数据库管理、协同办公、专家研讨厅、比赛录像、用户管理主要功能的切换进入，右侧为操作区，相应功能操作、信息显示、人机交互等主要在操作区完成，如图4所示。

4.2 数据综合查询功能设计

数据综合查询是水上项目国家队数据库管理模块最主要的功能。为了满足用户的多种使用需求，数据库综合查询方法包括分综合数据查询和自定义查询两种，前者是计算机根据用户选择的数据表名称，自动遍历数据表结构和字段类型，显示表单中的全部内容；后者则是根据用户自定义的查询字段，在数据表中查询出符合查询条件的数据内容。

4.2.1 数据库综合查询的工作过程

水上项目国家队数据库综合查询的工作过程是，首先接受用户输入全局数据查询信息，根据公共模型将全局查询分解为针对各异构数据源的子查询，将各子查询传递给各数据源执行，各数据执行的子查询结构根据公共模型进行结果合成，组成以XML结构表达的结果文件返回给用户。系统的工作过程如图5所示。

首先，用户利用集成查询用户界面提出查询要求，系统将用户查询转化成对全局模式的查询文档（全局XQuery查询文档）。查询处理器根据公共模型中局部模式与全局模式的映射关系，将全局XQuery分解为针对各个数据源的XQuery子查询。然后将XQuery子查询文档包装为SOAP消息传递到各数据源包装器（Wrapper）。各子查询在通过查询转换器转化为各数据源的内部查询，并执行查询。各数据源的查询结果通过结果转换器转换成XML文档。结果集成器对各数据源返回的查询结果XML文档做集成处理，依据局部模式与全局模式的映射关系，合并不完整的数据和过滤不符合查询条件的数据，组合成统一的最终查询结果向用户提交。结果文档到达客户端后，可使用XSL样式单对结果进行排版和显示。

4.2.2 综合数据集成查询

综合数据查询是系统根据用户选择的数据库和数据表名称自动遍历该数据表的结构和内容，并将该数据表的全部内容通过统一显示界面完整地显示给用户（如图6），通过该方法可以方便地将SQL Server、Oracle等不同类型的数据库内容显示出来，避免了用户不断登陆不同信息系统平台而浪费时间。

4.2.3 自定义数据集成查询

自定义数据查询是为满足用户在不同信息系统数据库间综合查询数据而开发的查询模块。模块依靠FLASH技术提供了一个可自定义的查询界面设计器（如图7），通过表单设计器用户可以添加输入框、选择

框和时间控件等，整个操作是可视化的，设计界面的控件可以自由拖动，并且设置属性。添加控件后，用户可以在该界面的SQL语句输入区，输入自定义的查询语句，如以下语句则显示图8所示内容：select team_id 所属训练队，chief_coach_id 总教练，trainer_id 教练员，jihrq 计划日期，zaocheng 早晨，shangwu 上午，xiawu 下午，wanshang 晚上，zhixing 执行，beizhu 备注 from yundd_xunljh where team_id like ～input1%～ and trainer_id like ～input2%'～and jihrq like ～date3%～。

4.3 专家研讨厅的设计与开发

水上项目国家队训练工作是一个复杂的系统工程，需要教练员、运动员和科研人员的共同参与，众多参与者集思广益、共同讨论是水上项目训练工作必不可少的一部分。为了满足水上项目专家实时进行异地讨论和工作指导，我们设计了一个具有音频、视频和多媒体沟通功能的水上项目专家研讨厅模块。该模块提供了共享白板、语音视频通讯、文本通讯和专家列表4个主要的功能服务，通过该模块教练员、运动员和项目专家可以进行各种工作交流，将各种训练信息进行分类、筛选、加工并通过网络实现信息共享，极大提高了水上项目训练工作的效率。

4.3.1 水上项目专家研讨厅系统设计

水上项目专家研讨厅采用了大量的界面技术及服务器技术进行设计和开发，使用DOM（Document Object Model）和Action Script（AS）编写界面操作，采用flash视频技术提供视频及音频功能，采用Flash Media Server （FMS）作为服务器端。RTMP（the Real-time Messaging Protocol）协议作为客户端和服务器端的传输协议，这是一个专门为高效传输视频、音频和数据而设计的 TCP/IP 协议。该协议建立在TCP协议或者轮询HTTP协议之上。其系统工作模式图如图9所示。

4.3.2 水上项目专家研讨厅主要功能分析

4.3.2.1 共享白板

共享白板是水上项目国家队数据库网络管理平台应用中的一个重要工具，它指的是一个虚拟工作区域，在这个区域中各终端人员可以共享.doc、.ppt、.jpg、.htm等格式的文档，也可自己手工绘制图形。

白板数据是共享数据，当一个用户在白板上绘制或修改了数据后，其更新结果将即刻反映到其他用户的白板上，即所谓的“你见即我见”（WYSIWIS，What You See Is What I See）功能。通过本模块教练员可以共同浏览训练计划，分析训练现场图片，制定出有效的训练计划和战术等。

4.3.2.2 语音视频通讯

临场感是在专家研讨过程中最为关注的一个感受，因此如何在研讨厅提供语音视频通信也是一个重要内容。水上项目国家队数据库网络管理平台的音、视频交流依据目前较为成熟的理论技术，经过音视频采集、音视频压缩、传输、解析、播放这样几个过程，专家通过摄像头和麦克风采集的图像和声音，在研讨厅中可以进行音、视频的交流，每一个专家可以设定自己在研讨会议中的声音、图像使用情况，即是否进行发言，是否允许其他人观看自己的图像。

4.4 比赛录像管理系统的设计与开发

比赛录像是水上运动项目进行比赛总结、战术分析、训练指导、科学研究的第一手资料，这部分资料也是弥足珍贵的。比赛录像管理模块是水上运动项目多媒体资料管理的重要功能模块，该模块实现了视频资料上传、压缩、截图和播放多个重要功能

4.4.1 视频资料压缩和截图

比赛录像是水上运动项目训练重要的资料数据，但录制的图像信息量较大，同时检索也是一个难题。水上项目国家队数据库网络管理平台通过视频压缩和截图的方式，将视频资料压缩为FLV（FLASH VIEDO）格式，由于这种格式形成的文件非常小，加载速度极快，方便了大量视频资料的上传，该模块采用ffmpge组件实现，使图像信息在水上项目训练、比赛策略分析方面取得重大进步。视频信息采用图片配合文字的方式进行排列，通过文字名称可以基本确定寻找的内容，图片显示了主要的视频内容，生成时间和发布人用于录像信息的甄别和管理。

4.4.2 视频播放器

为了良好地播放视频，系统采用flash进行了视频播放器的开发，视频播放器可以内嵌在皮划艇项目数据库网络管理平台的客户端页面中，也可以通过用户控制呈现为完整的控制页面，进行录像播放。视频播放器从数据库加载播放地址，并进行播放。通过以上技术，实现了比赛录像管理的各个功能，即使在较差的网络环境下比赛录像仍可以流畅播放。

5 小结

5.1 水上运动管理中心的项目（业务部）多，其训练基地相对分散且相距较远，需要将每个项目训练队的训练信息进行数据集成，进行网络化管理，便于管理者和教练员了解和利用相关信息与数据。

5.2 不同的运动项目队（部）业务与功能不同，已建成的信息管理系统的数据源往往彼此独立，训练数据难以在系统之间交流、共享和融合。本研究成果从信息标准化入手，采用数据集成和协同工作的理论和方法，开发了一套集水上运动项目数据集成、协同工作和多媒体管理为一体的训练信息管理平台，有效地整合了水上项目各训练队信息管理系统数据库，集成现有的大量异构数据资源，解决了我国水上项目国家队数据库管理和人员沟通问题，实现了有效信息的集成查询与分析。

5.3 本研究开发的用于我国各水上项目国家队在线交流和协同工作的协同办公和专家研讨厅功能模块，能够实现水上项目各训练队间的信息共享和在线沟通，在一定程度上提高了水上项目训练和管理的信息化水平。

5.4 水上项目国家队数据库网络管理平台是信息技术的产物，它具有信息技术广泛的渗透性和关联带动作用，是水上项目训练队进行技术创新的重要工具。水上项目各训练队在技术创新的活动中，可以运用此平台进行项目科学技术信息的收集、整合和利用，进而提高项目技术创新的效率和效果，增强项目的竞争力。

参考文献：

[1]李晨峰，张晓琳. 中国国家队科研现状及发展讨论[J]. 中国体育科技，2009（3）.

[2]赵云宏. 新时期我国体育信息化建设若干问题的思考[J]. 中国体育科技，2005（4）.

[3]马利成. 基于XML的异构数据集成系统的研究与实现[D].上海：上海交通大学， 2007.

[4]李光军，郭建伟，彭李明，周彤，洪伟，朱宁. 国家帆船帆板队信息化平台的设计与应用[J]. 武汉体育学院学报，2009（9）.

[5]周长城. 国家帆船帆板队信息平台的构建及应用[D].武汉：武汉体育学院， 2007.

[6]郭建伟. 关于体育信息资源利用和整合的思考[J]. 武汉体育学院学报，2006（9）.

[7]胡彪， 饶坚， 姚蕾， 唐义梅. 体育信息整合暨区域间信息共享的研究[J]. 武汉体育学院学报，2006（2）.

[8]孔军，易勤.面向用户的竞技体育信息集成服务平台建设研究[J]. 武汉体育学院学报，2009（8）.

[9]李燕.构建安徽省竞技体育信息服务体系研究[J]. 哈尔滨体育学院学报，2011（6）：44-47.

[10]孔军. 体育信息资源的跨系统整合研究[J]. 南京体育学院学报：社会科学版，2009（3）.

[11]华音，胡彪，谢晓云. 体育信息资源共享的现状、问题和措施[J]. 体育文化导刊，2005（10）.

[12]辛丽，丁锴，沈雍兰. 江苏体育信息资源整合研究[J]. 南京体育学院学报：然科学版，2011（6）：3-6.

[13]钟亚平. 信息技术在运动训练中的应用与展望[J]. 武汉体育学院学报，2008（6）.

[14]杨旭.竞技体育中的信息作用与传导研究[J]. 安徽工业大学学报：社会科学版，2012（5）：166-167.

[15]徐冰. 基于BP网络的击剑训练负荷分析系统的研究与开发[D].青岛：中国海洋大学，2004.

[16]汪桂兰.数据挖掘分类技术及其在击剑负荷分析中的应用[D]. 青岛：中国海洋大学，2006.

[17]雷建和.基于多源信息融合的人体运动分析与建模研究[D].合肥：中国科学技术大学，2006.

[18]马静华.基于运动信息获取及智能处理的运动员训练指导系统研究[D].合肥：中国科学技术大学，2006.

[19]张立， 潘志琛， 袁俊杰， 刘畅， 李劲松. 国家队实用管理信息系统的研制与应用[J].天津体育学院学报，2006（6）.

[20]黄国言，李晓冬. 协同工作（CSCW）下协作模型的研究[J]. 计算机工程与应用，2006（22）.

[21]华桦，王丽洁. 体育信息在大型赛事备战中的采集与个案分析[J]. 山东体育科技，2013（4）：70-73.

[22]李鹏. Web环境下企业产品信息共享的若干关键技术研究[D].西安：西北工业大学，2006.

[23]臣勇，须德.基于Internet的视频会议系统的设计与实现[J].计算机工程与应用，2005（13） .

[24]杜呈伟，李伟荣，吴国新. 基于B/S的电子白板的设计与实现[J].计算机工程与设计，2006（16） .

[25]肖万贤，刘江宁. 企业数据集成模型的研究[J]. 计算机工程与科学，2004（5）.

[26]刘桂文. 现代电子信息技术对竞技体育的影响[J]. 当代体育科技，2014（26）：173-174.

[27]袁晓洁， 于士涛， 李志梁. 基于Mediation的异构数据集成系统HDIS设计与实现[J]. 计算机工程与应用，2006（1）.

基于SOA的企业应用集成研究 第6篇

“信息孤岛”催生了企业应用集成 (EAI, Enterprise Application Integration) 技术的产生与发展。EAI使企业内部的ERP、CRM、SCM、数据库、数据仓库等应用之间无缝地共享和交换数据。但是, 传统的EAI使用CORBA、DCOM、JCA等技术实现分布式、跨平台的应用交互, 缺乏开放公用的标准, 其实现与特定厂商的私有技术紧密关联, 限制了企业应用集成的发展。

面向服务体系架构 (SOA, Service-Oriented Architecture) 的出现, 为EAI提供了新的解决方案。SOA要求开发者从服务集成的角度来设计应用系统, 充分挖掘、重用企业现有系统中的业务和数据资源, 并以新的形式重新集成各类应用系统[1], 从根本上解决了“信息孤岛”与业务无法协同等问题。

2、传统EAI解决方案

2.1 基于CORBA的企业应用集成

公共对象请求代理架构 (CORBA) 是分布式对象技术在异构环境下进行分布式开发的一种有效解决方案。如图1所示, 基于CORBA的企业应用集成的基本方法是以企业模型、信息共享模型为基础, 以产品为对象, 以产品开发过程为核心, 利用软件总线和构件技术, 来开发不同应用软件的接口适配器, 以实现各种应用软件的即插即用以及彼此之间的信息交换与共享。

2.2 基于COM/DCOM的企业应用集成

COM/DCOM技术是Microsoft在对象连接与嵌入 (OLE) 基础上发展起来的构件接口规范, 提供了构件开发、运行和集成的环境。如图2所示, 基于COM/DCOM的企业应用集成以组件对象模型为核心, 建立了一套组件形态标准和接口标准, 以确保不同厂商、不同语言、不同操作系统的组件具有二进制级的互操作性, 并通过RPC (即对象RPC或ORPC) 实现远程调用。

2.3 基于J2EE/JCA的企业应用集成

J2EE连接器架构 (JCA) 是SUN公司与其合作伙伴提出的一种基于J2EE的体系架构规范, 用来集成J2EE组件与企业信息系统 (EIS) , 为应用服务器和EIS的连接提供JAVA解决方案。如图3所示, 基于J2EE/JCA的企业应用集成模型提供了包装和部署设施, 各种应用能够以EJB组件的形式“插入”到J2EE应用服务器中。

2.4 基于MOM的企业应用集成

消息中间件 (MOM) 能在消息的生产者和消费者之间建立连接, 并支持分布式应用程序之间消息的可靠传递。如图4所示, 基于MOM的企业应用集成模型提供了应用集成所必须的数据传送、过滤、映射和路由等功能, 屏蔽了不同硬件平台、消息格式、通信协议之间的差异, 使不同应用之间具有高效、便捷的通信能力。

通过对上面几种模型的阐述, 可以看出, 传统的EAI解决方案主要存在以下缺陷。

首先, 传统的EAI大多是点到点的集成, 不同应用之间需要一个专有的“适配器”来进行连接。当需要集成的应用较多时, 这种逻辑关系就会成级数增加, 需要花费大量的时间和精力。

其次, 企业不同应用之间相互依赖, 需要了解彼此内部的具体实现方式, 使得集成架构缺乏“柔性”和可扩展性, 应用功能随业务需求灵活变化的便捷性较差。

最后, 不同的应用和数据源使用不同的接口和数据格式, 没有统一、公开的标准和协议, 增加了维护的复杂度和成本, 同时, 难于实现在其它集成架构中重用。

3、基于SOA的企业应用集成架构

在传统EAI解决方案基础上, 通过引入SOA中企业服务总线 (ESB) 和业务流程编排 (BPM) 等技术;同时, 利用成熟的Web Services技术实现对不同应用的服务封装, 得到了如图5所示的基于SOA的企业应用集成架构。

下面具体介绍架构中各层的定义和实现的功能。

3.1 应用系统层

包含企业现有的CRM、SCM和ERP打包应用程序等, 以及一些遗留的基于对象的系统实现、业务智能应用程序。

3.2 组件层

组件层支持将不同技术实现的应用系统通过封装的方式部署在集成架构中。具体实现是利用Web Services技术对应用系统进行服务封装, 以WSDL形式向外暴露接口, 使用SOAP消息传输方式进行交互[3]。Web Services技术屏蔽不同应用系统的实现细节, 实现了以松散耦合的方式使用服务, 因此当服务内部的具体实现变更时, 只要WSDL描述的接口不变, 就不会影响服务的调用。

3.3 连接层

连接层位于组件层之上, 实现对服务的部署、管理、控制和调用等功能, 这里借助企业服务总线来实现。ESB是过去消息中间件的发展, 采用总线这种模式来管理和简化企业应用集成的拓扑结构, 以开放的标准为基础来实现不同应用之间在消息、事件和服务级别上的互联互通[4], 克服了点对点集成过程中的不足。

3.4 服务层

服务层包括Web服务平台和可用的Web服务, 实现服务的发布、注册、查询和调用等功能。Web服务被封装实现后在IIS中发布或在UDDI中注册。服务请求者可以通过IIS获取服务地址直接调用, 也可以在UDDI中通过搜索与之需求匹配的服务进行调用。

3.5 流程层

流程层定义了服务层中Web服务组合和编排的形式, 通常使用基于XML的业务流程执行语言 (WS-BPEL) 进行业务流程描述。服务的不同组合方式代表了企业的不同业务过程, 从而实现动态业务模型[5]。当业务流程发生变化时, 只要调整服务之间的编排方式, 就可以快速灵活地响应业务需求。

3.6 表示层

表示层位于架构的顶层, 为企业应用提供用户交互界面。可以说, 表示层实现了对服务的集成, 为外部访问不同的应用系统提供了一个接口, 服务调用的过程对用户来说是透明的。

4、结语

本文针对传统EAI解决方案中的不足, 基于SOA思想, 提出了一种面向服务的企业应用集成架构。该架构具有SOA的松散耦合、可重用和高度可集成等特征, 能有效地集成企业现有资源, 提高业务敏捷能力和消除“信息孤岛”。

摘要：随着企业信息化进程的推进, 迫切需要消除企业间以及内部的“信息孤岛”, 以实现不同应用系统间既相互独立, 又能信息共享、业务协同。本文针对这个问题, 提出了一种基于SOA的企业应用集成架构, 并详细设计了架构中各层的功能。

关键词：SOA,EAI,信息孤岛,服务

参考文献

[1]毛新生.SOA原理方法实践[M].北京:电子工业出版社, 2007.

[2]刘松.面向服务的企业应用集成架构[J].吉林大学学报, 2005 (6) :657-663.

[3]丁兆青, 董传良.基于SOA的分布式应用集成研究[J].计算机工程, 2007, 33 (10) .

[4]谢小轩.企业应用集成综述[J].计算机工程与应用, 2006, 38 (22) .

基于SOA技术的BOM集成研究 第7篇

产品全生命周期管理(Product Lifecycle Management,PLM)是指管理产品从需求、规划、设计、生产、销售、运行、使用、维修保养、直到回收再用处置的全生命周期中的信息与过程。BOM(Bill of Material,物料清单)作为企业主要基础数据,在CAD/PDM/CAPP/MES等PLM关键应用分系统的集成中,发挥着至关重要作用。它不仅仅是PLM分系统自身数据的核心,同时也是各个分系统数据集成的纽带。

在产品生命周期的不同阶段,由于产品结构关系的不同,存在着各种不同的BOM,如设计BOM(Engineering BOM:EBOM)、工艺BOM(Plan BOM:PBOM)和制造BOM(Manufacturing BOM:MBOM)等。在飞机、汽车等制造与装配行业,由于BOM结构复杂、各种BOM的转化与调整较为频繁,所以实现不同BOM之间的数据转换以及数据集成管理是飞机、汽车等行业实施PLM的关键所在。文中以企业的产品数据管理系统和工艺管理系统的集成为例,探讨了PDM与CAPP两个异构系统之间的BOM数据交换的实现方式。

2 关键技术分析

随着企业信息化建设的深入,许多企业都逐步建立了各类应用信息系统,由于各个信息系统都是独立开发的,并且大多数是基于部门需求从单项业务系统开始的,所采用的开发方式和平台各不相同。设计部门采用的PDM系统大都是基于J2EE架构的Web平台,具有不同的系统架构和外部接口;由于工艺编制界面多样,工艺部门采用的CAPP系统采用微软的技术平台,也具有多样性与异构性的特点,因此必须采用基于平台无关的技术来实现通用的CAPP和PDM系统的集成。

2.1 SOA概述

为了解决企业中由于位置上分散的独立系统而逐渐形成的“信息孤岛”问题,以及更好地重用已有系统的功能模块、缩短软件的开发及实施周期,一种面向服务的体系结构SOA(Service Oriented Architecture)的软件设计方法被提了出来。相对于面向对象和基于构件的软件复用方法,SOA提供了构建松散耦合的分布式系统的方法,能够达到更高的复用度和更好的扩充性。

2.2 SOA体系结构

SOA是一种基于组件模型的面向服务的软件体系结构,它通过服务间定义的透明接口,将应用程序的不同功能单元的服务(Service)连接集成起来,同时,接口采用独立于具体实现服务的硬件平台、操作系统平台和编程语言的中立方式进行定义,使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。简单来讲,SOA能够以程序化的、可访问软件服务的形式公开业务功能,以使其他应用程序可以通过已发布和可发现的接口来使用这些服务。

SOA模型中共有3种不同角色的关系(服务代理者、服务提供者和服务消费者),如图1所示。

(1)服务提供者(Service Provider)。发布自己的服务,并且对使用自身服务的请求进行响应。

(2)服务代理(Service Broker)。注册已经发布的服务提供者,对其进行分类并提供搜索服务。

(3)服务请求者(Service Requester)。利用服务代理查找所需的服务,然后使用该服务。

SOA体系结构中的组件必须具有上述一种或多种角色。在这些角色之间通过使用3种基本操作进行相互作用:

(1)发布(Publish)。服务提供者向服务代理者发布服务,注册自己的功能及访问接口。

(2)查找(Find)。服务请求者通过服务代理查找特定种类的服务。

(3)绑定(Bind)。服务请求者能够真正使用服务提供者。

2.3 实施SOA的关键技术

直到XML语言的出现以及Web Service等技术的发展,SOA才从概念阶段慢慢走入企业的视野,从理论逐渐转向于实际应用。实施SOA的关键技术如Web服务栈结构如图2所示,其中涉及的主要技术包括以下几个:XML(Extensible Markup Language,一种扩展性标识语言)、SOAP(Simple Object Access Protocol,简单对象访问协议)、WSDL(Web Service Description Language)、和UDDI(Universal Description Discovery and Integration)等。

3 具体实现方式

企业中需要工艺管理系统通过“结构快照”表示PBOM(包括工艺BOM和装配BOM),可以按照生产和装配的需要改变这些BOM的结构,但不会影响设计BOM的完整性,如在装配BOM的结构中可增加虚拟件、拆分零件等,所以要求实现产品设计平台与工艺设计平台的一体化工艺管理系统中的PBOM在导入的EBOM结构上派生。

3.1 系统集成框架

下面以PTC公司的Windchill PDM系统和开目公司的CAPP工艺管理系统为例,CAPP系统通过WebService接口读取Windchill PDM系统的EBOM结构设计数据,达到集成Windchill PDM系统的目的。系统集成的框架结构如图3所示。

在CAPP系统中基于.NET平台开发插件并将它作为PDM系统WebService的客户端,插件程序通过WebService平台发送XML格式的SOAP消息给PDM应用程序,PDM通过数据交换封装接口解析XML格式的消息为PDM内部数据格式,在PDM的产品信息数据库中查找产品的结构树信息,并且通过数据交换封装接口把查询结果由PDM的数据格式转换成XML格式,然后把XML数据封装成SOAP消息传回给CAPP系统的插件应用程序,CAPP系统通过数据交换封装接口把得到的XML格式的结果转换成CAPP系统内部的数据格式,这样就完成了BOM数据的交换,可以在CAPP系统中查看已传递的产品结构树信息。

3.2 BOM数据的交换格式

CAPP与PDM之间主要交换的数据是结构化的物料清单表,XML提供了一种结构化的数据表示方式,使得数据与结构分离,所以选择XML作为中间格式并通过SOAP协议传递来实现CAPP与PDM之间的数据交换。CAPP可以从PDM中得到设计结构树和设计节点属性,PDM则可以从CAPP中得到工艺BOM和装配BOM。下面给出用于传递产品结构树(EBOM)数据格式的例子:

3.3 系统集成界面

在开目工艺管理系统主框架上有主菜单【WINDCHILL】,选择该菜单下的【WINDCHILL数据导入】命令,如图4所示。在点击菜单后,程序将弹出登录PDM系统对话框。

在对话框中输入用户名和密码,点击【确定】按钮后,程序调将用PDM的集成插件,PDM系统进行权限验证。验证成功后,读取PDM系统中的产品结构如图5所示。

输入查询条件查询PDM系统中的EBOM结构信息,选中需要下载至CAPP系统的结构节点,点击【确定】按钮。该零部件结构以及相关的零部件属性将自动传递到CAPP系统中,用户可在CAPP系统中的【对象管理】的【数据批量导入】中看到当前导入的结构及其属性。通过确认EBOM产品结构数据后,点击【提交】按钮,将导入的产品结构树提交为正式的工艺BOM数据。

4 结语

通过结合企业的应用实际,针对现有PDM与CAPP系统,分析并提出了BOM数据集成过程的关键点:采用基于SOA的松耦合的集成接口方式,搭建了以产品数据管理(PDM)系统为核心,与工艺规划管理(CAPP)系统之间的BOM数据集成框架,实现了从EBOM到PBOM的数据传递,同时为实现企业各系统之间的综合集成奠定了基础。

参考文献

[1]Howard Kushner,著,张云涛,等,译.IBM WebSphereStudio J2EE应用开发.机械工业出版社,2004,4.

[2]苟凌怡,等.基于XML的产品信息集成关键技术研究.计算机辅助设计与图形学学报,2002,14(2):1-6.

[3]张昌利,李蜀瑜,等.一种基于Web服务的应用集成解决方案.微电子与计算机,2005,8(23):55-57.

[4]朱海平,邵新字,等.面向BOM的CAPP系统研究与实践[J].华中科技大学学报,2001,4.

[5]冯站峰,等.PDM集成框架下PDM和CAPP的信息交换[J].武汉理工大学学报,2002,24(3):21-24.

基于SOA的军事信息系统集成研究 第8篇

SOA是一种面向服务的软件架构。作为一种设计和构建松散耦合的软件解决方案的方法, 近年来得到了广泛关注。本文基于SOA架构, 依据服务融合的思想, 综合利用已有的信息资源, 快速地构建集成军事信息系统, 使之能够适应军事业务不断变化对信息系统集成产生的影响。

1 SOA概述

面向服务的架构 (Service-Oriented Architecture, SOA) 并不是一个新的概念, 它是一种将信息系统模块化为服务的架构风格, 拥有服务之后, 就可以通过编配这些服务给业务流程带来生命力[1]。

SOA的一般定义为:“本质上是服务的集合。服务间彼此通信, 这种通信可能是简单的数据传送, 也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数[2]。”

在SOA架构中, 包括三种角色:服务提供者、服务请求者和服务代理者。这三种角色通过3个基本操作:发布、查找、绑定相互作用。服务提供者向服务代理者发布服务;服务请求者通过服务代理者查找所需的服务, 并绑定到这些服务商;服务提供者和服务请求者之间可以交互[3]。SOA架构模型如图1所示。

从本质上说, SOA是一种面向服务的软件架构, 是一种设计和构建松散耦合的软件解决方案的方法。SOA架构的基本元素是服务, 服务作为用于业务流程的可重用组件, 它提供信息服务或简化业务数据的状态迁移过程, 响应客户的请求并提供高质量的服务[4]。

2 军事信息系统体系结构

2.1 体系结构设计要求

1) 集成现有系统。由于历史的原因, 我军目前现有的各类信息系统呈“烟囱式”特点, 互连互通互操作困难。现代军事信息系统的建设, 不能只着眼于新的、孤立的系统的建设, 而应该充分考虑对遗留系统的再利用。

2) 结构松散耦合。松耦合使得服务更容易集成, 或组成其他的服务, 同时提供了良好的应用和服务管理能力。系统所提供服务应该是透明的、协议独立的, 从而可以不必与特定的系统和网络相连接, 同时也使得服务重用成为可能。

3) 基础架构统一。在所有不同的应用系统之间, 基础架构的开发和部署应该一致。现有组件、新开发组件可以合并在一个框架内, 从而增强系统可扩展性。

2.2 系统总体结构

基于SOA的军事信息集成系统, 通过标准化的服务接口连接起来进行数据交换。它屏蔽了不同平台、编程语言、操作系统和硬件架构之间的差异。在这种模式下, 一个应用或部分应用是一种服务, 可以被重用和共享。与传统相比, 整个环境变得更富有弹性, 能快速响应决策业务需求, 从而实现更好的业务灵活性[5]。总的来说该框架分为四层:数据存储层、组件服务层、业务逻辑层以及表现层。

数据存储层:数据层是系统中各个服务得以实现的基础。数据存储层包括当前流行的数据库管理系统, 如SQL Server 2005, Oracle 11g等, 用来存储系统中使用的各种系统参数以及军事支撑数据;也可以是遗留系统的数据集合。军事信息系统中的数据包括战术想定库, 军事模型数据库, 军事地图库, 军事案例库, 态势信息库, 战术原则数据库及模型算法库等。

组件服务层:利用数据存储层提供的统一数据服务接口可访问完整的集成数据。主要对请求消息以及回执消息的整个过程进行处理, 包括SOAP消息的封装、消息监听器、作业处理器、注册中心以及安全组件等[6]。

业务逻辑层:由具体实现系统核心功能的业务组件组成, 主要包括战术想定业务、军事模型业务、战术原则业务、军事案例业务、态势信息业务、综合保障业务等。这些组件可以是EIB, COM, CORBA, 也可以是细粒度地实现业务逻辑的Web服务[7]。在需要重用资源协调系统的业务逻辑时, 可以通过工作流程控制引擎访问组件来调用其功能。

表现层:提供统一的交互服务, 包括登录服务、用户统一管理、用户授权等。通过登录系统, 可对应用系统的信息安全进行统一设计、统一开发, 形成一个完整的、通用的、透明的安全服务体系。

3 关键技术

3.1 数据整合过程

为实现数据资源整合的目标, 在实施基于SOA的解决方案时候要管理好元数据以及对数据服务的封装[8]。元数据的管理是全局统一信息标准的集中体现, 对全局信息标准数据字典和代码集进行维护, 对表描述或表所含数据项描述及数据结构可以进行增加、删除、修改、导出存档和查询, 是对于军事信息系统元数据的归并与整理, 为后续新建系统提供指导与规范;为便于对源数据的访问以及附带基于数据流之上的业务逻辑, 需要将数据封装成数据服务, 在实现时可以采用定制Web service, 也可以采用专用ETL工具将源数据进行抽取后通过专用接口发布成服务。

3.2 SOA服务模式

SOA就是实现独立于技术的服务接口[9]。SOA的编程思想是通过应用组件和传输协议的松散耦合 (服务的传输协议的透明化) , 从而实现组件的虚拟化, 造就一个虚拟的集成架构或者集成平台服务总线, 这样使得服务集成不受任何限制, 可以同时集成.NET和J2EE组件, 以及集成其他遗留系统的各种应用, 同时也可以随时更换这些组件。

4 结束语

信息化条件下军事系统的内在复杂性, 导致了分布式系统集成技术、部署位置以及作业流程的不确定性。这些不确定性, 需要系统集成框架具有一种柔性的处理方式。基于SOA的系统集成框架, 在分布式环境下, 基于开放、可扩展的体系结构, 用面向服务的架构思想, 实施组件服务化, 针对复杂灵活的军事需求, 以组件组合的方式构建跨地域、跨平台的集成系统。实践表明, 所构建框架能够满足跨地域异构平台下军事系统集成需求。

摘要：为了使分布式军事信息系统能够适应实现技术、部署位置和操作流程等不确定因素, 提出了一个基于SOA的柔性分布式系统集成框架。首先对SOA进行了概要阐述, 进而提出军事信息系统集成要求, 最后给出了系统集成框架。框架基于SOA架构、组件化思想, 采用web技术实现服务封装;使用服务总线实现服务的集成和交互;利用动态加载和实时配置的方法对服务进行管理。实践表明, 框架满足在分布式环境下, 跨地域、跨平台的异构军事信息单元的集成和交互。

关键词：SOA,军事,信息系统,集成,体系结构

参考文献

[1]Brown P C.SOA实践指南——应用整体架构[M].胡键.宋玮, 祁飞, 译.北京:机械工业出版社, 2009.

[2]潘卫明, 郝平.基于SOA和工作流的数据仓库更新系统[J].计算机应用与软件, 2010, 27 (2) :206-208.

[3]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机, 2006, 23 (5) :211-213.

[4]郑合锋, 陈四军.基于SOA的军事信息系统综合集成研究[J].火力与指挥控制, 2010, 35 (1) :81-83.

[5]龙朝阳, 肖静波.基于SOA的服务型电子政务模型研究[J].情报杂志, 2009, 28 (2) :61-65.

[6]冉崇善, 吴莎莎, 许光.基于SOA的异构系统数据整合的研究[J].陕西科技大学学报, 2010, 28 (3) :109-113.

[7]鄢沛, 郭皎, 应宏.基于SOA的柔性分布式仿真框架的设计[J].计算机仿真, 2010, 20 (1) :78-81.

[8]李雪俭, 何文华.基于SOA架构的高校数据资源整合研究[J].计算机技术与发展, 2010, 36 (2) :78-81.

基于SOA的教育资源集成系统研究 第9篇

关键词：SOA,教育资源,集成,Web Service

信息技术的发展和计算机的应用已经对教学产生了巨大的影响, 促使教学过程发生根本的变化。随着技术的逐渐成熟, 远程教育模式被越来越多的学校采用, 并为更多的教师、学生所接受。然而, 远程教育信息资源种类繁多、杂乱无序, 封闭在各自系统中;由于技术、资金等多方面的制约, 目前多数远程教育平台还停留在低层次、低水平的自治共享上, 极大地限制了远程教育的推广应用。因此, 如何有效地开发、整合教育资源, 已成为远程教育领域的一个重要研究课题。

1 面向服务架构——SOA

1.1 SOA的结构

SOA (Service-Oriented Architecture) 是一种面向服务的体系结构, 面向服务的计算技术对分布式应用集成所带来的最明显的好处可以充分体现在面向服务架构中。在2002年, Gartner组织就指出面向服务架构将是“现代应用开发领域最重要的课题”, 并预计到2008年, 面向服务架构将成为占有绝对优势的软件工程实践方法。SOA体系是由多种技术搭建而成的, 它是一种整合现有技术的松耦合架构体系, 其结构如图1所示[1]。

(1) SOAP, WSDL, UDDI。WSDL, UDDI和SOAP是SOA的基础部件。WSDL用于描述服务;UDDI用于注册和查找服务;而SOAP作为传输层, 用于在消费者和服务提供者之间传送消息。一个消费者可以在UDDI注册表 (registry) 中查找服务, 取得服务的WSDL描述, 然后通过SOAP来调用服务。

(2) WS-I Basic Profile。WS-I Basic Profile, 由Web服务互用性组织提供, 是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

(3) J2EE和.NET。J2EE和.NET平台是开发SOA应用程序常用的平台, 但并不仅限于此。像J2EE这类平台, 不仅为开发者自然而然地参与到SOA中来提供了一个平台, 还通过其内在的特性, 将可扩展性、可靠性、可用性引入SOA。新的规范, 例如JAXB (Java API for XML Binding) , 用于将XML文档定位到Java类;JAXR (Java API for XML Registry) 用来规范对UDDI注册表的操作;XML-RPC (Java API for XML-based Remote Procedure Call) 在J2EE 1.4中用来调用远程服务, 这使得开发和部署可移植于标准J2EE容器的Web服务变得容易, 与此同时, 实现了跨平台的服务互用。

1.2 SOA应用于远程教育资源整合的优势

加快教学资源建设是现代远程教育发展的关键。远程教育中的教学资源具有多样性、典型性、新颖性、结构化以及智能化的特点。传统的业务系统集成方案, 是通过业务功能的专用接口调用, 实现资源信息共享。业务方法集成通过开发业务组件加以实现, 实现业务功能的业务组件通常具有一些标准格式的结构和接口, 具有较好的集成性能, 业务组件的实现常采用CORBA、EJB、DCOM等技术。但专用调用接口方案存在着一些不足。专用调用接口方案是一种紧密耦合的集成方法, 这种方法集成的结果不利于业务流程、资源信息的调整和重组, 缺乏可扩展性、灵活性和适应性。其次是实现技术缺乏标准, 不同的软件厂商提供了不同的实现技术, 当前组件技术存在着多个标准, 不同组件技术之间的互操作给集成增加了一定的成本和难度[2]。

SOA是实现远程教育资源之间数据和业务无缝衔接的理想方案, 它在服务层中将各业务功能点以服务的形式暴露于系统之外, 其他信息系统可以通过服务协约对服务进行访问。这种技术简化了系统集成, 可以快捷、容易地对业务需求的变化做出反应。另外, 面向服务架构是与平台和语言无关的, 因此不必考虑实施环境是何种平台系统和设备, 与其他系统集成技术相比, 面向服务的集成构架是解决远程教育资源集成的理想选择。

SOA之所以被用于信息资源整合, 是因为其具备了标准化、可组装的特性[3]。因此基于SOA资源整合的关键技术, 是把原有的信息资源封装为服务, 然后将开发的新服务和原有系统包装的服务进行有效组合, 共同实现对信息资源的整合。与传统的模式相比, SOA具有如下重要优势: (1) 具有精确定义的标准化接口。 (2) 粗粒度、松耦合的服务构架。 (3) 完好的封装性和高度集成能力。

2 利用SOA技术实现教育资源的集成——ERI-WS

2.1 ERI-WS概念模型

ERI-WS采用标准的SOAP协议作为数据传输协议, 通过ERI-WS来为服务请求者提供服务, 为Web服务提供适配与接口标准, 并通过内部软件模块与元数据来完成管理与控制, 如图2所示。

2.2 ERI-WS体系结构模型

通过分析SOA结构中的各层组织, 本文设计了基于SOA的教育资源集成框架ERI-WS, 框架的整体设计如图3所示。

(1) 表示层。表示层的主要作用是将应用产生的结果信息显示给用户, 可以使用B/S或C/S架构。

(2) 安全管理层。服务安全管理层是为ERI-WS提供系统安全保障。主要作用是验证SOAP消息来源的可信任程度以及是否有权访问该服务。如果没有通过验证, 返回包含错误说明的SOAP响应, 并结束调用。如果成功通过安全性认证, 则继续进行调用Web服务的过程。

(3) 服务访问层。服务访问层通过与UDDI接口的交互, 实现服务的发布、查找、调用, 通过与业务逻辑层的交互获取组合服务信息。这里的UDDI注册中心可以为私有注册中心, 也可以是公有注册中心。如果是私有注册中心则集成的是单位内部的应用系统;如果是公有注册中心, 则可以通过Internet集成不同单位的不同系统。

(4) 业务逻辑层。业务逻辑层需要事务处理机制和组合控制, 它主要起在企业信息系统中定制新的系统集成的作用。

(5) 服务层。服务层主要负责把各个教育资源通过Web Service封装成服务, 并且通过对照UDDI中的组织元数据的映射关系, 对不同教育资源间的信息格式进行统一, 然后在注册中心进行注册。

基于SOA框架的教育资源集成系统解决了以往教育部门之间交互的复杂性以及教育部门中信息孤岛等问题, 使用户能够快速、有效地获取所需要的信息, 增加了教育资源的利用率和价值。平台中使用业务逻辑控制使各教育部门分离的业务有机地结合, 形成完整的、新型的业务, 提高了工作效率。

3 结束语

面向SOA的服务总线在新一代应用集成技术中占有重要的地位。针对现在面向SOA服务总线普遍存在应用系统紧耦合的现象, 本文提出了一种基于SOA和Web Service的服务总线模型ERI-WS。ERI-WS提供统一的适配机制来灵活集成异构的应用, 采用Web服务的方式集成, 不仅集成组织内遗留系统之间、遗留系统与新部署的系统之间的互操作, 同时也集成组织外的应用系统与组织内的应用系统之间的互操作, 从而为实现跨应用集成和业务整合提供有力支持, 能够较好地实现异构系统间的整合。

参考文献

[1]吴雷.基于SOA的工作流引擎的研究与实现[D].武汉:武汉理工大学, 2007.

[2][美]Newcomer E, Lomow G.Understanding SOA with Web Services[M].中文版.徐涵, 译.北京:电子工业出版社, 2006.

基于SOA的企业应用集成方案设计 第10篇

1.1 公司背景

该海运物流企业为一总部在内地, 业务面向国内长江流域、国际上日本和韩国的物流企业。公司现拥有5000吨级 (332TEU) 多用途集装箱船舶四艘和10000吨级 (672TEU) 多用途集装箱船舶两艘, 总载重吨为38100吨, 总箱位数为2672TEU。经过激烈市场竞争的磨砺和锤炼, 现已逐步发展成以集装箱运输为主业, 积极拓展货代、船代、船舶租赁业务、劳务技术输出等多元化的经营模式, 寻求新的经济增长点, 积极向现代物流企业转变。

公司积极倡导以现代物流的理念来改造传统运输业, 在继续保持航运业务的核心竞争力的同时, 充分利用中国高速公路网和中国长江黄金水道的优势, 让集装箱运输这种功能强大的现代化运输方式把内地经济与世界充分接轨, 形成具有较强实力和发展潜力的现代物流企业。初步形成了集装箱近洋运输、南北线集装箱散货运输、长江内支线集装箱运输相结合的江海联运格局。

1.2 信息化基础

公司现有信息化系统总体架构如图1所示。

从网络层面分析, 公司已经购置了路由器、交换机和防火墙等网络设备, 实现了公司内部网络环境, 并支持内部网络与外部Internet互联互通。同时通过虚拟专用网VPN技术, 实现了公司总部与驻外分支机构之间低成本、可靠、保密的网络通信信道。公司通过服务器托管方式部署了WWW服务器。

从技术层面分析, 现有信息系统构建在Intel处理器平台的PC级服务器上, 其中一些系统采用普通的兼容PC机。操作系统平台主要选择微软公司的Windows, 部分系统采用Linux。数据库系统主要采用微软公司的SQL Server, 但各系统数据间相互独立。办公自动化系统采用Lotus Domino群件系统。

从应用层面分析, 现有七套信息系统分别实现了相应业务领域的管理功能, 单一系统从功能上功能基本符合公司业务需要。公司主要为客户提供江、海运输服务。现有七套信息系统, 提升了企业的管理水平, 它们的技术特点如下:用友U8财务系统, 办公自动化系统, 船员管理系统, 海运船舶监控系统, 内河船舶监控系统, 机务管理系统, 内支线管理系统 (CARGO) , 以上系统由公司委托技术公司开发, 其中, 船员管理系统、海运船舶监控系统和机务管理系统由某大学下属软件公司开发;内河船舶监控系统由某件公司A开发;内支线管理系统 (CARGO) 由软件公司B开发;办公自动化系统由软件公司C开发;财务系统为财务软件公司D开发。

2 EAI建设思路

为适应日益激烈的市场竞争, 提升企业核心竞争力, 该文在现有信息化建设成果基础上, 分析存在的不足, 进一步完善信息化发展规划, 优化、集成信息化系统, 将公司信息化水平上升到一个新的层次。

根据企业实际需要, 论文讨论的内容将重点解决以下问题:

(1) 信息系统集成与整合。将目前若干个信息系统根据业务需要整合成一个软件业务平台。避免或减少使用者在不同业务系统间手工切换的繁琐操作。各信息系统间能够实现数据集成, 在公共的平台上以各个系统提供的数据为基础, 生成更加高级业务逻辑的数据, 满足更层次的业务需要。

(2) 业务系统功能优化与完善。对目前业务系统中一些操作不方便、功能不完善的功能进行完善, 对某些目前尚需要进行大量手工操作、消耗较多人力和时间的业务操作进行信息化改造, 用软件系统处理的方式替代或部分替代人工操作。

(3) 提供决策支持服务。为了应对更加激烈的市场竞争, 帮助公司决策层快速获取准确、有效的决策支撑数据, 拟在公司业务操作系统数据基础上开发部署决策支持软件系统, 对海量的业务数据进行提炼、整理, 从更高级的层面呈现数据的特性, 为公司决策提供有力的依据。更好地控制经营成本, 提供财务预警机制。

(4) 开辟电子商务业务模式。公司在不断拓展传统商务模式的基础上, 开辟新的电子商务业务模式。为客户提供服务性能优越的电子订舱, 为客户提供随时可查询的订单处理信息, 提高客户满意度和忠诚度。同时, 将电子商务系统与公司内部其它业务系统有机连接起来, 提高业务相应能力。

(5) 构建适合公司发展需要的信息化基础设施。为了支撑以上信息化建设的业务内容, 必须对公司现有信息化基础设施进行规划和扩展。从网络技术设备、网络构建模式、系统服务器平台、数据存储平台以及信息系统管理等多个方面做好规划, 有效保障公司信息化系统建设和应用的基础环境。

(6) 支撑公司未来业务的友好扩展。根据公司未来潜在的业务发展需要, 本项目提出的规划应当很好地支持公司未来信息化系统的运行环境, 例如拖车管理系统和仓储管理系统等, 能够提供必要的接口方式, 把新的系统友好地融入到整个信息化平台中。

3 信息系统规划

3.1 系统框架

论文在公司网络信息基础设施基础之上, 将这个企业的软件系统组织成为一个整体。整个系统框架可以从业务层次上划分为基础业务层、中间业务层和集成业务层等三个层次, 从用户角度可以划分为四个视图, 分别是领导决策视图、管理视图、业务视图和客户视图, 它们分别与前述的四类使用者一一对应。系统总体框架图如图2所示。

3.2 业务系统视图

业务系统视图根据使用者的需求, 从众多系统业务功能模块中选择其中使用者关心的功能模块子集, 让使用者应用更方便, 同时也可以避免使用者越权访问未授权的业务功能模块, 提高了系统的安全性。此外, 本规划中还支持使用者自定制操作界面的功能。使用者可以在授权的业务功能模块中, 按照自身工作习惯和需要, 选择恰当的功能模块, 这样就能将业务系统视图尽可能按照使用者的需要定制。

根据服务对象的划分, 业务系统视图可提供领导决策层、管理层、业务层和客户层等四种视图, 其中前三种面向公司内部使用者, 最后一种面向公司外部的客户。内部视图可授权访问各种业务信息;外部视图只能访问与该客户直接相关的业务信息, 或者公司授权的部分业务信息。在各种视图中包含一些公共的服务元素, 比如电子邮件系统、个人通信录、天气预报、电子记事簿、个性化设置等, 对公司内部使用者的视图还包含公司通信录、内部公告栏、内部文件库、协同工作日程安排、资源管理器、业务工作流系统、会议管理系统、内部及时信息 (类似QQ或Messenger) 和网络存储器等。此外, 每种视图还有其特殊的服务元素, 具体如图3所示。

上述各种视图的使用者并不是相互孤立的开展业务工作。借助公司邮件系统和业务平台的消息传递机制, 集成整合之后的系统平台能够实现快速、有效的信息互通, 将公司各业务层面、各业务阶段的业务行为有机整合在一起, 实现公司员工与客户、公司内部不同业务层次人员之间协同工作, 大幅度提升公司业务处理的效率和处理能力。

3.3 典型用例

下面就公司典型的应用流程做一个典型的用例分析, 整个业务过程可参见图4。

客户在公司的门户网站系统中注册一个用户名, 并通过该系统获取电子订舱表格, 完成电子订舱操作。订舱信息经过门户网站进入公司内部的数据系统, 同时向系统设定的业务员发送新订单通知信息。通知信息的形式可以根据定制设置为业务系统消息、电子邮件或手机短信。

业务员获知信息后, 通过集成业务平台检查确认订单信息, 并将订单信息转发通知订舱操作员。通知客户和订舱操作员的方式同样可以选择上述不同的方式。

订舱操作员通过集成业务平台获取各种需要处理的订单信息, 并从平台上直接激活进入CARGO系统, 根据订单要求选择船期、集装箱和舱位, 确定后的信息可以通知业务员和客户。业务员从业务平台中查阅该订单及其它订单的当前关联信息, 包括集装箱、船期、舱位等。

船只运行过程中, 通过卫星信道或CDMA信道将船只当前的GPS数据和其它运行状态发送回公司总部的服务器上, 并记录到数据库系统中。根据货物、船只和位置三者之间的关联关系, 业务员和客户均可以分别通过业务平台和网站门户查询客户特定货物的及时位置以及行程轨迹, 并进一步判断货物的运抵时间。集成业务平台可以根据业务员或客户设置的通知选项, 以系统消息、电子邮件或手机短信等形式及时告知货物运输的动态, 例如开始驶离某港口、抵达某港口。

客户在货物运输合同执行过程中, 向公司所支付的各种费用进入公司的财务系统。如果公司在电子商务模式中开通了网上银行支付功能, 公司能够实时获取银行支付或到帐信息, 并及时将信息反馈到集成业务平台中。集成业务平台也可以提取后台财务系统中的财务数据, 使业务员能够随时查询所负责客户及客户每单业务的应付款、已付款和待付款情况, 以便及时与客户对帐。客户同样可以门户网站查询当前执行订单的付款详情, 以及历史订单执行详情。

4 总结