我眼中的SOA，以及在实际项目中的应用经验
包包所在的Group从事的是为欧美航空公司量身打造客机管控平台的项目，有以下几个特点：
1).按照每个Team十几人的样子，整个开发Group大约几百人的样子；
2).项目投入的人力和财力都很大；
3).扩展性和重用性要求都很高；
4).根据Function的不同，各个Team的开发周期也不一样，有的甚至要几年。
5).跨平台可移植能力。之前已经写好的很多项目是基于J2EE的，现在要把它们转换为.NET平台。
基于以上多方面考虑，整个Group采用了SOA的架构。我们没有像IBM那样设计一整套企业级服务总线，而是针对具体业务具体实现，来一个需求就暴露一个接口方法。其实，说白了，就是用JavaBean封装企业逻辑，然后通过WebSevice的方式来暴露，只是.NET没有JavaBean，而是用WF工作流来代替。
说了这么多，就是为了告诉大家，SOA这东西，如果不是大规模的项目，比如说开发人数（用户人数倒在其次）、需求变更（这个倒是用户care的）、跨平台（比如说.NET的WebService如何给Java程序使用），那还是算了吧，有点杀鸡用牛刀的感觉。因为SOA中有太多的地方需要你去关注，不是说加了几个WebService把对数据库的访问放到WebMethod中就是SOA了。
SOA的概念我就不说了，反正都是书本上的东西，多少有些教条，对于入门的朋友，还是更希望看到它在项目中是怎么实现的。下面就详细谈一谈.NET项目中的企业级实施：
工欲善其事，必先利其器。我们使用的是微软提供的Service Factory。也就是Web Service Software Factory。我记得在张逸的博客上看到过只言片语的介绍：
http://www.cnblogs.com/wayfarer/archive/2007/01/30/634899.html。它是作为一个插件安装到Visual Studio.NET中的，于是，作为开发者，在拿到UseCase后，只要定制一下Request和Response消息中的实体，然后在类图设计器中把契约、方法以及参数（Request）、返回值（Response）摆放并连接正确，右键点击“生成代码”菜单，就会基于SOA架构自动为我们生成6个project，截两个图给大家瞅瞅吧（这里没敢用公司的项目截图，于是顺手写了一个ServiceFactory出来）：
1.Schema
假设有一个GetUserName方法，签名如下：
string GetUserName(string userId)
那么，我们就要在Request.xsd中定义方法的参数：
<xs:element name="UserId" type="xs:string"/>
而在Response.xsd中定义方法的返回值：
<xs:element name="UserName" type="xs:string"/>
说白了，这里就是定义xml元素和.NET的实体类型之间的对应关系。所有的学问都在这里，不熟悉xsd的要回去补课了。
很遗憾，ServiceFactory中的Schema图只有在VS2005中才是可视化的，在vs2008下只能是手动编辑，所以我是最讨厌做定义shcema的事情了，上面的代码只是string类型的，如果是自定义实体、数组、字典……
在SOA中，我们遵循为每个方法定义一对Request和Response的原则（而不是一个契约的所有方法共享同一套Request和Response）。只有这样，在传来传去的Message中，才不会有太多的信息冗余。比如说，我有2个方法，分别是：string GetUserName(string userId)和UserInfo GetUserInfo(string userId)，如果2个方法的Response定义在一起，那么不管调用那个方法，每次返回的Response，不是多带了一个string类型，就是多带了一个UseInfo类型，相应的消息（也就是xml文件）体积就会变大。
此外，Java程序是不认识.NET WebServce中的List<T>的，它只认识数组，于是为了遵守SOA的跨平台兼容性，我们在Schema中只能定义数组，即使是coding，也要刻意对集合执行ToArray方法。于是，很多人都会抱怨，在调用WebService的一方，仍然是用.NET写的，于是，我们又要把接收到的数组费老大劲转换回List<T>。——这也是我认为小型项目没必要用SOA架构的一个原因，你会被折腾疯的。
此外，虽然大多数SOA系统要求平台兼容，但实际应用中却发现做来做去竟然全都是.NET平台，而极少甚至是没有Java平台。这时候发现数组和集合的转来转去是白做了，性能受到很大影响。这种情况其实也是有解决方案的，就是先全都做成.NET平台的集合，然后哪些方法需要暴露给J2EE使用，再包一层面向数组的WebService就好了。但是，这个方案也只适用于项目刚起步一穷二白啥都没有的情况，对于从Java平台升级为.NET平台，或者两套系统都有残余物（破烂很多又不舍得扔），那么牺牲性能就再所难免了。
2.Contract图
注意到，基本上每一个方法都对应Request和Response两个Message，当然如果一个方法不带参数，那就不需要Request这个参数了。但是一个void方法呢，比如说Save？是不是也可以省略Response了呢？——NO。这就涉及到SOA架构的另一个原则：方法一律返回object类型的数组，其中数组中第一个值返回成功与否，如果成功，数组的第二个值才返回相应的结果，当然如果是Save，只需要第一个参数判断是否Save成功就够了，不用设置数组第二个值。
3.Project中的WF和Service
WF我就不多说了，Group里面好几个Team一大帮人专门就是写这个的，那个WF图中的框框线线画得不要太复杂哦，居然还打印出来比美感。我看了两眼就烦了，毕竟我是做Silverlight的，只负责调用这些service。但是包包有时候也要写一些Service Factory。为什么呢？因为Silverlight是跨域的，所以需要在service添加跨域文件。但这是SOA啊？写WebService的人可能和你不是一个Team的，他不可能修改他的project来满足你的额外要求，或者，这个WebService是用Java写的……没辙了么？还有最后一招，就是自己再写一层WebService，并添加这个异步文件，并在其中调用原有的WebService，然后我的Silverlight再调用自己写的这个WebService。
嗯，如果说什么是SOA，那上面这个就是活生生的例子了——松耦合，使得A不必直接调用S，A可以先调用B，然后让B调用S。
可这也暴露出SOA的另一个缺点——部署麻烦。比如说，还是上面的那个例子，由原先要部署一个Service，变成了要部署两个Service。就是说，我要在ReleaseNotes里面添加这一笔配置信息。如果这个Service被部署在其他Server上，那么我就要准备好几份ReleaseNotes。要知道，部属的事情不一定是开发这套code的人去做的，所以WebService的多少和出错的几率是成正比的。
SOA中部署的复杂，导致了一旦其中有一个环节出错，就摸不着头脑找不到是那一层的问题。于是我们要添加异常处理机制，把异常从底层到高层逐层往上冒。所以，对于一个Service方法，返回的不是成功执行后得到的string或int，而是一个object数组。第一个参数表示成功与否，如果是否，那么第二个参数就要传递捕获到的异常信息。
另一个排查Service异常的方法就是借助于SoapUI这个工具了。这是用Java开发的unity，我们指定WebService的地址和要调用的方法，然后把一个消息的XML文本填进Request中，就可以获取到Response了。当然，如果获取不到，要么是Request写错了，要么就是这个Service有问题。这个是需要足够的耐心的，哈哈，我对面的老兄就是做这个的，反正我是没有这个耐心的。
最后说一说SOA的坏话：
刚才字里行间提到了一些SOA的缺点，一是部署麻烦，二是为了平台兼容而牺牲的性能。
此外，在SOA的每个Project中，都存在两套实体，一套是调用上一层WebService时产生的代理，另一套是这project自己的实体逻辑。这就会导致在同一个类中同时面对两套类似的实体，不仅仅是类似，有时候连类的名称和成员都一样。但是由于它们属于不同的namespace，所以我们在调用WebMethod后，立即要做的就是进行二者间的转换。在接受数据时，把上一层实体转化为本层实体，在发送数据时，又把本层实体转换回上一层实体。为了区别类的名称不同，我们在调用的时候直接在类前面加上很长很出的namespace前缀。要知道，这样的代码，可读性是很差的。
难道就没有解决办法么？
我见过有同事直接使用上一层的代理实体，而不再定义适用于本层的新实体。这样代码确实简单了不少，但是耦合性呢？完全没有了。一旦上层实体变动，那么下层也要跟着大规模变动，会导致很多不可预知的bug。——这样做是不对的。
实话实说，无解。做SOA就要面临这样的痛苦。
各位，看到以上若干文字，你还敢轻易就谈SOA么？SOA不是时尚，不是说你多写几个WebService就是SOA了。SOA是一种企业级架构，当你的项目繁芜到一定规模，当你的人力到达一定规模（一两个人多少有点扯淡），自然而然要使用SOA的架构了。这时候，把开发人员按照WebService层来划分Team，两头是UI和DB。Team直接靠Service通信，而不再是接口。而各个Team之间的边界也不在是exe或者AppDomain，而是URI（之所以不说是Server，是因为两个Service可能部署在同一台Server上，只是端口不同）。
