谈谈工作流引擎及面向服务编程（转载来自己看的）

相信很多人对于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在内。我搜集到的材料让我确认第二派会在未来占上方，有时间大家再一起聊聊吧