本项目来源于与某“机械设计研究所”的合作项目。该所历史上在管理和设计模式上采用传统的层次化垂直结构。但是近年来，随着用户对产品更新换代的要求越来越快、质量要求越来越高，在竞争日益剧烈、外部压力日益增大的形势下，该所在管理模型上重新定位，打破长久以来形成的垂直结构，形成一种趋向于水平集成的业务模型，这就形成了企业重构的趋势，使企业能更专注于自己的业务特长，在产品研发时，能更好地利用国内更先进的技术力量，以实现合作方异地协同设计。
1 合作方的协同设计
该所以某型产品的设计为基础进行转型试点，他们选定3家具有资质的异地设计单位作为合作方（出于保密性要求，本文暂且称为北京方、上海方和广州方，以此来突出在地理位置上的分布性，而不特指该城市），利用地域和知识优势，充分利用当地资源来设计相关部件，而机械设计研究所负责项目的整体设计、系统集成、过程管理和监控等工作。其简化的工作模型，如图1所示：
这个模型被称之为合作方协同设计PCD(Partners Cooperative Design)。为了避免管理方法与业务模式的不匹配，机械设计研究所决定建立一套符合目前这种业务模式的信息系统。该所已经成功地把PDM(Product Data Management，产品数据管理)系统用到本地产品设计管理中，将产品整个设计生命周期内的所有数据，按一定模式加以定义、组织和管理，使产品数据在整个生命周期内保持一致和共享，为企业设计和生产构筑一个并行产品开发和管理的环境。
但是，现有PDM系统是针对当初封闭的管理模式而设计的，无法应对设计变更比较频繁的异地的合作方协调设计环境。因此，该所要求把原来的系统进行扩展，在原有系统上增加合作方协同设计能力，搭建基于互联网的合作方协同沟通平台，使得部件设计合作方能够在早期就介入产品的研发过程，及时获取产品信息和变更通知，并将相关的信息及时反馈到企业，缩短主要设计部门和合作方的沟通时间，提高合作方在新产品设计中的响应能力，实现各方共赢。
PDM系统的开放性，将为实现产品的异地、异构设计提供强大支持。通过合理利用Web Services技术，实现分布式数据源整合，实现数据物理位置的透明性，可以方便地实现对现有系统的二次封装，有效管理各子系统的信息。通过实现工程中设计、制造、测试、维护等职能的综合考虑，使新产品开发更加有序和有效。
2 基于Web Services的PDM系统架构
根据调研的结果，PDM系统整体采用基于Web Services的架构形式有如下优点：
2.1 有利于协调不同的服务领域间的异构数据模型
本PDM系统的合作方协同设计是一些特定领域相关的服务集合，在这个服务领域中所有服务应该采用统一的数据模型进行定义。但是，由于合作方业务的复杂性，数据服务来自不同服务领域，这就使得模型间语义与结构存在巨大差异，而且具有多点服务的特质。采用基于Web Services的PDM系统，将有利于协调不同的服务领域间的异构数据模型。
2.2 便于实现面向服务的集成(SOI)
SOI是使用Web Services进行的集成，通过使用Web Services来解决集成与互操作的问题。本项目的Web Services平台为完成相似项目将需要提供多种选择，必须选择一种标准化的契约(WSDL)来提供服务，利用WSDL可以达到如下目的：
a、适应当前集成项目：改进现有数据模型，以适应当前集成项目。
b、创建新服务：根据服务契约对传统系统进行包装，创建当前系统集成所需要的新服务。
c、跨越不同数据领域边界：定义用于“进行不同数据模型的映射”的数据转换，以便数据能够跨越不同的数据领域边界。
d、实施企业级的服务质量：为Web服务平台配置执行环境，以支持并实施企业级的服务质量。
本项目Web Services所提供的服务，是把各个合作方本身异构的相关数据，通过Web Service中的XML层，转换为通用的XML形式，然后由PDM系统进行数据集成，这样就形成一个在项目内共享的数据总线。在这个过程中，WSDL在服务契约的定义担任了关键角色。这种技术路线的优势在于，各合作方的数据服务是独立而且异构的，采用Web Services技术就能够提供一种快速集成方案，项目将关注共享数据与可重用的服务，而不是专有的集成产品，因此能够更快、更轻松地确保IT投入与企业战略规划保持一致。
在系统中采用XML格式可能会有效率问题，但是，本项目大量的工作是用于合作设计过程控制与管理，产品本身设计过程利用内部原有的处于封闭状态的PDM系统，因此，大部分相关数据的传输速率应该在可接受范围内的。至于少量大型工艺文件，考虑到合作方协同设计主要是在里程碑点上的传输，而不是日常的频繁传输，所以，速率问题不大。
在这个架构中，合作方本身工作模型并没有改变，合作方的Web Service服务器只是为了建立数据总线的通讯，与合作有关的数据将直接保留在本地数据库相应的区中，这个数据区将直接与Web Service服务器有关应用程序相连。其他的数据将与这个服务器绝缘，以保护本地数据的安全。
项目要求与合作协同设计有关的业务，通过瘦GUI Web客户端程序或者浏览器实现人机交互。在设计的初始方案中有4个关键问题需要解决：第一，这个系统如何来处理以协同设计为特征的业务模型工作流：第二，在PDM处理工艺图纸的时候，由于文件体积庞大，需要重点解决文件存放结构与调用方法的问题；第三，互联网上信息传输的不安全性，是设计本身需要重点考虑的问题；第四，Web Services技术如何实现，实现过程中需要处理哪些问题。
设计要求各合作方的Web Service组件只处理与合作项目相关的数据和文件，所有合作方均通过中心服务器使用数据和功能。所有传输数据协议一律采用XML，不需要改变合作方内部的任何工作方式。包括应用层和传输层两个方面的安全机制需要仔细考虑，以保证各方商业秘密的安全性。
3 PDM体系结构设计
3.1 高层体系结构设计
本项目系统设计共分成3个子系统，它们是：
项目管理与过程管理子系统(Project Management and Process Management，PM&PM)。
工程图档与文档管理子系统(Engineering Drawing and Document Management，ED&DM)。
配置管理与变更管理子系统(Configuration Management and Change Management，CM&CM)。
各子系统要求设计成具有独立系统架构的完整系统，为了减少子系统之间的耦合并增加子系统的内聚度，项目设计要求各子系统之间不得直接交互，它们只能通过共享的数据总线(Data Bus)进行交互，从而减少了开发、集成、调试、维护以及后期升级的难度。系统的整体体系结构关系，如图2所示：
系统的数据总线通过Web Services技术来实现，隔离了远程异构数据的物理位置、数据格式等信息，把本地数据和远程数据结合起来，使用者并不需要知道这些远程异构数据源的具体情况。系统还提供了公用的数据格式与交换、缓存和安全机制，提高了模块的可复用性。
系统在设计中采用垂直分层，水平分模块，力争结构清晰。垂直方向基本按照表示层、业务层和持久化3个层次划分，使关注点分离功能分割清晰，而且通过接口分解了模块之间的耦合性，便于系统维护。
在表示层，按垂直方向分离了用户接口组件和用户接口过程组件；在业务层，按照统一的接口对外，水平分离了业务流程、业务组件和业务实体；在持久化层，水平分离了数据访问组件以及服务代理，实现了统一的数据总线机制，使整个体系结构清晰度得以提高。
3.2 子系统体系结构的设计
本系统要求子系统是具有独立体系架构的系统，各子系统之间只能通过数据总线进行交互，这种规定确保了子系统的独立性，下面简要介绍各个子系统的高层体系结构。
3.2.1 项目管理与过程管理子系统(PM&PM)
本子系统需要对项目合作方进行统一无缝的项目管理与监控，所以具备一般PDM系统所不具备的功能。子系统的下层分为模块，也就是独立的业务单元。项目设计规则要求，各模块是独立设计的，模块之间不能直接交互，而只能通过接口用规则的方法交互，项目的这个要求，确保了模块的高内聚与低偶合，也确保了后期的升级和维护成本比较低。该子系统的项层体系结构，如图3所示：
3.3 工程图档与文档管理子系统(ED&DM)
工程图档与文档管理子系统是这个项目的重要部分，也是PDM系统的核心功能，主要用于检索，修改、变更工艺过程中所需要的各类设计文档与图形文档，其中可能还包括三维演示视频文档，本子系统的顶层体系结构，如图4所示：
3.4 配置管理与变更管理子系统(CM&CM)
本子系统主要用于处理整个工程文档的演化与版本控制，其中包括可视化的版本跟踪，企业编码的生成与应用，批次文档的查询与组合，以及产品零部件的配置等重要信息处理。PDM文件处理只有和配置管理系统结合起来，才可能发挥相应的作用，而变更管理是新产品设计与发布的重要一环。本子系统的顶层体系结构，如图5所示：
4 结论
本PDM系统应用Web Services的重要目的是综合各个合作方的数据，通过隔离合作方不相关数据，保证合作方本身内部数据的安全。PDM系统综合各方数据以后，将把这些异构数据转换成统一的数据格式(XML)的信息，便于各方面的应用。由于采用Web Services技术，各种异构数据和异构平台的整合变得可行，就为系统下一步的发展，打下了坚实的基础。