適用於：
Microsoft .NET Framework 3.0
本頁內容
簡介
保險業影響因素
本文檔中使用的行業術語
人壽保險保單案例
結構概述
保險代理人保單系統
保險公司系統
具有什麼價值？
總結
資源
簡介
本白皮書系列旨在提供有關集成問題的指導。
在本白皮書中，我們將通過保險業的案例來說明 Microsoft 平台的互操作功能。隨著技術發展以及新技術不斷湧現，許多企業在企業發展的各個階段可能選擇了不同的技術：從基於大型機的 COBOL 或 FORTRAN 類型的傳統應用程序，到更為現代的基於 .NET、移動系統或 Java 的解決方案，以及一切的中間技術。因此，隨著企業所采用技術的日益龐雜，各類技術所面臨的限制也越來越多。
保險互操作系列
本白皮書旨在為面臨保險行業集成難點的結構設計師提供指導。本文將向您顯示如何使用 Microsoft 集成技術為企業集成各種有著本質差別的系統。另外，本文檔會針對使用開放式標准（如 WS-*）來構建互操作解決方案方面，提供實用的設計指南。此系列中還將包括下列文檔：
用於構建互操作保險系統的結構概述
確保保險解決方案的安全性
分析和操作管理
部署企業解決方案
開發復合應用程序
涵蓋的技術包括：
BizTalk 2006。用於此解決方案的集成技術。解決方案也會用到 BizTalk 業務規則和工作流編排功能。
Windows Communication Foundation (WCF)。用於開發 Web 服務消息以及使用 WS-* 協議來管理協議級通信的編程模型。
Windows Workflow Foundation (WF)。用於采用智能客戶端技術來創建恰當的工作流。
SQL Server 2006。所有應用程序和客戶數據的存儲庫。
Windows Server 2003。服務器平台。
該案例將使我們對業務流程有一個初步了解。與許多其他企業一樣，每家保險公司都有自己獨特的流程處理方式。但是，這些企業在平台級別具有一些相似之處。這意味著我們能夠利用這些共有的平台服務來構建面向服務的體系結構 (SOA)，從而為這些具有特定業務流程的組織帶來更大的靈活性。
保險業影響因素
目前保險業中所采用的技術有多種，包括大型機、UNIX 以及 Windows。在所應用的平台技術如此龐雜的情況下，要對不斷變化的金融市場保持靈活應對的同時進行管理和運作正變得越來越困難。多年以來，各個組織一直在構建並購買技術以滿足這些需要。互操作性已經成為在構建和/或實現了解決方案後不得不解決的棘手問題。之前，人們采用的是點到點集成的方式，但這種方法只能解決應用程序級或系統級的某些特定問題，而無法解決業務功能級的問題。
圖 1. 點到點集成的結果
如果不謹慎，多年以來的點到點集成會導致：
由於系統重復、集成形式多樣以及應用程序依賴性管理等原因，IT 資產組合變得無法管理。
大量的自定義集成造成 IT 系統成本大幅度上升。
由於代碼復雜性增加、重用性有限以及企業內部缺乏標准化，因此顯著降低了系統開發的速度，從而導致了靈活性的喪失。
那麼，對於眾多保險公司而言，這意味著什麼？這表示互操作性非常重要，不僅是效率問題，對提高公司競爭力也極為關鍵。在現代商業競爭中，公司必須通過簡化流程及提高靈活性來增加其 IT 系統的投資回報 (ROI)，從而保持競爭力。
我們的目標是利用 Microsoft 平台上的一組企業就緒技術來應對行業挑戰。示例中包含以下要素：
企業級解決方案
標准通信：
采用 WS-* 標准
ACORD 消息
確保與現有解決方案之間的互操作性
本文檔中使用的行業術語
ACORD—ACORD (www.acord.org) 是一個非贏利協會，其目的是促進保險、再保險以及相關金融服務行業標准的發展和使用。
訂單系統—創建對外部數據的請求，將其傳輸給相應的第三方數據提供者，管理收到的響應並將響應與相應的請求者對應起來。
第三方服務提供者—實現保險需求請求的外部系統（例如，信用評級系統）。
保險流程—執行新業務的評估和處理流程。
代理系統—可采用的智能客戶端前端系統，由保險代理人使用，作用是訂單輸入以及過程監視。也可使用其他前端系統，例如為代理人提供的 Web 門戶，或者由客戶自助輸入訂單的 Web UI。
人壽保險保單案例
客戶 Robert 要購買 1 百萬美元的白金級壽險。代理人 Tom 使用其智能客戶端應用程序來輸入 Robert 的保單申請。保單被發送到訂單系統，然後系統會對其進行處理並傳送到相應系統以開始保險流程。保單處於訂單系統中時，便會啟動第三方服務。在此案例中，我們使用 Paramed，這是一種核實保險申請人健康狀況以及醫療記錄的第三方服務。
如果滿足特定條件，內置業務邏輯也可以生成對第三方的請求。這裡的第三方可以是代理人或保險公司的另一個合作伙伴。
圖 2. 此案例的業務流程
結構概述
本節將介紹此案例中使用的高級邏輯結構。有關特定方面（如安全性、消息、開發和部署）的詳細信息會在本系列的其他文章中介紹。
為了確保適用於實際問題，我們會提出一組高級要求。
要求
以下是對企業級解決方案的要求：
必須能夠與已有的現成商業應用程序進行互操作。如前文所述，許多組織會購買並自定義軟件。因此，滿足此要求便顯得極為關鍵。
集成技術必須為 Web 服務。許多形式的通信（例如二進制通信）都是專用的。直到出現 Web 服務，才有了消息通信的標准化方法。Web 服務提供了在完全不同的平台間進行通信的方法。
必須采用 WS-* 標准。多年以來，采用 SOAP 和 WSDL 的 Web 服務一直是行業的集成標准。但是，這些傳統的 Web 服務缺乏消息傳遞所需要的健壯性。WS-* 標准提供了這些必要功能，而且不需要使用二進制通信。
長時間運行工作流。長時間業務管理非常困難，尤其是當該工作流還會衍生出許多更小的外部工作流時，在這種情況下協調和事務管理會變得極為復雜。
在此解決方案中，我們使用 BizTalk 作為消息中心，因為它功能強大，而且此保險解決方案非常需要將多個系統綁定在一起並管理多個外部工作流。
圖 3. 采用消息總線技術
圖 3 所顯示的是作為企業服務總線 (ESB) 的 BizTalk 的企業視圖。請注意，並不是一定要將它用作 ESB。本白皮書僅將此層作為消息層，因此在任何情況下都可以把它集成到解決方案中。
使用 BizTalk 的根本原因在於它能夠提供用於以下功能的集中化平台：
業務流程管理—將可重復使用的業務流程集中化不僅可給出服務導向，而且向組織提供了在無需修改現有或購買的現成（基於 COTS）商業應用程序的情況下對其進行擴展的機制。
工作流編排—通過該平台可以簡化對多個工作流的管理。從而按應有的方式管理解決方案，而不需要對每個工作流進行編碼或協調。我們通過創建一個工作流，來從頭至尾管理能夠編排多個內部系統工作流的業務流程。
豐富的適配器支持—快速開發對於組織而言有著重要的意義。BizTalk 具有多種適配器，可滿足集成需要。在保險領域，有一種 ACORD 適配器，可以使集成突飛猛進。Web 服務適配器和基於文件的適配器可與 ACORD 一起供 BizTalk 使用。
消息傳送和轉換—必須對消息進行轉換其他系統才能理解時，消息的傳送會非常復雜。BizTalk 可以提供平台，在降低復雜性的同時仍符合開放標准。
保險代理人保單系統
當前，保險行業中的技術發展方向包括門戶、胖客戶端、3270 主機終端仿真屏幕以及智能客戶端。在該領域存在各種應用程序和眾多供應商的情況下，基於以下理由，我們選擇采用智能客戶端用戶界面 (UI) 來為代理人提供最佳體驗：
離線和在線模式
不依賴網絡連接
增強的功能帶來更為豐富的用戶體驗
斷開模型對代理人而言非常適用，因為代理人會經常處於移動狀態或者在訪問網絡資源方面存在限制。但是，由於我們在構建此解決方案時將 Web 服務作為消息傳遞策略的核心，因此最終代理人提交保單的方式並不重要。
對於客戶端結構，使用 Windows 窗體作為用戶界面，來為代理人提供所需的用戶界面。界面上有一些控件，如數據網格、文本框及命令按鈕。Windows 窗體上的數據網格將由代理人使用，用作到保單管道的窗口。我們使用 Web 服務來更新該數據網格以確保實時更新。
由於這是智能客戶端，返回數據可以存放在緩存中以供離線查看和更新。這對代理人極其有用。除了數據，在客戶端應用程序上還會有一個小的業務邏輯層。大部分應用程序邏輯會駐留在保險公司這端。其根本原因是我們將使用輕量規則來驅動 UI 功能。
圖 4. 客戶端邏輯結構
要在客戶端發起對消息傳遞層的調用，我們將使用 Windows Communication Foundation (WCF)。WCF 會采用 ACORD 消息傳遞架構來發送 SOAP 1.2 Web 服務消息。WCF 為開發人員提供了用於編碼通信的統一開發模型。站在協議的角度，我們會采用一系列 WS-* 標准。但是，這還不足以確保互操作性。采用 ACORD 行業標准也很關鍵。我們應能在“本地生成”的應用程序、COTS 應用程序以及第三方服務之間進行無縫互操作。
消息傳遞結構
通過 Web 服務，各種通道便能利用通用的 Web 服務。該服務以 ACORD 103 消息（具有指定的保單號，在整個示例中將使用該號碼來進行跟蹤/關聯）的形式接收新的業務申請並將申請加入保險流程中。該 ACORD 103 New Business Submission 消息基於 SOAP 消息傳輸優化機制 (MTOM/XOP) 附件，其中包含 Robert 簽名的二進制表示，以根據 HIPAA 的要求授權發布醫療信息。顯然，將 ACORD 標准集成到消息傳遞中非常重要。這可確保結構的可移植性。
通信的安全性和可靠性也非常重要。為達此目的，我們將 WS-Secure Conversation (WS-SC) 用於可能要通過未知數目中間方的個人信息。我們還將 WS-SC 用於量大且頻繁的請求（例如信用審核），所有新的保單申請都會進行此類請求。我們將 WS-Security 用於頻率較低的請求，例如主治醫生報告 (APS)，其中建立會話的開銷大小並不由請求的量來決定。在極少數情況下，服務會直接處理請求而不經過任何中間傳送過程，此時我們也使用 TLS/SSL（也稱作 HTTPS）。
對於需要跟蹤接收情況的消息傳遞（例如確保接收到新的保單以獲得代理權），我們會使用 WS- Reliable Messaging (WS-RM)。我們也會將 WS RM 用於處理起來代價高昂的數據請求（這種情況通常涉及人力工作流，如 APS 查詢）。這確保請求只傳遞一次，避免了代價高昂的重復請求。
對於長時間運行的消息，我們使用 WS-Secure Conversation (WS-SC)（請參閱資源）。
圖 5. 客戶端消息交換模式
事務 業務流程 WS-* 協議 結構決策 提交新保單（103 請求） 代理客戶端表 1：業務流程消息傳遞設計決策矩陣
在進行提交後，您可能會問自己：為什麼狀態在單獨的事務中返回？原因有兩方面。首先，該過程異步進行很重要，並且 ACORD 標准不允許在沒有將狀態從提交分離出來的情況下進行實施。其次，通過查詢狀態服務，代理人可以定期從申請過程獲得返回狀態。
保險公司系統
過去在構建解決方案的服務器端時，需要考慮下列問題：
該結構用於碎片系統。
功能區域是自我包含的，需要進行管理。
操作系統和開發環境存在差異。
結果就是，存在大量與特定應用程序的點到點集成，因而需要專門的實現過程。在本解決方案中，會圍繞這些現有的應用程序創建外層。
圖 6. 保險消息總線
在本圖中，您可以看到我們如何將企業服務總線 (ESB) 用作消息總線。該層會作為管理內部和外部消息的集中化消息傳遞層來發揮作用。管理和編排功能是該結構重要的優點。
此類基礎結構可以將智能的長時間運行業務流程和事務策略置於一層而不是多層，從而使不同的點到點集成變得井然有序。在五或六個以上的系統中具有幾個截然不同的基於 COTS 的應用程序以完成端到端的事務處理會很普遍。我們正通過合並冗余功能（例如工作流和消息傳遞）來減小系統，將基礎結構級的功能留在其所屬位置並在適用的應用程序中保留業務邏輯。
請務必牢記，此消息總線是“邏輯”表示。“實現”視圖與此有相當大的差異。例如，消息總線可能是多個 BizTalk 服務器，或者是由位於不同 DMZ 環境中的服務器來管理內部和外部通信。
圖 7. 工作流設計器
下面一層（在其中執行特定業務功能）包含以一個接口封裝的兩個不同的傳統系統：訂單系統和履行系統。我們將它們作為單獨的系統而不是把它們合並在一起的原因是，多數時候，這是兩個獨立的、基於 COTS 的系統。
添加狀態系統的原因是：
提供集中化的方法以向代理人報告狀態。
減少查詢多個系統所需的接口和控制邏輯的數量。
它能與用於長時間運行工作流的 ESB 的編排功能絕佳配合。
訂單系統和履行系統已轉換為過程消除服務。這樣可以消除獨立實現之間的依賴性。這些系統的所有通信現在都會經過消息中心。然後，通過消息總線來管理的公開 Web 服務端點可以利用內置在 BizTalk 中的編排技術來管理。
圖 8. 端到端消息交換模式
由於這些應用程序作為 Web 服務公開，任何接受 Web 服務 XML 的技術都可以和這些應用程序集成。這消除了其他技術協議間可能會限制互操作性的緊密耦合。例如，如果您之前用的是基於 Java 的系統，您現在仍可對這些系統進行輕松使用。
SQL Server 在此處用於將應用程序數據存儲在數據庫層中。由於本白皮書的中心是集成和復合應用程序，在此我們就不對這一點進行重點介紹了。
引用的第三方服務是外部服務，由履行服務來調用。這些服務有不同的協議要求。但是，本白皮書會向您展示 WS-* 標准是如何提供更多用於服務的功能。請務必注意，許多實際的保險第三方服務只支持基於 XML 的通信，而不支持更加高級的基於 SOAP 的 Web 服務。後面的消息傳遞結構部分會介紹更多關於第三方服務的內容。
保險公司消息傳遞結構
本節會介紹由保險公司處理的基本壽險保單。在 Robert 所提供信息的基礎上，保險流程中定義的業務規則/啟發邏輯確定還需要主治醫生報告 APS（即身體檢查）。
因為另一個提供者必須執行該請求，訂單系統會創建 ACORD XML TransType 121 General Requirements Order Request 事務 (TXLifeRequest)，並將它傳輸給 Robert 的醫生所用的二級外部訂單系統（APS 系統）。該消息還包含 Robert 簽名的 MTOM/XOP 附件，簽名初始由 ACORD 103 New Business Submission 攜帶，用於授權他的醫生向保險公司發布其醫療信息。
在某個時刻，Robert 的醫生會驗證 Robert 的簽名是否與他所擁有的文件上的簽名匹配，然後檢查 Robert 的疾病史，填寫 APS 報告上要求的信息，從而完成 APS 訂單的處理。
在醫生完成 APS 報告後，會生成 1122 General Requirements Status/Results Transmittal 消息並將其傳輸回 WS-Addressing ReplyTo（在之前的 ACORD 121 中指定）中指定的端點引用。也會使用 WS-Reliable Messaging 來可靠傳遞該消息。
業務流程的其余部分開始執行，其中包括所有自動保險統計師決策。但是，在本例中，由於有 APS 以及一些可能無法自動處理的附加信息，因此該案例會被標記以供保險商檢查和批准。
圖 9. 保險流程消息交換模式
履行服務
在保險業中，履行系統或服務與履行的流程大不相同：
履行系統：接收請求並執行的系統或服務。可將履行服務視為用於收集數據的集成組件。在本例中，履行系統負責從第三方提供者收集各種報告。
履行流程：保險公司核發保單的流程。
您可能會問，為什麼要保留履行服務。就本例而言，我們假設此類系統是被作為黑盒解決方案購買的。這並不是說不能刪除這些層並轉而將其合並到消息總線中。
選擇消息傳遞模式並不像選擇一組標准那麼容易。在設計解決方案的這部分時，必須停下來查看一下每個事務的業務和傳統方面。
某些事務，例如接收信用報告，比較容易確定。但是，諸如請求 APS 報告的事務，則要求具有附件功能。
以下是一些在設計消息傳遞時要考慮的內容：
理解業務流程。理解業務使用這些消息的方式（例如，確保數據安全）非常重要。如果正發送的數據不敏感，則無需對消息采取大量安全預防措施。
理解服務提供者如何使用事務。這包含內部和外部兩方面。很多時候，在利用服務提供者時會存在技術上的限制，包括標准支持及操作時間等。
適當關注安全性。這一點經常被忽視。大多數情況下，SSL/TLS 之類的協議級安全便已足夠，但並非總是如此。務必要對數據的敏感性進行評估，並檢查消息路徑以確定在最終使用者前有多少個端點。
注重實際。設計這些服務時，不要試圖采用每一個標准。如果標准不屬於某個消息，不要強行將它置於其中。這只會帶來不必要的復雜性。
圖 10. 履行系統消息交換模式
具有什麼價值？
通過本示例，我們介紹了許多關於 Microsoft 平台和開發技術的知識。也重點介紹了結構決策。但是我們沒有就這些 Microsoft 技術的功能進行專門介紹。
以下是在保險業中使用 Microsoft 技術的主要優點：
業務流程自動化—業務流程非常復雜，並且每個運營商都有其獨特的運作方式。有了 BizTalk 提供的編排工具，便可由業務分析人員來開發業務流程，不但使開發人員從這項工作中脫離出來，還對業務提供了更好的支持。
減少集成代碼—利用 BizTalk 中的自定義適配器以及 WCF 的統一編程模型，集成系統所需要的代碼大大減少。
符合標准—WCF 和 BizTalk 本質上基於開放式 XML 標准。因此集成 Web 服務標准無需再進行自定義編碼。
效率—通過集成的 Visual Studio IDE 和 .NET 3.0 技術，工具和開發語言兩者相結合帶來了其他語言無法比擬的高效率。
總結
如同本白皮書所展示的一樣，僅采用協議級標准遠遠不夠，捕捉消息傳遞事務的業務方面才是讓互操作性為業務服務的關鍵。這適用於各個行業，而不僅僅是保險業。
我們擁有 Web 服務標准，但那不是全部。您仍然需要執行必要的操作以便為您的企業做出最佳技術決策。利用此特定的引用實現，我們介紹了一個實際的案例並根據該案例的業務影響因素來確定最佳消息傳遞。在選擇適用於貴組織的消息交換模式時，可將此用作參考。建立了所有的結構後，選擇特定標准時就有了權衡。重要的是理解這些權衡的意義並采用正確的標准。
Microsoft 致力於使其客戶能夠更加輕松地構建並開發面向服務的解決方案。通過本文，您可以發現 Microsoft 已消除了讓客戶望而生畏的行業壁壘和復雜性。從提供行業標准中的領先觀念到自動執行並構建現成的 Web 服務支持，Microsoft 均能為您一一呈獻。
