用於產品生命週期管理的 SOA 方法，第 2 部分: 產品生命週期管理的 SOA 參考體系架構

本部分的組織結構如下：

• “分解 PLM 域”闡述如何將 PLM 生態系統劃分為許多 PLM 規程。
• “用於 PLM 的 SOA 參考體系結構”介紹了用於在 PLM 域中應用 SOA 技術的參考體系結構。
• “對每個 PLM 規程應用 SOA”闡述瞭如何對每個 PLM 規程應用 SOA 技術。

分解 PLM 域

可以將 PLM 域分解為若干個規程。下面的列表並不詳盡，但是包含了許多最重要的 PLM 規程：

• 產品資料管理

  此規程指的是產品設計階段中的產品資料的管理

• 模擬資料管理

  此規程指的是每個產品配置的數值密集型模擬資料的管理

• 製造資料管理

  此規程指的是在製造階段使用的物料單的管理

• 服務資料管理

  此規程指的是在產品資產生存期中的服務資料的管理

• 工程更改管理

  此規程指的是在整個產品生命週期中控制更改請求流的過程。

請注意，前四個規程與產品生命週期的各個階段中的資料管理相關。最後一個規程，即工程更改管理（Engineering Change Management，ECM），是跨越產品生命週期所有階段的業務流程管理（Business Process Management，BPM）規程。

圖 1 說明了這些規程與產品生命週期的關係。

圖 1. PLM 規程與產品生命週期

圖 1 表明了四個資料管理規程如何對應於產品生命週期的每個階段，而 ECM 規程則跨越所有的階段。我們現在可以討論如何使用 SOA 技術來解決第一部分中的“挑戰”一節中討論的許多挑戰，在該節中，我們討論了應用程式局面的多樣性和 IT 環境的複雜性。這些挑戰使得資料和流程很難在各個產品生命週期階段中順利地流動。我們可以將“挑戰”中討論的主要問題歸類如下：

• 應用程式整合問題

  PLM 環境中使用了許多應用程式。這種多樣性往往將資料分割到豎井中，使得構建跨越多個應用程式的業務流程變得非常困難。

• 資料整合問題

  資料在整個企業中四處散佈，不僅散佈在不同的應用程式之間，而且還散佈在不同的業務部門之間。此外，許多產品是使用供應商和協作者的網路來製造的，從而使得資料整合問題更加惡化。

• BPM 問題

  產品開發生命週期的每個階段都涉及到若干依賴手動操作的業務流程的協作。此類業務流程的糟糕執行限制了對它們的優化，從而限制了製造商利用業務流程轉換來縮短產品開發生命週期和實現創新的能力。

• 業務服務治理問題

  上述三個問題表明了具有大量應用程式、資料來源和業務流程的 PLM 環境的異常複雜性。單獨解決這其中每個問題決不可能實現 PLM 局面的優化。必須構建治理策略，根據策略將每個應用程式、資料來源和業務流程表示為業務服務，並且必須建立治理模型，以實現所有元件的高效使用。

在下面幾個小節中，我們將說明如何使用 SOA 技術解決這其中每個問題，從而產生可通過高效的治理模型進行開發和管理的業務服務的統一集合。

用於 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) 是優化和管理企業中存在的大量業務流程的能力。最近，出現了許多用於實現 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 治理的“服務端點管理”方面感興趣。在“工作示例概述”中，我們將討論兩項使用服務註冊中心查詢功能來處理端點解析的技術。

對每個 PLM 規程應用 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 流程如何幫助自動化產品生命週期的所有階段，同時還在流程中提供了極有價值的業務流程智慧。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-584503/，如需轉載，請註明出處，否則將追究法律責任。