SOA催化数据管理难题快速形成

　　由于在前一阶段的工作中，整个SOA领导小组在孙维的带领下把大部分精力都消耗在反复修改服务设计中，导致对现有IT架构的分析不够彻底。随着开发工作的全面展开，要孙维决定的事情越来越多。

　　“老孙，这个单线程的问题怎么解决？”

　　“孙头儿，这个定时运行的程序怎么办？”

　　由于老系统的某些业务功能只能通过单线程方式访问，或者原本只能在特定时间运行的应用限制了服务与应用之间的交互，孙维不得不为此伤脑筋。“先放一放，如果能用别的办法解决就用别的办法，实在不行就只能留着以后再解决。”可说归说，除了极个别的“问题”能通过对老系统的简单二次开发解决掉，其它的问题只能通过调整本就“粗制滥造”的迁移计划留待以后处理。

　　“让我们比较痛疼的是程序书写习惯的问题。”仍在新悦集团“服役”的王立回忆到，“最初的一段时间经常因为这个问题返工。”SOA所倡导的松耦合要求服务应该是独立的、自包含的，不应该或要尽量避免一个服务需要依赖另一个服务，提供的信息才能实现自身功能。但是在开发过程中，部分技术人员错误地将一些服务设计成了与此相悖的实现。例如，原来的程序会用“查询张三的在职时间以及他的业绩档案”的方式设计。而按照SOA松耦合所要求的，这个功能应该用“查询张三的在职时间，查询张三的业绩档案”这种方式进行设计。

　　“要解决的问题太多了，之前根本没想到。不过后来我发现，像老系统的遗留问题和书写习惯都还只是小问题。”随着服务开发工作的不断推进，孙维还发现不仅服务变得越来越多，连数据库也随之“丰满”起来了，“很多服务往往要调用原本存储在很多个数据表里的数据，另外一些服务又对表结构有新要求，所以每次都要为这些服务设计新的表结构。以后的数据管理会存在非常大的难度，开发工作的后期我们就遇到过一次：要修改一个数据，却发现必须同时更新很多个数据表的情况，哪怕有一个遗漏都可能给实际工作带来很大的麻烦。”

　　其实，关于数据管理的问题早已存在，一定程度上来说SOA只是加快了这一问题的显现速度。因为SOA的松耦合方式使服务看起来更像“即插即用”，这就让很多开发人员忽略了数据存储的问题。包括数据大集中概念的出现，也是一些数据库高手为了解决这个问题而提出的设想，希望通过把所有数据存储在一个大数据库中，从而降低管理难度和成本。多年过去了，实践已证明这并非一个行之有效的解决方案。东方通研发中心副总设计师刘川认为，“要从根本上解决数据管理问题必须从IT架构设计阶段入手。可以把数据也当作一种特殊的服务看待，对其标识、索引、注册。”带着这个问题，记者也采访了其它SOA方案供应商，尽管大家都推荐了类似“把数据当服务”的主数据管理（MDM）的解决思路，但是动辄百万以上的成本投入目前在国内企业中又有几家能承受的起？