论坛徽章:: 2

电梯直达

1楼 [收藏(0)] [报告]

发表于 2007-08-02 09:44 |只看该作者 |倒序浏览

开放源码工作流工具箱 (WFTK) 是一种任务管理和工作流系统。这是一种新开放源码开发模式（即赞助基金）的一个极佳范例。本文给出了 WFTK 技术概述；描述该项目的历史；并讨论有赞助的开放源码模式给每个相关人员（包括赞助人、开发者和社区）带来的好处。

开放源码可能是强大的

尽管有关开放源码软件开发的新闻报导大部分集中在 Linux 的突然和出人意料的成功方面，但其它开放源码项目实际上占有更大的市场份额：Apache Web 服务器占有 70% 的 HTTP 服务器市场， sendmail 处理着因特网上大约 90% 的电子邮件业务，而 BIND 对 DNS 服务提供的解决方案是如此成功，以至于基本上没有它这种级别的商业产品。（域名系统是通用的分布式复制的数据查询服务，用于将主机名转换成网际地址。）

但 Linux 正在面对 Microsoft Windows 这样个业界巨擘而成长起来，并开始占据它自己的份额，这吸引了分析家的注意。

开放源码软件的构思很简单：所有用户都享有对产品源代码的自由访问。拥有对源代码的自由访问对软件用户意味着三个基本意义：可以随意查找和修改它们自己安装中的错误；有最大的自由集成和定制软件；并且给予他们对软件的完全控制以适应个别需要。 Linux 开发的效率已成为开放源码模型中最著名的成功案例之一。在许多情况下，操作系统中的“臭虫”是在发现后几个小时内修复的。

什么时侯开放源码项目失败

开放源码项目失败的一个解释是开放源码开发文化的本质具有随意性。典型的开放源码项目是在程序员有需要时（“期待解决的问题”）启动的。程序员为满足需要而使用工具的第一次运行构成了新项目的核心。如果它是不错的工具，并解决了一般问题，从理论上说，该项目就可以吸引许多用户。这些用户中就有新一代的核心开发者。因此，一个健康的社区就可以进行开发并日趋稳定。如果项目的用户社区足够大，它甚至还能负担商业支持供应商、付费开发者等等的费用。（这些当然是 Linux 见证的现象，但其它还包括 sendmail 和 Apache。）

但这种方法会因许多原因而失败。项目的受重视级别可能不够高。实现太专门化，或者开发者没有足够的时间或对将工具推向市场没有兴趣。例如，开发领导人在可能这个社区稳定之前得到另一份工作，或者整个项目在有进展之前失去动力。因为开放源码开发通常是没有报酬的工作，所以在现实世界中要持续成功运行开放源码项目很难

商业企业害怕将开放源码作为解决方案

在企业市场中，开放源码通常被看作是一个危险的提议。如果公司将其解决方案基于开放源码项目，而后来失败了，究竟会发生什么呢？但如果您仔细考虑，就会认识到这种观点是基于对开放源码项目的错误理解上的，而比起那些专有的项目，开放源码项目不再失败或很少失败。开放源码主要是代码开发和维护的一种方法，因此选择使用开放源码解决方案的企业总能在最初的开发阶段中节省金钱。

企业管理者更倾向于封闭源码商业解决方案的理由是基于这样一种观念，即在有故障情况下必须有某人负责。但如果您阅读了任何一个软件包的许可证条款，就会注意到软件公司从来都不同意在出现故障情况下负责。最近，评估 Microsoft Outlook 中由于电子邮件蠕虫病毒利用已知安全性问题所造成的损失就能够很好地证明这点。合同中没有规定 Microsoft 要补偿这些损失。

所以，开放源码能够象适合开发者和应用程序的用户那样很好地适合应用企业。当然，参与任何开放源码项目的企业也有益于项目。现在，让我们看一下工作流系统是如何使赞助资金模型适用于开放源码项目的。

究竟什么是工作流？

如果回忆一下，就会发现这篇文章是有关工作流工具箱的。那么，什么是工作流？工作流系统使协调自动化。可以通过两种途径来了解这一点。一种工作流的观点是将一组任务指派给组织中某个人（或程序）。从以上观点来看，工作流系统所做的就是协调谁来执行和何时执行。因此，如果我请购一把椅子，我不用从管理员处获得书面的表单，填好，然后通过内部邮件发送给采购部门，而只需要启动一个工作流进程。工作流系统知道谁需要不经签字而批准请购，需要通知谁去采购，并且系统能够相应地创建任务。可以明确地将这些任务指派给各人，也可以从“部门人员”列表中选择他们。任务完成后，工作流引擎跟踪下一步将发生的事件。

这是一种观点。另一种工作流的观点是从过程方面：可以将进程看作通过许多人（或程序）的努力而随时间构建起来的数据结构。工作流引擎协调进程。所以可以发现，工作流引擎也可以作为无数实用 Web 应用的基础、客户服务状态报告页面等等。如果在对复杂 Web 应用程序进行任何类型的编码，您有可能已在使用工作流。但如果正式将工作流引入引擎中，可能做得不够好。

商业工作流系统

如您想象的那样，现在工作流市场已经饱和。有超过 40 种已知的商业工作流应用程序。而 Microsoft 还在竭力尝试进入工作流市场。为什么呢？

经济原因是显而易见的。在相当大的组织中安装的一个典型工作流需要的现金花费难以想象：通常在服务器和每用户上的费用相当高。几乎要一直雇佣供应商以定制产品。为了将商业实践整理为正规的工作流处理等，还有为牵涉到的人员和/或工作流分析员提供的培训课程。类似的问题还有很多。光是一个比较小的 FileNet Workflow 安装的软件许可证费用就要花费大约五万美元。而一个实际工作中的典型工作流系统需要有百万资金。简而言之，工作流市场蕴含着无尽的宝藏。

没有开放源码工作流系统

和所有钟意于工作流的人一样，您可能认为市场上已经有某些种类的开放源码系统了。但事实上，大多数开放源码程序员都不为企业工作。他们通常是大学里的工作人员或独立的咨询师（象我一样）。极少数情况下，企业会从头开发自己的工具，基本上没有机会让这些工具的源码公开。但管理层就不是那么考虑的了。

因此当 Galactic Marketing 确定他们需要工作流系统后，就全面考虑了商业解决方案的定价，并在意识到商业解决方案提供的是唯一唾手可得的解决方案后，他们就发现有期待解决的问题。唯一的障碍是他们不是程序员。

有赞助的开放源码：两种世界的最佳选择

进入 SourceXchange。SourceXchange 是由 Collab.net 提供的一个站点，该公司是尝试开放源码业务的公司。 SourceXchange 的设想是提供一个赞助商可以发布项目、相当详细的说明书和一笔愿意支付的资金的所在地。然后，有兴趣的开发者可以为这些项目做计划。所产生的代码必须是开放源码。赞助商和开发者共享版权，所以替代许可证和进一步开发不需要受开放源码许可证支配。

因此 Galactic Marketing 在 SourceXchange 上发布一个工作流系统的 RFP （建议请求）。我赢得了这个合同。然后有了 WFTK。Galactic 为最初的开发和部分代码所有权付费。

这种合作伙伴关系的关键在于开放源码编程不需要是人们经常假设的自愿项目。有关企业环境中开放源码的一个批评是，更改由于是随意答应的，所以可能花费很长的时间也不能完成。（让我们暂时忽略商业应用供应商经常也有类似行为。）为什么企业希望有人能在自愿基础上工作来适应他们的日程安排呢？答案到现在应该很明显了：如果您现在有问题，那么需要为解决方案付钱。SourceXchange 不是可以安排这类事务的唯一地方。最近提供这些服务的站点正在不断涌现。但 SourceXchange 是有组织的，他们已有很多经验，并且已在企业和开放源码界建立了良好的声誉。

开放源码工作流工具箱概况

WFTK 项目的构思过去是（现在也是）有以下特性的引擎

实用，能够嵌入任意 Web 应用程序。
易于使用和安装
易于与现有基础设施集成
易于定制
包括用于管理开放任务／进程的用户界面 (UI) 和编辑进程定义的 UI。

换句话说，开放源码工作流工具箱不只是包括源代码的简单工作流引擎。开放源码开发和开放源码工作流工具箱的实际强度在于您不必隐藏任何东西。没有商业秘密。您可以对任何希望使用的事物进行操作，并可以争取您所需的任何应用程序。只要能满足赞助商的需要，就允许您对它花费更多精力。在一段长时间后，额外的努力将得到回报。

WFTK 的基本设置由以下模块组成：

核心引擎

核心引擎负责实际执行的工作流。因此，如果有一个活动的进程，并且一个任务刚刚完成，我就告诉核心引擎，它就更新进程的状态，确定下一步发生什么，并给我结果信息。每个进程的状态都存储在名为 "datasheet" 的 XML 文件中，后者存储在中央目录里。

任务管理器

尽管可以将核心引擎认为是完整的工作流系统（将满足许多工作流应用程序的要求），还是可以使用任务管理器来维护板上有关活动进程的信息。原型系统中的任务管理器组件是以 PostgreSQL 实现的数据库，并包括一个作为 AOLServer/Tcl 代码实现的全功能 UI。任务管理器通过将它作为命令行程序调用来与核心引擎进行通话。它从核心引擎中获取任务激活通知，并使用它们来在数据库中创建任务记录。因此，有关“我拥有哪些任务”的全面查询非常容易得到答案。任务管理器也可以安排核心引擎根本不管理的特殊任务（执行任务列表项）。

进程定义管理器

procdef 管理器维护着 procdef 资源库。 procdef 资源库是一个有效的用于进程定义的简单文档管理和版本控制系统。这样做的原因是个别的进程可以在很长的一段时间内保持活动状态。如果个别进程下的进程定义有更改，肯定会发生大混乱。因此资源库确保工作的进程总是来自用于启动它的那个进程定义的同一版本。另外，procdef 管理器提供了一个简单的编辑 UI 用于创建测试版本的进程、修改它们，以及（不管怎样，很快）在“沙箱”中测试它们。

用户管理器

某些时侯，在所有组件中包括 LDAP（轻量级目录访问协议）是个不错的想法，但对目前来说，以及对我们当中不使用 LDAP 的人来说，WFTK 包括了一个简单的用户管理器。每个用户都用一个 XML 文件表示，许可权是集中管理的。

WFTK 中的每样事物都用 XML 文档表示。"expat" 语法分析器 -- 也是一个开放源码产品（由 James Clark 开发）-- 对文档进行语法分析；一旦装入全功能操作 API，它也对文档使用。

一个典型的工作流进程定义可能看上去如下（实际上，这是设计的第一种用法方案）：

<workflow name="Purchase request" author="Michael [email]michael@vivtek.com[/email]">
<role name="Supervisor"/>
<role name="Purchasing"/>
<role name="Accounting"/>
<role name="Receiving"/>
<data name="Product requested" type="string"/>
<data name="Reason for request" type="string"/>
<data name="Requester's email" type="string"/>
<sequence>
<task label="Approval" role="Supervisor">
<data name="Approval code" type="string"/>
</task>
<if expr="${Approval code} == 'No'">
<situation name="Request rejected"/>
</if>
<task label="Order item" role="Purchasing">
<data name="Purchasing record" type="string"/>
</task>
<alert type="email" to="${Requester's email}">
Your request for the purchase of ${Product requested} has been approved and the
order was placed. The purchasing record is ${Purchasing record} if you need to
contact Purchasing for inquiries.
</alert>
<alert type="role" to="Accounting">
An order for ${Product requested} has been placed.
</alert>
<alert type="role" to="Receiving">
An order for ${Product requested} has been placed. Expect delivery.
</alert>
<parallel>
<sequence>
<task label="Receive ${Product requested}" role="Receiving"></task>
<alert type="email" to="${Requester's email}">
Your requested ${Product requested} has arrived.
</alert>
</sequence>
<task label="File invoice" role="Accounting">
<data name="Invoice number" type="string">INV309843</data>
</task>
</parallel>
<task label="Pay invoice" role="Accounting"/>
<alert type="role" to="Purchasing">
The purchase has been paid.
</alert>
</sequence>
<handle situation="Request rejected">
<alert type="email" to="${Requester's email}">
Your request for ${Product requested} has been rejected by your supervisor.
</alert>
</handle>
</workflow>

复制代码

我不会在此说明任何代码分析的详细信息。请访问项目站点（下面列出）获得深入信息。但在代码示例中包括的内容可以让您体会到 XML 定义看上去是怎样的。

在此，我希望说明几个有趣的要点。首先，请注意任务和其它操作的标题可以取决于为特定情况收集的数据。实际上，过程本身的描述可以取决于在启动过程时所收集的数据。您可以为警告和通知进行编码，作为进程的一个完整部分。通过电子邮件接收到的数据稍后将添加到引擎中，可以允许非常大的灵活性。

另外，特定的数据项可以在过程中的任何时侯收集。任务管理器根据过程定义构建一个表单，用户可以使用表单来完成任务。所有收集的数据就都成为过程数据表的一个部分，使报告每个个别进程的状态非常简便。

开放源码的经历

WFTK 是我在开放源码环境中开发的第一次经历。一方面，最初时我非常担心我的代码对公众可见。但它是编写更完善代码的激励，当然它也非常好地为我的代码提供了文件证明。我还能在别的什么地方说明为获得原型所走的那些捷径呢？

但开放源码世界最突出的方面是人们可以突然发电子邮件给我，提供有关可能工具的一些非常有价值的建议、我所犯的错误、可能的扩展等等。我刚接到来自印度的一个大学班级小组对我的引擎一部分的 Rational Rose 实现。我和大学师生、空军工具使用者和其它项目的维护者有过深入的交谈，探讨有关工作流设计的问题。开放源码的公开性对这个项目提供的质量远远高于我以前所做的任何一个项目。

文库|博客

返回列表

Chinaunix › 论坛 › IT运维 › 初创企业IT架构选型 › 工作流工具箱：开放源码项目的案例研究 zt

[电子政务] 工作流工具箱：开放源码项目的案例研究 zt [复制链接]

浏览过的版块