服务器集成（精选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
下一页12
简介
Cisco Fabric Manager是一种基于Web、易于使用的响应性应用，能够用集成式方法实现交换机和网络管理，从而简化存储局域网(SAN)中Cisco MDS 9000系列交换机的管理。Cisco Fabric Manager能够为存储管理员提供网络级管理功能，包括识别、多交换机配置、连续网络监控和故障排除。这种功能强大的方法能够大大缩短交换机的设置时间，提高整个网络的可靠性，并提供丰富的诊断信息，帮助解决网络问题和配置不一致性。
利用Cisco Fabric Manager的直观图形界面，存储管理员可以对交换机配置进行对比，对Cisco MDS 9000系列交换机进行配置策略检查，为通报第三方错误管理应用设置阈值，实时查看单台设备的统计数据和总体统计数据，以及分析历史性能统计数据等。所有这些功能都可以通过一个安全的界面执行，而且几乎能够从任何位置远程管理。
Cisco Fabric Manager的特点
・嵌入交换机的Java应用――将交换机与网络管理集成到随每台Cisco MDS 9000系列交换机供应的一个性能优化工具中。
・矩阵可视化――执行集中式自动识别，并显示存储网络拓扑、连接和区域/虚拟存储局域网(VSAN)重点标注，使相关人员能够快速了解网络状况和发现配置问题，
・多个视图，包括矩阵、设备和总结――简化多台交换机的配置和监控，支持配置复制。
・全面配置多台交换机――提供集成式网络、交换机和端口级配置，简化区域、VSAN、IP光纤通道(FCIP)、小型计算机系统接口(iSCSI)、IBM光纤连接(FICON)和智能服务配置。
・灵活监控和警报――以表格和图形格式显示实时和历史性能监控统计数据，基于阈值的警报的配置，包括呼叫到家，有利于相关人员对例外情况作出快速响应。
・历史性能监控――提供表格和图形报告，显示交换机间链路(ISL)上、主机和存储连接上以及某些光纤通道源站点和目标站点之间的每日、每周、每月和每年流量。提供网络级统计数据的前10名报告和每日汇总报告能大大简化网络热点分析。
・强大的配置分析功能――执行区域合并分析和配置检查，简化问题的解决过程，促进网络成功合并，并自动解决配置不一致性问题。
・网络诊断――用Fibre Channel Ping和Traceroute检测网络和交换机的操作状况，使管理员能够快速发现网络连接和性能问题。
・全面的安全性――利用简单网络管理协议第3版本(SNMP v3)、安全壳协议(SSH)和基于角色的接入控制(RBAC)防止非授权管理接入。
设备识别
Cisco Fabric Manager使用基于标准的协议，自动识别所有设备，并将一个或多个网络互相连接起来。所有可用的交换机、主机总线适配器(HBA)和存储设备都可以被识别到。识别信息包括设备名称、软件版本号、厂商、ISL、PortChannels和VSAN等。
拓扑映射
Cisco Fabric Manager能够按照设备识别信息显示拓扑图，从而提供多个网络的准确视图。用户只需在界面上拖动鼠标，就可以修改拓扑图的图标布置，还可以突出显示某些配置信息，例如超过使用阈值的区域、VSAN和ISL。
面向用户的公共信息服务集成研究 篇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
工程项目售后服务管理制度
售后服务工作的质量是工程质量的延伸。为了履行对客户的质量承诺，售后服务由公司专职人员进行管理，提供技术支持，确保接到通知后及时到达现场进行维修处理。真正做到及时的响应、规范的服务、精湛的技术、礼貌的行动向客户提供高质量的售后服务。
1、服务方式
包括：
1、现场维修；
2、日常电话服务；
3、网络在线服务。
在保证服务质量的情况下，尽量采用电话服务和网络在线服务方式处理，提高工作效率和降低售后服务费用。
2、服务电话：
售后服务电话对外统一公布为****-*******，投诉电话为****-*******。如果需要上门现场服务，技术人员需提醒客户拨打统一售后服务电话进行受理安排。
3、处理流程：
1）售后服务信息的收集：
A、售后服务电话接听；B、技术人员反馈；C、公司领导指示。
所有信息必须首先由公司专职人员进行收集整理，技术人员反馈售后服务信息，需由专职人员进行核实。
2）信息的整理分类：
所有信息必须由公司专职人员在《售后服务记录本》上登记时间、地点、人物、故障现象等详细信息，并根据服务的紧急程度、服务种类、是否过保和收费等等，并与客户进行沟通处理的方式。
3）服务指令的发布
首先向专职技术人员发布指令进行售后服务，或向部门经理反馈进行人员安排。
4）售后服务的执行
接到指令的售后技术员，按照公司对用户的服务承诺要求，按时间要求提供售后服务（通过售后服务的三种方式）。
5）售后服务工作的完结
服务完成后，要填写《售后服务信息反馈单》，写明故障现象，检查记录，处理结果，请用户对服务工作的满意度进行评价，签字盖章。填写不完整的不计入考核范围。
6）《售后服务信息反馈单》交公司专职人员，部门经理将对用户进行电话回访，并统计服务和电话反馈结果。
7）公司专职人员在月底统计月度售后服务完成情况，形成统计表格，经部门经理审核后上报公司领导审批后，作为售后服务月度绩效考核的依据。
4、绩效管理：
售后服务人员工资设底薪、服务补贴、奖金三个部分。
1）底薪部分按照公司制度进行统一的考核（包括考勤、转正情况、工龄等等），在月初进行发放。
2）服务补贴部分根据每月的售后服务统计表的统计情况进行发放，发放的标准为：售后服务每次**元。没有售后服务信息反馈单和反馈单不完整的不计算次数。
3）售后服务奖金：当月无投诉，每月奖励***元，如有投诉，每次处罚**元，月累计*次及以上，扣除当月奖金。试用期员工不参与此奖金的发放。
注：现场售后服务一般情况下只报销公共交通费用，如遇紧急情况或携带大宗物品，需上报部门经理后，才能报销的士或货运费用，未申报不予报销。
非专职售后服务人员提供现场上门服务，每次人工费用**元，交通费用参照专职售后人员标准执行。
5、产品维修
1）在售后服务过程中产生的产品返产维修问题，首先与公司商务联系，首先确定是否在保修期内；其次确认厂商是否提供上门服务；在保修期范围内尽可能通知厂商上门服务。
2）超出保修期范围和没有上门服务的产品，经与公司联系后，与客户确认维修费用（含运费）后，送回公司交商务部进行维修。并负责收回费用。
6、增值服务
1）配件销售
A、售后人员在提供售后服务同时，客户需要购买其他的电脑软硬件，或在维修设备、仪器时需要更换零配件（保修期外设备），技术员可帮用户直接与公司联系购买。该笔业务可算本人的销售。核发纯利的30%作为奖金。所代购的零配件的货款，由当事人负责收回。
B、配件销售原则上是款到发货，如遇特殊情况，***元以下需经部门经理同意，***元以上须报公司领导同意后方可实施，货款由经手人负责收回。
C、应由经手人负责收回货款的，在一年内还未收回，由经手人负担货总货款的80－100％，在当月工资中扣除。
2）软件服务
A、超过保修期范围的软件服务，或者在设备维护之外的软件咨询服务，包括系统安装等，在报公司同意后，可向客户提出收取一定的软件服务费用，并在收回款项的前提下按照40%的比例提取奖金，公司可开具发票。
B、没有上报公司私自收取顾客的软件服务费用并引起顾客投诉，除按收取金额从工资中扣除外，另行处罚**元/次。
本制度从*****起试行。
****系统工程公司
服务器集成 篇6
摘要：基于对提供产品服务系统的制造过程和服务过程的不同阶段及特点的刻画，建立了产品制造与服务过程集成的框架模型，提出了基于售后集成、销售集成、生产集成和设计集成的产品服务供应链4种典型模式，分析了各模式中供应链成员的职能及其交互关系，指出了每种模式的价值实现方式及实施关键点，并应用案例对每种模式进行了说明。
关键词：产品服务供应链；供应链模式；过程集成；产品服务系统
中图分类号：F2707文献标志码：A文章编号：
10085831（2016）01009908
服务经济大发展趋势下，制造业服务化正成为制造业的重要发展方向之一[1]。产品服务系统（简称PSS）作为一种客户需求驱动的“产品+服务”的整体解决方案，相比单纯的产品或服务而言，能够显著提高企业市场竞争力和顾客满意度[2-3]。由于PSS具有复合性、实时性、定制性、全寿命周期性、增值性和客户参与性等特征，因此提供有效的PSS比单纯提供产品或服务要复杂和困难得多。它需要产品制造过程和服务提供过程的有效集成以及顾客的参与，从而实现产品服务供应链（简称PSSC）的顺利运行。然而现有的产品供应链或服务供应链模型因缺乏对产品与服务交互关系的刻画而不能完全适用于产品服务供应链，使企业在实施过程中困难重重。因此急需有效的产品服务供应链模式来指导企业实现有效的PSSC运作管理。
有关产品服务供应链模式的研究，主要基于产品供应链和服务供应链的模式（或模型）研究发展而来。产品供应链模式的研究已比较成熟，如H-P模型、SCOR模型和GSCF模型等已得到广泛接受和认可。然而由于服务与产品的不同特征[4]，产品供应链模式不能直接用于对服务供应链的刻画。一些学者在此基础上结合服务的特征研究了服务供应链模式，例如，Ellram等提出了具有明显服务特征的Ellram模型[5]；Baltacioglu等提出了强调过程管理、服务能力及资源管理的IUE-SSC模型[6]；Stavrulaki和Davis强调不同交付过程和交付方式的服务类型，定义不同的服务供应链并给出相应实施策略[7]。这些服务供应链模式在一定程度上可为产品服务供应链模式的研究提供借鉴，但由于已有的服务供应链模式缺乏对产品与服务交互关系的刻画，因此不能适用于产品服务供应链的运作。关于产品服务供应链模式，2008年Johnson和Mena提出“面向服务化产品的供应链管理”的概念，并通过案例分析给出该供应链的初步结构模型，但并未系统地刻画PSSC的体系结构、业务流程以及成员间的协同关系[8]。Meier等提出了由产品零部件制造商、服务提供商、工业产品服务系统模块提供商、工业产品服务系统集成商和顾客组成的IPSS供应链成员网络组织架构，并对IPSS供应链中各成员角色和职能进行重新定义，但其研究仅限于工业产品服务系统领域[9]。Maull等针对SCOR模型不能有效刻画PSSC的问题，分析了服务的特点以及产品与服务的交互关系，提出了以服务提供商为核心企业的产品服务供应链过程模型[10]。Xu等提出由产品制造商、服务提供商和顾客组成的通用PSSC结构框架模型，总结PSSC具有价值共创、自发性、不确定性和动态性的特征，据此提出针对供应链各流程的管理建议[11]。王康周等以服务型制造混合供应链中的售后服务情形为研究对象，指出其与传统供应链的差别，并强调生产与服务能力协同管理的重要性[12]。李刚等提出服务型制造的体系架构、商业模式及生产组织方式[13]。李浩等分别将面向制造业的生产性服务模式和面向制造业的产品服务发展模式作进一步细分，并用系统结构和案例说明每种模式的特征[14]。然而，产品制造与服务过程的集成方式具有差异性，差异化集成下的产品服务供应链中产品制造商与服务提供商的合作关系也存在多样性，不同的合作关系使得产品服务供应链的参与成员和组织方式也各不相同，已有的PSSC结构模型并不能完全适应各种不同产品服务系统的集成特征，也没有分析不同PSSC模式间的相互关系。
鉴于此，本文以产品制造与服务过程集成的不同方式为基础，提出4种产品服务供应链模式，分析各个模式的技术特点及其适用对象，指出企业在实施各种产品服务供应链时的价值实现方式及实施关键点，并结合案例进行说明。
一、产品制造与服务过程集成的框架模型
产品服务供应链中产品制造商和服务提供商并非整个供应链流程都从始至终紧密集成，而是从满足顾客需求和最大限度提升原有产品或服务价值的角度出发选择最优集成点开始集成。根据产品制造过程和服务过程的不同，构建如图1所示的产品制造与服务过程集成的框架模型。下面将在描述产品制造过程和服务过程的基础上，刻画产品制造与服务的过程集成点。
（一）产品制造过程
为使产品制造与服务过程能够有效集成，在产品价值链和产品全生命周期的划分基础上，将产品制造过程分为以下4个阶段：（1）产品设计：通过市场调研、需求分析等及时获取顾客的最新需求，以顾客的需求为依据形成产品的设计方案。（2）产品生产：包括生产过程中的生产资源准备和产品的制造过程。首先根据产品设计方案进行生产资源准备，然后开展产品的制造过程。（3）产品销售：产品生产结束后，产品制造商构建分销渠道，选择销售方式直至将产品的所有权转移给顾客。产品销售可能涉及销售方式选择、销售咨询交流、收款方式选择等具体环节。（4）产品售后：产品销售完成后的环节统称产品售后环节，包括产品递送至顾客的物流环节、产品运行维护环节以及产品最终的报废回收环节。
（二）服务过程
服务的无形性、不可分离性、差异性和不可储存性使服务与实体产品存在巨大差异。因此，服务过程难以用业务先后顺序来描述，而应通过价值增加的过程来刻画。在产品服务系统中，以服务增值为依据，可将服务划分为多个过程，使产品制造与服务过程的差异化集成方式更为明晰。
服务器集成 篇7
随着数字化医疗建设的发展,各种医疗信息系统,如医院信息系统(hospital information system,HIS)、实验信息管理系统(laboratory information management system,LIS)、放射信息系统(radiology information system,RIS)等广泛应用到医疗机构。但是,这些医疗信息系统的结构不同且各系统内的数据格式不兼容。另外,各信息系统具有分布广泛、业务数据复杂且分散等特点,严重影响了系统交互过程中医疗数据的传输与共享。目前,医疗机构迫切需要一种架构统一、符合特定开发技术规范的应用运行和接口方法,以实现各医疗系统中分散医疗信息的共享和系统间的高效互访。
本文提出依据面向服务的体系架构(service oriented architecture,SOA)的体系结构,基于Biztalk Server 2009技术平台,以面向服务的方式,构建异构信息系统数据集成平台,并以医嘱查询事务交互为例,阐述以数据集成平台为核心的医疗信息系统数据交互的实现。
SOA[1,2]是面向服务的体系架构,它是一种按需连接资源的系统,将应用程序的不同功能单元通过服务间定义良好的接口和契约联系起来[3]。接口是采用中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言[4],使得系统间具有松散耦合的特征。SOA以服务为核心,将各种资源整合成基于标准的服务,使其能够重新组合和应用。
Biztal K Server 2009[5,6]是微软的业务流程管理和企业应用集成平台,旨在促进企业内部及企业之间的电子商务流程的协作,以松耦合的方式,快速实现企业应用集成(EAI),是遵循SOA架构而设计的开发工具[7,8]。平台内部处理的消息以XML格式描述,采用发布-订阅的消息传递机制。它的基本架构主要由消息、适配器、管道、消息库、业务流程、跟踪库、配置库等组成。基本工作原理是Biztalk Server通过在给定接收端口中定义的接收位置接收消息,消息由接收位置处理,然后被发布到Message Box数据库,Message Box评估活动的订阅,并将消息路由到具有匹配订阅的业务流程和发送端口。因此,借助于Biztalk Server,可以按模块化的方式添加或修改服务,便于实现异构医疗信息系统的集成。
2 系统数据集成框架
2.1 数据集成平台的功能要求
系统数据集成的主要目标是实现异构数据源的集成[9],即对分散在各个系统的数据进行提取、转换和传输等操作以实现异构数据源内各种数据的共享和交互[10],并提供多种类型的数据访问接口,解决不同数据源所带来的通讯方式多样化的问题。本文以Biztalk Server作为数据集成平台,采用XML数据标准,以WCF服务作为各系统访问平台的接口。而WCF是使用托管代码建立和运行面向服务应用程序的统一框架,有助于建立一个跨平台的安全、可信赖、事务性的解决方案,且能与已有系统兼容协作。系统平台的体系框架如图1所示。
以HIS和LIS之间医嘱信息交互为例,说明集成平台数据交换过程。之前,HIS与LIS之间医嘱信息的交互是通过彼此开放数据访问的接口来实现的,而且各自需要负责将数据转换成符合自身的数据格式。建立数据集成平台后,LIS通过URL直接调用WCF服务,提交查询申请,平台利用SQL适配器从HIS提取原始数据,进行格式数据转换、合并等操作后,将生成的XML数据路由到LIS。LIS接收到数据后,存入医嘱信息数据库表。如果LIS在执行医嘱时,发现医嘱信息不合格,同样只需调用WCF服务,向平台提交校验信息,由平台负责将数据传输到HIS。
2.2 业务功能组件的设计
软件的体系框架主要由3层组成:服务层、集成与业务处理层、数据层。服务层是寄存在互联网信息服务器(internet information server,IIS)上的WCF服务,向应用程序提供接入集成平台的接口;外部应用程序通过引用服务的URL调用WCF服务来实现数据访问。集成与业务处理层是整个体系结构的核心,采用Biztalk Server 2009作为集成服务器。利用WCF适配器负责提供统一的WCF访问接口;Biztalk Server业务流程实现各种业务逻辑,为具体的应用提供异常处理、日志、通知等服务功能;利用多种Biztalk Server适配器,如WCF适配器,实现对来自不同应用系统的数据进行灵活的集成。数据层主要是存储各种应用系统的数据源,如HIS数据库、人事数据库等。
3 应用系统接入数据集成平台的流程
为了开发的方便,制定应用程序接入集成平台的业务流程,如图2所示。其接入步骤为:(1)应用系统A的开发人员向Biztalk开发人员提出数据交互的业务需求,并提供交互的XML数据架构,编写接收数据的WCF服务接口。(2)Biztalk开发人员根据应用系统A提交XML数据架构和应用系统B提供的数据访问接口规范,制定接口规范,并将规范发布给应用系统A的开发人员。(3)Biztalk开发人员根据业务需求,在Biztalk数据交换平台上构建消息映射,编写Biztalk业务流程,将业务流程发布成寄存在IIS上的WCF服务接口,编写调用应用程序A的WCF接口的发送接口。(4)应用系统开发人员编写引用Biztalk发布的WCF服务的接口,调用服务,实现数据交互。在接收/发送端口,以XML消息架构作为端口方法参数。
4 数据集成实现
以HIS与LIS之间医嘱查询的数据交换为例,阐述业务流程的设计过程。医嘱查询是典型的跨系统的业务处理过程,采用请求-响应的方式,实现数据的提取和转换以及系统间消息的路由。医嘱查询的业务处理流程图如图3所示。
(1)医嘱执行系统调用WCF服务接口,向集成平台提交医嘱查询请求。
(2)数据集成中心的WCF服务接收端口收到数据后,经过消息转换,构建初始消息,将数据发送到Biztalk数据库(Biztalk Msg Box Db)。
(3)相应的Biztalk业务流程订阅该消息,根据不同的消息类型按照不同的方式工作。其具体工作方式有2种:(1)数据查询流程。业务流程通过数据库访问接口查询异地数据库,获得医嘱信息,并将结果通过格式转换后,返回到医嘱执行系统。(2)数据路由流程。业务流程接受的是医嘱执行系统提交的不合格医嘱消息的校验信息,经过消息格式转换,将其发送到数据发送端口,再以一对一或一对多的方式将其路由到医嘱申请系统。结束业务流程并记录日志。
4.1 LIS需要实现的功能
医嘱执行系统提供数据结构定义(见表1),编写接收发送数据的WCF服务接口,包含2个方法:(1)Public GetOrderResult GetOrder(string PatientID)。(2)Public SendResult SendNotify(string ItemID)。功能流程如图4所示。
LIS的医嘱执行模块通过调用方法Get Order向数据中心提交医嘱申请,获得医嘱信息。如果医嘱不合格,则调用方法Send Notify向数据集成平台提交医嘱信息不合格的校验信息,由集成平台负责路由到医嘱申请系统。
4.2 HIS需要实现的功能
医嘱申请方提供数据结构定义(形式见表1),编写接收/发送的WCF服务接口,包含4个方法:(1)Public OrdersRe-sults SendDutyTable(string ApplyID)。(2)Public void RegisterSubscriberStatus(string OnlineStatus)。(3)Public void ReceiveNotify(Message notifySets)。(4)Public NotifyResults GetNotify(string BookingID)。功能流程如图5所示。
HIS的医嘱申请模块通过方法Send Duty Table获取医嘱执行结果;由Register Subscriber Status方法,向数据交换中心注册不合格医嘱校验信息的订阅者端口接收状态,以此表示方法Receive Notify是否可以与数据中心通讯,集成平台依据接收端口状态决定将反馈信息直接路由到订阅者,还是存储到数据库表。医嘱申请系统能通过方法Get Notify向数据库查询,并将失败的信息反馈到该订阅者。
4.3 数据集成中心的实现
4.3.1 集成平台配置文件的设计
根据设计规则,Biztlak数据集成平台包括的配置文件有:接受/发送端口的配置文件(例如医嘱请求的文档架构LISRequest Order.xsd,如图6所示);数据映射与代码对照配置文件(例如HIS2LIS.Sex.txt,如图7所示);消息订阅者信息配置文件(例如Get Subscriber Config.xsd)。
接受/发送端口的配置文件是接口文档架构,根据接入数据平台的应用程序提交的数据结构制定,规定了数据平台的WCF端口能接受的消息类型,如图4所示。数据映射配置文件使源文件中的字段与目标文件的字段建立联系,实现数据的提取、合并和转换等操作。代码对照配置文件是描述不同系统对代码的转换关系,如性别可以用数字1和字母M表示男性,如图7所示。消息订阅者信息配置文件用于获取动态发送端口的通讯协议配置信息(如WCF协议中的Action、Address等参数信息)。
4.3.2 消息映射的设计
Mapper设计主要负责数据的提取、合并和转换问题。在Biztalk Server中,Map映射工具是一个图形编辑器,显示2个架构,即“源”架构和“目的”架构,在映射过程中提供对XML字段的操作功能,建立有用的映射,即目标系统需要的字段[11]。如图8所示,在Root源架构,Input Message Part_0包含了医嘱查询条件Patient_ID和在Operation Result中反映的查询操作结果的状态信息,而在Input Message Part_1的HISOrder节点包含属于医嘱申请系统数据库表结构的医嘱信息字段。通过映射,这些信息将被映射到LISRequest Order架构。针对描述内容相同,但不同系统引用的代码标准不一致的问题,根据不同的引用标准制定格式统一的代码对照配置文件,如图5所示,再在.NET平台下读取编写标准代码映射脚本[12]。在运行时,通过脚本读取本地映射的文本文档,从中检索标准代码的转换关系。
4.3.3 业务流程的设计
为了在服务总线上扮演重要角色,Biztalk Server的Or-chestration中不仅可以使用外部服务,而且能将自身以Web或WCF服务的方式,供其他应用调用。本文中,业务流程当作WCF服务使用。依据图3所示的流程,编排Biztalk的业务流程。
如图9所示,当医嘱执行系统提交一个医嘱查询的请求到对应业务流程的Rec Port_LIS Re…请求-响应端口,其XML消息类型LIS Request Order架构,适配器类型为WCF-WSHttp,如果消息格式符合此架构,数据被提交给Receive LIS Request Order,经过消息初始化,进入Sope Get HIS Order作用域,进入医嘱查询执行阶段,通过选用SQL适配器的请求-响应SQLSendReceiv…端口查询HIS数据库中的医嘱信息,根据判断查询结果是否存在,进行不同的业务处理,最后通过消息映射构建响应消息,最终由RecPort_LISRe…请求-响应端口返回响应消息,最后写入服务调用的日志文件。
如图10所示的流程中,当医嘱执行系统提交一个医嘱不合格的校验消息到Rec Port_LISNo…接受端口,其适配器类型为WCF-WS-Http,如果消息格式正确,消息数据会被提交给Receive LISNo…,经过一个Transform消息格式转换,构建目标消息,目标消息被存入自定义缓存数据库后,由选用SQL适配器的Sql Get Subscri…端口查询该消息的所有订阅者的WCF接口通讯配置信息,再采用使用WCF-WSHttp适配器的Dynamic Port动态发送端口,在业务流程执行的过程中动态配置发送端口的WCF配置信息,如Address,以一对多或一对一的方式,将不合格的医嘱信息动态路由到目的系统,例如将消息发送到医嘱申请的Receive Notify方法,从而在不修改业务流程的情况下,灵活地添加消息的该订阅者,最后写入流程运行的日志文件。
5 结语
本文针对医疗信息系统间存在异构和数据不兼容问题,提出依据SOA体系结构,建立基于Biztalk服务器的数据集成平台,实现异构系统的数据共享与交互。数据集成平台向各医疗信息系统提供基于WCF服务的应用程序接口使其通过调用服务实现系统间的数据访问。利用Biztalk的映射功能,解决异构数据不兼容问题。利用不同类型的数据适配器来满足异构系统间数据通信多样化要求。利用Biz Talk业务流程来实现异构系统数据交互的具体细节。该方法能够在不对现有系统作重大修改的基础上,解决异构医疗信息系统数据分布性和不兼容性问题。本文设计的系统已经在广州欧唯斯计算机系统集成服务有限公司开发的HIS上调试通过。
摘要：目的:解决异构医疗信息系统间的非标准数据的交互问题,实现医疗信息系统数据集成。方法:提出一种依据面向服务的体系架构的体系结构,建立基于Biztalk服务器的数据集成平台,数据集成平台依据.Net框架设计,采用WCF服务作为平台与异构医疗信息系统之间的接口标准,利用XML语言描述交互数据的结构。结果:该系统已经在广州欧唯斯计算机系统集成服务有限公司开发的HIS上调试通过。结论:该集成平台能够在不对现有医院信息系统作重大修改的基础上,解决异构医疗信息系统数据分布性和不兼容性问题,对解决异构医疗信息系统间的非标准数据的交互问题,实现医疗信息系统数据集成具有广阔的应用前景。
关键词：SOA,Biztalk Server,WCF服务,数据集成
参考文献
[1]刘靖.基于SOA的政务应用系统集成研究[J].电脑与电信,2010(8):58-59.
[2]王紫瑶.SOA核心技术及应用[M].电子工业出版社,2008.
[3]张妍,王淑蓉.基于BizTalk的SOA安全研究[J].科技信息,2009(25):449.
[4]胡凤华,袁继军.高校数字档案馆信息资源整合交换的策略及应用[J].档案学研究,2011(1):43-46.
[5]赵英,罗日东.基于BizTalk的物流信息管理系统设计与实现研究[J].西南民族大学学报:人文社会科学版,2010(5):149-153.
[6]George Dunphy,Sergei Moukhnitski.Pro BizTalk2009[M].New York Springer-Verlag Inc.,2009.
[7]Richard Seroter.SOA Patterns With BizTalk Server2009[M].Olto Birmingham:Packt Publishing Ltd.,2009.
[8]冯靓,李立持,主振强.基于SOA思想的电子口岸信息平台系统[J].计算机应用与软件,2007,24(9):117-119.
[9]杨正合.基SOA的数据集成研究[J].电脑知识和技术,2009,5(5)1044-1046.
[10]王振宇,罗晓菁.基于MS BizTalk服务器实现数据集成[J].计算机工程与设计,2007,28(10):2435-2438.
[11]戴文娟,王晓峰.基于XML和BizTalk数据集成平台的设计与构建[J].计算机技术与发展,2008,18(10):162-165.
数字油田数据集成及服务体系研究 篇8
随着近十年来“数字油田”被国内大部分油田相继确定为信息化建设目标, 到目前将“云计算”和“物联网”等先进信息化技术应用到油气生产流程中, 已经成为国内“数字油田”建设的主要方向。但是, 无论是建设油田生产、科研、管理和决策的综合基础信息平台的“数字油田”, 还是建设高智能感知油田动态信息、自动操控油田活动、预测油田各方面变化趋势的“智能油田”, 它们的核心都是一样的, 就是必须实现各类专业数据的集中统一管理[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.
服务器集成 篇9
一、软件介绍
(1) n Lite:免费软件, 软件可以为你所定制的Windows安装文件集成Service Pack和Windows安全更新程序, 还可以集成常用的应用软件 (包括DirectX、.Net Framework、软件整合包、桌面主题和驱动程序等) , 并且可以移除Windows安装组件里面你认为不需要使用的组件以减少Windows安装文件的容量, 而且还可以优化调整注册表、更改系统服务设置、进行Windows无人参与安装以及创建可引导的ISO光盘镜像等。软件下载地址:http://www.nliteos.com/download.html。
(2) SATA及磁盘阵列卡驱动:可以在服务器厂商的官方网站技术支持页面下载, 下载后一般是一个压缩文件。
(3) Microsoft.NET Framework Version 2.0:是支持生成和运行下一代应用程序和XML Web services的内部Windows组件。运行过程中如果提示没有安装, 要下载安装。下载地址:http://www.microsoft.com/downloads/details.aspx芽FamilyID=0856eacb-4362-4b0d-8eddaab15c5e04f5&DisplayLang=zh-cn。
(4) Windows 2000及Windows 2003系统安装盘 (是正常安装的那种, 不是Ghost版) 。
二、制作方法
笔者以戴尔Power Edge 840服务器为例进行制作, 如有出入, 请大家参考自己服务器的具体型号下载相应的驱动程序制作。
(1) 在“我的电脑”D盘或E盘 (有足够的使用空间即可) , 建立一个文件夹, 如D:Win2000, 把Win2000系统安装盘中的所有文件复制到这里 (这样做的好处是文件处理快速, 如果不想这样做, 也可以把Win2000系统安装光盘放到光驱中, 然后再做, 建立一个文件夹, 如D:Win2000ser, 存放制作好的安装系统) , 再建立一个Driver文件夹, 把解压好的SATA及磁盘阵列卡的驱动复制到这里。
(2) 安装nLite软件。第一次运行时它默认的语言是英语, 可以在选择框中选择语言, 这里选简体中文。然后点击“OK”, 进入到欢迎安装界面, 点击“下一步”, 进入到安装许可界面, 点击“我同意”, 点击“下一步”, 下面的一般都保持默认, 点击“下一步”即可, 直到安装完成界面, 点击“完成”。
(3) 运行软件nLite。第一次使用软件默认的是英语, 在“Language”选择框中选择“Simplified Chinese”, 选中后软件界面会即时切换到中文界面, 点击“前进”进入下一步。在接下来界面中, 需要选择安装文件的所在路径。此时选择在“我的电脑”中建立文件夹的地方, 点击“浏览”, 选择“我的电脑”, D:Win2000 (或者向光驱中插入系统安装光盘, 然后点击“浏览”找到光盘所在光驱盘符。确定后会弹出一个对话框, 告诉需要指定一个存放安装文件的位置, 确定后指定一个硬盘的文件夹即可, 如D:Win2000ser, nLite会自动复制整个光盘的内容到这个文件夹下。需要注意的是, 最终制作光盘时会把这个文件夹下所有的内容都包含进去, 因此, 这个文件夹最好是一个空文件夹。复制文件完成后, nLite会自动扫描复制后的文件) 。然后得到安装文件的准确版本、语言以及大小等。
(4) 确定这些信息无误后, 点击前进。进入下一步, 到选择“预设”界面, 此步骤是加载上次使用后自动保存的配置文件, 因为是第一次使用, 没有配置文件可以加载, 所以, 直接点击“前进”。
(5) 进入到“任务选择”界面, 这个界面中提供了八个选项供选择。由于只是整合驱动, 因此, 只需选中“驱动程序”以及最后一项“可引导ISO镜像”即可。该项的意思是在驱动整合结束后直接由程序制作完整ISO文件, 点击“前进”进入下一步。
(6) 进入“驱动程序”界面。点击“插入”, 在这里有两个选项, 一个是“单个驱动程序”和“多个驱动程序所在的文件夹”, 可以一个一个驱动程序的添加, 也可以选择整个驱动程序所在的文件夹。在选择框中选定你需要整合的驱动程序的INF文件即可。这里选择“D:Driver”中的INF文件, 确定后驱动信息会显示在列表栏里。
(7) 点击“前进”会弹出一个对话框, 询问是否要开始进行处理, 如果确定上面的操作都没有问题后, 直接点击“是”开始处理, 否则点击“否”, 返回上一步进行修改。
(8) 经过一段时间运行后, nLite完成了驱动程序的整合, 这里显示了完成后的安装文件大小以及驱动文件大小。点击“前进”进入下一步。
(9) 进入到“可引导ISO镜像”界面。模式中选择“创建镜像”, 也可以选择“直接烧录”或“烧录镜像”选项。“ISO卷标”中显示了最终制作成的ISO文件的卷标, 也就是在光驱中插入光盘时, “我的电脑”中显示的光驱所在盘符的名称, 可以更改卷标为个人喜欢的名字, 但不宜过长。
(10) 确定无误后, 点击“创建ISO”, 指定ISO文件存放的位置, 等待几分钟后, “集成驱动程序的系统安装盘”就做好了。点击“前进”进入到“定制完毕”界面, 点击“完成”退出程序。至此, 全部的工作完成, 然后就可以用刻录软件刻录成光盘, 用制作好的“集成驱动程序系统安装光盘”来安装系统了。
服务器集成 篇10
传统信息运作方式虽然大大推进了企业生产力, 但又反作用于信息技术, 促使企业内外部商务信息的大规模集成。从面向过程到面向服务的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.
服务器集成 篇11
摘要：当前的时代是信息的时代，它是由通信支撑起来的，为了满足其不断的发展，信息交流就要求更加便捷，这样就会加大通信工程企业的工作量和业务量，显而易见，全都采用人工来完成是不可能实现的。因此，出现一种更快更方便的管理项目的方式是十分有必要的，通信工程项目管理系统就应运而生了。本文将详细阐述对于通信工程项目信息管理系统的研究。
关键词：通信工程；项目；信息管理系统；研究
通信建设市场不仅是信息化社会的主战场，也是信息化建设项目管理的主战场。当前，通常采取人工管理来对通信建设项目进行管理，由于管理的项目众多，如项目的立项，计划的管理，合同的签订以及工程的管理等等，人工管理就会产生管理不透明、信息不能共享等弊端。因此，急需建立一套切实可用的通信工程项目管理系统。
一、通信工程项目管理系统集成服务的重要性
现代社会是一个信息爆炸的社会。因此；在各个行业发展过程中有效选择信息、筛选信息，获得有用信息、让信息帮助行业决策就显得极其重要。通信工程项目管理系统集成服务就是基于这一社会现状而被提出来的。通信工程项目管理集成服务即通过集成化的方式。用一个核心组件服务器将原有应用集成在一起。从而综合获取其他应用系统的信息与数据。由此可见，构建通信工程项目管理系统集成服务迫在眉睫。它的建构不仅有利于提高获取信息的效率，也对改善企业决策 的准确度等方面有极大的作用。
二、通信工程项目信息管理系统的结构分析
通信工程项目信息管理系统由内外两部分结构组成，通信工程项目信息管理系统的结构一定程度上决定了管理系统的作用与效率，而这一点也是其与企业信息管理系统最明显的区别。通信工程项目信息管理系统建构十分复杂，涉及到多个方面，常见的有前期的规划设计、实际勘察设计、设备的制造与定时供应等，涉及方面的繁多对信息管理系统的功能与结构也是不小的挑战。我们重点分析其内部结构，主要包括项目的造价管理、项目的进度管理、项目的合同管理、项目的物质管理、项目的档案管理、项目的决策管理、项目的办公管理等，不同的工作阶段，每个管理系统的作用不同，或强或弱。
三、通信工程项目信息管理系统的流程分析
（一）流程设计中需求管理模块的流程分析。需求管理模块的设计要求虽然要满足各个部门的需求，但是设计要求上相对简单，配合提出一般的需求岗位即可，一般需求提出岗位一般包括需求管理岗位、投资预期设计岗位、计划主任岗位、需求审批岗位。设计中由需求管理岗位记录各部门的需求，在记录需求管理时要做到全面与仔细，做到各个需求部门需求的不遗漏。在完成需求管理的记录后进入下一个环节的审批，审批工作由指定的需求负责人完成，需求负责人的身份一般是各部门的主要领导，在完成需求审核之后进行需求的上报与汇总。
（二）流程设计中立项管理模块的流程分析。立项管理模块主要服务于项目投资，包括项目投资管理岗位与项目主任使用受理、项目审核、项目确定，流程相对比较简单。
（三）流程设计中资源调配管理模块的流程分析。资调配管理模块主要服务于资源调配室。涉及的内容有资源调配管理岗位、调配室主任的资源调配与项目设计审核。
（四）流程设计中工程管理模块的流程分析。工程管模块主要为工程建设室服务，是工程建设岗位与工程审批位從初期的工程项目受理到工程信息任务派送所涉及的一类活动。具体流程为：首先由工程的管理人员进行项目的受理，在受理之前要重点查看项目的采购状态，以此为依据定项目施工任务书，在完成立项与审核之后具体下发到施工部门，施工部门开始进行项目的施工与软件的研发，工程理流程中主要负责项目的受理与停工事宜。
（五）流程设计中的设计管理模块的设计分析。顾名思义，设计管理模块主要负责项目的管理工作，具体体现为计所所长和设计员之间的表单与数据事宜的处理与沟通，内容比较简单，全责比较明确。
（六）流程设计重视审计管理模块的流程分析。设计理是流程设计中的末端环节，供设计管理与审计审批使用主要包括项目工程的初审、复审，并负责起草具体的审计告，编写最终的审计决定。
四、通信工程项目管理系统集成服务的建构需要借助地理信息技术
实现通信项目管理集成化需要采用地理信息技术，因为在通信项目管理系统集成服务过程 中需要对信息进行自动采集、动态监测，从而达到信息资源的可视化的目的。而这一目的的达到就应有准确的坐标、时间、空间等立体维度信息的获取，这样才能更好的帮助企业决策，对相关信息进行有效管理、规划应用等。那么，达到这一效果的首要措施就是要构建空间信息的空间基础数据框架，从而使获得的信息更好地加工成数字地图产品。同时，要对数据进行有效管理，制定数据共享政策。真正确保所获信息的有效利用，提高各个方面的工作效率。
五、通信工程项目管理系统集成服务的建构需要核心网络平台的建设
核心网络平台的建设是指在网络环境支持下，通过数据库服务器、浏览器等环节来实现地理信息系统在页面上的运行。简单来说就是构建通信工程项目管理系统信息的网站，从而有利 于地理信息的快速搜索，以及信息的交互查询与表达；这样就有利于更快捷、更方便地获取信息，同时也能在对通信工程项目管理系统集成服务的过程中，及时通过信息的比较来获取新的信息与挖掘潜在信息。建设核心网络平台的最终目的即解借助地理信息系统与数据库技术来解决设备管理、项目管理以及专业应用领域中出现的一些突发问题，保证信息的有效传输，使通信工程项目管理系统集成服务真正达到服务企业，为企业带来更多的经济效益。
六、构建通信工程项目管理系统集成服务需要建设空间数据
基础设施要使通信工程项目管理真正实现集成服务，那就有必要对通信工程项目管理的空间信息进行数字化处理，这一目标的实现需要各个相关部门共同协作，综合多种方式与技术，使海量信息得到海量存储及采用元数据提取方式，让获得信息的终端更加高效化。而这一切 的实现少不了空 间数据基础设施的建设，它们在信息的获取、选择、管理等方面发挥着极其重要的作用；同时，这也是符合构建核心网络平台要求的一个主要举措。另外，建设空间数据基础设施也有助于信息的增值管理，使有关部门能轻松地从众多信息之中获得有用信息，并挖掘信息深处所潜藏的资源。
七、实现通信工程项目管理系统集成服务需要综合运用各种技术
通信工程项目管理系统集成服务的最终实现除了要有效运用地理信息技术、核心网络平台构 建与空间数据基础设施建设之外；还要综合运用其他多种技术。诸如海量存储技术、空间数据库技术、动态规划技术、空间分析模型等等；只有综合多方面 的技术才能最终使来自各渠道的信息得到系统式处理。这样才能从真正意义上使通信工程项 管理系统实现随时查询、调取与利用，使任何复杂的、海量的信息在此真正实现集成。综合运用各种技术的最终目的是使分布式的信息得到升华，使每一个有效信息转化成让人容易掌握、理解的资料。
结束语
想要提高通信工程项目信息的管理水平，最直接有效的途径就是采用信息管理系统。本文通过对通信工程项目信息管理系统技术进行细致的分析与研究，希望能为通信工程信息管理系统的完善和发展起到一定的辅助作用，使其能够提供更加准确、更加安全、更加可靠的管理信息，更好的为我们的生活、工作提供服务。
参考文献：
[1]刘启，张靠社.基于 B/S的电力通信工程项目管理信息系统研发.信息与电脑（理论版），2010
[2]王建华.工程项目综合管理信息系统的应用及要求.中国建设信息，2012
基于ESB的Web服务集成技术 篇12
近年来,软件系统的开发方法正由面向功能的开发方法转向面向服务的、面向流程的开发方法,由基于模块的构造方法转向基于组件的构造方法[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．