1 項目背景
本項目來源于與某“機械設計研究所”的合作項目，該所歷史上在設計管理模式上采用傳統的層次化垂直結構，但是近年來，隨著用戶對產品更新換代的要求越來越快、質量要求越來越高，在競爭日益劇烈、外部壓力日益增大的形勢下，該所在管理模型上重新定位，打破長久以來形成的垂直結構，形成一種趨向于水平集成的業務模型，這形成了企業重構的趨勢，使企業能更專注于自己的業務特長，在產品研發時，能更好地利用國內更先進的技術力量，以實現合作方異地協同設計。
該所已經成功地把PDM(Product Data Management，產品數據管理)系統用到本地產品設計管理中，將產品整個設計生命周期內的所有數據，按一定模式加以定義、組織和管理，使產品數據在整個生命周期內保持一致和共享，為企業設計和生產構筑一個并行產品開發和管理的環境。
但是，現有PDM系統是針對當初封閉的管理模式而設計的，無法應對設計變更比較頻繁的異地的合作方協調設計環境，因此，該所要求把原來的系統進行擴展，在原有系統上增加合作方協同設計能力，搭建基于互聯網的合作方協同設計溝通管理平臺，使得部件設計合作方能夠在早期就介入產品的研發過程，及時獲取產品信息和變更通知，并將相關的信息及時反饋到企業，縮短主要設計部門和合作方的溝通時間，提高合作方在新產品設計中的響應能力，實現各方共贏。
新的PDM系統的開放性，將為實現產品的異地、異構設計提供強大支持，通過合理利用Web Services技術，實現業務與分布式數據源整合，并根據業務發展的需要，實現業務方法的重新編排，可以有效管理各合作方協同設計過程，通過實現工程中設計、制造、測試、維護等職能的綜合考慮，使新產品開發更加有序和有效。
2 PDM架構設計
2.1 架構設計需要解決的問題
根據對多個方案的比較分析，本項目采用基于Web Services的面向服務架構的形式，它有如下優點：
①有利于協調不同的服務領域間的異構數據模型
本PDM系統的合作方協同設計是一些特定領域相關的服務集合，在這個服務領域中需要所有服務采用統一的數據模型進行定義，但是，由于合作方業務的復雜性，數據服務來自不同服務領域，這就使得模型間語義與結構存在巨大差異，采用Web Services技術，將有利于協調不同的服務領域間的異構數據模型。
②便于實現面向服務的集成(SOI)
通過使用Web Services來解決集成與互操作的問題將有利于達到如下目的：
a.改進現有數據模型，以適應當前集成項目。
b.根據服務契約對傳統系統進行包裝，創建當前系統集成所需要的新服務。
c.定義用于“進行不同數據模型的映射”的數據轉換，以便數據能夠跨越不同的數據領域邊界。
d.為Web服務平臺配置執行環境，以支持并實施企業級的服務質量。
項目要求與合作協同設計有關的業務，通過瘦GUI Web客戶端或者瀏覽器實現人機交互，在設計的初始方案中有四個關鍵問題需要解決：第一，服務如何識別與搭建，第二，如何處理以協同設計為特征的業務模型工作流，第三，在PDM處理工藝圖紙的時候，由于文件體積龐大，需要重點解決文件存放結構與調用方法的問題，第四，基于Web Services的面向服務架構如何實現，實現中需要處理哪些問題。
2.2 頂層架構設計
頂層設計的一個基本策略，就是為每個服務子系統賦予清晰的職責，這些職責是內聚的，相互間的關系松散而簡單，在業務需要服務變化的時候，采取了只增加服務而不是修改服務的策略(開放和封閉的原則)。這樣一來，就使系統具有很強的可伸縮、可擴展性，以及對于業務變化的敏捷適應能力。
在項目之初，通過對與項目目標相關的業務進行梳理，依據完整性、自治性、重用性、封裝性、松耦合性以及接口的一致性對服務進行了識別，為了避免點對點服務帶來的問題(不能改變信息、難以跟蹤服務使用狀況、難以驗證、安全隱患等)，整個服務使用了企業服務總線(EntERPrise Service Bus，ESB)和數據總線(Data Bus)進行集中管理，根據合作方協同設計的要求，從業務層面來看，本項目共分成三個完全自治的子服務，其架構關系如圖1所示。
圖1 合作方協同設計頂層架構
下面對主要的服務對象加以說明：
①項目管理與過程管理子服務(PM&PM)
主要解決在合作方協同設計的情況下，確保有效項目管理的信息服務，主要包括：組織機構定義和修改服務；人員角色指派服務；產品數據操作權限分派服務；項目開發過程定義服務；工作流定義服務；任務列表生成服務；任務執行狀況信息服務；協同開發項目過程監控服務；工作進展信息提供服務等。
②工程圖檔與文檔管理子服務(ED&DM)
這是PDM系統傳統業務的一部分，關注點是工程圖檔的管理，主要包括：圖檔基本信息錄入服務；圖檔基本信息編輯服務；圖檔文件間連接關系服務；圖檔文件的批量入庫和交互入庫服務；圖檔文件釋放及傳送服務；圖檔文件顯示服務；圖檔顯示模塊轉換格式服務；圖檔批注及符號服務等。
③配置管理與變更管理子服務(CM&CM)
主要解決工程文件的版本控制以及變更管理的問題，還必須保證在并行情況下圖檔修改的串行化，主要包括：產品結構樹生成服務；圖檔版本演化可視化服務；產品批次結構信息服務；產品零部件之間的層次關系服務：產品變更管理服務；產品修改串行化服務；文檔或圖紙編碼規則服務等。
這三個子服務相互支持，共同完成合作方協同設計中項目管理、圖檔管理、版本管理以及圖檔修改串行化的業務要求，為了減少子服務之間的耦合并增加子服務的內聚度，項目設計要求各子服務之間不得直接交互，它們只能通過組合服務的上層組件進行交互，從而減少了開發、集成、調試、維護以及后期升級的難度。
2.3 數據資源的可伸縮性設計
①用數據服務取代遠程數據調用
在數據資源的應用上，由于各個合作方數據本身具有敏感性以及數據庫和數據結構的多樣性，直接通過互聯網調用合作方的數據庫是不安全，也是不合理的，因此本設計采用的方法，是使合作方的數據資源以服務的形式提供出來，而且只提供與合作方協同設計相關的數據，而禁止其他不相關的數據被非法使用，這種數據服務的提供方式采用XML/Web Service技術，就保證了異構數據以統一的格式進行整合。
本系統通過一個數據總線(Data Bus)統一管理數據使用者的權限、格式轉換以及其它方面的問題，以確保數據的安全性和使用上的方便性，由于數據是以服務的形式提供的，數據服務的分布性為大數據量的性能要求提供了支持。
②數據總線應用的REST風格
為了進一步提高異構數據應用上的方便性，在數據總線的應用上使用了REST風格，也就是利用URL來表示數據操作，把最基本的四個對數據的原子操作(創建、讀取、更新和刪除)表示為：GET、POST、PUT和DELETE，這種針對資源的網絡應用設計和開發方式，可以降低開發的復雜性，提高系統的可伸縮性，也使得資源的調用更加簡潔與易于理解，這樣一來，就形成了一種簡潔并與HTTP協議的完美結合的表達方式，如圖2所示。
圖2 REST風格的數據應用表達方式
實踐表明，采用REST風格的數據應用格式可以獲得如下好處：
a.REST風格天然地具有服務器無狀態的特征，在狀態遷移的過程中，服務器不需要記錄任何Session，所有的狀態都通過URL的形式記錄在了客戶端。
b.REST風格能夠提高系統的可伸縮性，在操作無狀態的情況下沒有上下文約束，這樣一來，在我們強調要分布式、集群的時候，就不需要考慮上下文的問題。
c.由于在數據總線中統一采用了REST風格，數據應用與具體的數據庫SQL無關，這樣就減輕了大部分程序員的負擔，保證了系統后期升級、維護和擴展的可實現性。
在本項目中，只是在數據總線的應用中采用了REST風格，在總線的內部設計中還是采用了XML/Web Service調用數據的遠程服務，數據總線作為一個中間件，起到了格式轉換和統一管理的的作用，如圖3所示。
圖3 數據總線的基礎架構
2.4 分布式服務解決方案
采用Web Service技術盡管能夠很好的解決異構系統與數據的整合，但是也帶來了性能上的問題，對于本合作方協同設計系統來說，盡管不是絕對的實時系統，但是對性能也還是有比較高的要求，在具體設計中，我們采取了服務分層次的分布式布局策略來解決性能問題。
在合作方位置遙遠、業務非常復雜而且繁忙時，把所有的服務都集中在中央服務中心是不合適的，這樣會嚴重影響服務的性能，而把業務處理全部轉移到GUI客戶端也不合適，因為業務處理流程必須維護全局狀態，也增加了維護的難度，本項目解決這個問題的思路是把服務按照不同的級別進行分布式配置，如圖4所示。
圖4 分布式服務解決方案
在這個方案中，服務分成兩個不同的層次：
a.中心服務：這種服務所處的位置在全局數據中心服務器上，其維護的狀態是全局性的，更多的是關注各個合作方之間的協調的業務，特別是在響應某個請求的時候需要多個分布式服務站點參與時尤其重要，中心服務中的服務職責可以居中協調共同完成業務處理，這種布局的好處在于：一般來說，在同一空間(合作方)中會有大量內部相互協調的操作，而合作方之間的協調在總量上要少得多，這就可以大幅度減少應用服務的網絡流量，提高系統的整體性能。
b.棧服務：這種服務的所謂全局狀態是有區域性的，例如在同一個合作方內，相當多的業務處理都是在內部進行的，其全局狀態也只是指的這個合作方范圍內而言，我們可以把這類服務(也可能是半服務)在物理上直接置于合作方本身的數據中心，至于這個合作方數據中心提供服務的方式是采用內網還是外網并不重要(大多數情況下這種處理都是置于內網)，進一步，某些只與具體的客戶相關的業務處理，也可以置于GUI客戶端上，通過這樣的處理，可以極大的提升本地服務的性能，減輕中央服務器的壓力。
分布式服務不可避免會帶來如何處理會話(Session)的問題，本設計方案不采用在服務器內存中存放會話的方案，而是把所有生命周期超過一個任務的的數據都存放在“持久服務”(會話數據庫)中，這種設計盡管在保存和使用會話數據速度方面比內存方式慢了點，但是由于同一個業務可以在不同物理位置上進行處理，或者在性能需要的時候可以進行多服務器擴展，所以這是更合適的方案，通過在系統中大量使用并行計算的方式，在總體性能上提升的余地更大。
3 結論
本設計實際應用效果表明：所設計的合作方協同設計PDM系統，可以很好的適應企業重構趨勢下的應用要求，并且具有比較廣闊的未來發展空間，所采用的分布式服務方案極大地提高了系統的可伸縮性、性能、吞吐量、容錯性以及可用性，可伸縮性的提高是因為服務可以利用服務方已有的分布式硬件，當合作開始或終止的時候，只要安裝或者關閉這個服務，也就自然開始或終止了這個業務節點和數據源的使用，這就使整個系統具有可伸縮型，性能和吞吐量的提升是因為合理的分布式服務布局，使網絡的使用量被減到最小(絕大部分操作可以在本地內網空間運行而不需要昂貴的互聯網絡開銷)，可用性和容錯性的提高是因為某個合作方服務中心發生故障時，并不會影響其它服務的可用性，此外，由于PDM體系的相似性，所有服務都可以由一個通用的設計來支持，并沒有增加設計上的復雜性。
本PDM系統應用Web Services的重要目的是綜合各個合作方的數據，通過隔離合作方不相關數據，保證合作方本身內部數據的安全。PDM系統綜合各方數據以后，將把這些異構數據轉換成統一的數據格式(XML)的信息，便于各方面的應用，由于采用Web Services技術，各種異構數據和異構平臺的整合變得可行，就為系統下一步的發展，打下了堅實的基礎。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：面向合作方協同設計的PDM架構
相關文章
