小系统 大问题

这些日子看了些SOA的文章，想起了以前做BOSS项目中遇到的一件事。

一个同事正在尝使用Java开发一个东西，因为他本来是做windows C++的，对于Java并不熟悉，所以向我请教，看了这个程序觉得有些蹊跷，因为这个程序既不是web应用，也不是图形化工具，而是一个要运行在Unix下的main程序，其中还有一个没有终止的循环。详细询问，才知道原来的营业系统有一个通告功能，可以向营业员说明一些重要注意事项，其中的很多通告也需要通知代理商，而代理商系统则是另一个系统，移动的管理员不希望同样的信息发送两遍，所以让我们开发一个同步的功能。

我的这位同事选择的方法让人很奇怪。他首先改造营业系统，在信息存放的表中添加了一个字段，表示信息是否发送到代理商系统，然后又去写那个程序，那个程序会一直循环，不断检测新到信息，如果发现新的信息，就存放到代理商的数据库中。

我们的BOSS使用tuxedo中间件，在处理系统间调用时需要配置tuxedo域，而且可能代理商系统那边的对应接口也需要进行调整，显然我的那位同事对于这种方式心存畏惧，所以决定用独立的小程序解决这个问题，而无需为此大动干戈。但实际上，他的这个方式虽然不需要去配置域，可是也有很多问题。原来的系统已经有了几十个这样的后台进程，又增加了一个这样的东西，也就增加了维护人员的负担。

这样的场景对我来说似曾相识，类似问题在以前参与的工商局的项目中也遇到过，为了实现考核系统，不得不和许多小系统的数据打交道，为了应付不同数据来源、不同格式的数据，必须去实现完整的导入导出功能，很多功能解决的问题涉及的数据量非常少，常常让我们有杀鸡用宰牛刀的感觉，有时候感叹还不如让勤劳的公务员手工录入呢。即使如此有时候也难以满足客户的要求，因为客户的许多细节都在不停的变化，所以我们就要不停的适应。

我为实现这么简单的功能而劳师动众感到遗憾，但是我想已经体现出了许多传统应用的主要问题。在系统间的调用还需要配置，一旦依赖的服务发生的迁移，那么也要修改对应的配置，日常维护的代价很大。

我想这也是SOA所要解决的问题，为此我们必须思考应该如何去做。首先SOA要有适合调用的服务，这就需要规划好需要调用的服务，诸如OSB之类的产品可以将Tuxedo的服务包装成WebService之类的接口，从而可以方便其他系统的调用。SOA过程中最复杂步骤应当就是对原有系统服务的规划上，原来跨系统的调用都是相当直接的，需要什么接口就做什么接口。而SOA化的服务应该更象一门语言，每个服务应当是一个函数，经过一定的组合就能完成非常复杂的业务。但是这种改造还要受到性能的制约，我们不太可能在一些高负荷的业务中使用WebService的技术。中国移动拥有全世界最大的用户量，大多数系统已经处在并不富裕的状况，所以改造只能是从那些数据量不大的业务和外围系统上开始。而对于一些电子政务之类的系统，只是需要能够灵活的定制服务并实现调用，对于性能则没有过高的要求，它们的目标就是尽可能的让流程顺畅。

其次我们要简化维护的工作量，要将服务的地址虚拟化，这样一旦真正的服务位置发生改变我们需要做的就是把导向改变，这对于电信系统尤其重要，例如我们帐务系统，营业、代理商、客服等多个系统都会调用它的服务，在换主机或者升级的时候必须改变所有的配置，然后还要不断地测试。采用ESB之类的系统，可以让我们将许多服务用代理服务代替，就避免了对于系统间的紧密耦合，提高系统的灵活性。

有了上述基础条件，就有机会实现更为复杂的能力。还是这个发消息的例子，现代ESB一个很重要的功能就是服务的组合重编，本来只是发到代理商的消息，如果其他系统也有类似的服务，在无需改动原来服务的情况，我们就可以实现到其他系统的消息发布。当然如果工具足够强大，即使服务接口并不一致，我们也能够通过参数转化完成这项工作。

最后，我想说系统的快速应变能力日益重要，越来越多的业务需要更加智能化，实时性要求也更高，所以系统间的业务集成也更加普遍，再去添加一个个小系统去完成各种各样的集成已经不能满足要求了，我们是应该建立一个更坚实的平台去实现这个目标。

此外，这里有ORACLE最新的中间件官方资料可以下载。