專利名稱：服務處理方法和裝置的制作方法
技術領域：
本發(fā)明實施例涉及通信技術，尤其涉及一種服務處理方法和裝置。
背景技術：
公共對象請求代理結構(Common Object Request Broker Architecture ；以下簡 稱C0RBA)作為對象間通信的一種工業(yè)標準，使用面向對象的設計結構，允許軟件對象在 不同的操作系統(tǒng)平臺和應用程序中重復使用。CORBA應用是指符合CORBA規(guī)范的由任意開 發(fā)語言開發(fā)的軟件應用程序，通常由提供CORBA對象接口服務的服務端程序和調用CORBA 對象接口服務的客戶端程序構成。典型的CORBA應用包括名字服務(Naming Service)和 通知服務(NotifyService)，名字服務為分散的CORBA應用提供對象注冊點，服務端先將對 象服務信息注冊到名字服務上，客戶端從名字服務上獲取到對象服務信息后，直接調用對 象接口服務，而無需再通過名字服務進行中轉；通知服務則用來傳遞服務端到客戶端的通 知事件，服務端先在通知服務上創(chuàng)建事件通道，并向通知服務上報事件，由通知服務向客戶 端轉發(fā)事件。在實現(xiàn)本發(fā)明過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術中至少存在如下問題C0RBA應用需 要在名字服務和通知服務啟動后才能啟動，這樣為系統(tǒng)部署帶來限制和不便，造成不必要 的維護和咨詢成本。當名字服務在運行過程中異常重啟后，由于CORBA應用未能獲知該情 況，服務端未向名字服務重新注冊，則客戶端向服務端獲取對象服務時將失敗。當通知服務 異常重啟后，由于服務端未向通知服務重新創(chuàng)建事件通道，則服務端在向原來的事件通道 上發(fā)送事件時則導致發(fā)送失敗，客戶端也無法收到通知服務轉發(fā)的事件。由此可見，在現(xiàn)有 技術中，當名字服務、通知服務出現(xiàn)異常重啟后，需要手工依次重啟名字服務或通知服務、 服務端應用、客戶端應用才能使得系統(tǒng)恢復正常，否則會造成定位失敗和事件丟失，需要專 業(yè)支持人員進行現(xiàn)場定位和恢復，導致成本提高，同時如果長時間脫管造成告警事件丟失， 則會嚴重影響網(wǎng)絡的正常運營。

發(fā)明內容
本發(fā)明實施例在于提供一種服務處理方法和裝置，解決應用與服務之間的啟動依 賴和注冊依賴問題，解除應用與名字服務或通知服務之間啟動順序的限制，實現(xiàn)在名字服 務或通知服務出現(xiàn)異常時保證網(wǎng)絡的正常運營。為了實現(xiàn)上述目的，本發(fā)明實施例提供了一種服務處理方法，包括公共對象請求代理結構服務端啟動后，該服務端啟動名字服務管理任務；在名字服務停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述名字服務管理任務將 服務端的對象服務信息注冊到所述名字服務上。本發(fā)明實施例還提供了另一種服務處理方法，包括公共對象請求代理結構服務端啟動后，該服務端啟動通知服務管理任務；在通知服務停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述通知服務管理任務創(chuàng)建服務端與通知服務的事件通道。本發(fā)明實施例提供了一種公共對象請求代理結構服務端裝置，包括第一任務啟動模塊，用于在服務端啟動后，啟動名字服務管理任務；第一服務管理模塊，用于在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通 過所述名字服務管理任務將服務端的對象服務信息注冊到名字服務上。本發(fā)明實施例還提供了另一種公共對象請求代理結構服務端裝置，包括第二任務啟動模塊，用于在服務端啟動后，啟動通知服務管理任務；第二服務管理模塊，用于在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通 過所述通知服務管理任務創(chuàng)建服務端與通知服務的事件通道。本發(fā)明實施例提供的一種服務處理方法和裝置，通過設置并啟動服務管理任務， 通過服務管理任務完成在名字服務異常時將服務端的對象服務信息注冊到名字服務上，或 在通知服務異常時創(chuàng)建服務端與通知服務之間的事件通道，解決了應用與名字服務或通知 服務之間的啟動依賴和注冊依賴問題，解除了應用與名字服務或通知服務之間啟動順序的 限制，實現(xiàn)了在名字服務或通知服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，同時大大降低了維 護和咨詢成本，減少了定位失敗和事件丟失。


圖1為本發(fā)明服務處理方法一實施例的流程圖2為本發(fā)明服務處理方法一實施例的信令圖3為本發(fā)明服務處理方法另一實施例的信令圖4為本發(fā)明服務處理方法另一實施例的流程圖5為本發(fā)明服務處理方法又一實施例的信令圖6為本發(fā)明服務處理方法再一實施例的信令圖7為本發(fā)明服務處理方法還一實施例的信令圖8為本發(fā)明服務處理方法又另一實施例的信令圖9為本發(fā)明服務處理方法又再一實施例的信令圖10為本發(fā)明服務處理方法又還一實施例的信令圖11為本發(fā)明公共對象請求代理結構服務端裝置一實施例的結構圖12為本發(fā)明公共對象請求代理結構服務端裝置另一實施例的結構圖
具體實施例方式下面通過附圖和實施例，對本發(fā)明的技術方案做進一步的詳細描述。在CORBA應用提供的眾多服務中，名字服務和通知服務為最典型的兩種服務。其 中，CORBA應用需要通過名字服務為CORBA對象指定一個唯一的名字上下文，使用CORBA對 象的名字上下文從名字服務中獲取相應的CORBA對象，通過建立層次化的名字樹，將名字 上下文和相應的CORBA對象綁定在一起。通知服務則用來完成從服務端到客戶端的通知 事件的傳遞，通過CORBA應用的服務端在通知服務上創(chuàng)建事件通道，CORBA應用的客戶端則 由事件通道來接收服務端發(fā)送的事件。CORBA應用的服務端和客戶端依賴于名字服務和通 知服務，服務端應用、客戶端應用的啟動與名字服務、通知服務的啟動之間存在順序上的限制。本發(fā)明實施例為了消除諸如CORBA應用與名字服務、通知服務之間所存在的啟動依賴 性、注冊依賴性，提供一種應用與服務之間的松耦合思想，使得在服務出現(xiàn)異常時仍能保證 網(wǎng)絡的正常運營。本發(fā)明的以下實施例將以CORBA應用以及其定義的名字服務和通知服務 為例對本發(fā)明實施例的技術方案進行詳細的說明，需要指出的是，本發(fā)明實施例提供的服 務與應用的松耦合思想并不局限于CORBA應用，適用于其他任何存在啟動依賴性或注冊依 賴性的應用，如對JMS存在依賴性的新興接口技術MT0SI，以下不再贅述。圖1為本發(fā)明服務處理方法一實施例的流程圖，如圖1所示，本實施例提供了 一種 服務處理方法，具體包括如下步驟步驟101，CORBA服務端啟動后，該服務端啟動名字服務管理任務；在本實施例中，CORBA應用的服務端啟動服務端對應的一個名字服務管理任務，此 處對應的含義可以理解為，該名字服務管理任務在物理形態(tài)上可以為服務端應用的一個線 程或者一個定時任務，也可以為一個獨立的進程或進程組。具體地，該名字服務管理任務可 以為名字服務狀態(tài)檢測任務，用來定期檢測名字服務的服務狀態(tài)的；也還可以為名字服務 定期注冊任務，用來定期在名字服務上注冊對象服務信息。名字服務管理任務在名字服務 啟動之前啟動，并在名字服務的整個運行期間運行。步驟102，在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，服務端通過名字服 務管理任務將服務端的對象服務信息注冊到名字服務上。在本步驟中，在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，服務端通過啟 動的名字服務管理任務進行對象服務信息的注冊。名字服務由停止服務狀態(tài)轉換為開始服 務狀態(tài)這一服務狀態(tài)的變化可以具體為名字服務重新啟動，也可以為名字服務上注冊的對 象服務信息丟失等。需要指出的是，名字服務重新啟動可以為名字服務首次啟動、正常重啟 或者異常重啟。在名字服務首次啟動、正常重啟或者異常重啟之后，服務端通過該名字服務管理 任務將服務端的對象服務信息注冊到名字服務上?；蛘?，在名字服務首次啟動、正常重啟或 者異常重啟之后，服務端通過名字服務管理任務以預定的時間周期，定期將服務端的對象 服務信息注冊到名字服務上。可以保證在名字服務運行正常時服務端自身將對象服務信息 注冊到名字服務上。同時也可以保證在名字服務后于服務端啟動或名字服務出現(xiàn)異常重啟 的情形下，保證名字服務啟動后服務端能自動檢測到名字服務的狀態(tài)，并自動注冊對象服 務信息。因此，本實施例提供的服務處理方法使得CORBA應用的服務端的啟動不再依賴于 名字服務的啟動，而且當名字服務異常重啟后，無需再手動重啟CORBA應用，仍可以正常向 名字服務注冊對象服務信息，保證了后續(xù)客戶端可以正常獲取到對象服務信息，大大降低 了維護和咨詢成本，減少了定位失敗和事件丟失。本實施例提供了一種服務處理方法，通過設置并啟動服務端對應的名字服務管理 任務，通過名字服務管理任務完成在名字服務上注冊對象服務信息，解決了 CORBA應用與 名字服務之間的啟動依賴和注冊依賴問題，解除了 CORBA應用與名字服務之間啟動順序的 限制，實現(xiàn)了在名字服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，同時大大降低了維護和咨詢成 本，減少了定位失敗。圖2為本發(fā)明服務處理方法一實施例的信令圖，如圖2所示，本實施例具體為 CORBA應用的服務端對名字服務的啟動期松耦合方案，本實施例提供的方法具體包括如下
步驟201，CORBA服務端啟動后，該服務端啟動與服務端對應的名字服務狀態(tài)檢測 任務。在本實施例中，名字服務管理任務具體為名字服務狀態(tài)檢測任務。本步驟為CORBA 應用的服務端在啟動之后，啟動名字服務狀態(tài)檢測任務，服務端對應的名字服務狀態(tài)檢測 任務可以為服務端應用的一個線程或者一個定時任務，也可以為一個獨立的進程或進程 組。本實施例中的服務端在名字服務啟動之前啟動，在服務端的啟動期間，服務端不直接在 名字服務上注冊對象服務信息，而是先啟動對應的名字服務狀態(tài)檢測任務，由該名字服務 狀態(tài)檢測任務對名字服務的服務狀態(tài)進行定時檢測。步驟202，服務端通過名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)。服務端先于名字服務啟動，并啟動服務端對應的名字服務狀態(tài)檢測任務，通過名 字服務狀態(tài)檢測任務，對名字服務的當前服務狀態(tài)進行定期的檢測，不斷地檢測名字服務 是否已經(jīng)啟動，以根據(jù)名字服務的服務狀態(tài)來進行后續(xù)的相應操作。步驟203，當名字服務狀態(tài)檢測任務檢測到名字服務首次啟動時，則將服務端的對 象服務信息注冊到名字服務上。本實施例中預設的觸發(fā)條件為名字服務狀態(tài)檢測任務對名字服務的服務狀態(tài)進 行檢測，檢測到名字服務的狀態(tài)由停止服務狀態(tài)轉為開始服務狀態(tài)，本實施例以名字服務 的首次啟動為例進行說明。本實施例針對的是名字服務在啟動期的情況，在名字服務狀態(tài) 檢測任務啟動之前名字服務尚未啟動。服務端對應的名字服務狀態(tài)檢測任務啟動之后，對 名字服務的當前服務狀態(tài)進行定期的檢測，不斷地檢測名字服務是否已經(jīng)啟動，當名字服 務在某一時間以不生成持久化信息的方式啟動時，名字服務狀態(tài)檢測任務檢測到名字服務 從停止服務狀態(tài)轉為開始服務狀態(tài)，即名字服務首次啟動時，則名字服務狀態(tài)檢測任務代 替服務端將服務端的對象服務信息注冊到名字服務上。之后，客戶端便可以從名字服務上 獲取已注冊的對象服務信息，并通過服務端調用該對象服務接口。本實施例提供了 一種服務處理方法，在本實施例中，CORBA應用的服務端先于名字 服務啟動，并先啟動服務端對應的名字服務狀態(tài)檢測任務，對名字服務的服務狀態(tài)進行不 斷地檢測，一旦檢測到名字服務啟動，則在該名字服務上注冊對象服務信息，消除了現(xiàn)有技 術中對于CORBA應用的服務端應用和名字服務在啟動順序上的限制，使得服務端應用先于 名字服務啟動時，仍可以進行正常的對象服務信息的注冊以及對象服務接口的調用，不影 響整個網(wǎng)絡的正常運營。本實施例解決了 CORBA應用與名字服務之間的啟動依賴性問題， 解除了 CORBA應用與名字服務之間啟動順序的限制，在啟動順序發(fā)生變化時仍能保證正常 的注冊，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低了出 現(xiàn)問題的幾率和維護成本。圖3為本發(fā)明服務處理方法另一實施例的信令圖，如圖3所示，本實施例具體為 CORBA應用的服務端對名字服務的運行期松耦合方案，本實施例提供的方法具體包括如下 步驟步驟301，CORBA服務端啟動后，該服務端啟動與服務端對應的名字服務狀態(tài)檢測 任務。本實施例針對的是名字服務在運行期的情況，名字服務狀態(tài)檢測任務在名字服務的啟動期啟動，并在名字服務的整個運行期內運行，定期對名字服務的服務狀態(tài)進行檢測。
步驟302，服務端通過名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)。
名字服務以不生成持久化信息的方式正常啟動，在名字服務狀態(tài)檢測任務檢測到 名字服務的服務狀態(tài)首次啟動之后，將服務端的對象服務信息注冊到名字服務上，而在名 字服務正常運行時，此過程中名字服務狀態(tài)檢測任務未檢測到名字服務的服務狀態(tài)由停止 服務狀態(tài)轉化為開始服務狀態(tài)，則由服務端正常向該名字服務進行對象服務信息的注冊， 并由客戶端進行后續(xù)的對象服務信息的獲取以及對象服務接口的調用過程。在名字服務運 行過程中，名字服務狀態(tài)檢測任務繼續(xù)對名字服務的服務狀態(tài)進行檢測，例如當名字服務 由于某些客觀原因或人為原因在某一時刻發(fā)生異常，并且進行異常重啟之后，名字服務狀 態(tài)檢測任務即可檢測到名字服務的狀態(tài)由停止服務狀態(tài)轉化為繼續(xù)服務狀態(tài)。步驟303，當名字服務狀態(tài)檢測任務檢測到名字服務異常重啟時，則將服務端的對 象服務信息注冊到名字服務上。本實施例中預設的觸發(fā)條件為名字服務狀態(tài)檢測任務對名字服務的服務狀態(tài)進 行檢測，檢測到名字服務的狀態(tài)由停止服務狀態(tài)轉為開始服務狀態(tài)，本實施例以名字服務 的異常重啟為例進行說明。由于名字服務在初次啟動時的啟動方式為不生成持久化信息的 方式，因此在名字服務異常重啟之后，在名字服務上未對異常重啟之前注冊的對象服務信 息進行保存，如果采用現(xiàn)有技術的方法，則客戶端應用此時無法從名字服務上獲取對象服 務信息。而采用本實施例所提供的方法時，由于增設了服務端對應的名字服務狀態(tài)檢測任 務，該名字服務狀態(tài)檢測任務在名字服務的運行過程中不斷地對名字服務的服務狀態(tài)進行 檢測，當名字服務狀態(tài)檢測任務檢測到名字服務的服務狀態(tài)為異常重啟時，則代替服務端 將服務端的對象服務信息注冊到該名字服務上。進一步地，本實施例提供的服務處理方法還可以包括如下步驟通過名字服務狀 態(tài)檢測任務檢測名字服務的服務狀態(tài)，當名字服務狀態(tài)檢測任務檢測到名字服務上注冊的 對象服務信息與服務端的對象服務信息不一致時，確定名字服務由停止服務狀態(tài)轉換為開 始服務狀態(tài)，并將服務端的對象服務信息注冊到名字服務上。本實施例提供的名字服務狀 態(tài)檢測任務對名字服務的服務狀態(tài)進行檢測，可以檢測到名字服務上注冊的對象服務信息 丟失。名字服務狀態(tài)檢測任務可以將名字服務上注冊的對象服務信息與客戶端獲取的對象 服務信息進行比較，如果二者不同，則表明對象服務信息已丟失，當名字服務狀態(tài)檢測任務 檢測到對象服務信息丟失時，確定所述名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，同 樣將服務端的對象服務信息注冊到名字服務上，以保證后續(xù)操作正?；?。本實施例提供了 一種服務處理方法，在本實施例中，CORBA應用的服務端通過設置 并啟動名字服務狀態(tài)檢測任務，并在名字服務的整個運行期間運行，對名字服務的狀態(tài)進 行不斷地檢測，一旦檢測到名字服務的狀態(tài)發(fā)生異常時，即名字服務異常重啟或發(fā)生對象 服務信息丟失等，則在該名字服務上重新注冊對象服務信息，消除了現(xiàn)有技術中對于CORBA 應用的服務端應用對名字服務的啟動依賴性和注冊依賴性，使得名字服務異常重啟后，無 需重啟服務端，仍可以進行正常的對象服務信息的注冊以及對象服務接口的調用，不影響 整個網(wǎng)絡的正常運營，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性， 大大降低了出現(xiàn)問題的幾率和維護成本。圖4為本發(fā)明服務處理方法另一實施例的流程圖，如圖4所示，本實施例提供了另一種服務處理方法，具體包括如下步驟步驟401，CORBA服務端啟動后，該服務端啟動通知服務管理任務；在本實施例中，CORBA應用的服務端啟動服務端對應的一個通知服務管理任務，此 處對應的含義可以理解為，該通知服務管理任務在物理形態(tài)上可以為服務端應用的一個線 程或者一個定時任務，也可以為一個獨立的進程或進程組。具體地，該通知服務管理任務可 以為通知服務狀態(tài)檢測任務，用來定期檢測通知服務的服務狀態(tài)的；也通知服務事件通道 創(chuàng)建任務，用來定期創(chuàng)建服務端與通知服務之間的事件通道。通知服務管理任務在通知服 務啟動之前啟動，并在通知服務的整個運行期間運行。步驟402，在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，服務端通過通知服 務管理任務創(chuàng)建服務端與通知服務的事件通道。在本步驟中，在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，服務端通過啟 動的通知服務管理任務進行事件通道的創(chuàng)建。通知服務停止服務并重新啟動這一服務狀態(tài) 的變化可以具體為通知服務重新啟動，也可以為通知服務上創(chuàng)建的事件通道發(fā)生異常等。 需要指出的是，通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)可以為通知服務首次啟動、 正常重啟或者異常重啟。在通知服務首次啟動、正常重啟或者異常重啟之后，服務端通過該通知服務管理 任務創(chuàng)建服務端與通知服務之間的事件通道。或者在通知服務首次啟動、正常重啟或者異 常重啟之后，服務端通過通知服務管理任務以預定的時間周期，定期創(chuàng)建服務端與通知服 務之間的事件通道?？梢员ＷC在通知服務運行正常時創(chuàng)建服務端與通知服務之間的事件 通道，同時也可以保證在通知服務后于服務端啟動或通知服務出現(xiàn)異常重啟的情形下，保 證通知服務啟動后服務端能自動檢測到通知服務的狀態(tài)，并自動在通知服務上創(chuàng)建事件通 道。因此，本實施例提供的服務處理方法使得CORBA應用的服務端的啟動不再依賴于通知 服務的啟動，而且當通知服務異常重啟后，無需再手動重啟CORBA應用，仍可以正常向通知 服務創(chuàng)建事件通道，保證了后續(xù)通知服務也可以正常通過事件通道向客戶端轉發(fā)事件，大 大降低了維護和咨詢成本，減少了事件丟失。本實施例提供了一種服務處理方法，通過設置并啟動服務端對應的通知服務管 理任務，通過通知服務管理任務完成在通知服務上創(chuàng)建事件通道，解決了 CORBA應用與通 知服務之間的啟動依賴和注冊依賴問題，解除了 CORBA應用與通知服務之間啟動順序的限 制，實現(xiàn)了在名字服務、通知服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，同時大大降低了維護和 咨詢成本，減少了事件丟失。圖5為本發(fā)明服務處理方法又一實施例的信令圖，如圖5所示，本實施例具體為 CORBA應用的服務端對通知服務的啟動期松耦合方案，本實施例提供的方法具體包括如下 步驟步驟501，CORBA服務端啟動后，該服務端啟動對應的通知服務狀態(tài)檢測任務。在本實施例中，服務管理任務具體為通知服務狀態(tài)檢測任務，通知服務狀態(tài)檢測 任務可以為服務端的一個線程或者一個定時任務，也可以為一個獨立的進程或進程組。服 務端先于通知服務啟動，并啟動服務端對應的通知服務狀態(tài)檢測任務，而不直接在通知服 務上創(chuàng)建事件通道。步驟502，服務端通過通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)。
服務端先于通知服務啟動，并啟動對應的通知服務狀態(tài)檢測任務，通過通知服務 狀態(tài)檢測任務對通知服務的服務狀態(tài)進行定期檢測，不斷地檢測通知服務是否已經(jīng)啟動， 以根據(jù)通知服務的服務狀態(tài)來進行后續(xù)的相應操作。步驟503，當通知服務狀態(tài)檢測任務檢測到通知服務首次啟動時，則創(chuàng)建服務端與 通知服務之間的事件通道。本實施例中預設的觸發(fā)條件為通知服務狀態(tài)檢測任務對通知服務的服務狀態(tài)進 行檢測，檢測到通知服務的狀態(tài)由停止服務狀態(tài)轉為開始服務狀態(tài)，本實施例以通知服務 的首次啟動為例進行說明。通知服務狀態(tài)檢測任務對通知服務的服務狀態(tài)進行定期檢測， 當通知服務在某一時間以不生成持久化信息的方式啟動，通知服務狀態(tài)檢測任務檢測到通 知服務的服務狀態(tài)從停止服務狀態(tài)轉化為開始服務狀態(tài)，即檢測到通知服務首次啟動時， 通知服務狀態(tài)檢測任務代替服務端創(chuàng)建該服務端與通知服務之間的事件通道。步驟504，通知服務狀態(tài)檢測任務向服務端發(fā)送事件通道可用消息，指示服務端上 報事件。步驟505，服務端通過事件通道將事件上報到通知服務上。在通知服務狀態(tài)檢測任務將服務端與通知服務之間的事件通道創(chuàng)建成功之后，向 服務端發(fā)送事件通道可用消息，由該事件通道可用消息指示服務端上報事件。當服務端接 收到事件通道可用消息，獲知事件通道可用后，通過該事件通道向通知服務進行事件的上 報，此后，通知服務可以向客戶端轉發(fā)服務端應用發(fā)送的事件，客戶端便可以通過創(chuàng)建的事 件通道正常接收其感興趣的事件。進一步地，在步驟504之前，還可以包括通知服務狀態(tài)檢測任務在檢測到通知服 務處于停止服務狀態(tài)時，向服務端發(fā)送事件通道不可用消息，指示述服務端在接收到事件 通道可用消息前將需要上報的事件進行本地緩存處理；通知服務狀態(tài)檢測任務檢測到服務 從停止服務狀態(tài)轉為開始服務狀態(tài)并創(chuàng)建與通知服務之間的事件通道后，向服務端發(fā)送事 件通道可用消息，指示服務端將所緩存的事件通過事件通道發(fā)送給通知服務。在服務端啟 動之后，通知服務啟動之前，通知服務狀態(tài)檢測任務檢測到的通知服務的服務狀態(tài)為停止 服務狀態(tài)，在此過程中實際上有事件發(fā)生，但由于未創(chuàng)建事件通道，因此在這段時間發(fā)生的 事件均不直接進行上報，而是進行本地緩存處理。此處所指的本地緩存處理可以采用以下 方式中的任意一種第一種方式為丟棄未上報事件，這種方式為將事件通道創(chuàng)建之前所發(fā) 生的未上報事件直接丟棄，不再進行后續(xù)的上報操作。第二種方式為緩存未上報事件到文 件或數(shù)據(jù)庫中，這種方式未丟棄未上報事件，而是將其進行持久化緩存，即緩存在特定的文 件或者數(shù)據(jù)庫中，當通知服務狀態(tài)檢測任務檢測到通知服務的服務狀態(tài)從停止服務狀態(tài)轉 為開始服務狀態(tài)，并已成功創(chuàng)建服務端與通知服務之間的事件通道之后，通知服務狀態(tài)檢 測任務向服務端發(fā)送事件通道可用消息，通過該事件通道可用消息指示服務端將緩存在特 定的文件或者數(shù)據(jù)庫中的事件通過該事件通道發(fā)送到通知服務，這種方式可以保證未上報 事件均不丟失。第三種方式為緩存未上報事件到額定存儲空間的內存中，這種方式未將未 上報事件直接丟棄，也未將其直接緩存在特定的文件或數(shù)據(jù)庫中，而是將其緩存在具有額 定存儲空間的內存中。此處所指的內存可以為具有額定存儲空間的內存隊列，也可以為具 有額定存儲空間的文件或數(shù)據(jù)庫等形式的緩存。這種方式中所指的內存具有額定存儲空 間，即設定內存的最大容量，在進行未上報事件的緩存時，并不是對未上報事件進行無限量緩存，而對其數(shù)量進行了限制，當達到內存最大容量時，按照先入先出的方式丟棄最早緩存 的未上報事件。當通知服務狀態(tài)檢測任務檢測到通知服務的服務狀態(tài)從停止服務狀態(tài)轉為 開始服務狀態(tài)，并已成功創(chuàng)建服務端與通知服務之間的事件通道之后，通知服務狀態(tài)檢測 任務向服務端發(fā)送事件通道可用消息，通過該事件通道可用消息指示服務端將緩存在該內 存的事件通過該事件通道發(fā)送到通知服務?？梢姡@種方式可以保證最新發(fā)生的一定數(shù)量 的未上報事件不會丟失。本實施例提供了 一種服務處理方法，在本實施例中，CORBA應用的服務端先于通知 服務啟動，并先啟動對應的通知服務狀態(tài)檢測任務，而不是直接向通知服務創(chuàng)建事件通道， 通過通知服務狀態(tài)檢測任務對通知服務的服務狀態(tài)進行不斷地檢測，一旦檢測到通知服務 啟動后，則在該通知服務上創(chuàng)建事件通道，隨后即通過該事件通道進行事件上報，且將事件 通道創(chuàng)建成功之前發(fā)生的事件進行緩存，在事件通道創(chuàng)建成功后也進行上報。通過本實施 例提供的方法消除了現(xiàn)有技術中對CORBA應用的服務端和通知服務在啟動順序上的限制， 使得服務端在先于通知服務啟動時，仍可以進行正常的事件通道創(chuàng)建以及事件的上報，不 影響整個網(wǎng)絡的正常運營。本實施例解決了 CORBA應用與通知服務之間的啟動依賴性問 題，解除了 CORBA應用與通知服務之間啟動順序的限制，當啟動順序發(fā)生變化時，仍能保證 正常的定位，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低 了出現(xiàn)問題的幾率和維護成本。圖6為本發(fā)明服務處理方法再一實施例的信令圖，如圖6所示，本實施例具體為 CORBA應用的服務端對通知服務的運行期松耦合方案，本實施例提供的方法具體包括如下 步驟步驟601，CORBA服務端啟動后，啟動對應的通知服務狀態(tài)檢測任務。本實施例針對的是通知服務在運行期的情況，通知服務狀態(tài)檢測任務在通知服務 的啟動期啟動，并在通知服務的整個運行期內運行，定期對通知服務的狀態(tài)進行檢測。步驟602，服務端通過通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)。通知服務以不生成持久化信息的方式正常啟動，在通知服務狀態(tài)檢測任務檢測到 通知服務的服務狀態(tài)首次啟動之后，代替服務端創(chuàng)建與通知服務之間的事件通道，而在通 知服務正常運行時，此過程中通知服務狀態(tài)檢測任務未檢測到通知服務的服務狀態(tài)由停止 服務狀態(tài)轉化為開始服務狀態(tài)，則由服務端自身正常向該通知服務進行事件通道的創(chuàng)建， 并向通知服務正常上報事件。在通知服務運行過程中，通知服務狀態(tài)檢測任務繼續(xù)對通知 服務的服務狀態(tài)進行檢測，例如當通知服務由于某些客觀原因或人為原因在某一時刻發(fā)生 異常，并且進行異常重啟之后，通知服務狀態(tài)檢測任務即可檢測到通知服務的狀態(tài)由停止 服務狀態(tài)轉化為繼續(xù)服務狀態(tài)。步驟603，當通知服務狀態(tài)檢測任務檢測到通知服務異常啟動時，則創(chuàng)建服務端與 通知服務之間的事件通道。本實施例中預設的觸發(fā)條件為通知服務狀態(tài)檢測任務對通知服務的服務狀態(tài) 進行檢測，檢測到通知服務的狀態(tài)由停止服務狀態(tài)轉為開始服務狀態(tài)，本實施例以通知服 務的異常重啟為例進行說明。通知服務以不生成持久化信息的方式正常啟動后，在該通知 服務上正常創(chuàng)建事件通道并上報事件。在運行過程中，通知服務由于某些客觀原因或人為 原因在某一時刻發(fā)生異常，并且進行異常重啟時，通知服務狀態(tài)檢測任務即檢測到通知服
12務異常啟動，則通知服務狀態(tài)檢測任務代替服務端創(chuàng)建該服務端與通知服務之間的事件通道。步驟604，通知服務狀態(tài)檢測任務向服務端發(fā)送事件通道可用消息，指示服務端上 報事件。步驟605，服務端通過事件通道將事件上報到通知服務上。在通知服務狀態(tài)檢測任務將服務端與通知服務之間的事件通道創(chuàng)建成功之后，向 服務端發(fā)送事件通道可用消息，由該事件通道可用消息指示服務端上報事件。當服務端接 收到事件通道可用消息，獲知事件通道可用后，通過該事件通道向通知服務進行事件的上 報，此后，通知服務可以向客戶端轉發(fā)服務端應用發(fā)送的事件，客戶端便可以通過創(chuàng)建的事 件通道正常接收其感興趣的事件。進一步地，在步驟604之前，還可以包括通知服務狀態(tài)檢測任務在檢測到通知服 務處于停止服務狀態(tài)時，向服務端發(fā)送事件通道不可用消息，指示述服務端在接收到事件 通道可用消息前將需要上報的事件進行本地緩存處理；通知服務狀態(tài)檢測任務檢測到服 務從停止服務狀態(tài)轉為開始服務狀態(tài)并創(chuàng)建與通知服務之間的事件通道后，向服務端發(fā)送 事件通道可用消息，指示服務端將所緩存的事件通過事件通道發(fā)送給通知服務。在通知服 務異常終止之后，通知服務狀態(tài)檢測任務檢測到的通知服務的服務狀態(tài)為停止服務狀態(tài)， 在通知服務重啟之前所發(fā)生的事件均不直接進行上報，而是對未上報事件進行本地緩存處 理。此處所指的本地緩存處理可以采用以下方式中的任意一種第一種方式為丟棄未上報 事件，這種方式為將事件通道創(chuàng)建之前所發(fā)生的未上報事件直接丟棄，不再進行后續(xù)的上 報操作。第二種方式為緩存未上報事件到文件或數(shù)據(jù)庫中，這種方式未丟棄未上報事件，而 是將其進行持久化緩存，即緩存在特定的文件或者數(shù)據(jù)庫中，當通知服務狀態(tài)檢測任務檢 測到通知服務的服務狀態(tài)從停止服務狀態(tài)轉為開始服務狀態(tài)，并已成功創(chuàng)建服務端與通知 服務之間的事件通道之后，通知服務狀態(tài)檢測任務向服務端發(fā)送事件通道可用消息，通過 該事件通道可用消息指示服務端將緩存在特定的文件或者數(shù)據(jù)庫中的事件通過該事件通 道發(fā)送到通知服務，這種方式可以保證未上報事件均不丟失。第三種方式為緩存未上報事 件到額定存儲空間的內存中，這種方式未將未上報事件直接丟棄，也未將其直接緩存在特 定的文件或數(shù)據(jù)庫中，而是將其緩存在具有額定存儲空間的內存中。此處所指的內存可以 為具有額定存儲空間的內存隊列，也可以為具有額定存儲空間的文件或數(shù)據(jù)庫等形式的緩 存。這種方式中所指的內存具有額定存儲空間，即設定內存的最大容量，在進行未上報事件 的緩存時，并不是對未上報事件進行無限量緩存，而對其數(shù)量進行了限制，當達到內存最大 容量時，按照先入先出的方式丟棄最早緩存的未上報事件。通知服務狀態(tài)檢測任務檢測到 通知服務的服務狀態(tài)從停止服務狀態(tài)轉為開始服務狀態(tài)，并已成功創(chuàng)建服務端與通知服務 之間的事件通道之后，通知服務狀態(tài)檢測任務向服務端發(fā)送事件通道可用消息，通過該事 件通道可用消息指示服務端將緩存在該內存的事件通過該事件通道發(fā)送到通知服務?？?見，這種方式可以保證最新發(fā)生地一定數(shù)量的未上報事件不會丟失。進一步地，本實施例提供的服務處理方法還可以包括如下步驟若通知服務狀態(tài) 檢測任務檢測到通知服務上創(chuàng)建的事件通道發(fā)生異常，則確定名字服務由停止服務狀態(tài)轉 換為開始服務狀態(tài)，通知服務狀態(tài)檢測任務創(chuàng)建服務端與通知服務之間的事件通道。本實 施例提供的通知服務狀態(tài)檢測任務對通知服務的服務狀態(tài)進行檢測，檢測的通知服務的服
13務狀態(tài)除包括通知服務異常重啟外，還可以包括通知服務的其他異常狀況，如通知服務上 的事件通道異常。通知服務狀態(tài)檢測任務對通知服務上的事件通道的狀態(tài)進行檢測，當檢 測到事件通道異常時，通知服務狀態(tài)檢測任務代替服務端向通知服務重新創(chuàng)建事件通道， 以保證后續(xù)操作正?；１緦嵤├峁┝?一種服務處理方法，在本實施例中，CORBA應用的服務端通過設置 并啟動通知服務狀態(tài)檢測任務，并在通知服務的整個運行期間運行，對通知服務的狀態(tài)進 行不斷地檢測，一旦檢測到通知服務的狀態(tài)發(fā)生異常時，即通知服務異常重啟或發(fā)生事件 通道異常等，則在該通知服務上重新創(chuàng)建事件通道，消除了現(xiàn)有技術中對于CORBA應用的 服務端應用對通知服務的啟動依賴性和注冊依賴性，使得通知服務異常重啟后，無需重啟 服務端，仍可以進行正常的事件通道的創(chuàng)建以及事件的上報，不影響整個網(wǎng)絡的正常運營， 直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低了出現(xiàn)問題 的幾率和維護成本。圖7為本發(fā)明服務處理方法還一實施例的信令圖，如圖7所示，本實施例提供了另 一種服務處理方法，本實施例針對CORBA應用的服務端應用與名字服務在啟動期和運行期 的松耦合方案，具體包括如下步驟步驟701，CORBA服務端啟動后，該服務端啟動服務端對應的名字服務定期注冊任務。步驟702，服務端通過名字服務定期注冊任務以預定的時間周期將服務端的對象 服務信息注冊到名字服務上。本實施例采用的方法為與上述圖2-圖3所示的方法不同，本實施例為對上述實施 例的一種簡化，在本實施例中設置的名字服務管理任務為服務端對應的名字服務定期注冊 任務，而不是名字服務狀態(tài)檢測任務，名字服務定期注冊任務可以為服務端的一個線程或 者一個定時任務，也可以為一個獨立的進程或進程組。此處所指的預定的時間周期為名字 服務定期注冊任務執(zhí)行注冊動作的時間間隔，該時間間隔由用戶根據(jù)名字服務在運行過程 中的實際情況而設定的，如考慮名字服務可能出現(xiàn)異常的頻率，以及事件發(fā)生的頻率等實 際情況，使得名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的時間位于該預定的時間周期 內。當然，設定的時間周期越短越能減少因名字服務異常而導致的網(wǎng)絡運營異常的概率，但 同時名字服務定期注冊任務的高頻率運行也導致系統(tǒng)資源的占用率提高，影響系統(tǒng)運行的 效率，因此，用戶在設定任務運行的間隔時間時，需要進行以上方面的權衡考慮。名字服務定期注冊任務在名字服務的啟動期即啟動，不管名字服務的狀態(tài)如何， 均定期向名字服務進行對象服務信息的注冊。如上述步驟中，當名字服務出現(xiàn)異常重啟之 后，名字服務定期注冊任務會將服務端的對象服務信息注冊到名字服務上，因此客戶端應 用仍可以從名字服務上正常獲取對象服務信息，不會影響網(wǎng)絡的正常運營。而且采用本實 施例提供的方法時，由于名字服務定期注冊任務不斷地在名字服務上注冊對象服務信息， 服務端應用也可以在名字服務啟動之前啟動，解除了服務端應用對于名字服務的啟動依賴 性。本實施例提供的方法為對上述實施例的一種簡化，無需定期檢測名字服務的狀態(tài)，因此 降低了 CORBA應用的服務端的實現(xiàn)復雜度，同時還可以保證對象服務信息的注冊可靠性， 但CORBA應用的客戶端在獲取其感興趣的事件時，由于其不能確定當前的事件通道是否可 用，需要偵聽通知服務上的所有事件通道。
本實施例提供了一種服務處理方法，通過設置名字服務定期注冊任務，不管名字 服務的狀態(tài)如何，定期向名字服務注冊對象服務信息，消除了現(xiàn)有技術中對于CORBA應用 的服務端對名字服務的啟動依賴性和注冊依賴性，使得服務端先于名字服務啟動時，仍可 以進行正常的對象服務信息的注冊以及對象服務接口的調用，而且當名字服務異常重啟 后，無需重啟服務端，仍可以進行正常的對象服務信息的注冊以及對象服務接口的調用，不 影響整個網(wǎng)絡的正常運營，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可 靠性，大大降低了出現(xiàn)問題的幾率和維護成本。圖8為本發(fā)明服務處理方法又另一實施例的信令圖，如圖8所示，本實施例提供的 服務處理方法包括如下步驟步驟801，服務端啟動對應的配置信息變更檢測任務。步驟802，服務端通過配置信息變更檢測任務定期檢測名字服務的配置信息的狀 態(tài)。步驟803，當配置信息變更檢測任務檢測到名字服務的配置信息發(fā)生更新，則確定 名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，并通過配置信息變更檢測任務將服務端的 對象服務信息注冊到新的名字服務上。在本實施例中，名字服務的相關信息可以通過配置信息進行定制，而非固定在可 執(zhí)行代碼中，即名字服務是可以根據(jù)配置信息而改變的，配置信息發(fā)生變更時，名字服務也 變?yōu)榱硪环N新的名字服務。服務端可以在其啟動期即啟動對應的配置信息變更檢測任務， 通過配置信息變更檢測任務定期檢測名字服務的配置信息的狀態(tài)。當配置信息變更檢測任 務檢測到名字服務的配置信息發(fā)生變更時，則表明名字服務變更為新的名字服務，確定名 字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，配置信息變更檢測任務將所述服務端的對象 服務信息注冊到配置信息更新后的名字服務上。同時，配置信息變更檢測任務向服務端發(fā) 送配置信息更新消息，由該配置信息更新消息指示名字服務的配置信息發(fā)生變化，在將對 象服務信息注冊到新的名字服務注冊上后，客戶端后續(xù)便可從新的名字服務上獲取對象服 務信息。本實施例提供了一種服務處理方法，通過設置并啟動配置信息變更檢測任務，檢 測名字服務的配置信息的狀態(tài)，當檢測到名字服務的配置信息發(fā)生變化時，則服務端向新 的名字服務注冊對象服務信息，實現(xiàn)了在名字服務發(fā)生變化時無需重啟服務端，自動進行 對象服務信息的注冊，不影響整個網(wǎng)絡的正常運營，從而解除了 CORBA應用與名字服務的 啟動依賴性，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低 了出現(xiàn)問題的幾率和維護成本。圖9為本發(fā)明服務處理方法又再一實施例的信令圖，如圖9所示，本實施例提供了 另一種服務處理方法，本實施例針對CORBA應用的服務端應用與通知服務在啟動期和運行 期的松耦合方案，具體包括如下步驟步驟901，CORBA服務端啟動后，該服務端啟動通知服務定期創(chuàng)建任務。步驟902，服務端通過通知服務定期創(chuàng)建任務，以預定的時間周期定期在通知服務 上創(chuàng)建事件通道。本實施例采用的方法為與上述圖5-圖6所示的方法不同，本實施例為對上述實施 例的一種簡化，在本實施例中設置的通知服務管理任務為服務端對應的通知服務定期創(chuàng)建任務，而不是通知服務狀態(tài)檢測任務，通知服務定期創(chuàng)建任務可以為服務端的一個線程或 者一個定時任務，也可以為一個獨立的進程或進程組。此處所指的預定的時間周期為通知 服務定期創(chuàng)建任務執(zhí)行通道創(chuàng)建動作的時間間隔，該時間間隔由用戶根據(jù)通知服務在運行 過程中的實際情況而設定的，如考慮通知服務可能出現(xiàn)異常的頻率，以及事件發(fā)生的頻率 等實際情況，使得該通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的時間位于預定的時間 周期內。當然，設定的時間周期越短越能減少因通知服務異常而導致的網(wǎng)絡運營異常的概 率，但同時通知服務定期創(chuàng)建任務的高頻率運行也導致系統(tǒng)資源的占用率提高，影響系統(tǒng) 運行的效率，因此，用戶在設定任務運行的間隔周期時，需要進行以上方面的權衡考慮。通知服務定期創(chuàng)建任務在通知服務的啟動期即啟動，不管通知服務的狀態(tài)如何， 均定期在通知服務上銷毀原有事件通道，并創(chuàng)建新的事件通道。如上述步驟中，當通知服 務出現(xiàn)異常重啟之后，通知服務定期創(chuàng)建任務會代替服務端創(chuàng)建與通知服務之間的事件通 道，因此服務端仍可以將后續(xù)事件通過事件通道上報到通知服務，客戶端仍可以通過通知 服務接收轉發(fā)的事件，不會影響網(wǎng)絡的正常運營。而且采用本實施例提供的方法時，由于通 知服務定期創(chuàng)建任務不斷地在通知服務上創(chuàng)建事件通道，服務端也可以在通知服務啟動之 前啟動，解除了服務端對于通知服務的啟動依賴性。本實施例提供的方法為對上述實施例 的一種簡化，無需定期檢測通知服務的狀態(tài)，因此降低了 CORBA應用的服務端的實現(xiàn)復雜 度，同時還可以保證事件通道創(chuàng)建的可靠性。本實施例提供了一種服務處理方法，通過設置通知服務定期創(chuàng)建任務，不管通知 服務的狀態(tài)如何，定期在通知服務上創(chuàng)建事件通道，消除了現(xiàn)有技術中對于CORBA應用的 服務端對通知服務的啟動依賴性和注冊依賴性，使得服務端先于通知服務啟動時，仍可以 進行正常的事件通道的創(chuàng)建以及事件的上報，而且當通知服務異常重啟后，無需重啟服務 端應用，仍可以進行正常的事件通道的創(chuàng)建以及事件的上報，不影響整個網(wǎng)絡的正常運營， 直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低了出現(xiàn)問題 的幾率和維護成本。圖10為本發(fā)明服務處理方法又還一實施例的信令圖，如圖10所示，本實施例提供 的服務處理方法包括如下步驟步驟1001，CORBA服務端啟動之后，該服務端啟動對應的配置信息變更檢測任務。步驟1002，服務端通過配置信息變更檢測任務定期檢測通知服務的配置信息的狀 態(tài)。步驟1003，當配置信息變更檢測任務檢測到通知服務的配置信息發(fā)生更新時，則 確定通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，通過配置信息變更檢測任務創(chuàng)建服務 端與新的通知服務之間的事件通道。在本實施例中，通知服務的相關信息可以通過配置信息進行定制，而非固定在可 執(zhí)行代碼中，即通知服務是可以根據(jù)配置信息而改變的，配置信息發(fā)生變更時，通知服務也 變?yōu)榱硪环N新的通知服務。服務端可以在其啟動期即啟動對應的配置信息變更檢測任務， 通過配置信息變更檢測任務定期檢測通知服務的配置信息的狀態(tài)。當配置信息變更檢測任 務檢測到通知服務的配置信息發(fā)生變更時，則表明通知服務變更為新的通知服務，確定通 知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，配置信息變更檢測任務創(chuàng)建服務端與新的通 知服務之間的事件通道。同時，配置信息變更檢測任務向服務端發(fā)送配置信息更新消息，由該配置信息更新消息指示服務端通知服務的配置信息發(fā)生變化，在新的事件通道創(chuàng)建成功 后，服務端通過新的事件通道將事件上報到通知服務，客戶端后續(xù)便可通過新的通知服務 上獲取感興趣的事件。本實施例提供了一種服務處理方法，通過設置并啟動配置信息變更檢測任務，檢 測通知服務的配置信息的變狀態(tài)，當檢測到通知服務的配置信息發(fā)生變化時，則創(chuàng)建服務 端與新的通知服務之間的事件通道，實現(xiàn)了在通知服務發(fā)生變化時無需重啟服務端，自動 進行事件通道的創(chuàng)建，不影響整個網(wǎng)絡的正常運營，從而解除了 CORBA應用與通知服務的 啟動依賴性，直接降低了 CORBA接口在網(wǎng)絡部署上的難度，提高了接口的可靠性，大大降低 了出現(xiàn)問題的幾率和維護成本。圖11為本發(fā)明公共對象請求代理結構服務端裝置一實施例的結構圖，如圖11所 示，本發(fā)明實施例提供的一種公共對象請求代理結構服務端裝置包括第一任務啟動模塊 1101和第一服務管理模塊1102。其中，第一任務啟動模塊1101用于在本服務端啟動后，啟 動名字服務管理任務。第一服務管理模塊1102用于在名字服務由停止服務狀態(tài)轉換為開 始服務狀態(tài)后，通過名字服務管理任務將服務端的對象服務信息注冊到名字服務上。名字 服務管理任務在物理形態(tài)上可以為服務端的一個子模塊，也可以為一個獨立的模塊。第一 服務管理模塊1102在名字服務啟動之前啟動，并在名字服務的整個運行期間運行。第一服 務管理模塊1102可以在名字服務運行正常時向名字服務注冊對象服務信息，也可以在名 字服務運行異常時仍然向名字服務注冊對象服務信息。本實施例提供的服務端裝置使得 CORBA應用的服務端的啟動不再依賴于名字服務的啟動，當名字服務異常重啟后，無需再手 動重啟CORBA應用，服務端應用仍正常向名字服務注冊對象服務信息，保證了后續(xù)客戶端 可以正常獲取到對象服務信息，大大降低了維護和咨詢成本，減少了定位失敗。具體地，名字服務管理任務可以具體為名字服務狀態(tài)檢測任務，則第一服務管理 模塊1102可以包括第一名字服務狀態(tài)檢測子模塊和第一信息注冊子模塊。其中，第一名字 服務狀態(tài)檢測子模塊用于通過名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)；第一信息 注冊子模塊用于當檢測到所述名字服務從停止服務狀態(tài)轉為開始服務狀態(tài)時，通過名字服 務狀態(tài)檢測任務將服務端的對象服務信息注冊到名字服務上。具體地，在名字服務狀態(tài)檢 測任務檢測到名字服務從停止服務狀態(tài)轉為開始服務狀態(tài)時，包括檢測到名字服務首次啟 動、正常重啟以及異常重啟的狀態(tài)，第一信息注冊子模塊代替服務端將服務端的對象服務 信息注冊到名字服務上，使得在名字服務后于服務端啟動時，或者在名字服務出現(xiàn)異常重 啟之后，仍可以正常向名字服務注冊對象服務信息，而客戶端可以正常從名字服務上獲取 對象服務信息，不影響整個網(wǎng)絡的正常運營?；蛘?，名字服務管理任務具體為名字服務狀態(tài)檢測任務，第一服務管理模塊1102 可以包括第二名字服務狀態(tài)檢測子模塊和第二信息注冊子模塊。其中，第二名字服務狀態(tài) 檢測子模塊用于通過名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)；第二信息注冊子模 塊用于當檢測到名字服務上注冊的對象服務信息與客戶端獲取的對象服務信息不一致時， 確定名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，并通過名字服務狀態(tài)檢測任務將服務 端的對象服務信息注冊到名字服務上。或者，名字服務管理服務具體為名字服務定期注冊任務，第一服務管理模塊1102 可以包括信息定期注冊子模塊。信息定期注冊子模塊用于通過名字服務定期注冊任務以預定的時間周期將服務端的對象服務信息注冊到名字服務上，該名字服務由停止服務狀態(tài)轉 換為開始服務狀態(tài)的時間位于預定的時間周期內。不管名字服務的狀態(tài)如何，均通過名字 服務定期注冊任務定期向名字服務進行對象服務信息的注冊，當名字服務出現(xiàn)異常重啟之 后，名字服務定期注冊任務會將服務端的對象服務信息注冊到名字服務上，因此客戶端應 用仍可以從名字服務上正常獲取對象服務信息，不會影響網(wǎng)絡的正常運營?；蛘?，名字服務管理服務具體為配置信息變更檢測任務，第一服務管理模塊1102 可以包括配置信息檢測子模塊和第三信息注冊子模塊。其中該配置信息檢測子模塊用于檢 測名字服務的配置信息，當檢測到名字服務的配置信息發(fā)生更新時，則確定名字服務由停 止服務狀態(tài)轉換為開始服務狀態(tài)；第三信息注冊子模塊用于通過配置信息變更檢測任務將 服務端的對象服務信息注冊到配置信息更新后的名字服務上。本實施例提供了一種CORBA服務端裝置，通過第一任務啟動模塊和第一服務管理 模塊，完成在名字服務發(fā)生異常時向名字服務上注冊對象服務信息，解決了 CORBA應用與 名字服務之間的啟動依賴和注冊依賴問題，解除了 CORBA應用與名字服務之間啟動順序的 限制，實現(xiàn)了在名字服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，同時大大降低了維護和咨詢成 本，減少了定位失敗。圖12為本發(fā)明公共對象請求代理結構服務端裝置另一實施例的結構圖，如圖12 所示，本發(fā)明實施例提供的一種公共對象請求代理結構服務端裝置包括第二任務啟動模塊 1201和第二服務管理模塊1202。其中，第二任務啟動模塊1201用于在本服務端啟動后， 啟動通知服務管理任務。第二服務管理模塊1202用于在通知服務由停止服務狀態(tài)轉換為 開始服務狀態(tài)后，通過通知服務管理任務創(chuàng)建服務端與通知服務的事件通道。通知服務管 理任務在物理形態(tài)上可以為服務端的一個子模塊，也可以為一個獨立的模塊。通知服務管 理任務在通知服務啟動之前啟動，并在通知服務的整個運行期間運行。第二服務管理模塊 1202可以在通知服務運行正常時向通知服務創(chuàng)建事件通道，也可以在通知服務運行異常時 仍然向通知服務創(chuàng)建事件通道。本實施例提供的服務端裝置使得CORBA應用的服務端的啟 動不再依賴于通知服務的啟動，當通知服務異常重啟后，無需再手動重啟CORBA應用，服務 端應用仍正常向通知服務創(chuàng)建事件通道，保證了后續(xù)通知服務也可以正常通過事件通道向 客戶端轉發(fā)事件，大大降低了維護和咨詢成本，減少了事件丟失。具體地，通知服務管理任務可以具體為通知服務狀態(tài)檢測任務，則第二服務管理 模塊1202可以包括第一通知服務狀態(tài)檢測子模塊和第一通道創(chuàng)建子模塊。其中，第一通 知服務狀態(tài)檢測子模塊用于通過通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)；第一通 道創(chuàng)建子模塊用于當檢測到所述通知服務從停止服務狀態(tài)轉為開始服務狀態(tài)時，通過通知 服務狀態(tài)檢測任務創(chuàng)建服務端與通知服務之間的事件通道?；蛘撸ㄖ展芾砣蝿站唧w為通知服務狀態(tài)檢測任務，則第二服務管理模塊 1202包括第二通知服務狀態(tài)檢測子模塊和第二通道創(chuàng)建子模塊。其中，第二通知服務狀 態(tài)檢測子模塊用于通過通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)；第二通道創(chuàng)建子 模塊用于當檢測到通知服務上創(chuàng)建的事件通道發(fā)生異常時，確定通知服務由停止服務狀態(tài) 轉換為開始服務狀態(tài)，并通過通知服務狀態(tài)檢測任務創(chuàng)建服務端與通知服務之間的事件通 道?；蛘撸ㄖ展芾砣蝿湛梢跃唧w為通知服務定期創(chuàng)建任務，則第二服務管理模
18塊1202包括通道定期創(chuàng)建子模塊。該通道定期創(chuàng)建子模塊用于通過通知服務定期創(chuàng)建任 務以預定的時間周期創(chuàng)建服務端與通知服務之間的事件通道，該通知服務由停止服務狀態(tài) 轉換為開始服務狀態(tài)的時間位于預定的時間周期內。無論通知服務的狀態(tài)如何，第三通知 服務子模塊定期銷毀原事件通道，向通知服務創(chuàng)建新的事件通道，因此，在通知服務出現(xiàn)異 常重啟之后，不會因為未重新啟動服務端裝置，未在通知服務上創(chuàng)建事件通道，而使得后續(xù) 上報事件失敗，客戶端獲取不到感興趣的事件?；蛘撸ㄖ展芾砣蝿站唧w為配置信息變更檢測任務，則第二服務管理模塊 1202包括配置信息檢測子模塊和第三通道創(chuàng)建子模塊。其中，配置信息檢測子模塊用于通 過配置信息變更檢測任務檢測通知服務的配置信息，當檢測到通知服務的配置信息發(fā)生更 新，確定通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)。第三通道創(chuàng)建子模塊用于通過該 配置信息變更檢測任務創(chuàng)建服務端與新的通知服務之間的事件通道。本實施例提供了一種CORBA服務端裝置，通過第二任務啟動模塊和第二服務管 理模塊，完成在通知服務發(fā)生異常時在通知服務上創(chuàng)建事件通道，解決了 CORBA應用與通 知服務之間的啟動依賴和注冊依賴問題，解除了 CORBA應用與通知服務之間啟動順序的限 制，實現(xiàn)了在通知服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，同時大大降低了維護和咨詢成本， 減少了事件丟失。最后應說明的是以上實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡 管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解其依然 可以對前述實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換； 而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明實施例技術方案的精神和范圍。
權利要求
一種服務處理方法，其特征在于，包括公共對象請求代理結構服務端啟動后，該服務端啟動名字服務管理任務；在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述名字服務管理任務將服務端的對象服務信息注冊到所述名字服務上。
2.根據(jù)權利要求1所述的服務處理方法，其特征在于，所述名字服務管理任務具體為 名字服務狀態(tài)檢測任務；所述在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述名字服務管理任務將服務端的對象服務信息注冊到所述名字服務上包括通過所述名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)；當檢測到所述名字服務從停止服務狀態(tài)轉為開始服務狀態(tài)時，通過所述名字服務狀態(tài) 檢測任務將服務端的對象服務信息注冊到名字服務上；或者通過所述名字服務狀態(tài)檢測任務檢測名字服務的服務狀態(tài)；當檢測到所述名字服務上注冊的對象服務信息與客戶端獲取的對象服務信息不一致 時，確定所述名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)；通過所述名字服務狀態(tài)檢測任務將所述服務端的對象服務信息注冊到名字服務上。
3.根據(jù)權利要求1所述的服務處理方法，其特征在于，所述名字服務管理任務具體為 名字服務定期注冊任務，所述在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述名字服務管理任務將服務端的對象服務信息注冊到所述名字服務上包括通過所述名字服務定期注冊任務以預定的時間周期將服務端的對象服務信息注冊到 所述名字服務上，該名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的時間位于預定的時間 周期內。
4.根據(jù)權利要求1所述的服務處理方法，其特征在于，所述名字服務管理任務具體為 配置信息變更檢測任務；所述在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述名字服務管理任務將服務端的對象服務信息注冊到所述名字服務上包括通過配置信息變更檢測任務檢測所述名字服務的配置信息，當檢測到所述名字服務的 配置信息發(fā)生更新時，確定所述名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)；通過所述配置信息變更檢測任務將所述服務端的對象服務信息注冊到配置信息更新 后的名字服務上。
5.一種服務處理方法，其特征在于，包括公共對象請求代理結構服務端啟動后，該服務端啟動通知服務管理任務；在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述通知服務管理任務創(chuàng)建 服務端與通知服務的事件通道。
6.根據(jù)權利要求5所述的服務處理方法，其特征在于，所述通知服務管理任務具體為 通知服務狀態(tài)檢測任務；所述在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述通知服務管理任務創(chuàng)建服務端與通知服務的事件通道包括通過所述通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)；當檢測到所述通知服務從停止服務狀態(tài)轉為開始服務狀態(tài)時，通過所述通知服務狀態(tài) 檢測任務創(chuàng)建服務端與通知服務之間的事件通道；或者通過所述通知服務狀態(tài)檢測任務檢測通知服務的服務狀態(tài)；當檢測到所述通知服務上創(chuàng)建的事件通道發(fā)生異常時，確定所述通知服務由停止服務 狀態(tài)轉換為開始服務狀態(tài)；通過所述通知服務狀態(tài)檢測任務創(chuàng)建所述服務端與通知服務之間的事件通道。
7.根據(jù)權利要求5所述的服務處理方法，其特征在于，所述通知服務管理任務具體為 通知服務定期創(chuàng)建任務，所述在通知服務停止服務轉化為開始服務狀態(tài)后，通過所述通知 服務管理任務創(chuàng)建服務端與通知服務的事件通道包括通過所述通知服務定期創(chuàng)建任務以預定的時間周期創(chuàng)建服務端與通知服務之間的事 件通道，該通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的時間位于預定的時間周期內。
8.根據(jù)權利要求5所述的服務處理方法，其特征在于，所述通知服務管理任務具體為 配置信息變更檢測任務；所述在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述通知服務管理任務創(chuàng)建服務端與通知服務的事件通道包括通過配置信息變更檢測任務檢測所述通知服務的配置信息，當檢測到所述通知服務的 配置信息發(fā)生更新，確定所述通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)；通過所述配置信息變更檢測任務創(chuàng)建所述服務端與配置信息更新后的通知服務之間 的事件通道。
9.一種公共對象請求代理結構服務端裝置，其特征在于，包括 第一任務啟動模塊，用于在服務端啟動后，啟動名字服務管理任務；第一服務管理模塊，用于在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述名字服務管理任務將服務端的對象服務信息注冊到所述名字服務上。
10.根據(jù)權利要求9所述的裝置，其特征在于，所述名字服務管理任務具體為名字服務狀態(tài)檢測任務；所述第一服務管理模塊包括 第一名字服務狀態(tài)檢測子模塊，用于通過所述名字服務狀態(tài)檢測任務檢測名字服務的 服務狀態(tài)；第一信息注冊子模塊，用于當檢測到所述名字服務從停止服務狀態(tài)轉為開始服務狀態(tài) 時，通過所述名字服務狀態(tài)檢測任務將服務端的對象服務信息注冊到名字服務上；或者，所述名字服務管理任務具體為名字服務狀態(tài)檢測任務，所述第一服務管理模塊 包括第二名字服務狀態(tài)檢測子模塊，用于通過所述名字服務狀態(tài)檢測任務檢測名字服務的 服務狀態(tài)；第二信息注冊子模塊，用于當檢測到所述名字服務上注冊的對象服務信息與客戶端獲 取的對象服務信息不一致時，確定所述名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，并 通過所述名字服務狀態(tài)檢測任務將所述服務端的對象服務信息注冊到名字服務上；或者，所述名字服務管理服務具體為名字服務定期注冊任務，所述第一服務管理模塊 包括信息定期注冊子模塊，用于通過所述名字服務定期注冊任務以預定的時間周期將服務 端的對象服務信息注冊到名字服務上，該名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的 時間位于預定的時間周期內；或者，所述名字服務管理服務具體為配置信息變更檢測任務，所述第一服務管理模塊包括配置信息檢測子模塊，用于檢測所述名字服務的配置信息，當檢測到所述名字服務的 配置信息發(fā)生更新時，確定所述名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)；第三名字服務信息注冊子模塊，用于通過所述配置信息變更檢測任務將所述服務端的 對象服務信息注冊到配置信息更新后的名字服務上。
11.一種公共對象請求代理結構服務端裝置，其特征在于，包括第二任務啟動模塊，用于在服務端啟動后，啟動通知服務管理任務；第二服務管理模塊，用于在通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所 述通知服務管理任務創(chuàng)建服務端與通知服務的事件通道。
12.根據(jù)權利要求11所述的裝置，其特征在于，所述通知服務管理任務具體為通知服務狀態(tài)檢測任務；所述第二服務管理模塊包括第一通知服務狀態(tài)檢測子模塊，用于通過所述通知服務狀態(tài)檢測任務檢測通知服務的 服務狀態(tài)；第一通道創(chuàng)建子模塊，用于當檢測到所述通知服務從停止服務狀態(tài)轉為開始服務狀態(tài) 時，通過所述通知服務狀態(tài)檢測任務創(chuàng)建服務端與通知服務之間的事件通道；或者，所述通知服務管理任務具體為通知服務狀態(tài)檢測任務；所述第二服務管理模塊 包括第二通知服務狀態(tài)檢測子模塊，用于通過所述通知服務狀態(tài)檢測任務檢測通知服務的 服務狀態(tài)；第二通道創(chuàng)建子模塊，用于當檢測到所述通知服務上創(chuàng)建的事件通道發(fā)生異常時，確 定所述通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)，并通過所述通知服務狀態(tài)檢測任務 創(chuàng)建所述服務端與通知服務之間的事件通道；或者，所述通知服務管理任務具體為通知服務定期創(chuàng)建任務；所述第二服務管理模塊 包括通道定期創(chuàng)建子模塊，用于通過所述通知服務定期創(chuàng)建任務以預定的時間周期創(chuàng)建服 務端與通知服務之間的事件通道，該通知服務由停止服務狀態(tài)轉換為開始服務狀態(tài)的時間 位于預定的時間周期內；或者，所述通知服務管理任務具體為配置信息變更檢測任務；所述第二服務管理模塊 包括配置信息檢測子模塊，用于通過所述配置信息變更檢測任務檢測所述通知服務的配置 信息，當檢測到所述通知服務的配置信息發(fā)生更新，確定所述通知服務由停止服務狀態(tài)轉 換為開始服務狀態(tài)；第三通道創(chuàng)建子模塊，用于通過所述配置信息變更檢測任務創(chuàng)建所述服務端與更新后 的通知服務之間的事件通道。
全文摘要
本發(fā)明實施例公開了一種服務處理方法和裝置，其中服務處理方法包括公共對象請求代理結構服務端啟動后，該服務端啟動名字服務管理任務；在名字服務停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述服務管理任務將服務端的對象服務信息注冊到名字服務上。公共對象請求代理結構服務端裝置包括第一任務啟動模塊，用于在本服務端啟動后，啟動名字服務管理任務；第一服務管理模塊，用于在名字服務由停止服務狀態(tài)轉換為開始服務狀態(tài)后，通過所述名字服務管理任務將服務端的對象服務信息注冊到名字服務上。本發(fā)明實施例實現(xiàn)了在名字服務或通知服務出現(xiàn)異常時保證網(wǎng)絡的正常運營，減少了定位失敗和事件丟失。
文檔編號H04L12/24GK101895519SQ200910084760
公開日2010年11月24日 申請日期2009年5月19日 優(yōu)先權日2009年5月19日
發(fā)明者李翔, 蔣治華 申請人:華為技術有限公司