相信很多人对于BizTalk Server 2004(简称BTS)都有一种误解,认为这是微软出品的工作流引擎。包括我在内,从没有进入MS以来,一直在围绕着BizTalk Server 2004做开发,而加入后,所做的大部分PoC都是基于BizTalk Server 2004的。当然,我做的都是一些外围开发,而不是一些核心性的BizTalk开发。
所谓的外围开发,就是为工作流做一些UI界面,以便驱动整个工作流能够进行下去。做得久了,经常会有一些疑问,我相信大部分做过BizTalk Server开发的人员都会遇到类似的疑问,因为在我与Partner的研发人员闲聊时,也遇到类似的困惑,那就是为什么有了BizTalk Server 2004这么好的工具,我们做工作流开发还这么累呢??很多时候,为了完成一个简单的公文流转功能,我们用ASP.NET可能几行代码就搞定了,但加上了BizTalk Server 2004后,却发现工作量成倍的增加。
经过这一个月以来,与同事探讨,终于找到了一个原因。因为我们错了,BizTalk Server不是微软的工作流引擎。这话似乎有一点惊世骇俗,但我相信,我们的观点没有错误。
博客堂前段时间一直在探讨SOA(面向服务编程),其实在我看来,BizTalk Server 2004正是为了SOA而做准备的,它是为了整合各个System的Service,而建立的自动流程功能,同时,由于各个System的Service所传递的消息的Schema的不统一,所以BTS里面提供了Mapping的功能。在BizTalk Server 2004的文档中,其功能就列了两点:(1)EAI,企业应用整合;(2)B2B的消息传送。
这种EAI的Service整合,在流程运行时,没有人为因素的干扰,没有UI的驱动,非常适合BTS这种无角色流程引擎进行驱动(BizTalk Server还是有角色的,不过非常淡化)。而类似于OA这种公文工作流的引擎,则BTS根本不适合。
前段时间,非常有幸看到了ADOBE Workflow Server的介绍(本来也想去看看点击科技王志东老大的工作流系统,可是无缘),对此我更有感悟。ADOBE的这套东西,才是真正基于公文工作流的,我们可以比较它的流程图与BTS流程图的异同。BTS的流程图更像我们的软件逻辑图,在这个图中,你很难一眼就从中找到哪个点应该是一个UI,这个UI上应该有哪些单元。但ADOBE的流程图则不一样,它每个节点就是一个UI,在这个节点旁边可以罗列一些选项,比如“同意”、“不同意”、“退回秘书”之类的,然后从这些选项到它们应该到的下一个节点间连一点线。非常清晰的就把这个工作流的UI都给清晰化了。再配合ADOBE Form Server以及Form Designer,则能够很简单的做出来一个公文工作流系统。
且慢,难道微软真的没有工作流软件吗?非也非也。加入微软之前,也很有幸接触到了Teamplate的工作流产品,这是一个微软的全球合作伙伴,它的TeamPlate产品基本上把MS的所有Server都包含进来了,比如BizTalk Server 2004、SharePoint Portal Server 2003、Exchange Server 2003,那么这个工作流产品使用了BizTalk Server 2004的什么特性呢?原来使用的是HWS(工作流服务,Human Workflow Service)。
HWS,翻开BTS的随机文档,发现关于HWS的文档真的是非常珍贵,打印出来估计不到十页纸(估计其中大部分还是HWS的UI方面的,介绍哪个按钮做什么的)。估计没有人能够看得明白,但是再去MSDN Online上找一下,好多了,因为我们发现了BTS的SDK,在Sample里面还是一些料的,不过,我估计再没有人指引的情况下,没有几个人会对这东西能够上手。
HWS,实现的就是ADOBE Workflow Server所实现的东西,但是在目前,它缺少一个Workflow Desinger的设计工具,所以会造成它的曲高和寡的局面。你必须自己手动写代码去完成你的工作流设计,虽然在SDK里面有Step By Step的指导,但似乎还是很难(想想BizTalk Server 2004本身,本来设计流程就是画画那么简单,但MS还是怕很多人不会,还提供了一个免费的Visio插件,供大家做图玩)。
可能很多人读了上面的文章,会认为我在贬低BTS,其实不然。我觉得做BTS始终是MS的大智慧所在,它早在2000年就预示到了SOA的到来。只不过由于其流程图画得那么“好看”,导致大家有一些误解,从而杀鸡用坦克,既不顺手,还劳民伤财。在SOA服务来临之日,BTS更能突显其危力。我们想想Longhorn,那里面有一个Indigo。仔细思考一下,其实Indigo的很多功能似乎与BTS有交集,所以有理由相信,在未来,BTS下一版本又有新的面貌了,至于新貌如何,还请各位看倌拭目以待。
BTW:讲到SOA,想到前段时间博客堂对于SOA中传递消息的讨论,一派人认为SOA应该只传简单类型,一派人认为SOA可以传递复杂自定义对象,甚至包括DataSet在内。我搜集到的材料让我确认第二派会在未来占上方,有时间大家再一起聊聊吧 Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=32485