BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

为什么Java开发者憎恨BPM?

| 作者 Jean-Jacques Dubray 关注 3 他的粉丝 ,译者 王军 关注 0 他的粉丝 发布于 2007年12月2日. 估计阅读时间: 7 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

最近John Raynolds提出这个问题:“为什么Java开发者憎恨BPM?

从自己和他人的经验中,他得出这样的结论:

BPM套件[……]抢走你的创意[并]指挥你如何开发应用软件。BPM套件让编程成为一件烦人的事。它们迫使你使用点击拖放工具来设计过程图、数据模型和窗体。

更糟的是它们竟然鼓励业务人士自己去构建过程模型和设计窗体……

他声称:

Java开发者(大多数)宁愿使用像Struts和Spring这样的框架,也不愿承受来自BPM套件的限制……用Spring或Struts,你可以构造几乎所有东西(如果你已经掌握了Java的错综复杂)。它们是轻量级的、敏捷的,而且在你的履历中看起来很迷人。

我们已经用Java构建了不少工具,这些工具使得通晓Java本身变得并不那么重要。同时也使那些没有学习Java多长时间的人们与我们展开了竞争。

我们成了自己成功的受害者……这正让我们蒙受损失。

这也就是Java开发者憎恨BPM的原因。

读者们也表达了其他不同的理由。例如下面这个读者憎恨BPM是因为:

坦白说,我不认为BPM会是一个有所作为的应用工具……——NetBeans有免费的BPM工具,但它看起来仅仅像一个简单的Web Service自动化工具。它对我所遇到的业务需求和关注问题完全没有用处。即便是更为花哨的工具,例如花哨的高级过程脚本工具,也没能提供多大价值。——没有一个好的BPM套件是免费提供给开发者们使用的,所以很难对之进行试验。它们价钱不菲,我的老板是不会买它们的。

哪里有成功的案例?我非常乐意倾听:给我看一下这种技术在现实中的应用吧。

另一位则认为:

我们憎恨BPM,原因是我们不应当去使用它。BPM的[……]观念是让业务人士去做建模任务,但事实上业务人士并不用它,因此最终我们[在]用。

这位读者对于经常宣传的貌似简单的“点击运行”并不买账:

现实情况是即使给出最简单的过程,那些过程实际上还是在计算机上运行。而电脑……只懂得“做我说的”,而不会“做我的想要的” 。

不管那些线框图表示什么,都需要对这些线框组合所代表的现实有一个基本的了解。很多很微妙的细节包含在“张贴发票(Post Invoice)”泡沫中,并且这些细微之处突显并影响它们周围的内容。

最终,需要创造这些图表的人还是需要了解电脑和计算技术。这些人程序员,而且编程要求特定的思路和技术知识。

……所以,虽然在图上可能只显示为一个单一的盒子,但你最好真正了解这"100行J2EE代码"实际在干什么。不管这个小盒子的颜色或形状是什么样的,复杂度依然存在。

作为一个开发者,我……迷惑不解,“什么时候我的系统变得足够大,值得将这一大堆基础设施放入其中——我需要一个本身占用1G内存的脚本语言解释器和运行时” 。

长期以来,抽象很明显已经让我们所有人过得更好。从二进制代码到汇编程序到C再到Java。“一行Java代码代表10行Java字节码,代表100行机器语言指令”。但最好的Java程序员能了解这100行机器语言指令是怎么运行的。新手程序员则因对此不了解而时常受到惩罚。

Robert Perkins曾经使用过BPM工具,他解释了自己不喜欢BPM套件的原因:

去让你的工程师使用如visio这样的流程图工具来编写你产品的下一个版本。他们将被限制使用javascript。他们将没有自动回归测试系统。他们将没有一向所依靠的eclipse或Intellij Idea的任何特色功能。这里也不会有任何构建部署脚本,部署工作将陷入手工拷贝文件。噢,他们将不会有版本管理。

你含沙射影地说那些想使用这些工具而不用能为业务创造最大价值的工具或产品的开发者是为了一己之需。

这确实有些道理。我认为有很多非技术的企业都会相信这一点,它正在制造开发者和企业之间的不信任。我知道我现在的公司就有这个问题,我想很多厂商和销售团队都在利用这一点。

而且就成功的案例而言,我不知道应该信多少。我的公司被列为一个“成功案例”。而现实情况是该项目是一个灾难,最终用户还在抗议中,并且截至今年3月整个开发团队还在继续开发中。

问题不仅仅在于BPM,而是更为普遍。在很多地方,企业是个性化一些业务或表达逻辑的最佳位置。最近Mark Proctor就统一规则和过程引擎是否有益提出疑问,他认为许多过程定义需要更有表达力的规则引擎,而且规则能受益于过程引擎的状态管理能力。Mark补充说:

统一建模环境的一个美景在于你可以选择想要的方式对事物进行建模。

Dave Wright认为这一切都有千丝万缕的联系:

你可以说,在给定的相似的数据模型和条件及事实模型下,规则和数据相比规则和过程而言要更加紧密地联系在一起。我知道你不想分离过程和规则平台,你也想去掉分离的数据平台吗?

Pierre Bonnet关于敏捷链管理系统(ACMS)的分析证实了这一点,他认为MDM, BRMS和BPMS之间有着非常强的联系:

  • 主数据管理(MDM)。 引用数据和参数的简化管理,允许服务配置模式的实现将执行置于上下文中。
  • 业务规则管理系统(BRMS)。 规则依赖于引用数据和参数。组织服务的前置、后置条件位于规则管理系统中。
  • 业务过程管理(BPM)。 过程使用规则来驱动不同阶段的活动。编制服务被MDM和BRMS置于上下文中。

Peter Evans-Greenwood赞成使用一种新途径来定义应用语义:

规则和过程之间的分离只是技术所带来的一种人为结果,并不是我们希望它们如此。分离规则和过程引擎带来了庞大的花费(这是我们可以免除的)。

更富有成效的做法可能来自这个问题的反方向。让我们由上而下来调查人们是如何认识和处理业务逻辑的,然后创造出能够模仿我们的做法的工具和技术。
查看英文原文:Why do Java developers hate BPM?
译者简介:王军,长期从事软件开发工作,实际项目偏重于JBOSS平台上构建网管软件。对于性能测试工具有较多的关注,关心软件技术和相关工具的动态,将其中相对成熟的技术和工具应用到实际的项目之中。长期担任技术管理和项目管理工作,一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。参与InfoQ中文站内容建设,请邮件至china-editorial@infoq.com

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

把BPM引向DDD? by Cho Forrest

在Intalio还卖5000刀的时候,我们就开始使用它,试图最终覆盖所有公司的Business Process。但是结果就像上面“另一位认为”的那样,专业人员不愿使用它们,而开发者对这种“方便的”定制方法却不领情。导致应用的范围极其有限。

想让专业人员有开发者的逻辑基本是种徒劳的努力。通过双方的讨论,和不断的原型验证,从而生成一套面向领域的模型,这正是DDD所倡导的。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT