发明内容
本发明的目的是提供一种通用的信息交互平台,在复杂的电信运营支撑领域中,能适应不同应用系统间快速的信息交互需求变化,能实现简单灵活的信息交互;本发明能够克服重复开发,降低开发成本。
本发明提出的技术方案如下:
一种通用的信息交互平台,包括:
注册与定制管理单元,用于注册或注销服务提供方能够提供的服务及服务接口;还用于根据业务需求和已注册的服务定制包含一个或多个服务的服务包,供服务请求方订阅用;
服务请求处理单元,提供能够适配多种接口协议的接口;获得服务请求方接口信息;通过所述接口接收服务请求方的服务请求信息,其中包含服务包名称和消息体;从注册管理单元查阅所述请求的服务包的接口信息,将其和消息体分发至服务调用单元;
服务调用单元,提供能够适配多种接口协议的客户端;接收服务请求处理单元发过来的服务包名称和消息体,根据收到的服务包接口信息选择适应服务提供方服务接口协议的动态客户端,通过动态客户端对服务提供方提供服务的接口地址进行调用,将接收到的消息体发送给服务提供方。
优选的,所述的服务请求处理单元进一步包括:
服务请求处理单元,提供能够适配多种接口协议的接口;获得服务请求方接口信息;通过所述接口接收服务请求方的服务请求信息,其中包含服务包名称和消息体;从注册管理单元查阅所述请求的服务包的接口信息,将其和消息体分发至服务调用单元;
服务调用单元,提供能够适配多种接口协议的客户端;接收服务请求处理单元发过来的服务包名称和消息体,根据收到的服务包接口信息选择适应服务提供方服务接口协议的动态客户端,通过动态客户端对服务提供方提供服务的接口地址进行调用,将接收到的消息体发送给服务提供方。
优选的,所述的服务接口信息获取及分发模块中,还包括消息体格式的转换处理,以适应服务提供方识别的格式。
优选的,所述的服务调用单元还包括将调用结果反馈给服务请求处理单元;所述的服务请求处理单元还包括调用结果反馈模块,将收到的调用结果写入消息体,通过适配服务请求方接口将所述消息体反馈给服务请求方。
优选的,所述服务请求处理单元提供的基本接口为:WEB Servise接口、MQ消息队列接口和Socket接口,并可以根据实际应用的需要对基本接口进行扩展和删除;所述服务调用单元提供的基本接口的动态客户端为:WEBServise动态客户端、MQ动态客户端和Socket动态客户端,并可以根据实际应用的需要对基本接口的动态客户端进行扩展和删除。
优选的,还包括日志记录单元,用于记录平台运行过程中产生的日志和调用的结果。
优选的,
注册与定制管理单元,还包括对服务请求方身份进行注册并分配给目标服务权限;
服务请求处理单元,在通过所述接口接收服务请求方的服务请求信息之后,还包括,根据注册与定制管理单元已注册的身份和服务权限信息,验证服务请求方身份和是否具有请求目标服务的权限,通过身份验证和服务鉴权后才能将请求的服务包的接口信息和消息体分发至服务调用单元。
优选的,所述的注册管理单元进一步包括:
服务注册模块,用于注册或注销服务提供方能够提供的服务及服务接口,包括服务提供方提供的服务名称/代码、服务接口类型、接口地址信息等,将所述信息保存到服务注册表;
服务包定制模块,用于根据业务需求和已注册的服务定制包含一个或多个服务的服务包,供服务请求方订阅用。
为增加安全性管理,也可以进一步包括:
用户注册模块,对服务请求方身份进行注册并分配给目标服务权限。
优选的,还包括外部交互单元,用于输入服务提供方的注册信息,根据业务需求定制由已注册的服务组成的服务包,将所述注册的服务包名称/代码及包含的服务名称/代码发给注册管理单元,同时可将已通过注册管理单元注册的信息输出;用于输入服务请求方的服务请求信息,根据已定制的服务包进行订阅,将所订阅的服务请求信息发给服务订阅处理单元。
本发明该同时提出一种通用的信息交互方法,所述方法包括:
对服务提供方能够提供的服务及服务接口进行注册;
根据业务需求和已注册的服务,定制包含一个或多个服务的服务包,供服务请求方订阅用;
提供能够适配多种接口协议的接口;获得服务请求方接口信息;通过所述接口接收服务请求方的服务请求信息,其中包含服务包名称和消息体;根据服务包中包含的服务名称,查阅注册信息中所述请求的服务包所包含服务的接口信息,将消息体发送给服务提供方;
提供能够适配多种接口协议的客户端;根据收到的服务包接口信息选择适应服务提供方服务接口协议的动态客户端,通过动态客户端对服务提供方提供服务的接口地址进行调用,将接收到的消息体发送给服务提供方。
进一步地,将消息体发送给服务提供方之前,还包括将消息体格式进行转换处理,以适应服务提供方识别的格式。
进一步地,对服务提供方接口地址进行调用后,将调用结果写入消息体,通过适配服务请求方接口将所述消息体反馈给服务请求方。
进一步地,所述提供的基本接口类型为:WEB Servise接口、MQ消息队列接口和Socket接口,并可以根据实际应用的需要对基本接口进行扩展和删除;所述提供的基本接口的动态客户端为:WEB Servise动态客户端、MQ动态客户端和Socket动态客户端,并可以根据实际应用的需要对基本接口的动态客户端进行扩展和删除。
进一步地,还包括记录平台运行过程中产生的日志和调用的结果。
进一步地,还包括对服务请求方身份进行注册并分配给目标服务权限;
通过所述接口接收服务请求方的服务请求信息后,根据已注册的服务请求方身份信息验证服务请求方身份和是否具有请求目标服务的权限,通过身份验证和服务鉴权后才能将请求的服务包的消息体分发至目标服务提供方,继而才能通过动态客户端对目标服务提供方提供服务的接口地址进行调用。
进一步地,通过外部交互接口输入服务提供方的注册信息,根据业务需求定制由已注册的服务组成的服务包,并输出已注册和定制的信息;通过外部交互接口输入服务请求方的服务请求信息,根据已定制的服务包进行订阅,将所订阅的服务请求信息输出。
本发明技术方案所述的一种通用的信息交互平台,对外提供多种不同的基本接口,且接口可扩展,以适应多种不同接口的应用系统。另一方面,只要是符合通用信息交互平台提供的基本接口的系统,均可以接入所述信息交互平台,使得多个系统之间可以相互调用多种服务,进行无障碍的信息交互。当应用系统出现新的接口协议时,只需针对所述平台进行一次新接口协议适配器的开发,即可完成新接口的接入,提高了平台的开发效率,降低了开发成本。通过注册各应用系统可提供的服务名称,明确平台可提供哪些具体的信息交互内容,进一步将与业务相关的服务用服务包定制下来,使得多个相同或相似业务的服务名称被归纳对应到一个服务包下,建立一个服务包对应多个服务名称的对应关系,在服务请求方发起调用时,只需输入或选择相应的服务包名称即可完成调用,而不用关心中间的处理环节,当服务提供方的服务名称变更时,也不需要通知其他应用系统,因此使得信息交互变得更加简便与灵活;平台对服务提供方提供的服务地址按照接口类型的不同分别进行保存,获得服务提供方的地址列表,使得交互信息的路由变得更加明确,服务请求方只需输入或选择相应的服务包名称,即可自动找到信息交互路由完成调用,摆脱了固定交互路由的局限性,将传统的点对点的应用方式改变成多对多的总线方式,实现了各系统间简单便捷的信息交互,优化各系统间的架构,易于管理和维护;本发明为了减化调用接口的改造工作,特引入了动态客户端,以动态适配多协议的系统接口,减少接入系统的接口改造工作。
具体实施方式
要实现不同应用系统之间的灵活信息交互,即通过应用系统的服务接口可以随时根据业务需要在不同应用系统之间传递信息,具体为在服务请求方应用系统的服务接口与服务提供方应用系统的服务接口之间传递信息。为使得任何一个能够提供服务的应用系统或者需要服务请求的应用系统,都能够自由不受约束地交互信息,本发明提供一种通用的信息交互平台作为服务提供方与服务请求方之间的一种中间媒介,来实现两者之间的信息交互。本发明中所述的服务泛指各个应用系统所能提供的业务功能和/或资源数据,能够为其他应用系统重复使用。
为了使本技术领域的人员能够更好地理解本发明方案,下面结合附图和实施例对本发明作进一步的详细说明。
参照图1,为本发明一种通用的信息交互平台实施例一的结构示意图,包括注册管理单元,服务订阅处理单元和服务调用单元,其中:
注册与定制管理单元11,用于注册或注销服务提供方能够提供的服务及服务接口;还用于根据业务需求和已注册的服务定制包含一个或多个服务的服务包,供服务请求方订阅用。
注册服务的内容应至少包括服务名称/代码、服务提供方提供服务接口的协议类型、服务提供方的接口地址信息,还可以包括服务提供方名称、对所提供服务(数据)的描述等。将填写如下服务注册表1:
表1服务注册表RegisterTable
对于常见的业务相关的系列服务可以预先定制,根据已经注册的服务名称,选择定制一个或多个服务,组成一个服务包,便于服务请求方订阅用,填写如下服务定制表2:
表2服务定制表SubscribeTable
服务请求处理单元12,提供能够适配多种接口协议的接口;获得服务请求方接口信息;通过所述接口接收服务请求方的服务请求信息,其中包含服务包名称和消息体;从注册管理单元11查阅所述请求的服务包的接口信息,将其和消息体分发至服务调用单元13;。
所属的接口类型可以支持多种常用的通讯接口,如Socket接口、WEBServise接口、MQ接口等。
服务请求方一般根据自身的业务需求,根据表2中的服务包名称/代码及所对应的服务名称/代码进行订阅,发出服务请求信息。
通过所述接口接收服务请求方订阅的服务请求信息,解析之可得到服务包信息,查阅表1可知对应的每个服务的接口类型和地址信息。
本单元还通过所述接口接收到与服务相关的消息体,例如一项查阅天气情况的服务,那么就要将地点和日期参数在服务请求中同时携带在消息体中,以便于从服务提供方得到某地某日的天气情况。
综合所得到的每个服务的接口类型、地址信息和消息体内容,发至服务调用单元13。
服务调用单元13,提供能够适配多种接口协议的客户端;接收服务请求处理单元发过来的服务包名称和消息体,根据收到的服务包接口信息选择适应服务提供方服务接口协议的动态客户端,通过动态客户端对服务提供方提供服务的接口地址进行调用,将接收到的消息体发送给服务提供方。
适应服务提供方接口的动态客户端就是对应的Socket接口动态客户端、WEB Servise接口动态客户端、MQ接口动态客户端等。这时,这些动态客户端将与服务提供方一起进行信息交互。
除了这些常用的基本接口的动态客户端外,还可以根据实际应用的需要对动态客户端进行扩展和删除,如果服务提供方的接口不是基本接口,可以对动态客户端进行扩展,在此增加新的接口类型的动态客户端,并且采用热部署的方式,即插即用,不用进行复杂的开发工作,简化了研发人员的工作量,提高了效率。
动态客户端可以用Java代码实现,主要包括获取服务调用地址、创建服务调用会话,通过动态客户端访问目标服务接口,将消息体发送至目标服务,从而完成对服务提供方的调用。
动态客户端主要是为了解决平台访问服务提供方时,服务提供方接口与服务请求方接口不统一的情况。动态客户端首先根据服务提供方的协议类型,来选择相应的客户端程序,如服务提供方在平台中注册的是MQ接口,平台调用MQ动态客户端程序,去访问服务提供方的MQ接口。同理,如果平台要访问的服务提供方注册的是Web Service接口,平台则会调用WebService动态客户端程序去访问服务提供方的Web Service接口。服务提供方的接口协议类型、接口地址、参数等在注册时已存入平台的注册与定制管理单元。
通过动态客户端,可以避免接入平台的应用系统再进行自身接口改造工作,减少接口开发和联调工作量。
如图2用于进一步说明服务请求处理单元具体组成的实施例二:
服务请求接收模块121,提供能够适配多种接口协议的接口,并可根据新的接口协议需求扩展新的接口;获得服务请求方接口信息;通过所述接口接收服务请求方发出的服务请求信息,将所述服务请求信息发送至服务接口获取及分发模块122;。
服务接口获取及分发模块122,用于解析接收到的服务请求信息,获得请求的服务包名称/代码以及携带的消息体,根据服务包名称从注册与定制管理单元查阅所包含的服务名称对应的服务提供方的接口协议类型及地址信息;然后将所述服务请求方携带的消息体和服务提供方的接口地址信息分发至服务调用单元13。
为解决大量的成批量的信息交互,可以将基本接口设为:WEB Servise接口、MQ消息队列接口和Socket接口,并可以根据实际应用的需要对基本接口再进行扩展和删除。
所述服务调用单元提供的基本接口的动态客户端对应为:WEB Servise动态客户端、MQ动态客户端和Socket动态客户端,并可以根据实际应用的需要对基本接口的动态客户端进行扩展和删除。
例如,若服务请求方使用的是Web Service的接口,而服务提供方使用的是MQ接口,服务请求方通过自身的Web Service接口发送了服务请求信息;平台的服务请求接收模块121获得服务请求方接口信息,从121的Web Service接口接收服务请求信息,将所述服务请求信息发送至服务接口信息获取及分发模块122,服务接口获取及分发模块122解析服务请求信息中的服务包,查阅注册表,得到所包含的服务提供方的服务名称和地址/地址列表和消息体,发送至服务调用单元13中的MQ动态客户端,服务调用单元13中的MQ动态客户端接收到信息后,根据获得的服务提供方的地址列表,将消息体发送到所有服务提供方,并对服务提供方进行调用。
表1中与接口类型相应的地址信息可以进一步扩展,将不同接口类型的地址信息分别进行保存。
如果是MQ接口,可将MQ接口类型的地址信息保存入MQ地址信息表中,如表3所示,其中MQID作为主键与表1中的InterfaceAddressID相对应,则在使用时,就可以通过主键查找到与其服务名称相对应的地址。
表3MQ地址信息表MQ_ADDRESS
名称 |
描述 |
MQID |
目标地址ID |
HostName |
目标主机名称/IP |
Port |
端口 |
QManagerName |
队列管理器名称 |
InputQ |
队列名称 |
如果是Web Service接口,可将Web Service接口类型的地址信息保存入Web Service地址信息表中,如表4所示,其中WSID作为主键与表1中的InterfaceAddressID相对应,则在使用时,就可以通过主键查找到与其服务名称相对应的地址。
表4Web Service地址信息表WS_ADDRESS
名称 |
描述 |
WSID |
目标地址ID |
Address |
服务地址 |
Operation |
服务接口 |
若平台还有其他的接口类型,则还可以设其它对应的地址信息表。
这样的设计结构,使得接口的扩展更加容易,即针对新的标准接口进行新的开发,便于使用新接口的应用系统可以接入平台;根据新的接口接入平台的需要,在服务请求处理单元中添加一个新的接口类型,或者在服务调用单元添加新的动态客户端,相应地添加有关接口协议内容对应的表结构。由于添加内容都是独立存在,因此实现添加新接口的在线升级,对平台的其余功能单元和数据结构均无影响,同样删除一个接口时也不会对其他单元造成影响。如为适应HTTP,JMS,TCPIP,FTP等常见的协议类型接口,不用进行复杂的开发工作。
需要说明的是,为了完成接口的增删功能,在增加新的接口时,需要在注册与定制管理单元内增加相应接口的地址信息表,同样在删除接口时,需要在注册与定制管理单元内删除相应接口的地址信息表。
例如,要新增一个适配服务请求方的FTP协议接口,需要在平台的服务请求处理单元新增一个FTP接口,接收接入系统的FTP请求,相应地在注册与定制管理单元中增加一个FTP地址信息表如表5所示,用于保存FTP的地址信息:
表5FTP地址信息表FTP_ADDRESS
名称 |
描述 |
FTPID |
主键 |
HostName |
目标主机名称/IP |
Port |
端口 |
UserName |
用户名 |
Password |
密码 |
url |
文件路径 |
FileName |
文件名称 |
由于平台提供了多个基本的对外接口和多个基本接口的动态客户端,完全屏蔽了服务请求方和服务提供方在接口上的差异,但服务请求方和服务提供方还可能存在由于各方面的原因导致双方对所传递消息体的描述方式不一致的情况,如对于消息体中的同一个参数信息,服务请求方和服务提供方的命名方式有可能不相同,因此需要将服务请求方的消息体根据服务提供方的消息体形式进行格式转化,才能完成信息的交互。
服务请求方和服务提供方还可能存在由于各方面的原因导致双方对消息体的描述方式不一致的情况,对于消息体中的同一个参数信息,服务请求方和服务提供方的命名方式有可能不相同,因此需要将服务请求方的消息体根据服务提供方的消息体形式进行转化,才能完成信息的交互。
为使消息体的内容得到更好的利用,进一步优化的方案还可以考虑,在上述服务请求处理单元中,增加消息体的数据格式变换处理功能,以适应服务请求方多种格式的数据需求。
进一步地,适用更加广泛的技术方案还可以包括对调用结果的处理,如下:
所述的服务调用单元还包括将调用结果反馈给服务请求处理单元;
所述的服务请求处理单元还包括调用结果反馈模块,将收到的调用结果写入消息体,通过适配服务请求方接口将所述消息体反馈给服务请求方。
调用结果一般包括通知消息和/或封装的调用结果。对于一些简单的调用,如更新文件,返回的调用结果为通知消息即通知服务请求方调用已经完成,对于一些复杂的调用,如查询,返回的结果为封装的调用结果信息,即将查询的结果封装起来从服务请求方接口返回给服务请求方,供服务请求方使用。
例如前述查阅天气情况的服务,需要将查阅天气的结果反馈给服务订阅处理单元,写入消息体,通过平台的对外接口和服务请求方接口将所述消息体反馈给服务请求方。
为了促使本发明平台与服务请求方和服务提供方之间进一步有灵活方便的信息交互,本发明平台还提供更优化的方案,可增加一个外部交互单元14,如图3所示的实施例三,用于输入服务提供方的注册信息,根据业务需求定制由已注册的服务组成的服务包,将所述注册的服务包名称/代码及包含的服务名称/代码发给注册与定制管理单元,同时可将已通过注册与定制管理单元注册的信息输出;用于输入服务请求方的服务请求信息,根据已定制的服务包进行订阅,将所订阅的服务请求信息发给服务请求处理单元。
如果选择人机交互式的外部交互单元,通过人机交互界面进行输入和输出,则给运维管理带来极大的便利性。例如,服务提供方利用人机交互界面输入登记所拥有的服务信息,便于注册与定制管理单元进行服务注册,也可根据情况注销已经注册的服务;同时该界面也可以把已经注册好的服务信息进行展现,服务请求方则利用该界面查阅已经注册好的服务信息,并选择订阅其需要的服务,并携带消息体信息,将选好的若干个服务一起组成定制为服务包,便于服务订阅处理单元做进一步处理。服务请求方也利用该界面直接订阅已经定制好的服务包,使得信息交互更加便捷。借助该界面还可以根据业务需求输入消息体的内容,甚至于增加消息体的多种格式表达,便于给服务请求方提供更好的服务。
外部交互单元14接收的服务请求方发出的服务请求信息,是包含服务包名称/代码、以及服务请求方与服务提供方交互消息体messageBody的字符串,可以是XML格式,也可以是约定的其他格式。
服务调用单元13中的动态客户端根据消息体的内容使服务提供方实现服务调用,即通知服务提供方按照消息体中所指示的FTP地址和文件路径更新A.zip的文件,至此完成了信息交互的过程。
由于一个服务包名称/代码可以与多个服务名称/代码相对应,因此由一个服务包名称/代码可能查找到多个服务的地址信息,为了下一步进行更好的服务地址分发,提高平台的工作效率,优选的,可以将这些地址信息保存为一个地址列表。
优选的,通用信息交互平台还可以包括:
日志记录单元,用于记录调用过程中产生的日志和调用的结果。以便于及时跟踪了解信息交互过程。
优选的,通用信息交互平台还可以增加安全管理功能,对服务请求方身份进行验证和对服务调用权限进行控制,以便于实现安全的信息交互,即:
注册与定制管理单元,还包括对服务请求方身份进行注册并分配给目标服务权限;
服务请求处理单元,在通过所述接口接收服务请求方的服务请求信息之后,还包括,根据注册与定制管理单元已注册的身份和服务权限信息,验证服务请求方身份和是否具有请求目标服务的权限,通过身份验证和服务鉴权后才能将请求的服务包的接口信息和消息体分发至服务调用单元。
这时,在注册与定制管理单元中,需要增加一个用户身份注册表,至少包括用户名和密码,用于验证用户身份,如表6所示:
表6用户身份注册表UserInfoTable
名称 |
描述 |
备注 |
USER_NAME |
应用系统用户名 |
必要项 |
然后,需要给服务请求方系统分配服务调用权限。平台通过关联服务注册表中的“服务请求方系统名称”和服务定制表中“服务包名称/代码”来完成对应用系统用户分配服务调用权限。关联内容记录在如下表7中的服务权限表,也在注册与制定管理单元进行制定和修改。
表7服务权限表UserPopedomTable
名称 |
描述 |
备注 |
USER_NAME |
应用系统名称 |
必要项 |
ServicePack |
服务包名称/代码 |
必要项 |
服务请求方系统在完成系统注册和获取服务调用权限后,就可对平台进行正常交互,访问已有权限的服务。
平台的服务请求处理单元在接收到服务请求方的服务请求信息之后,根据注册与定制管理单元已注册的用户名和密码名称进行身份验证,根据服务权限表信息进行鉴权。通过对服务请求方进行身份验证和鉴权之后,才能将请求的服务包的接口信息和消息体分发至服务调用单元。
为了能更好的实现注册与定制管理单元11的功能,参见图4所示的实施例四,注册与定制管理单元11可以进一步包括:
服务注册模块,用于注册或注销服务提供方能够提供的服务及服务接口,包括服务提供方提供的服务名称/代码、服务接口类型、接口地址信息等,将所述信息进行保存入服务注册表。
所述信息可以通过人机交互界面接收获得。由于接入平台的应用系统接口类型不同,导致不同接口类型的应用系统提供的服务地址信息格式有所不同,因此注册管理单元将接收到的地址信息按照服务提供方接口类型的不同分别进行保存,保存地址信息的表与服务注册表通过主键进行关联。如实施例一中表1和实施例二中表3、表4、表5所示。若平台还有其他的接口类型,则还应有其它对应的地址信息表。
服务包定制模块,用于根据业务需求和已注册的服务定制包含一个或多个服务的服务包,供服务请求方订阅用。
服务请求方一般会请求一个或多个服务,预先按常用的业务类型将有业务关联的服务打包,建立服务包名称与服务名称的对应关系,便于即时订阅,如实施例一中的表2所示,可以在应用的过程中根据业务的变更需求增加定制新的服务包,平台的使用者也可以通过服务包名称/代码在人机交互界面上查询有哪些服务可用。
一个服务包名称可与一个服务名称相对应,也可与多个服务名称相对应。开发人员或平台高级管理员可以根据实际业务的需求,来完成服务包与服务名称对应关系的注册,将相同或相似业务类型的服务名称对应到一个服务包下,因此服务请求方在使用平台进行信息交互时,只需要输入自己需要调用的服务包名称,平台即可根据服务包名称/代码找到其对应的服务名称,进而找到获取该服务的地址后,自动调用服务,最终完成信息交互。
一个应用系统可以在平台上注册能够提供服务的相关信息,以表明可以提供哪些服务,当然如果其可以提供多种接口类型的服务,则也可以注册多个接口类型的服务,另一方面,当该应用系统作为服务请求方需要调用其他应用系统提供的服务时,只需输入或选择相应的服务包名称即可。
注册与定制管理单元11还可以进一步包括用户注册模块,对服务请求方身份进行注册并分配给目标服务权限。用以实现安全的信息交互。
平台在接收到应用系统的注册信息后,将注册过的服务进行梳理或整合,即将业务相同和相似的服务名称与服务包名称进行关联后,将可这些可以被调用或订阅的服务在人机交互界面中显示。接入系统作为服务请求方时,首先在平台可提供的服务列表即众多的服务包名称/代码(ServicePack)中查找需要调用的服务,通过该服务包代码完成后续的调用工作。
在解析服务请求信息时,只需要读取字符串,取出相应的节点即可。
假设有以下业务场景:综合资源系统的资源数据在发生变更时,需要将变更数据同步至网络优化系统、综合性能管理系统。则综合资源系统的资源数据在发生变更时,需要通知网络优化系统、综合性能管理系统要进行相应数据变更;综合资源系统作为服务请求方通知资源变更,网络优化系统、综合性能管理系统作为服务提供方提供资源获取服务。首先需要在平台上注册两个服务,一个是网络优化系统的资源获取服务,一个是综合性能管理系统的资源获取服务,分别有各自的文件更新服务接口,文件更新服务的功能是根据服务请求方提供的文件地址信息获取文件。注册信息可以包括服务名称:Service1,服务提供方系统名称sys1(网络优化系统),Service2,服务提供方系统名称sys2(综合性能管理系统),sys1的服务接口地址为:http://192.168.1.1/wangyou/service,sys2服务接口地址为:http://192.168.1.2/zonghexingn/service。然后再定制一个服务包,名称为“fileupdate”,包括以上两个服务Service1和Service2。那么当综合资源系统要更新文件时,即可选择订阅“fileupdate”服务包,发出如下的请求服务信息,本发明以XML格式为例。从提高平台工作效率的角度出发,可以由平台的使用者约定服务请求信息的具体格式,即将服务包名称/代码、以及消息体按照固定的顺序写入字符串,则接入通用信息交互平台的服务请求方,都需要遵循约定的格式发送服务请求信息,从而使得平台可以更加简便快捷的工作。
例如服务请求方发出的服务请求信息message.xml如下所示:
<message>
<messageInfo>
<ServicePack>fileupdate</ServicePack>/*服务包名称*/
<systemID>sys1<systemID>/*服务请求方系统名称*/
</messageInfo>
<messageBody>/*消息体*/
<property name=EventID value=2 type=string/>
<property name=ConnectionString
value=ftp://usr:pwd192.168.0.123:21 type=string/>
<property name=Path value=/home/user/data type=string/>
<property name=File value=A.zip type=string/>
</messageBody>
</message>
上述服务请求信息message.xml中所述的消息体messageBody,messageBody里的内容说明的是要更新的文件的名称A.zip,获取该文件的FTP连接地址ftp://usr:pwd192.168.0.123:21和文件路径/home/user/data。
平台根据服务包名称“fileupdate”通过查阅服务注册表可以得知两个服务的名称Service1和Service2,将所述消息体发送到Service1和Service2的服务接口地址处,服务提供方sys1(网络优化系统)、sys2(综合性能管理系统)的动态客户端将执行服务提供方sys1和sys2在服务接口处的服务程序,读取消息体中的FTP有关登录信息(使用权限、连接地址、文件路径等)则获知到该ftp地址处去获取更新的文件,便达到了综合资源系统与网络优化系统、综合性能管理系统之间数据同步的目的。
由于所有接入平台的应用系统在接入前都需要对自身的信息进行注册,发布可以提供哪些服务,因此根据服务请求方订阅的服务包名称/代码从所述注册与定制管理单元11中获取与所述服务包名称/代码对应的服务名称,进而根据所述服务名称获取服务提供方的地址列表和服务提供方的接口信息。
实施例一中已经描述过,由于在应用系统进行注册时,已经填写了包含地址的服务相关信息,因此可在注册管理单元中获得提供该服务的地址信息,若订阅的服务包对应的服务涉及有多个服务提供方,则可以查询到多个服务提供方的地址信息,返回一个地址列表。
服务接口信息获取及分发模块122,用于将消息体和服务提供方的接口及地址列表分发至所述服务调用单元13。
下面实施例五结合实际情况介绍一种通用信息交互平台的工作原理:
1、某应用系统需要对外发布一种数据。某用户登录通用信息交互平台,通过外部交互单元14输入相应的信息,在注册与定制管理单元11的服务注册模块111注册该应用系统名称为sys1,其提供服务名称为I_NM_IN-NM_W_NE_43的文件更新服务,接口类型为Web Service,输入了相应的地址信息(包括服务地址和服务接口),并通过服务包定制模块112注册服务包名称fileupdate与该服务名称相关联。
2、已经通过平台注册的某应用系统sys2,接口类型为MQ,需要请求调用服务包名称为fileupdate下的服务,某用户登录通用信息交互平台,并通过外部交互单元14向平台发送了服务请求信息message.xml。
3、服务请求接收模块121接收服务请求信息,通过对外接口将接收到的服务请求信息message.xml发送给服务接口信息获取及分发模块122。
4、服务接口信息获取及分发模块122解析服务请求信息,获得服务包名称为fileupdate,服务请求方系统名称为sys2,和携带的消息体。根据服务包名称到注册与定制管理单元中查找到与服务包名称fileupdate对应的服务名称I_NM_IN-NM_W_NE_43,进而查找到了sys1系统的接口类型为Web Service,并获得其地址信息。
5、服务接口信息获取及分发模块122将所述服务请求方sys2携带的消息体转换成sys1可识别的消息体,通过对外接口将消息体和sys1的接口类型发送到服务调用单元13。
6、服务调用单元13根据服务接口信息获取及分发模块122发送的sys1接口类型,选择了Web Service的动态客户端,并将经过转换的消息体发送到sys1接口地址,最后通过Web Service动态客户端对sys1接口进行调用。
7、优选的,平台通过调用结果反馈模块,反馈调用的结果,并通过日志记录单元记录调用过程中产生的日志。
本发明还提供实施例六,一种实现通用的信息交互平台的实现方法,如图5所示,包括以下步骤:
步骤S101:对接入平台的服务提供方应用系统能够提供的服务及服务接口进行注册;
可以通过人机交互界面输入注册信息,也可以通过写配置文件等其他方式,注册需要进行信息交互的各应用系统提供的服务名称、应用系统服务接口类型、该应用系统提供服务接口的地址信息。
步骤S102:根据业务需求和已注册的服务,在平台上定制包含一个或多个服务的服务包,供服务请求方订阅用;
根据业务需求和已注册的服务,将服务包名称/代码与服务名称的对应关系进行定制。
以上两步其实是完成了两个部分的注册,即服务、服务包的注册以及服务包与服务的对应关系信息的注册。
由于接入平台的应用系统接口类型不同,导致不同接口类型的应用系统提供的服务地址信息格式有所不同,因此注册与定制管理单元将接收到的地址信息按照其系统接口类型的不同分别进行保存,保存地址信息的表与保存应用系统信息的表通过主键进行关联。应用系统信息保存在注册表中,不同接口类型的地址信息分别进行保存,保存在地址信息表中。
对需要注册信息的相关阐述参见实施例一中注册与定制管理单元的相应描述,在此不再赘述。
步骤S103:平台提供能够适配多种接口协议的接口;获得服务请求方接口信息;通过所述接口接收服务请求方的服务请求信息,其中包含服务包名称和消息体;根据服务包中包含的服务名称,查阅注册信息中所述请求的服务包所包含服务的接口信息,将消息体发送给服务提供方。
提供的基本接口为:WEB Servise接口、MQ消息队列接口和Socket接口,并可以根据实际应用的需要对基本接口进行扩展和删除。
当应用系统出现新的接口类型时,则平台需要相应提供新的接口类型和应用系统的接口类型适配,需要开发新接口协议程序、添加基于新协议内容的表结构。由于添加内容独立于原有的接口功能,因此添加新接口类型的行为对平台的其余功能单元和数据结构均无无影响,同样删除时也不会对其他单元造成影响。同时,在增加新的接口时,需要增加相应接口的地址信息表,同样在删除接口时,需要删除相应接口的地址信息表。
所述服务请求方发出的服务请求信息,是包含有服务包名称/代码、以及服务请求方与服务提供方交互消息体的字符串。
解析所述服务请求信息,根据服务包中包含的服务名称,进而可以在注册过的地址信息中查找与该服务名称对应的提供该服务的地址信息,最终获得服务提供方的地址。由于一个服务包名称可以包含多个服务,即与多个服务名称相对应,因此可能查找到多个服务接口地址信息,为了下一步进行更好的分发,提高平台的工作效率。优选的,可以将这些地址信息保存为一个地址列表。
步骤S104:平台提供能够适配多种接口协议的客户端;根据收到的服务包接口信息选择适应服务提供方服务接口协议的动态客户端,通过动态客户端对服务提供方提供服务的接口地址进行调用,将接收到的消息体发送给服务提供方。
由于平台提供了多个基本的对外接口和多个基本接口的动态客户端,完全屏蔽了服务请求方和服务提供方在接口上的差异。需要补充的是,某些情况下,服务请求方和服务提供方还可能存在由于各方面的原因导致双方对消息体的描述方式不一致的情况,对于携带消息体中的同一个参数信息,服务请求方和服务提供方的命名方式有可能不相同,这时可以将服务请求方的消息体根据服务提供方的消息体形式进行转化,从而方便完成信息的交互。
一般提供的基本接口的动态客户端为:WEB Servise动态客户端、MQ动态客户端和Socket动态客户端,并可以根据实际应用的需要对基本接口的动态客户端进行扩展和删除。
通过所述动态客户端根据所述发送的消息体和获取的所述服务提供方的地址列表,对服务提供方接口进行调用。
为了增加安全管理功能,基于上述实施例六,方案中还可增加对服务请求方身份进行验证和对服务调用权限进行控制,以便于实现安全的信息交互,即:
对服务请求方身份进行注册并分配给目标服务权限;
通过所述接口接收服务请求方的服务请求信息后,根据已注册的服务请求方身份信息验证服务请求方身份和是否具有请求目标服务的权限,通过身份验证和服务鉴权后才能将请求的服务包的消息体分发至目标服务提供方,继而才能通过动态客户端对目标服务提供方提供服务的接口地址进行调用。
服务请求方系统在完成系统注册登陆和获取服务调用权限后,就可对平台进行正常交互,访问已有权限的服务。则工作过程如下:
服务请求方向平台发起服务调用请求,请求信息中需要包含有系统名称、验证密码和服务包名称/代码,以及系统名称对服务包名称/代码的服务效用关系几项内容。
平台在接受到服务调用请求后,进行身份验证和服务调用权限的认证。首先进行用户身份验证,通过用户信息注册表中的用户注册登录信息来验证系统用户名是否存在,如果验证失败则返回失败原因。在通过用户信息验证后则进行服务调用权限鉴定,通过服务请求方系统此次请求中所含的的系统用户名和需要请求的服务包名称/代码信息,与服务权限表中的用户和服务包名称/代码的关联关系进行比较验证,判断该系统用户是否具有请求目标服务的权限。验证成功后将请求的服务包的消息体分发至目标服务提供方,继而通过动态客户端对目标服务提供方提供服务的接口地址进行调用。验证失败则返回服务调用权限验证失败信息。
根据以上步骤,参见图5,优选的,上述实施例六的步骤还包括,在步骤101和102增加通过外部交互接口实现注册,在步骤103通过外部交互接口接收服务请求方的订阅的过程。
另外,还可以对调用过程中产生的日志和调用的结果进行记录。
所述调用返回的结果包括通知消息和/或封装的调用结果信息,对于一些简单的调用,如更新文件,返回的调用结果为通知消息即通知服务请求方调用已经完成,对于一些复杂的调用,如查询,返回的此结果为封装的调用结果信息,即将查询的结果封装起来发送给服务请求方,供服务请求方使用。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。