|
锁定老帖子 主题：关于工作流引擎的问题！
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-04-30
我也来关注一下，感觉工作流引擎却是比较重要
|
| 返回顶楼 | |
|
发表时间：2005-04-30
cyberwjw 写道 我也来关注一下，感觉工作流引擎却是比较重要
拜托，以后这样的帖子，不要再发了，毫无内容，纯属灌水。 下次再遇到这样的帖子，立删！ |
| 返回顶楼 | |
|
发表时间：2005-05-03
以偶的经验来看，1人开发一个基本的工作流引擎需要6个月，能够支持特复杂的流程再加6个月。加上设计器，监控器等GUI可能还要再加3个月。一般是拿开源的来改，比如我们用enhydra shark，它完全按照wfmc标准开发，而且做了很多模块的反射配置，方便拆卸，经典案例是把数据库管理由DODS改成Hibernate。
BPEL没用过，不予评论。 光有引擎没用，要考虑在什么地方调用引擎API(主要是业务逻辑处理完之后)，如何与表单、查询列表结合，组织结构，权限设置等等。 感觉目前工作流引擎产品的第一轮蛋糕已经分得差不多了(国内公司10+，国外公司4+，04年底的数据，相关数据所在论坛已关闭)，再做引擎开发可能要做好打价格战的准备。 可能接下来比较需要具备将工作流引擎和其他模块整合的技术。 |
| 返回顶楼 | |
|
发表时间：2005-05-07
结合实践我们多讨论一下基于企业应用的工作流技术，提提这方面的需求和功能看。我先说以下几点：
1. 人工步骤、自动步骤、定时步骤。 2. 同步分叉和选择分叉，多用户接收，多用户接收占用策略。 3. 聚合Or和聚合All。 4. 安全退回，安全终止 5. 接收者实现可配置，也可以由客户端程序自定义。 6. 接收者委托机制。 7. 工作日机制。 …… |
| 返回顶楼 | |
|
发表时间：2005-05-17
从技术可行上说说我的看法：
我现在使用的技术如下： BPEL做业务流程建模，并依赖WEB SERVICE发布服务，生成相应的服务代理 WEB SERVICE描述流程控制 使用MVC架构构建J2EE架构，在控制层引用业务流程的服务代理，并做事务处理。 可以参考如下框架： 优点：可以在多个异构应用间（伙伴）重组业务流程； 本人已经使用WebSphere做中间件服务器，以STRUTS（ACTION当中引用服务代理）+SPRING+HB,已经测试通过。认为是一个可行的技术实现，也是一个成熟、容易理解的操作，很快将会伴随着WEB服务的一起火热。 |
| 返回顶楼 | |
|
发表时间：2005-12-26
凤舞凰扬 写道 如果一个纯粹的工作流引擎，那么按照工作流联盟的方式分析、设计处理，也并不难，去年我所在的公司也做了一个，我参与其中，当时我们绑定的应用是OA的公文流转。
为什么工作流出现了这么久，在国内并没有多少成功的案例呢？其实问题并不是出现在工作流引擎多么难，而是在于流程的定义。在国内，几乎每一家公司的业务流程都是一种活性的流程，人控制的因素太多，这个时候，就很难用工作流系统去处理其了。比如说，我后来参与了一个订单处理系统的分析，业务非常复杂，每个订单在确认后，还有unConfirm、Revise功能，其实从准确的意义上来讲，这个就不符合流程控制了（因为它是由人进行控制）。 所以说，工作流系统一般只适合于能用固定流程描述的应用。当然，也许因为我的才疏学浅，不知道而已。 至于Struts什么的，一个是Web控制层，一个是中间件，两者是没有任何关系的，当然可以绑定。 没有办法的事情 老外用流程规范业务 中国要流程迁就人和业务，能用就怪了 但是客户指定要工作流。。。。中国IT，嘿嘿 |
| 返回顶楼 | |
|
发表时间：2005-12-26
likeblood 写道 我也是给oa做引擎的，不过在我看来，引擎根本不能称之为引擎，也许是我的用户要求问题吧。工作流应该是自动流转的，但是我们做的根本就不需要，全部是人工在选下一活动和处理人，我不清楚是不是所有的用户都是这样的要求，至少我现在做的就是这样，后来想想，我的工作流引擎最终被使用的意义仅仅是给选择处理人时设定了一个范围，也就是performer标签定义的那个id而已，其他的都是没意义的东西
hand，我对工作引擎的理解也是如此，这样才比较符合真正的工作流。 工作流不是生产流水线 ：） |
| 返回顶楼 | |
|
发表时间：2005-12-28
戏说乾隆 写道 likeblood 写道 我也是给oa做引擎的，不过在我看来，引擎根本不能称之为引擎，也许是我的用户要求问题吧。工作流应该是自动流转的，但是我们做的根本就不需要，全部是人工在选下一活动和处理人，我不清楚是不是所有的用户都是这样的要求，至少我现在做的就是这样，后来想想，我的工作流引擎最终被使用的意义仅仅是给选择处理人时设定了一个范围，也就是performer标签定义的那个id而已，其他的都是没意义的东西
hand，我对工作引擎的理解也是如此，这样才比较符合真正的工作流。 工作流不是生产流水线 ：） 这样理解太片面了吧？！偶目前在修改OSWorkflow来适合公司的需要，在我看来选用工作流产品，需要考虑两个问题： 1。工作流在应用中的位置 2。工作流的表现形式 问题一：工作流在应用中的位置 1。以工作流为核心，是工作流"拉"应用 2。以工作流为模块，应用"推"工作流运转（你们的OA估计是这样的类型） 那么采用推、拉都要看具体的应用，如果你们的应用开发是后期采用工作流，这个时候工作流更像是一个模块，采用推的模式也许更适合一些；而OA这样的应用也许更应该以工作流为核心 问题二：工作流的表现形式 至于将工作流作为独立的应用、模块、服务或者其他什么类型，都仅仅只是工作流的表现形式而已，在确定了工作流的位置就可以考虑它的表现形式了。 |
| 返回顶楼 | |
|
发表时间：2006-02-23
我最近也在做工作流的东西,麻烦楼主可否把你做的那个东东贴出来,让我看看!谢谢!
|
| 返回顶楼 | |
|
发表时间：2006-03-29
WORKFLOW 主要是熟悉业务流程，开发起来一点都找不到面向对象编程的快感：（
|
| 返回顶楼 | |
