ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx_第1頁
ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx_第2頁
ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx_第3頁
ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx_第4頁
ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式.docx_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

ESB提供事件驅(qū)動(dòng)和文檔導(dǎo)向的處理模式,以及分布式的運(yùn)行管理機(jī)制,支持基于內(nèi)容的路由和過濾,具備了復(fù)雜數(shù)據(jù)的傳輸能力,并可以提供一系列的標(biāo)準(zhǔn)接口。ESB是中間件技術(shù)實(shí)現(xiàn)并且支持SOA的一組基礎(chǔ)架構(gòu),支持異構(gòu)環(huán)境中的服務(wù)、消息以及基于事件的交互,并且具有適當(dāng)?shù)姆?wù)級(jí)別和可管理性。ESB是SOA中的消息框架,即消息相互交換和通信的方式,是業(yè)界標(biāo)準(zhǔn)與客戶消息框架的整合。分布式部署和集中控制。ESB服務(wù)器在物理上可能相隔很遠(yuǎn),但是通過集中管理,這些服務(wù)器組成一個(gè)ESB網(wǎng)絡(luò),在邏輯上形成完整的企業(yè)服務(wù)總線。服務(wù)注冊(cè)、發(fā)布和編排。在Apusic ESB的服務(wù)倉(cāng)庫(kù)中,任何符合標(biāo)準(zhǔn)的服務(wù)都可以在其中注冊(cè),從而被其他服務(wù)調(diào)用。而消費(fèi)服務(wù)也無需知道被調(diào)用服務(wù)的具體特征,只需要發(fā)送相應(yīng)地請(qǐng)求即可找到相應(yīng)的服務(wù),并進(jìn)。行綁定和數(shù)據(jù)的傳輸。同時(shí)為了滿足具體的業(yè)務(wù)需求,不同的服務(wù)需要被組裝在一起形成新的應(yīng)用系統(tǒng)。Apusic ESB引入了工作流流程的概念,引入自主實(shí)現(xiàn)且基于業(yè)界標(biāo)準(zhǔn)的,具有條件分支和合并并行流轉(zhuǎn)功能的BPEL4WS流程引擎,從而實(shí)現(xiàn)綜合的、復(fù)雜的業(yè)務(wù)邏輯編排。這個(gè)流程引擎支持子流程、條件腳本、路由節(jié)點(diǎn)等功能。通過靈活的流程定義,按照即時(shí)的業(yè)務(wù)需求,將單個(gè)離散服務(wù)有機(jī)的組合起來,達(dá)到服務(wù)重組的目的,完成集成的業(yè)務(wù)需求。 此外,Apusic ESB在引擎級(jí)別將BPEL規(guī)范的細(xì)節(jié)進(jìn)行了包裝,對(duì)用戶來說,只需要關(guān)心流程中的一個(gè)服務(wù)即可,無須再去關(guān)心BPEL的具體技術(shù)細(xì)節(jié)。 最后,所有的調(diào)用、轉(zhuǎn)換都必須有一個(gè)良好的管理工具來幫助實(shí)施,并進(jìn)行監(jiān)控。Apusic ESB則提供了一體化的管理工具,通過這些工具,您可以非常方便的對(duì)ApusicESB進(jìn)行集中式管理、可視化的流程設(shè)計(jì),以及運(yùn)行期的實(shí)時(shí)監(jiān)控等功能。SOA項(xiàng)目不應(yīng)從ESB開始,因?yàn)镋SB只是技術(shù)手段,而SOA的目標(biāo)則是業(yè)務(wù)價(jià)值。對(duì)技術(shù)手段的過分重視往往使人們忽略了SOA的最終目標(biāo),陷入在技術(shù)的泥潭當(dāng)中不能自拔。 以ESB來啟動(dòng)一個(gè)SOA項(xiàng)目是有害的,它將陷入技術(shù)的怪圈中,而無法產(chǎn)生最大的業(yè)務(wù)價(jià)值。業(yè)務(wù)才應(yīng)該是SOA開始的起點(diǎn)和最終的目標(biāo)。你首先要在業(yè)務(wù)上進(jìn)行服務(wù)的分解,然后才把他們映射到技術(shù)實(shí)現(xiàn)中。 SOA項(xiàng)目的實(shí)施必須從業(yè)務(wù)需求的分析開始,而不是從構(gòu)建ESB來開始。SOA框架體系下的軟件開發(fā),應(yīng)該是從業(yè)務(wù)流程分析開始的,用一些組件化的業(yè)務(wù)建模方法,對(duì)實(shí)際的業(yè)務(wù)場(chǎng)景進(jìn)行分析。在這個(gè)基礎(chǔ)上建立業(yè)務(wù)用例,并根據(jù)這些業(yè)務(wù)用例構(gòu)造業(yè)務(wù)流程模型。ESB不過工具和技術(shù)而已,關(guān)鍵上集成業(yè)務(wù)如何做?業(yè)務(wù)邏輯如何編制?如何實(shí)施? ESB項(xiàng)目需求分析和方案設(shè)計(jì)淺談2010-1-6如同其它IT項(xiàng)目一樣,企業(yè)服務(wù)總線類項(xiàng)目的實(shí)施也要經(jīng)歷需求分析、方案設(shè)計(jì)、編碼和測(cè)試、上線部署等階段。下面我們將針對(duì)ESB項(xiàng)目的設(shè)計(jì)和實(shí)施過程中各個(gè)階段要完成的主要工作內(nèi)容和一些最佳實(shí)踐跟大家作一些討論,進(jìn)而希望大家在企業(yè)ESB項(xiàng)目實(shí)施過程中借鑒科學(xué)的方法論的指導(dǎo)來保證其成功。 TT SOA編輯推薦:企業(yè)服務(wù)總線ESB(更新版)ESB的需求分析需求分析階段是梳理項(xiàng)目中相關(guān)功能需求和非功能需求的重要步驟,它是整個(gè)項(xiàng)目成敗的關(guān)鍵。在這個(gè)階段我們將從企業(yè)業(yè)務(wù)需求出發(fā),梳理端到端的跨系統(tǒng)業(yè)務(wù)流程;基于業(yè)務(wù)流程,依據(jù)科學(xué)的方法論進(jìn)行服務(wù)鑒別;由服務(wù)列表出發(fā),梳理服務(wù)的消費(fèi)和提供關(guān)系;然后根據(jù)SOA的最佳實(shí)踐,定義服務(wù)的接口,包括服務(wù)的Schema描述,字段的類型,編碼的規(guī)則;依據(jù)服務(wù)的消費(fèi)提供關(guān)系,梳理ESB中的服務(wù)映射和轉(zhuǎn)換規(guī)則和策略。概括而言,我們需要從功能性和非功能性兩個(gè)方面來進(jìn)行ESB的需求分析。針對(duì)ESB的功能性需求,我們要側(cè)重了解以下方面的問題:1. 梳理出要被集成的系統(tǒng)的名稱,個(gè)數(shù)。2. 針對(duì)每個(gè)系統(tǒng)而言,要了解:該系統(tǒng)的對(duì)外接口是向外調(diào)用,被別人調(diào)用,還是二者都有; 接口的實(shí)時(shí)性要求,是實(shí)時(shí)的還是批量的,還是二者皆有? 接口的調(diào)用方式,是同步的還是異步的,還是二者皆有? 應(yīng)用系統(tǒng)所運(yùn)行的操作系統(tǒng)平臺(tái)。 應(yīng)用系統(tǒng)本身的編程語言?C/C+, Java. 這些系統(tǒng)現(xiàn)有接口的情況,是否已經(jīng)可以提供對(duì)外接口,接口的方式是什么,包括接口的通訊協(xié)議是什么,HTTP/MQ/Socket/ 其它?接口的數(shù)據(jù)格式是什么,XML/ 自定義格式 / 其他行業(yè)標(biāo)準(zhǔn)格式?接口的編程語言是什么,Java/C/C+?如果本身不能提供接口,那么要做接口開發(fā)時(shí)有什么要求或限制條件? 這些應(yīng)用后臺(tái)數(shù)據(jù)庫(kù)的情況,數(shù)據(jù)庫(kù)能否直接訪問? 每個(gè)應(yīng)用跟其他應(yīng)用交換數(shù)據(jù)時(shí),源數(shù)據(jù)格式和目的數(shù)據(jù)格式,比如從文本格式轉(zhuǎn)換為 XML 格式? 交易特征:哪些處理要采用兩階段提交;是否需要多個(gè)消息組成一個(gè)交易;是否要保證消息之間的處理順序; 適配器的情況:對(duì)于一些特殊系統(tǒng),是否已經(jīng)具備現(xiàn)成的適配器;適配器是單向的還是雙向的; 消息通信的模式:是Send and Forget、Request/Reply還是Pub/Sub? 針對(duì)ESB的非功能性需求,我們要確認(rèn):1. ESB平臺(tái)的擴(kuò)展性和高可用性需求,包括HA和集群等;2. ESB平臺(tái)的性能需求,主要包括系統(tǒng)間數(shù)據(jù)交換的頻率,要交換的數(shù)據(jù)的大小 ( 消息大小將直接對(duì)效率造成影響 );峰值時(shí)候?qū)SB數(shù)據(jù)吞吐量、響應(yīng)時(shí)間的要求等;3. 哪些交易要保證數(shù)據(jù)傳輸?shù)母呖煽啃裕?. ESB平臺(tái)的可管理性需求,如服務(wù)的生命周期管理,ESB 平臺(tái)的維護(hù)和管理;如果企業(yè)已經(jīng)設(shè)立了SOA管控方面的規(guī)范,那么要遵從規(guī)范的制約,比如要考慮是否有規(guī)定的命名規(guī)則,企業(yè)是否有企業(yè)級(jí)的數(shù)據(jù)規(guī)范和底層通訊協(xié)議的規(guī)范等;5. 安全性方面的要求:是否采用SSL傳輸加密,是否對(duì)消息進(jìn)行加密/解密處理等;6. 錯(cuò)誤處理和日志以及平臺(tái)本身的運(yùn)行監(jiān)控等方面的要求等。ESB的方案設(shè)計(jì)方案設(shè)計(jì)的主要內(nèi)容包括:ESB涉及IT應(yīng)用環(huán)境分析,定義ESB與相關(guān)應(yīng)用的接口模式; ESB架構(gòu)概要設(shè)計(jì),并定義架構(gòu)原則; ESB相關(guān)產(chǎn)品選擇,包括與外圍系統(tǒng)的適配器選擇和ESB產(chǎn)品選擇; ESB組件模型設(shè)計(jì),分解ESB的相關(guān)模塊,滿足SOA的分離關(guān)注點(diǎn)等架構(gòu)原則; ESB運(yùn)作模型設(shè)計(jì),滿足平臺(tái)的非功能性需求; ESB平臺(tái)的服務(wù)流設(shè)計(jì),涉及路由、轉(zhuǎn)換和映射等; ESB的同步、異步或者發(fā)布/訂閱模式設(shè)計(jì); ESB平臺(tái)的接入渠道和數(shù)據(jù)接口設(shè)計(jì),包括XML/JMS、SOAP/HTTP、EDI/MQ 等; ESB相關(guān)的適配器設(shè)計(jì),包括技術(shù)適配器或者自開發(fā)的適配器; ESB平臺(tái)的容錯(cuò)和重試機(jī)制設(shè)計(jì),包括日志等的統(tǒng)一管理等; 圖 1 是一個(gè)采用ESB整合的高層架構(gòu)設(shè)計(jì)舉例:圖 1. ESB參考架構(gòu) 如圖 1 所示,ESB架構(gòu)設(shè)計(jì)時(shí)主要要考慮通訊協(xié)議接入和轉(zhuǎn)換、數(shù)據(jù)接入和轉(zhuǎn)換、數(shù)據(jù)處理流程以及服務(wù)的注冊(cè)和管理等方面的內(nèi)容。其中通訊協(xié)議接入和轉(zhuǎn)換是指對(duì)各種被集成的應(yīng)用系統(tǒng)的通訊協(xié)議的支持和轉(zhuǎn)換能力,例如HTTP、JMS、Socket、FTP等;數(shù)據(jù)接入和轉(zhuǎn)換是指對(duì)各種被集成的應(yīng)用系統(tǒng)提供的數(shù)據(jù)格式的支持和轉(zhuǎn)換能力,例如XML、SOAP、自定義格式以及符合某些行業(yè)標(biāo)準(zhǔn)的專有格式(SWIFT、EDI、HL7 等);數(shù)據(jù)處理流程是指路由、格式轉(zhuǎn)換、數(shù)據(jù)庫(kù)讀寫等對(duì)數(shù)據(jù)的各種處理;統(tǒng)一服務(wù)注冊(cè)存儲(chǔ)管理是指對(duì)服務(wù)的注冊(cè)、發(fā)布、查詢,以及對(duì)運(yùn)營(yíng)時(shí)服務(wù)的管控,并且提供服務(wù)運(yùn)營(yíng)狀態(tài)的統(tǒng)計(jì)分析數(shù)據(jù)。ESB的組件模型圖 2. ESB組件模型 圖 2 給出了一個(gè)ESB組件模型的示例,其中包含的各主要組件及其功能如下:1. Message Broker Runtime組件提供消息路由、格式轉(zhuǎn)換、消息日志等操作的運(yùn)行時(shí)環(huán)境。該運(yùn)行環(huán)境由IBM Message Broker提供;2. Messaging Broker Instance組件是處理基于MQ消息業(yè)務(wù)請(qǐng)求的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該實(shí)例提供了MQ消息的業(yè)務(wù)請(qǐng)求處理器、服務(wù)日志、服務(wù)定位等功能的運(yùn)行容器;3. Web Service Broker Instance組件是處理基于Web Service的業(yè)務(wù)請(qǐng)求的容器,它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該實(shí)例提供了Web Service的業(yè)務(wù)請(qǐng)求處理、服務(wù)日志、以及服務(wù)定位等功能。4. Event Broker Instance組件是平臺(tái)內(nèi)部處理Pub/Sub事件的容器。它是作為一個(gè)Broker實(shí)例運(yùn)行在Message Broker Runtime上的。該容器提供了Event Handler組件的運(yùn)行環(huán)境,將基于MQ/JMS的事件分發(fā)到不同平臺(tái)組件的目標(biāo)隊(duì)列上。5. Message Handler組件是處理基于MQ消息的業(yè)務(wù)請(qǐng)求,包括消息解析、格式轉(zhuǎn)換,服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Message Handler組件處理MQ消息的典型流程如下:首先對(duì)MQ消息進(jìn)行解析,對(duì)解析后的業(yè)務(wù)請(qǐng)求進(jìn)行分析,之后通過Authentication 與 Authorization組件判斷該請(qǐng)求者的業(yè)務(wù)請(qǐng)求是否可以進(jìn)行后續(xù)處理; 通過Service Locating組件對(duì)該業(yè)務(wù)請(qǐng)求進(jìn)行服務(wù)定位與路由;將基于MQ的業(yè)務(wù)請(qǐng)求消息轉(zhuǎn)換成Web Service的業(yè)務(wù)請(qǐng)求消息; 通過Service Logging組件對(duì)整個(gè)業(yè)務(wù)請(qǐng)求進(jìn)行日志記錄; 返回業(yè)務(wù)請(qǐng)求處理結(jié)果給業(yè)務(wù)發(fā)起者,如果失敗,返回錯(cuò)誤消息。 6. Web Service Handler組件是處理基于Web Service的業(yè)務(wù)請(qǐng)求,與Message Handler組件功能類似,也包括消息解析、格式轉(zhuǎn)換,服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Web ServiceHandler組件處理Web Service請(qǐng)求的典型流程如下:首先對(duì)Web Service請(qǐng)求消息進(jìn)行解析,對(duì)解析后的業(yè)務(wù)請(qǐng)求進(jìn)行分析,之后通過Authentication與Authorization組件判斷該請(qǐng)求者的業(yè)務(wù)請(qǐng)求是否可以進(jìn)行后續(xù)處理; 通過Service Locating組件對(duì)該業(yè)務(wù)請(qǐng)求進(jìn)行服務(wù)定位與路由; 通過 Service Logging 組件對(duì)整個(gè)業(yè)務(wù)請(qǐng)求進(jìn)行日志記錄; 返回業(yè)務(wù)請(qǐng)求處理結(jié)果給業(yè)務(wù)發(fā)起者,如果失敗,返回錯(cuò)誤消息。 7. Event Handler組件實(shí)現(xiàn)對(duì)Pub/Sub的處理。8. Service Locating組件負(fù)責(zé)根據(jù)業(yè)務(wù)請(qǐng)求定位具體的服務(wù)提供者。Service Locating通過對(duì)服務(wù)目錄的查詢選擇適合的服務(wù)進(jìn)行后續(xù)的調(diào)用,該查詢工作可以通過實(shí)時(shí)的服務(wù)目錄查詢獲得結(jié)果。9. Service Logging組件負(fù)責(zé)記錄整個(gè)業(yè)務(wù)請(qǐng)求處理過程中的情況,該組件的實(shí)現(xiàn)可以通過文件或者數(shù)據(jù)庫(kù)的方式。10. Authentication組件負(fù)責(zé)對(duì)業(yè)務(wù)請(qǐng)求者進(jìn)行鑒權(quán),判斷該業(yè)務(wù)請(qǐng)求者是否可以訪問平臺(tái)服務(wù),該鑒權(quán)的工作在企業(yè)服務(wù)總線的外部進(jìn)行,Authentication組件只是調(diào)用外部功能完成。11. Authorization組件判斷業(yè)務(wù)請(qǐng)求者是否具備訪問某特定服務(wù)的權(quán)限,該驗(yàn)證權(quán)限的工作在企業(yè)服務(wù)總線的外部進(jìn)行,Authorization 組件只是調(diào)用外部功能完成。以處理基于MQ消息輸入為例,ESB的組件交互圖如圖 3 所示:圖 3. ESB組件交互圖 ESB方案設(shè)計(jì)時(shí)的最佳實(shí)踐根據(jù)我們以往項(xiàng)目設(shè)計(jì)和開發(fā)時(shí)的一些經(jīng)驗(yàn),我們建議進(jìn)行ESB的方案設(shè)計(jì)時(shí)要遵循下述最佳實(shí)踐:確定標(biāo)準(zhǔn)的使用:使用與否、使用到什么程度; 確定在ESB上實(shí)現(xiàn)的業(yè)務(wù)邏輯:ESB是一個(gè)服務(wù)路由和轉(zhuǎn)換中心,而不是一個(gè)應(yīng)用服務(wù)器,因此它并不能取代應(yīng)有服務(wù)器。復(fù)雜的消息解析和轉(zhuǎn)換相比簡(jiǎn)單的路由操作所需消耗的成本要高的多,因此在ESB上應(yīng)該主要考慮路由、格式轉(zhuǎn)換、服務(wù)調(diào)用等問題,而對(duì)于數(shù)據(jù)本身的處理應(yīng)該交給相應(yīng)的應(yīng)用來完成; 確定消息格式:從標(biāo)準(zhǔn)化的角度而言,XML當(dāng)然是首選,但是從解析 / 處理性能、行業(yè)標(biāo)準(zhǔn)以及對(duì)現(xiàn)有應(yīng)用的最大兼容性的角度而言,可能會(huì)采用某些特定格式,例如EDI、SWITF、平文本或者自定義格式等; 區(qū)別消息頭和消息體:把數(shù)據(jù)的Meta-data,例如:安全相關(guān)的信息、日志的等級(jí)、請(qǐng)求端的標(biāo)識(shí)等放在消息頭中,而不要放在消息體中。這樣可以很容易地改變其內(nèi)容及其對(duì)其的處理邏輯。在ESB中只處理消息頭,避免對(duì)消息體的解析; 設(shè)計(jì)時(shí)參考ESB相關(guān)的成熟Patterns; 使用服務(wù)注冊(cè)庫(kù):如需要服務(wù)Endpoint的查找:推薦從服務(wù)注冊(cè)中心進(jìn)行查找,這樣的好處在于:服務(wù)提供者可以容易地發(fā)布新的服務(wù),服務(wù)提供者和ESB之間的耦合度可以更低,通過關(guān)于服務(wù)本身的Metadata來進(jìn)行服務(wù)的查找和路由; 注重性能和高可用性的考慮; 在必須的情況下考慮交易完整性; 適配器的采用:應(yīng)用系統(tǒng)通過適配器實(shí)現(xiàn)與 ESB 的雙向交互,適配器主要分為技術(shù)適配器、應(yīng)用適配器兩種,適配器的物理部署可以與EIS部署在一起、或者與ESB部署在一起,也可以單獨(dú)部署,在適配器設(shè)計(jì)時(shí)要考慮通信協(xié)議和消息格式兩個(gè)方面;多 ESB 的設(shè)計(jì):ESB 也是一個(gè)邏輯的組件,在一個(gè)企業(yè)里可能需要多個(gè)ESB,例如:企業(yè)內(nèi)部ESB連接企業(yè)內(nèi)部各個(gè)系統(tǒng),外部ESB實(shí)現(xiàn)企業(yè)與合作伙伴等的外部連接;再如:企業(yè)內(nèi)部可能存在若干個(gè)部門級(jí)ESB和一個(gè)全企業(yè)ESB; 確定服務(wù)版本控制策略; 確定端到端的QoS準(zhǔn)則; 注重安全性; 確定IT部門ESB平臺(tái)的負(fù)責(zé)主體,長(zhǎng)期的投入。 ESB的安全性考慮對(duì)于ESB的安全性考慮,主要有兩種方式,第一種方式是通過ESB內(nèi)部的Mediation節(jié)點(diǎn)來進(jìn)行服務(wù)請(qǐng)求者的認(rèn)證 / 授權(quán);另一種是調(diào)用一個(gè)外部服務(wù)進(jìn)行服務(wù)請(qǐng)求者的認(rèn)證 / 授權(quán),如圖4所示,圖中給出了這兩種方式的示意圖,具體實(shí)施時(shí)可以進(jìn)行選擇。圖 4. ESB的兩種安全實(shí)現(xiàn)方式 運(yùn)行在ESB平臺(tái)上的服務(wù)的管理和監(jiān)控當(dāng)一個(gè)企業(yè)開始它的SOA之旅時(shí),開始階段通常會(huì)選取一個(gè)具體的項(xiàng)目進(jìn)行 SOA 的嘗試,然后便會(huì)逐步走向全企業(yè)采納,這時(shí),大多數(shù)企業(yè)都會(huì)面臨一個(gè)問題,那就是服務(wù)越來越多,對(duì)這些服務(wù)目錄的管理出現(xiàn)了很多問題,例如:所有與服務(wù)相關(guān)的信息是如何被管理的,包括存儲(chǔ)、管理、維護(hù)、存取等?服務(wù)請(qǐng)求者如何決定使用哪個(gè)服務(wù)?服務(wù)請(qǐng)求者如何定位服務(wù)的 Endpoint?當(dāng)服務(wù)信息發(fā)生改變時(shí)如何得到通知?因此我們建議用戶在盡可能早的情況下考慮服務(wù)注冊(cè)中心的建設(shè),所謂服務(wù)注冊(cè)中心是一個(gè)企業(yè)范圍內(nèi)的服務(wù)信息的存儲(chǔ)庫(kù),該存儲(chǔ)庫(kù)存儲(chǔ)了企業(yè)中注冊(cè)的服務(wù)和服務(wù)相關(guān)的信息,它的主要功能包括:采用集中的方式來管理服務(wù)相關(guān)的信息,為服務(wù)元數(shù)據(jù)同時(shí)提供“注冊(cè)中心”功能,允許用戶存儲(chǔ)、管理和查詢包含服務(wù)描述的服務(wù)元數(shù)據(jù)構(gòu)件; 提供服務(wù)的治理功能,實(shí)現(xiàn)整個(gè)服務(wù)生命周期的管理; 提供服務(wù)間依賴、包容關(guān)系的管理; 提供分類和版本控制等功能; 提供服務(wù)發(fā)現(xiàn)和通知等能力等。 除了服務(wù)注冊(cè)中心的考慮之外,我們還要考慮對(duì)服務(wù)的管理。服務(wù)不僅具有特定的功能,還應(yīng)該滿足一些諸如性能、可用性、安全性等QoS指標(biāo)。服務(wù)響應(yīng)的快慢、什么時(shí)間可用、可以被誰調(diào)用、在某個(gè)時(shí)間段里能被調(diào)用多少次、哪些事件要記錄日志,這些都是服務(wù)管理要考慮的問題。通過服務(wù)注冊(cè)中心和服務(wù)監(jiān)控平臺(tái)的有機(jī)配合,我們可以根據(jù)服務(wù)的響應(yīng)時(shí)間、服務(wù)可用與否等策

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論