浅议“SOA架构下系统应用整合”（一）

 

系统整合是这几年比较火的项目，尤其是最近两年随着SOA架构思想的成熟，关于系统整合的技术理论以及思想也逐渐的丰富起来。最近也有不少的朋友问我一些SOA，ESB以及系统整合的相关问题。我将会在浅议“SOA下系统应用整合”系列文章中，逐步的谈一下我的看法。

本文是系列文章的第一篇，仅仅对国内整合项目的现状进行描述，并从项目实施的角度对一些问题进行了简单的说明，而没有涉及到用于整合的产品、技术等相关问题，在本系列的后面文章中，将会陆续介绍。

1 国内整合项目的现状

对于ESB的作用，当前业内有一个比较认同的观点：ESB的主要作用是在SOA架构下进行系统应用整合。从功能上来说，ESB与广义上的EAI解决的问题都是一致的，即通过企业应用整合，使得不同的单位间或者单位内部的不同应用系统中数据能够同步和共享，流程能够更加敏捷、合理，业务更贴合实际。最终目的都是通过整合使得单位的资源能够复用，业务成本能够减低，工作流程更加标准可控，从而实现利益最大化。

从上面的描述可以看出，一般的整合包括数据整合、业务整合、流程整合。当然在系统整合中，也存在用户与人机交互上的整合需求，使用户能够有统一的入口进入到被整合的各个应用中，包括统一的身份认证，统一的权限管理，门户，单点登录等。

虽然大家对ESB的认同存在多多少少的不同，但是在国内的ESB生态圈中，进行过ESB系统建设的实施人员或者产品研发人员，以及使用过ESB的最终客户，对于整个产品的认识还是存在很大的相同点的。对于上面提到的几点，大家还是都比较认同的。

当然了整合不一定非要和ESB有关系，只不过使用ESB是当前比较流行，比较好的解决方案而已。

前面提到了系统整合的几大目的，那么国内众多的整合项目，都处于哪个整合层次呢？就我所做过的几个整合项目来说，从哪个层面上进行系统整合建设的都有，而这种现象出现的原因我觉得有两个原因：

第一：各个单位信息化建设的程度不一致，而又存在着整合需求。有些公司待整合的系统都是最近几年新建设的，从建设初期，就考虑了扩展、整合、信息孤岛这些问题；还有的公司希望能够建设一个基础架构平台，以后所有的系统都通过该平台进行整合。那么这样的公司就可以从一个比较高的层次进行系统整合。而另外一些公司的系统，有15年前建设的系统（很多大公司使用的生产管理类似的系统），有10年前建设的系统，有5年前建设的系统……，15年前建设的系统，很难想的出来15年以后的整合需求。这类公司可能就只能从一个比较低的层次进行整合，比如先整合数据，把信息孤岛问题解决。

第二：实际业务的需要。虽然整合可以从人机交互，业务，流程，数据这几个层次进行，但是并不是所有的项目公司都需要从这几个层次上进行整合。比如说我最近正在推进的一个某省级气象局的系统整合项目，其主要需要解决的问题就是数据整合，当前的业务简图如下所示：

 

 

 

 

当然了，所有的数据都是在业务中形成的，都是由流程携带的消息。但是他们目前最关心的就是能够自动的实现已有的各个系统，上下游系统之间的数据的便捷的通信、传输与转换问题。在这个项目的一期中，他们只需要将一些主要的数据整合工作完成（当然了，规划设计的时候需要考虑二期、三期的业务、流程以及人机交互）。

除了因为单位因为实际的需要而进行的系统整合项目之外，国内还存在一类“政策性”项目，所谓政策性项目，是指项目并不是某个业务单位的需求而发起，而是由于国家的某些政策条文而实施。比如我曾经建设过的某地级市的“单位基础名录库”，其中涉及到工商局，质监局，国税局，地税局，统计局，民政局以及编制办公室，就是为了响应国家的一些政策而建设的(关于单位基础名录库与人口库的介绍，大家可以查阅相关资料)。再比如我曾经建设过的某省级“人口库”，其中涉及到民政局，劳动保障局，计生委，卫生局，质监局，流动人口管理中心，工商局，税务局，建委，住房公积金管理中心，公安局等。这些项目并不是业务单位发起的，建成后对其中的一些业务单位也没有很大的帮助作用(当然很多项目会通过在项目实施过程中，开发一些应用系统来给被整合的各个系统提供便利)。

很多人认为系统整合就是封装几个接口，就是规定几个规范化的数据格式，就是互相的发几条消息，就是…………，其实，系统整合真的不是这么简单，如果你是这么想的，那就大大的错了。

2 整合项目的常见难点

技术难

系统整合项目中涉及到各种各样的技术，这对项目实施人员是个很大的挑战，因为你不知道你将会遇到什么样的系统，该系统使用的技术也是未知的，这对实施人员是个很大的挑战。正是基于此，才出现了各种各样的整合产品以及技术理论，包括ESB，流程管理工具，SCA，SDO等等（虽然很多技术理论不是因为整合而出现的，但是他们用在整合中却是非常的合适），正式这些产品以及技术理论的出现，确实可以使你将一部分的技术难度降低，转而将更多的注意力集中到业务方面。（这里只是从项目实施的角度考虑，如果考虑到整合产品的研发，涉及到的主要技术大概有30多种。）

业务难

被整合的系统大多是不同领域的系统，你可能是一个财务专家，但是当将财务系统与人力资源系统，与电子商务系统进行整合时，你就不一定既是财务专家，又是电子商务业务专家了……。当然了，被抽象出来的，待整合的功能点可能并不要求你非得是专家才行，但是、但是、但是你至少得在该领域里面有所了解吧。

资源协调难

对于很多系统整合项目，资源非常难协调。常见的表现有两点，第一：如果你的设计方案需要对原有系统进行改造，那么恭喜你了，你的一只脚已经迈进泥潭了。程序根本没有源代码，该系统是几年前实施的，实施该系统的公司都可能倒闭了，即使没倒闭，核心开发人员肯定早就已经不知道跳槽到哪里去了。此时你只能不断的修改你的方案，直到最好找到一个可行的方案。修改到最后，项目的目标都可能已经发生改变了，没办法，如果不这样，可能等你头发胡子都花白了，项目也做不完。

第二：你需要对数据进行整合，但是如果你根本就获取不到数据，何谈整合？这种情况真的存在，虽然最后你千心万苦的、可怜兮兮的、经过N长时间，打了N个报告，做了N个方案，终于获得了一点点有用的数据，虽然与你最初的项目规划相差甚远，但是你肯定已经感觉知足了。

客户不配合

对于所有的项目来说，客户都有些些许的不配合，但是系统整合项目中会与很多的单位打交道，这种不配合就会被无形的放大。如果你所实施的项目是我前面所描述的“政策性”项目，那么恭喜你了，你遇到的难度会无限大。坐下来仔细想想，实施一个人口库项目，需要那么多的公司参与，但是实际的受益单位有几个呢？不能从中获取利益，肯定配合的不密切。如果项目的发起单位还不够强势，那么真的够你喝一壶的了。

从业人员少，技术社区不够活跃

我这里说的从业人员少，主要是指SOA架构下进行系统整合的人员少。导致整个社区的活跃度不够，出现了一些问题，你去google、baidu都没有可用的答案。社区环境不够成熟，客观上导致了项目中的某些技术难点，方案可行性等问题被放大。

说实话，做了几年的系统应用整合，尤其是从06年底开始做SOA架构下的系统应用整合，对这一点的体会简直是太深刻了，这也是我一直的推动SOA草根社区建设、发展、活动的原动力。同样，我发起国内首款开源ESB，在一定程度上也是为了推动国内ESB社区的发展，扩大从业人群，让更多的人能够参与到其中。