跳转到主要内容

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

当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

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

  • 关闭 [x]

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

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

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

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

  • 关闭 [x]

停止复制,开始链接

下一代模型管理

Claus Torp Jensen, 高级技术人员, IBM
Claus Jensen
Claus Torp Jensen 是位于纽约州 Somers 的 IBM 高级技术人员。他是 IBM 的 SOA Foundation 团队的成员,从事不同体系结构原则之间的聚合工作。Claus 是 WebSphere Foundation Architecture Board 的一名成员。

在加入 IBM 之前,Claus 作为首席架构师和 SOA 推广人员已经有十年的经验。

Jasmine Basrai, 高级产品经理, IBM
Jasmine Basrai 的照片
Jasmine Basrai 做了 5 年的 WebSphere BPM 高级产品经理。她致力于业务建模、监控和 BPM 终端用户接口。她因 IBM 收购 HOLOSOFX 而加入 IBM,在 HOLOSOFX,她是一名咨询服务经理,成功地实施了很多 BPM 方案。她有 11 年的 BMP 行业经验,热衷于通过创建 BPM 解决方案来推动更多的业务用户交互。
Pablo Irassar, 高级技术人员, IBM
Pablo Irassar
Pablo Irassar 是安大略省多伦多市 IBM Software Group AIM 部门的一名高级技术人员。他是 WebSphere BPM Advanced Customer Deployments (SWAT) 团队的成员。

简介: 本文描述了一种跨越不同建模域、工具和存储库的高效互连建模工件(artifacts)的链接方法,其目的是提供遍及可扩展模型驱动开发环境的一致可见性和可追溯性。

发布日期: 2010 年 8 月 05 日
级别: 初级 其他语言版本: 英文
访问情况 : 2984 次浏览
评论: 


概述

对于任何成功的模型驱动开发(MDD)计划,可见性和可追溯性是两个必不可少的部分,特别是在使用多种建模工具支持不同角色和模型类型的环境中。支持这些必要因素的方法很大程度上是基于一个输出/输入概念或一个全局存储库的概念。然而这两种方法在动态分布式环境中都有严重的管理问题。

早期的互联网和 Web 创始者面临一个类似的挑战,他们选择一个完全不同的方法实现可见性和可追溯性。今天的 Web 是基于这样一种概念,即通过轻量级、标准化的 HTTP 引用链接各类网页,且发现这类引用时常被破坏,以至于为避免过度复制或存储库僵化需要付出很大代价。

本文中,我们将介绍一种跨越不同建模域、工具和存储库的高效互联建模工件链接方法,以提供贯穿扩展 MDD 环境的一致可见性和可追溯性。


简介

随着诸如面向服务架构(SOA)、业务流程管理(BPM)、信息管理(IM)和企业架构(EA)之类模型驱动技术和规则的普及,许多企业自身面临着跨领域和角色管理数量不断增长的模型工件的挑战。模型工件之间关系密切、相互依赖,甚至本质相同的系统也有不同的表示。模型工件引用经常被通过复制或转变模型本身而解决,使其用于不同的工具或领域。这种方法可能造成大量的修改工作,并使跨越环境和工具的持久同步性需求制度化。更糟糕的是,复制模糊了所有权界线,没有考虑到不同类型模型工件的生命周期不同。

正如前面提到的,对于任何成功的 MDD 计划,特别是在使用多种建模工具支持不同角色和模型类型的环境中,可见性和可追溯性是两个至关重要的因素。创建可见性和可追溯性的一种方法是让所有的建模工具使用一个全局存储库。然而,很多情况下,因为相关工具或基础设施组合,或者只是因为不同角色需要不同用户经验,最终导致不同的模型管理需求,这都是不切实际的。


停止复制

跨建模域协作时,以往典型的做法是通过复制交换工件,很多情况下,甚至使用转换。使用这种方法有几个问题,包括:

  • 点到点的专有整合。
  • 转换造成信息丢失或概念不匹配。
  • 跨领域界限无可见性。
  • 由于所有权界线不是很明确,转换管理变得复杂,甚至不可能。
  • 不支持工件生命周期管理。

诸如 BPMN2.0SoaML 之类的行业标准的出现,组成准规范指南,减少转换和专有整合的需求。目前尚没有标准模式能对可管理性问题起到帮助,要真正解决这些问题,惟一的方法是停止复制工件。问题的根本是,当您复制一个工件时,突然出现同一事物的两个截然不同的副本。克隆一个相关但又截然不同的工件,其差别是微妙而严重的。以下例子有助于澄清区别:

  • 复制:在服务建模工具和流程建模工具之间交换服务模型,是为了充分利用服务模型进行流程编排。
  • 克隆:取出一个企业架构流程模块和并将其克隆,作为特定解决方案流程模块的一部分。

在第一个案例中,使用复制方法。不管您使用哪个工具改变服务模型,毫无疑问,您应该同步该改变到另一个工具中,因为两个副本事实上是同一个工件。

在第二个案例中,使用克隆方法,尽管克隆是逐步复制原型(或许是它的一个变形),克隆有自己鲜明的特征和独立的生命周期。即使您为某个解决方案修改了该流程模型,多数情况下,不意味着您需要修改企业标准。尽管如此,从克隆到原型保持一个链接,支持可见性、可追溯性和未来协作仍然很重要。该协作模式的更多细节,参见 Continuous improvement with BPM and EA together(Claus T. Jensen,developerWorks 2010)。

这仅仅是一个例子。它说明了这个事实,当跨越领域界限时,很难有好的理由通过复制进行交换。不管是一个足够提供可见性和可追溯性的简单链接,还是一个有自己独特特征且链接回原型的克隆,都是必需的。


开始链接

是否能通过简单链接处理一个既定状况,或者,是否需要克隆。在这两种情况下,都需要一个标准化中性方式来跨建模域链接工件。此标准化链接是 Open Services for Lifecycle Collaboration (OSLC) 计划 中解决的挑战之一:

  • 链接必须是透明的。
  • 链接必须是双向可见的。
  • 链接必须是版本敏感的。
  • 链接必须是受改变影响较小的。

比起复制,链接提供了一个更加无缝的体验,并提供更好的跨越角色和工具界线的可见性和可追溯性。流程模型能被直接链接到他们编排的服务模型中,相关性对业务分析人员和服务架构师都是可见的。服务可以被链接到它们依赖的信息工件上,且它们对服务架构师和数据架构师都是可见的。企业架构目标可被链接到他们导向和控制的解决方案模型,并且这种关系对企业架构师和任何使用该解决方案模型进行工作的人都是可见的。简而言之,我们需要在任何我们可以使用的工件之间使用透明链接,如图 1 所示。


图 1. 互联网式链接
互联网式链接

甚至在真正需要 “复制” 的案例中,比如,散播一个带有 EA 模板的 BPM 解决方案,原始工件应以一种可追溯、可链接的方式被克隆,而不是通过复制交换。这提供了如下经验:

  • 以人为中心,支持参与者协作,但尊重所有权。
  • 透明的,以多对多的工件关系支持跨领域可见性。
  • 可管理的,使用工具辅助工件链接管理。
  • 协调的,用轻量级协调关注协作而不是尝试繁重的完全同步。

近来,行业已经将注意力放在实现灵活变化上,但是以可管理性为代价的敏捷不是很有用。事实上,现代企业必须面对的挑战是如何通过协作和整体规划实现持续的业务改进,并跨企业交付流程。规划和交付的合并是最强的,确切地说在链接方法中是最强的,因为它允许我们考虑生命周期、领域边界和所有权,甚至提供全部的可见性和协作。关于如何链接 BPM 和 EA 实现更好的业务改善,参见 Leveraging SOA, BPM and EA for Strategic Business and IT Alignment(Claus T. Jensen et al,developerWorks 2008)。图 2 显示了如何链接 BPM 和 EA 的例子。


图 2. 通过灵活链接释放 BPM 和 EA 协作
通过灵活链接释放 BPM 和 EA 协作

规划与交付的结合不仅对 IT 是重要的,对扩展业务范围也很重要。没有适当的跨企业规划和交付流程的整合,业务发展将会是不透明和不协调的。跨建模域管理架构变更不严格,解决方案就会变得很脆弱。

支持链接方法的技术是快速发展的,已经有很多资产管理存储库支持库中资产间的任意点对点关系,并提供社会化协作的基本元素。下一步,链接需要标准化并跨存储库联合 OSLC 访问的各种属性。事实上,基本链接同 MDD 资源控制、工件管理和追踪这些传统元素的合并是未来工作的核心。


结束语

从本质上讲,模型驱动开发需要跨越多种不同建模和工程领域的协作和可见性。每个域都有自己的规范和价值主张,一个模型驱动企业需要确保每个领域同其他领域是相互促进的。在企业级利用此类协作需要建立适当的协作和管理流程。从组织的角度来看,企业需要利用健壮构架规划和敏捷业务优化的强大协作功能。从技术的角度来看,企业需要建立一个平台,通过跨越所有角色和工具,在目标和解决方案之间创建可见性、可追溯性和完整性来实现适当的协作。

经典的用于跨域协作的 “复制变换” 方法在较大的模型驱动企业中伸缩性不是很好。最好的情况是产生一个脆弱且难以维护的模型构架,最坏的是引起错误和不协调工作,这将极大地伤害一个新兴的建模文化。基于健壮的可维护模型构架的跨建模域高效协作,是成功企业实现持续业务性能和服务优化的一个关键分水岭。为此,此类企业需要停止复制,开始链接。


参考资料

学习

  • Continuous improvement with BPM and EA together(Claus T. Jensen,developerWorks 2010 ):这篇文章从业务角度描述了协调和互连 BPM 和 EA 的原则。主要读者是团队负责人和架构师,他们需要理解如何有效地联合 BPM 和 EA,将其作为驱使成功企业实现持续业务改进的一个关键分水岭。

  • Achieving business agility with BPM and SOA together – Smart work in the smart enterprise(Claus T. Jensen, Rob High,Jr.,Steve Mills,2009):这篇文章描述了 BPM 和 SOA 的聚合原则。当 BPM 和 SOA 有自己的价值时,IBM 相信,它们是自然协作的,当它们一同协作时,业务和IT 敏捷、优化和协作达到最好。当它们一同协作时,BPM 提供业务背景、理解和指标,SOA 提供一个良好架构服务和信息建筑块的控制库。事实上,为了动态优化投资,驱使卓越运营和管理商业风险,两者都是必需的。学习如何高效地联合 BPM 和 SOA,是使您的企业实现业务敏捷的关键分水岭。

  • BPM and SOA require robust and scalable information systems – Smart work in the smart enterprise(Claus T Jensen,Rob High,Jr.,Steve Mills,2009):该白皮书从信息系统角度描述了 BPM 和 SOA 的聚合原则。从信息系统角度来看,当 BPM 和 SOA 适当结合时,BPM 带来的卓越业务执行极大地依赖于 SOA 提供的水平事务处理和伸缩。利用这种自然协作的网络效应就是,形成一个可信的、一致的、可管理的交互网络和相互依赖的人、流程、服务和信息资源。本书主要读者是 IT 领导和架构师,他们需要理解如何有效地联合 BPM 和 SOA,来支持业务整合和卓越经营。

  • Leveraging SOA, BPM and EA for Strategic Business and IT Alignment(Claus T. Jensen et al,developerWorks 2008 ):在当今的企业中,将业务与 IT 保持一致来支持业务敏捷性和转换至关重要。通过协作方式一起应用 SOA、BPM 和 EA 可以实现此目标。本白皮书将描述实现该体系结构聚合的关键体系结构和生命周期原则,并建议基于组织的需求和成熟度采用模式。

  • Actionable Business Architecture (PDF)(Ray Harishankar,Kerrie Holley et al,2010):提出和解决了实现业务构架可操作性的因素,并讨论了三个具体观点:策略和转换(S&T),业务流程管理(BPM)和面向服务构架(SOA)。

  • Open Services for Lifecycle Collaboration:访问 OSLC 社区,获取更多信息。

  • Object Management Group Business Process Management Initiative:获取 BPMN 2.0 规范、文章等。

  • Service oriented architecture Modeling Language (SoaML):获取 SoaML 规范和其他相关信息。

  • developerWorks BPM 专区:获取 IBM BPM 解决方案最新技术资源,包括下载、演示、文章、教程、事件、网络广播等。

  • IBM developerWorks 中国 WebSphere 专区:为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库,包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。

获得产品和技术

讨论

作者简介

Claus Jensen

Claus Torp Jensen 是位于纽约州 Somers 的 IBM 高级技术人员。他是 IBM 的 SOA Foundation 团队的成员,从事不同体系结构原则之间的聚合工作。Claus 是 WebSphere Foundation Architecture Board 的一名成员。

在加入 IBM 之前,Claus 作为首席架构师和 SOA 推广人员已经有十年的经验。

Jasmine Basrai 的照片

Jasmine Basrai 做了 5 年的 WebSphere BPM 高级产品经理。她致力于业务建模、监控和 BPM 终端用户接口。她因 IBM 收购 HOLOSOFX 而加入 IBM,在 HOLOSOFX,她是一名咨询服务经理,成功地实施了很多 BPM 方案。她有 11 年的 BMP 行业经验,热衷于通过创建 BPM 解决方案来推动更多的业务用户交互。

Pablo Irassar

Pablo Irassar 是安大略省多伦多市 IBM Software Group AIM 部门的一名高级技术人员。他是 WebSphere BPM Advanced Customer Deployments (SWAT) 团队的成员。

关于报告滥用的帮助

报告滥用

谢谢! 此内容已经标识给管理员注意。


关于报告滥用的帮助

报告滥用

报告滥用提交失败。 请稍后重试。


developerWorks:登录


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


忘记密码?
更改您的密码

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

 


当您初次登录到 developerWorks 时,将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人,但您可以随时修改这些信息的显示状态。您的姓名(除非选择隐藏)和昵称将和您在 developerWorks 发布的内容一同显示。

请选择您的昵称:

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

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

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


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

 


为本文评分

评论

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services
ArticleID=505133
ArticleTitle=停止复制,开始链接
publish-date=08052010
author1-email=ctjensen@us.ibm.com
author1-email-cc=
author2-email=basrai_cnnew1@us.ibm.com
author2-email-cc=crothemi@us.ibm.com
author3-email=pirassar@ca.ibm.com
author3-email-cc=

标签

Help
使用 搜索 文本框在 My developerWorks 中查找包含该标签的所有内容。

使用 滑动条 调节标签的数量。

热门标签 显示了特定专区最受欢迎的标签(例如 Java technology,Linux,WebSphere)。

我的标签 显示了特定专区您标记的标签(例如 Java technology,Linux,WebSphere)。

使用搜索文本框在 My developerWorks 中查找包含该标签的所有内容。热门标签 显示了特定专区最受欢迎的标签(例如 Java technology,Linux,WebSphere)。我的标签 显示了特定专区您标记的标签(例如 Java technology,Linux,WebSphere)。