使用模型设计业务流程和服务

使用建模工具装配各种组件

概览业务流程和服务的设计,涉及的角色和工具,以及可以使用各种软件工件的工作流程。作者重点展示了在业务流程和服务中装配参与者和服务的优势,并提供示例来演示不同的模型在各种工具(用于生成可部署的工件)上的效果。她还说明了实现出色结果的技巧,包括从不完整的模型开始,并且总结了在装配流程和服务时使用的 SoaML 建模实践。

Tanya Wolff, 软件质量开发人员, IBM

作者照片Tanya 是一名 Rational 软件架构师和绿色线程系统验证测试团队的开发人员。她使用 IBM Rational 和 WebSphere 工具,根据在协作式环境中进行部署的需求开发端到端场景,通过这些测试了业务驱动开发绿色线程和产品集成。



2012 年 11 月 29 日

下载 Rational® Software Architect 试用版  |  Rational® Software Architect Design Manager 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

选择您的装备

随着企业不断增长,企业要适应行业方向和技术发展的变化,业务流程架构师必须持续分析和优化当前的解决方案。通过开发新的战略来自动运行各种服务或改进流程,同时跟踪业务愿景和最大限度发挥重用的威力,架构师和开发人员可缩短需求与实现之间的距离,不断地提供更有效、可跟踪、灵活和可用的解决方案来支持业务集成与敏捷性。随着 IBM 推出了 IBM® Business Process Manager Version 7.5 和 IBM® Rational® Software Architect Version 8.0.4 中以业务为中心的功能,软件设计师可在其工具包中采用并集成新的装备。

构建一个业务解决方案首先需要分析当前的业务流程以及支持该流程的 IT 服务。然后确定哪种方法最适合实现您的业务目标,方法是选择面向服务的架构或业务流程管理方法,无论使用 SOA 还是 BPM,要牢记的是,架构和开发生命周期中都需要这两种方法。架构师要了解工具的各种功能、最佳实践以及某种业务相关的基础架构,同时能分析解决方案的缺点并提供解决方案设计战略。开发人员还可以选择不同的技术或工具来满足各种需求,将解决方案带入部署阶段,并对解决方案进行维护治理。开发人员在面对不同的侧重点时可能有不同的选择,比如关注用户界面时要考虑美观的问题,如果产品上市速度很关键,则需要能快速完成开发工作的技术或工具。

图 1 中的概述图展示了两种方法中涉及的工具,包括建模、实现、模拟、部署和治理。首先使用 Rational Software Architect 对业务流程或服务进行建模,然后根据需要使用 Business Process Manager Process Designer 进行分析和优化,使用 Rational Software Architect 转换工具生成代码存根 (stub),然后使用 Business Process Manager Integration Designer 继续实现解决方案。已完成的流程应用程序或服务的目标是 Business Process Manager Process Server。各种服务器和应用程序可存储在 Business Process Manager Process Center 中。图 1 展示了该流程。

图 1. 业务流程设计拓扑结构图
流程图

在 SOA 方法中,通过定义需求和功能,各种商业动机和目标驱动着解决方案的设计,这些动机和目标是服务 的候选者。Rational Software Architect 用于将商业目标确定为用例,并定义在服务架构 中实现这些目标的战略,组成这种架构的参与者 使用和提供服务。借助可重用的部件,SOA 允许企业实现更好的互操作性和可分配性,通过将接口与实现分开,提高了适用性。

提示:
要想使用 Rational Software Architect 构建 SOA 解决方案,可使用一个服务设计模板创建 UML 模型,该模板中附带了每个创建步骤的说明。

BPM 架构师首先建模业务流程,识别所涉及的资源编排 (orchestration),看看可在何处改进流程。通过从这些协作中提取已提供的所需接口(通过转换 到服务模型)来改进解决方案。然后在参与者和服务的包层次结构中详细制定解决方案的结构。BPM 让流程模型和执行变得更紧密了,通过质量保证要求促使实现更敏捷的解决方案。

提示:
要想使用 Rational Software Architect 构建一个业务流程管理 (BPM) 解决方案,可使用流程模板创建一个 BPMN 项目,或者如果愿意设计多个协作流程,可以使用一个协作模板。要想使用 IBM Business Process Manager Process Designer 构建解决方案,可在 Process Center 中创建一个新的流程应用程序,并在 Process Designer 中打开该应用程序。您需要使用 Business Process Manager 7.5.1 版本导出 Business Process Modeling Notation 2.0 (BPMN 2.0) 模型,该模型将被导入到 Rational Software Architect。(使用 Process Designer 7.5 版时,只能导入 BPMN 2.0 模型。)

进行建模时,两种方法经常会交织在一起。因此,可以将某个流程视为一个服务,反之亦然。一个流程是由引用服务的多个活动组成的;可通过活动图或流程详细描述每个服务。使用 SOA 方法,架构师可以选择使用 BPMN 流程来描述服务架构中的服务合约,并展示参与者如何使用和提供这些合约中指定的服务。调用 BPM 方法的 BPMN 模型中可能包含 IT 服务。如果的确如此,那么架构师会使用 SoaML 模型详细描述流程的活动和服务接口。所以 IT 服务可能仍需要全部或部分人员参与工作。

无论采用哪种方法,在解决方案中涉及各个参与者协作的地方,SOA 和 BPM 方法都要完成设计并开始在 SOA Modeling Language (SoaML) 中装配流程或服务,并将其表示为 Rational Software Architect 产品描述。本文中的示例引用了 SoaML 工件中的装配参与者 (Assemble participant) 任务。


装配一个流程或服务解决方案

能够在业务驱动开发的建模阶段装配各个参与者,这让设计师可以更好地控制不同角色的成员为特定实现所选择的开发方向。参与者公开为其提供的服务并通过端口 表示所需的服务。端口的类型是服务接口,描述了可用的操作及其输入和输出参数。各个参与者在单独参与者的复合结构图 中被装配起来,即复合或装配参与者。该参与者的内部结构会收集协作参与者的实例,将其作为装配参与者的属性。

在复合结构中,通过服务通道 连接参与者实例上的端口,该通道封装了参与者之间的相互作用。这些实例和服务命令 Rational Software Architect 中的 UML-to-SOA 转换 工具创建各种实现工件,并设置已装配的解决方案实现中的绑定信息。

正在开发的另一个流程或服务解决方案可能使用部分或所有的相同参与者,或者使用新的参与者和不同的实现方法,该方法公开相同的接口,以满足不同的业务需求。


使用建模工具进行装配的收益

作为流程或服务开发中的基本步骤,使用 Rational Software Architect 8.0.4 中提供的建模工具装配各个参与者并创建任务,这样做可从多个方面受益,如以下小节所述。

高效

SOA 和 BPM 架构师可将完整的服务模型转换为实现工件,并将其传递给集成开发人员,以便继续完成 SOA 开发生命周期流程。在推出 Rational Software Architect 8.0.4 之前,装配参与者的任务是由担任这两个角色的人员执行的;架构师负责建模被装配的参与者之间的连接,在将工件导入 Integration Designer 后,集成开发人员会再次连接各个部分,方法是在每次导入时指定绑定信息。借助 8.0.4 版本中的转换增强功能,可以消除这种重复执行的工作。

Rational Software Architect 现在可将某个流程或 SOA 中的已装配参与者转换为一组 Service Component Definition Language (SCDL) 模块,这些模块通过 Service Component Architecture (SCA) 服务、引用导入和引用导出连接在一起,正确地设置 SCA 连接目标和导入绑定。

可跟踪

已装配的参与者实例代表了协作或解决方案中的规范角色。解决方案中每个组件实例通过端口进行访问,并且其实现通过组件定义中的各种行为来表示,以满足业务目标的规范要求。

在解决方案建模过程中使用 Rational Service-Oriented Modeling and Architecture (SOMA) 流程可改进业务目标的实现。

  • 首先,使用角色和协作来标识实现业务目标所需的各种服务。
  • 其次,通过服务接口和协议来指定服务。
  • 最后,将它们实现为各种组件、端口和服务通道。

从规范的角度看,每个阶段都实现了进一步的改进。

在通过用例和业务模型指定业务流程或需求的地方,服务识别 (Service Identification) 被细化为各种角色和协作。然后将各种角色和协作细化为服务合约以及接口和角色,最后将它们细化为各种服务和行为。

在完成所有细化阶段后完成服务或行为的抽象定义,通过装配参与者 开始实现阶段。该装配任务允许架构师指定不同参与者之间的通信通道,并履行协作中各角色的工作。可轻松地跟踪正在装配的参与者上公开的服务,一直追溯到业务需求或系统用例。

灵活性

能够从服务识别到装配各个参与者来设计服务模型,这解决了设计师应当首先从 SOA 还是 BPM 的角度(还是同时使用二者)来推动解决方案的难题。我们可以在 UML 中设计一个服务架构来标识各个服务,或者在 BPMN 模型中设计一个流程来展示所涉及的活动并确定候选服务。根据所用的方法,可以将装配参与者的工作视为提供一个服务或流程。

从 SOA 的角度看,用例由提供简单服务接口的参与者进行识别,或者由正在装配的参与者(包含两个或多个协作参与者实例)进行识别。

从 BPM 的角度看,业务流程可以很简单,也可以是协作式的。简单的业务流程由单个参与者进行识别,该参与者代表某种业务或业务中的一个部门,而协作式的流程涉及多个部门或业务合作伙伴。

可用性

在考虑组件的目标系统时,部署设计师可同时利用 BPM 和 SOA 的优势。虽然可通过 Java Enterprise Edition (JEE) 模块或 Business Process Execution Language (BPEL) 流程来实现简单的服务或流程,但协作式的解决方案或流程可集成各种实现。根据开发人员的选择,这些实现不仅是可互换的,而且在各种工件中通常是必备的。UML-to-SOA 转换将为公开多个服务的参与者生成一个 BPEL 实现,以便将服务调用路由到合适的服务。在构建全面的业务解决方案时,从 UML 装配如何集成、分发和适应多个方面、服务和技术的要求中就能看到其重要性。


如何转换到 SOA

有了 Rational Software Architect 8.0.4,就能够通过 SoaML 模型中的装配参与者生成 SCDL 和正确的绑定导入,下面将用几个示例展示该转换算法的工作方式。正确的转换结果源自于检查装配组件部分上的服务通道,所提供服务的实现工作委托给该组件。揭示该算法的工作原理有助于您理解某些结果。

转换装配参与者时,Rational Software Architect 执行清单 1 中所示的转换装配算法。

清单 1. 转换装配算法
1.  给定一个复合参与者,在复合的内部结构中查找该参与者的实例,已根据参与者的端口委托该复合结构。
2. 对于每个实例委托:
       a.  使用 SCDL 组件和导出创建一个 SCA 模块
       b. 查找通过服务通道连接实例的所有参与者实例。
       c.  对于每个实例
             i.  在当前模块中创建一个 SCDL 导入并设置绑定属性。
            ii.  检查实例的类型。
           iii.  如果具有一个复合结构,则调用转换装配(递归)。
            iv.  否则,使用一个组件和导出创建一个 SCA 模块。
图 2. 转换装配参与者的流程图
工作流程图

该算法会在委托树中的每个参与者中递归执行,遍历这些连接,创建 SCA 模块。递归过程在遇到一个没有内部结构的简单参与者时结束;也就是说,该参与者不需要任何接口。


示例

为了演示转换的内部工作原理及其限制,我们需要设计多个参与者的示例,最少应该有三个参与者。这需要装配这些参与者并且协作中至少涉及两个参与者,并且在参与者之间的单个服务通道中进行会话。

屏幕截图显示了应用转换工具前 Rational Software Architect 中的模型,以及完成转换后在 Integration Designer 中生成的 SCA 结构。如果因为错误的装配模型而导致转换产生奇怪的结果,则会为 Integration Designer 用户提供一个恢复技术选择,以便能够使用给定的工件。

三种 SoaML 设计展示了在 IBM Integration Designer 中成功转换已装配参与者的结果:

  • 简单 演示了最简单的协作:两个已装配的参与者,一个委托的已提供接口 (provided interface)。
  • 嵌套 演示了嵌套的装配参与者。每个装配参与者有一个委托的已提供接口和两个已装配的参与者。
  • 双重 演示了具有两个已提供接口的解决方案。它可表示一个具有两个入口点的业务流程,更有可能的是表示一个提供多个服务接口的 SOA 解决方案。

第四个设计展示了当前转换的限制,提供了一个不完整的装配。

  • NoDelegate 演示了装配参与者的效果,但是装配参与者既未提供服务,也没有委托其某个部分。该设计是不完整的,并且 Rational Software Architect 不会给出任何警告,所以架构师要将结果提供给开发人员。该示例提供了开发人员应使用哪些技巧在 Integration Designer 中完成模型。

当然,其他设计也是可能的。例如,更为复杂的会话可能在同一流程中的参与者之间需要更多的端口和服务通道,更多的抽象和识别才能实现更深的嵌套级别,当然,也可以提供更多的参与者,以便实现用例或业务流程设计所需的更多服务或流程。

两个参与者的简单协作

该模型展示了两个参与者;第一个将 UML 活动作为其行为,调用第二个参与者中的某个操作。SoaML 指导原则强调要最大限度减少耦合,因此所有连接都位于端口之间。某个委托连接要将内部端口连接到装配参与者上具有相同类型的端口,而服务通道要将请求端口连接到装配参与者的结构中的服务端口。

图 3. 装配一个简单协作
模型示意图

对该模型进行 UML-to-SOA 转换可生成 SCA 模块和一个库。com.simple.Part1.Participantcom.simple.Part2.Participant 模块每个都有一个组件和导出。第一个模块还包含组件行为的一个 BPEL 实现,还有一个引用第二个模块上所需服务的导入。该导入的绑定属性带有模块和导出名,指向第二个模块上的导出(com.simple.part1.Participant 中的导入绑定到 com.simple.part2.Participant 的导出)。

图 4. 简单协作的 SCA 组件
SCA 模块图与导入属性

嵌套的参与者

该 UML 模型展示了三个参与者:第一个参与者请求第二个参与者,第二个参与者则请求第三个参与者。该 UML 模型中有两个装配:A1 和 A2。A2 是嵌套装配,其中包含第二个和第三个参与者。

图 5. 装配嵌套的参与者
A1 复合模型与嵌套的 A2

转换生成的输出内容展示了算法中的递归流程。这些模块对应于 Participant、Participant2 和 Participant3。虽然在 UML 模型中有五个参与者,但转换只生成了三个 SCA 模块。装配各个参与者的目的是指定委托模块导入的绑定属性,如图中的 Integration Designer 所示。

图 6. 嵌套装配的 SCA 组件
3 个 SCA 模块和绑定属性

双重委托

该 UML 模型展示了两个参与者。每个参与者有一个接口,并且都在请求对方。下面是架构师认识到的在 BPM 和 SOA 方法间进行协同的好处。BPM 架构师会设计一个流程,其中装配参与者的名称反映了协作参与者与哪个流程进行会话。但是在这个示例中,是按照出色装配实践的指导方针进行设计的,其中为装配内的所有已提供接口添加了一个委托连接器(否则无法进行连接)。这类似于 SOA 解决方案:提供一组接口,而不是单个流程。设计师为戴了 SOA 的帽子而自鸣得意,但戴了 BPM 帽子的设计师会变得很紧张。还是戴着 BPM 的帽子吧,因为这会让您更轻松地理解转换。

图 7. 装配多个服务
UML 模型由 2 个委托组成

点击查看大图

图 7. 装配多个服务

UML 模型由 2 个委托组成

转换 UML 装配参与者之后,得到的 SCA 为复合结构中的每个参与者提供了一个 SCDL 模块。每个模块包含一个导入绑定,连接到其他模块的导出。这种结果可能让 SOA 架构师感到迷惑,因为它仍生成两个模块,每个流程一个模块,以满足 BPM 风格的要求。

图 8. 多个服务的 SCA 组件
2 个 SCA 模块与 SCA 导入绑定

注意:
这些示例只在接口级展示了流程和所提供的服务。从理论上讲,每个接口中会提供多个操作。但是,BPM 风格的解决方案在表示流程的接口中应该只有一个方法,而在 SOA 中,一个参与者可实现多个方法,并在一个接口中或单独的接口中公开这些方法。如果 SOA 架构师更希望在生成的 SCA 中看到单个模块,那么他们可设计一个使用前两个参与者的新参与者,提供任意数目的服务,并将所有三个参与者都包装到第四个装配参与者中。然后通过服务通道将两个最初公开的接口连接到第三个参与者。

图 9. 使用多个服务装配各个组件
具有 3 个参与者实例的复合结构

得到的 SCA 具有最初的双重委托示例中的原始构建块,以及导入两个参与者的新模块。

图 10. 使用多个服务的 SCA 组件
3 个 SCA 模块和导入绑定属性

点击查看大图

图 10. 使用多个服务的 SCA 组件

3 个 SCA 模块和导入绑定属性

没有委托的装配

该 UML 模型装配一个简单场景中的多个参与者,但其中没有委托。

根据服务建模模板说明中的指导方针,装配参与者应该创建一个连接到所有已提供接口的委托连接器(否则无法连接到请求端口)。该示例展示了未完成的模型会发生什么情况。

图 11. 没有委托的装配
没有委托连接器的 UML 复合结构

转换为装配工作中的每个参与者生成了构建块模块,以及单独的装配模块,但没有在装配模块中生成正确的导入。得到的组件实现在装配中,而不是在它自己的模块中,所以应该避免使用此工作流程。最好让各个组件断开连接。准备好将服务委托到特定的实现之前,不要在某个装配中包装它们。

图 12. 未导出的 SCA 组件
所有 UML 参与者的 SCA 模块

规避方法

如果无法访问原始模型来添加委托或删除装配参与者,可采用不同的方法在 Integration Designer 中纠正该模块的问题。

在 Rational Software Architect 8.0.4 中,目前您会看到所生成的三个模块:

  • com.noDelegate.Part1.Assembly
    包含两个组件和一个导出。没有连接到导出的连接,因为 UML 模型中没有委托。其中一个组件在其 SCDL 表示中具有 BPEL 实现,指向 com/noDelegate/Part1/Participant.bpel 文件,该文件在此模块中不存在。该组件的 SCDL 包含以下代码:
<implementation xsi:type="process:ProcessImplementation">
 <scdl:implementationQualifier xsi:type="scdl:Transaction" value="global"/>
 <process bpel="com/noDelegate/Part1/Participant.bpel"/>
</implementation>
  • com.noDelegate.Part1.Participant

包含一个在其 SCDL 中没有实现内容的组件,一个接口类型为 com.noDelegate.Part1.ServiceInterface 的导出,以及一个接口类型为 com.noDelegate.Part2.ServiceInterface2 的导入。但是绑定没有指定目标模块/导出。在 com/noDelegate/Part1 目录中有一个 BPEL 文件。

  • com.noDelegate.Part2.Participant
    包含一个组件和一个导出。

转换工作按照预期创建了一组构建块模块,但还为装配参与者生成了一个模块。该模块尝试装配实际的各个构建块,而不是导入这些构建块模块的引用。这会导致组件的实现最终位于错误的地方。

您必须决定是否要在装配模块中隐藏各个构建块,方法是选择使用 com.noDelegate.Part1.Assembly模块,或者保留各个构建块,方法是选择使用 com.noDelegate.Part1.Participantcom.noDelegate.Part2.Participant模块。

装配模块中各个组件的方法是自顶向下 的方法,类似于组成 UML 中的子结构组件。子结构复合与模块重用指导方针相矛盾,只在复合结构以外从不需要某些部分时才使用,无需单独创建可部署的组件。要使用自底向上 的方法构建协作方案,则要执行转换工作所完成的各个步骤(如果在 UML 中正确创建了模型)。构建块仍保持不变并且位于正在构建的装配模块的外部。

根据所选的方法执行步骤,完成 ID 中的协作。

自顶向下的规避方法

一个装配模块由多个内部连接的组件组成。

  1. 将 BPEL 从 com.noDelegate.Part1.Participant 模块移到 com.noDelegate.Part1.Assembly 中。您可在 Navigator 视图中复制整个文件夹层次结构。确保已将 ParticipantArtifacts.wsdl 文件复制到与 BPEL 相同的文件夹中。
  2. 清除 com.noDelegate.Part1.Assembly 模块并重新构建它。通过在装配图中双击组件,确保 BPEL 的位置正确无误。该操作会打开 BPEL 图。
  3. 按照错误标记中的建议修复组件属性中的新错误。图 13 中的屏幕截图显示了接口的正确属性和引用。
图 13. 校正后的组件中的接口属性
装配图与接口属性
图 14. 校正后的组件中的引用属性
示意图与校正后的引用属性
  1. 将导出与所提供的接口相连。
  2. 删除以下模块:
    • com.noDelegate.Part1.Participant
    • com.noDelegate.Part2.Participant

自底向上的规避方法

将构建块(协作参与者)放在装配的外部,在装配模块中使用导入来引用它们。在本示例中,惟一的构建块是在 com.noDelegate.Part2.Participant 中实现的所需的服务。com.noDelegate.Part1.Participant 是导入构建块的模块。com.noDelegate.Part1.Assembly 模块不是必要的。

  1. 将实现标记从第一个模块的组件复制到第二个模块的组件。
  2. 删除第一个模块 com.noDelegate.Part1.Assembly
  3. 创建一个名为 com.noDelegate.Assembly 的新模块,它具有 SCA 组件和连接到它的 SCA 导出。
  4. 将绑定信息添加到第二个模块 com.noDelegate.Part1.Participant 中的导入。结果与 图 4 中显示的结果类似,即第一个示例中简单协作的 SCA 组件。

复合模块 SCDL 是未完成的。您可以继续实现构建块或组成装配结构的包含组件。完成实现后,您可让它成为一个可部署的 Web 服务,方法是在导出上生成 Web 服务绑定,并将该模块部署到流程服务器。


SoaML 建模指导方针

按照 Jim Amsden 在 "Modeling with SoaML, Part 4. Service Composition"(参见参考资料,查看此五部分系列文章的链接)中提供的最佳实践,在装配参与者时最大限度进行重用并且减少耦合:

  • 使用对已装配参与者的引用来装配其他参与者,方法是将参与者拖放到复合结构图上,从而创建参与者实例。
  • 通过服务和请求端口建模参与者的功能和需求,而不是建模从参与者到服务接口的直接关系。
  • 在装配参与者的内部结构中,使用参与者实例的服务和请求端口之间的服务通道来完成装配参与者所表示的服务或流程的实现。
  • 保持参与者定义和装配建模是单独的事项。组件定义是类级别的,而装配是实例级别的。
  • 为装配参与者使用一个参与者,而不是为对重用所包含的参与者有限制的子系统使用一个参与者。
  • 装配参与者必须至少有一个从公开的服务到内部参与者实例的端口的委托连接器。应该将复合结构图中的所有未连接端口委托给装配参与者上的端口。

结束语

建模面向服务的架构简化了流程或服务解决方案的开发工作,从中可改进或实现业务流程。装配业务解决方案中涉及的各种流程和服务是架构师的任务,并且可在 Rational Software Architect 中执行该任务。在推出 Rational Software Architect 8.0.4 以前,在 SoaML 中建模时建议架构师跳过该装配步骤(参见 IBM BPM integration issues in modeling and transformations of business processes and services architecture),将该任务留给开发人员,让他们在将生成的工件导入 ID 后再完成各个参与者之间的连接。

从 Rational Software Architect 8.0.4 开始,在流程开发的建模阶段连接各个组件要更为高效。这提供了更高的设计灵活性,因为同时为 BPM 和 SOA 架构师提供了工具。通过更平稳的架构师和开发人员集成,在整个服务建模和实现期间维护设计决策的可跟踪性,让产品的可用性变得更高。

本文使用了简单的模型来演示 UML-to-SOA 转换如何生成 SCA 模型、组件、导入和导出,并在根据所需的接口生成的导入上设置导入绑定属性。还提供了在 Integration Designer 中完成 SCA 装配工作的各种技巧,而在 Integration Designer 中无法找到 SCDL 实现和导入属性。我还从各种 developerWorks 文章中收集了一组使用 SoaML 装配参与者的最佳实践。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


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


忘记密码?
更改您的密码

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

 


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

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

选择您的昵称



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

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

标有星(*)号的字段是必填字段。

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=847966
ArticleTitle=使用模型设计业务流程和服务
publish-date=11292012