Biz finally Talked

按照冯老师给我的BizTalk Server 2004培训资料，总算是完成了具有里程碑意义的一次实验：部署并正常运行。接收了几个请求，都按照Orchestrations里定义好的流程产生了正确的输出，谢天谢地。
我看的那部分资料只覆盖了开发，对安装和配置没有涉及——要么就是还没看到，好在我很熟悉NT架构的Windows系统管理etc.，还学过一阵儿win32开发，所以一些问题也用不着四处Google就能解决虽然比较“仇视”微软的东西，但是无论是刚开始自学网络安全还是后来自学win32开发，都让我对Windows有了很深入的了解，甚至是理解，至少当个系统管理员甚至是纯Windows网络的网络管理员也没啥问题，最大的问题是，我现在相当急切地想如同玩转Windows一样玩转SuSE…
言归正传，VS.Net+BizTalk SDK来开发部署在BizTalk上的应用还是很方便的，而且一如既往地visual化开发。脱离了VS多时，我都不习惯这样点来点去的开发流程了，总觉得自己的控制力下降了很多，都被可恶的IDE接管了不过RAD的这个R字可真是落实了…如果很熟悉BizTalk Server 2004，在VS.Net里面不用BizTalk SDK提供的Wizard、视图等等来进行开发和配置以及最后部署当然是没有问题，但是效率肯定大打折扣，因为要涉及的东西太多，既有Schema设计，消息映射设计，流程设计，甚至functoid的设计和使用，Pipeline设计等等等等等等，像我这样的新手来白手起家做这些肯定要累趴下最后还不见得能做出来一个可以部署上去并正确运行的组件。
在学习开发BizTalk应用并最终部署过去的过程里，我也稍微管中窥豹地揣测了一下BizTalk的架构，Adapter，Port，Pipeline，Message，Map，以及functoid，好像在其他产品或者规范中也能看到它们的影子，但是如何把这些东西组合起来，用一个合理有效的架构和运行时平台来调配它们的工作，并最大程度地简化开发流程，都是值得一个有志成为架构师的人仔细揣摩的。
最后还是要感慨一下，微软的技术水平就像大家评价的那样，肯定不是世界上最好的，微软自己的企业应用产品之间的“耦合”极为严重——当然这也是人家的市场策略——但是微软总会保证最后出货（ship）时的产品能符合大部分情景下的应用，这是和一些天才hacker们的想法比较相左的，那些天才们总是致力于提供最灵活的架构和最彻底的解耦方案，然后把扩展功能和组合组件或产品的任务留给用户（当然不会是end user那类的user了~），然而商业用户购买产品显然是图个省事儿，而并非为了给自己找事儿，在购买产品以外还要增加二次开发的投入。