头发又乱了

        我部正在开发的一个新项目，选择了jQuery作为基础的Javascript函数库。同时确定了jQuery提供的ajax系列方法作为异步推拉数据的基础接口。

使用过ajax方法的同事应该是知道的，ajax方法需要提供一组选型，比如content-type、mime-type、data、async等等，这些选项的组合搭配可以构成不同的请求方式，必须理解HTTP的部分协议才能够正确的完成配置。当然，也可以从google上去找配置好的代码片段copy过来用, 关于这种方式的缺陷就不多说了。

1.      没有在代码编写之前，规定好如何利用jQuery的ajax方法。导致开发人员直接把ajax方法的调用写在页面的脚本块内，导致页面内出现了如下所示的代码：

 $.ajax({ type: "post", contentType: "application/json",datatype: "json", async: false, url: "DemoHandler.asmx/GetData",data: "{index:1}", complete: function(e, s) { alert("ok")});

       上面的代码的意图是通过http的post方法，调用服务端web services的GetData方法，传入的参数名称为index,值为1 。这是以硬编码方式与服务端达成的强耦合关系的编码方式，隐含了如下的问题：

1.      DemoHandler.asmx文件的路经改变了，就会影响页面内所有这样的代码；

2.      服务端GetData的方法签名如果变化了，就会影响页面内所有这样的代码；

3.      如果以后出现了更好的ajax框架，替换的工作量也是如同推倒重来的；

4.      GetData这样的方法如果被其他地方调用，采用的方法是copy一段这样的代码；

5.      当我们提倡前后台分开的开发的情况下，理论上前台开发人员精通的技术应该是div+css、js这些，后台开发才关注web services这样的技术。只有这样才能把各自的领域做精、最好。上面所示代码的第一个模板是我提供的，因为我个人扮演了联通前台和后台技术的桥梁角色，但反思起来他是个人行为，却不是团队力量的体现。

6.      开发人员可以自问一下，contentType: "application/json" 这个选项起到什么作用？为什么DemoHandler.asmx/GetData这样的写法可以成功调入到web services方法内部？为什么data要写成 "{index:1}" 这样的样式？我尝试问了项目组的人，答案都是不知道。很明显，真正和开发有关的只是业务，而不是这些底层协议方面的知识，它是可以对大家屏蔽的。

       当把存在的问题分析清楚了，答案也就有了。我们为每一个web serivices写一个专门的js文件，它内部封装了一组与web method一致签名的函数。这样页面只通过js方法传参数调用即可，而不再关注那些ajax调用选项的细节。达到了相关概念的逻辑统一封装和管理、一点维护多点使用、不同职责的开发人员关注不同功能这些要求。

       在这件事情的执行上，又出现了一个小插曲。负责写js文件的同学参考了其它网上牛人的js书写风格，也玩起了风靡一时的js花招—动态对象、闭包。当然很快就被否定了，其它原因不多讲，只有一点原因需要特别说明：任何编程技巧和技术的使用都要考虑它是否适合团队中的一般水平，如果不适合就要考虑其它办法。闭包显然只是一个技巧而已，不是解决问题的王道。它的引入至少给一般人阅读代码增加了难度，所以要被PASS掉。

最终还是选择采用大白话式的prototype来声明服务对象的方法。一开始，我写了一个头部的初始化函数，该函数封装好了所有的选项配置信息，以及把服务对象扩展到jQuery体系中去，使开发人员可以按照一致的规格调用服务端函数。后期，其他开发人员只要在文件的尾部按需追加一个个与服务端方法对应的函数即可。

为了利用.net script services对web services的扩展，项目组一开始规定后台直接提供web services对客户端进行暴露。这对客户端提交数据没有问题，但对我们使用的某些控件就不太适合了。因为控件要求返回值是一个纯粹的json数据，而script services框架会在输出的json数据外层再包上一个名d的根，这就导致控件无法识别这个数据源。于是项目组通过ashx文件，实现Ihttphandler来手动处理请求。

很快，服务端工程里多出了10几个ashx文件，因为客户端需要10几种不同的数据请求。每个ashx内部的ProcessRequest方法处理四件大事：1）设置WEB反馈的HTTP头信息；2）处理业务逻辑；3）序列化业务数据为JSON；4）把JSON数据写到输出流中。

这个现象说明了两个问题：1）ashx文件的数量会随着应用需求的增多而不断的增多，今后非常难以维护；2）四件事情只有一件是必须每次都做的，即处理业务逻辑，其它事件都是有规律并重复的。

基于对上述问题，项目组做出了改进，实现一个统一的WEB请求的调度和处理机制，使得同一类的请求可以放在一个ashx文件内完成，并且每个请求直接映射到一个函数来完成，输出、输出、缓存都由这个机制来处理；另外，普通开发人员只需要完成业务逻辑代码即可，其它一概不要关心。

       时间又过了2天，新的问题再此困扰了我。如果服务端增加一个新的方法，客户端的js也要与之匹配的增加一个函数作为调用代理。这样同一语意的函数，就产生了前后台两点维护，这是不合理的。它也是一个机械性的工作，每次都要开发手动来做，这也是不人性的。于是，新的解决方法是当客户端直接请求ashx文件的时候，服务端自动生成相应的客户端代理脚本。这样带来了客户端代码更大的改进，我们只需要将 <script src=”..\xHandler.ashx”>置入页面，一切就OK了。因为自动获得的js脚本会自动初始化客户端服务，后续就可以在页面的任何地方通过例如这样的方法调用服务了: $.net. xHandler.GetData()

这样改进之后，项目组的开发人员是充满喜悦的，因为他们可以少做很多不必要的事情，可以把代码写的更加整洁，可以让BUG变的更少。从此，我们也把整合jQuery.ajax和.net的技术方案固化了下来，以后团队将依赖存在的技术稳定的工作，而不再依赖个人。顺便说一句，在我们写出这些代码的时候，已经考虑过例如ajaxpro.net、.NET MVC这样的框架，只是他并不适合我们而已。

最后，附源码：WebHandler.zip

有朋友问：你为什么不使用ajaxpro呢？我有一个很简单的理由，因为我有足够的实力来驾驭目前的需求。当我发现1000行代码可以搞定需求的情况下，我是不会去引入一套DLL的，何况我也要学习它。完成此文章所提模块，笔者所花费的时间也仅仅是一个下午加一个晚上而已。我坚持一个理念：不要因为需要一点色彩，就把整个染缸都搬过来。

     5.27 日有朋友问了一个问题：如果.ashx包含了n个方法，但前端只需要一个或者其中的几个，那么现在的情况客户端都会生成包含所有方法的JS，请问如何解决这个问题？答案有三种：

1. 在脚本引用块script src 属性引用.ashx时，后面可以带上参数，如 src=xHandler.ashx?find=method&like=get*, 同步修改 GetSvr方法，使其签名为  public StringBuilder GetSvr(string find,sting like) 这样就可以获得客户端传来的参数，其中find表示按什么方式匹配方法，如按名称匹配，like表示匹配的模式，如所有get开头的方法，接下来修改该函数的内部逻辑，我就不细说了。

2.  在我的实际项目中回避了这个问题，因为我采用的是整个项目只有一个Master页面的形式，虽然开发过程中分开了不同的页面，但实际运行中，这些页面都作为web part的方式被异步获取html后，嵌入了Master的伪windows内(div实现)。所以，作为web part的页面，实际上是不需要引用.ashx的，它直接共享了Master页面已经加载的脚本。

3. .ashx是可以直接通过浏览器加载生成脚本文件的，我们可以人工下载这个文件，裁剪出需要的方法，然后手工加入到项目中，并且不再需要在script处引用.ashx了。这也是为什么每个.ashx生成脚本文件都是模板化、单层次的原因，因为这样就方便开发者自己修改这个模板，而不依赖其它。这也是本项目的潜在的最佳实践之一。

上一篇：决战Biztalk

      上一篇讲了和biztalk的决战，这一篇要讲战斗的结果啦。先引用一句本人的格言：“深入，不是为了更加深入，是为了决定该不该及时退出”。实际上，biztalk具有非常丰富的功能，可真正适合我们的功能屈指可数。这里大概说一下我们用到技术点：

• 定义消息格式，即XSD
• 画数据流程图，实际上非常简单，也就两三个环节而已
• 将流程入口发布为WEB SERVICES
• WEB SERVICE将流程激活后将收到的消息再通过调用WEB SERVICES适配器发送给其它系统
• 其它就是利用BTS提供的管理功能配置一下适配器，或者将流程打包成MSI再发布

      记忆里还能找的出来的也就这些了。那么，我们以前遇到的麻烦，甚至可以说成是苦难的原因是什么呢？实际上，我们把大把的时间都花费在了研究Biztalk平台本身上面去了。感谢我们的咨询、销售、感谢biztalk、感谢我们的团队…咱们做技术的成长全仰仗这些人、这些事了。

      我们的客户是非常高档的业主，第一，因为他有的是钱；第二，因为他的钱用也用不完，所以他可以听风即雨地认为工欲善其事必先利其器，而且要用就用最利的器。而到了我嘴里这么一说，好像又有点艺不精怪器不利的味道了。是，我必须承认我们的技术水平还是有待进几步提高的。难道咱就不能通过提高自身的水平和巩固团队积累来玩好biztalk吗？作为个人，我可以努力去尝试做到。作为团队，我办不到。有如下原因：
      

• 知识面问题：前面已经提到Biztalk实际上是综合学科，能玩好综合学科的人有几个？
• 人才问题：Biztalk不是编程语言有教科书教你，它是解决方案，要求玩它的人之前做过很多系统的设计，还要有充分的动手能力，知道大型应用痛在哪里？这样的人才市场上有多少？培育这样的人才需要多长的周期?
• 地域问题：我们所在中部发展中地区，工资给的少，有经验的优秀人才都一个劲的往北京、上海等高薪地区跑，一般我们公司拿3K的到上海至少哪8K。于是，又有几个能在我们这里守着枯灯等天亮的？
• 模式问题：我们一个近10人的维护团队天天围着客户转，他们消耗的却是新项目的利润，客户至今没有给运维增加专项费用。于是，平台越是复杂，运维方面的投入就越多，资源就越不够用。
  
        唉！一个发展中的公司的主要问题其实都通过这个项目暴露了，那就是“人”的问题。所以，在人的问题没有得到解决的之前，我只能另谋他法了。（下一章接着再讲）

       我谈通“下水道”（系列连载4）--与biztalk战斗的岁月 http://www.cnblogs.com/wzcheng/archive/2009/09/24/1573012.html

经过那次技术交流后，弄清楚了很多问题。比如，原来BTS调用JAVA开发的WEB SERVICES就是不能成功，项目组成员就用.NET写了一个程序集，BTS调用这个程序集，这个程序集内部再调用JAVA的WEB SERVICES，还美其名曰为这种方式取了个名字，叫“桥模式”。不知道的准被这个名字忽悠住了，咋一听还真是个玄乎的字眼。如果放在哪位同学的论文里出现，说不定连某些所谓的导师都一愣呢，不，不，不，所谓的导师其实就是导师！

不用我多说，很多项目的复杂性就像上述的问题一样，是把简单的问题搞复杂，再扣上个漂亮的大帽子，于是，大多数人就都相信这个项目真的就很有技术含量，能搞出这个东西人就是“床说”中的牛人，所有问题在他面前可谓是“神挡杀神，佛挡杀佛”呀。现在回想起来，也真都是“好傻，好天真呀”。为什么是“床说”，因为躺在床上说梦话呀。

可惜我不是大多数人，我也不是牛人。但我有一个笨办法：联调接口的时候让JAVA那方的人在WEB REQUEST发生的时候，把Input流拿出来解码成明文。这样就可以看到HTTP头信息，和SOAP XML了。把通过程序集调用的正确的明文复制一份，再把BTS调用发生错误的明文复制一份，两份明文一比较，差异出现在哪里，结果也就清楚了。接下来的问题就是在BTS上改一点配置（在VS的Properties Windows上改），具体改什么属性我忘记了，但无非就相当于在.NET里改了几个标记在客户端WEB代理方法上的Attribute罢了，最终的意义也就是完成SOAP约定，使发起方使用的协议符合服务端原先规定的协议就是。

于是，牛B的问题消失了，变的简单了，自此，我们得出了一个千古不变的道理”简单即合理、大道却无形、牛外亦有牛”。

这里再说说，跟上述问题相关的问题。举个例子：一条“供应商信息”是财务系统、计划建设系统、物资管理系统、采购系统、供应商评估系统中共享的数据，该信息的维护入口在计划建设系统。那么，按总线的要求，应该是【计划建设】发送【供应商】数据到BTS，BTS并行或者串行”POST”这条记录到其它各订阅系统。因为前面提到的，用外部.NET程序集调用了外部各个系统的接收WEB SERVICES这样的设计，所以实际上BTS只需要调用外部程序集的一个接收字符串的方法就好了，其他都交给程序集去处理。程序集内部的逻辑大致是这样的，把收到的字符串变成XML，再提取其中一个属性，该属性标明这条数据应发给哪些系统，程序集再根据这些系统标识分别创建不同系统的客户端WEB SERVICES对象。为了让程序更加灵活，设计者又使用了.NET DOM根据WSDL动态生成程序集的方式，这样只要在程序集的配置文件中加入各个外部系统提供的WEB SERVICES的WSDL，再添加要调用的WEB 方法就OK了。（BTY,各个系统提供的WEB SERVICES都是按甲方约定提供的，比如WEB METHOD只有一个方法，这个方法只接受一个字符参数。）

可能，不少人都会为上面的方案拍案称绝，绝在哪里？答案是显然的，牛呀，不信你瞧！连动态调用WEB SERVICES的用了上，还能不牛吗？再说了，如果以后万一多一家系统要接收供应商数据，在配置文件里加一项不就好了，你说这方案不灵活吗？说到这里，我也忍不住拍案而起，大声疾呼了…此处略去5000字。

我拍案而起不是因为喝彩，是愤怒，我大声疾呼不是为了叫好，是骂娘。您别怪说我这个人素质低，修养差，只能怪我圣贤书读的太少。不过我还真得说说我这素质低的理由，要不然还真对不起半夜起来写博客这点激情了。

第一：用.NET程序集是避重就轻的方法，是因为对JAVA提供的WEB SERVICES调用失败导致的，我们是绕着问题走的；

第二：我们当初用BTS的初衷是什么？很显然我们给忘记了。从甲方管理者决定采购BTS的视角看，用BTS是希望能从这个平台提供的流程架构图清晰的看出数据流向的，就好比用VISIO一样（实际上，就可以用VISIO画流程图导入BTS）；从BTS提供的通信端口去管理所有参与系统的位置、协议等等至关重要的信息的，这些我们都忽略了；

第三：实际上绕开了BTS后，BTS对数据流转过程也就产生不了管理的作用了，比如消息传递失败了重试功能、通过HAT查看流程目前的运行状态等；

第四：BTS的提供的BAM功能就成了多余，因为实际上流程很短，也就是走了个总线的形式，所以流程运行后的分析也就没有丝毫意义。

第五：虽说，如果不用外部程序集这种方式，那就要在流程设计的时候把所有的外部WEB SERVICES端口都添加进来。以后万一要添加一个系统接收数据，就得改流程。可是，如果一开始顺利解决了异构WEB SERVICES调用问题，那么添加一个WEB SERVICE端口就变得很快了，麻烦也就非常小了。既然麻烦都没有，我们还要那么牛的技术来做什么呢？实际上，至今没有多出什么系统来接收。

说到这里，我得总结一下架构师的能力了，说的不一定对，您大可一笑置之。架构师就像好的厨师，得对自己做出来的菜的“色、香、味”负责。一盘绿油油的青菜炒出来的楞是少放了盐，抑或是一钵子鲍汁太极羹营养的确丰富，可愣是给放凉了再给端上来，这样都不行。架构师要综合考虑技术、业务需求、客户诉求、用户要求、实施团队的能力这几个方面，拿出一套既能让甲方负责人（客户）觉得这个项目拿的出手、好向更上级汇报的方案，又不至于挖下太大的坑把自己的团队给埋了，还得让用户用起来顺手的方案。于是，架构师的定位是游离的，他游离于技术研究、销售策划、技术实施等等工作方面。（别拿鸡蛋砸我，已经洗过澡了，写完最后几句就要睡了）。

至今，我还没跟您交待我拍谁的案、骂谁吧？我拍的是自己家的桌子，骂的也是自己。为啥？没当领导就学领导样了，在项目进行时，指手画脚，实际上也没提出半句有用的意见。哼哼哈哈说了半天，虽说想把项目搞好，实际上没有半点有效的措施。改，改，改，咱一定得改，好好学习，天天向上，咱从今开始要深入技术、深入项目, 还要游离，游到客户身边，游到销售身边、游到开发身边、再游到老板身边（有何图谋？不可说…不可说）。

     话说我这个土包子进了大观园一趟后回到了公司，就开始安装biztalk2006, 照着SAMPLE开始搞，后来还加入一个biztalk组：group33022@xiaoi.com ，从这个组里获取了很多帮助。时间匆匆的过去两个多月了，那个项目也拿下了。于是带着弟兄们杀到了战场：定义XSD、提升属性、画数据流程，数据转换配置、开发自定义程序集、调用第三方WEB SERVICES、使用用数据库适配器，十八般武艺陆续登台，弟兄们在biztalk 平台上那好一顿搞呀。那时，光接口规范文档就写了上千页，真可谓气势如虹呀！当然，正是这个过程，让我非常清晰的理解了什么是ESB，一个可以称之为ESB的平台，它应具有什么功能。这一干就是小半年的时光过去了。

       不幸的是，后来上线运行之后，各种各样的问题就接踵而至，比如高可用性、性能、系统管理、在线调试等等，这让我们非常被动，也弄的措手不及。我这个人有个优点，就是爱钻研，同时也有个缺点，就是太爱钻研。爷就不服气，一个biztalk就能把我整趴下，我今后还怎么在江湖上混呀。于是，日，以继夜，夜以继，日，我开始深入研究它。终于我出关了。带着N多个SAMPLE，和一个脑图（附图在末尾）出关了。我把在biztalk上工作至少需要了解的方方面面画了一图，每一项都配备自己写的SAMPLE，并注释好适用的场景。

终于，终于我开坛设讲啦…我把项目的所有技术力量集中在公司的大会议室，照着脑图开始讲。各位看官，您别好奇，怎么没有PPT呢？ 因为PPT在我心中！ 没有金刚钻，怎揽瓷器活？不喷数小时，怎敢台上站？您说是这个理吧？正当我讲的正酣的时候，整个身子颤了一下。“不好，低血糖了，要晕倒”。我心里暗自琢磨，于是坐了下来，慢慢把话题引入到这次会议的背景上。其实我们遇到这么多问题，只因为团队整理实力还欠缺，无法驾驭BTS这批烈马而已。马虽好，但也需要好骑手才行。请允许我自嘲一下：我们这个团里不少人都不清楚SOAP到底规定了哪些事情，也不清楚什么时候用长事务还是短事务，好像不清楚反射可以做什么的人也有。我把手放在良心上发誓：biztalk绝对是个综合学科: XML，XSD，XSLT， HTTP，SOAP，NamedPipe，数字签名，.NET反射调用，ISAPI，数据库，WINDWOS群集…最重要的就是--那种经历了无数的系统整合项目后、被折磨得死去活来之后、灵魂升华之后，得到的结晶，那就是传说中的设计思想啦。在与biztalk这头倔马一起战斗的时候，你既要把自己的思想融入到它里面，又要从中吸取它的思想，当人马合一之时，便是咱超脱之日。唉！可惜在那一日到来之前，我这位骑手已经决心换骑自家的毛驴了,不是咱骑不来这马，而是这马骑着太费劲了。

其实，公司不是没有牛人，可惜牛人都在搞哲学。比如程序员到底算是技工还是技师，算是固定资产，还是低值易耗品？据说大学里只有成绩最优秀的同学才可以学哲学呢！（楼主，你就净扯淡吧！）

言归正传，其实我也在反思自己，这小半年里，并没有BOSS期待的那样，用自己的屁股给脑袋做过主呀。当然，能开这么一次技术交流会议，至少说明咱还是有点上进心的，看官您说是吧？会议一直持续到下班，等我走出会议室的时候，外面人人都在议论同一件事，这就是5.12的那天下午。

       有了这次会议，大家开始调整了很多设计，也解决了很多问题，但接下来遇到的更多的问题…

我谈通“下水道”（系列连载2） ,我谈通“下水道”（系列连载1）

到了上海才早晨5点多，打了个出租直奔美罗大厦。出租车上有点小激动，作为一个程序员，虽然去不了西雅图，能到美罗也算是和MS走近了一步，那些另外神往已久的自由、活泼、先进的气息就要扑面而来，这能不让人兴奋不已吗？下车出租车，我们几人钻进了路边的一家麦当劳，边吃早点边扯淡，等着MS上班。

         事实上，确实如很多小道消息上说，MS的会议室里总是放着新鲜的水果、诱人的甜点、还有各种饮料，心想如果我们公司也有这种条件该多爽呀，心里想着，一个阿姨推着点心车子从我身边经过，问了声我需要点什么。很显然，我已经陶醉，我什么都不需要。如果真的让我说出来自己想要点什么，那么我想要个湿巾，擦试一下我眼中噙而不放的泪花。

我们本是奔着Biztalk而去的，结果却被理解为我们需要了解BI项目的实施方法。MS的高高高级工程师跟我们SHOW了一大堆的PPT，又看了一大堆关于SSIS的SAMPLE之后，也许他是注意到了我们迷茫的双眼里流露出无限寂寞的眼神，他终于开始问我们，这些对你们有帮助吗？“哥要的不是SSIS，哥要的是Biztalk”我心里嘀咕着。我们BOSS倒是爽快，说“能不能给我们找一位精通biztalk的MCS，我们最想了解这个产品”。很显然，这位哥们脸上有点挂不住，应了声之后直接跑出去找他的BOSS去了。“很抱歉，biztalk工程师出差去了，不过我这里有BTS的限期试用版和大量的SAMPLE，需要的话我拷给你们”，那位打着领带的BOSS进来非常礼貌对我们说。我晕！得了吧，就这么着了。半个小时之后，我的硬盘里少了好几个G的空间。借来的火种是点不亮自己的心灯呀，爷回家还是好好自己研究罢了。

一个非常意外的意外突然温暖了那瓦凉瓦凉的心。SQL SERVER的研发团队的多位核心人员聚集在美罗大厦，包括他们的总经理。他们非常乐意和我们做一次技术交流。那一次，我见到了SQL Server 中国研发中心的总监孙博凯(Prakash Sundaresan)。这次短暂的沟通奠定了我“程序人生”的目标。他们一行差不多20人，很多也都是开发，年龄都在40岁左右。最年轻的是一个华人，比我也大好几岁。我们谈了LINQ，谈了SQL 2008的空间数据类型，谈了数据库性能优化，反正谈了很多。结束的时候那位最年轻的华人居然过来和我握手，说这么年轻就做架构师，真的非常意外。我的脸顿时红到了耳根，在他们面前，我只配“菜鸟”两个字。

     此行虽没有如愿以偿，好歹也是有意外收获了。至少让我看到了自己将来可能走的路——努力做好程序员，争取做到60岁。