按需业务流程生命周期,第 1 部分: 为您的按需业务流程构建基础

系列概述

　　

　　

　　文档选项

　　

　　

将此页作为电子邮件发送

　　

未显示需要 JavaScript 的文档选项

拓展 Tomcat 应用

　　

下载 IBM 开源 J2EE 应用服务器 WAS CE 新版本 V1.1

级别: 初级

German Goldszmidt，PhD, 资深软件工程师, IBM

Joshy Joseph, 软件工程师, IBM

Naveen Sachdeva, 软件咨询工程师, IBM

Wei Liu, 软件工程师, IBM

2004 年 10 月 22 日

按需业务厂商需要快速调整自己的生产流程来适应急速变化的市场需求。本文章系列提供了开发灵活、按需业务流程的方法。这一方法提高了快速定义、创建和部署灵活的解决方案的能力，通过集成业务流程内部的服务、数据、规则、角色和规格来满足不断变化的客户需求。基于 IBM 目前正在使用的硬件订单处理系统，文章引入了一个真实化的订单处理场景。这一场景为系列中的其它文章提供了一个通用的上下文环境和一组使用案例，系列中的其它文章将涉及模式、模型、工作流、规则和监控等

引言

本系列文章源于我们在一个试验性项目 Oneida-2 中的经验（请参阅 Oneida-2 project 以获取更多信息）。在这个实验性项目中，我们在一个理想供应链的假设前提下实现了按需业务改造。我们将向您介绍那些技术和方法，使得您可以利用它们来构造可重用组件，以应用到按需业务流程的快速构建中。

在供应链中，制造处理系统（OTMPS）的订单通常位于订单入口和制造支持系统之间（如 图 1 所示）。您可以使用通用的OTMPS 场景和使用案例来理解上面提到的应用。

图 1. 供应链中的订单处理

　　Oneida-2 项目

我们通过实现一个面向服务的体系结构（SOA）原型来说明按需业务改造。这个按需业务改造是在 客户订单分析和跟踪系统（COATS）的一个真实部分基础上来进行的。作为 IBM 的集成供应链（ISC）的核心业务流程，国际 IBM 通过 COATS 来实现主要的业务处理，以满足复杂硬件系统的定购。

在 Oneida-2 工程中，我们对一个遗留的 OTMPS 进行按需业务改造。我们的目标是通过实现一个原型系统来说明如何满足以下业务需求：

更快的时间到价值的转化 -- 对于功能上的改进，用更短的时间进行开发、集成和测试。 弹性处理 -- 管理 IT 风险，在持续运行过程中能够快速捕捉机会，并立即处置外来威胁。 适应性的业务策略 -- 不需要中断重大操作就可以进行动态业务策略调整。 业务性能监控 --综合测控和业务级别相关的信息展示。

文章系列同样也描述了为满足以上需求的和所应用的方法、工具和模式以及 SOA 设计概念。我们采用交互式设计和增量式开发方法，利用模式进行建模、开发和发布。方法强调业务流程中的重用、 IT 技术的成熟度，并且一些关键功能尽可能通过 Web 服务来实现。我们交互式设计主要步骤如下：

通过 IBM WebSphere Business Integration Modeler (WBI Modeler) 对业务流程建模 利用 IBM Rational XDE 定于数据对象模型 利用 WebSphere Studio Application Developer Integration Edition 实现系统 （在此之后作为应用开发者) 将结果应用发布到 WBI Server Foundation 通过 WebSphere Portal 执行过程中监视业务流程性能

我们首先介绍场景、需求和几个使用案例。同时我们将重点阐述建模、系统实现、性能监测解决模式和系统架构。系列中的其它文章将对上面的内容提供更详细的描述，并重点强调按需业务流程解决方案中使用的方法、工具和模式。

回页首

场景

OTMPS 使得客户能够提交订单（参考 Stakeholders 来了解场景中各种角色的详细信息）。您可以利用这些有效填写的订单作为输入来产生制造术语中相应的 BOM。 然后您可以提交这些订单给制造厂进行生产。在正常情况下，这些提交的订单在对应的 BOM 和制造指令下达给制造厂之前要经历多个步骤。在这一过程中可能会有意外情况需要人工干预（如，OTMPS 操作员可能手工处理和纠正一些错误的订单）。

　　Stakeholders

感兴趣的有 7 种类型的 OTMPS stakeholders：

顾客 业主 分析师 架构师 开发人员 管理人员 操作员

顾客是最终用户（例如，销售人员输入新的订单，生产人员接收原材料输出）。业主进行支付，他们决定业务需求，但他们通常用自然语言表达业务需求。分析员负责业务级别的解决方案 。他们和业主一起确定业务需求，然后把相应的逻辑和处理流程利用 WBI Modeler 建模。 架构师负责将业务级别的设计转化为技术架构。他们同时还负责定义系统实现的组件和接口。开发人员利用编程工具如 WebSphere Studio 实现架构。管理人员负责系统运行的管理，操作员负责 OTMPS 应用运行支持并在一定条件下（如订单错误）进行人工干预。

功能

OTMPS 包含的功能组件如下所示（它们组成了系统的主要部分）：

调度器 -- 调度器调度并启动订单的处理流程 控制器 -- 控制器顺序执行订单处理 分组 -- 寻找订单间的关系并据此进行分组 校验 --根据预先定义的规则对订单进行校验 转换 -- 按照制造业术语产生 BOM 输出 制造 -- 将输出打包派送给对应的每个制造厂

在设计实现OTMPS的过程中，您可以对这些功能组件进行适当变化。

回页首

需求

根据与业主的交流，分析人员对 OTMPS 的实现定义了如下的示例需求：

它应该以批处理的方式处理保存的订单。 它应该实时处理在线订单。 它应该能够适应业务以及 IT 策略的改变。 在系统出错的情况下，它应该能够通知管理员。 它应该允许管理员实时的检查和更新系统状态。 对于无效订单它应该通知操作员并允许操作员修改订单。 它应该能够实时产生且显示出关键业务规格。 它应该能够通知业主当关键业务规格超出预定义的范围。 它应该能够与遗留应用程序进行集成（如，硬件配置）。 它应该能够与外部合作者集成（如，合作供应商）。 它应该能够支持不同的协议和数据格式（如，简单对象访问协议（SOAP）/HTTP 或 EDI）。 它应该允许动态替换相容的合作者。 它应该能够跟踪一般工作人员、管理人员和业主的行为。 它应该能够方便一般工作人员、管理人员和业主之间进行合作。 它应该基于 SOA 实现。

回页首

使用案例

根据需求以及前面提到的场景， OTMPS 需要实现以下使用案例（注意，没用全部列出）：

UC0：产生订单 UC1：调度一组在线订单 UC2：开始/停止调度处理 UC3：处理订单 订单分组 订单检验 产生 BOM 发送结果给制造厂 向供应商请求部件 产生业务指标

UC4：通知操作员校验失败 UC5：通知管理员系统意外 UC6：通知业主超出服务允许质量误差 UC7：监视业务规格变动参数 UC8：改变业务规则 UC9：更新订单 UC10：取消订单 UC11：检查订单状态

为加深理解，我们将对 3 个使用案例（UC1、 UC4 和 UC7 ）进行详细描述：

UC1：调度一组在线订单

Actor：操作员

前提：门户和业务集成服务器准备好并处于运行状态

主要成功场景：

操作员登录门户服务器。 系统显示“处理页面”。 操作员进行订单列表并点击 执行按钮。 系统显示系统活动的运行日志。 系统执行 UC3 。 系统显示“执行成功”提示信息。

扩展：5a. 系统显示“失败”提示信息

UC4:通知操作员校验失败

Actor:操作员

前提:成功执行 UC3 过程中遇到无效订单

主要成功场景：

系统给操作员产生一个工作提示信息。 操作员登录门户服务器（如果尚未登录）。 系统显示给操作员要做的事情。 系统等待操作员的请求。 系统显示无效的订单给操作员。 操作员更新订单并点击 更新按钮。 系统更新后台数据库中的订单。

扩展：6a. 操作员与顾客进行协商后更新或取消订单。

UC7：监视业务流程规格

Actor：业务业主

前提：UC1 至少被成功执行一次

主要成功场景：

业主登录门户服务器。 业主打开“监视”页面。 系统显示特定的业务参数（参考 业务流程监视）。

图 2 列出了上面提到的所有使用案例。例如，在 UC7 中，业主通过与 监视系统交互来观察业务性能信息。 在另外一个例子中，操作员连接 Order Application 来执行 UC1 ，UC1 反过来又通过 Order Processing 系统执行 UC3。 供应商显示外部供应商系统，它提供了一个请求部件的接口。 Legacy System 和 Validation System 显示现存的应用，它们被用在 UC3 中。

图 2. OTMPS 使用案例

回页首

开发流程概述

图 3 详细说明了循环开发流程以及每一阶段使用的工具和方法。开发流程从利用 WBI Modeler 对业务流程建模开始。第一步是分析师组织业务领域相关的专家来准确描述业务需求。利用准确的业务需求作为输入，分析师利用 WBI Modeler 对现有的“as-is”业务流程建模。利用一个协作流程，“as-is”业务流程被移植为更有用的“to-be”业务流程。预先存在的模型构件，称为流程元素（参考服务和流程元素一节），在适当的时候被从中心库中取出来加入模型，这样，将来使用的一个新的模型组件就产生了。分析师同时来定义了在业务执行流程中需要监测的业务规格。

一旦成功完成建模，业务分析师将流程模型传递到 IT 开发小组来实现。在实际操作中，IT 架构师应该参与到流程建模中，以保证业务建模与系统实现间的顺利过渡。

WBI Modeler 以业务流程执行语言（BPEL）、XSD 和 WSDL 构件相结合的形式输出流程模型以及相关的业务级别的对象定义。流程模型的实现需要集成其它一些组件如访问遗留功能系统的适配器、业务逻辑组件、Web 服务绑定等待。有许多相关的模式都可以应用在模型的设计和实现上（参考 模式解决方案）。

回页首

Oneida 生命周期

图 3. Oneida 按需业务流程生命周期

利用 IBM Rational XDE，架构师定义其它 IT 组件的对象模型并产生模型的 Java 代码。随后开发人员利用 Application Developer 将 WBI Modeler 和 Rational XDE 的输出、业务合作伙伴的服务、遗留系统以及规则框架集成起来。利用 Application Developer ，开发人员将其它组件（XML schemas、Java 代码、服务、规则）与 BPEL 工作流关联起来。您可以利用通用事件基础设施（CEI）来产生相关流程事件。最终的应用程序实现发布到 WBI 基础运行服务器上。

在执行流程中，CEL 基础设施能够监视流程规格。如果条件满足，您可以使用 WBI 监视器 5.1 版。它支持 CEI 并提供相应的监视工具。另外一种解决方案是，您可以使用 WebSphere Portal Server 来显示性能信息。分析员将利用这些信息来改进业务流程，从而实现一个封闭的生命周期循环。

如上所述，流程模型和实现由几个单独的角色来完成，他们分别需要不同的技能。流程语义，包括过程流、策略和性能参数被用来在 业务- IT 之间的行业差距间传递信息。在此行业差距之上进行增量式和交互式的开发并不是无关紧要的，因为每一方的变动都有可能对另外一方造成重大影响。因此，角色之间进行密切合作对于确定和解决 业务架构有很大帮助。

回页首

业务流程模型

建模就是将业务流程分解成代表不同功能、组件、服务以及相关的数据输入输出、策略和规格的子流程。 As-is 模型可用来进行仿真并找出当前的瓶颈。 As-is 业务流程又可转化为 to-be 业务流程来实现期望的改变。可通过仿真 to-be 模型来找出潜在的流程改进。分析师同样也可找出流程执行过程中需要关注的业务 规格。 图 4 说明了 WBI Modeler V5.1 中一个常见的流程片段。 这一简单的 OTMPS 模型描绘了经过校验和制造厂的订单流。 利用 校验和产生拓扑服务调用步骤，模型集成了一个校验合作服务。图中还包含一个决策点 校验是否成功？， 2 个数据格式转换任务，一个本地数据仓库用来存储后面处理流程中用到的客户订单，一个循环处理来选择并将订单发送到正确的制造工厂。

图 4. WBI Modeler V5.1 中流程模型片段

分析师还可能应用一些已经存在的模型组件（如，服务或流程元素）来帮助和加速模型的构建（请参考 服务和流程元素）。这些模型元素作为业务构件被存储在一个中央仓库中。

　　服务和流程元素

服务元素是一个预先被定义的服务，它可以通过输入到 WBI modeler 而被集成到模型中。它们可以定义发布 Web 服务的输入输出和操作。 例如，一个服务元素可定义 Web 服务来提供远程合作供应商。

流程元素是一个组件集合，它被用来定义业务流程模型中的一些流程片段，这些片段被设计和管理为可重用的。它们组合为：

固定的任务和决策系列 数据对象引用 规则 角色 规格

流程元素包含一些相关的元数据（如，目的、职能效率、关键索引词等的等），它们帮助分析师查找、选择和使用这些流程元素。它们代表一些可重用的用来满足简单需求的实践操作（如用来校验和计算购物篮中物品价格的 子流程）。

系列中的第 3 篇文章引入技术指南来指导利用 WBI Modeler V5 的交互式建模流程。文章描述了如何定义核心流程元素：

控制流 子流程 规则 角色 OTMPS 场景的度量

定义完核心业务组件之后，我们以下面的顺序说明建模方法：

定义并列出任务 任务排序 产生任务之间的控制流 将数据引入到流程中 将服务集成到流程模型中

我们简要描述了利用 WBI Modeler 通过静态或动态仿真来进行模型校验和分析。我们通过对 WBI Modeler 的各种输出功能进行描述作出一个总结并描述了产生的构件。

回页首

实现

WBI modeler 产生的 BPEL、 XSD 和 WSDL 组件成为系统实现的起点。 利用 Rational XDE ，架构师定义其它IT组件的对象模型并产生相应的 Java 代码。我们利用 Application Developer 5.1 “业务集成”透视图来创造一个服务工程，它包含各种组件如 XML schemas、Web 服务以及对象和流程等。利用 XDE 和 Application Developer 产生的 Java 类和 XML schemas 构件分别被用来访问外部合作者服务。 BPEL 工作流被扩展（通过 Java 代码）来集成规则、支持遗留服务交互和产生业务事件。 图 5 是一个 Application Developer BPEL 编辑器视图。

流程通过静态绑定机制来连接它的合作者服务，它在流程发布的时候产生。必要的绑定、发布代码和组件集成到一起。它包括产生的遗留代理组件代码、 WSDL/XSD 文件和一些发布组件（EJB 和 SOAP 绑定）。 意外被外部的宏工作流处理，它是一个长期运行的流程，它为引入工作人员来评估意外情况并决定如何来处理提供了可能。

图 5. Application Developer BPEL 编辑器

在系列的第 4 篇文章中，我们描述了如何将 WBI Modeler 的输出和 Rational XDE 的输出导入 Application Developer 以及如何将它们集成在一起。文章还描述了流程和服务组件实现以及 Java 类和 XMLschema 组件如何以输入/输出消息和状态对象的形式加入到实现。为完成实现，需要包装并连接到外部的合作者服务和规则。 我们描述了一些最佳实现来提高工作流的性能。我们 解释了微工作流之间在事务行为、并行性和性能上的区别。我们提出了在不同条件下的最佳类型和组合方式。我们罗列了不同的数据映射方法、调用方式、绑定发布技巧以及这些不同方法技巧对于性能的影响。

回页首

定制：策略和规则

随着时间进展，业主引入新的需求到 OTMPS 实现中（如，改变如何来决定配置订单的策略）。我们的目标就是使 OTMPS 能够适应需求的快速改变。

　　策略、规则和强制点

策略通常是公开的（如，只有美国的客户才能够定购某种类型的机器）每一策略在实现中往往需要 1 个或多个强制点。 强制点可能是流程中的一个单独的步骤或代码中的某个特定位置。在处理事件的流程中强制点也可以发生。 规则通常是实现强制点的有效途径。规则是有效逻辑执行的。一个简单的规则如下所示：

"If !(location(customer) == "USA") then reject(order);"

在通常情况下，策略并没用明确标明，只是在实现中隐式定义。换句话说，策略通过定义一组实现强制点和规则来实现。

分析师可以来定义策略，但策略需要明确的、可执行的规则来强制执行。可以参考“策略、规则和强制点”一节中关于策略、规则和强制点的定义。

在传统的应用程序中，规则被嵌入到应用程序中的代码中。当策略发生改变，应用程序代码需要被更新且重新发布。 规则外部化使得业务分析人员和其它非技术用户可以更改策略而不需要改变流程逻辑和重新发布应用程序。

为重用现存的工作流组件，对架构来说实现后期定制来满足策略改变很有必要。这种定制可以通过在工作流执行过程中动态改变外部规则来实现，这些外部规则正是用来实现和强制业务策略。

作为试验性项目 OTMPS 的一部分，我们实现了一个简单的服务器框架，它包含一个规则服务代理和一个规则选择引擎（详细信息请参阅系列文章中的第 5 篇）。我们通过业务规则 Beans（BRBeans）（请参阅 图 6）来实现框架。

BRBeans 是 WBI-SF 中的一个框架，用来创建、修改和调用规则，它通过 Rule、RuleFolder 和 RuleHelper 等 EJB 来实现。在 BRBeans 框架中，每条规则都由一个实体 EJB 来实现，实体 EJB 持久性地存储规则相关的信息。每一条规则被指派一个特定的名字和相关的属性（如开始日期、结束日期、可用性、javaRuleImplementorName 等），被存储在相关的规则路径中。规则实现就是用 Java 语言编写的算法并通过 ‘javaRuleImplementorName’ 属性来与规则关联。

图 6. BRBeans 架构

除了从工作流中直接调用 BRBeans API ，我们建议采用服务调用的方式，它反过来通过规则框架调用 BRBeans API ，如 图 7 所示。所有应用特定的规则都封装到一个服务代理中，每个规则作为一个代理提供的方法。应用程序（如安全、业务性能等等）间共享的规则可以定义为另外一个通用服务代理。规则框架隐藏了规则引擎，使得可以选择不同的规则引擎。分析员通过特定的规则引擎管理系统（通过规则管理 GUI ）来定义规则并发布到对应的规则引擎。

图 7. 规则服务代理

在策略强制点，规则以普通 Web 服务的形式被调用，为执行传递必要的参数。我们应用策略模式来进行合适规则引擎的选择。创造了一个命令模式进行正确规则的选择及其在相应规则引擎上的执行。一旦一个规则命令类被创建，它将在特定的规则引擎上被触发且执行正确的规则。

回页首

业务流程监控

业务流程监控允许业主和管理员实时监控关键性能指示器（KPI，参考关键性能指示器）。它同样也帮助分析师定位当前系统中的问题和瓶颈，形成如 图 3 所示的闭合的开发周期。基于此反馈信息，分析师可以决定如何来调整和改变业务流程来实现循环的开发流程。如，在试验性项目中，OTMPS 业主定义了如下关键性能测量参数：

订单平均吞吐量 订单成功率 无效订单数量 解决故障平均时间

　　关键性能指示器

KPI 是由业主定义的一种可测量的方式，用来反映业务关键成功因素。流程视图由一个显示基于 KPI 的实际性能参数的 仪表板组成。如 KPI 可能有一个相关的上限或下限。当相应的指标偏离超出了期望的范围，将产生一个适当的警告信息。

CEI 基础架构使您能够以一种统一的方式创造和发布事件。您可以编写应用程序/工具来根据这些事件计算并显示有用信息。事件通常被用来激发信息相关的业务流程，这些流程被用来计算性能指标。利用 WBI-SF V5.1.1 中包含的 CEI API ，事件以通用基本事件（CBE）的格式产生。我们利用 WebSphere Portal Server Express 来显示并聚合信息到一个复合页面中，以复合表格的形式给用户提供信息。我们定制 WebSphere Portal Server Express 提供的 Web 页面来监视业务事件和性能信息。

在本系列将来的文章中，我们将演示如何利用 CEI 实现业务流程监视。我们讨论如何在 WBI Modeler V5.1 中定义 KPI ，如何利用 BPEL 编辑器和 Application Developer V5.1.1 中的 CEI API 来创建相应的事件，我们简单描述了 CBE 的架构，说明了如何利用 XPath 查询语言进行查询，如何利用 WBI-SF V5.1.1 创建事件组，如何利用 CEI API 来查询事件。

回页首

模式解决方案

有许多相关的模式（请参考 模式）可应用在 OTMPS 的分析、测试、电子业务以及发布等等。这些模式是如何结合在一起的？在一个特定的上下文中如何应用这些模式来创建一个灵活的，及时响应的解决方案？这些问题都不是很清楚。在系列中的第 2 篇文章中我们描述了一个 OPMPS 的模式解决方案的实现，利用模式来实现电子商务。为了解电子商务模式，请参考 Jonathan Adams、 Srinivas Koushik、 Guru Vasudeva 和 George Galambos 撰写的 电子商务模式：可重用方法，IBM Press， 2001， ISBN 1-931182-02-7。要了解 IBM developerWorks 中电子商务资源中其它的模式信息，请参考 IBM 电子商务模式。

　　模式

模式描述了一个重复发生的问题的解决方案。 模式方案 将许多模式连接在一起。

在第 2 篇文章中，我们引入了 4 种设计模式，它们或者是现有模式的变形，或者是有可能成为新的设计模式：

业务流程复合模式：允许启动一个需要协作和监控的业务流程。 页面应用聚合模式：作为一个访问一体化应用程序的模式，它提供了一个可定制的通用接口来访问多个应用程序 单点访问运行模式：一个基本的运行时模式，相对于页面聚合应用模式，它提供了访问各种 Web 应用程序的统一的访问点。 Web 客户运行模式是一个可管理的协作运行模式：它允许 Web 客户以先前定义的方式进行异步协同。

回页首

系统架构

就像文章开头提到的，我们实现了一个真正的 OTMPS 的按需改造，在下面的文章中，我们将详细描述所采用的技术和方法，这些技术方法在您设计构建类似的系统时同样也可用上。 图 8 说明了在我们的 OTMPS 原型系统中主要组件之间运行时的关系。

WebSphere Portal -- 包含提供用户访问 OTMPS 服务的 portlet。 WBI Server Foundation V5.1.1 - 提供以下功能特性： Web 包容器 -- 包含用来处理来自 portlet 请求的 servlet（如，启动一个新的业务流程实例，收集性能信息等等）。 Process 包容器 -- 提供执行（BPEL）业务流程的引擎。 BRBeans -- 使业务规则外部化。 CEI -- 用来产生和收集业务事件。

DB - -数据库（DB2），用来存储 BRBeans 规则和 CEI 数据。 外部配置器和遗留系统服务-- 用来配置和校验订单的外部合作服务，支持的协议有 MQ 和 FTP。

图 8. 组件 -- 逻辑视图

回页首

结束语

本系列文章概述了实现灵活的业务流程所需的技术以及开发生命周期，这些技术和开发流程使得业务流程可以满足不断变化的需求。 我们描述了一个订单处理视图，它为系列中的其它文章提供了一个通用的上下文环境和一组使用案例。第一步是利用 WBI Modeler 对现存的或期望的业务流程建模。模型输出构件和其它构件进行组合，最终的应用程序发布到 WBI-SF 上。CEI 产生相关事件用来测量业务规格，这些信息通过计算并显示在业务控制界面上。这些规格随后作为输入供分析师来改进业务流程，从而完成一个循环。通过将多个电子商务模式集成可以产生一个模式解决方案，架构设计正是基于这种方式来设计的。

回页首

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

可以从下列文章中获取按需操作环境的相关信息： 按需操作环境 ( developerWorks， August 2004) 实现按需突破的操作环境要素 ( developerWorks， August 2004) 按需解决方案的架构设计：利用 IBM 按需操作环境 13 种特性的最佳实践 ( developerWorks系列文章)

可以获取更多电子商务模式方面的书籍 电子商务模式：可重用方法 , Jonathan Adams, Srinivas Koushik, Guru Vasudeva, 和 George Galambos 著，(IBM Press, 2001, ISBN 1-931182-02-7).

您也可以在 developerWorks站点 IBM 电子商务模式 学习更多知识。

下载 “Web 服务的业务流程执行语言，1.1 版”规范 (developerWorks, March 2003).

使用 快速启动 Web 服务访问 Web 服务知识、工具和技能，它提供了最新的基于 Java 的软件开发工具和来自 IBM 的中间件（试用版），以及在线教程和文章和在线技术论坛。

访问 Developer Bookstore 以获取综合性的技术图书列表，其中包括数以百计的 Web 服务主题。

想获取更多信息吗？developerWorks 的 SOA 与 Web 服务专区拥有许多提供信息的文章和关于如何开发 Web 服务应用程序的入门级、中级的和高级教程。

回页首

作者简介

German Goldszmidt 博士是 IBM 公司的资深软件工程师，主要研究实现、定制和发布按需解决方案一体化平台。在此之前，作为 IBM T.J. Watson 研究中心的研究员，他领导着多个重要项目的设计和实现，包括第一个自动电子公共设施的原型 Oceano 、网络分派器（Websphere 负载平衡组件）。

Joshy Joseph 是 IBM 按需业务开发组织的软件工程师。作为一名架构师和程序员，他掌握了分布式计算、网格计算、 Web 服务以及业务流程和工作流等领域基本技术和技能。2003 年他的专著《网格计算》由 Prentice Hall 出版社出版 。另外，他还撰写了大量的关于网格计算、业务流程开发以及 Web 服务方面的文章。

Naveen Sachdeva 是 IBM 应用集成中间件开发团体的软件工程咨询师， 他在大规模系统集成和分布式计算系统的设计和开发领域具有 10 年以上的经验。他目前正帮助 IBM 的业务合作者利用 Websphere 产品进行技术可行性和概念论证。

Wei Liu 是 IBM 的软件工程师，她目前正在 IBM 按需业务开发小组工作。她从事的研究领域主要包括应用服务器、 Web 服务和工作流开发。