Shark第一印象--透明思考

Shark第一印象- -

试了一下Enhydra Shark工作流引擎，暂时还不知道如何编程使用，只有一些肤浅的印象。

庞大——比OSWorkflow和Werkflow都大了许多，概念非常完整，一时间还很难完全理解这些概念。对于OSWorkflow和Werkflow这种轻量级工作流来说，要管理的唯一目标就是流程实例（process instance），操纵流程实例的状态变迁，至于如何使用流程实例、状态如何发展，都在工作流引擎之外。Shark管理的目标要宽泛得多，比如有User和UserGroup的概念，用户必须有此角色（即group）才能涉足此流程。不知道这会不会和统一用户管理平台冲突。

标准——完全符合WfMC参考模型，并且没有任何额外扩展，采用XPDL作为工作流定义语言。标准是好事，但是对于一些比较特殊的流程，我担心它的扩展能力。比如电子政务中经常会出现一种“无序流程”（只要领导插手，就可以随便到任何位置），WfMC是否能支持呢？另外，Enhydra提供JaWE编辑器，可能是最好的XPDL可视化编辑器。

支持多语言插件——对于需要自动执行的流程，Shark允许插入多种语言的运行单元，包括Java、JavaScript、BeanShell、Python等等，相信提供对Groovy的支持也会很简单。我们自己的工作流不支持自动执行，OSWorkflow只支持简单的BeanShell（语句直接写在配置文件中）。

持久化——默认的持久化方式是DODS，这是Enhydra自己做的一个O/R mapping。原来用的数据库是HSQL，我今天尝试迁移到MySQL还没有成功，因此也不知道这个持久化机制究竟如何。另外还提供LDAP的持久化，持久化方式的移植也不知道是否困难。我相信O/R mapping基础上移植不会太难。

服务接口——可以作为应用程序的一部分在代码级集成，也可以作为外部服务通过RPC集成。Shark很重视CORBA接口，对于异构环境的集成应该是很有帮助的。这里也有一点性能上的顾虑：应用内集成时，工作流引擎和工作流实例会不会带来太大的性能开销？毕竟它给我一种重量级的感觉。

明天如果有空就继续尝试，先把应用内集成搞明白，那么RPC集成也就简单了。

- 作者： gigix 2004年04月6日, 星期二 20:48

- 评论人：xy

Fri Apr 29 20:22:29 CST 2005　

哎~,我实在是没有心情,为什么大多数中国人不认真地思考一些问题呢?

----不要叫唤, 不要不动脑筋乱开腔,也不要顶我.
我只是在认真地做,而且就在认真地做,而且还要做出来

- 评论人：leopold

Wed Mar 23 17:58:16 CST 2005　

我现在就在用SHARK开发一个系统，已经作了三个多月了，现在发现SHARK的性能真的是个大问题，查找一个用户的任务要花30秒，我们的服务器性能已经是很好的了。用的也是SHARK自己的API，不知道大家有没有遇到同样的问题。

- 评论人：maybe

Sat Jan 29 11:05:09 CST 2005　

maybe you are wrong the usermanagement is open extensible,the mapping for user and role between your own and the result of flow model can deal with intergating

- 评论人：j2ee

Wed Nov 17 14:35:13 CST 2004　

即使在一个应用中，也得用CORBA么？开销是不是太大了

- 评论人：billistar

Mon Sep 27 15:15:42 CST 2004　

持久化肯定没问题。我移植到ms sql server了，非常轻松，一点问题都没有

- 评论人：匿名

Tue Sep 21 12:35:53 CST 2004　

ddd

- 评论人：billistar

Mon Sep 20 21:14:27 CST 2004　　

os workflow 太简单

- 评论人：BlueDavy

Tue Apr 06 23:23:19 CST 2004　　

^_^.......gigix遇到的问题和我们差不多哦，政府行业的流程就是不一样，它更多需要的往往是人工干预的控制，而不象企业的流程更多需要的自动控制的功能，感觉严格按照WFMC实现的流程引擎在政府行业用来会有些麻烦，目前咱们政府需要的流程引擎反倒是简单的那种

- 评论人：Quake Wang

Tue Apr 06 23:03:31 CST 2004　　

电子政务/ OA 如果要使用workflow engine的话, shark, jbpm之类的workflow engine有点杀鸡用牛刀的味道. shark 和 jbpm都强迫你使用它的用户模型, 怎样把企业现有的用户模型(包括组织结构)映射过来是很繁琐的事情, 比如常见的OA应用中, 申请者对应的部门负责人为下一个流程的人工参与者, 使用shark 或者 jbpm都得绕一圈, 通过现有的人力资源系统, 获得用户, 再对应过来. 这还仅仅是一个简单的需求, 更不用说国内企业千奇百怪的组织结构, 以及各种特殊流程, 用wfmc 或者其他所谓的workflow通用标准去做不怎么标准的事情, 吃力不讨好.用osworkflow这种基于状态机的workflow engine反而会轻松很多, 而且它也没有强迫你使用它的用户模型. 另外纠正一点: osworkflow不仅仅支持简单的BeanShell, 还支持java class, bsf, ejb. 如果做电子政务/ OA的话, 觉得目前osworkflow是最适用的opensource workflow engine.

透明思考