信息孤岛与企业应用集成研究
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2018）13-0038-03
Research on Information Island and Enterprise Application Integration
DONG Heng-jing， ZHOU Hui-qing
（COSCO SHIPPING BULK CO.， LTD.， Tianjin 300010， China）
Abstract： After many years of information construction， many enterprises have made great achievements， and also faced with the enterprise "information island" phenomenon. "Information island" is a common problem， almost all the enterprises in the process of information construction must face and solve. After the analysis of this problem， this paper discusses how to solve it. In terms of Technology， this paper put forward 4 steps to solve the problem of “information island”. Among them， “enterprise application integration” is the most basic and important step， and then this paper propose a method to complete it. On the basis of open source CAS， ESB and other products， the integration development and tests are carried out to prove the method.
Key words： Information Island； Single Sign-on（SSO）； Enterprise Service Bus（ESB）； Enterprise Application Integration（EAI）； CAS； WSO2
随着持续的信息化建设，国内许多企业在信息化应用方面都取得了很大的成绩，这些成绩给企业带来了巨大的经济效益。但随着应用系统规模的扩大，企业也出现了“信息孤岛”（Information Isolated Island，或Information Island）[1]的现象。信息孤岛是一个普遍的问题，它的产生有一定的必然性[2]。企业的信息化是一个循序渐进的过程，不能一蹴而就。而计算机开发技术飞速发展，使用较新的开发技术的应用系统往往比之前的应用系统有一定的优势，但也造成很难与以往应用系统采用相同的系统标准。这样，在大多数企业中，特定应用的开发往往局限于企业发展的特定阶段，围绕特定的业务需求。这些因为时间不同，所用的平台、架构、技术、标准也不尽相同，形成了企业内部各信息资源并存，业务、数据跨平台协作困难的现象，就是常说的“信息孤岛”。
一般认为，“信息孤岛”可以分为数据孤岛、系统孤岛、业务孤岛和管控孤岛[3]，并且经常是多种孤岛形式并存。“信息孤岛”问题的存在，在数据质量、操作效率、经营管理等等方面都会给企业带来负面的影响[2]。因此，“信息孤岛”问题如何解决已经引起了业界广泛的关注[1-6]。“信息孤岛”问题的解决策略，可以分为被动策略和主动策略[1]。企业一般需要被动策略和主动策略结合去解决“信息孤岛”的问题。本文讨论的“信息孤岛”问题在技术上如何解决，主要属于被动策略的范畴。
1“信息孤岛”技术解决方法
“信息孤岛”的解决，是一个系统化的工程，需要有信息化建设的统一规划和步步推进。在技术上，解决方法主要包括数据层面的数据共享，应用系统层面的服务调用，用户界面层面的门户策略，业务流程层面的流程整合等等。基本上，“信息孤?u”的问题可以通过以下4步得到解决。
1）进行企业应用集成（Enterprise Application Integration，简称EAI），使各应用系统互联互通，共享业务与数据；
2）进行企业信息门户（Enterprise Information Portal，简称EIP）建设，使各应用系统在操作层面上成为一个整体；
3）统一数据标准，建立数据中心，使公司在数据上深度融合；
4）统一业务流程，形成跨部门的公司级流程体系。
做好前两步，只要用户需求确定，就可以将用户关心的各系统数据集成到统一的界面（门户），达到用户“统一查看业务数据、灵活处理各业务功能”的目标。在这个意义上，应用系统间已经互联互通，可以说企业已经消除了信息孤岛。但各系统的数据还是原系统内部的格式，流程还是原系统内部的流程，进行大范围的数据分析还是比较比较困难的。从直观感受上说，前两步相当于进行企业并购，后两步则是对并购后的企业进行整合吸收。后两步是在前两步完成的基础上进行的集成升级工作，将使得公司各个应用系统、数据成为一个整体，这更容易给公司带来潜在的价值。同时，从企业应用架构上来说，企业信息门户建设是企业应用集成结果的展现，企业应用集成是“信息孤岛”问题解决的基础与关键。 本文以下部分将进行企业应用集成的实现研究。
2企业应用集成的实现研究
企业应用集成是解决企业“信息孤岛”问题的关键步骤，本文提出了实现应用系统集成的架构方案（如图1），并基于开源产品，对该方案进行了实现与测试。
本方案主要基于单点登录（Single Sign-on，简称SSO）[11] 系统、企业服务总线（Enterprise Service Bus，简称ESB）[8]，和Web Services [10]等技术，进行企业应用集成方案的设计。
系统间的连通，主要包含嵌套其她应用系统的链接（页面），进行跨系统的业务（服务）的调用，进行数据的集成等。系统中嵌套其他应用系统的链接，在单点登录系统的帮助下，可以以对方系统的合法账号（登录后）进入链接所引用的页面。而对于系统间的业务/数据调用，由于不同人员（账号）发起的调用在被调用系统中被识别为是同一个地址（调用者应用服务器）发出的，单点登录系统不能靠Session或者Cookie对调用者账号进行区分，所以只靠单点登录还不能实现携带用户身份的系统间服务调用。
如图2，系统间的业务/数据调用，可以通过企业服务总线与单点登录系统的集成来解决。
如图3，没有加入单点登录的应用系统（Client）调用服务前（已经加入单点登录的应用将直接从第5步起），需要通过企业服务总线进行登录/验证。验证通过后，企业服务总线在本地缓存用户的登录信息，并将单点登录Token返回给客户端应用。之后，客户端应用将通过携带单点登录Token进行服务的调用，企业服务总线通过本地缓存的登录信息（缓存中没有时，企业服务总线通过单点登录服务器进行验证，若验证通过，先进行本地缓存），转换为携带对方应用系统的账号进行服务调用。
到这里，单点登录系统与企业服务总线集成后，无论是已经加入单点登录的应用，或是没有加入单点登录的应用，都可以携带自己的身份（以对方系统的账号），调用各应用发布的web服务（业务函数）。
对于C/S架构的应用，自然没有办法发布web服务，但可以通过数据服务服务器发布基于数据库的web服务。
这样，企业所有的应用系统/数据库都可以实现web服务的发布和调用，也就是实现了业务/数据服务的互联互通。再加上企业门户对业务/数据服务的整合，就实现了公司所有应用系统的充分连通。
3基于开源产品的实现
3.1开源产品简介
企业服务总线是从SOA发展而来的，是传统中间件技术与XML、Web服务等技术结合的产物，是企业服务集成架构运行的基础设施，为系统调用提供统一的服务调用接口。企业服务总线负责对分散在整个企业内的服务进行集中配置、部署和管理，采用总线模式可以有效管理和简化应用之间的集成拓扑结构，可以消除不同应用之间的技术差异，实现不同服务之间的通信和整合。WSO2是一个领先的开源SOA（Service-Oriented Architecture）解决方案提供者，其提供了一整套面向企业应用的架构与产品，其中就包括企业服务总线和数据服务服务器等产品。
单点登录是进行企业门户建设的关键步骤之一，实现了用户操作层面上的系统之间的灵活跳转。用户只需一次登录，就可以根据权限进入不同的应用系统，省去了重复验证的烦琐，这是解决系统孤岛的基础工作。CAS（Central Authentication Service）[12]是Yale大学发起的一个开源项目，为Web应用系统提供一种可靠的单点登录方法，CAS在2004年12月正式成为JA―SIG的一个项目，是目前比较流行的服务于企业单点登录的解决方案之一。
CAS、WSO2的ESB和DSS（Data Services Server）都是基于Apache License 2.0协议的，可以进行二次开发与部署。本文主要在它们的基础上进行开发与实现。
3.2实现
加入单点登录的应用系统，在调用服务时可以携带单点登录Token。没有加入单点登录的应用系统，需要先进行登录，再携带单点登录Token进行服务调用。因此，我们在CAS服务器、ESB服务器和应用系统三部分，进行了的实现开发，主要为了实现两种命令调用：一个是登录，一个是带单点登录Token的服务调用。
实现方法具体如下：
1）CAS开发部分。
针对本文的设计，基于CAS服务器的开发，实现如图4的两个服务。其中，AccountInfo类存储的是应用系统账号类型、账号等信息。
2）WSO2 ESB开发部分。
基于ESB服务器，需要进行以下开发：
① 通?^发布login.aar文件到ESB服务器（文件夹路径为：repository/deployment/server/axis2services）的方式，在ESB上发布login的web服务。
② 开发并发布起“单点登录过滤器”作用的ClassMediator（基于org.apache.synapse.mediators.AbstractMediator类）。该过滤器根据客户端应用的SOAP请求，解析并判断包含在Header中的是待验证的登录信息，还是单点登录的Token信息。进而决定是到单点登录服务器进行验证请求（存入缓存），或是根据Token获取账号信息（从缓存中读取）。由于无论是否缓存账号信息，都可以根据Token获得账号信息（如果没有缓存，到单点登录服务器调用服务），所以该过滤器支持ESB的集群部署。
③ 通过ESB管理控制台，开发并发布Login Sequence，设置login服务使用该Sequence。在客户端应用调用登录操作时，Login Sequence进行单点登录服务器的登录调用，直接返回单点登录Token（不执行login服务的实现内容）。其代码的主体部分如图5。 ④通?^ESB管理控制台，开发并发布Check Sequence，设置所有需要用户账号信息的服务都使用该Sequence，并在ESB的控制台界面中给服务制定一个初始化参数（应用系统账号类型）。在客户端应用进行服务调用时，根据请求中的单点登录Token信息，先去缓存中读取，如果没有，再进行单点登录服务请求，然后将被调用服务对应的账号替换到请求的Header信息（去掉Token信息）中（如图6）。
3）应用系统（服务提供者）开发部分。
在本企业的应用中，根据与应用系统的兼容性，我们使用了Axis1，Axis2和JAX-WS等3种Web服务发布方法。每种服务发布方法的具体用法，这里就不再叙述了。需要指出的是，我们根据SOAP请求的Header信息，开发了账号获取Handler。这样，在服务（函数）的实现内的任何地方，可以直接使用该Handler获得服务调用者在本系统中的账号。这样，不但可以满足服务调用的业务要求，而且可以使用原系统的安全机制对服务调用进行安全检查。
到此，跨应用系统的服务调用就如同在应用内调用一样了。C/S架构应用系统的服务发布，可以通过DSS产品（因未涉及更多开发，本文不再叙述）进行。这样，基于单点登录和企业服务产品，就实现了应用系统对其他应用系统的服务、数据的直接调用。
4性能测试
基于本企业人员规模，我们进行了单点登录服务器和企业服务总线都是双机集群（每台虚拟服务器的配置相当于个人PC，1颗CPU，4G内存）的性能测试。经测试证明，企业服务总线可以支持500个并发的登录操作（每次登录都进行单点登录服务器的验证请求），或支持6000以上并发的服务调用。
5结语
为了解决企业内部信息资源并存，业务、数据跨平台协作困难的问题，本文对“信息孤岛”的解决方法进行了研究，提出了解决该问题的4个步骤。同时，结合本公司的实践，论文介绍了基于CAS、WSO2的ESB和DSS等产品的二次开发，进行企业应用集成的实现方法。实践证明，这不仅使得应用系统间的业务、数据的共享调用与应用内调用一样方便，而且符合原系
统的用户权限管理机制。这些应该对其他公司的应用集成实践有一定的参考价值。
“信息孤岛”问题的彻底解决，还有大量的工作值得研究。完成以上4步，只是说在技术上可以做到该问题的解决。除此之外，企业需要进行业务优化、管理提升等多方面的同步跟进，才能彻底解决“信息孤岛”问题。
