生活就是一个谜

下面开始介绍.NET2003下，如何利用反射、AOP、以及ASMX实现SOA：

一、实现机制

.NET2003的ASMX框架提供了Web Service 反射功能，如果按照平常的引用Web Service，IDE会自动生成一个Reference .cs文件的东西，里面实现了所引用的Web Service的反射调用类。其实我们可以自己来定义自己的反射类，来实现动态调用Web Service。比如直接建立一个类似Reference.cs文件的类，将里面的Web Service地址(服务地址)等当作参数传入（如虚线所示），实现动态绑定Web Service。然而有几个地方需要注意的：由于用了反射，每个Web Service方法的映射必须提供方法名、参数序列以及返回结果类型，特别是要考虑通用性时就得非常小心处理。但是，我们也应看到这个方案的优点，试想一下，各个系统提供的业务服务千差万别，服务地址、方法名、参数序列和返回结果都不可能相同，居于此方案，使该反射类能够尽可能的包含了各种业务方法的情况，从而实现反射的稳定性和适应性。

业务服务管理系统 WSMng

业务系统A

业务系统B

业务系统XXX

映射类

WS

WS

映射类

WS

映射类

图2：

首先要考虑的是，必须为各个业务系统统一Web Service命名空间（该命名空间和类的命名空间含义是不一样的，可以参考MSDN帮助文档），在发布Web Service时，可以通过System.Web.Services.WebService属性来制定命名空间。对于一个开发商来说，当然能够自己定义自己的命名空间，这也不是什么难事，因此在规划面向服务结构体系时，应统一服务命名空间。对于不同的开发商来说，那就没办法了，只好为每个开发商来映射，当然这也是情理之中。

定义了服务的命名空间，则在反射类在反射Web Service方法的时候就方便多了。我们假设本公司统一定义面向服务体系结构的所有Web Service命名空间都为Company.WebService(此命名空间在映射类中需要用于描述http头，用于定位WebService，比如基于此命名空间，Company.WebService/GetServiceData则映射到方法GetServiceData，亦即SOAPAction定位)，并开发和部署该Web Service服务。那么下面我们就应该考虑服务方法的实现了。

二、服务方法定义

接着考虑为服务方法定规范。由于服务方法必须要能够通用，因此方法名是必须预先定义的，而且只有一个；返回结果用最通用的DataSet返回，参数序列我们也用DataSet来传输。为什么要考虑定义一个唯一的服务方法，因为在反射机制之中，每一个方法的反射都必须提供方法名和参数列，如果业务方法很多而且不断的扩展，那么反射类也必须相应的修改，这使得通用性、维护性上变得非常差，不可能因为每上一个系统都要修改以前系统的代码来重新反射新的业务服务。为什么考虑DataSet，因为DataSet最容易封装和序列化，同时输出XML也非常容易，为了以后扩展成XML通讯十分便利。

假设当前Web Service服务xxx.asmx有如下的方法：DataSet  CallServiceMethod (DataSet)，用于获取当前服务业务的所有功能；DataSet GetServiceDetail()则是将当前有关业务方法(非Web Service方法，而是Web Service需要调用的其他业务方法)的信息按照规范提供出去，这些规范预先定义好的。因为Web Service的主要方法只有CallServiceMethod，所以只能通过参数的不同在后台用不同的业务方法处理，而参数和这些具体业务方法也必须能建立相应的对应关系。接下来的关键，就是要提供一个能够解释输出结果、参数序列的机制。注意，当其他业务系统需要用到当前业务系统的服务时，它必须利用已开发的反射类来调用，并且将当前服务的地址传入(动态调用，图2所示)。

业务系统A WS: xxx.asmx

M1业务方法

M2业务方法

M3业务方法

CallServiceMethod方法

GetServiceDetail方法

图3

由于实际应用中，输出结果和参数的变化性比较大，可能是基本数据类型，也可能是数组、结构、对象等等，因此我们要对输出结果和参数要定一个说明书。说明书的DataSet（含结果DataTable和参数DataTable描述）将会解释了输出结果的所有信息结构，并能保障别的系统能拿到该说明书就知道用什么内容的参数调用CallServiceMethod，输出的结果是怎么样的，包含了什么，并能够转换成实际类型的结果。

为什么要用这种规范和对应关系，主要是为了考虑业务系统的后期绑定，开发时可以不用考虑最终的实现到底使用哪个Web Service，在实际应用的时候才配置绑定，虽然这个绑定需要手工配置（后面会详细解释），但对于业务的独立来说，仍然有价值。

三、说明文档获取方法定义

下面讨论这方法参数和返回结果两个规范的问题，也就是如何定义和解释这个说明书DataSet：含参数DataTable（可能多个）和结果DataTable。这些数据都通过GetServiceDetail（）方法来获取。

首先，我们预先定义好规范。规范的说明文档记录方式：WSURL、明书DataSet。WSURL用于定位远程方法CallServiceMethod所在的WebService服务地址；参数DataTable用于记录该WS服务具体的业务方法，主要字段有MethodName、ParameterName、ParameterType、ParameterValue、Description；结果DataTable记录每个业务方法的返回结果的数据结构，主要字段有MethodName、ResultType、ResultValue、Description。在业务服务管理系统之中，相应的有一个存储规范的数据表，数据表保存URL和这个明书DataSet的XML描述，并且提供获取规范的方法(也是WS服务方法)。每个业务子系统（比如A）都需要在发布的时候调用该方法(GetServiceDetail方法实现) 获取规范信息，并用规范信息来解释业务子系统并形成说明文档，然后将说明文档发布到业务服务管理系统之中。或者通过业务服务管理系统自动询查注册在线的各个系统的说明文档。

业务服务管理系统WSMng

业务系统A  WS: xxx.asmx

DataSet GetServiceDetail()

说明文档管理

发布说明文档 PublishServiceDetail(WSMngURL)

GetMethodDetail (当前服务类))

图4：

DataSet GetlMethodDetail(typeof(当前服务类))将获取当前服务所有业务方法的规范文档的整理，该方法利用自定义属性和映射的机制来收集当前服务的各个方法参数信息、结果信息，并封装成说明文档DataSet（包含含参数DataTable和结果DataTable）返回。

假设A系统有M1、M2、M3三个业务方法分别为：DataSet M1(DataSet Pa, int Pb)、bool M2(String,String)、void M3()，则说明文档DataSet应该如下：

方法的的参数表：MethodDetail

其中Mn表示实际的业务方法，如图3所示。

结果表：ResultDetSail

说明书的传递方式，我们可以用一个固定的服务方法传递，比如DataSet GetServiceDetail()，该方法返回当前Web Service服务所有方法的说明(包括结果、参数)。

四、服务方法实现

好，接下来介绍如何通过WS服务方法调用业务方法。

业务子系统WS服务方法DataSet CallServiceMethod (DataSet)用于实现调用业务方法过程。要理解的是，WS只发布了WebMethod：CallServiceMethod，为什么没有发布其他业务方法，请参照第二节服务方法定义。服务方法基本上就是将参数DataSet按照自身的参数说明文档解释成实际的参数，再根据这些实际的参数进行相关的业务操作，然后将业务操作的结果按照结果说明封装成结果DataSet输出。

业务系统A WS: xxx.asmx

参数PramDataSet

DataSet CallServiceMethod (PramDataSet)

M1

M2

M3

DataSet CallMethod(typeof(当前服务类), PramDataSet)

图5：

其中DataSet CallMethod(typeof(当前服务类),DataSet)将实际的参数转换，并能根据参数DataSet调用真正的业务方法(M1~M3等)，将结果按照规范封装输出。

其调用过程实际用了反射的原理，因为参数已经提供了方法名、方法的参数内容，所以利用反射可以调用相应的方法。

XXX.asmx实现代码片断：

……

         [Nontriv.Attribute.WebService.ServiceMethod]

         public System.Data.DataSet M1(System.Data.DataSet Pa, int Pb)

         {

              ……

              return ds;

         }

         [WebMethod]

         public System.Data.DataSet CallServiceMethod(System.Data.DataSet parameter)

         {

              Nontriv.WebService.Reference.Criterion criterion=new Criterion();

              return criterion.CallMethod(typeof(WebServiceTest),parameter);            

         }

……

其中WebserviceMethod为自定义属性，标记该方法为Webservice的业务方法。Criterion为规范文档类，用于收集当前WS类的有WebserviceMethod自定义属性的方法详细信息，并提供CallMethod方法调用业务方法。

五、服务管理系统

Now，我们已经实现了一个业务服务系统的基本功能，已经包含了如何制定服务，将服务发布到服务器，如何接收参数和返回结果。

下面讨论一下服务管理器如何实现管理这些服务，并能够很方便的给别的系统查询和配置。

和服务管理系统相关的最重要的就是说明文档管理系统了，其实这个说明文档管理也是一个WebService服务，不过由于这个服务比较特殊，没有涉及到客户的业务，因此这个服务是固定的，而且服务的方法也是固定的。

业务服务管理系统WSMng: xxx.asmx

QueryWS(WSURL)

AddOrUpdateWS(WSURL, DataSet)

其他管理

业务系统A WS：xxx.asmx

GetServiceDetail

PublishServiceDetail

说明文档包含了各个注册业务服务的规范说明，包括WS地址、包含方法参数和结果的说明文档DataSet。其主要功能是提供查询，便于配置本地方法和WS业务服务方法对应，同时还为以后执行一些任务式的调用作准备。比如可以让业务服务管理系统定时调用某个业务服务的某个方法。

发布到服务管理器有两条途径，一是通过在服务管理系统中输入业务服务WS的地址，系统将自动询查业务服务系统的所有业务方法及输出结果的说明；另外一种就是业务系统输入服务器地址，业务系统将自动将自己的说明注册到服务器。这辆条路径都需要人工操作，目前还无法实现自动询查和注册，主要还要考虑路由等，比较难实现。

六、调用服务和接受服务结果

最后考虑如何接收服务以及处理服务返回的结果。

调用方和服务方类似，也就是将参数通过将调用参数说明构造成DataSet，然后调用DataSet CallServiceMethod (DataSet)，再利用结果说明将结果解释出来。注意的是，这里的CallServiceMethod是本地对远程WS的反射类，记得前面我们介绍过，WS的反射必须方法名字、参数序列等必须要一致。

在些调用WebService业务方法时，必须要准备这两项重要工作：获取到映射类，用于将WebService类映射到本地类，并通过动态配置WSURL来实现动态调用业务服务；AOP面向方面框架，用于捕获本地方法调用参数，并将这些参数提取出来，并用于映射类调用远程服务方法时所需的参数拟定；和服务方一样，也需要一个能够获取到本地方法的说明文档，这些说明文档表示了哪些方法需要调用远程方法，以便后期可以根据这些信息来绑定具体的WS方法。

参数对应配置，由本地配置并保存在本地XML中。保存字段主要有：WSURL、WebService业务方法及参数序列、本地方法及参数序列。这个配置过程，是由手工配置的。可以通过在业务管理系统中查出WebService以及其说明文档，用户再根据本地开发时的调用方法的参数文档进行一一配对。

举个开发例子。

比如在开发某业务系统时，我们需要用到权限验证，在权限验证的方法中，我们实现如下：

     [Nontriv.WebService.AOP.WSAOP]  

     public class ClientOfWS:Nontriv.WebService.AOP.WSCountexBoundObject

     {

         [Nontriv.Attribute.WebService.ClientMethod]

         public bool HaveQX(string Name,string qx)

         {

              return (bool)reflect.GetData(this.GetParamDS());

         }

     }

和WS服务实现有点类似，其中Nontriv.WebService.AOP.WSAOP表示该类自定义了属性，也表示了该类实现了AOP框架（继承了Nontriv.WebService.AOP.WSCountexBoundObject）。

由于使用了AOP框架，方法在调用时捕捉到实际的调用参数，并根据说明文档格式将参数转换成DataSet(包含了含参数DataTable和结果DataTable)，如果参数是DataSet，则将该DataSet的数据表一一拆离，并复制到说明文档的DataSet之中，并标记它是属于哪一个参数的。这些参数信息，我们用this.GetParamDS()来获取，有点像获取当前上下文对象的信息，不过这里面的实现是结合了AOP框架，使用了Remoting的上下文消息监听机制。

HaveQX方法的实现，我们只用了WS映射类的一个固定方法GetData，此方法封装了之前我们讨论的CallServiceMethod方法（asxm的反射方法，用于反射远程Webservice的CallServiceMethod方法），由于CallServiceMethod返回的是一个封装了结果的DataSet，因此GetData方法还需对结果进行转换。另外，此方法还根据配置情况对实际参数进行转换，后面会介绍怎么转换。

this.GetParamDS()得到的数据大概如下(DataSet数据结构参见规范及说明描述)：

MethoDetail表：

ResultDetail表：

假设我们需要将本地方法HaveQX和前面所定义的远程方法M2绑定，配置文件如下：

<PrmDataSet>

 <PrmDataTable>

    <LocalMethodName>HaveQX</LocalMethodName>

    <LocalMethodPrm>Name,qx</LocalMethodPrm>

    <WSURL>http://……/XXX.asmx</WSURL>

    <WSMethodName>M2</WSMethodName>

    <WSMethodPrm>Pa,Pb</WSMethodPrm>

 </PrmDataTable>

</PrmDataSet>

这个配置文件表示本地方法HaveQX调用了某个WebService业务方法M2，在调用过程中，将HaveQX的参数Name传给M2的Pa，将HaveQX的参数qx传给M2的Pb。配置过程的大概是通过配置页面进行配置的，具体做法大概是用户得到了业务服务管理系统的注册服务信息，将它们列出来，用户经过选择并配置到本地的业务系统方法之中。

经过上面配置后，则反射类的GetData方法会跟据这个说明文档将参数转换成如下参数数据：

MethoDetail表：

ResultDetail表：

本地调用方法的参数传送到远程WS的CallServiceMethod方法之后，CallServiceMethod调用了 CallMethod，该方法根据参数表调用具体的业务方法，并将结果填充到ResultDetail表。如果返回结果是DataSet，类似的也会将DataSet里面的表拆离并复制到CallMethod返回结果的DataSet之中。

之后的事情就是将这个结果返回给客户端，再由客户端根据结果类型来转换远程所返回的DataSet里面的内容。

综上所述，本文已经从各个方面描述了WebService实现SOA平台的基本功能，但也有一些缺陷在里面：规范定义和说明文档并不能描述得了所有参数类型和返回结果，特别是DataSet的情况。在实际的处理DataSet，基本上都是需要知道列的信息，而本文并没有好办法通过规范和说明并无法描述列的信息（包括列信息的映射和数据的映射）。此外对于非序列化的数据也不能很好的支持，比如参数或者结果如果是ArrayList、HashTable的情况下，则无法传送。

此外本平台的实现肯定还有很多劣势，其中关于AOP的实现就不是很理想，需要利用到.NET的Remoting消息监听机制。另外对于传大数据来说，本平台还是显得不适合。

  系统间互相独立，和本系统不相关的业务操作均通过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，而且方法也固定，那么最多就是配置一下对应关系的规范文档即可立即使用另外一套权限系统。

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

      信息化建设越来越成熟，但由于过去的建设手段，软件开发手段不尽相同，技术手段、开发理念也参差不齐，面向过程、面向对象、COM、CORBA、组件化种种技术，软件系统也有产品式、项目式等，然而很多这些技术和项目，都是解决一个方面的问题，这对于我们这个社会主义社会结构、各行各业的业务结构来说，都只能解决某个局限的问题。社会是不断进步和发展的，业务也是一样，其中的种种关系千丝万缕，等你回头一看，你就会发现原来我们很多东西只做了其一，还有更多东西原先并没有考虑到。
    简单说个例子。人员/权限系统大家都做过，而且还可能每个业务系统都做过。但实际上，在现实的社会结构中，某个单位的人员/权限系统本来就不复杂，张三只有一个，李四也只有一个，张三在A业务的权限只有一套，在B业务的权限也只有一套。哪为什么就不能统一一套权限系统，里面记录张三在A、B业务系统的权限，或者未来更多的XX业务系统的权限，并为这些系统提供权限校验服务？或者是否我们一开始就只认为，我开发A系统的时候，只考虑A业务，谁管他B还是XX业务的东西。如果现在还是这样子考虑问题，那你就too naive, too out了！
    面向服务，更趋向于将业务结构抽象化，而不是简单的对象抽象化。天气预报、权限查询都同样是一种业务性很专一的系统，单和这业务相关的其他业务却千千万万，如何更好的抽象这些业务，使之更好的为过去、现在、将来的系统作出自己最大的效益，那就得用面向服务的思想来指导我们的问题考虑。
    现在实现面向服务的技术也越来越多，然而最让人关注的还是WebService，尽管SOA!=WebService。随着微软的Indigo推出，我想SOA在微软框架下的实现也越来越成熟，越来越有效率。
    未来会是一个什么样的软件结构呢？对，卖的就是平台；面向的就是服务。软件越来越趋于社会描述，对社会的体现也越来越成熟，而不再是简单的一个个对象的抽象和实例化。试想一下，以后的所有信息处理，都有可能被别人实现和共享，而你要做的，就是怎么样合理利用者些信息去处理你自己的业务。当然这个伟大的理想，恐怕不是一两年就能实现。但我想未来的信息化，应该无处不在，服务无处不在，你可以在你办公室的电脑桌面屏幕摆下你家里的信息收集（冰箱运行情况、监视器运行情况）、你需要处理的公文信息、天气预报……，还可以设定当天气为下雨时，你家里的窗户会自动关闭。

    美好的世界，SOA，面向服务，面向社会！