目前主要列出?3家公司，q几家主要是做workflow的。当Ӟ目前国内做OAQ做PlatformQ包含workflowQ的公司很多Q但是，在workflow斚w非常专注的，比较?br /> q有很多公司没有列出来，主要是个人感觉他们在workflowq一个方面ƈ不是非常强劲Q可能他们的productQplatform很好Q，比如QBOSQ金ӞQEOSQ普元）QGK-WorkflowQ北京点ȝ技Q，iOffice.netQ广州红帆）QKA-2Q北京科诺）QOW4JQOracle中国Q，UAPQ用友）QHotOAQ上华炎）QZoTnQ中唐）。还有些型的工作流产品公司Q品ƈ不是非常有特Ԍ也没有列出来Q比如：WiseFlowQ上L泎ͼQaoflowQ北京奥宝）
目前我所知道的，在国内比较有名的国外workflow/BPM 厂商Q主要有三家QUltimusQ较早进入中国）QBusinessWareQ北京麒麟，国VITRIAQ?2003q进入中国； webMethodsQ?003q底在北京成立办事处)
以下?#8220;?/span>”表示可workflow参考度和可研究度，多表示产品在workflowq一斚w更有特点。注QBusinessWare只给了三?#8220;?/span>”Q是表示其所定位在解x案和目实施Q整个品定位在Business Process Integration层次Q有些超目前国内市场需求?
|
~号 |
|
|
|
|
I00 |
★★?span lang="EN-US"> |
AWFQ北京炎黄盈动） |
嵌入式的工作^収ͼ功能不是太完善，主要研发实力不 |
|
I01 |
★★ |
DLFloQ上东兎ͼ |
2000开始做工作^収ͼ2002q推Zjava版本。但整体来看Q发展的不是很理?/span> |
|
I02 |
★★★★?span lang="EN-US"> |
LiveFlowQ上东兎ͼ |
?/span>DLFlo定位差不多，都面向二ơ开发^台。但是正个品还是停留在“workflow”功能层次。—?/span> 但是Q吸收了DLFlo的很多经验，所以其工作^台目前还是属于国内前?/span> |
|
I03 |
★★?span lang="EN-US"> |
BusinessWareQ北京麒麟远创） |
主要方向?/span>BPM?/span>BPIQ业务流E整合）。整个品是一?#8220;集成q_”?/span> |
|
I04 |
★★ |
e-cologyQ上h微） |
但从workflowq个层次来说Q泛微没有太多的特色?/span> |
|
I05 |
★★ |
eWay PlatformQ北京东Ҏl_ |
Eway的黄金时代已l一M复返了，自动“马毅”那个团队d以后。工作流的一些理念当时还是值得的，有些cMofbiz。表单处里采用二ơ开?/span>jsp面来处理?/span> |
|
I06 |
★★?/span> |
JKCFlowQ四川金U成Q?/span> |
JFCFlow从早期的工作品{Ud“业务基础软gq_”Q但是整个品^台目前还只能是Q一?/span>OA开发^台。在workflow?/span>model斚wq不是非常的?/span> |
|
I07 |
★★★★ |
JoinWorkQ上天际星Q?/span> |
Joinwork刚刚推出来，其开发者丁宏比较欣?/span>jBPMQ?/span>joinwork很多思想也是参考了jBPM。但功能上稍微弱了点。但是其ZSWT的设计思想很值得借鉴?/span> |
|
I08 |
★★★★ |
Koof MetaLogicQ北京世U金政） |
d推出?/span>workflow产品Q专做工作流q_Q虽然主要定位于oa和电子政务^収ͼ但工作流q一快，q是有很多克参考的功能?/span> |
|
I09 |
★★?span lang="EN-US"> |
RiseOfficeQ北京有生博大） |
当前版本riseoffice5.1Q整个工作流产品基本上ؓ“OA审批程”量n定做。其表单处里和权限控制很有特Ԍ以及审批历程的处理。整?/span>design端时采用web的，用的 addflow控g?/span> |
|
I10 |
★★★★?span lang="EN-US"> |
SunFlowQ杭州信雅达Q?/span> |
sunFlowq一两年发展很迅速，大有赶超SynchroFlow 势?/span> 其品最大的特色是采用基于域的联邦系l架构，对分布式理、运行支持较好。而且也是目前国内为数不多的可以支?#8220;仿真”的工作流pȝ?/span> |
|
I11 |
★★★★?/span> |
SynchroFlowQ西安协同数码） |
基本上非怸格遵循了wfmc的规范，interface1?span lang="EN-US">interface2?span lang="EN-US">interface3?span lang="EN-US">interface5?span lang="EN-US"> SunFlow?/span>SynchroFlow都有很多相像的地方，都遗留很多学院研I的特点Q这两个产品的最初原型都是在大学中诞生的Q?/span> |
|
I12 |
★★★★?span lang="EN-US"> |
UtimusQ国内） |
q入中国最早的国外工作品，整个产品采用逻辑的组l结构图Q工作流pȝ支持的功能也很强。其比较有特色的是其“事g条g?/span> |
]]>
|
对于BPM产品目前无公认的分cL准，如果沿用以前对工作流的分c，则可以分为生产型Q又可以再细分ؓ自治式和嵌入式两U）、管理型、协同型和专门型四大cR但q样一来，市场上主的通用BPM产品大都会被划分到生产型Q难以分辨出它们之间的本质差异，因此我们需要一U新的分cL法? W者徏议根据品内在拓扑结构的差异q行分类Q将BPM产品划分为面向引擎型、面向业务型、面向消费者型、以及对{型四大cR而一些功能较强的产品能同时支持多U拓扑结构? 面向引擎型：匚w单枪 见自性清静，自修自作法nQ自行佛行，自成佛道? 企业内的工作系l广泛采用了q种集中控制式拓扑结构，客户端连接到负责接受h的中央引擎服务器。当程上有客户端完成了dQ它会将l果发送给服务器，服务器接攉工作数据Q就开始组l下一个Q务项。大多数BPM产品都支持这U最原始的拓扑Ş式? q种方式的长处在于其单性，它得管理和控制都很ҎQ而且它对客户端的要求不高Q大多数负蝲和责任都从客L转移C引擎服务器? q种模式的缺点在于成败悬于一U，整个pȝ完全依赖于一个全能服务器。该服务器必d能非常强大，q且必须能够承受巨大的压力。反q来_q又限制了系l的可扩展性? 采取q种l构的BPMpȝ一般非帔R视用于自动型zd的企业应用集成（EAI/A2AQ和用于人工型活动的人机交互界面。有集成服务器背景的厂商往往侧重于应用集成和直通处理（pȝ到系l的交易Q，Fuego、SeeBeyond、Vitria和WebMethods属于此类。有着工作背景的厂商则往往寚w要大量h工干预的应用提供更完善的功能QFileNet、Identitech、Plexus和Staffware属于此c，q类厂商对客L面和程设计工具q行了优化，可以支持各种程的h工干预。新玩家HandySoft和Intalio则介于两者之间? 归根到底Q应用集成能力的高低是区别诸解决Ҏ的一个主要因素。如果你所考虑的应用需要相当高的集成水qI其是与多个pȝ的集成，集成服务器厂商提供的产品昄h优势Q但选择来自集成服务器厂商的BPM解决Ҏ可能意味着需要采用它们的q_作ؓ集成标准?nbsp; 面向业务型：天龙八部
时世尊Q天龙八部，四众围绕Q王及大众，五体投地Qؓ佛作C{? 许多业务程理pȝ是通过可靠消息通信实现的。消息队列技术允许系l异步和分布q行Q支持跨异构|络甚至是暂时离U的pȝ间通信。一个客LZ与属于另一引擎服务器的客户端进行协作，可以消息发送到自己所属引擎的队列中，引擎会完成剩下的实际消息转发和传递工作，q把最l的q回消息也放在发赯的接收队列中，供该客户端随时提取? q是一U多引擎的拓扑结构，可以解决许多单纯的客?服务器拓扑存在的问题Q但它仍焉用集中控制的ҎQ因Z个引擎通常服务于一大堆客户端，d只是在相互连接的引擎之间分割和协作? q一解决Ҏ的优点在于可扩展性好Q当负荷太重时可以通过d引擎来缓解。这一Ҏ的容错性也更强Q当某台引擎出现故障Ӟ其他引擎可以接管其原来的工作。另外，它可以支持更有效的通信Q因为引擎可以与客户端离得更q? q一方式的缺点在于引擎必设计得很精巧，它必L能处理客LhQ又能与其他引擎协调。它q有一点与面向引擎的拓扑类|即仍然将负荷和责M客户端改扛在了引擎服务器肩上Q只不过不光是一个引擎Ş了。另外，同时l护多个引擎也需要更多的理开销? 支持q种拓扑l构的BPM产品一般都擅长于跨企业的应用集成和协调QB2BiQ。许多BPM应用Q如支持多̎户应用处理的金融服务Q往往Z应用服务器环境。例如IBM的MQSeries Workflow的品；BEA的Process Integration。Fujitsu、Intalio、Quovadx、Savvion、Versata{厂商的产品不仅能够与IBM或BEA的应用服务器兼容Q还各自提供常见BPMlg的定制开发环境。对侧重于开发流E之间的应用到应用通信q以微Y产品Z心的环境而言Q微软的BizTalk则非帔R合?nbsp; 面向消费者型Q心心相?/strong>
昔时圣h互出Q乃C灯，后贤者差肩，乃曰l祖Q是以心心相传，法法相印? q些q_发布/订阅QPub/SubQ拓扑结构成为构建、实现和集成复杂程的抢手货Q被认ؓ是满_态需求的一U简单而有效的手段。很多强大、灵zȝBPMpȝ徏立在q种模式之上Q例如，TIBCO便一直是使用Pub/Sub方式构徏松散耦合的分布式应用的先驱。在动态演化的pȝ中应用Pub/Sub模式实现业务程已被证明相当有效? Pub/Sub拓扑l构的一大长处是无需复杂的集中式服务器和路由机制Q因为消息直接由来源发往目的地。该模式支持高度分散的业务流E间的协作? 它的q在于可~性非常有限。每个发布者只能包含有限数目的订阅者，否则会处理不q来。此外，在没有集中控制的情况下发现发布者和订阅者也很困难，因ؓ当你找不到对方的时候，无处去询问和诉说。最后，它还存在生命期的依赖性? 像抵Dƾ、烦赔甚x付处理等BPM应用q需要与程理功能紧密相关的图像处理及内容理功能Qؓ此，Plexus能把大容量文档图像处理和高度可~的程理紧密l合在一P而Identitech{厂商捆l了ZXML的电子表格和本地记录理功能QFileNet的新ƾPanangonq_特别提供了企业内容管理（ECMQ功能，能同时支持文档图像处理、Web内容理及可靠的集成Ҏ和选项。尽Handysoftq不提供本地|站门户Q也不提供内容管理功能，但却提供了与Documentum、Hummingbird、Plumtree和微软的SharePoint盔R成的功能?nbsp; 对等型：打成一?/strong>
长短好恶Q打成一片，一一拈来Q更无异见? P2PQPeer-to-PeerQ计是Internet发展的最C物，在Internet之上已经有了C胜数的资源和对等端，它们有潜力克服传l客?服务器系l的大多数限Ӟ如可伸羃性、内容可用性、计能力等Q当Ӟq也需要比单纯消息{发给所有对{端更有效的组通信机制Q因些对{端可能是在|格计算背景下分布在全球的用户和厂商? P2P模式是完全分散的Q每个结炚w被认为是一个对{端Q它会连接到一个或者几个其他的端口。如果不使用qo机制的话Q那么每个对{端都会把会话{发给盔R的所有对{端QŞ成会?#8220;z水”。所以在实际应用中，应该使用分割、投影、过滤等{略Q只与该对{端相关的流E部|在它上面，该对{端只接受从其流E上游发来的消息Q再经q处理的l果仅发送给它的下游对等端? P2P拓扑的好处在于无需集中式服务器Q允怓Q意数量的|络l点Q因为工作负荷可以在各个对等端之间^衡与׃n? 它的坏处在于有时候gq现象严重，因ؓ程有时需要在多个对等端之间协同。另外，部分低效的对{端必然影响整体的性能? ׃U院软g所和中U国际共同开发的A2E-DI支持完全分散的数据提取、{换、传输和加蝲的全q程操作。HandySoft开发的BizFlow则提供了一pd由可伸羃业务程引擎驱动的基于Web的协作工P其可伸羃性决定了它亦能应用于对等环境?nbsp; 在P2Pl构的基之上q可能出现P2P ClusterQP2P集群Q拓扑结构。它可以通过分而治之的{略解决单纯P2P模式中消息通信存在的某些问题。网l被划分Zpd集群Q每个集都了解其管辖的对等端。在每个集群中，牺牲一台服务器用于充当协调者的角色Q它知道哪个对等端订阅了q程的某个发布者，也知道远E的某个订阅者订阅了集群内部的哪个对{端Q这样就不必把时间花在那些无关的集群内部了。其优缺点与P2P拓扑大体怼? |
]]>