第 1 部分讨论了产品生命周期管理（Product Lifecycle Management，PLM）环境如何变化多样，以及对集成大量作为复杂 PLM 生态系统一部分的流程和信息源的需要。本章研究如何应用 SOA 技术来实现这其中许多目标。
本部分的组织结构如下：
- “分解 PLM 域”阐述如何将 PLM 生态系统划分为许多 PLM 规程。
- “用于 PLM 的 SOA 参考体系结构”介绍了用于在 PLM 域中应用 SOA 技术的参考体系结构。
- “对每个 PLM 规程应用 SOA”阐述了如何对每个 PLM 规程应用 SOA 技术。
可以将 PLM 域分解为若干个规程。下面的列表并不详尽，但是包含了许多最重要的 PLM 规程：
- 产品数据管理
此规程指的是产品设计阶段中的产品数据的管理
- 模拟数据管理
此规程指的是每个产品配置的数值密集型模拟数据的管理
- 制造数据管理
此规程指的是在制造阶段使用的物料单的管理
- 服务数据管理
此规程指的是在产品资产生存期中的服务数据的管理
- 工程更改管理
此规程指的是在整个产品生命周期中控制更改请求流的过程。
请注意，前四个规程与产品生命周期的各个阶段中的数据管理相关。最后一个规程，即工程更改管理（Engineering Change Management，ECM），是跨越产品生命周期所有阶段的业务流程管理（Business Process Management，BPM）规程。
图 1 说明了这些规程与产品生命周期的关系。
图 1. PLM 规程与产品生命周期
图 1 表明了四个数据管理规程如何对应于产品生命周期的每个阶段，而 ECM 规程则跨越所有的阶段。我们现在可以讨论如何使用 SOA 技术来解决第一部分中的“挑战”一节中讨论的许多挑战，在该节中，我们讨论了应用程序局面的多样性和 IT 环境的复杂性。这些挑战使得数据和流程很难在各个产品生命周期阶段中顺利地流动。我们可以将“挑战”中讨论的主要问题归类如下：
- 应用程序集成问题
PLM 环境中使用了许多应用程序。这种多样性往往将数据分割到竖井中，使得构建跨越多个应用程序的业务流程变得非常困难。
- 数据集成问题
数据在整个企业中四处散布，不仅散布在不同的应用程序之间，而且还散布在不同的业务部门之间。此外，许多产品是使用供应商和协作者的网络来制造的，从而使得数据集成问题更加恶化。
- BPM 问题
产品开发生命周期的每个阶段都涉及到若干依赖手动操作的业务流程的协作。此类业务流程的糟糕执行限制了对它们的优化，从而限制了制造商利用业务流程转换来缩短产品开发生命周期和实现创新的能力。
- 业务服务治理问题
上述三个问题表明了具有大量应用程序、数据源和业务流程的 PLM 环境的异常复杂性。单独解决这其中每个问题决不可能实现 PLM 局面的优化。必须构建治理策略，根据策略将每个应用程序、数据源和业务流程表示为业务服务，并且必须创建治理模型，以实现所有组件的高效使用。
在下面几个小节中，我们将说明如何使用 SOA 技术解决这其中每个问题，从而产生可通过高效的治理模型进行开发和管理的业务服务的统一集合。
 |
|
本节讨论我们用于构建 PLM 局面基础的 SOA 体系结构。该体系结构是在实际项目中使用可用的最新 SOA 技术经过多年实践构建而成的。我们开发的 PLM 集成体系结构集合了核心的 PLM 规程，如图 2 所示。该体系结构建议使用四个基本集成层，这些层支持各个 PLM 规程并产生高效的 PLM 基础结构（请参见图 2）。
图 2. PLM 集成架构
PLM 集成体系结构的实现使用企业服务总线（Enterprise Service Bus，ESB）模式来进行应用程序集成。此集成模式称为用于 PLM 的 SOA 体系结构 (SOA Architecture for PLM)，如图 3 所示。
图 3. 用于 PLM 的 SOA 体系结构模式
在图 3 中，用于 PLM 的 SOA 体系结构基于 ESB 体系结构模式。应用程序集成层显示在总线的下方部分，而其他三个层则由连接在总线上方的三个框表示。如果没有正确的设计和数据模型，我们无法简单地将这些组件连接到总线。这样将会创建复杂性而不是降低复杂性。特别是，应用程序使用单个基于标准的数据模型和协议进行连接是极其重要的。为了实现所有应用程序的协议和数据模型聚合，上述体系结构使用了可在应用程序数据模型和基于标准的模型之间来回转换的连接器。该标准必须谨慎选择。在 PLM 领域，国际标准化组织（International Standards Organization，ISO）、对象管理组织（Object Management Group，OMG）和开放应用程序组集成规范（Open Application Group Integration Specification，OAGIS）已经做了大量工作。在文中，我们选择了 OMG PLM Services 2.0，此标准基于 ISO AP214 产品数据交换标准（Standard for Exchange of Product Data，STEP）和德国汽车工业协会（Verband der Automobilindustrie，VDA）的 ECM 建议。下面几小节将讨论每个层如何连接到总线，以及它们在总体体系结构中扮演的角色。
我们的 SOA 体系结构的应用程序集成层处理将各个应用程序连接到 ESB 的需要。通常，连接器用于提供到应用程序的 SOA 连接性。在其他情况下，应用程序可能已经提供了 SOA 接口。无论进行连接的方式如何，最重要的考虑事项在于，用于连接到 ESB 的接口应该尽可能基于开放行业标准。这可以确保各层使用的数据模型和数据访问语义与其他层匹配。此外，开放行业标准的采用降低了 IT 实现的复杂性，因为它减少了企业中使用的API 和数据模型的数量。
除了采用开放行业标准进行连接和数据建模以外，另一个重要考虑事项是双向连接性。双向功能不仅规定 ESB 必须能够向应用程序发出请求，而且应用程序也必须能够向 ESB 发出请求。许多场景都需要这种双向功能，但是直到最近，连接器标准才得到更新以提供双向功能。例如，只有最新版本的 Java Connector Architecture (JCA) 标准 JCA 1.5 才包括此功能。请考虑以下两个要求双向功能的常见应用程序集成场景：
- 应用程序用户使用某个 GUI 以便执行某个操作，例如创建一个新项。假设创建该项所需的某些信息必须从某个较旧的企业信息系统中提取。使用双向连接，应用程序可以调用总线以便检索所需的参数。
- 用户更新该应用程序中的某些数据。假设我们希望生成某个事件，以便此更新能够触发其他应用程序中的某些操作。通过将应用程序构造为连接到总线中来通知该更新，我们将能够实现此目的。
开放行业标准的采用和双向功能现在可以进行组合。也就是说，用于提供到应用程序中的连接的相同开放行业标准可以提供到总线的连接。我们将这称为对称双向功能。在我们的体系结构中，双向功能可以由 JCA 1.5 连接器提供，或者由具有双向功能的较简单 Web 服务连接器提供。从总线发起并针对应用程序的服务调用称为出站服务。相反，由应用程序发起并针对总线的服务调用称为入站服务。此术语将总线而不是应用程序视为有关服务方向的参考点。我们在本红皮书中采用的此术语与 JCA 1.5 术语一致。
图 4 描绘了使用开放行业标准来同时提供到 ESB 的入站和出站连接的对称双向连接器。
图 4 对称双向连接器
我们在本文中使用的数据集成层称为“将信息作为服务”(Information as a Service)。尝试大规模的数据合并策略涉及到将所有数据从多个应用程序提取到中央数据库，与此不同，将信息作为服务的方法实现联合查询，从而可以提供多个应用程序中包含的数据的统一视图。此方法可以避免中央数据库中的复制，从而避免了数据同步和一致性问题。
此方法最适合通过示例来解释。假设我们的企业中有两个 PDM 系统，一个系统由从事卡车驾驶室的工程师使用，另一个系统由从事底盘和电气系统的工程师使用。这种情况实际上非常普遍，因为通常使用不同的工具来创建表面和电气布线。在我们的示例中，我们根据公共标准 (OMG PLM Services 2.0) 对两个应用程序进行规范化，该标准提供了一个查询接口。我们现在可以构建一个服务，该服务提供相同的标准查询接口，并且可以提供两个系统中存储的数据的集成视图（整辆卡车）。使用此服务的客户端不会注意到数据实际上是从两个不同的系统合并而来的。这就是作为服务的信息方法的魅力所在。
通常，作为服务的信息必须执行从两个系统提取信息的工作流，然后产生集成的视图。这样的工作流被实现为由 WebSphere Process Server 执行的业务流程执行语言（Business Process Execution Language，BPEL）工作流。如图 5 所示。
图 5 作为服务的信息
BPM (BPM) 是优化和管理企业中存在的大量业务流程的能力。最近，出现了许多用于实现 BPM 的基于 SOA 的工具。BPM 与 SOA 技术之间的协作来自于对工作流工具的利用。例如，最广泛地用于创建 SOA 应用程序的工具基于使用 BPEL 开发的工作流。另一方面，业务分析人员传统上也依赖工作流技术来对企业流程建模。随着 SOA 技术的采用，现在可以将大致的业务流程工作流转换为采用 BPEL 的实际 SOA 实现。
BPM 领域的另一个重要发展是业务流程监视的实现。在业务流程定义阶段，分析人员可以创建关键性能指标（Key Performance Indicator，KPI），这些指标用于实时监视业务流程的性能。KPI 是流程的业务性能的指示器，例如成本、时间、里程碑等等。在业务流程的执行过程中，流程分析人员能够监视流程的业务性能，并检测可能的改进机会。然后分析人员能够对业务流程进行再工程，然后发送流程以便由 IT 专家进行重新实现。由于可以直接从业务流程模型得出 BPEL 实现，所以此过程是非常简单的。
这种实践支持持续的改进周期，从而连续地将业务分析人员的要求发送到 IT 专家以便加以实现。然后将在后续迭代中根据需要对流程进行监视和再工程。图 6 显示了此方法。
图 6 支持完整的业务流程生命周期
我们用于 PLM 的 SOA 体系结构的最顶层与业务服务治理相关。请注意，在其他三层中，我们已产生了大量的服务：
- 封装为服务的应用程序
- 作为服务提供的信息
- 带服务接口的业务流程
随着 SOA 技术的采用在企业中的增长，所部署的业务服务的数量也会增长。不仅服务的数量非常大，而且很可能会持续地引入服务的新版本。最后，使用此类服务的应用程序的数量也可能会增长，对业务服务治理的需要也随之增长。
业务服务治理是一个非常复杂的主题，因为它涉及到 SOA 治理的所有阶段。幸运的是，以前发表的红皮书出版物 Implementing Technology to Support SOA Governance and Management, SG24-7538 对此主题进行了详细的介绍。
就本文而言，我们特别对 SOA 治理的“服务端点管理”方面感兴趣。在“工作示例概述”中，我们将讨论两项使用服务注册中心查找功能来处理端点解析的技术。
|
|
本节描述 SOA 如何为以下 PLM 规程中的每个规程带来好处：
- “工程更改管理”
- “产品数据管理”
- “模拟数据管理”
- “制造数据管理”
- “服务数据管理”
PLM 的最重要方面之一是工程更改管理（Engineering Change Management，ECM）。ECM 流程控制请求工程更改的业务流程，并在整个产品开发流水线中传播。此流程在单个企业的上下文中以及在企业协作场景中都极其重要。在企业协作的情况下，ECM 流程及其关联数据类型采用某种标准是非常重要的。
在本文发表之际，以下两个标准被认为是最重要的 ECM 标准：
- VDA 4965
由德国汽车工业协会（Verband der Automobilindustrie，VDA）建议
- Configuration Management II (CMII)
由配置管理协会 (Institute for Configuration Management) 建议
要实现 ECM 业务流程，必须采用能够处理业务流程请求和数据类型的协议。OMG PLM Services 2.0 标准是旨在支持 VDA 4965 业务流程的 SOA 协议。本文的后续小节包含了对 OMG PLM Services 2.0 标准及其与 VDA 4965 标准的关系的讨论。
图 7 显示了 VDA 4965 ECM 流程及其里程碑的大致视图。此图显示了该流程的第三个步骤“更改的规范和决策”的深入视图，我们在其中看到了工程更改请求（Engineering Change Request，ECR）子流程和里程碑。
图 7 ECM 流程及其里程碑
工程更改流程是可以跨越许多应用程序并在供应商协作场景中可以跨越许多不同企业的业务流程。这就是它能够得益于 SOA 技术的原因。该业务流程可以采用 BPEL 来表达和实现，同时 OMG PLM Services 2.0 标准提供了公共数据模型和协议，可以使该流程能够跨越多个应用程序和多个参与企业。
产品数据管理（Product Data Management，PDM）是最重要的 PLM 规程之一。它包括与产品数据的管理相关的所有方面，例如产品数据结构（Product Data Structure，PDS）、产品配置等等。ISO AP214 STEP 标准专门设计来用作公共 PDM 数据模型。相应地，OMG PLM Services 2.0 标准为采用 STEP 格式表示的 PDM 数据的操作提供了 SOA 接口。到公共 PDM 格式的聚合以及用于 PDM 数据访问的 SOA 接口的标准化带来了许多好处。它允许原始设备制造商（Original Equipment Maker，OEM）使用公共数据模型与供应商网络交换数据，而 SOA 访问接口的标准化则允许使用 BPEL 来自动化数据交换过程。产品数据交换过程的自动化带来了以下好处：
- 减少以前由手动过程引起的错误
- 提供数据转换规则的自动应用，例如在使用多个零件号约定的情况下的零件号映射
- 缩短设计生命周期和上市时间
除了在产品数据交换领域的应用以外，SOA 在 PDM 领域还具有其他几个用途。后面的文章中演示了一个称为“产品数据结构合并”的场景。该场景在汽车和航空航天业非常普遍。该场景假设给定的产品存储在多个 PDM 系统中。这种情况经常发生，因为制造商经常使用不同的工具来设计产品的表面和其他部件，例如传动系或引擎。这是因为有些工具最适合于设计表面，而其他工具则基于参数技术。这些参数技术更适合于使用不同的参数产生某个零件的多个实例，例如具有不同直径的齿轮集，在传动系中就是这样。在另一个示例中，飞机制造商可能转包飞机的若干部分的制造，因此，飞机被划分到不同的 PDM 系统中。在这两个场景中，制造商最终都将面对着必须合并来自多个 PDM 系统的数据以获得汽车或飞机的完整视图的挑战。
模拟数据管理规程包括与模拟流程相关联的输入和输出数据的处理。由于当今的大多数设计流程都依赖数字模型技术（digital mock-up technology，DMU），制造商可以得益于在构建物理模型之前获得相关重要方面的可能性。诸如汽车燃油效率、飞机空气动力学或涡轮重量等方面可以使用模拟技术从 DMU 模型中获得。制造商依赖此技术来确保未来产品符合设计要求、遵从性规则等等。此技术已变得如此普及，以致诸如汽车或飞机等大型产品的开发需要大量的模拟，每当出现工程更改时就会重复这些模拟。其结果是生成数千兆字节的模拟数据，必须对这些数据进行管理、版本控制并将其与特定的设计更改相关联。
这就是可以应用 SOA 技术来提供帮助的地方。在上面描绘的 VDA ECM 的步骤 3 中，我们看到了一个标签为“工程更改请求的技术分析 (Technical Analysis of the Engineering Change Request)”的活动。我们已提到过基于 BPEL 的 SOA 流程如何自动化 ECM 流程。我们现在还具有实现自动化的 SOA 流程的能力，这样的流程能够向模拟应用程序发出模拟请求，解释结果，并基于通过/未通过决策采取适当的操作。所有这一切都基于模拟结果。
当然，仅当使用合适的标准来表示模拟数据模型和访问接口时，才能够实现这样的高级业务流程自动化。这样的标准，例如 PROSTEP iViP 协会建议的模拟 PDM（Simulation PDM，SimPDM）标准，现在正在日臻成熟。尽管该标准的应用超出了本红皮书出版物的范围，但是我们可以预期新出现的标准会通过模拟与 ECM 流程的集成提供巨大的节省和增强的效率。
制造数据管理涉及到将 PDS 转换为制造系统中使用的物料单（Bill of Material，BOM），以便进行库存控制、采购等等。
除了能够将 PDS 转换为 BOM 或产生不同标准格式的 BOM 表示形式之外，在将 ERP 系统中存储的 BOM 与 PDM 系统中保存的 PDS 保持同步方面，SOA 技术也发挥着重要的作用。这种同步非常重要，因为更改经常发生。我们可以使用支持 SOA 的工程更改管理流程来自动化用于做出更改和更新所有相关系统的过程。在后面的文章中，我们将演示此能力，其中将提供一个 SOA 驱动的流程来实现 VDA ECM 流程，并使用 OMG PLM Services 2.0 标准，从而使得能够自动在 ERP 系统中创建工程更改通知（Engineering Change Notice，ECN）和同步 BOM，以响应 PDM 系统中的 PDS 更改。
此场景清楚地说明了 SOA 技术的许多积极方面：
- 业务流程自动化
- 数据模型转换
- 应用程序集成
服务数据管理规程涉及到特定产品实例的产品数据的管理，通常是在产品已制造并销售之后。例如，飞机具有很长的使用寿命，出于遵从性目的，必须经常对飞机进行维修。在对飞机进行维修时，可能需要对其构成零部件进行更改。例如，在某些机场，必须将原始零部件替换为等效的零部件。在某些情况下，可能需要对整个机身部分进行重新抛光。服务数据管理规程处理服务 BOM、特定资产实例的构成零部件列表以及其维护历史记录的跟踪。此规程还与工程更改管理流程联系在一起。例如，假设制造商检测到了某个产生特定遵从性模拟结果的可能缺陷。现在必须回想起并查找给定零部件的所有使用实例。
SOA 对 PLM 域的另一个有趣应用涉及到使用提供业务智能的 BPM 工具。在此情况下，我们可以检测工程更改流程以产生可用作 KPI 的事件。此技术的优点数不胜数。例如，假设每次需要更换某个零部件时，PLM 应用程序都向零部件制造商发出一个事件。然后零部件制造商可以使用业务事件关联技术，以便确定故障率是否高于容许阈值，在此情况下，可能会触发工程更改管理流程以对缺陷零部件进行重新设计。然后支持 SOA 的 ECM 流程可以运行新设计的零部件的所有相关模拟。最终，设计获得批准，BOM 在 ERP 系统中被更改，新产品被制造出来，支持 SOA 的 ECM 流程将更改情况通知该零部件的所有用户。此示例表明支持 SOA 的 ECM 流程如何帮助自动化产品生命周期的所有阶段，同时还在流程中提供了极有价值的业务流程智能。
学习
- 您可以参阅本文在 IBM 红皮书网站上的 英文原文 。
- 本系列的第 1 部分：本文向您提供了一些背景信息，以帮助您了解产品生命周期管理 (Product Lifecycle Management)、IBM 如何将 SOA 应用于产品生命周期管理、以及产品生命周期管理标准等这些基础知识。 。
- IBM developerWorks SOA and Web services 专区 提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
- 使用 IBM SOA Sandbox 进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
- IBM SOA 网站 提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
- 了解关于 developerWorks 技术事件和网络广播 的最新消息。请特别关注以下 SOA 和 Web 服务技术讲座：
- Building SOA solutions and managing the service lifecycle
- SCA/SDO: To drive the next generation of SOA
- 访问 Safari 书店 ，浏览有关这些技术主题以及其他方面的书籍。
获得产品和技术
- 使用 IBM 试用软件 开发您的下一个项目，可下载或索取 DVD 光盘。
讨论
- 参与 developerWorks Blog，从而加入到 developerWorks 社区中来，其中包括以下与 SOA 和 Web 服务相关的 Blogs：
- Sandy Carter 的 Service Oriented Architecture -- Off the Record
- Ali Arsanjani 的 Best Practices in Service-Oriented Architecture
- Bobby Woolf 的 WebSphere SOA and J2EE in Practice
- Eoin Lane 博士的 Building SOA applications with patterns
- Kerrie Holley 的 Client Insights, Concerns and Perspectives on SOA
- Simon Johnston 的 Service-Oriented Architecture and Business-Level Tooling
- Sanjay Bose 的 SOA, ESB and Beyond
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-539589/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-539589/
3329
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
