使用 SOA 技術實現既有資產的開發和重組（下）

在本文中，作者使用中間會合 (meet-in-the-middle) 開發模式，對既有資產進行抽取、分析、編排和對映，生成滿足業務目標的可部署程式碼和介面定義檔案，從而實現了對於既有資產的轉換和重組。

實現細節

使用 WDz 7.0 進行既有 IT 資產開發和重組

下面我們將介紹如何通過建立 WDz 7.0 的 Service Flow 工程來實現 COBOL 應用的匯入、開發、重組和部署全過程。這裡採用從中間會合的模式，我們通過匯入實現目標的介面定義檔案和需要轉換的非終端應用程式 COBOL 原始碼，根據需求分析建立操作及其輸入輸出訊息的對映和關聯，最終生成可部署的 Web Service 描述檔案和可執行程式碼，完成既有資產到 Web Service 方式的轉換。

1. 建立 SFP（Service Flow Project）

建立一個空的 SFP，命名為 LookupPartOrder，進入預設的 EST 透檢視。

圖 6

2. 匯入介面定義檔案

該介面定義檔案描述了目標 Web Service 的實現目標，WSDL 檔案內容如圖 4 所示。在 EST Project Explorer 檢視的右鍵選單中選擇 Import->WSDL，如圖 7 所示。完成 Import Wizard 之後，在 SFP 的 Interface 目錄中將生成兩類檔案：(1) 介面定義檔案 (.wsdl)，描述了目標 Web Service 的操作。一個 wsdl 檔案只能定義一個操作，作為呼叫一個 flow 的介面資訊，包括埠型別、操作名稱、輸入與輸出訊息的引用等。(2) 訊息定義檔案 (.mxsd)，描述了該操作所引用的輸入與輸出訊息的型別資訊。

圖 7

3. 匯入非終端應用程式

EST 工具提供了對匯入基於終端的應用程式、非終端應用程式以及基於 CICS 的 Web Service 的支援，實現對這些既有資產元件的開發和重組。本例匯入的 COBOL/Copy book 檔案是作為非終端應用程式匯入的，其他兩類的匯入方式與其類似，這裡不再贅述。在 EST Project Explorer 檢視的右鍵選單中選擇 Import->COBOL，主要功能是從每個 COBOL 原始檔 (COBOL program 和 copy book) 中抽取 COBOL 的資料結構生成 Service Flow 工程中對應的訊息檔案（.mxsd）。

圖 8

在 Import 嚮導的第二步中，需要定製將要生成的 COBOL 程式，例如建立 COBOL 應用程式提供的操作及對應的輸入輸出訊息，並將新增的操作以描述語言的形式新增到新建或者已存在的一個 WSDL 檔案中。本例的 COBOL 應用主要提供了兩個操作：CheckPartOrder 和 CheckPartPrice，COBOL 程式命名為 CheckPart。如圖 9，在 New File 輸入框定義了新建的 WSDL 檔名稱，Add Program 則可以新增多個操作，Input Data 和 Output Data 輸入框則可以為操作選擇輸入和輸出的資料型別。

圖 9

4. 建立業務流程 (Service Flow)

在獲取了目標業務和已有元件應用的資訊之後，我們需要按照業務需求對各個應用元件之間進行組合和編排，並建立目標 Web Service 與應用元件之間的關係，以實現既有資產到 Web Service 的轉換。在本例中，我們需要實現一個具有查詢訂單價格功能的目標 Web Service，其描述檔案為 Interface 目錄下的 LookupPartOrder.wsdl，需要呼叫已實現的應用元件的兩個操作 CheckPartOrder 和 CheckPartPrice，其描述檔案為 NonTerminal 目錄下的 CheckPart.wsdl，flow 的建立與修改通過以圖形化的形式編輯 Flow 目錄下的 .seqflow 檔案來完成。

(1) 將目標 Web Service 實現的操作新增到 flow 中。在 Flow Editor 的右鍵選單中選擇 Select Interface Operation( 或者 Select Operation)，如圖 10，開啟向導，選擇所要新增操作的 wsdl 描述檔案（該檔案必須來自 Interface 目錄下的介面定義檔案，而不能來自 Nonterminal，Terminal 或 Outbound Web Service 目錄）。新增完成以後，該操作的埠型別和程式名稱便與 flow 關聯起來，同時該操作所引用的輸入訊息與 flow 中的 Receive 節點相關聯，輸出訊息與 flow 中的 Reply 節點相關聯。

圖 10

(2) 將 COBOL 應用元件的兩個操作新增到 flow。同樣，在右鍵選單中選擇 Add Operation，從 Nonterminal 目錄中選擇我們想要新增的 operation 即可。新增完成以後，這些操作的埠型別和輸入輸出訊息將作為 Invoke 節點與該 flow 相關聯。

(3) 根據業務流程將 Receive、Reply 和 Invoke 節點之間進行邏輯連線，如圖 11，這樣 flow 的各個操作之間的呼叫關係體現了整個 Web Service 的業務流程。

圖 11

5. 建立訊息對映規則

一個訊息對映可以是簡單型別到簡單型別或複雜型別到複雜型別之間的對映。我們需要建立各個操作節點之間的輸入輸出訊息的對映規則，從而將業務流程更細粒度的進行描述。系統將會自動在 Mapping 目錄下生成一個 .seqmap 檔案來維護所有對映規則。以目標操作 CheckPartOrder 為例，我們在 Flow Editor 中選擇其中一個 invoke 節點 CheckPartOrder，如圖 12，在其右鍵選單中選擇 open mapping routine－>msg_ORDERSTATUSREC( 綠色箭頭代表建立輸入對映，紫色箭頭代表建立輸出對映 )，便會自動開啟預設的 mapping editor，同時在 .seqmapping 檔案中生成一個命名為 CheckPartOrder_t_msg_ORDERSTATUSREC 的對映規則。

圖 12

在 mapping editor 開啟的這條對映規則中，我們需要建立目標操作 CheckPartOrder 與 Receive 節點的輸入訊息之間的對映，因此在 Source 介面的右鍵選單中選擇 Add Message Input，開啟新增嚮導如圖 13 所示，選擇 Interface 目錄下的訊息定義檔案 inputMsgMsg 作為源訊息。完成新增之後，Source 和 Target 便分別列出了所有源節點和目標節點定義的所有訊息型別，我們可以採用拖拽的方式來建立一對一或一對多關聯，從而完成訊息對映的建立。

圖 13


圖 14

6. 建立 Generation Properties 檔案

通過介面匯入、COBOL 應用元件的匯入以及業務流程和訊息對映的設計，Service Flow 工程結構和內容如圖 15 所示。

圖 15

下面我們需要建立 Generation Properties 檔案來配置生成可執行程式碼和 Web Service 的相關資訊。

(1) 新建 generation properties 檔案。我們為每個需要生成 runtime code 的 flow 檔案建立一個 generation properties 檔案。在本例中，選擇 lookupPart.seqflow 檔案，在右鍵選單中選擇 New Generation Properties File，開啟新建嚮導如圖 16 所示，在嚮導中設定屬性檔案的名稱、對應的 flow 檔名稱，並選擇 CICS Service Flow Runtime 型別，完成後系統便會自動生成一個 .wsdl 檔案並以 generation properties editor 開啟。

圖 16

(2) 配置 generation properties 檔案資訊。我們需要對 flow 的配置檔案以及 flow 中所有呼叫操作節點的配置檔案進行設定。如圖 17，首先使用屬性編輯器開啟該 flow 對應的配置檔案，需要修改的屬性例如：Flow Type，描述了 flow 中的節點型別；Request Name，描述了請求或命令的名稱；Program Name，描述了將在介面卡服務中執行的程式名稱；Transaction ID，描述了程式所屬的事務 ID；Request Type，描述了該 flow 呼叫事務的模式，包括 ASYNC，SYNC，SYNC ROLLBACK；Generate Internal Data Structures，選擇是否生成 COBOL 源程式的資料結構，如 JCL 或 CBL；Web Service Generation Properties，用於生成非 SOAP 部署（如 CTG 或 MQ）的轉換支援檔案或 CICS 部署所需的 Web Service 描述檔案等等。

圖 17

此外，我們還需要對 flow 中所有呼叫操作的屬性進行設定，在 Outline 檢視中點選這個 flow 下的某個操作，屬性編輯器將會自動開啟對應的配置檔案，見圖 18。主要屬性有：Invoke Type，描述了基於 COBOL 流程的節點呼叫型別，包括 DPL 和 MQ；Link To Program Name，描述了服務端由 DPL 型別呼叫連結的程式名稱；System ID 描述了事務所執行的 CICS 系統名稱；Maximum Commarea Length，COBOL 原始碼所分配的儲存量的最大值。

圖 18

7. 生成 runtime code

這是整個資產開發的最後一步，即生成能夠在 CICS Service Flow Runtime 上部署和執行的程式碼。CICS Service Flow Runtime 支援包含終端應用（如 FEPI 和 LINK3270）和基於 COBOL 的非終端應用（DPL 和 MQ 節點），或者這些應用的集合。在 Project Explorer 檢視的右鍵選單中或者直接在 generation properties 編輯器中選擇 generate runtime code，系統便會自動生成執行時程式碼，包括：COBOL、Copybook（描述了輸入輸出訊息的資料結構）、JCL、Web Service bind 檔案和 wsdl 描述檔案。

最後我們可以編譯這些執行時程式碼並部署 bind 檔案來測試 Web Service，從而完成 COBOL 應用在 WDZ 7.0 上的開發與重組，實現既有資產到 SOA 的轉換。

結論

本文介紹了利用 SOA 方法，使用 WDz SFPT 開發既有資產，將資產轉化為 Web Service 的過程；並提供了一個詳細的樣例，描述了一種端到端的解決方案，實現和驗證了上述過程，幫助讀者深入瞭解 SOA 環境下既有資產的開發和轉換。

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