我谈通“下水道”（系列连载5）--决战biztalk

       我谈通“下水道”（系列连载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端口就变得很快了，麻烦也就非常小了。既然麻烦都没有，我们还要那么牛的技术来做什么呢？实际上，至今没有多出什么系统来接收。

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

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