午啪啪夜福利无码亚洲,亚洲欧美suv精品,欧洲尺码日本尺码专线美国,老狼影院成年女人大片

1、如同其它IT項目一樣，企業服務總線類項目的實施也要經歷需求分析、方案設計、編碼和測試、上線部署等階段。下面我們將針對ESB項目的設計和實施過程中各個階段要完成的主要工作內容和一些最佳實踐跟大家作一些討論，進而希望大家在企業ESB項目實施過程中借鑒科學的方法論的指導來保證其成功。ESB的需求分析需求分析階段是梳理項目中相關功能需求和非功能需求的重要步驟，它是整個項目成敗的關鍵。在這個階段我們將從企業業務需求出發，梳理端到端的跨系統業務流程；基于業務流程，依據科學的方法論進行服務鑒別；由服務列表出發，梳理服務的消費和提供關系；然后根據SOA的最佳實踐，定義服務的接口，包括服務的Schema描述，字2、段的類型，編碼的規則；依據服務的消費提供關系，梳理ESB中的服務映射和轉換規則和策略。概括而言，我們需要從功能性和非功能性兩個方面來進行ESB的需求分析。針對ESB的功能性需求，我們要側重了解以下方面的問題：1. 梳理出要被集成的系統的名稱，個數。2. 針對每個系統而言，要了解：該系統的對外接口是向外調用，被別人調用，還是二者都有； 接口的實時性要求，是實時的還是批量的，還是二者皆有？ 接口的調用方式，是同步的還是異步的，還是二者皆有？ 應用系統所運行的操作系統平臺。 應用系統本身的編程語言？C/C+, Java. 這些系統現有接口的情況，是否已經可以提供對外接口，接口的方式是什么，包括接口的3、通訊協議是什么，HTTP/MQ/Socket/ 其它？接口的數據格式是什么，XML/ 自定義格式 / 其他行業標準格式？接口的編程語言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口開發時有什么要求或限制條件？ 這些應用后臺數據庫的情況，數據庫能否直接訪問？ 每個應用跟其他應用交換數據時，源數據格式和目的數據格式，比如從文本格式轉換為 XML 格式？ 交易特征：哪些處理要采用兩階段提交；是否需要多個消息組成一個交易；是否要保證消息之間的處理順序； 適配器的情況：對于一些特殊系統，是否已經具備現成的適配器；適配器是單向的還是雙向的； 消息通信的模式：是Send and Forget4、Request/Reply還是Pub/Sub? 針對ESB的非功能性需求，我們要確認：1. ESB平臺的擴展性和高可用性需求，包括HA和集群等；2. ESB平臺的性能需求，主要包括系統間數據交換的頻率，要交換的數據的大小 ( 消息大小將直接對效率造成影響 )；峰值時候對ESB數據吞吐量、響應時間的要求等；3. 哪些交易要保證數據傳輸的高可靠性；4. ESB平臺的可管理性需求，如服務的生命周期管理，ESB 平臺的維護和管理；如果企業已經設立了SOA管控方面的規范，那么要遵從規范的制約，比如要考慮是否有規定的命名規則，企業是否有企業級的數據規范和底層通訊協議的規范等；5. 安全性方面的要求：是否5、采用SSL傳輸加密，是否對消息進行加密/解密處理等；6. 錯誤處理和日志以及平臺本身的運行監控等方面的要求等。ESB的方案設計方案設計的主要內容包括：ESB涉及IT應用環境分析，定義ESB與相關應用的接口模式； ESB架構概要設計，并定義架構原則； ESB相關產品選擇，包括與外圍系統的適配器選擇和ESB產品選擇； ESB組件模型設計，分解ESB的相關模塊，滿足SOA的分離關注點等架構原則； ESB運作模型設計，滿足平臺的非功能性需求； ESB平臺的服務流設計，涉及路由、轉換和映射等； ESB的同步、異步或者發布/訂閱模式設計； ESB平臺的接入渠道和數據接口設計，包括XML/JMS、SOAP/6、HTTP、EDI/MQ 等； ESB相關的適配器設計，包括技術適配器或者自開發的適配器； ESB平臺的容錯和重試機制設計，包括日志等的統一管理等； 圖 1 是一個采用ESB整合的高層架構設計舉例：圖 1. ESB參考架構 如圖 1 所示，ESB架構設計時主要要考慮通訊協議接入和轉換、數據接入和轉換、數據處理流程以及服務的注冊和管理等方面的內容。其中通訊協議接入和轉換是指對各種被集成的應用系統的通訊協議的支持和轉換能力，例如HTTP、JMS、Socket、FTP等；數據接入和轉換是指對各種被集成的應用系統提供的數據格式的支持和轉換能力，例如XML、SOAP、自定義格式以及符合某些行業標準的專有格7、式（SWIFT、EDI、HL7 等）；數據處理流程是指路由、格式轉換、數據庫讀寫等對數據的各種處理；統一服務注冊存儲管理是指對服務的注冊、發布、查詢，以及對運營時服務的管控，并且提供服務運營狀態的統計分析數據。ESB的組件模型圖 2. ESB組件模型 圖 2 給出了一個ESB組件模型的示例，其中包含的各主要組件及其功能如下：1. Message Broker Runtime組件提供消息路由、格式轉換、消息日志等操作的運行時環境。該運行環境由IBM Message Broker提供；2. Messaging Broker Instance組件是處理基于MQ消息業務請求的容器。它是作為一個Brok8、er實例運行在Message Broker Runtime上的。該實例提供了MQ消息的業務請求處理器、服務日志、服務定位等功能的運行容器；3. Web Service Broker Instance組件是處理基于Web Service的業務請求的容器，它是作為一個Broker實例運行在Message Broker Runtime上的。該實例提供了Web Service的業務請求處理、服務日志、以及服務定位等功能。4. Event Broker Instance組件是平臺內部處理Pub/Sub事件的容器。它是作為一個Broker實例運行在Message Broker Runtime上的。該容器提9、供了Event Handler組件的運行環境，將基于MQ/JMS的事件分發到不同平臺組件的目標隊列上。5. Message Handler組件是處理基于MQ消息的業務請求，包括消息解析、格式轉換，服務鑒權與認證、服務路由、服務日志等功能。Message Handler組件處理MQ消息的典型流程如下：首先對MQ消息進行解析，對解析后的業務請求進行分析，之后通過Authentication 與 Authorization組件判斷該請求者的業務請求是否可以進行后續處理； 通過Service Locating組件對該業務請求進行服務定位與路由；將基于MQ的業務請求消息轉換成Web Service的業務10、請求消息； 通過Service Logging組件對整個業務請求進行日志記錄； 返回業務請求處理結果給業務發起者，如果失敗，返回錯誤消息。 6. Web Service Handler組件是處理基于Web Service的業務請求，與Message Handler組件功能類似，也包括消息解析、格式轉換，服務鑒權與認證、服務路由、服務日志等功能。Web ServiceHandler組件處理Web Service請求的典型流程如下：首先對Web Service請求消息進行解析，對解析后的業務請求進行分析，之后通過Authentication與Authorization組件判斷該請求者的業務請求是否11、可以進行后續處理； 通過Service Locating組件對該業務請求進行服務定位與路由； 通過 Service Logging 組件對整個業務請求進行日志記錄； 返回業務請求處理結果給業務發起者，如果失敗，返回錯誤消息。 7. Event Handler組件實現對Pub/Sub的處理。8. Service Locating組件負責根據業務請求定位具體的服務提供者。Service Locating通過對服務目錄的查詢選擇適合的服務進行后續的調用，該查詢工作可以通過實時的服務目錄查詢獲得結果。9. Service Logging組件負責記錄整個業務請求處理過程中的情況，該組件的實現可以通過文件12、或者數據庫的方式。10. Authentication組件負責對業務請求者進行鑒權，判斷該業務請求者是否可以訪問平臺服務，該鑒權的工作在企業服務總線的外部進行，Authentication組件只是調用外部功能完成。11. Authorization組件判斷業務請求者是否具備訪問某特定服務的權限，該驗證權限的工作在企業服務總線的外部進行，Authorization 組件只是調用外部功能完成。以處理基于MQ消息輸入為例，ESB的組件交互圖如圖 3 所示：圖 3. ESB組件交互圖 ESB方案設計時的最佳實踐根據我們以往項目設計和開發時的一些經驗，我們建議進行ESB的方案設計時要遵循下述最佳實踐：確13、定標準的使用：使用與否、使用到什么程度； 確定在ESB上實現的業務邏輯：ESB是一個服務路由和轉換中心，而不是一個應用服務器，因此它并不能取代應有服務器。復雜的消息解析和轉換相比簡單的路由操作所需消耗的成本要高的多，因此在ESB上應該主要考慮路由、格式轉換、服務調用等問題，而對于數據本身的處理應該交給相應的應用來完成； 確定消息格式：從標準化的角度而言，XML當然是首選，但是從解析 / 處理性能、行業標準以及對現有應用的最大兼容性的角度而言，可能會采用某些特定格式，例如EDI、SWITF、平文本或者自定義格式等； 區別消息頭和消息體：把數據的Meta-data，例如：安全相關的信息、日志的等級14、請求端的標識等放在消息頭中，而不要放在消息體中。這樣可以很容易地改變其內容及其對其的處理邏輯。在ESB中只處理消息頭，避免對消息體的解析； 設計時參考ESB相關的成熟Patterns； 使用服務注冊庫：如需要服務Endpoint的查找：推薦從服務注冊中心進行查找，這樣的好處在于：服務提供者可以容易地發布新的服務，服務提供者和ESB之間的耦合度可以更低，通過關于服務本身的Metadata來進行服務的查找和路由； 注重性能和高可用性的考慮； 在必須的情況下考慮交易完整性； 適配器的采用：應用系統通過適配器實現與 ESB 的雙向交互，適配器主要分為技術適配器、應用適配器兩種，適配器的物理部署可以與15、EIS部署在一起、或者與ESB部署在一起，也可以單獨部署，在適配器設計時要考慮通信協議和消息格式兩個方面；多 ESB 的設計：ESB 也是一個邏輯的組件，在一個企業里可能需要多個ESB，例如：企業內部ESB連接企業內部各個系統，外部ESB實現企業與合作伙伴等的外部連接；再如：企業內部可能存在若干個部門級ESB和一個全企業ESB； 確定服務版本控制策略； 確定端到端的QoS準則； 注重安全性； 確定IT部門ESB平臺的負責主體，長期的投入。 ESB的安全性考慮對于ESB的安全性考慮，主要有兩種方式，第一種方式是通過ESB內部的Mediation節點來進行服務請求者的認證 / 授權；另一種是調用一16、個外部服務進行服務請求者的認證 / 授權，如圖4所示，圖中給出了這兩種方式的示意圖，具體實施時可以進行選擇。圖 4. ESB的兩種安全實現方式 運行在ESB平臺上的服務的管理和監控當一個企業開始它的SOA之旅時，開始階段通常會選取一個具體的項目進行 SOA 的嘗試，然后便會逐步走向全企業采納，這時，大多數企業都會面臨一個問題，那就是服務越來越多，對這些服務目錄的管理出現了很多問題，例如：所有與服務相關的信息是如何被管理的，包括存儲、管理、維護、存取等？服務請求者如何決定使用哪個服務？服務請求者如何定位服務的 Endpoint？當服務信息發生改變時如何得到通知？因此我們建議用戶在盡可能早的情況下17、考慮服務注冊中心的建設，所謂服務注冊中心是一個企業范圍內的服務信息的存儲庫，該存儲庫存儲了企業中注冊的服務和服務相關的信息，它的主要功能包括：采用集中的方式來管理服務相關的信息，為服務元數據同時提供“注冊中心”功能，允許用戶存儲、管理和查詢包含服務描述的服務元數據構件； 提供服務的治理功能，實現整個服務生命周期的管理； 提供服務間依賴、包容關系的管理； 提供分類和版本控制等功能； 提供服務發現和通知等能力等。 除了服務注冊中心的考慮之外，我們還要考慮對服務的管理。服務不僅具有特定的功能，還應該滿足一些諸如性能、可用性、安全性等QoS指標。服務響應的快慢、什么時間可用、可以被誰調用、在某個時間段18、里能被調用多少次、哪些事件要記錄日志，這些都是服務管理要考慮的問題。通過服務注冊中心和服務監控平臺的有機配合，我們可以根據服務的響應時間、服務可用與否等策略來實現對服務的動態訪問。讓我們來看一個例子：圖 5. 使用服務監控平臺之前ESB的服務請求和響應圖 6. 使用服務監控平臺之后ESB的服務請求和響應 如圖 5 和圖 6 所示，我們可以利用服務監控平臺對服務進行監控和統計分析，從而使ESB平臺可以根據服務提供者的性能優劣來動態地綁定和調用高性能的服務，其過程如下：服務請求者請求“PurchaseOrder”服務 服務注冊庫查找到服務提供者 服務注冊管理平臺第一次調用了Proder1提供的服務19、 Provider1的性能被監控工具監控到 隨著時間的推移，Provider1的性能越來越差 監控軟件監控到這一現象，就會停止使用Provider1提供的服務 當下一次服務請求者再次請求此服務時，服務注冊管理平臺將調用Provider2，請求來自Provider2提供的服務。 ESB的開發和測試在ESB開發和測試階段要完成的工作主要包括：基于eclipse工具的模型驅動的快速開發； ESB集成流程的開發； ESB路由、消息處理邏輯的開發； ESB數據映射和轉換的開發； ESB外圍適配器的開發和配置； 單元測試：基于模塊的測試，包括適配器的測試，路由的測試，BO的測試等； 集成測試：ESB與其他服務提供者和服務消費者的集成測試，重點關注服務接口； ESB平臺的性能測試以及系統測試，即整個ESB涉及到的端到端業務場景的測試等。進行基于WebSphere Message Broker平臺進行ESB開發時，通常要考慮以下一些方面的最佳實踐，例如：通用的錯誤 / 例外處理、通用的日志 / 管理機制、子流程設計、交易完整性和消息永久性、ESQL的使用等。