关于SOA的思考3：平台的设想

  系统间互相独立，和本系统不相关的业务操作均通过Web Service服务来实现，为了未来的通用性、易维护、以及扩展等因素考虑，各个系统间的Web Service服务必须定下一个通用的数据交换规范。

实现的目的大概是这样，提供一个业务服务管理系统，里面记录了各个业务系统的Web Service服务地址、调用方式和返回结果；任何需要获取其他业务服务的系统，都提供一个配置管理器，可以直接从管理系统搜索并配置所需的业务服务。

就如114台查询一样，比如114台登记并管理了各种业务公司的电话号(服务地址)以及业务服务范围(服务内容和服务方式)，任何一个客户如果想得到某个公司的服务，可以向114台搜索并选择自己需要的服务公司及服务内容(这个就是配置过程)。之后的业务活动，用户便可直接和提供服务的公司进行交互(传递服务方式参数，服务公司“调用”实际的业务服务过程，并返回服务结果)。

业务服务管理系统

WSMng

业务系统A

业务系统B

业务系统XXX

图1：

从上面看来，整个过程有两方面功能：接收别的业务系统服务，提供本系统的业务服务。

假设服务管理系统为WSMng，业务系统有A、B，可能有更多业务系统XXX，那么A系统在开发的时候，实现接收服务（蓝色线所示）和提供服务（红色线所示）的功能。后面会详细解释如何实现这些功能。绿色线表示服务规范配置信息传递，蓝色线表示最终调用关系。为什么要规范服务配置信息呢？

接收别的业务系统服务必须考虑别的系统所提供的服务方法、本系统所需传送的参数序列以及返回结果；提供服务则是个反过程，需要考虑本身能提供的服务方法、接受的参数序列和输出的结果。如上图所示，假设A系统需要某个服务方法，在最终部署的时候，A系统只知道这个方法的返回类型和调用参数，比如DataSet A.MA(int prma1,string prma2)，假设B系统提供了某个方法DataSet Mb(int prmb1 string prmb2)，其返回类型和调用参数恰好和A系统所需的相同，那么配置就非常简单，只需描述其对应关系即可，即：本地方法MA，参数序列prma1,prma2；远程方法Mb，参数序列均为prmb1,prmb2。假设C系统也有一个方法DataSet Mc(string prmc1,int prmc2)，起所示实现的功能也恰好是A系统所需的，只不过参数序列有所不同，那么就可以配置信息如下：本地方法MA,参数序列prma1,prma2，远程方法Mc,参数序列prmc2,prmc1。也就是说，配置信息必须描述了本地方法和远程方法一一对应的信息。

就如现实生活中，你想要的服务，可能很多公司都有，只不过每个公司实现该服务的所需条件不一样。假设你能提供的条件也有很多，那么你如何活得一个公司的服务？肯定会发生这个事情，就是你必须将你的条件和该公司的服务条件一一匹对，当条件满足之后，该公司才执行服务过程。这个匹对的过程，就需要一个规范来定义（在现实中，至少服务公司也需要你填个表什么的），这个规范所起到的作用，就是解释供求双方对服务要求的细节。

总的来说，如何定制服务方法、参数序列和结果的规范是必须的。

这个平台有什么好处？

SOA平台，应当最大限度的降低系统与系统之间的依赖，提高系统间信息的共享度。比如权限系统，该系统功能比较单一，无非就是人员信息、权限信息等的管理，但这些信息几乎所有别的系统都需要，也就是说，别的系统应该和权限系统尽可能的降低依赖，而权限系统尽可能的共享信息，所有权限校验的服务，都可以通过统一的接口来获取。

在信息不断的建设过程中，可能权限系统还会不断的升级，但如果保持服务的接口不变，都是WebService，而且方法也固定，那么最多就是配置一下对应关系的规范文档即可立即使用另外一套权限系统。

类似的，各种各样的业务系统之间的信息共享，也需要这样一个非常松耦合的平台，才使得任何业务的纷繁变化也不至于影响别的系统，却能确保信息最大共享。