專利名稱：：網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及網(wǎng)絡(luò)管理
技術(shù)領(lǐng)域：
，特別是指一種在網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法。
背景技術(shù)：
：在目前的基于公共對象請求代理體系(CORBA)總線技術(shù)的網(wǎng)管解決方案中，大多數(shù)網(wǎng)管對于網(wǎng)管操作日志以及安全的管理還是采用的是在應(yīng)用代碼中添加日志記錄或權(quán)限校驗(yàn)處理代碼的方式。如創(chuàng)建一個(gè)網(wǎng)元，網(wǎng)管系統(tǒng)為了記錄這條操作日志，往往需要在創(chuàng)建網(wǎng)元的應(yīng)用層代碼中增加相應(yīng)的日志處理代碼；類似的為了判斷當(dāng)前操作用戶是否擁有創(chuàng)建網(wǎng)元的操作權(quán)限，則還需要在應(yīng)用代碼中添加操作權(quán)限校驗(yàn)的代碼。又如設(shè)置設(shè)備的告警屏蔽開關(guān)，網(wǎng)管系統(tǒng)在接收到用戶的“屏蔽指定設(shè)備的告警”的請求，并且在請求下發(fā)給真實(shí)的物理設(shè)備之前，系統(tǒng)必須先對用戶的操作權(quán)限進(jìn)行校驗(yàn)，確認(rèn)用戶具備設(shè)置告警屏蔽開關(guān)的功能以后，會記錄相應(yīng)的請求信息，然后才會將請求下發(fā)給網(wǎng)元設(shè)備，并同步等待設(shè)備的響應(yīng)消息，收到設(shè)備返回的響應(yīng)或出錯(cuò)消息后，系統(tǒng)需要再次記錄操作的結(jié)果，最后才會將操作結(jié)果返回給用戶。為了更好的說明問題，下面以傳輸網(wǎng)絡(luò)管理系統(tǒng)中的“創(chuàng)建網(wǎng)元”操作為例對現(xiàn)有技術(shù)方案進(jìn)行說明。當(dāng)網(wǎng)管用戶下發(fā)創(chuàng)建網(wǎng)元的操作請求之后，網(wǎng)管系統(tǒng)主要需要完成以下三項(xiàng)任務(wù)1、校驗(yàn)當(dāng)前操作用戶是否有創(chuàng)建網(wǎng)元的操作權(quán)限；2、如果權(quán)限校驗(yàn)通過，則開始網(wǎng)元?jiǎng)?chuàng)建的業(yè)務(wù)處理流程；3、記錄操作日志，包括需要記錄請求參數(shù)，如網(wǎng)元標(biāo)識(ID)、網(wǎng)元類型等，操作成功還是失敗等詳細(xì)信息。具體流程參見圖1所示，包括以下步驟步驟101～102，網(wǎng)管用戶發(fā)出的創(chuàng)建網(wǎng)元的操作請求分發(fā)至網(wǎng)管系統(tǒng)后；網(wǎng)管系統(tǒng)進(jìn)行操作權(quán)限校驗(yàn)，判斷權(quán)限校驗(yàn)是否通過，若是，則進(jìn)入步驟103，否則，進(jìn)入步驟104；步驟103，網(wǎng)管系統(tǒng)根據(jù)該創(chuàng)建網(wǎng)元的請求進(jìn)行網(wǎng)元?jiǎng)?chuàng)建的業(yè)務(wù)處理流程，完成后進(jìn)入步驟104；步驟104，記錄當(dāng)前的操作日志。目前大多數(shù)網(wǎng)管系統(tǒng)對于這三項(xiàng)任務(wù)的處理還是集中在應(yīng)用層代碼中完成，即在處理請求前插入處理用戶操作權(quán)限校驗(yàn)的代碼，根據(jù)當(dāng)前發(fā)送請求的用戶ID、當(dāng)前請求的命令字，調(diào)用安全管理的公共函數(shù)或?qū)ο蠓椒▉砼袛喈?dāng)前用戶是否被允許執(zhí)行創(chuàng)建網(wǎng)元的請求，如果權(quán)限校驗(yàn)失敗，則直接返回錯(cuò)誤碼；如果權(quán)限校驗(yàn)通過，則請求被轉(zhuǎn)入真正的業(yè)務(wù)邏輯處理單元中進(jìn)行處理；請求處理完成之后，請求響應(yīng)消息返回之前，需要插入代碼以記錄操作日志信息，記錄時(shí)需要判斷操作是成功還是失敗，同時(shí)需要對請求參數(shù)進(jìn)行處理，這里可能需要對復(fù)雜的參數(shù)進(jìn)行流化處理，使其變成可輸出并可讀的字符串，然后調(diào)用日志管理的公共函數(shù)或?qū)ο蠓椒ㄍ瓿扇罩居泿觳僮鳌，F(xiàn)有的技術(shù)存在以下幾個(gè)明顯的缺點(diǎn)(1)軟件層次模糊?，F(xiàn)有技術(shù)方案需要在應(yīng)用層代碼中添加代碼以處理日志以及安全校驗(yàn)的問題，因此無法將應(yīng)用層業(yè)務(wù)處理模塊和日志安全等模塊隔離開，無法保證業(yè)務(wù)邏輯的獨(dú)立性。(2)維護(hù)困難。因?yàn)樾枰趹?yīng)用層代碼中每個(gè)請求的處理代碼中插入日志以及安全的處理代碼，非常繁瑣，而且這些處理代碼通常會調(diào)用一些日志或安全處理的公共函數(shù)或方法，一旦這些公共函數(shù)參數(shù)發(fā)生變更，無疑將帶來大量代碼維護(hù)上的開銷。(3)處理困難。每個(gè)操作的參數(shù)都是千差萬別，這就意味著為了記錄這些操作的詳細(xì)信息，需要在應(yīng)用層增加代碼將操作的參數(shù)解析出來并且按照一定的規(guī)則字符串化，然后才能調(diào)用公共函數(shù)或?qū)ο蠓椒ㄟM(jìn)行記錄，這直接增加了處理上的開銷，而且一旦這些請求參數(shù)變化或是記錄的格式發(fā)生變化，相關(guān)代碼也需要隨之修改。(4)可擴(kuò)展性差。基于現(xiàn)有技術(shù)方案，目前還僅僅是解決了日志記錄和權(quán)限校驗(yàn)的問題，而如果需要在此基礎(chǔ)上擴(kuò)展功能，如計(jì)算每個(gè)請求的處理時(shí)間，則又需要在各個(gè)請求處理代碼中重新增添新代碼以支持新的功能需求，功能可擴(kuò)展性非常差。
發(fā)明內(nèi)容有鑒于此，本發(fā)明的目的在于提供一種網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法，使得上述處理更加簡單，便于維護(hù)并具有可擴(kuò)展性?；谏鲜瞿康谋景l(fā)明提供的一種網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法，基于公共對象請求代理體系CORBA平臺，在對象請求代理ORB模塊初始化后，應(yīng)用模塊向ORB模塊中注冊一個(gè)消息截獲器；并進(jìn)一步包括A.對象請求代理模塊接收到消息后，調(diào)用注冊的消息截獲器截獲所述接收的消息；B.根據(jù)預(yù)先設(shè)置處理所述消息；C.將所述消息調(diào)度給該消息對應(yīng)的可移植對象適配器POA中的具體對象進(jìn)行處理。該方法在請求代理和請求對象之間插入通用的消息截獲器，步驟B所述處理包括但不限于日志記錄、或集中鑒權(quán)、或消息修改的操作。該方法對消息處理采用的方法包括動態(tài)消息解析方法，或POA與用戶特征信息的關(guān)聯(lián)方法，或消息上下文處理方法。該方法步驟B進(jìn)一步包括B11.使用動態(tài)Any技術(shù)對該消息中包含的Any類型的數(shù)據(jù)進(jìn)行解析，并轉(zhuǎn)換成用戶可讀的字符串信息；B12.將得到的字符串信息記錄到日志文件中。該方法所述消息為請求消息，在Servant對象對請求消息處理完畢后，響應(yīng)消息發(fā)送給客戶側(cè)之前進(jìn)一步包括POA調(diào)用消息截獲器截獲該請求消息的響應(yīng)消息，對響應(yīng)消息進(jìn)行修改或日志記錄。該方法所述消息為請求消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求ID、操作名稱、請求參數(shù)和操作返回值；所述消息為響應(yīng)消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求ID、操作名稱、請求參數(shù)、操作返回值和響應(yīng)數(shù)據(jù)；所述消息為異常消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求ID、操作名稱、請求參數(shù)、操作返回值和操作異常信息。該方法步驟A所述截獲的消息為請求消息，步驟B進(jìn)一步包括B21.獲取請求所屬的POA名字；B22.根據(jù)獲取的請求消息所屬POA的名字驗(yàn)證該客戶側(cè)的用戶是否擁有所請求的該項(xiàng)操作的權(quán)限，如果是，該請求消息所屬的POA將該請求消息調(diào)度給對應(yīng)的Servant類進(jìn)行處理；否則，拋出非法調(diào)用異常消息。該方法進(jìn)一步包括預(yù)先為每個(gè)連接到該系統(tǒng)的用戶新建一個(gè)用于處理該用戶請求的POA；其中，所述POA名字與用戶的名字相同。該方法步驟A所述截獲的消息為請求消息，步驟B進(jìn)一步包括B31.初始化一個(gè)服務(wù)上下文；B32.獲取系統(tǒng)當(dāng)前時(shí)間；B33.將系統(tǒng)當(dāng)前時(shí)間添加到所述服務(wù)上下文的參數(shù)當(dāng)中去；B34.將該服務(wù)上下文添加到請求消息中去；B35.ORB模塊的POA將所述請求消息調(diào)度給所屬的Servant對象，Servant對象完成對該請求消息的處理；B36.ORB模塊截獲該請求消息處理完成后的請求響應(yīng)消息；B37.獲取請求響應(yīng)消息中的指定的服務(wù)上下文對象；B38.獲取系統(tǒng)當(dāng)前時(shí)間；B39.根據(jù)當(dāng)前系統(tǒng)時(shí)間和指定的服務(wù)上下文對象中包含的時(shí)間參數(shù)，計(jì)算請求從接收到處理完成所花費(fèi)的時(shí)間。該方法步驟B32和B38中所述獲取系統(tǒng)當(dāng)前時(shí)間的過程為通過調(diào)用操作系統(tǒng)本身提供的系統(tǒng)函數(shù)獲取系統(tǒng)當(dāng)前時(shí)間。該方法步驟B39所述計(jì)算過程包括將當(dāng)前系統(tǒng)時(shí)間減去服務(wù)上下文對象中包含的時(shí)間參數(shù)所指示的時(shí)間得到請求從接收到處理完成所花費(fèi)的時(shí)間。從上述方案可以看出，本發(fā)明直接采用POA樹形結(jié)構(gòu)來識別請求的發(fā)起對象，即是誰發(fā)起了該操作請求，不需要請求參數(shù)中附帶請求用戶ID的信息，同時(shí)如果權(quán)限校驗(yàn)失敗，可以直接將消息返回，而不需要將消息繼續(xù)轉(zhuǎn)發(fā)給應(yīng)用層處理，從而節(jié)省系統(tǒng)開銷。同時(shí)借助CORBA的消息截獲機(jī)制可以直接獲取請求名稱、請求參數(shù)信息以及請求參數(shù)的類型，即是輸入?yún)?shù)、輸出參數(shù)還是輸入輸出雙向參數(shù)，而不再需要操作參數(shù)中附帶請求命令字信息來區(qū)分不同的請求。直接利用CORBA的消息截獲機(jī)制激活請求或響應(yīng)消息，然后結(jié)合CORBA的動態(tài)Any技術(shù)對消息中包含的請求參數(shù)信息、響應(yīng)參數(shù)信息、返回值或是異常信息進(jìn)行解析，并按照自定義的記錄格式存庫，應(yīng)用層完全不需要關(guān)注操作日志記錄的事情，只需要關(guān)注于業(yè)務(wù)邏輯的處理上，從而將系統(tǒng)框架和應(yīng)用層分離開。利用CORBA消息截獲機(jī)制可以對激活的消息進(jìn)行修改，增加一些請求自定義上下文參數(shù)，就可以保證在不影響現(xiàn)有功能以及現(xiàn)有應(yīng)用層處理邏輯的基礎(chǔ)上擴(kuò)展功能。典型的如在請求中插入用戶記錄請求從接收到處理返回所花費(fèi)時(shí)間的上下文參數(shù)。圖1為現(xiàn)有傳輸網(wǎng)絡(luò)管理系統(tǒng)中的創(chuàng)建網(wǎng)元操作的流程示意圖；圖2為本發(fā)明實(shí)施例消息截獲器注冊過程的流程示意圖；圖3為本發(fā)明實(shí)施例日志處理過程的流程示意圖；圖4為本發(fā)明實(shí)施例安全校驗(yàn)處理過程的流程示意圖；圖5為本發(fā)明實(shí)施例擴(kuò)展應(yīng)用處理過程的流程示意圖。具體實(shí)施例方式事實(shí)上，對于基于CORBA總線技術(shù)的網(wǎng)管系統(tǒng)而言，CORBA技術(shù)本身提供了一種消息截獲機(jī)制(Intercept)，利用該機(jī)制可以截獲系統(tǒng)往來的請求以及響應(yīng)消息，基于所截獲的消息，完全可以以一種通用的方式來實(shí)現(xiàn)操作日志的記錄、操作權(quán)限的校驗(yàn)等處理，從而可以將日志記錄以及權(quán)限校驗(yàn)完全屏蔽在系統(tǒng)底層框架內(nèi)實(shí)現(xiàn)，應(yīng)用層可以不用理會而專注于業(yè)務(wù)邏輯的實(shí)現(xiàn)上。因此本發(fā)明方案的核心是基于CORBA體系平臺，在對象請求代理(ORB)模塊初始化后，應(yīng)用模塊向ORB模塊中注冊一個(gè)消息截獲器；并進(jìn)一步包括ORB模塊接收到消息后，調(diào)用注冊的消息截獲器截獲所述接收的消息；根據(jù)預(yù)先設(shè)置處理所述消息；再將所述消息調(diào)度給該消息對應(yīng)的可移植對象適配器(POA，PortableObjectAdapter)中的具體對象進(jìn)行處理。下面對本發(fā)明中所涉及到的現(xiàn)有CORBA體系中的功能模塊進(jìn)行說明。1、ORB截獲器機(jī)制功能模塊，主要包括ORB初始化、消息截獲器注冊/去注冊、服務(wù)上下文定義等功能。以下對該模塊在本發(fā)明中所涉及的幾個(gè)類進(jìn)行說明。1)ORB模塊(Module)，這里ORBModule實(shí)際上不是一個(gè)類，而是代表所有的ORBAPI，這里為了方便描述，將整個(gè)ORB模塊抽象的看作一個(gè)接口類，內(nèi)部的實(shí)際細(xì)節(jié)不在本發(fā)明涉及的范圍之內(nèi)，具體可參考OMGCORBA規(guī)范或相關(guān)ORB產(chǎn)品的技術(shù)手冊。2)ORB_Init類，代表網(wǎng)管系統(tǒng)底層框架層的一個(gè)功能類，主要完成對ORB平臺的初始化以及配置等相關(guān)的功能，與本發(fā)明相關(guān)的功能為Init，初始化底層ORB平臺相關(guān)的環(huán)境，如截獲器注冊、POA激活等。3)Server_Request_Interceptor類，表示CORBA消息截獲器，主要完成對請求消息、響應(yīng)消息以及異常信息的截獲。其中，包含有截獲請求消息receive_request、截獲響應(yīng)消息send_reply、截獲異常消息send_exception。4)PortableInterceptior::ORB_initInfo類，記錄和管理與ORB初始化相關(guān)的信息。含有注冊消息截獲器add_server_request_interceptor。5)Server_ORBInitializer類，表示ORB_core對象實(shí)例初始化的輔助類，主要處理ORB_core對象實(shí)例初始化前后的一些初始化相關(guān)的任務(wù)。包含有pre_init處理ORB_core對象實(shí)例初始化之前的任務(wù)；以及post_init，處理ORB_core對象實(shí)例初始化之后的任務(wù)。6)PortableInterceptor::ServerRequestInfo類，是表示請求信息的實(shí)體類。包括add_reply_serive_context，添加請求響應(yīng)服務(wù)上下文參數(shù)；get_reply_service_context，獲取請求響應(yīng)服務(wù)上下文參數(shù)；adapter_name，獲取請求所在POA的名字；sending_exception，獲取異常信息；request_id，獲取請求ID；arguments，獲取請求參數(shù)信息；operation，獲取請求名稱；reply_status，獲取請求響應(yīng)狀態(tài)；result，獲取請求結(jié)果。7)IOP::ServiceContext類，用于在請求中增加或獲取服務(wù)上下文參數(shù)信息，是一個(gè)結(jié)構(gòu)體。歸納起來ORB截獲器機(jī)制功能模塊在本發(fā)明中所涉及的類，參見表1所示表12、日志及安全管理功能模塊該模塊主要是由網(wǎng)管應(yīng)用層實(shí)現(xiàn)，主要功能包括對截獲器截取的消息，包括請求消息、響應(yīng)消息、異常消息等進(jìn)行解析，生成相應(yīng)的日志記錄；對截獲的請求先判斷其用戶操作權(quán)限，然后在決定是否將該請求調(diào)度到處理程序。以下對該模塊在本發(fā)明中所涉及的幾個(gè)類進(jìn)行說明。8)TALogMgr類，為日志管理類，完成日志管理相關(guān)操作。其中的主要方法包括TAWriteOperLog，記錄操作日志；GetOperLogRecord，從截獲的消息中獲取日志記錄項(xiàng)所需的信息；WriteOperLogRecord，日志記庫操作。9)TALogHelper類，為日志輔助類，完成日志管理的相關(guān)輔助功能。其中的主要方法包括ParseAnyData，使用CORBA的動態(tài)Any技術(shù)對消息中包含的數(shù)據(jù)信息進(jìn)行解析；ParseException解析異常消息中的數(shù)據(jù)信息。10)TASecurityMgr類，實(shí)現(xiàn)對操作權(quán)限的校驗(yàn)和管理功能。其中主要方法包括Verify，校驗(yàn)用戶是否具備某項(xiàng)操作的權(quán)限，即直接根據(jù)截獲的請求消息判斷用戶是否具備執(zhí)行該項(xiàng)操作的權(quán)限，權(quán)限校驗(yàn)通過，則將請求轉(zhuǎn)發(fā)給具體的請求處理模塊；否則丟棄該請求消息或直接返回失敗響應(yīng)消息。11)伺服(Servant)類，表示CORBA中的Servant類，即應(yīng)用層具體處理對象請求的類。其中主要包括OperationImpl，表示請求業(yè)務(wù)邏輯處理方法。歸納起來日志及安全管理功能模塊在本發(fā)明中所涉及的類，參見表2所示表2本方案處理實(shí)現(xiàn)流程主要包括消息截獲器注冊流程、日志處理流程、安全校驗(yàn)流程幾部分，下面分別進(jìn)行闡述。注冊消息截獲器主要先完成ORB初始化過程，然后再向ORB中注冊一個(gè)消息截獲器對象，這樣每次當(dāng)ORB從本端或遠(yuǎn)端接收到CORBA消息時(shí)，其中CORBA消息可能為請求消息、響應(yīng)消息、異常消息等，ORB都會自動回調(diào)該消息截獲器對象的相應(yīng)的消息處理方法，然后再通過日志處理流程或安全校驗(yàn)流程部分的方法完成消息到日志的轉(zhuǎn)化或操作權(quán)限的校驗(yàn)功能。參見圖2所示，具體包括以下步驟步驟201，ORB_Init類調(diào)用Server_ORBInitializer類的構(gòu)造函數(shù)實(shí)例化Server_ORBInitializer對象；步驟202，ORB_Init類調(diào)用register_orb_initializer方法向ORB中注冊Server_ORBInitializer對象；步驟203，ORB_Init調(diào)用ORB_init方法初始化ORB；步驟204，ORB初始化的過程中會依次調(diào)用Server_ORBInitializer的pre_init和post_init方法；步驟205，Server_ORBInitializer的post_init方法調(diào)用Server_Request_Interceptor的構(gòu)造函數(shù)實(shí)例化消息截獲器對象；步驟206，Server_ORBInitializer調(diào)用PortableInterceptor::ORB_initInfo的add_server_request_interceptor向ORB中注冊該消息截獲器對象。日志處理流程本流程主要由消息截獲器驅(qū)動，當(dāng)消息截獲器截獲到消息后，會回調(diào)日志管理模塊相應(yīng)的對象方法，來對該消息中包含的請求ID、操作名稱、請求參數(shù)、響應(yīng)數(shù)據(jù)(對響應(yīng)消息而言)、操作返回值、操作異常信息(對異常消息而言)等數(shù)據(jù)信息進(jìn)行解析，并轉(zhuǎn)換成用戶可讀的字符串信息，然后記錄到日志文件中。日志處理完成后，截獲器再將消息繼續(xù)調(diào)度到相應(yīng)的請求處理模塊進(jìn)行處理。對于響應(yīng)消息以及異常消息處理也是類似，在請求處理完響應(yīng)消息發(fā)送出去之前，消息截獲器先截獲消息，進(jìn)行日志處理后再發(fā)出去。具體的處理步驟包括步驟301，ORBModule在接收到客戶側(cè)發(fā)送來的請求消息后，會將請求消息調(diào)度給負(fù)責(zé)處理該客戶側(cè)請求的該請求所屬POA處理，而POA在將請求消息進(jìn)一步調(diào)度給被請求的Servant類對象之前，會先調(diào)用消息截獲器的receive_request方法。其中ORB內(nèi)部的具體實(shí)現(xiàn)細(xì)節(jié)為已有技術(shù)，這里不作細(xì)述。步驟302，消息截獲器的receive_request調(diào)用TALogMgr的TAWriteOperLog方法，以解析消息數(shù)據(jù)并記錄該請求日志信息。步驟303，TAWriteOperLog方法會進(jìn)一步調(diào)用GetOperLogRecord方法，以獲取日志記錄信息。步驟304，GetOperLogRecord方法進(jìn)一步調(diào)用TALogHelper的ParseAnyData方法，使用CORBA的動態(tài)Any技術(shù)對消息中包含的請求ID、操作名稱、請求參數(shù)、操作返回值等數(shù)據(jù)進(jìn)行解析，并轉(zhuǎn)換成用戶可讀的字符串信息。其中，本步驟中如果截獲的消息為響應(yīng)消息，則還將對響應(yīng)數(shù)據(jù)進(jìn)行解析；如果截獲的消息為異常消息，則還將對操作異常信息進(jìn)行解析。步驟305，TALogMgr調(diào)用內(nèi)部的WriteOperLogRecord將得到的字符串信息記錄到日志文件中。步驟306，日志處理完畢后，請求消息將被ORBModule中的POA調(diào)度給被請求的Servant類對象，由Servant類對象完成對請求的處理。步驟307，請求處理完成后，在響應(yīng)消息發(fā)送給客戶側(cè)之前，ORBModule會調(diào)用截獲器的send_reply方法截獲響應(yīng)消息，使應(yīng)用有機(jī)會在響應(yīng)消息發(fā)送前對消息做修改或日志記錄。在對響應(yīng)消息以及異常消息的處理過程中也可采用同樣方法進(jìn)行日志記錄，具體日志記錄的過程與請求消息的處理流程基本一致，這里不再贅述。安全校驗(yàn)處理流程和日志處理流程完全類似，即在ORB接收到請求消息后，先回調(diào)消息截獲器對象的方法，將消息轉(zhuǎn)給截獲器先進(jìn)行操作權(quán)限校驗(yàn)的處理，處理完后再根據(jù)鑒權(quán)的結(jié)果決定是否繼續(xù)轉(zhuǎn)發(fā)消息或是直接返回錯(cuò)誤。具體的處理順序圖和步驟如下步驟401，ORBModule在接收到客戶側(cè)發(fā)送來的請求消息后，ORBModule調(diào)用Server_Request_Interceptor的receive_request方法，使得應(yīng)用可以有機(jī)會對截獲的請求消息進(jìn)行處理。步驟402，Server_Request_Interceptor調(diào)用PortableInterceptor::ServerRequestInfo的adapter_name方法獲取請求對象所屬POA的名字。這里需要說明的是，這里的POA的名字和用戶的名字是一樣的，也就是說這里假設(shè)系統(tǒng)為每一個(gè)連接到該系統(tǒng)的用戶新建一個(gè)子POA，該用戶發(fā)送的所有請求都調(diào)度給該P(yáng)OA進(jìn)行處理。如果系統(tǒng)不是采用這種POA管理機(jī)制，則需要在請求參數(shù)中傳遞相應(yīng)的用戶ID，有兩種方案供選擇一是直接在請求參數(shù)中增加一個(gè)用戶ID的參數(shù)；二是由客戶側(cè)在請求發(fā)送之前先將請求截獲，并在請求中增加一個(gè)請求服務(wù)上下文，該上下文中放入用戶ID參數(shù)。具體實(shí)現(xiàn)方法和“擴(kuò)展應(yīng)用”部分描述的步驟類似，差別在于該消息由客戶側(cè)發(fā)出之前截獲。步驟403，Server_Request_Interceptor調(diào)用TASecurityMgr的verify方法根據(jù)獲取的請求所屬POA的名字驗(yàn)證用戶是否擁有該項(xiàng)操作的權(quán)限，如果是，進(jìn)入步驟406；否則，進(jìn)入步驟404。步驟404，如果用戶不具備該項(xiàng)權(quán)限，則Server_Request_Interceptor拋出相應(yīng)的非法調(diào)用異常消息，這樣該請求將不會被繼續(xù)調(diào)度給被請求的Servant類對象做處理，而是直接返回給請求用戶。步驟405，由于操作返回異常，因此ORBModule會調(diào)用截獲器的send_exception方法以便應(yīng)用可以截獲相應(yīng)的異常消息并做處理。步驟406，如果用戶權(quán)限校驗(yàn)通過，則ORBModule中相應(yīng)的POA會將該請求調(diào)度給被請求的Servant類對象進(jìn)行處理。擴(kuò)展應(yīng)用處理流程主要描述CORBA消息截獲機(jī)制的一個(gè)簡單的擴(kuò)展應(yīng)用，即實(shí)現(xiàn)通過修改請求消息，來計(jì)算請求處理所花費(fèi)的時(shí)間的功能。主要的原理是在消息截獲器截取到請求消息后，先往請求消息中插入一個(gè)請求上下文對象，記錄請求消息接收到的時(shí)間，然后等請求處理完成，應(yīng)用層返回響應(yīng)消息的時(shí)候，消息截獲器再次截獲響應(yīng)消息，將之前插入消息中的請求上下文取出來，和當(dāng)前響應(yīng)消息的截獲時(shí)間進(jìn)行對比，即可計(jì)算出該操作一共花費(fèi)了多少處理時(shí)間。具體的處理順序圖和步驟如下步驟501，ORBModule在接收到客戶側(cè)發(fā)送來的請求消息后，ORBModule調(diào)用Server_Request_Interceptor的receive_request方法，使得應(yīng)用可以有機(jī)會對截獲的請求消息進(jìn)行處理。步驟502，Server_Request_Interceptor初始化一個(gè)服務(wù)上下文ServiceContext。步驟503，Server_Request_Interceptor通過調(diào)用操作系統(tǒng)本身提供的系統(tǒng)函數(shù)獲取系統(tǒng)當(dāng)前時(shí)間currenttime。其中，所述的系統(tǒng)函數(shù)是操作系統(tǒng)本身提供的功能，如GetSystemTime()等系統(tǒng)調(diào)用。步驟504，Server_Request_Interceptor將系統(tǒng)當(dāng)前時(shí)間添加到服務(wù)上下文ServiceContext參數(shù)當(dāng)中去。步驟505，Server_Request_Interceptor調(diào)用PortableInterceptor::RequestInfo的add_reply_service_context方法將該服務(wù)上下文ServiceContext添加到請求消息中去。步驟506，ORBModule的POA對象將請求調(diào)度給被請求的Servant類對象，由Servant類對象完成對請求的處理。步驟507，請求處理完成后，ORBModule調(diào)用截獲器的send_reply方法以截獲請求響應(yīng)消息。步驟508，Server_Request_Interceptor調(diào)用PortableInterceptor::RequestInfo的get_reply_service_context方法獲取指定的服務(wù)上下文對象ServiceContext。步驟509，Server_Request_Interceptor通過調(diào)用系統(tǒng)函數(shù)獲取系統(tǒng)當(dāng)前時(shí)間currenttime。步驟510，根據(jù)當(dāng)前系統(tǒng)時(shí)間和ServiceContext中包含的時(shí)間參數(shù)，計(jì)算請求從接收到處理完成所花費(fèi)的時(shí)間，即用當(dāng)前系統(tǒng)時(shí)間減去ServiceContext中包含的時(shí)間參數(shù)所指示的時(shí)間得到請求從接收到處理完成所花費(fèi)的時(shí)間。本發(fā)明技術(shù)方案降低了系統(tǒng)模塊之間的耦合關(guān)系，同時(shí)采用通用的處理模式有效的降低了系統(tǒng)的維護(hù)工作量和維護(hù)復(fù)雜度，并且使得系統(tǒng)具備良好的可擴(kuò)展性。以上所述僅為本發(fā)明的較佳實(shí)施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。權(quán)利要求1.一種網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法，其特征在于，基于公共對象請求代理體系平臺，在對象請求代理模塊初始化后，應(yīng)用模塊向?qū)ο笳埱蟠砟K中注冊一個(gè)消息截獲器；并進(jìn)一步包括A.對象請求代理模塊接收到消息后，調(diào)用注冊的消息截獲器截獲所述接收的消息；B.根據(jù)預(yù)先設(shè)置處理所述消息；C.將所述消息調(diào)度給該消息對應(yīng)的可移植對象適配器中的具體對象進(jìn)行處理。2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B所述處理包括但不限于日志記錄、或集中鑒權(quán)、或消息修改的操作。3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，對消息處理采用的方法包括動態(tài)消息解析方法，或可移植對象適配器與用戶特征信息的關(guān)聯(lián)方法，或消息上下文處理方法。4.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B進(jìn)一步包括B11.使用動態(tài)Any技術(shù)對該消息中包含的Any類型的數(shù)據(jù)進(jìn)行解析，并轉(zhuǎn)換成用戶可讀的字符串信息；B12.將得到的字符串信息記錄到日志文件中。5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述消息為請求消息，在伺服對象對請求消息處理完畢后，響應(yīng)消息發(fā)送給客戶側(cè)之前進(jìn)一步包括可移植對象適配器調(diào)用消息截獲器截獲該請求消息的響應(yīng)消息，對響應(yīng)消息進(jìn)行修改或日志記錄。6.根據(jù)權(quán)利要求4或5所述的方法，其特征在于，所述消息為請求消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求標(biāo)識、操作名稱、請求參數(shù)和操作返回值；所述消息為響應(yīng)消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求標(biāo)識、操作名稱、請求參數(shù)、操作返回值和響應(yīng)數(shù)據(jù)；所述消息為異常消息，所述消息中包含的Any類型的數(shù)據(jù)包括請求標(biāo)識、操作名稱、請求參數(shù)、操作返回值和操作異常信息。7.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A所述截獲的消息為請求消息，步驟B進(jìn)一步包括B21.獲取請求所屬的可移植對象適配器名字；B22.根據(jù)獲取的請求消息所屬可移植對象適配器的名字驗(yàn)證該客戶側(cè)的用戶是否擁有所請求的該項(xiàng)操作的權(quán)限，如果是，該請求消息所屬的可移植對象適配器將該請求消息調(diào)度給對應(yīng)的伺服類進(jìn)行處理；否則，拋出非法調(diào)用異常消息。8.根據(jù)權(quán)利要求7所述的方法，其特征在于，該方法進(jìn)一步包括預(yù)先為每個(gè)連接到該系統(tǒng)的用戶新建一個(gè)用于處理該用戶請求的可移植對象適配器；其中，所述可移植對象適配器名字與用戶的名字相同。9.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A所述截獲的消息為請求消息，步驟B進(jìn)一步包括B31.初始化一個(gè)服務(wù)上下文；B32.獲取系統(tǒng)當(dāng)前時(shí)間；B33.將系統(tǒng)當(dāng)前時(shí)間添加到所述服務(wù)上下文的參數(shù)當(dāng)中去；B34.將該服務(wù)上下文添加到請求消息中去；B35.對象請求代理模塊的可移植對象適配器將所述請求消息調(diào)度給所屬的伺服對象，伺服對象完成對該請求消息的處理；B36.對象請求代理模塊截獲該請求消息處理完成后的請求響應(yīng)消息；B37.獲取請求響應(yīng)消息中的指定的服務(wù)上下文對象；B38.獲取系統(tǒng)當(dāng)前時(shí)間；B39.根據(jù)當(dāng)前系統(tǒng)時(shí)間和指定的服務(wù)上下文對象中包含的時(shí)間參數(shù)，計(jì)算請求從接收到處理完成所花費(fèi)的時(shí)間。10.根據(jù)權(quán)利要求9所述的方法，其特征在于，步驟B32和B38中所述獲取系統(tǒng)當(dāng)前時(shí)間的過程為通過調(diào)用操作系統(tǒng)本身提供的系統(tǒng)函數(shù)獲取系統(tǒng)當(dāng)前時(shí)間。11.根據(jù)權(quán)利要求9所述的方法，其特征在于，步驟B39所述計(jì)算過程包括將當(dāng)前系統(tǒng)時(shí)間減去服務(wù)上下文對象中包含的時(shí)間參數(shù)所指示的時(shí)間得到請求從接收到處理完成所花費(fèi)的時(shí)間。全文摘要本發(fā)明公開了在一種網(wǎng)絡(luò)管理中通用的消息偵聽以及處理方法，基于公共對象請求代理體系CORBA平臺，在對象請求代理ORB模塊初始化后，應(yīng)用模塊向ORB模塊中注冊一個(gè)消息截獲器；并包括對象請求代理模塊接收到消息后，調(diào)用注冊的消息截獲器截獲所述接收的消息；根據(jù)預(yù)先設(shè)置處理所述消息；將所述消息調(diào)度給該消息對應(yīng)的可移植對象適配器POA中的具體對象進(jìn)行處理。通過本發(fā)明方案使得上述處理過程更加簡單，便于維護(hù)并具有可擴(kuò)展性。文檔編號H04L12/58GK1852142SQ200510097120公開日2006年10月25日申請日期2005年12月30日優(yōu)先權(quán)日2005年12月30日發(fā)明者劉少軍申請人:華為技術(shù)有限公司