胡长城(银狐999)BLOG

专注SOA,MDA,EAI,BPM,工作流,J2EE;个人主页http://www.javafox.org

胡长城ID:james999
549445次访问,排名71好友0人,关注者49
J2EE,Workflow,BPM,EAI,SOA,工作流
james999的文章
原创 185 篇
翻译 0 篇
转载 2 篇
评论 620 篇
银狐999的公告
个人主要工作流文档可从 javafox live网络硬盘下载

最近评论
shendl:胡兄现在在国内公司吗? 什么公司,什么Workflow产品吗?
subarasiyi:不知道楼主是否听说过Interstage BPM?
这个在Gartner的评价中也是非常高的
friendoyc:这个可能是自动回复,不是Layna Fischer回答你的问题。
friendoyc:可以在b节点处加个判断条件,如果b成立则a-c-b-d,如果b不成立则a-c-d
friendoyc:可以在b节点处加个判断条件,如果b成立则a-c-b-d,如果b不成立则a-c-d
文章分类
收藏
    相册
    50 Relational Blogs
    Hongsoft博客
    J2EE与ERP禅话
    Peter's Blog
    俠盜躶奔漢
    切尔斯基(RSS)
    动物园的猪
    胡奇
    赵斌BLog
    阿飞外传
    55 Workflow Preacher
    Ekkart Kindler
    Michael zur Muehlen
    Wil van der Aalst
    存档
    订阅我的博客
    XML聚合  FeedSky

    原创 正视平台,不要张口闭口就是业务开发平台收藏

    新一篇: Moment of Truth(关键时刻) | 旧一篇: 给联银通公司做了一整天工作流培训的纪实

           上周javaparty的活动,听了EOS的讲座。结果接下来的几天讨论围绕EOS和平台扯了n多东西。扯来扯去,就扯到平台上来的。

           在maillist上谈了自己对平台的看法,摘录如下:

           没想到对EOS还讨论的挺远,虽然我们当中有很多人是做平台的,但是有几个真正做出过平台的(是做出来,不是在做),这个还是需要打个问号?
           EOS定位在快速开发平台,而不是特定行业的业务开发平台。估计当前用友NC和金蝶EAS 那种才能谈得上与业务开发有些关系吧。 —— 至于BEA的那套,也仅仅只是“业务解决方案”,也不是业务开发平台。Justep Bussines3.0不是,5.0吗估计短时间也不可能是。

          其实对客户来说,最好的东西其实是“定制化”的。不可能所谓的拖拖拽拽的就可以轻松的满足一个系统。当然我们可以利用一些“积累的组件”,不管这些组件是“业务性的”,还是“基础性”的,可以利用它们有效的降低开发周期。—— 我想这应该是所有开发平台所看重的。

          这半年来,在这边做平台,也才体会到这一点。以前虽然也在做,但是却没有怎么真正的深入。前几天听EOS的讲解,竟然发现很多平台思路都是一样的。

           至少我认为,不要用所谓的元模型去解决所谓的业务模型。真正的业务组件和模型是不断的特定领域内的项目积累所成的,而不是一个所谓的平台上构建的。—— 平台只是在不断的积累和扩充中,逐步由一个基础组建的平台向可以提供业务组建的平台扩充,最终才能够产生所谓的“业务开发平台”。—— 即使是业务开发平台,其必然会存在所公用的内核,而这些内核,其实无非是一些 底层框架(提供分布式、存储等等底层服务)和Org Model,Process Model,数据字典,view Model,Authorize Model等等。—— 我想这些东西是几乎任何平台都不能少的,只是每家的解决方案不同,能力不同而已。

    发表于 @ 2005年06月03日 12:18:00|评论(loading...)|编辑

    新一篇: Moment of Truth(关键时刻) | 旧一篇: 给联银通公司做了一整天工作流培训的纪实

    评论

    #stringstring 发表于2005-07-13 10:30:00  IP: 61.186.252.*
    一阵风。就像现在协同被热炒。

    平台 现在也被热炒。

    大家都看到了 管理软件 得问题。
    即每个项目都需要做大量的修改,使得每个项目变成一个独立产品。大量重复工作,组件无法复用。无法统一升级。各个项目的人员 称得上 陈兵百万。

    因此希望找到一个 所谓的银弹。

    但就像 JBPM的作者 在工作流状态一文所说:
    那些试图说明通过图形托拽就能定义好用户的业务流程的说法,纯粹是市场行为。并不能像我们想象的那么轻易。

    我们需要真正的搞清楚 我们真正能做什么,真正能解决什么问题,而不是 在一个虚无缥缈的激动地概念下闭门造车。
    #stringstring 发表于2005-07-13 10:30:00  IP: 61.186.252.*
    一阵风。就像现在协同被热炒。

    平台 现在也被热炒。

    大家都看到了 管理软件 得问题。
    即每个项目都需要做大量的修改,使得每个项目变成一个独立产品。大量重复工作,组件无法复用。无法统一升级。各个项目的人员 称得上 陈兵百万。

    因此希望找到一个 所谓的银弹。

    但就像 JBPM的作者 在工作流状态一文所说:
    那些试图说明通过图形托拽就能定义好用户的业务流程的说法,纯粹是市场行为。并不能像我们想象的那么轻易。

    我们需要真正的搞清楚 我们真正能做什么,真正能解决什么问题,而不是 在一个虚无缥缈的激动地概念下闭门造车。
    #peter 发表于2006-04-11 16:22:00  IP: 10.210.27.*
    EOS绝对是一个不值得用的东西。真的。不使EOS的理由:

    1 其许可相当贵,最可恶的是期所有极心的东西都是使用了开源的,如服务器使用JBOSS3.25,但其许可费却要按并发数来收取。这是相当可恶的。

    2 EOS什么上就是一个插件,提高开发速度的插件如Myeclipse相当,但却有别于Myeclipse,因为其做得不伦不类的。其插件目标含糊。

    3 没有原意自己开发的东西对自己不透明。使用了EOS就违背了JAVA的精神。

    4 移植相关困难,只能用来晋元自己修改过的JBOSS里。

    5 具我所使用的5.1版本还存在着相当多的Bug
    #extract 发表于2006-06-30 12:37:00  IP: 61.171.251.*
    stringstring不知是否还记得我,群萃软件的;说得有道理;总感觉在国内做业务平台有些为时过早,业务模式能找出二个相同的企业嘛?(当然说细节啦,不过如果没有细节,软件的用处大大折扣)
    加快开发效率的途径,需要有个过程,业务模式的方式理想状态是业务构造完全拉出来拼凑,这在可以预见的将来都很难,细节太多太多啦,为每个细节进行配置?该有多少配置项?这样一步到位的模式难于推行,真让不懂开发的业务员来定制软件?还需要一段不短的时间;
    我们认为加快开发效率的更为现实的途径是提升程序员的效率,而实现这一目标相对要可行得多;EOS努力得方向应该是正确得,但在宣传上的确有时过于夸张些,没办法,这年头无论你多夸张都有人比你更夸张;
    加快开发效率得方式只有一个,组件话,把更多得可以规范话得东西变成可以方便使用的东西,说来其实简单,但重要的是“度”的问题,组件话的粒度是难以把握的东西,太细小可能最终结果反而是开发效率的降低,太大了,效率固然上去了,可能表现能力、功能性和细节支持能力全没有啦;把握好这个度是至关重要的;
    感觉EOS在这个“度”上有些太细小啦,看看演示动画,一个查询显示功能就要制作3、4个流程图,进行一大堆设置,让人有些怕,那么复杂的会怎样呢?
    不过仍然很佩服刘亚东的眼光,在4、5年前就能把握住这个方向;
    发表评论  


    当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
    Csdn Blog version 3.1a
    Copyright © 银狐999