集成服务

集成服务（共12篇）

集成服务 篇1

摘要：服务集成的目标是将多个服务集成到同一系统中以实现特定的业务需求。在集成过程中,由于工具、服务通常有着不同的数据标准、传输机制,导致了集成的困难。为了解决该问题,在服务集成系统中引入了企业服务总线ESB(Enterprise Service Bus)。目前ESB系统的配置文件能够表达较为复杂的服务接入场景,但是根据服务的设计、架构不同,服务接入方法不同,也不支持集成系统的热部署功能。给出一种用于描述工具、服务信息的模型SDModel(Service Description Model),并在该模型基础上提出一种面向服务集成的自动化服务注册方法。方法能够利用SDModel,自动化地解析拟接入集成系统的第三方服务和工具,并实现热部署,供应用层使用。

关键词：服务集成,企业级服务总线,自动化注册

0 引言

在软件开发中,通常会有多种第三方提供的工具、服务被使用。通过集成这些工具和服务,能够提升软件开发的质量和效率。然而由于工具、服务往往由不同开发商提供,集成中很难共享数据和统一管理。

服务集成的目标是将三方服务与工具集成到同一系统中使用[1]。在集成过程中,系统能够满足不同类型的工具、服务接入的需求,不需要更改自身的代码。集成后,系统能够复用三方工具的页面以及它所提供的服务,减少开发、集成的工作量。也可以根据特定的业务需求,将服务组合后提供给用户使用[2]。

进行系统集成时,由于工具、服务通常有着不同的系统设计、数据标准、传输机制等原因,其互相之间的通信、集成较为困难。为了解决这个问题,在服务集成系统中引入了企业服务总线ESB[3],为不同的工具、服务间提供一个通信的桥梁。

系统的集成分为服务的集成和工具的集成两种情况。当集成三方服务时,首先将服务接入ESB,通过ESB提供的通信协议、数据格式转换功能,形成新的服务提供给系统使用。该过程中,需要向ESB提供其能够识别、使用的配置文件。配置文件中包含了服务的输入输出、地址等信息。当集成三方工具时,除了将工具所提供的服务接入ESB外,还要将使用工具所需的必要信息如用户名密码、工具的地址等提交给系统,以便系统复用该工具的页面。

现有ESB系统所提供的集成方法并不能较好地满足服务集成系统的需求,具体问题如下:

1)ESB配置文件的格式和内容复杂,对用户不友好。配置文件包含许多ESB内部组件,如数据格式转换模块等。这类组件和接入服务并不直接相关。另外如果配置错误,用户需要花费时间来检查和调试。

2)由于工具、服务的种类众多,集成中需要针对其不同的设计、架构,编写不同的集成模块,这将花费大量的时间。

3)集成系统不支持热部署功能,导致在集成工具、服务过程中,系统无法使用。只有在集成完成后,重新启动系统,才能够使用新的工具和服务。

针对上述问题,本文提出了面向服务集成的自动化服务注册方法。该方法定义了一个能够表达接入工具、服务信息的模型,利用该模型自动化的完成注册工作。

1 相关工作

一些研究提出了新的服务组合算法,解决了在Web服务注册到ESB后,如何利用工作流系统,根据需求选择服务,封装组合后形成新的服务提供给用户使用的问题[4,5];一些研究关注于如何对ESB系统上的Web服务进行管理[6,7,8];Tan等人按照Web服务的用途分类后,使用Petri网计算,得到服务的组合方式[9];也有的工作设计了一个分布式高可信ESB系统,在这个系统中解决了服务的组合问题[10]。上述研究重点解决了如何根据用户的需求,整合服务的问题。但是这些研究以服务已经注册到ESB为前提,没有把工具和服务的注册问题作为重点。

王路远提出了一个ESB管理系统[11],该系统通过界面引导用户完成服务的配置后,自动生成ESB的配置文件,来完成服务的注册。该方法降低了用户注册和管理ESB的难度,但是没有关注集成系统如何使用三方工具的问题。

边小凡等人提出了一种快速集成工具、服务的系统模型[12]。该模型使用ESB来完成各部件之间的通信工作,并应用到了国家安全以及灾难响应的场景中。文中使用了UDDI[13]来进行服务的发现和注册,但没有重点阐述集成系统如何使用三方工具的问题。

本文提出了一个面向服务集成的自动化服务注册方法,其能够解决上文描述的三个问题,方便接入新工具和服务。其包括下面两个步骤:

1)从实际的工具、服务中抽象出一个较为通用的服务描述模型,其能够表达工具、服务的集成信息,以及它们的设计、架构差异;

2)设计自动化注册方法,利用上述模型所含有的数据完成服务、工具的注册,并保证系统能够使用它们。

2 自动化服务注册方法

由于工具和服务的数量众多,为每一个都设计特定的注册方法将耗费大量的时间,因此需要根据实际使用的软件开发工具、服务,抽象出一个较为通用的服务描述模型SDModel。

图1是注册方法的架构设计。首先根据需要集成的工具、服务的信息抽象,由用户填写或可视化模块生成SDModel。模型解析模块会验证SDModel的合法性,如果不符合系统的要求,集成过程将不会被完成。此后SDModel会被解析成两部分数据,一是符合ESB规范的配置文件,二是存储后供查询的工具、服务信息。完成SDModel解析后,解析模块向服务管理模块发出通知,将生成的ESB配置文件交由ESB部署模块使用。通过使用热部署模块,文件被配置到ESB中。这个步骤中,由于诸多原因可能造成部署的失败,因此在部署前,状态保存模块会将正确运行的配置文件保存备份。一旦部署失败,服务管理模块会取出备份文件交给部署模块尝试重新部署。在部署服务中,服务地址管理模块负责分配和回收地址供服务使用。

部署完成后,服务管理模块会通知应用层模块新的工具、服务接入完毕。应用层模块通过服务管理模块查找需要的服务,而后会使用接入总线服务所使用的协议和总线进行通信。到这里,ESB就完成数据格式、通信协议的统一工作,将不能够通信的三方工具、服务连接到了一起。

为了让自动化注册方法实际工作,需要:

1)定义SDModel,描述待集成的工具和服务;

2)模型解析模块,用于解析SDModel,生成ESB能够识别、使用的配置文件;

3)服务信息模块,保存工具、服务的信息以及ESB的配置文件备份;

4)ESB配置模块,将生成的配置文件部署到运行中的ESB中,并保证ESB的正确运行;

5)服务管理模块,向应用层提供已经集成的服务,同时控制ESB配置模块进行部署操作;

6)可视化模块,帮助用户生成SDModel。

2.1 服务描述模型

本文参考了WSDL(Web Service Description Language)[14]定义服务描述模型,该模型符合标准的XML格式(<key>value</key>)。SD-Model包含了拟接入的三方服务和工具信息。SDModel的层次结构应该如图2所示。

首先使用sdmodel关键字来定义模型。所有接入工具、服务等等信息都将写在这个关键字之中。

1)三方服务

对于待集成的三方服务集合,使用服务集合(services)来描述。对于其中的某项具体服务,使用服务(service)来描述。三方服务包括了服务描述、服务协议、输入、输出、期望输出几部分。

服务描述:包括了服务名称(name)、简要描述(description)和服务地址(address)三方面的信息。这里地址应当包括协议和地址两部分。如:http://192.168.10.10/xmltojson。其中http为协议,后面部分为具体的地址。

服务协议:使用protocol关键字。服务的数据经过ESB处理后,需要再次提供给其他模块使用,如果用户想在这里改变数据传输的协议,应该使用protocol关键字。如果没有,则默认为服务地址中的协议。

输入:使用input关键字,描述服务的输入参数。由于输入中可能包含了若干的参数,定义param关键字来描述这些参数。每个参数由参数名称(name),参数格式(param-format)和参数取值(param-value)几部分组成。参数格式取值如XML、Object等。如果参数取值为空,则表示该参数将在ESB运行中传入。

输出:使用output关键字,描述服务的输出结果。由param关键字描述,但是不包含参数取值。

期望输出:使用expect-output关键字,描述用户希望通过ESB处理后输出的结果。由param关键字描述,但是不包含参数取值。

2)三方工具

三方工具由两部分信息组成:一是工具自身的信息,如账户、工具地址等;二是工具提供服务的信息。使用工具(tool)描述用具定义的开始和结尾。

工具描述:包括了工具名称(name)、简要描述(description)和工具地址(address)三方面的信息。

工具认证:用tool-access关键字描述,定义三方工具账户信息,其中可以包含多个账户(account)。每个账户中提供工具的用户名、密码。和服务的输入输出类似,账户中使用参数(param)来描述具体的用户名和密码。此外,对于B/S架构的工具[15],还可以添加工具的登录信息,如工具的登录的地址,来帮系统进行单点登录操作。

工具服务:表示由工具提供的若干服务。该部分和三方服务集合(services)类似。不同的是这些服务可能没有具体的地址,故可以不配置地址(address)。

3)示例

下文展示了一个详细的SDModel,其中包含了缺陷管理工具Bugzilla的工具地址,同时提供一个用户名为123@example.com,密码为123的账号供集成系统使用。此外,SDModel中还定义了Bugzilla提供的get Bug By Id服务。该服务的输入为int格式的bug Id,而输出为xml格式的具体bug。

通过SDModel的定义,其能够较为通用地表达三方工具、三方服务的信息。

2.2 注册方法模块实现

1)模型解析模块

解析模块首先会接收用户上传的SDModel,然后会验证其正确性。

为了便于SDModel的解析和验证,这使用了JAXP(Java API for XML Processing)[16]。JAXP是一套用来处理XML文档的API。其中包括了javax.xml.validation、javax.xml.parsers等多个包(package)。

验证分为两个阶段:第一阶段通过javax.xml.validation包来验证SDModel是否符合标准XML文件的格式;第二阶段验证SDModel的完整性,如<tool>中是否含有<address>信息,<param>中是否遗漏了<param-format>等。如果模块发现SDModel有错误,则模块不会进行下一步的ESB配置文件生成工作。同时,会将具体的错误信息返回给用户。该模块避免了用户错误填写配置文件后,系统的不能正常运行问题,也减少了进行错误的排查修正的时间。

而后,利用javax.xml.parsers包解析SDModel。将解析出的数据写成ESB的标准配置文件。根据ESB的不同,其配置文件的格式也不同。为了解决这个问题,模块对常见的ESB配置文件进行单独处理,并且维护其配置文件的格式信息。如mule ESB的配置文件开始和结束的标识为<mule></mule>,且通过xmlns来关联需要的其他XML文件[17]。随后,该文件将会发送至ESB配置模块。另外,SDModel还包含的工具、服务信息,如服务所需要的输入输出、是否需要格式的转换等,将会被储存起来,供服务管理模块查询使用。

2)ESB配置模块

为了达到集成系统的热部署功能,同时保证ESB的正常运行,ESB处理模块会有三个主要的功能:

(1)服务地址管理模块。当新的服务接入到集成系统中后,需要为其分配相应的服务地址。该模块维护一个地址池,该地址池由集成系统管理员根据拥有的IP段进行分配。地址池按顺序为新的服务和工具分配IP,同时回收不再使用、注销的服务的IP。

(2)热部署模块。ESB配置文件生成后,需要把该文件部署到ESB运行环境中。对于一些ESB,如Synapse,只需将该文件放入运行环境下;而对于mule,需要将配置文件打包为发布版后,再放入运行环境。随后重启ESB系统(根据ESB的不同,处理方式稍有差别,如mule ESB不用重启便可完成新服务的部署,而synapse需要重启),使新的服务和工具生效。这里使用脚本来控制ESB的启动、停止等工作。模块首先会判断用户所使用的操作系统。在Linux/Mac系统下采用shell脚本;在Windows系统下则采用bat脚本。另外,由于可能出现的网络异常、配置文件错误、ESB系统异常等原因,部署可能会失败。因而每次部署前,应当保存当前ESB上正常运行的配置文件。部署失败时,向状态保存模块请求恢复之前的状态。

(3)状态保存模块。由于ESB在部署过程中可能出现的异常情况,在每次热部署之前,该模块会记录下当前ESB系统中的配置信息。如果系统发生了错误,本模块会负责取回最近一次的信息进行恢复。同时,还应该提醒用户部署发生错误,以及错误原因。

通过ESB配置模块,当集成系统接入新的工具和服务时,不再需要重启整个系统,保证了用户的使用。

3)服务信息模块

服务信息模块将会主要保存三部分信息:

(1)用户管理数据,用于记录用户的信息,如用户名、密码等。

(2)工具、服务的注册数据。这部分信息将会用于服务管理模块的查询和变更工作。当集成系统需要多个工具的单点登录功能时,该部分还会记录工具的登录地址等信息,以便集成系统模拟登录取回工具的cookie。

(3)状态保存信息。该模块负责维护ESB的配置文件,以及ESB是否正常工作等数据。通过设置时间间隔,模块将定时从ESB抓取当前系统的运行信息。部署失败时,模块将取出最近一次正常工作的配置文件,以便ESB系统恢复运行。

4)服务管理模块

该模块主要包含了两个功能:

(1)服务查询模块。当应用层模块需要调用ESB上的服务时,会首先向该模块发出申请。模块查询ESB是否存在该服务,以及该服务运行是否正常,然后把查询的结果返回给应用层模块。最后应用层模块会根据该结果决定是否对服务发起http、或是其他协议的请求。例如前文中Bugzilla提供的get BugBy Id服务,由于该服务的协议是http,应用层将会对该服务的地址发起http请求。在请求中包含有服务需要的参数bug Id。ESB响应请求后,从Bugzilla查找bug数据,最后把该bug返回给应用层。此外,每次部署新工具、服务成功后,模块会向应用层模块发出消息,通知其可以使用这些工具和服务。

(2)服务变更模块。当用户不再需要某个服务或是想对服务做出修改时,该模块会对保存的服务信息做出相应的变更。如注销get Bug By Id服务,该服务的数据则会被删除。同时模块会定位该服务所属的ESB配置文件,在该文件中去除不需要的服务项,最后通知ESB配置模块,重新部署更新后的ESB配置文件。

5)可视化模块

对于用户来说,手动编写SDModel仍有一定的难度,因此可以根据具体集成系统的需求,为用户提供两种方式完成注册:

(1)对话输入框的方式,引导用户填写注册信息。

(2)直接上传包含有接入工具、服务信息的SDModel。此后所有的工作由模块自动完成。该界面将会在下一章的案例分析中给出示例。

3 案例分析

3.1 软件开发可信证据采集平台介绍

本文所提出的自动化服务注册方法已经应用在软件开发可信证据采集平台上。该平台是一个Web应用工具集成系统,主要用于将软件生命周期的相关工具,如需求管理工具Jira、缺陷管理工具Bugzilla、测试工具Test Link等,集成到同一系统后提供给用户使用。

在用户使用的过程中,这些接入的工具将产生许多和软件生产相关的数据。平台可以利用这些数据,按照可信证据的定义计算出该软件的可信度。此外,在工具集成的基础上,平台还允许用户在为本平台定制的工作流规则下组合工具所提供的服务。例如同类工具之间的数据传输,将Bugzilla中的缺陷数据同步到Mantis中。该平台的简单架构图如图3所示。

在使用平台之前,用户需要在平台注册一系列工具和服务。在使用中,用户可以选择从平台进入某个工具操作。也可以利用平台的工作流系统定制出一套符合自己业务需求的流程,如通过项目中需求和测试的差值求得黑盒覆盖率。最后由工作流引擎调用ESB上所接入的服务,返回结果给用户。在使用平台前,需要接入软件生命周期中的各项工具和服务。传统的注册方法需要平台针对每一个接入的工具、服务都开发一套通信组件,这增大了平台开发的负担。另一方面,传统的集成方法不能够解决集成的工具之间互相的通信问题。例如希望Bugzilla和Jira通信,则需要为两个工具单独的开发通信组件。那么当Bugzilla希望和另外10个工具通信时,开发工作量和难度都将增加。在引入ESB后,所有工具、服务间的通信都通过总线来完成,只需要为它们开发和ESB通信的组件即可,大大节省了集成的工作量。

这时,本文提出的注册方法就能够解决上文所述的集成场景。基于以上原因,平台使用了本文所提出的自动化注册方法,以支持平台访问工具,以及工作流引擎调用服务的需求。

3.2 平台注册方法

在该平台下,用户可以选择两种方式来接入三方工具和服务:一是直接上传SDModel;二是通过可视化界面的引导,填写信息后,由平台生成SDModel供自动化注册方法使用。平台使用了mule ESB,该ESB提供了为接入工具而设计的connector机制。用户可以将三方工具提供的API封装为connector,接入到ESB后提供Web服务。因此当用户需要为平台接入新工具,且该工具没有提供现成的服务时,还需要上传封装好的connector。

3.3 可视化界面和单点登录

为了进一步降低用户在接入工具、服务时的困难,平台设计了一套友好的可视化界面来引导用户完成注册工作,如图4所示。

用户在界面上填写工具、服务的信息后,平台会生成SDModel文件,供注册方法使用。

另一方面,用户还需要直接在登录平台的同时登录接入的三方工具,因此这里需要一个单点登录服务。对于B/S架构的工具,当用户登录时,工具服务器会生成若干cookie来标记用户的信息,如加密后的用户名、密码,以及服务器session Id。根据这些cookie,服务就能够判断用户是否登录。为了让平台模拟用户登录的动作,需要在SDModel的tool-access关键字中添加工具的登录地址和登录表单用户名、密码的ID,这里的数据还是通过param关键字来定义。

此外,平台和工具的地址通常不在同一个域中,为了能够让平台和工具跨域通信,将所有三方工具通过apache的反向代理设置在了同一个域下。

3.4 定制业务流程

当平台接入了服务后,用户能够利用这些服务定制业务流程,并使用j BPM工作流引擎[18]来驱动业务流程的执行。为了方便制定过程,平台提供了一个可以拖拽的可视化界面,如图5所示。图中的每一个元素均代表一项接入的服务或工具,在定制界面下方可设定三方服务或者三方工具提供的服务,这里的每一项服务,都由ESB所提供。

完成流程的定制后,平台将验证其是否符合执行规范。如测试服务节点必须处于需求服务节点之后。而后工作流引擎调用平台的通信模块,发送http或其他请求和ESB进行通信,即可运行该工作流。

最后,平台利用自动化注册方法完成新工具、服务的接入工作,减少了集成所花费的时间,提供了热部署功能,满足了应用层定制业务流程的需求。

4 结语

本文通过分析发现当前服务集成系统注册新工具、服务所存在的几个问题:1)ESB配置文件较复杂对用户不友好;2)工具、服务种类众多,开发相应的集成方法需要大量时间;3)不支持热部署导致重新部署系统时用户无法使用。为了解决这些问题,首先定义了服务描述模型SDModel,利用该模型,可以较为完整地描述出用户希望接入服务或工具的信息。在此基础上,设计了一个基于SDModel的自动化注册方法。该方法能够读取、解析SDModel,并将其转换为对应ESB系统的配置文件,通过热部署的方式使其生效。由于SDModel能够较为通用表达服务、工具的信息,该方法具有一定的普适性。此外,方法提供了错误检测和恢复机制,保证了集成系统可以从错误状态中恢复。该方法已经在软件开发可信证据采集平台中实现,并取得了良好效果。

本文提出的自动化注册方法在面对分布式部署的ESB总线时,还有一定的缺陷,不能够根据ESB当前的负载,将服务注册到空闲的节点上。因此这是需要进一步研究的方向。

集成服务 篇2

著名研究机构Gartner公司的资深分析师Daryl C. Plummer表示，Web服务是通过标准的互联网技术发布的松散耦合的软件组件。Web服务所使用的协议是独立于平台和供应商的，来自不同来源的不同应用彼此可以通过一个公共的XML格式进行交流，无须耗费大量时间进行自定义编码。使用Web服务可以让IT部门更见专注于建设以标准为基础的应用基础设施，而不是专有技术---这是创建更加灵活的企业业务应用的重要。

使用Web服务集成CRM应用可以让企业在很多方面受益。总的来说，使用Web服务进行应用集成的企业有可能会变得更有效率，并且更快地应对市场变化和竞争压力。 Web服务使得组件能够重用，减低了应用集成的成本，有助于企业解决系统互用性方面的挑战。Web服务还未共享信息和数据建立了一个共同的格式，这使企业能够克服系统不兼容的问题，并有助于达到更快的用户普及率。

Web服务可以帮助企业按照一种最具成本效益的方式高效地将按需定制型自助应用和交互式语音应答(IVR)系统与核心CRM应用软件集成在一起。它们使企业能够在自助式工具、模块以及CRM应用之间无缝地交流信息，不需要进行一个漫长而复杂的集成进程。

虽然Web服务提供了有效的集成机制，不过，这种方式确实也有一些缺点。由于用户界面非常灵活再加上相互依存性，定制是非常不容易的。并且Web服务是一个相对较新的技术，因此，它使用的标准和规范仍然在不断变化。作为一个基于HTTP的协议，Web服务也容易受到安全方面的威胁，所以必须要使用认证机制，并采用SSL加密技术。

Web服务如何支持CRM应用集成

使用Web服务集成任何两个应用程序都需要有一个面向服务的架构(SOA)。SOA捆绑了服务，而这些服务是由一个应用服务器环境发布的。Web服务器是访问这些服务的HTTP网络传输器，而应用服务器则托管了简单对象访问协议(SOAP)接口。Web服务还提供了组成服务的对象组件，这些对象组件提供了位于应用之上的业务服务层。最终的结果是Web服务抽取了提供不同服务的基本应用，而这些服务有助于明确定义企业业务流程。

下面的这几个步骤构成了使用Web服务集成CRM应用软件的标准过程，

集成项目所需要的时间和期限随着CRM应用的不同而不同，因为这依赖于需要集成的业务实体的数量以及需要开发的Web服务的数量。同样，部署过程和步骤也会由于需要集成的应用的不同而不同，但是处理数据所使用的原理和技术将保持不变。以下就列出了一些技术要点：

数据处理应该使用可扩展标记语言(XML)格式，XML是一种标准的数据和信息表示方式。

通用描述、发现和集成( UDDI)应该用于列举和定位应用。UDDI的是一个“目录标准”，一些应用工具在集成过程中将UDDI作为内置的服务向用户提供。

Web服务描述语言(WSDL)文件应该从第三方应用程序获得，数据应该发送给第三方应用程序或者从第三方应用程序检索数据。WSDL是一种“广义标准”，主要用于某个应用程序在向其它应用程序描述自己的接口和通讯规则。WSDL文档是用XML语言编写的;该文件对Web服务进行描述，定义了服务的位置和服务提供的操作(或方法)。WSDL文件还可以包含其它内容，比如扩展元素和服务元素，用户可以利用这些扩展和服务元素将多个Web服务的定义集合在一个单一地俄WSDL文件中。

将WSDL与每个应用程序提供的专有工具配合在一起使用，生成能满足数据结构需要的XML消息。

然后使用SOAP传输XML数据，SOAP是一个用于数据交换的轻量级协议，它是XML并且由三部分组成：一个信封、一套编码规则、一个公约。信封定义了一个框架，描述了消息包含什么内容以及如何处理;编码规则描述了定义应用所用的数据类型;公约提供了一种表示远程过程调用和响应的方法。

SOAP的可用于HTTP协议和HTTP扩展框架这样的协议。使用上面提到的XML，HTTP通信协议有助于张贴或查询第三方应用程序。

如何开始使用Web服务集成CRM系统

如果你考虑使用Web服务作为CRM集成的一部分，那么你要做的第一步是分析现有的应用服务器、应用开发环境以及它们扩展Web服务的能力。

其次，在将Web服务用于CRM集成之前，分析和评估存在于多个客户管理系统中的数据。

面向用户的公共信息服务集成研究 篇3

关键词：用户需求 公共信息服务 集成策略

中图分类号： G203 文献标识码： Ａ 文章编号： 1003-69３８（２０12）０1－0114-05

Study on Delivering Integrated Public Information Service to Customers

Abstract Based on analyzing theory basis and concept， this paper discusses the necessity of delivering integrated public information service to customers. And it stresses that， at the basis of analyzing customers’ need， delivering integrated public information service to customers mainly considers content integration and channel integration， and sets out integrated strategy and some measures.

Keywords customers’ need； public information service； integrated strategy

公共信息服务作为政府提供地公共服务的重要组成部分，应努力使社会公众满意，及时满足社会公众的公共信息服务需求，而目前，我国政府提供地公共信息服务与社会公众的需求之间还存在较大的差距，与构建服务型政府的要求还有很大的差距。

1 理论基础及概念界定

面向用户进行公共信息服务集成有着深厚的理论基础，行政学家罗伯特·登哈特夫妇提出的新公共服务理论对面向用户的公共信息服务集成具有直接的理论指导意义。所谓新公共服务，指的是关于公共行政在以公民为中心的治理系统中所扮演的角色的一套理念［1］。新公共服务理论的内容，简单地说，有以下七点［2］：服务，而非掌舵；公共利益是目标，而非副产品；思想上要有战略性，行动要有民主性；服务于公民，而非顾客；责任并不简单；重视人，而非生产率；公民权和公共服务胜过企业家精神。该理论强调公民权的实现，认为公民是公共服务的中心；政府应担当起服务者的角色；政府及其工作人员应该帮助社会公众表达并主动倾听他们的公共服务需求，努力为其提供高品质的公共服务；政府及其工作人员所努力追求的目标就是维护公共利益，增进公共价值。该理论启示：政府在提供公共信息服务时应以社会公众为中心，以其便利获取与利用为标准，而政府在提供公共信息服务时需要考虑效率与成本，在这种情况下，就需要政府在了解社会的公共信息服务需求的基础上对公共信息服务进行集成式提供。

对公共信息服务而言，它的用户有多类人群，大致可细分为：公民、社会组织、政府部门及其工作人员。公共信息服务是指由政府提供的，用以满足社会公众公共信息需求的各种硬件和软件的集合，它包括各种信息基础设施和公共信息。集成是将两个或两个以上的集成单元（要素、子系统）集合成为一个有机整体的行为和过程，所形成的集成体（集成系统）不是集成单元之间的简单叠加，而是按照一定的集成方式和模式进行的构造和组合，其目的在于更大程度地提高集成体的整体功能，以实现其整体功能的倍增或涌现的集成目标［3］。基于以上分析，可将面向用户的公共信息服务集成界定为：针对社会公众的需求，政府将所提供的公共信息和信息基础设施（服务提供渠道）进行高度集中处理，以形成公共信息集合体和服务渠道集合体，最终使社会公众可以在一个平台或通过一个渠道获取所需的完整的、高质量的信息服务的活动。

2 面向用户进行公共信息服务集成的必要性分析

目前，政府向社会公众提供公共信息服务时存在着诸多问题，如公共信息服务的碎片化、公众的公共信息服务需求得不到满足、公共信息服务渠道不畅等，这些问题的存在严重影响着信息时代政府的行政能力，严重侵蚀着政府的公信力，与构建服务型政府的理念背道而驰。

2.1 公共信息服务的碎片化

由于我国在电子政务建设的初期，缺乏全国统一的标准和规划，基本上全国各地一轰而上，每个地方都有自己的一套建设思路，甚至同一级政府的不同部门亦不同。《中国政府透明度年度报告（2010）》指出，有的地方政府，如大同、广州、长春市政府同时运行两个官方网站，这些网站均为gov后缀，且均在更新。另外，有的地方政府所属部门的网站也存在类似情况［4］。在这种情况下，每个部门及每个地方都按照不同的标准对政府信息资源进行分类与管理，造成彼此之间共享与整合非常困难，形成了诸多“信息孤岛”。这导致公共信息服务的碎片化，社会公众或者说用户根本无法在一个平台获取所需的完整的公共信息服务。

2.2 政府提供的公共信息服务质量不高

政府部门在门户网站上公开的信息资源主要是机构设置、领导活动、招商引资等，多为“打广告”性质的信息，而且实效性比较差，实用性的信息资源比较少。另外，政府部门公开的经济发展和社会发展方面的数据和信息都比较宏观而且有时是不连贯的。究其原因，政府提供公共信息服务的理念还未转变过来，还停留在以政府为、以政府的好恶来决定提供哪些公共信息服务上。不难看出，政府在门户网站上提供的公共信息服务质量还有很大的提高空间。

2.3 政府对用户的需求缺乏了解

笔者曾向我国东部发达地区的A镇和西部欠发达地区的B乡的社会公众各发放调查问卷320份，分别回收有效问卷306份、310份，并对问卷结果运用EXCEL和SPSS统计分析软件进行处理。两地公众在被问及“您认为政府在向公众提供公共信息服务前是否了解过您的需求”，A镇和B乡的公众回答情况见表1。可见，在大多情况下，政府只是独白式的提供公共信息服务，缺乏与民互动沟通，在缺乏对用户需求充分了解的情况下提供地公共信息服务当然无法满足其公共信息服务需求。

2.4 政府提供公共信息服务的渠道不畅

目前，政府提供公共信息服务的渠道主要有：政府网站、广播电视、报刊杂志、公共图书馆、档案馆、公共信息亭等。但现有的渠道并没有得到政府的充分利用，还受“愚民政策”的影响，借口一些政府信息资源涉密不对外公布。另外，政府提供公共信息服务时基本没有考虑残障人这一特殊用户的需求，突出的表现就是我国政府门户网站基本没有设立残障人专用通道，客观上无情地剥夺了他们获取和利用公共信息服务的权利。

3 用户需求分析

3.1 用户分析

新加波政府门户网站按照政府部门及其工作人员、公民、企业、非本国居民四类用户进行公共信息服务集成；美国联邦政府门户网站将用户分为公民、企业及非营利组织、政府雇员、外来旅游者、老年人、现役及退伍军人六类，并对每类人群提供集成性的公共信息服务。借鉴新加波和美国政府用户分类的经验，结合我国国情，可将我国公共信息服务集成的用户细分为：普通公众、农民、残障人、社会组织（包括企业、事业单位、非营利组织）、政府部门及其工作人员。需要指出的是，我国是农业人口大国，农民的公共信息服务需求与其他群体有着显著差别，政府在提供公共信息服务时需要将农民群体从社会公众中单列出来。另外，因残障人与其他群体在获取和利用公共信息服务时对信息基础设施有着特别的要求，故政府需要设立无障碍通道以使其享受公共信息服务。

3.2 用户需求分析

因在受教育程度、职业背景、信息意识等方面存在着不同，不同的用户对公共信息服务的需求亦是不一样的。对普通公众而言，他们需要的公共信息服务主要有：便利地公共信息服务获取渠道、社会保障信息、就业信息、文化体育信息、婚姻信息、住房信息、医疗卫生信息、交通出行信息、食品安全信息等。对农民而言，他们需要的公共信息服务主要有：便利地公共信息服务获取渠道、“三农”相关政策法规、农产品的生产与价格信息、农业技术信息、社会保障信息、医疗卫生信息、交通出行信息、食品安全信息等。对残障人而言，他们需要的公共信息服务主要有：便利地公共信息服务获取渠道、残障人的相关政策法规、社会保障信息、医疗卫生信息、教育培训信息、就业信息等。对社会组织而言，他们需要的公共信息服务主要有：国家经济发展方面的政策法规、行业政策及发展动态信息、经济发展的数据与统计信息、政府项目信息、财税信息、便利地公共信息服务获取渠道等。对政府部门及其工作人员而言，他们需要的公共信息服务主要有：公务员管理的相关政策法规、预算信息、交通出行信息、其他政府部门发布的公共信息等。

用户的公共信息服务需求具有动态性，为能前瞻性地向用户提供服务，就需要预测他们的需求，另外，有些用户存在潜在的需求但无法表达出来，这时就需要政府及其工作人员来帮助唤醒他们的需求。具体而言，社会公众的公共信息服务需求调查方法主要有：①政府可以在门户网站上设立互动区，让访问者对公共信息服务需要改进处进行留言，或者在门户网站上设立联系政府的专区，如通过Facebook、Twitter、RSS、政府博客等方式及时与政府进行联系。②通过政府与用户互动访谈的方式来了解需求，可采用随机抽样的方式从一类用户中选择一定数量的人员，并邀请几位心理学家、营销专家参与访谈，让他们用专业知识与能力分析用户的现有需求并唤醒潜在需求。③政府通过社区组织来了解用户的公共信息服务需求。社区组织工作人员通过问卷调查或走访等方式来了解本社区成员的公共信息服务需求并上报政府部门。④政府派调研员或政府工作人员亲自深入群众，通过与用户交谈的方式倾听他们的需求。

4 面向用户的公共信息服务集成的策略

在公共信息服务提供系统中，存在着三个因素：服务内容、用户、服务渠道（三者的关系见图1）。在对用户需求进行分析后，政府面向用户提供集成式公共信息服务时需要考虑两个方面的集成：内容集成和渠道集成。

4.1 内容集成

公共信息服务内容集成是指对各政府部门的信息资源进行共享、集中，形成政府信息资源集合体，以让用户轻松获取所需要的完整的公共信息服务。公共信息服务内容集成分为两个层次：①为确保公共信息服务集成的顺利进行，要求各政府部门按照统一的采集标准进行政府信息资源采集，根据《政务信息资源目录体系标准：第四部分 政务信息资源分类》（GB/T 21063.4-2007）的规定将相同属性的政府信息资源进行组织与整合，以使政府各部门的信息间易于共享，形成公共信息服务分类集合体。②变革政府各部门的政府信息资源管理理念，构建政府部门间政府信息资源共享交换机制，政府各部门主动拿出所掌握的信息资源用于部门间共享交换，从部门占有转变为政府整体占有，使公共信息服务的碎片化从向集成化，促使电子政府向集成政府转变。

西方发达国家在公共信息服务内容集成方面已开展了一些卓有成效的实践。如2006年，新加波政府发布了最新的电子政府总体规划—“iGov2010”。 “iGov2010”是新加波“智慧国2015（iN2015）”的重要组成部分，其目标是转变政府后台工作流程，提高前台效率和效能，建设一个“集成政府”（Integrated Government）［5］。美国联邦政府在门户网站上对公共信息服务进行了集成，以公民用户为例，政府将公民所需要的公共信息服务进行集成，公民可以在门户网站上便利地获取补助和财政补贴、企业和经济、消费者保护、国防和国际关系、教育及能源、家庭和社区、政府绩效、交通及旅游、历史文化、公共安全和法律等主题的公共信息服务［6］。

4.2 渠道集成

公共信息服务渠道集成是指让用户通过一个渠道就可以便利地获取其所需要的公共信息。公共信息服务渠道集成要求建立统一的公共信息服务平台、形成多元化的公共信息服务获取渠道。

4.2.1建立统一的公共信息服务平台

目前，我国政府门户网站有很多，中央政府、省、市、县四级政府中每个政府都有自己的门户网站，而且各网站的布局各异、互不兼容，造成公共信息服务提供的混乱、不便局面。如用户需要一条公共信息，在市级门户网站只能找到零星残片，还需要在省级门户网站上耗费很长时间找到相关信息。为改变这种状况，进行公共信息服务集成，需要对现有的政府门户网站进行改革。国外很多国家只有一个统一的门户网站，其他层级政府的网站都链接到此门户网站上，且各网站的布局基本相同，用户只需登陆门户网站、只需了解门户网站的布局就可以在各政府网站上畅游、便利地获取公共信息服务。鉴于我国地域差别很大，我国每个省建立统一的政府门户网站，省以下的政府不可再自行建立门户网站，并遵循省政府门户网站建设要求建立自己的网站，链接到门户网站上。在中央政府和省级政府门户网站上开设普通公众、农民、残障人、社会组织、政府部门及其工作人员五项服务栏目，使用户点击相应服务栏目就可以获取完整的信息服务。

为保证公共信息服务的公平性，针对残障人这一特殊的用户，政府需要在门户网站上设立专用通道，在政府网站上设置读屏、放大字体、触摸装置等，以使用户可以便利地获取公共信息服务。欧盟于2005年推出了“包容的电子政务计划”，以倡导“电子政务惠及全民，没有一个人被落下”的原则［7］。它强调为所有人提供平等的公共信息服务获取机会，让所有人特别是残疾人等信息弱势群体平等享受电子政务发展所带来的益处。

政府除了在门户网站上设立五项服务栏目外，还可以采用两个模式进行公共信息服务集成：一是下拉式列表；二是百度搜索式。采用下拉式列表的形式将本门户网站所涉及的政府及其部门全部纳入，用户在选择了一个政府或部门提交后跳转至下一个具体说明本政府或部门拥有哪些公共信息的页面，用户可以根据需要自行选择；政府还可以采用百度搜索模式，搜索范围限于门户网站所涉及的政府及其部门所拥有的公共信息，当用户输入自己所需要的公共信息主题提交后，系统会自动出现与这一主题相关的所有政府信息资源。

通过建立统一的公共信息服务平台，用户可以一站式的获取所需的公共信息服务。为推动公共信息服务的集成化，建设集成政府，澳大利亚政府推出了中心连接点项目，推行“面向用户的跨机构服务提供模式”。该项目对现存的政府机构进行重新设计，以使它们变得更为用户友好化；它使政府提供公共信息服务更为简便，以至于用户可以在一个地方获取而不是在很多不同的政府部门和地点［8］。在我国，江西省政府最早进行了统一的公共信息服务平台实践。早在1997年，江西省委、省政府就提出了全省电子政务建设要坚持“统一组织领导、统一规划实施、统一标准规范、统一网络平台、统一安全管理”的“五统一”和“集中统一、整合共享、联合协同、安全高效”的总体要求，集中力量建设全省电子政务统一网络平台，实现全省党政机关网络互联互通。2004年初，纵向到底、横向到边，覆盖江西省、市、县三级党政机关的全省电子政务统一网络平台（江西省政务信息网）建成开通［9］。

4.2.2公共信息服务获取渠道的多元化

信息时代，在用户的公共信息服务内容需求多样化的同时，日益要求能够通过多元化的渠道获取服务。这就要求政府除了建立统一的政府门户网站，并开通门户网站手机版，还需要开辟新的获取渠道。

2005年，加拿大政府实施了“服务加拿大”项目，该项目旨在改善向加拿大人提供的政府项目和公共信息服务，使它们获取的更快、更容易、更便利。该项目向用户提供了获取一系列政府项目和公共信息服务的单一窗口，这些窗口遍布全国，各呼叫中心及互联网上［10］。

2009年，为使用户便利获取公共信息服务，云南省政府开通了96128政务信息查询专线，用户拨打此专线就可以得到政府工作人员的直接回复，获得所需的公共信息服务。96128专线的建设采用了BOO（Build-Own-Operate）的模式，省电信公司负责硬件设备和软件系统的投资建设，并提供话务转接服务，而省政府部门负责公共信息提供和服务监督考核，并通过购买基本服务的方式获得96128专线的使用权。96128政务查询专线的具体运作模式为：政务专线的接线员来自各政府部门，他们都经过一定的专门培训，且他们中有会彝族和苗族语言的。用户拨打这个电话时，电信公司的话务员根据其问题转接到各部门的接线员由他们来回答问题，能当场回答解决的问题就立即解决，如果不能立即解决的，他们就向本部门领导汇报，在规定期限内解决。若是少数民族群众（不会讲汉语）打来的电话，接线员若不会少数民族语言就能立即找到会讲少数民族语言的接线员进行处理。通过这种方式可以让无法接触或使用网络的用户便利地获取所需的公共信息服务。

5 面向用户进行公共信息服务集成的保障措施

5.1 政府高层领导的重视与支持

新加波政府的集成政府战略、美国联邦政府的公共信息服务集成、加拿大政府的“服务加拿大”项目、澳大利亚政府的“中心连接点”项目的有效推行皆因有政府高层领导的重视与支持。在我国现行政治与行政体制下，面向用户进行公共信息服务集成若没有政府高层领导的重视与支持很难取得成功。知晓并预测用户的需求工作、政府信息资源的共享交换、建立统一的公共信息服务平台等工作都急需政府高层领导的重视与推动。政府高层领导需要重视并提出面向用户进行公共信息服务集成的战略，以指导全国各地各政府部门的公共信息服务集成工作，确保各项工作都导向共同目标——向用户提供集成式公共信息服务。

5.2 变革公共信息服务理念

理念是行动的先导，要想行动有高度，理念就必须要有高度。面向用户进行公共信息服务集成的有序进行，需要政府及其工作人员切实转变公共信息服务的理念。目前，政府及其工作人员在向用户提供公共信息服务时大都还停留在以政府为中心上，并没有真正树立用户至上的理念，没有将用户的需求融入到公共信息服务提供过程中。政府及其工作人员是公共信息服务的提供者，只有他们牢固树立起以用户为中心、用户需求决定公共信息服务如何提供的理念，面向用户进行公共信息服务集成工作才能得到顺利进行。

5.3 建立政府信息资源共享交换的绩效考核机制

为确保公共信息服务内容集成的有效开展，需要建立政府信息资源共享交换的绩效考核机制。通过建立考核机制，对某一个政府部门的政府信息资源共享交换绩效由与其相关联的政府部门、用户、第三方进行共同考核，并将考核结果向社会公开发布，接受社会的监督。对政府信息资源共享交换工作做的好者予以奖励，并记入政府部门领导政绩；对做的差者予以批评，将考核结果与政府部门领导的职务升降相挂钩，以此来激发他们进行政府信息共享交换的积极性、主动性，进而形成公共信息服务集成体。

参考文献：

［1］丁煌.西方行政学理论概要［M］.北京：中国人民大学出版社，2005：380.

［2］R. B. Denhardt， J.V.Denhardt. The New Public Service： Serving Rather than Steering ［J］. Public Administration Review， 2000， 60（6）：553-556.

［3］海峰等.集成论的基本范畴［J］.中国软科学，2001，（1）：114-117.

［4］李辉.2011年《法治蓝皮书》发布［EB/OL］.［2011-11-10］.http：//news.hexun.com/2011-03-07/127766521.html.

［5］From integrating services to integrating government： report by the iGov2010 Project Steering Committee［EB/OL］.［2011-11-12］.http：//www.worldcat.org/title/from-integrating-services-to-integrating-government-report-by-the-igov2010-project-steering-committee/oclc/070886481.

［6］Just for Citizens［EB/OL］.［2011-11-13］.http：//www.usa.gov/.

［7］Inclusive e-Government ［EB/OL］.［2011-11-15 ］.http：//ec.europa.eu/information_society/activities/einclusion/policy/egov/index_en.htm.

［8］New Centrelink Network Launched ［EB/OL］.［2010-11-15］.http：//www.centrelink.gov.au/internet/internet.nsf/media/media_releases_launch.htm.

［9］王长胜，许晓平.中国电子政务发展报告（2010）［M］.北京：社会科学文献出版社，2010：176-185.

［10］About Service Canada ［EB/OL］.［2010-11-15］. http：//www.servicecanada.gc.ca/eng/about/index.shtml

物流金融的集成服务研究 篇4

企业的流动资产从货币形态开始, 依次转变形态, 最后回到货币形态的过程中, 占有了大量资金, 这为开展物流金融提供了一定的可能性。流动资产形态变化图如下:

很明显, 企业的流动资产是占有资金的, 物流企业通过创新物流金融的实现路径, 可以盘活这些流动资产, 提升企业经营资金的周转效率和获利能力。

物流金融的基本思想是:物流企业在传统物流服务的基础上, 与金融机构合作, 共同帮助客户盘活流动资产, 缓解资金占用问题。对单个企业来说, 物流金融服务只涉及供应链某个环节, 而要真正发挥物流金融的作用, 应该将服务向上下游延伸, 增强物流和资金流的连续性。由此可以进行单个物流金融产品组合, 得到三种集成服务方案。

1、生产、销售环节集成

生产物流中的产成品和销售物流中的商品实质上同物异名, 是两种物流形态的衔接点, 因此, 在生产物流和销售物流中, 可以实施“质押监管+未来提货权融资+保理”等集成物流金融服务, 具体业务流程如下图2:

2、供应、生产环节集成

供应物流和生产物流的衔接点也是库存。对制造商来说, 预付款占用资金;对供应商来说, 售后货款有坏账风险。因此, 可以通过“未来提货权融资+统一授信融资”集成服务方式开展物流金融, 具体流程如下图3:

值得一提的是, 在制造商付款提货过程中, 物流企业不必立刻跟供应商结算, 之间有一个时间差, 这段时间内制造商支付的货款归物流企业所有, 物流企业可以进行资本运作。类似的路径有“托收+授信融资”和“垫付货款+授信融资”。

3、全供应链集成服务

全供应链上的集成物流金融业务形式多样, 如“订单融资+质押监管+未来提货权融资”。具体流程如下:

物流金融是近几年兴起的一股新潮, 从实践的成果来看, 这种模式确实为企业注入了新鲜血液。但也应该意识到, 要实现这种新型商业模式的持续、健康发展, 需要从系统的角度集成各种物流金融产品, 这样才能发挥物流金融最大的作用。

摘要：本文从供应链角度, 提供了“质押监管+未来提货权融资+保理”、“未来提货权融资+授信融资”和“授信融资+质押监管+保理”三种物流金融的集成服务方案, 以期对企业开展物流金融有一定的借鉴意义。

关键词：物流金融,质押监管,未来提货权融资,保理,授信融资

参考文献

[1]邹小芃, 陈万翔.国内物流金融研究综述[J].商业时代, 2006, (36) :17-18.

[2]Sidney Rutberg.Financing the supply chain by Piggy-backing on the Massive Distribution Clout of United Parcel Service[J].The Second lender, 2002, 58 (6) :40-46.

[3]汤洪宇.开放条件下我国物流金融发展模式研究[D].广西:广西大学, 2008.

集成服务 篇5

基于Web服务的企业应用集成系统及其接口

阐述了针对中小制造企业的应用集成的方式和Web服务的基本原理及其标准协议,并通过实例给出了基于Web服务的企业应用集成系统的框架体系,提出了一种开发Web服务应用程序接口的方法,通过将该接口应用于基于Web服务的`企业应用集成系统框架体系结构中,实现了中小制造企业应用系统的集成.

作 者：卢丽丽 闫光荣 韩承祥 Lu Lili Yan Guangrong Han Chengxiang 作者单位：北京航空航天大学机械工程及自动化学院刊 名：航空制造技术 ISTIC英文刊名：AERONAUTICAL MANUFACTURING TECHNOLOGY年，卷(期)：“”(5)分类号：V2关键词：企业应用集成 Web服务 接口

集成服务 篇6

关键词：地下管线工程档案 集成服务 模式

1 集成服务研究

为进一步做好城市地下管线工程档案管理与服务，通过对1994年以来中国知网收录的集成服务方面文章进行综合分析，并对近些年一些理论文章进行研究，笔者认为我国集成服务研究存在着如下的问题：第一，对于集成服务的研究相对分散，虽然也取得了大量的研究成果，但是都是分散在各个领域，不很集中，也不够系统。第二，对于集成服务的理论研究欠缺，目前的研究大多是具体的实践经验的总结，不能称之为系统化的理论。第三，档案集成服务问题的研究不足，尤其是城市地下管线工程档案的集成服务，寥寥无几。

2 集成服务模式的类型①

集成服务模式依据不同的标准可以划分为多种不同的类型，依据集成服务系统建立的特征，城市建设文件、档案信息集成服务可分为以下三种模式：①独立式，是通过系统内业务环节或业务过程的集成而实现城市建设文件、档案信息服务自动化的一种模式。在该模式下所进行的只是孤立的系统集成和孤立的系统服务。②整合式，是通过系统间建立集成的机制来保证产品质量实现城市建设文件、档案信息服务网络化的一种模式。通过对各种质量规范进行统筹考虑，从多种客户需求、法律要求及质量要求出发来建立文件质量保证体系，保证文件质量标准及数据交换标准具有跨部门和跨系统兼容性的一种服务模式。这种模式下，文件及其信息的质量标准在文件生命全过程和工程项目全过程中得以连贯和一致，档案信息质量最终得以保证。③嵌入式，是通过复杂的系统间的各项功能的集成来实现城市建设文件、档案信息服务智能化的一种模式，也就是指依据城建文件、档案信息集成管理与集成服务原理，将城市建设文件、档案信息的各种业务管理活动、建设工程审批活动、及各专业单位的相关业务职能活动纳入与工程建设基本程序和城市建设工程规划及其管理过程，以保证管理过程经济、高效；依据客户关系管理理念全面考虑各类型档案信息的用户群需求，实现服务内容和服务方式的集约化、多元化、专业化和个性化的服务集成模式。这种模式中，城建文件档案信息的服务实现了与城建专业系统服务的集成，城建文件档案的价值得以最大实现。

3 城市地下管线工程档案集成服务的涵义及其最佳实践的特征

3.1 城市地下管理工程档案集成服务的涵义 城市地下管线工程档案集成服务即采用集成的思想和理念，保证城市地下管线工程档案信息质量，实现城市地下管线工程档案科学高效管理，从而达到用户服务高度满意的一种优化的服务理念和服务方式。

3.2 城市地下管理工程档案集成服务最佳实践的特征② 第一，城市地下管线工程管理流程集成（系统集成），即指以后现代档案管理理念为指导，将地下管线档案的各种管理系统、地下管线工程审批活动、各产权单位以及城建档案行政部门所扮演的角色、地下管线工程以及档案管理法规制度等纳入地下管线工程业务流程，以保证地下管线管理过程经济、高效。第二，城市地下管线工程档案产品集成（信息集成），即指通过对各种质量规范如：文件管理规范、档案管理规范、工程质量管理规范、信息分类规范、文件编目整理规范等都进行统筹考虑，真正从多方面保证信息数据的质量，使得各种载体形式的地下管线档案信息都能确保其真实性、准确性、完整性、可靠性、安全性和可用性。第三，城市地下管线工程档案服务集成（功能集成），即指依据客户关系管理理念全面考虑地下管线信息的用户群，实现服务内容和服务方式的集约化、多元化、专业化和个性化。和目前我国城市地下管线工程档案管理存在的几种模式相比，城市地下管线工程档案集成服务模式视角更开阔，涵盖范围更广，适用的对象更广泛，是一种具有普遍指导意义的理念、方式和模式。

4 城市地下管线工程档案集成服务的必要性、可行性及重要意义

4.1 必要性 城市地下管线工程建设是城市基本建设的重要组成部分，纵横交织的城市地下管线与社会生产和人民生活密切相关，是现代城市的“生命线”。城市地下管线档案必须实行集成服务，才能够为社会提供高效和高质量的服务。首先，城市地下管线本身处于动态变化之中，只有进行全程管理和集成的文件质量服务控制，才能够保障城市地下管线档案信息的真实性、完整性、准确性和可用性。其次，数字化、信息化的社会需要城市地下管线工程档案的集成服务。信息时代的到来，提出了集成信息、集约化服务等需求。最后，城市地下管线工程档案如果不采用集成服务的理念，档案服务系统将处于孤岛状况，服务将滞后于城市建设的需求，服务工作难以实现高效率和高效果，服务水平就不可能提高。

4.2 可行性 信息时代的到来为实现城市地下管线工程档案集成服务提供了各种有利条件。首先，《档案法》、《城市建设档案管理规定》以及城市管线档案管理办法（规定）等法规制度的完善为实现城市地下管线工程档案集成服务提供了保障。其次，现代信息技术和测绘技术的发展为实现城市地下管线工程档案的集成服务提供了技术平台。第一、信息技术尤其是计算机和通讯技术的发展，电子图纸和其他电子数据的形成，大大方便了城市地下管线信息的传输、移交和提供利用。第二、GIS能够将地下管线数据信息在系统中进行集成，为包括城市地下管线信息在内的综合性地理信息的管理与服务提供了一个先进的技术平台。第三、现代测绘技术的发展，使得地下管线的普查补测工作不再成为城市地下管线档案收集工作的障碍。最后，社会主义市场经济的发展，为城市地下管线工程档案管理提供了更广阔的发展空间。城市地下管线档案作为一种重要的信息资源，必须与市场接轨，才能够发挥自身的专业性优势，创造更高的经济效益和社会效益。

4.3 选择城市地下管线工程档案集成服务模式的意义

4.3.1 城市地下管线工程档案集成服务的受益广泛。城市地下管线工程档案集成服务的受益是多方面的。城市建设行政管理部门、建设单位、施工单位、管线产权单位、城建档案管理部门、城市规划设计、测绘部门和政府以及社会公众，都能够从中受益。城市建设部门能够发现体制上的弊端，理顺工作中的各种关系，改革管理体制，做好管理工作；建设单位能够在保护自己权益的前提下依据可靠的管线信息保证建设工程顺利施工；各管线产权单位能够在科学合理保管和使用本专业管线档案的同时，加强与其他管线产权单位的联系，共建管沟，科学利用地下空间，防止因管线归属不同，报批和施工各自为政，且重复建设，频繁开挖，影响市民生活；城建档案管理机构（城建档案馆）能够对全市的地下管线档案进行集中统一管理和提供利用；城市规划设计与测绘部门可以利用已有的多种管线综合信息为新的管线工程提供科学的数据和预测信息；对政府而言，城市地下管线工程档案的集成服务是政府行政效率提高的一个重要表现；对公众而言，其知情权得到了保护。

4.3.2 与传统的管理模式相比，集成服务模式具有以下优点：第一，采用后现代主义思想和后现代档案管理理念，把档案的管理纳入地下管线工程建设业务活动过程中，对业务流程进行全程控制，易于保证管线档案信息的质量。第二，采用客户关系管理理念，综合考虑多种类型的客户和多种形式的客户需求，努力达到集约化、多元化和个性化的服务，易于提高用户服务的满意度。第三，采用集成的管理机制，更有利于城市地下管线工程档案信息资源的积累、共享与交流，易于管线工程文件档案信息管理与服务的整合与优化，有利于城市可持续发展。

注释：

①该部分内容的撰写参考了：华灿丽，“EDMS 与ERMS集成管理的国际化实践经验及其启示”，《城市建设文件档案信息集成管理与集成服务研究》（论文集），北京：中国建筑工业出版社，2004年11月，第124-132页.

②本部分内容的撰写参考了：安小米，“集成管理与集成服务：21世纪城市建设文件、档案信息最优化管理的理论与实践研究（节选）”，《城建档案》，2003年第5期，第15-17页。安小米，“城建文件、档案信息集成管理与集成服务研究及其启示”，《城市建设文件档案信息集成管理与集成服务研究》（论文集），北京：中国建筑工业出版社，2004年11月，第87-101页.

参考文献：

[1]安小米.“集成管理与集成服务：21世纪城市建设文件、档案信息最优化管理的理论与实践研究”，承德会议研究报告，2003年8月.

[2]孟广均，徐引箎.“服务集成：图书馆信息服务的未来模式”，《国外图书馆学情报学研究进展》北京：北京图书馆出版社，1999.

数字油田数据集成及服务体系研究 篇7

随着近十年来“数字油田”被国内大部分油田相继确定为信息化建设目标, 到目前将“云计算”和“物联网”等先进信息化技术应用到油气生产流程中, 已经成为国内“数字油田”建设的主要方向。但是, 无论是建设油田生产、科研、管理和决策的综合基础信息平台的“数字油田”, 还是建设高智能感知油田动态信息、自动操控油田活动、预测油田各方面变化趋势的“智能油田”, 它们的核心都是一样的, 就是必须实现各类专业数据的集中统一管理[1], 让数据“进的来、出的去”, 所以最佳方案是通过围绕勘探开发一体化中心主库 (以下简称勘探开发主库) 来建立统一的数据集成与服务体系, 才能最终满足对油田海量数据的分析、处理、认知和判断, 最大限度地实现对油田可视化、可量测的智能化管理与控制。

一、勘探开发主库建设

勘探开发主库以中国石油统一的石油勘探开发数据模型EPDM为基础, EPDM模型是一个基于对象的数据模型, 包括基本实体、地球物理、钻井、录井、测井、试油试采、地质油藏、油气生产等覆盖油田勘探开发等各个专业领域。

勘探开发主库建设分为三个步骤, 首先是EPDM模型的本地化工作, 即按照模型设计规范要求, 结合本油田各专业业务特点, 严格执行控制各专业数据库数据采集的范围, 避免大而全, 同时各专业数据库的核心实体数据必须来自勘探开发主库, 严格禁止各专业库录入非本专业产生的实体数据, 通过利用主外键关系、域完整性[2]、代码表等方式规范勘探开发主库数据, 同时还要充分考虑在未来扩展新业务时, 不会影响到核心模型;其次是进行历史数据资源补充完善、专业库管理系统及采油单位正常化系统建设来实现各类专业数据的采集、审核和进入专业库;最后是建立勘探开发数据集成和服务体系架构, 形成以保证数据完整性、一致性、及时性的数据集成体系和应对不同层面的数据需求, 合理快捷地提供各取所需的数据服务体系, 只有数据集成和服务体系的健全和完善, 才能为油田的科研、生产及管理工作提供强有力的数据支持。

二、数据集成

数据集成是指将钻、录、测、试、分析化验、油气生产等专业数据库数据抽取到勘探开发主库, 在可维护, 实时同步、资源占用等方面综合考虑下, 最佳方式是采用Oracle的数据集成工具ODI (Oracle Data Integrator) 。ODI本身是一种开放的架构, 支持目前流行的关系数据库, 同时由于其本身是Java开发的产品, 可以跨Windows、Unix平台。ODI最大的特点是提出了知识模块的概念 (Knowledge Module) , 它把一些场景 (如不同数据库之间抓、送数据等操作) 的详细操作步骤记录为一个个知识模块供用户调用[3]。由ODI提供的100 多个知识模块中, 基本包含了普通应用所涉及的所有场景。此外还可以利用Java Python语言对知识模块进行二次开发, 实现测井曲线数据体、科研图形文档 (BLOB、CLOB) 等大对象集成到勘探开发主库, 不仅如此, ODI自10.1.3.6_02 版本后, 增加了针对采用Golden Gate获取源数据库增量变化的知识模块, 替代ODI中传统的Logminer抓取数据的部分, 避免了对源数据库系统的影响, 从而实现更加快速实时的数据集成解决方案。

2.1 数据集成方式和周期。ODI主要有全量和增量两种集成方式, 工作方式是“先全后增”, 即先做全量集成, 后做增量集成。

全量集成是指将各专业库当前所有数据一次性集成到勘探开发主库, 实现的步骤包括建立建立专业库和勘探开发主库物理方案;建立专业库和勘探开发主库逻辑方案;分别建立各自的上下文;通过上下文连接专业库和勘探开发主库的物理方案与逻辑方案;建立各自模型和模型下建立各自的目标存储库, 然后建立项目;导入知识模块;建立接口并完成字段映射;最后测试接口;创建并运行程序包, 如出现错误根据错误信息进行修改, 直到最终完成所有专业库的全量数据集成。

增量集成是指每次只将专业库上发生变化的数据同步到勘探开发主库, 以减轻专业库服务器和网络负担。在技术实现上, 主要有触发器、日志位和标志位三种方式, 在集成周期上, 包含实时和定时两种集成周期, 实时集成主要采用轮询方式实现, 随时监控专业库的数据变化情况, 一旦有变化即把专业库的数据同步到勘探开发主库。实时集成主要包括采用触发器记录新增数据的同步CDC模式 (Change Data Capture变化数据捕获) 和通过分析已经提交的日志记录来得到增量数据的异步CDC模式;定时集成一般采用专业库具体表的日期字段作为标志位作为变量, 在某一固定时间或每隔多长时间通过标志位判断进行增量集成[4]。

具体采用何种方式进行增量集成, 这就需要针对各专业库特点区别对待, 以不对专业库造成太大的压力, 影响各专业正常化系统运行为前提, 例如对油气生产日数据实施异步CDC的实时集成, 对油气生产月数据则要实施标志位的定时数据集成, 对于实时性不强或一次同步数据量较大的数据集成, 一般将执行计划设定在半夜或凌晨即网络和服务器都空闲时做集成, 当然随着油田各类应用软件对实时数据的需求, 将来必然会实施同步CDC模式。

2.2 数据集成监控。ODI的运行常会受到各种因素的影响而导致中断, 尤其是在数据集成过程中, 因为各专业数据正常化系统后台数据模型都是应用模型, 而勘探开发主库模型是对象模型, 在ODI程序包运行中随时都会出现各类问题, 如井、站队、井组等实体更新不及时, 出现违反唯一约束条件、完整约束条件、已找到子记录但父项关键字未找到、无效数字、分布式事务处理等待锁、空值无法插入等各类Oracle错误, 还有任务解释期间出错、口令过期、用户被锁、网络故障、专业库服务器宕机等问题都需要进行监控, 出现问题及时解决和反馈, 这就需要对数据集成进行实时监控, 出现问题后以最直观的方式告知运维人员[5]。

由于ODI提供了调用Web Service的机制, 同时ODI的数据接口也可以暴露为Web Service组件, 从而可以和SOA环境进行交互, 经过对开发速度、开发效率以及系统耦合度的论证, 采用基于JSF+Spring+Hibernate+Web Service为开发框架是ODI Web数据集成监控平台建设的最佳选择, 同时也确定了数据集成监控是数据集成工作必不可少的一部分。

数据集成监控平台是对各专业库数据集成到勘探开发主库的数据过程提供集成信息服务展示、运行状态监控、异常信息管理和集成数据统计等直观的展示, 尤其重要的功能是将数据集成过程中的抛出的出错信息利用RTX (腾讯公司的企业级即时通信平台) 消息提醒或者手机短信的方式提示运维管理员。同时建立一个知识库将这些错误信息和处理办法进行统计, 以方便其他运维管理员进行学习和参照。

三、数据服务

数据库建设不仅是数据的建设, 要体现数据库的价值, 还要需要强有力的数据服务体系, 才能够应对不同层面的数据需求, 合理快捷地提供数据, 但是由于勘探开发主库的EPDM模型是对象模型并不适合油田的实际应用。

3.1 数据应用层。EPDM模型是采用面向对象的数据建模技术, 从企业层面分析并描述了石油天然气勘探开发核心业务流和数据流, 并按照完整的井生命周期进行设计, 但是目前大多数的油田业务专家和勘探开发应用软件使用的是PCDM2002 模型, 所以, 勘探开发主库专业应用层构建是采用PCDM2002 模型以数据库视图方式提供数据服务, 首先建立基于PCDM2002 模型的基础视图, 然后再根据软件开发与业务人员的需求建立专业综合视图, 同时为了支持大型应用软件建立针对具体专业应用软件的专业软件视图, 在三类视图命名规则上进行严格定义和登记, 使在进行数据服务过程中一目了然, 避免出现差错。数据服务体系也是基于三类应用层视图进行开展和完善的。

3.2 数据服务对象。只有先清楚数据服务对象, 了解服务对象的需求, 才能有针对性的提供不同的数据服务, 是数据集成及服务体系建设的关键。经过归纳整理分析, 数据服务对象共分为三大类[6]。

第一类, 对拥有后台数据库的专业应用软件、勘探开发综合研究项目库、采油单位生产项目库提供数据分发服务方式, 直接“送数上门”。

第二类, 对软件开发人员和各专业正常化系统的井实体查询采取Web Service服务方式, 在支持.NET开发基础上, 增加JSON返回类型, 提供对IOS、Android、Windows Phone移动开发平台的数据服务支持, 达到“取数自助”。

第三类, 对油田科研、生产、管理人员采取通过“勘探开发主库应用平台”进行“数据查询下载”的服务方式, 实现“现查现用”。

3.3 数据服务方式。“送数上门”即数据分发, 数据分发与数据集成在技术实现上是有区别的, 数据集成是源表到目标表的数据传输, 而数据分发是视图到目标表的数据传输。视图在ODI中是无法实现数据实时同步的, 只能将勘探开发主库应用层视图及其主表关联作为源表, 将主表作为启动日记表, 当主表数据发生变更时, 源表才会发生变更, 以此才能达到实时传输数据的目的。此外, 还必须测试目标表的主键在对应的视图中字段是否唯一、有无空值等问题, 技术解决方案测试成功后, 就可以根据数据的及时性、重要性、使用频度进行数据的定时和实时接口划分, 最后才可以依次创建接口、程序包、生成方案、创建执行计划等步骤, 最终按专业将数据分发到项目库或专业应用软件后台数据库。

在对采油单位生产项目库进行数据分发时, 由于是采用一套业务模型向各采油单位分发数据, 只要建立好一个采油单位的数据传输接口即可, 向其它采油单位传输数据时不必重建接口, 只需要在采油单位Oracle数据库服务器上建立一个有采油单位唯一识别符记录的表, 利用在ODI数据分发项目中建立好的字符变量, 将变量值保存为采油单位唯一识别符后, 根据采油单位不同的上下文就可以实现勘探开发主库同时对多个采油单位的数据分发。

“取数自助”即利用Web Service技术为应用系统平台研发提供数据服务支撑, Web Service是目前软件开发的流行技术趋势, 通过XML Web Service标准, 应用软件之间可以实现跨平台, 跨编程语言的连接和互操作, 还可以有效地分解软件自身功能, 提炼软件中的公共部分, 勘探开发主库的Web Service包含非功能性和功能性两大类, 非功能性Web Service是提供井实体、区块等应用层基础视图查询服务;功能性Web Service是提供柱状图数据、平面图数据、测井成果图数据、地震数据等服务等专业数据服务, 这样目前和今后的科研、管理等专业软件开发中, 需要什么数据可根据Web服务注释“自助”的获取和定制, 随着科研管理等专业软件开发的深入, Web Service集越来越完善, 以后的软件开发工作量就会越来越少, 最后, 软件就是一个功能非常具体的客户端, 同时也降低了油田专业人员进行软件开发的难度, 只要通过短期的培训就能开发出自己想要功能软件, 不仅软件开发工作量减少, 而且勘探开发主库安全性也能得到进一步保证。

“现查现用”即利用“勘探开发主库应用平台”提供的树形导航查询、GIS查询、井名黄页查询、关联查询等查询方式进行数据查询、浏览和下载, 满足科研、生产、管理人员日常工作中方便快捷的获取历史和最新数据。

除了上述三种数据服务方式外, 还有一种服务称为“应用桥梁”, 即通过建立勘探开发综合研究项目库, 实现勘探开发主库将各专业数据快速分发到勘探开发综合研究项目库, 并利用Open Spirit实现专业数据在项目库与应用软件 (Geo Frame、Open Works、Petro Bank、Petrel等) 、应用软件与应用软件之间的便捷查询、格式转换、数据迁移等, 实现数据的统一管理和共享。

结束语

数据集成及服务体系是“数字油田”建设的核心, 通过ODI这个不停转动的“马达”, 将源头采集的各类专业数据完整、快速、高效的驱动它们到能发挥作用的领域, 变成表格、图形、曲线, 进而进入科研管理人员的头脑变成认识, 最后指导科研生产后再变成数据, 这是一个多么美妙神奇的数字之旅, 值得我们为之付出和努力!

参考文献

[1]武兴悦, 石丽梅, 王钢.基于ODI的应用数据交换、共享平台的研究与实现[J].计算机与数字工程, 2009, 37 (9) :89-98.

[2]练亚雄, 袁志刚, 万晓卿.用ODI实现信息管理系统间数据同步和共享[J].电脑编程技巧与维护, 2012 (8) :41-50.

[3]Oracle.The Oracle Data Integrator Enterprise Edition Configuration files[P], 2008.

[4]方禹润.基于ODI和WEB SERVICE的数据交换平台设计与实现[D].哈尔滨:哈尔滨工业大学, 2011.

[5]陈天河.Struts, Hibernate, Spring集成开发宝典[M].北京:电子工业出版社, 2007:485-489.

浅谈档案信息服务集成管理研究 篇8

一、档案信息服务集成背景介绍

用户对档案信息的查询需求是推进档案信息服务集成的最为本质的要求。当今信息技术的快速发展, 使得互联网、通信技术、以及云存储技术等相互融合, 形成了全新的当今生态系统网络。这使得用户希望通过这种生态网络有效获得档案信息, 也即在线、实时获得全部相关的信息, 这就要求各级档案部门顺应技术趋势, 加快档案信息服务系统建设。

此外, 针对档案专业本身的信息化建设, 比如政府办公自动化、档案业务流程管理信息化、复杂业务异构系统环境、文件及档案管理系统与现代信息管理系统间的整合等, 都迫切需要建立一个现代信息集成服务体系与之相匹配。

二、档案信息服务集成管理优势分析

档案信息服务集成的突出优势是相较于传统档案提供及利用服务而言的。传统的档案提供及利用服务主要是针对传统的纸质档案而言, 用户利用的效果不佳, 且利用档案的手续非常繁复。而档案信息集成服务则从根本上进行了改变, 档案信息服务集成将档案、文件的用户需求与业务管理有机衔接起来, 通过建立集成了异构的数字资源的检索系统, 通过建立数字化咨询信息系统等个性化的服务, 从而实现了档案信息资源的有效集成。信息集成服务的全面性、即时性、准确性、个性化等特点与优势更好的展现了现实背景下档案提供利用工作的指导思想, 更好地为档案用户服务, 为各类社会活动、社会文化等资源的存储与共享提供了有效保障。

三、档案信息服务集成管理体系的构成

(一) 实施标准化管理, 制定各类档案的专业标准, 是档案信息服务集成的前提

目前科学技术发展迅速, 需进一步推动档案工作的标准化体系建立, 使档案部门真正具备与现代技术进步相适应的标准化信息管理, 包括统一的专业术语定义、统一的数据交换方式、信息分类编码、功能设置、通讯规程、支撑系统与环境等, 这些基本标准的制定是实现档案利用开发的前提, 特别是现在档案资源信息服务集成管理的基石。只有真正在档案工作内部建立起一套统一的标准和规范行为准则, 建立了一种信息可以自由流通的共享平台, 才能在各档案部门形成开放信息联盟, 将原本看似孤立的各类档案文件有机的联系起来, 从而成为十分重要的档案信息资源。没有完善的档案标准化体系, 档案信息的集成服务就无从谈起, 就成了无源之水, 无本之木。

(二) 整合档案文件资源, 形成信息资源集成系统, 它为档案信息服务集成管理提供可利用的载体

档案文件资源主要包括两大类, 传统档案与电子文件。为了适应新形势下档案提供利用方式的发展, 按照档案信息服务集成管理的要求, 对传统档案与电子文件进行整合管理, 形成符合条件要求的信息资源, 为档案信息服务集成管理提供可利用的载体。这就要求我们对传统档案进行数字化处加工, 对电子文件进行数据导出, 建立格式统一的, 标准规范的数据库, 规范馆内乃至馆际数字档案馆信息资源, 形成真正意义上统一的档案信息资源集成系统。

(三) 做好信息服务的质量管理, 档案信息服务集成管理的主要目标

这主要可分为两个部分:一是业务质量管理, 即提供档案信息服务各流程中的业务质量管理, 大致包括档案信息检索平台的构建, 档案信息检索管理, 档案信息复制与备份管理, 档案编研成果管理等等。这些业务流程与管理大多有异于传统的档案提供利用, 主要是建立在虚拟网络环境中档案信息提供服务利用, 应该自信息资源形成之初即加强对整个工作流程与各项业务统一全面的质量管理, 特别是信息服务中安全性保障, 检索服务中各项数据统一性与准确性, 主动服务中利用与宣传等等。二是服务质量的管理。也即, 我们除了要确保所提供的档案资源信息的质量, 还需注重对用户提供有效的档案提供服务。有效的含义包括:是否为用户提供了足够的他所需的有用档案资源信息;在提供对应档案资源信息时是否真正给以方便快捷的服务;以及是否以积极主动的态度为用户利用档案的行为提供服务等, 这些都是档案信息服务集成管理的主要目标。

(四) 计算成本管理, 为档案信息集成服务提供最有力的支持

档案信息服务集成管理体系中关于成本的计算与管理也是不可或缺的。档案信息服务成本中除传统的人力、工作成本外, 还包括新体系构建过程中的沟通成本、创新成本和导入成本等。比如导入成本, 即技术成本, 主要是指人们对档案信息服务进行集成化管理时, 需要购置的硬件设备和软件系统, 具体比如计算机网络系统、服务器等各种必须的硬件设备, 各种管理软件以及相应的数据库、信息库等软件设备。创新成本指在档案信息集成过程中, 由于各种创新活动的不同步、不协调, 在重组创新集成体系所面临的障碍与阻力时所必须支付的成本。沟通成本指在档案管理与提供利用的过程中档案集成系统内外沟通与交流时所花费的费用。把握信息服务的成本种类, 计算与设定总的目标成本, 平衡与分解各具体成本, 对各类成本实施有效的过程控制, 保证最终目标成本的实现, 可以为档案信息集成服务的开展提供有力的支持与保障。

四、档案信息服务集成管理的实现

首先, 实现现代档案资源的信息服务集成更新现有观念, 也即从传统的思维模式中跳开, 用系统的思维方式看待新的档案工作流程、理解集成化的档案管理信息系统以及档案集成服务模式。唯有如此, 才能推进档案事业的快速发展。其次, 实现档案资源的信息服务集成还必须要充分掌握技术。因为档案信息服务集成是以集成各类异构数据资源和现代技术的实现为前提。只有当我们有效掌握了文本、数据、图像和声音的多媒体数据库、数据仓库和云存储等技术, 建立强大的集成计算环境, 才能使信息集成服务的实现成为可能。最后, 要进一步提高档案人员的综合知识体系结构。要实时培训、扩充自身的知识结构, 成为集成服务体系的主导者;要做好自身角色定位的转换。从被动管理者转变为信息利用审计和决策咨询的提供及服务者。

参考文献

[1]贾洪生周国富.网络环境下信息服务的新趋势集成服务[J].情报杂志, 2003 (11) .

[2]李宝山.集成管理——高科技时代的管理创新[M].中国人民大学出版社.

[3]梁孟华.基于全面质量管理的档案信息集成服务研究[J].档案学通讯, 2011 (01) .

高校图书馆信息集成服务浅议 篇9

1.1资源集成。

信息集成服务的基础是信息资源, 馆藏资源包括了大量结构化和非结构化的数字资源以及非数字资源。借由信息技术将不同位置不同结构的信息资源链接在一起, 形成信息集成服务的资源基础。通过业务流程重构和资源优化配置, 实现信息资源利用的最大化。

1.2服务集成。

整合门户网站、身份认证系统、OPAC和数据库系统, 集成网络导航、参考咨询、个性定制和特色服务。以综合门户为应用平台, 通过单点身份认证系统, 为读者提供“一站式”服务, 构建一个信息集成服务的环境基础, 实现信息服务方式和服务功能的融合。

二、高校图书馆信息集成服务的现状

2.1信息集成服务的宽度有待扩展。

高校图书馆信息资源逐渐多样化, 涵盖实体图书刊物、音像制品、多媒体资源、电子文献等多种载体。现阶段, 不少院校图书馆已经能在一定范围内实现馆藏资源的“一站式”使用。但是这一范围局限于OPAC数据和规模较大的数据库间。

2.2信息集成服务的深度有待挖掘。

传统图书馆信息服务仅仅提供一个个元数据, 未经加工, 为了达到使用目的, 读者还得耗费时间进行鉴别。细分的精加工服务, 避免了读者在庞大数据中分类、挑选的艰辛过程, 而是直观地使用加工后的精品内容。

三、高校图书馆信息集成服务的需求以及优势

3.1需求。

(1) 交叉学科环境下的专业化需求。高校图书馆读者为完成学习、教学、科研等任务, 在使用图书馆门户的过程中, 不可避免地需要使用到交叉学科的知识。传统图书馆所提供的单学科、单领域的专题数据库方式已经不能满足读者信息专业化需求。 (2) 信息集成服务中的高效化需求。传统图书馆资源庞大而无序, 使用过程中读者不得不耗费时间精力从分散的资源中提炼和组织。这就要求图书馆在信息集成的过程中, 进行数据的二次开发和加工, 将重组后的数字资源提供给读者, 已满足读者高效化“一站式”资源访问需求。

3.2优势:

(1) 优化馆藏资源, 提升文献信息使用率。信息集成服务打破了图书馆原有馆藏资源割裂的现象, 有利于馆员将馆藏文献信息完整系统地揭示给读者。通过对图书馆信息资源的整体二次开发和利用, 使读者能更全面地利用部分冷门信息资源, 最大限度地满足不同类型读者的多层次、个性化需求。 (2) 读者服务向参考咨询转移。经过信息集成服务的二次开发, 信息集成服务一定要面向读者、面向任务, 图书馆工作人员的工作重心不再局限于数据加工和维护, 工作对象从元数据转向读者服务, 提升了服务层次。

图书馆信息集成服务的目的是对分布式具有差异性的数字信息资源和服务进行集成, 实现对原有的分散的图书馆数字资源服务系统的统一控制, 使读者获得全方位、多元化动态信息服务, 从而构建数字图书馆面向用户、面向任务的综合化信息集成服务体系。

结语

传统图书馆信息管理模式已经不能满足读者需求, 而多系统、大数据的图书馆数字资源很大程度上给读者的使用带来很多不便。图书馆信息集成服务通过对图书馆现有资源和系统的整合、挖掘, 提高了图书馆服务系统的能力, 完成图书馆信息服务模式从面向数据到面向用户的转变。以信息集成服务为核心的图书馆信息服务必定在此基础上有不断的发展。

参考文献

基于ESB的Web服务集成技术 篇10

近年来,软件系统的开发方法正由面向功能的开发方法转向面向服务的、面向流程的开发方法,由基于模块的构造方法转向基于组件的构造方法[1]。传统的三层体系结构是一种面向单应用、紧耦合的分布式系统解决方案。随着网络应用的普及化,基于网络传输的大型分布式系统迫切需要将现有的多个应用系统集成,以保护用户投资并实现更强的信息处理能力,如电子政务、电子商务、智能交通、数字地球、税务数据的大集中,银行的通存通取等应用系统的集成。随着JMS(Java Messaging Service)、XML[2](eXtensible Markup Language)、SOAP[3,4,5](Simple Object Access Protocol)、WSDL[6](Web Service Description Language)和UDDI[7](Universal Description,Discovery,and Integration)等适用于Web服务[8](Web Service)的标准的出现和面向服务体系结构SOA[6]的发展,为企业服务总线ESB这种基于标准的、松耦合的和异构多应用系统集成的解决方案提供了基础技术支持。基于ESB的集成系统能有效地降低集成成本,快捷高效灵活地适应企业的异构应用系统集成,面向服务(Web服务)的ESB集成技术已经成为一种趋势。

本文探讨了ESB的功能,提出了面向Web服务的ESB架构,给出了基于ESB的政务信息资源交换平台解决方案,采用整合思想对系统进行设计,运用ESB技术对Web服务进行集成,有效地降低了各服务构件间的耦合,消除了在应用过程中异构构件之间的技术差异,使不同应用服务能协作运行,通过不同服务之间的消息通信,实现电子政务系统的低成本和高效集成。

1 Web服务

Web服务是开放的基于因特网标准(如HTTP),松散藕合、可重用,可编程访问、自适应和自描述的Web组件。它具有模块化、良好描述、实现独立、可访问性和互操作性好等优势[9]。Web服务由WSDL、SOAP和UDDI三个基本结构单元组成,它们解决了Web服务的描述、通信和发布等基本问题,是构建Web服务的核心与基础。Web服务协议栈进一步对Web服务的互操作、路由、安全和服务质量等进行了规范。

2 SOA体系结构

SOA是一种将服务构件装配成分布系统的体系结构参考模型,它具有基于行业标准、松散耦合、与协议无关性和业务敏捷性等优势。SOA有服务使用者、服务提供者和服务注册中心三种基本角色。SOA的工作机制包括发布、发现和绑定/调用字种基本操作,发布是为了使服务可访问,需要发布服务描述以便服务使用者可以发现和调用它;发现是指服务请求者定位服务,方法是查询服务注册中心找到满足其标准的服务;绑定/调用是在检索完服务描述之后,服务使用者继续根据服务描述中的信息来调用服务。

3 ESB架构

3.1 ESB功能

ESB是从SOA发展而来的。SOA实现和解决了服务模块间调用的互操作问题,为了提高企业级服务集成的适应性、灵活性、可扩展性,降低集成门槛,引入了ESB。ESB是一种新兴的、松散耦合的、基于标准的实现服务和应用无缝集成的中间件技术。一个ESB是一个预先组装的SOA实现,它包含了实现SOA分层目标所必需的基础功能部件,它集通信、Web服务、XML和数据传输于一体,管理相关连接并协调应用交互[10]。ESB提供了消息驱动、事件驱动和文档导向的处理模式,以及分布式的运行管理机制,支持基于内容的路由和过滤,具备复杂数据的传输能力,并可提供一系列的标准接口。

ESB作为一种使用SOAP和JMS等标准技术来实现的消息代理架构,提供了消息队列系统,在不同的业务应用之间提供公共、基于标准的应用连接和处理平衡。ESB实现的主要功能有:①提供位置透明的服务路由和寻址服务;②提供请求/响应、单路请求和发布/订阅等多种消息传递模式;③支持HTTPJMS、FTP、SMTP和MQ等多种传输协议;④通过元数据来控制数据的接收、发送、过滤和安全验证等,通过服务的智能化引擎来发现和调用服务;⑤提供事务、日志、安全、审计和监控等基础服务,提供有关服务管理、控制和接口策略;⑥支持Web服务、消息和适配器等多种服务集成方式;⑦能有效管理ESB的元数据与服务元数据。

3.2 面向Web服务的ESB架构

面向Web服务的ESB的体系结构由应用适配器、传输适配器、服务适配器、核心服务、元数据库和系统管理六个部分组成,如图1所示。

在面向Web服务的ESB体系结构中各个部分的作用是:①应用适配器:它将从Web服务、数据库应用、遗留系统、J2EE和.NET等应用中传递过来的消息转换成传输适配器能识别的统一信息表示方式,实现将现存的业务服务连接到ESB上,特定应用系统都有对应的应用适配器。②传输适配器:它是一个数据通信协议适配器,在接收应用适配器发送的请求消息,从底层通信消息中获取SOAP消息,并接收服务适配器返回的SOAP响应消息。它针对某种特定协议都有一个协议监听器,如SOAP、FTP、SMTP、HTTP和MQ监听器等。目前把SOAP协议绑定到HTTP协议上的应用最为广泛。③服务适配器:它是查找、定位和执行Web服务的核心。它可通过静态方式查找Web服务、或者向UDDI注册中心或JNDI等动态方式查找Web服务的服务描述信息实现本地或者远程Web服务的动态调用。④核心服务:它是传输适配器和服务适配器用来对ESB传输的SOAP消息进行控制的一些基础服务。包括安全服务、日志服务、事务服务等。安全服务包括对授权用户和非授权用户进行认证机制,保证传输到ESB中的消息是安全和可靠的,保证正确的过滤和路由。⑤元数据库:元数据是指ESB运行、管理需要的基础数据及其配置数据。规则库包括控制策略规则库、管理策略规则库和接口策略规则库等。⑥系统管理:它管理整个ESB,包括配置管理、策略管理、生命周期管理、消息监控和元数据管理等,其中配置管理用来对服务进行动态添加和注销,实现服务模型动态管理和监控。策略管理用来监控和管理服务的状态,对获取服务的规则进行动态的管理,实现优化网络和服务负载平衡,增加对边缘资源的利用率,提高服务的可靠性,以保证整个ESB稳定、高效的运行。

下面简要介绍有关核心部件基本功能的实现方法:①核心服务中的SOAP引擎是其核心部分,它主要由序列化器、反序列化器、编码器和解码器构成:序列化器把Java对象序列化为符合SOAP规范的XML字符串,以便将Java对象封装到SOAP消息中;反序列化器是把SOAP消息中封装的数据转换为Java对象;编码器对SOAP消息进行Base64编码;解码器则对Base64编码的消息进行解码。②传输适配器进行消息转换与转发,实现消息路由。其中的协议监听器一方面接收客户端的消息,另一方面实现底层的通信消息转变成SOAP消息,然后交由处理器链处理;由一系列处理器组成的处理器链按照部署设定的顺序执行,每个处理器完成某种特定的功能;前端控制器的主要任务是完成消息的转发,SOAP消息转发机制中的静态优先级保证SOAP消息的按照优先级的顺序进行转发,动态优先级则在提交SOAP消息时指定一个优先级,调度器在调度该SOAP消息时动态地计算该消息的优先级,以获得好的调度性能;基于规则的转发机制可通过输入条件得到下一站的转发地址;限于篇幅,基于JMS消息传递的队列方式的核心实现代码此处略;③服务适配器由服务处理器、业务代理、服务封装器、服务定位器、WSDL解析器、服务绑定等功能部件构成,它解析SOAP消息,对SOAP消息进行安全方面的操作、序列化与反序列化操作以及接收传输适配器发来的消息并转发给业务代理处理,并从业务代理获得响应消息,再转发给传输适配器。

4 基于ESB的政务信息资源交换平台设计

当前政务信息资源交换模式主要有集中交换模式、分布式交换模式和混合交换模式三种。集中交换模式是基于数据整合的系统集成方式;分布交换模式多用于异构系统互连,是目前跨部门信息交换的主要方式,具有构建灵活、可扩展性好、通信方式多、可充分保护以往系统投资,有效隔离下层交换服务与上层应用,使信息交换成为公共服务,为多个应用共享,可有效解决信息实时交换、信息适配和信息安全等,提高跨部门的有效性和可用性。混合模式是前面二者的综合运用。

传统的分布交换模式有点对点与Hub-Spoke结构,在点对点的服务集成中,若有N个服务互连,则会产生N*(N-1)个点到点的连接或接口,进而在集成第N+1个服务时,需要开发、文档化、测试和维护2N套新的接口,此外,它也不满足典型SOA架构对“服务的实现细节,服务的位置乃至服务请求的底层协议都应该透明”的要求;在Hub-Spoke结构中,由一个类似于Hub的中间件充当整个SOA架构的中央管理器,作为智能中转站,但它是一种基于部件的架构,没有统一开放的标准,扩展困难,在负载比较大时,性能会明显下降,甚至出现单点故障。

根据前述ESB的功能特点,采用基于ESB的分布式信息资源交换平台架构克服前述两种结构的不足,轻松解决各系统之间的信息管理、信息交换、信息共享以及其他公共功能,实现系统高效集成,提高集成系统的可扩展性、可管理性、可配置性和可审计性。基于ESB的政务信息资源交换平台架构如图2所示。

从图2可知,电子政务的业务应用、公共应用系统和政务信息资源库,通过ESB中各个系统特定的动态应用适配器,方便地封装成标准的接口,提供一致的访问行为和接口,实现平台挂接、支持各种类型的应用或数据源,形成协同办公、一站式服务的基础平台。基于ESB的信息资源交换平台能够提供数据描述、传输、安全加解密、转换、汇总、分发、转发、对等交换、同步、上/下载、组装等服务功能,实现数据的高效传输,并可防止数据的丢失、重传,简化了应用系统的开发。该结构属于松耦合,容易进行层次化的插件式结构扩展,构建跨部门的多级电子政务平台结构,以支持更大范围的广域方案。

在物理拓扑结构中,整个平台系统由中心服务器和节点服务器构成。中心服务器提供包括应用服务组合、组件开发环境、统一部署、监控管理、安全管理等平台公共应用支撑服务。节点服务器构成分布式的服务组件运行环境,并提供事件管理功能,如可靠事件的传输管理机制等,与各节点应用适配器运行于节点服务器上。中心服务器运行于覆盖各个部门的政务专网,节点服务器可以运行于政务专网或者委办局内网,组成一个网状拓扑结构的应用互联网络。通过配置数据交换节点的交换服务,每个节点只需要与数据交换平台通过标准的接口进行交互,并通过XML进行数据转换,即可获取到所需要的数据。

基于ESB的分布式信息资源交换平台比单一Hub-Spoke交换结构更开放,具有无限扩展的可能,真正体现了SOA中一切皆为服务的理念,服务在ESB中处于平等的地位。与点对点的服务集成相比,在基于ESB的服务集成方式中,若有N个服务互连,则可获得最小接口数目N的最优解决方案,能大量消除功能交叉的冗余代码,增加了代码的可重用性,降低系统的维护难度,增强系统的可扩展性和健壮性,保护政府投资,缩短开发周期,适应业务的快速变化,增强系统的敏捷性,真正做到了以业务为中心和面向服务。

5 结束语

本文中基于ESB的政务信息资源交换平台方案已经成功应用于某市的电子政务系统,通过消息传递的松耦合方式将财政、税务等多个部门的不同平台、不同架构和不同功能的业务系统有机连接,实现了各单位现有业务系统之间的信息交换和业务集成,消除了信息孤岛,提高了各部门数据的一致性,具有一定实用推广价值。

SOA和ESB成为了当前IT软件领域分布式企业级应用集成的主要技术趋势。基于标准的ESB能实现智能路由,能对传输中的数据进行必要的转换,具有技术开放、适应性好、成本低和效率高的优势,在电子政务和电子商务等企业级应用集成中有广阔的前景。

参考文献

[1]徐罡，黄涛，刘绍华，叶丹．分布式应用集成核心技术研究综述[J]．计算机学报，2005，28(4)：433-444．

[2]W3C.Extensible Markup Language(XML)1.0(Fourth Edition)[EB/ OL].2006,8.http://www.w3.org/TR/2006/REC-xml-20060816/.

[3]W3C.SOAP Version 1.2 Part 0:Primer(Second Edition)[EB/OL]. 2007,4.http://www.w3.org/TR/2007/REC-soap12-part0-20070427/.

[4]W3C.SOAP Version 1.2 Part 1:Messaging Framework(Second Edi- tion)[EB/OL].2007,4.http://www.w3.org/TR/2007/REC- soap12-part1-20070427/.

[5]W3C.SOAP Version 1.2 Part 2:Adjuncts(Second Edition)[EB/OL]. 2007,4.http://www.w3.org/TR/2007/REC-soap12-part2-20070427/.

[6]W3C.Web Services Description Language(WSDL)1.1[EB/OL]. 2001,3.http://www.w3.org/TR/wsdl.

[7]OASIS,UDDI Spec Technical Committee Specification.UDDI Version 3.0.1[EB/OL].2003,10.http://www.uddi.org/pubs/uddi-v3.0. 1-20031014.pdf.

[8]岳昆，王晓玲，周傲英．Web服务核心支撑技术：研究综述[J]．软件学报，2004，15(3)：428-442．

[9]麻志毅，陈泓婕．一种面向服务的体系结构参考模型[J]．计算机学报，2006，29(7)：1011-1019．

集成服务 篇11

一、打造“集成银行”的重要意义

（一）打造“集成银行”是增强商业银行综合竞争力的重要环节。目前，国内商业银行与现代商业银行高水准的综合竞争力要求相比，还具有很大的差距。同时，从目前影响各商业银行综合竞争力的诸因素看，还具有很大的提升空间。通过打造“集成银行”，可以改善商业银行内部的资源配置，放大资源配置的效能，从而更有效地增强商业银行的综合竞争力，更有力地促进商业银行跨越式的快速、优质、高效发展。

（二）打造“集成银行”是提高商业银行经营效益的重要手段。目前国有商业银行的资产收益率和人均利润水平，无论是与国内其他商业银行比，还是与外资商业银行比，都还存在着很大的差距。深究差距的成因，主要有如下两个原因：一是经营集约程度低；二是部门之间联系松散，联动程度低。通过打造“集成银行”，可以将国有商业银行的各种资源，从低效高险的领域向高效低效的领域转移，或在同一个领域将两个或两个以上的资源集合成为一个有机整体，放大效能，建立功能上“1+1>2”的机制，来推动业务经营质量和效率的提高，以更有效地提高国有商业银行发展的经济效益。

（三）打造“集成银行”是加速商业银行业务发展的重要渠道。当下，一方面商业银行受制于服务渠道的限制，无法满足客户的所有业务需求，另一方面受制于一线人手紧张、人员老化的影响，商业银行无法大力拓展网点以满足客户需求，这两个方面的因素限制了商业银行的业务发展。而打造“集成银行”却正好解决了这两点：一方面拓展、延伸了业务领域和服务链条，解决了客户需求，另一方面在不大幅增加人力成本的同时，集成了金融产品、渠道，拓宽了服务的范围，满足了客户的需求。可以说，打造“集成银行”从根本上解决了限制商业银行快速发展的桎梏，推动了商业银行的快速发展。

（四）打造“集成银行”是改变商业银行收入结构的重要途径。与外资银行相比，目前国内商业银行收入结构还比较单一，其最主要的收入还是来源于存贷款的利差收入，占比超过了70%，而2011年，全球7家代表性银行非利息收入占比平均为50.7%，远远高于国内的商业银行。打造“集成银行”意味着银行将围绕“为客户服务”进行各类资源的整合，逐步实现向“以服务换收入”的转变，提高服务性中间业务收入的占比，改变过去利差收入一枝独秀的局面。

二、打造“集成银行”的主要路径

（一）再造以客户为中心的银行业务流程。目前农行的业务系统人为地分成了前、后台，将一笔完整的业务割裂成了几段来办理，延长了客户办理业务的时间，往往会招致客户的不满，甚至会造成客户的流失，打造“集成银行”的宗旨就是围绕满足客户需求，建立从客户发现、客户需求到业务创新和反馈的一整套操作规范，形成从了解客户到满足客户的完整循环。变原有单一部门业务处理为综合性联动式操作，强化银行各级机构间的整体运作能力。营销、结算、产品开发、支持保障等部门间互为依托，共同参与对客户服务的方案设计、产品的营销及售后服务，提高整体服务效率。再造后的业务流程应直接面对客户，满足客户现有需求，挖掘客户潜在需求。在技术部门支持下，通过客户信息平台的建立反馈，让客户信息在各部门间流动、整合，为客户提供完善的服务方案。

（二）全面推行客户关系管理系统。规范、高效的客户服务是吸引客户、进而为客户提供服务的基础，但只有深入地把握客户需求，才能掌握客户需求的第一手资料，进而根据客户需求做出一整套符合客户实际利益、最能满足其服务要求的个性化解决方案，以全程式、互动型和差异化的服务，创造独属于本行的经营特色、产品特色和服务特色。这就必须建立信息化的客户关系管理系统，全面掌握客户信息，以庞大的客户信息数据库为平台提供客户终身价值的信息，通过对客户需求、习惯和目标的深入了解，全面掌握和分享客户信息，通过对客户信息的统计、分析来了解客户，及时与客户展开良好的互动，深入把握客户需求。

（三）不断进行技术创新、产品创新。西方先进银行的发展经验表明，成功的银行不仅仅是资金密集型企业，更加是技术密集型企业，如今伴随着网络经济的发展，带有明显网络特征的银行产品层出不穷，如网上银行、电话银行、在线支付、离线支付等等，首创式地开发出某一银行产品将意味着银行服务能力的重大提高、意味着为客户服务渠道的重大拓展，也意味着商业银行在竞争中将占得先机。创新对商业银行而言就是发展的持续动力，网络经济时代市场竞争的法则已经不再是“大鱼吃小鱼”，而是“快鱼吃慢鱼”，谁领先于竞争对手发展出新的产品，谁就能争得客户以获得更大的发展空间、利润空间。商业银行的创新说到底是要满足市场的需要，依托客户需求所进行的不断自主创新，以达到“抢得到客户、留得住客户”的目的。

集成服务 篇12

随着校园信息化应用的不断深入,学校内部各系统之间数据信息需要交互才可以很好的配置各部门的工作,但由于历史和现实的原因,目前很多信息系统是异构系统,基于不同的软件和硬件平台,数据格式也不统一,信息缺乏有效共享,应用缺乏有效集成。这种现象不但导致了重复建设、资金浪费严重,还给教学、科研和管理带来了极大的麻烦,“信息孤岛”、新旧信息资源的衔接、历史信息的有效利用、当前不同系统之间的通信、目前已开发的系统与今后将要开发的系统的连接等一系列问题都需要进行科学的分析,校园信息的整合集成已成为目前工作的重点。

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.