WebSphere Business Modeler 和 WebSphere Integration Developer 中的迭代开发

在业务流程随时间推移而更改时使其保持同步

IBM® WebSphere® Business Modeler 和 IBM WebSphere Integration Developer 是用于开发、组装和测试业务流程的工具，但是由于它们由不同的角色（分别为业务分析人员和集成开发人员）使用，一个环境中的模型可能与另一个环境中的模型失去同步。本文研究如何在业务模型随时间推移而发展时让两个工具环境中的业务模型彼此保持一致。 本文来自于 IBM Business Process Management Journal。

Marc Fasbinder, IT 咨询专家, IBM

关闭 [x]

Marc Fasbinder 是 IBM 位于密歇根州 Southfield 的 WebSphere Technical Sales 团队的一名 IT 专家。



2009 年 3 月 19 日

引言

IBM® WebSphere® Business Modeler（以下称为 Modeler）是非技术业务分析人员用于对业务流程建模的工具。通过模拟和分析，Modeler 支持对业务流程进行优化。然后可以将优化后的流程作为 WS-BPEL、XSD、WSDL 和其他构造导入到 IBM WebSphere Integration Developer 中，后者是担当集成开发人员角色的 IT 人员使用的工具。然后集成开发人员可以在将业务流程部署到 IBM WebSphere Process Server 之前对其进行组装和测试。

本文研究如何在模型随时间推移而发展时让两个工具环境中的模型彼此保持同步。

回页首

建模生命周期

在理想的世界中，业务分析人员创建模型以表示某个流程需要做的工作。然后将模型移交给 IT 人员，由 IT 人员定义如何实现该模型。例如：

  • 业务分析人员使用 Modeler 对当前状态（或者说是“原有”流程）建模。
  • 业务分析人员使用模拟和分析来创建将来的状态（或者说是模型的“将来”版本）。
  • IT 技术人员取得模型的所有权，添加技术详细信息，然后将更新后的模型从 Modeler 导出到 WebSphere Integration Developer。
  • 集成开发人员对模型进行技术更新、单元测试，然后将模型导出到 EAR 文件，以便部署到测试和生产服务器。

在现实世界中，该生命周期并非始终泾渭分明。例如，在将模型从 Modeler 导出到 WebSphere Integration Developer 以后，来自业务部门的后期更改请求可能会驱动对业务模型的更改需要。或者，集成开发人员可能需要对 WS-BPEL 模型做出更改，从而使其与业务模型不再匹配。换句话说，模型导出不是一次性的活动，而是可能使用迭代开发周期。

这里还有循环往返的场景；即使遵循理想的生命周期，将来也可能要在部署流程以后对模型作出更新。例如：

  • 流程的第 1 版投入生产运行。
  • WebSphere Business Monitor 在流程运行时收集业务度量。
  • 从 WebSphere Business Monitor 导出带观察度量的监视结果，如任务时间、决策百分比等等。
  • 初始的“将来”模型现在成为当前的“原有”状态。将监视结果导入 Modeler，以使用观察的业务度量值更新业务模型。
  • 执行模拟和分析以创建新的（第 2 版）“将来”模型。

如果只是将第 2 版的模型导出到 WebSphere Integration Developer，对 BPEL 所做的任何技术更新都将丢失。

在这里的每种情况下，其中一个模型独立于另一个模型而发展。因此需要某种机制来保持两个模型彼此同步。幸运的是，6.1 版本的 WebSphere BPM 堆栈包括相关功能，以帮助您将 Modeler 和 WebSphere Integration Developer 中的模型保持同步。

初始业务模型

本文中的场景使用一个简单的模型，该模型描述新员工上岗流程。本文附带的可下载项目文件包括此员工上岗业务流程的原有和将来版本。将来版本已经准备好导出到 WebSphere Integration Developer。要探索初始模型，可以将本文附带的 .mar 文件导入 Modeler：

  1. 下载本文附带的示例文件。
  2. 启动 WebSphere Business Modeler
  3. 在项目树的空白中单击鼠标右键并选择 Import...。
  4. 确保选择 WebSphere Business Modeler project (.mar, .zip)，然后单击 Next。
  5. 单击 Browse...，浏览到您下载示例的文件夹，然后单击 OK。
  6. 选择 Onboarding Modeling Project.mar，然后单击 Finish。
  7. 当您看到消息“Import finished successfully”时，请单击 OK。

如图 1 所示的将来流程的工作方式类似如下：

  • Capture New Hire Information 是一个局部人工任务，在此任务过程中将记录有关新员工的人力资源记录详细信息。
  • Add To Payroll System 是自动运行的任务，用于将员工信息添加到工资单系统中。
  • Assign Office Space 是一个局部人工任务，Office Administration 在此任务过程中决定向新员工分配哪个办公桌或办公室。
  • Apply Location Rules 是个局部业务规则任务，它使用工作位置来确定员工是否将获得停车位。
  • Assign Parking Space? 是个简单决策，它基于业务规则的结果控制流程的流。
  • Assign Parking Space 是个局部人工任务，如果该决策求值为 True，Office Administration 将在此任务过程中为新员工选择停车位。
  • 然后一个合并元素将该决策的 Yes 和 No 输出带回到一条单一路径。
  • Assign Phone 是个局部人工任务，Telecommunications 在此任务过程中向新员工分配电话分机。
  • Grant Network Access 是个局部人工任务，Network Security 在此任务过程中为员工创建用户 ID 和密码。
  • Schedule Training 是个局部任务，它自动分配员工参与标准公司培训。
  • Generate Summary of New Hire Details 是个局部任务，有一个自动服务将在此任务过程中为新员工的经理生成摘要报告。
图 1. 上岗业务模型
图 1. 上岗业务模型

探索该业务模型以后，将其导出到 WebSphere Integration Developer 以生成 WS-BPEL、XSD、WSDL 和运行时需要的其他构件：

  1. 右键单击 Onboarding - ToBe 并选择 Export...
  2. 选择 WebSphere Integration Developer 作为导出目标，然后单击 Next。
  3. 输入导出目录。确保选择 Export Specific Elements，并且仅选择导出 Onboarding - ToBe，然后单击 Next。
  4. 接受屏幕上的所有缺省设置，然后单击 Next。
  5. 您将看到将包括在报告中的所有内容的列表。单击 Finish。
  6. 当您看到消息“Export finished successfully”时，请单击 OK。

现在可以将项目交换导入 WebSphere Integration Developer。缺省情况下，Modeler 将向项目交换名称的结尾追加时间和日期字符串，因此您可以轻松判断它是在何时导出的。要导入项目交换文件，请执行以下操作：

  1. 启动 WebSphere Integration Developer。
  2. 在业务集成项目资源管理器的空白区域单击鼠标右键，选择 Import...
  3. 选择 Other - Project Interchange，然后单击 Next。
  4. 对于“From zip file”字段，请单击 Browse，然后导航到您从 Modeler 导出项目的目录。单击选择该 Modeler 导出的 .zip 文件，然后单击 Open。
  5. 单击 Select All，然后单击 Finish。
  6. 全部三个项目将导入 WebSphere Integration Developer。等待 Building Workspace 指示器到达 100%。

三个项目都已导入工作区中：

  • OnboardingModelingProject_lib：包含数据类型和接口的库项目。该业务流程在整个过程中使用单个业务项，因此只有一种数据类型。为每个任务生成了一个接口。
  • OnboardingModelingProject_impl：引用 OnboardingModelingProject_lib 的模块。此模块包含三个自动步骤的实现，这些步骤转换为 Java™ 组件。集成开发人员将负责实现这些组件。
  • OnboardingModelingProject：引用 OnboardingModelingProject_lib 的模块。此模块包含 BPEL 流程、该流程的规则组和规则逻辑。

在从 Modeler 导出时，您可能选择了将所有这些元素放在单个项目中的选项，但是将它们分离（推荐的做法）可以使得做出更改更加容易。例如，如果您已部署了模块并且需要更新其中一个 Java 组件，这种安排将使您无需重新部署流程即可重新部署 Java 组件。

流程的 WS-BPEL 表示形式（请参见图 2）与业务模型类似，因为存在连接在一起的步骤以及条件分支逻辑。业务模型用于文档记录和流程改进，而 BPEL 版本则是可执行的。该流程已准备好运行，但是首先必须完成 Java 组件。

图 2. 在 WebSphere Integration Developer 中编辑的 BPEL 流程
图 2. 在 WebSphere Integration Developer 中编辑的 BPEL 流程

更新场景

在将项目从 Modeler 导出并导入 WebSphere Integration Developer 以后，存在对其中任一种模型做出更新的可能性，并遵循以下三种场景之一：

  • 技术更新：在 BPEL 模型中对技术属性做出更新，同时集成开发人员负责完成实现。
  • 后期更新：在已将业务模型导出以后在业务模型中做出更新。
  • 往返更新：业务模型在系统投入生产运行以后继续发展，需要对技术实现进行更新。

下面将详细研究这其中每一种场景。

技术更新

并非 WebSphere Integration Developer 中可用的每个属性均可以由 Modeler 生成。因此，在解决方案完成并准备好运行之前，您需要对导出的大多数模型做一些工作。在此例中，WS-BPEL 流程已经完成，但是 Java 组件需要做一些工作后才能使用。

更新 Java 组件

  1. 在 OnboardingModelerProject_impl 模块中，展开 Business Logic 文件夹，然后展开 Java Usages 和 processes/onboarding。
  2. 双击 AddToPayrollSystemImpl 以在 Java 编辑器中将其打开。
  3. 滚动到底部并将下面的行：
    //TODO Needs to be implemented
    替换为：
    System.out.println("Adding to payroll...");
  4. 将行：
    return null
    更改为：
    return Input
  5. 保存更改。

AddToPayrollSystemImpl.java 的最后几行现在应该类似于清单 1 所示。

清单 1. AddToPayrollSystemImpl.java（部分清单）
public commonj.sdo.DataObject AddToPayroll(commonj.sdo.DataObject Input)  {
	    System.out.println("Adding to payroll...");
		return Input;

对 GenerateSummaryImpl 和 ScheduleTrainingImpl 重复此过程。如果希望进行测试，可以现在部署并运行该流程。

更新业务规则

假设您作为集成开发人员，发现业务分析人员忘了在业务规则定义中包括某个位置。您可以按照类似如下的方式更新业务规则：

  1. 在 OnboardingModelingProject 中，展开 Business Logic 文件夹，然后展开 Rule Logic 和 processes/onboarding。双击 applyRules 以编辑该规则集。
  2. 在规则编辑器中，向下滚动到 Rules 部分。现有五个规则，其中三个基于规则模板。通过单击“添加模板规则”图标添加模板规则图标从模板创建新规则。可以做出选择的模板列表将显示出来。选择 LocationParkingTemplate，在此例中，这是唯一的选项。在该列表的底部添加一个名为 Rule6 的新规则。
  3. 在 Rules.Input.Location 的第一行上，单击 Enter Value，然后输入城市名称，例如 Ann Arbor。
  4. 在 Rules.Output.Parking 的第二行上，单击 Enter Value，然后输入 Yes。
  5. 该规则现在应该与图 3 所示类似。保存更改。
    图 3. 更新后的业务规则
    图 3. 更新后的业务规则
  6. 该业务规则现在已更新。关闭规则编辑器。

更新业务流程

假设您发现工资单系统存在一个漏洞，在分配办公空间之前将无法添加新员工。您必须更改流程中的这两个步骤的顺序，以便工资单服务能够正常工作。

  1. 选择 Add To Payroll System 和 Assign Office Space 之间的链接，然后按 delete 键将其删除。
  2. 将人工任务 Assign Office Space 移到侧面。
  3. 单击从 Assign Office Space 流出的链接以选择它。链接顶部和底部将显示一个点，表示您可以移动它。单击连接器的顶部并按住鼠标键，移动连接器以使其现在从 Add To Payroll System 连接到 Apply Location Rules。
  4. 单击从 Capture New Hire Information 流出的链接以选择它。单击链接底部并将其移动到 Assign Office Space 的顶部。
  5. 添加一个从 Assign Office Space 到 Add To Payroll System 的链接。
  6. 移动任务以将它们排列整齐，或者单击鼠标右键并选择 Arrange Parallel Activities Contents。

两个任务的顺序现在已颠倒过来，如图 4 所示。

图 4. 更新后的流程
图 4. 更新后的流程

或者，您确定在同一个事务中运行最后两个自动活动将会更加高效。

  1. 单击名为 Schedule Training 的调用，然后单击 Properties 选项卡，再单击侧面的 Server 子选项卡。
  2. 选择 Participates 所对应的单选按钮。这将指示不在该活动完成后提交当前事务。
  3. 单击 Generate Summary of New Hire Details，并导航到属性中的 Server 子选项卡，以验证已选择了 Commit After。这告诉服务器在此活动完成后提交当前事务。

该流程现在已更新。保存更改，并关闭流程编辑器。

同步模型

WebSphere Integration Developer 中的实现模型已发生了更改。这意味着该模型与业务模型不再保持同步，因此现在必须重新同步两个模型。

  1. 右键单击 OnboardingModelingProject，并选择 Synchronize with Modeler Export...
  2. 在 Synchronize 窗口中，单击 Browse... 并选择您最初从 Modeler 导出的项目交换文件，然后单击 Next。
  3. 您将看到交换文件中的项目和工作区中将要比较的项目。单击 Synchronize 以查看更改列表。如果看到有关同步信息的提示，请单击 OK 以清除该提示。
  4. 您将看到多个工作区更改，表明您自从最初导入项目交换以来已对工作区做出了更改。单击 Commit。
  5. 系统将提示您已生成了更改报告。这是您将需要发回到 Modeler 的文件。单击 Yes 以导出此文件。
  6. 在弹出的向导中，已自动为您选择了该模块。单击 Browse... 以选择要在其中存储更改的文件。该文件的扩展名必须为 .zip。单击 Finish，然后导航到您选择的目录，以确认新文件存在。如果系统没有足够的内存同时运行两个工具，您现在可以关闭 WebSphere Integration Developer 以节省内存。
  7. 启动 Modeler 以便能够应用更新。确保您处于 WebSphere Process Server 模式。您需要的上下文菜单只有在此模式下才是活动的。
  8. 右键单击 Onboarding Modeling Project 并选择 Analyze Model Implementation Changes...
  9. 将打开一个窗口进行更改分析。单击 Browse...，然后选择您在步骤 6 中导出的更改文件，并单击 Open。然后您可以单击 Next 以移至下一个面板。
  10. 选择您希望分析的元素。单击 Select all，然后单击 Finish。
  11. 一个新的 Change Analysis View 选项卡将在 Modeler 中打开（请参见图 5）。展开所有文件夹以查看所有的更改。
    图 5. 更改分析视图
    图 5. 更改分析视图
  12. 检查更改列表。并非对技术模型做出的每个更改都会反映在更改列表中，因为业务模型并不表示技术模型中的每个可能属性。例如，业务模型没有映射到事务性控制的属性。此类更改不会流回业务模型。但是，对任务顺序的更改确实会流回业务模型。
  13. 您可以应用或忽略任何更改。单击其中一个更改以查看其详细信息，如图 6 所示。
    图 6. 更改详细信息
    图 6. 更改详细信息
  14. 目前，必须手动做出这些更改。遍历更改列表，并在业务模型中做出适当的更新。在做出每个更改时，您可以单击它并选择 Change Applied 以指示您已完成该更改，或选择 Change Ignored 以指示您发现该更改与业务不相关。

做出更改以后，该流程现在应该与图 7 所示类似，并且 Assign Office Space 人工任务现在已在 Add To Payroll System 之前。

图 7. Modeler 中更新后的流程
图 7. Modeler 中更新后的流程

局限性

对技术属性的更改未在业务模型中得到反映的事实不应视为局限性。因为那些属性不是业务模型的一部分，因此没有可供更改的内容。对 Java 组件的更新也是如此。Modeler 仅知道某个任务将被导出为 Java 组件。Modeler 中没有任何内容反映将要使用的实际 Java 代码。这些更改对业务模型来说不是业务相关的。

但是，对业务规则的更新可能已经反馈到业务模型中，但是却未在更改列表中得到反映。此局限性已在 Version 6.1.2 得到消除。

另一个局限性在于，并非 WebSphere Integration Developer 中的每个构造在 Modeler 中都有等效的构造。例如，如果将流程更新为使用循环流构造，则没有办法将该更改传播回 Modeler。

后期更新

在后期更新场景中，业务分析人员在已将业务模型导出到 WebSphere Integration Developer 以后对业务模型做出更改。对于此示例，假设分析人员注意到 Schedule Training 任务需要一个新数据字段。此外，分析人员认识到，使用当前的程序，门卫也可以获得停车位。仅当位置业务规则求值为 True，并且工作代码不等于“J01”时，该流程才应该继续流向 Yes 路径。

更新业务模型

要支持所需的更新，请打开 Modeler 并进入带有 Onboarding Modeling Project 的工作区。

  1. 展开 Business Items 文件夹，并双击 New Hire Information 以便您能编辑它。
  2. 单击 Add 以便将一个新属性添加到列表底部。
  3. 单击缺省名称 Attribute 以选择它，然后输入 Schedule Date。
  4. 单击 Schedule Date 的类型 Text。该字段右侧将显示一个按钮。单击该按钮以选择类型。选择基本类型 Date，然后单击 OK。如果看到要求您确认该操作的警告，请单击 OK。
  5. 保存并关闭 New Hire Information。

下一步，需要更新决策逻辑。在执行此步骤之前，请确保您处于中级模式或更高级模式。在基本模式下不能设置决策逻辑。

  1. 选择决策 Assign Parking Space? 并单击 Attributes 选项卡。
  2. 单击 Output branches 子选项卡，然后单击 Yes 以选择最顶上的输出。滚动到属性的底部，您将看到决策中当前使用的表达式：

    'Processes.Onboarding - ToBe.Assign Parking
    Space?.Input:2.Parking' is equal to "Yes"

  3. 单击 Edit... 以更改该表达式。此时会打开表达式编辑器。
  4. 单击 Add 以添加另一个表达式。缺省设置是对两个表达式执行逻辑“与”操作，这就是本例中需要的设置。
  5. 对于第一个条件，请选择 Modeling artifact。在下面的列表中，选择 Job Code。
  6. 对于运算符，请选择 is not equal to。
  7. 对于第二个条件，请选择 Text，然后将文本值替换为 J01。该表达式现在应该与图 8 所示类似。
    图 8. 表达式编辑器
    图 8. 表达式编辑器
  8. 单击 Apply 以使用这些值更新该表达式。（如果不单击 Apply，您的工作将会丢失！）
  9. 单击 OK 以关闭表达式编辑器。

该表达式现在应该为：

请单 2. 编辑后的表达式
( 'Processes.Onboarding - ToBe.Assign Parking 
Space?.Input:2.Parking' is equal to "Yes" )
AND ( 'Processes.Onboarding - ToBe.Assign Parking 
Space?.Input:2.Job Code' is not equal to "J01" )

通过这两个更新，该业务流程现在已是最新的了。现在可以将其导出到 WebSphere Integration Developer 了。

  1. 右键单击 Onboarding - ToBe 并选择 Export...
  2. 对于类型，请选择 WebSphere Integration Developer，然后单击 Next。
  3. 确认导出方向，并且 Onboarding - ToBe 已选中，然后单击 Next。
  4. 与前面一样保留缺省值 Recommended Export Option。这次，更改 Project Interchange Name，以便您知道这是该流程模型的更新版本。将该名称更改为 Onboarding Update，然后单击 Finish。
  5. 当您看到消息“Export finished successfully”时，请单击 OK。

如果系统没有足够的容量同时运行两个工具，您现在可以退出 Modeler 并启动 WebSphere Integration Developer。

  1. 在 WebSphere Integration Developer 中，右键单击 OnboardingModelingProject，并选择 Synchronize with Modeler Export...
  2. 对于 PI .zip 文件，请单击 Browse... 并导航到您先前从 Modeler 执行导出的目录。选择 Onboarding Update 文件并单击 Open。然后您可以单击 Next 以验证项目交换文件中的项目是否与工作区匹配。
  3. 单击 Synchronize。如果您接收到有关同步对话框的弹出消息，请单击 OK 以将其清除。
  4. 在受影响的构件列表中，单击 NewHireInformation。您将看到已添加了 ScheduleDate 字段。右键单击 The field "ScheduleDate[xsd:date]" was added 并选择 Apply 以接受此更改。
  5. 单击 Onboarding 流程。您将看到几个与重新定位该任务相关的更改。尽管此更改是在 WebSphere Integration Developer 发生的，但您仍然更新了业务模型，从而导致更改显示在列表中。右键单击其中每个更改并选择 Apply。
  6. 流程的 Valid from date 已更改，因为它被设置为从 Modeler 执行导出时的日期和时间。此日期用于在运行时对流程进行版本管理。如果您希望将版本保持相同，可以右键单击此更改并选择 Reject。如果不介意用于版本管理的不同日期，您可以接受此更改。
  7. 对决策的更新显示在内容如下的行中：

    body property on Condition was changed...

    右键单击其中每个更改并选择 Apply。

  8. 有一个更改针对事务行为。从 Modeler 导入该版本可能会覆盖您在 WebSphere Integration Developer 中做出的更新。
  9. 有一个更改涉及到业务规则的额外模板实例。您会希望拒绝此更改，因为它是您添加的。但是，拒绝选项已显示为灰色。只需跳过此更改即可。
  10. 还有几个与导入相关的更改。可以接受所有这些更改，但是拒绝选项已显示为灰色。这些更改涉及到由于不同数据类型而导致的导入更改。您可以接受其中每个更改。
  11. 单击 Commit 以提交更改。

Modeler 中的更改将自动流入 WebSphere Integration Developer。

  1. 编辑 OnboardingModelingProject_lib 中的 NewHireInformation 业务对象。该业务对象现已包括 ScheduleDate 字段，如图 9 所示。
    图 9. 更新后的业务对象
    图 9. 更新后的业务对象
  2. 编辑 Onboarding 流程。选择 Schedule Training，单击 Attributes 选项卡，然后单击 Server 子选项卡。仍然选择 Participates 单选按钮。
  3. 单击从 Apply Location Rules 到 Assign Parking Space 的链接。在 Attributes 选项卡中，单击 Details。该逻辑包括用于工作代码 (Job Code) 的表达式。

对业务模型的后期更改已流入技术模型。接受或拒绝每个更新的能力不仅使集成开发人员可以引入更改，而且还可以保留他们在第一次从 Modeler 导入模型以后可能已做出的更新。

局限性

在从 Modeler 到 WebSphere Integration Developer 的流中，在此例中发现的唯一局限性在于，其中某些更改无法拒绝，只能接受。如果要接受或拒绝，集成开发人员必须了解每个更改及其影响。

往返更新

建模工具的往返更新是人们期待已久的目标。在往返场景中，业务模型已经完成，技术模型也已完成，并投入了生产运行。基于流程改进或新的需求，业务模型需要发展，从而驱动对技术模型的更改。

换句话说，这实际上只是上面演示的后期更新场景的一种特殊情况。区别在于，应该维护原始版本的副本，以便开发团队拥有生产中正在使用的版本的副本。可以采用两种基本方法保留相同项目的不同副本：

  • 使用诸如 IBM Rational® ClearCase® 等版本控制系统。可以在 ClearCase 中将已完成项目的工作区存储为版本 1。当将业务模型中的更新引入项目时，可以将项目存储为版本 2。这将使开发人员能够取出任何一个版本进行处理。
  • 复制工作区中的原始模块，并将它们重构为新名称，以反映它们是原始版本。然后您可以并入业务模型中的更改，并继续开发周期。

局限性

针对技术更新和后期更新场景指出的所有局限性也适用于往返更新场景。

结束语

本文讨论了使用 Modeler 和 WebSphere Integration Developer 进行的开发周期。本文探索并演示了模型被更新的场景，并说明了如何将 WebSphere Integration Developer 中对模型的更改反馈回业务模型中，以及如何将 Modeler 中的更改引入 WebSphere Integration Developer，同时不必覆盖可能已在之前做出的任何更新。

回页首

下载

描述名字大小
示例代码OnboardingModelingProject.zip295 KB

参考资料

条评论

关闭 [x]

developerWorks: 登录

标有星（*）号的字段是必填字段。


需要一个 IBM ID？
忘记 IBM ID？


忘记密码？
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。

 

在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

关闭 [x]

选择您的昵称



当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

标有星（*）号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 

所有提交的信息确保安全。

回页首

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=372597
ArticleTitle=WebSphere Business Modeler 和 WebSphere Integration Developer 中的迭代开发
publish-date=03192009