專利名稱：Soa在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法
技術領域：
本發(fā)明是對軟件架構概念面向服務的體系結構SOA (Service-Oriented Architecture)的一種具體實現(xiàn)，是一種理論架構的具體實現(xiàn)，為S0A在外圍系統(tǒng)訪問核心 支撐系統(tǒng)的實現(xiàn)方法。
背景技術：
統(tǒng)一接口平臺用來處理電信行業(yè)外圍系統(tǒng)對核心運營/支撐系統(tǒng)(B0SS/BSS/ 0SS)的接入和功能訪問。外圍接入系統(tǒng)包括客戶服務自動臺、網(wǎng)上營業(yè)廳、WAP網(wǎng)廳、短信 營業(yè)廳、掌上營業(yè)廳、掌中助理、空中寫卡、繳費卡繳費系統(tǒng)、銀行代繳費、SP系統(tǒng)、以及各種 代理商系統(tǒng)等等，外圍系統(tǒng)的特點是建設時間跨度大、接入技術雜、接入量大、接入并發(fā)度
高、管理難度大。行業(yè)內(nèi)原有的外圍接入支撐方法是針對不同的外圍系統(tǒng)、不同的接入技術在核心 功能域側建設不同的適配系統(tǒng)。適配的接入技術包括各種自定義/行業(yè)Socket協(xié)議、各種 自定義/行業(yè)WebService接口規(guī)范、各種基于HTTP協(xié)議的自定義接口、Tuxedo接口等，由 于適配系統(tǒng)和適配技術不斷增多，給渠道擴展、業(yè)務推廣、系統(tǒng)維護都帶來了很大難度，增 加了電信運營商的運營成本。隨著電信技術/業(yè)務的不斷發(fā)展、以及渠道的不斷豐富，需要 能對外圍系統(tǒng)的接入進行統(tǒng)一支撐和管理。

發(fā)明內(nèi)容
本發(fā)明要解決的技術問題是在電信行業(yè)的信息處理中實現(xiàn)S0A，解決外圍系統(tǒng) 到核心系統(tǒng)接入技術雜、接入量大、接入并發(fā)度高、管理難度大等問題。本發(fā)明的技術方案是S0A在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，在外圍系 統(tǒng)與支撐系統(tǒng)之間設置統(tǒng)一接口平臺UIP，UIP包括5個基礎組件和5個可獨立運行的子系 統(tǒng)5個基礎組件配置管理、連接管理、安全管理、線程管理、協(xié)議適配器；5個子系統(tǒng)接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)、監(jiān)控管理子系統(tǒng)、業(yè)務處 理子系統(tǒng)，子系統(tǒng)中使用基礎組件；通過JMS消息管理器將外圍系統(tǒng)接口調用過程劃分為接入處理、消息管理、接出 處理三個過程的異步處理方式，每個過程只要處理一種協(xié)議接入過程實現(xiàn)外圍系統(tǒng)和 JMS的消息轉換和交換，接收/加工外部消息，交給JMS消息管理器，從JMS管理器獲取應答 消息，返回給外圍系統(tǒng)，由接入子系統(tǒng)負責；消息管理JMS消息管理器負責UIP的消息管理，具體包括消息接收、消息存放存 放于內(nèi)存/文件/數(shù)據(jù)庫、消息生命周期管理過期消息將被刪除、消息優(yōu)先級管理、消息隊 列管理；接出過程實現(xiàn)JMS和核心支撐系統(tǒng)的消息轉換和交換，從JMS消息管理器獲取 /加工消息，訪問核心系統(tǒng)功能，加工核心系統(tǒng)返回的消息，交給JMS消息管理器，由接出子系統(tǒng)負責；UIP內(nèi)部流轉的數(shù)據(jù)是JMS消息，提供基于WebService和Socket協(xié)議族的接口規(guī) 范。UIP的異步處理機制通過實現(xiàn)兩方面的解耦處理外圍系統(tǒng)接入請求1)外圍系統(tǒng)接入?yún)f(xié)議和核心系統(tǒng)接口協(xié)議解耦；2)外圍系統(tǒng)接入客戶端數(shù)/請求量和核心系統(tǒng)允許并發(fā)數(shù)/處理能力解耦。接入子系統(tǒng)實現(xiàn)HTTP、Socket協(xié)議的Server功能，負責監(jiān)聽外圍系統(tǒng)接入請求 和接收請求數(shù)據(jù)，并將外圍系統(tǒng)發(fā)給UIP的SOAP消息包、Socket數(shù)據(jù)包轉換成UIP標準消 息包；UIP標準消息包為由XML結構組織的數(shù)據(jù)包，UIP內(nèi)流轉的消息都采用UIP標準消息 包，也就是JMS消息都采用UIP標準消息包的形式，消息包包括包頭和包體兩部分包頭部 分的字段名和字段數(shù)固定不變，包括UIP消息內(nèi)部管理使用的信息和業(yè)務管理使用的基礎 信息；包體部分是與具體功能接口相關的字段，不同的功能接口字段數(shù)量和字段名稱不同， 報文體根據(jù)需要靈活定義。接出子系統(tǒng)實現(xiàn)通用客戶端功能，UIP的協(xié)議適配器定義消息轉換接口和通用客 戶端接口，由協(xié)議插件實現(xiàn)所述接口，接出子系統(tǒng)通過不同的協(xié)議插件實現(xiàn)對不同核心支 撐系統(tǒng)的出訪。UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的 通用線程池、Socket連接池、J0LT連接池、JMS消息。優(yōu)選使用ActiveMQ進行JMS消息管理。本發(fā)明在外圍系統(tǒng)與支撐系統(tǒng)之間設置統(tǒng)一接口平臺UIP(Uniform InterfacePlatform)，外圍系統(tǒng)訪問核心系統(tǒng)時，外圍系統(tǒng)的接入?yún)f(xié)議可能是WebServie、 某種自定義Socket、HTTP等；核心系統(tǒng)提供的可能是Tuxedo、JDBC、自定義Socket、自定義 WebService, FTP等。以往核心系統(tǒng)的接口適配系統(tǒng)以同步方式解決外圍系統(tǒng)和核心系統(tǒng) 在種協(xié)議和請求量的對接，不僅系統(tǒng)復用性差，并發(fā)性高接入量大時系統(tǒng)穩(wěn)定性差。本發(fā)明 采用異步處理的方式，UIP通過消息JMS消息管理器將外圍系統(tǒng)接口調用過程劃分為接入 處理和接出處理，每個過程只要處理一種協(xié)議，與以往系統(tǒng)架構相比處理過程簡潔高效，且 各過程只管理自己的連接，良好的動態(tài)伸縮性能保證外圍接入并發(fā)高、請求量大的情況。本發(fā)明帶來的有益效果及實現(xiàn)方式如下1)、降低核心功能域對外提供新接口功能的成本。只要實現(xiàn)UIP接出子系統(tǒng)對核心系統(tǒng)功能的訪問，在UIP接入子系統(tǒng)只需注冊和 發(fā)布該接口，外圍系統(tǒng)即可基于UIP接入子系統(tǒng)支持的協(xié)議訪問該功能。而UIP接出子系 統(tǒng)如果是基于已有接出協(xié)議訪問核心系統(tǒng)，也只需要按照標準配置文件對核心系統(tǒng)功能進 行配置即可，不需要額外的編碼工作；2)、降低支持新接入/接出協(xié)議的成本。UIP將接口協(xié)議實現(xiàn)和接口業(yè)務描述相剝離，通過“協(xié)議適配器”基礎組件，我們只 需要開發(fā)相應協(xié)議的插件即可基于該協(xié)議實現(xiàn)UIP的接入或接出功能，即可基于該協(xié)議支 持已發(fā)布的接口功能；3)、提高外圍系統(tǒng)訪為核心系統(tǒng)時的穩(wěn)定性。UIP通過消息管理器將傳統(tǒng)的接口調用過程解耦為接入過程和接出過程，接入過程只負責處理接入?yún)f(xié)議、報文處理、連接管理等工作，接出過程只負責接出協(xié)議、報文處理、 連接管理等工作。實現(xiàn)接入?yún)f(xié)議、消息格式、連接管理的解耦。大大降低了系統(tǒng)的復雜度， 從而從基本架構上奠定了系統(tǒng)穩(wěn)定的基礎。UIP通過基礎組件實現(xiàn)了系統(tǒng)動態(tài)伸縮性、運行 時的動態(tài)配置管理功能，提高了外圍請求并發(fā)量、請求量突發(fā)激增時的系統(tǒng)穩(wěn)定性；4)、降低維護成本。UIP基礎組件和各運行子系統(tǒng)提供了監(jiān)控/管理接口，通過UIP的監(jiān)控/管理子系 統(tǒng)可方便監(jiān)控系統(tǒng)各部分的運行狀況，可快速診斷、定位問題。同時UIP提供運行時管理功 能，可動態(tài)調整系統(tǒng)參數(shù)、增加/減少運行單元，而不用中斷系統(tǒng)運行，從而提高電信運營 商的運營支撐質量，降低運營成本；5)、提高對外圍系統(tǒng)運營的統(tǒng)計分析功能，從而有效支撐了電信運營商的精細化 運營。UIP對外圍系統(tǒng)的接口調用信息進行詳細記錄，內(nèi)容包括接入渠道、接口名稱、調用結 果(成功/失敗)、接口調用時長、電話號碼、用戶品牌等。通過分析這些信息電信運營商可 以了解各外圍系統(tǒng)的業(yè)務開展情況，進而對外圍系統(tǒng)將來的發(fā)展情況進行規(guī)劃，以更好的 支撐業(yè)務推廣和發(fā)展；通過對電話客戶的分析，可對不同屬性的客戶劃分成客戶群，進而制 定針對不同客戶群的營銷方案，提高運營質量。與現(xiàn)有的外圍系統(tǒng)訪問核心系統(tǒng)的方法相比，本發(fā)明的特點在1)、把接口調用拆分成接入、接出兩個過程，將外圍系統(tǒng)和核心系統(tǒng)解耦，降低系 統(tǒng)復雜度、提高系統(tǒng)穩(wěn)定性?，F(xiàn)有外圍系統(tǒng)一般以同步方式實現(xiàn)對核心系統(tǒng)的訪問，這種方式在外圍系統(tǒng)并發(fā) 量、請求量突發(fā)增大的情況下，系統(tǒng)穩(wěn)定性差；通過在外圍系統(tǒng)和核心系統(tǒng)之間架構UIP， 將調用過程拆分成接入、接出兩個過程，接入過程只處理外圍系統(tǒng)的接入處理，接出過程只 處理對核心系統(tǒng)的功能訪問，兩者通過JMS消息管理器銜接起來。2)、提高了接口開發(fā)速度，降低項目實施周期，提高客戶需求響應速度。以往外圍系統(tǒng)訪問核心系統(tǒng)時，往往針對不同的接入?yún)f(xié)議，在核心系統(tǒng)側需要開 發(fā)不同的接口適配系統(tǒng)，這種方式不僅開發(fā)工作量大、開發(fā)周期長，而且系統(tǒng)的復用性差， 有時增加一個新接口就需要大量的開發(fā)工作；UIP實現(xiàn)了電信行業(yè)主要的協(xié)議和接口標 準，支持新的外圍接入時只需要開發(fā)協(xié)議插件即可，提供新的接口功能時，只需要進行一些 配置工作，實現(xiàn)功能的注冊、發(fā)布即可。3)、提高了外圍系統(tǒng)訪問核心系統(tǒng)的可監(jiān)控、維護性。以往外圍系統(tǒng)訪問核心系統(tǒng)時，缺乏完善的監(jiān)控手段，沒有監(jiān)控界面、日志信息， 更沒有管理功能，維護難度較大，問題診斷/定位周期較長；UIP各基礎組件和運行子系統(tǒng) 都提供了完善的監(jiān)控/管理接口，提供日志信息、前臺監(jiān)控/管理界面等多種監(jiān)控/管理手 段，從而大大降低了診斷/定位問題的時間。4)、實現(xiàn)對外圍系統(tǒng)訪問核心系統(tǒng)的統(tǒng)計分析功能。以往外圍系統(tǒng)訪問核心系統(tǒng)時只簡單記錄了接口調用日志，且分散在不同的數(shù)據(jù) 表中，沒有提供相應的統(tǒng)計分析功能，電信運營商從核心系統(tǒng)的接口管理層面基本了解不 到各外圍系統(tǒng)的運營情況。UIP以統(tǒng)一的格式記錄了各外圍系統(tǒng)對核心系統(tǒng)的訪問情況古， 可進行多種緯度的統(tǒng)計/分析。


圖1為本發(fā)明的結構示意圖。圖2是本發(fā)明UIP系統(tǒng)架構圖。圖3是本發(fā)明UIP工作流程圖。圖4是本發(fā)明協(xié)議適器解析協(xié)議消息流程圖。圖5是本發(fā)明協(xié)議適配器組裝UIP標準消息流程圖。
具體實施例方式本發(fā)明實現(xiàn)了外圍接入系統(tǒng)和核心支撐系統(tǒng)的解耦，外圍系統(tǒng)看到的只是一個統(tǒng) 一的服務提供者，不需要知道內(nèi)部實現(xiàn)；本發(fā)明內(nèi)部使用消息管理器JMS對接入過程和接 出過程進行解耦，JMS為JAVA消息服務(Java Message Service)，以異步方式實現(xiàn)外圍系 統(tǒng)對核心支撐系統(tǒng)訪問的處理過程，有效處理接入量大、并發(fā)高的外圍接入請求；本發(fā)明使 用協(xié)議適配器對UIP消息處理過程和具體協(xié)議實現(xiàn)解耦，使UIP能更好的支持不同協(xié)議，適 應電信行業(yè)要求。如圖1，本發(fā)明在外圍系統(tǒng)與支撐系統(tǒng)之間設置統(tǒng)一接口平臺UIP，UIP包括5個 基礎組件和5個可獨立運行的子系統(tǒng)5個基礎組件配置管理、連接管理、安全管理、線程管理、協(xié)議適配器；5個子系統(tǒng)接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)、監(jiān)控管理子系統(tǒng)、業(yè)務處 理子系統(tǒng)，子系統(tǒng)中使用基礎組件；通過JMS消息管理器將外圍系統(tǒng)接口調用過程劃分為接入處理、消息管理、接出 處理三個過程的異步處理方式，每個過程只要處理一種協(xié)議接入過程實現(xiàn)外圍系統(tǒng)和JMS的消息轉換和交換，接收/加工外部消息，交給 JMS消息管理器，從JMS管理器獲取應答消息，返回給外圍系統(tǒng)，由接入子系統(tǒng)負責；消息管理JMS消息管理器負責UIP的消息管理；具體包括消息接收、消息存放 存放于內(nèi)存/文件/數(shù)據(jù)庫、消息生命周期管理過期消息將被刪除、消息優(yōu)先級管理、消息 隊列管理；接出過程實現(xiàn)JMS和核心支撐系統(tǒng)的消息轉換和交換，從JMS消息管理器獲取 /加工消息，訪問核心系統(tǒng)功能，加工核心系統(tǒng)返回的消息，交給JMS消息管理器，由接出子 系統(tǒng)負責；UIP內(nèi)部流轉的數(shù)據(jù)是JMS消息，提供基于WebService和Socket協(xié)議族的接口規(guī) 范。UIP的異步處理機制通過實現(xiàn)兩方面的解耦處理外圍系統(tǒng)接入請求1)外圍系統(tǒng)接入?yún)f(xié)議和核心系統(tǒng)接口協(xié)議解耦；2)外圍系統(tǒng)接入客戶端數(shù)/請求量和核心系統(tǒng)允許并發(fā)數(shù)/處理能力解耦。接入子系統(tǒng)實現(xiàn)HTTP、Socket協(xié)議的Server功能，負責監(jiān)聽外圍系統(tǒng)接入請求和 接收請求數(shù)據(jù)，并將外圍系統(tǒng)發(fā)給UIP的SOAP消息包、Socket數(shù)據(jù)包轉換成UIP標準消息 包。UIP標準消息包為由XML結構組織的數(shù)據(jù)包，UIP內(nèi)流轉的消息都采用UIP標準消息 包，也就是JMS消息都采用UIP標準消息包的形式，消息包包括包頭和包體兩部分包頭部 分的字段名和字段數(shù)固定不變，包括UIP消息內(nèi)部管理使用的信息和業(yè)務管理使用的基礎信息；包體部分是與具體功能接口相關的字段，不同的功能接口字段數(shù)量和字段名稱不同， 報文體根據(jù)需要靈活定義。接出子系統(tǒng)實現(xiàn)通用客戶端功能，UIP的協(xié)議適配器定義消息轉換接口和通用客 戶端接口，由協(xié)議插件實現(xiàn)所述接口，接出子系統(tǒng)通過不同的協(xié)議插件實現(xiàn)對不同核心支 撐系統(tǒng)的出訪。UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的 通用線程池、Socket連接池、JOLT連接池、JMS消息。這里說的“監(jiān)控/管理”是UIP的監(jiān) 控管理子系統(tǒng)的智能。接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)三部分構成了 UIP的核心架構，UIP監(jiān)控 管理子系統(tǒng)負責對這三個核心架構子系統(tǒng)中的連接池、線程池、JMS收發(fā)/積壓情況等進行 監(jiān)控和管理。這里說的監(jiān)控和管理是對消息管理器的監(jiān)控/管理，其中集成了 JMS消息管 理對JMS消息管理的部分功能，比如刪除過期消息、生成一個消息發(fā)到某個消息隊列等。本發(fā)明中，JMS消息管理器使用JMS規(guī)范的一種具體實現(xiàn)產(chǎn)品ActiveMQ進行消息 管理。下面結合附圖具體說明本發(fā)明。圖2是本發(fā)明UIP系統(tǒng)架構圖，可分為三部分1)右側“UIP自定義Socket”、“HTTP (WebService) ”代表外圍系統(tǒng)接入；2)左側“客服系統(tǒng)”、“核心運營支撐系統(tǒng)”、“DB”代表核心系統(tǒng)；3)中間描述UIP架構;UIP包括5個基礎組件和5個可獨立運行的子系統(tǒng)5個基礎組件配置管理、連接管理、安全管理、線程管理、協(xié)議適配器5個子系統(tǒng)接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)、監(jiān)控管理子系統(tǒng)、業(yè)務處 理子系統(tǒng)，子系統(tǒng)中使用基礎組件。圖3是本發(fā)明UIP工作流程圖，描述了一個調用過程中外圍系統(tǒng)、UIP、核心系統(tǒng)三 者的工作過程，主要描述了 UIP內(nèi)部工作過程。圖2的頂部描述了 5個角色外圍系統(tǒng)、UIP 接入子系統(tǒng)、ESBQMS消息管理器)、UIP接出子系統(tǒng)，核心系統(tǒng)，其中“UIP接入子系統(tǒng)”、 “UIP接出子系統(tǒng)”描述了接入處理、接出處理的處理過程，描述了在各自子系統(tǒng)內(nèi)同步方式 和異步方式兩種處理模式，其中紅色部分為異步方式時由單獨執(zhí)行單元執(zhí)行。接入子系統(tǒng)同步處理往JMS消息管理器發(fā)送消息后在對應的應答消息隊列上等 待消息返回。消息的發(fā)送和接收以同步方式順序執(zhí)行完成；接入子系統(tǒng)異步處理往JMS消息管理器發(fā)送消息后該流程即結束，該過程一般 為多線程方式，另一流程專門守護應答隊列，有消息即獲取，然后找到與該消息對應的客戶 端連接，將該消息返回給外圍系統(tǒng)，該過程為單線程方式；接出子系統(tǒng)同步處理將請求消息發(fā)給核心系統(tǒng)后等待核心系統(tǒng)的應答返回；接出子系統(tǒng)異步處理將請求消息發(fā)給核心系統(tǒng)后該流程即結束，該過程一般為 多線程方式，由另一流程專門守護與核心系統(tǒng)的接收連接，該過程一般為單線程方式，接收 所有應答消息，經(jīng)過處理后發(fā)往JMS消息管理器；圖4是本發(fā)明協(xié)議適器解析協(xié)議消息流程圖1).解析消息，獲取接收到的消息的總長度(A長度)；
8
2).根據(jù)接口編碼計算接口配置信息中所有字段的總長度(P長度)，校驗A長度 和P長度是否相等，以驗證消息長度是否合法；3).如果總長度不合法則異常結束，如果總長度合法則根據(jù)接口編碼獲取接口各 字段的配置信息，主要是字段值最大允許字節(jié)長度，對消息進行解析，并校驗各字段數(shù)據(jù)的 合法性；4).如果有字段數(shù)據(jù)不合法則異常結束，如果消息正常解析完則將解析出的數(shù)據(jù) 存放到中間容器中，解析過程結束。圖5是本發(fā)明協(xié)議適配器組裝UIP標準消息流程圖1).根據(jù)接口編碼獲取該接口的配置信息； 2).根據(jù)接口配置信息，將存放在中間容器中的數(shù)據(jù)封裝成UIP標準消息。外圍系統(tǒng)訪問核心系統(tǒng)時實現(xiàn)S0A的過程可分為三個過程1)對核心系統(tǒng)功能的 組織；2)接口服務在UIP中的注冊和發(fā)布；3)外圍系統(tǒng)對所發(fā)布服務的訪問。詳細步驟如 下a.開發(fā)UIP接出子系統(tǒng)訪問不同核心系統(tǒng)所需要的協(xié)議插件，實現(xiàn)核心系統(tǒng)消息 格式和標準UIP平臺消息的相互轉化，并實現(xiàn)UIP接出子系統(tǒng)和UIP JMS消息管理器基于 UIP標準格式消息的消息交互，從而實現(xiàn)UIP對核心系統(tǒng)功能的組織；UIP是開放式系統(tǒng)架 構，通過協(xié)議適配器可實現(xiàn)不同協(xié)議的插件。了解UIP結構后，本領域技術人員可設計自己 的協(xié)議技術規(guī)范和協(xié)議插件。b.開發(fā)UIP-WebService協(xié)議和UlP-Socket協(xié)議，本發(fā)明的一個協(xié)議的具體實施 例見后面的“UIP接口技術規(guī)范”，實現(xiàn)UIP發(fā)布服務的標準協(xié)議和服務接口規(guī)范；S0A — 般以WebService接口作為服務發(fā)布的標準接口，但考慮到電信行業(yè)特點，存在為數(shù)眾多 的Socket協(xié)議和其他協(xié)議的外圍系統(tǒng)，因此UIP除了提供UIP-WebService外還提供了 UlP-Socket，此外，還可開發(fā)針對其他協(xié)議的協(xié)議插件；c.在UIP接入子系統(tǒng)中，將UIP接出子系統(tǒng)中已組織的核心系統(tǒng)功能的輸入/輸 出業(yè)務要素配置成標準的接口配置文件，該標準的接口配置文件的內(nèi)容以XML格式組織， UIP-WebService協(xié)議和UlP-Socket協(xié)議都可以解析；d.在UIP中注冊已配置好的接口，將接口名稱注冊到接口功能參數(shù)表，狀態(tài)字段 為未發(fā)布；e.在UIP中發(fā)布已注冊好的接口，將接口功能參數(shù)表中的狀態(tài)字段改為已發(fā)布狀 態(tài)；此外，還可以在UIP中登記外圍系統(tǒng)的信息，并對外圍系統(tǒng)允許調用的接口分配該外圍 系統(tǒng)，只有分配到該外圍系統(tǒng)下的權限該外圍系統(tǒng)才可以調用，以此實現(xiàn)安全性控制；f.將UIP接口規(guī)范(技術規(guī)范和業(yè)務規(guī)范)和接口服務發(fā)布地址公布給外圍系 統(tǒng)，外圍系統(tǒng)依據(jù)接口規(guī)范開發(fā)自己程序，調用UIP發(fā)布出來的接口服務。以UIP-WebService接口規(guī)范為例，描述外圍系統(tǒng)通過UIP訪問核心系統(tǒng)“余額查 詢”功能的S0A具體實現(xiàn)過程1.外圍系統(tǒng)將按照UIP-WebService組織好的“余額查詢”消息發(fā)送給UIP接入子 系統(tǒng)；2. UIP接入子系統(tǒng)接收到該報文后，獲取接口報文中的接口編碼和外圍系統(tǒng)編碼， 校驗該接口是否已發(fā)布，校驗該外圍系統(tǒng)是否有調用該接口的權限，如果校驗通過，根據(jù)接口編碼獲取“余額查詢”的接口配置信息，對接口報文的合法性進行校驗，然后將消息封裝 成JMS消息發(fā)往JMS消息管理器的特定消息隊列，并在對應的應答隊列等待應答消息返 回；3.接出子系統(tǒng)從JMS消息管理器的特定消息隊列獲取JMS消息，從中解析出“余 額查詢”的UIP標準消息，根據(jù)“余額查詢”的接口編碼和UIP接出子系統(tǒng)對核心系統(tǒng)功能 的組織規(guī)則，使用對應的接出子系統(tǒng)使用的接出協(xié)議處理器將UIP標準消息轉化成核心系 統(tǒng)要求的消息格式，發(fā)往核心系統(tǒng)，等待核心系統(tǒng)返回應答消息；4.接出子系統(tǒng)接收到核心系統(tǒng)返回的應答消息后，使用相同的接出協(xié)議處理器將 核心系統(tǒng)的消息格式轉換成UIP標準消息，封裝成JMS消息發(fā)往JMS消息管理的特定應答 消息隊列；5接入子系統(tǒng)從JMS消息管理器的應答隊列中獲取JMS消息后，從中解析出UIP標 準消息，返回給外圍系統(tǒng)。UIP接口技術規(guī)范包括基于HTTP協(xié)議的UIP WebService接口規(guī)范和基于TCP/IP 協(xié)議的UIP Socket技術規(guī)范，這兩個規(guī)范彼此獨立，分別用于規(guī)定基于HTTP協(xié)議和TCP/IP 協(xié)議接入UIP的接口標準。這兩個接口規(guī)范有一定的共性，接口標準都分為包頭和包體兩部分，包頭部分的 字段名和字段數(shù)固定不變，包括包信息說明和業(yè)務管理使用的基礎信息；包體部分是與具 體功能接口相關的字段，不同的功能接口字段數(shù)量和字段名稱不同，包體可根據(jù)需要靈活定義。UIP WebService接口規(guī)范使用XML結構組織包數(shù)據(jù)的接口標準。實際數(shù)據(jù)包中 每個字段都有對應的邏輯字段名稱，可基于邏輯字段名解析出對應字段值。包數(shù)據(jù)一般采 用UTF-8編碼?？蛻舳伺cUIP之間采用短連接。UIP Socket接口規(guī)范由數(shù)據(jù)串組成的數(shù)據(jù)包，包頭定長，包體變長，包體字段數(shù) 據(jù)間、記錄數(shù)據(jù)間使用分隔符進行分隔。實際包中一般沒有字段邏輯名，只有字段值?？蛻?端和UIP之間可采用長連接或短連接。WebService 接 口規(guī)范WSDL 文件WS接口描述文件內(nèi)容如下所示< ？ xml version = " 1.0" encoding = 〃 UTF-8" ？ ><wsdl:definitions xmlns:soap = " http://schemas.xmlsoap.org/wsdl/ soap/"xmlns :tns = " http://www.linkage.com/UIP/"xmlns:wsdl = " http://schemas.xmlsoap.org/wsdl/"xmlns:xsd = " http://www.w3.org/2001/XMLSchema" name = 〃 UIP"targetNamespace = " http://www.linkage.com/UIP/" ><wsdl: types)<xsd:schema targetNamespace = " http://www.linkage.com/UIP/" ><xsd:element name = " businessCallRequest" ><xsd:complexType>
10
<xsd: sequence)<xsd: element name = “ svcCode “ type =〃 xsd: string/r /><xsd:element name =" requestMessage"type = /r xsd: string/r /></xsd: sequence)</xsd: complexType></xsd: element)</xsd: schema〉</wsdl: types)<wsdl :message name =〃 businessCallRequest 〃 ><wsdl :part element =" tns: businessCalIRequest “name = “ businessCallRequest" /></wsdl: message〉<wsdl:message name = “ businessCallResponse“ ><wsdl :part type =〃 xsd: string" name =〃 businessCallResponse “ /></wsdl: message〉<wsdl:portType name =" UIP" ><wsdl: operation name =〃 businessCal 1 〃 ><wsdl: input message =〃 tns: businessCal IRequest “ /><wsdl: output message =" tns: businessCalIResponse “ /></wsdl: operation〉</wsdl: portType>〈wsdl:binding name =" UIPS0AP" type = " tns:UIP" >〈soap:binding style =" document"transport =" http://schemas. xmlsoap. org/soap/http" />〈wsdl: operation name =〃 businessCall 〃 >〈soap: operation/)<wsdl: input)〈soap:body use = " literal" /></wsdl: input)〈wsdl: output〉〈soap:body use = " literal" />〈/wsdl: output〉〈/wsdl: operation〉〈/wsdl: binding〉〈wsdl: service name =〃 UIP〃 >〈wsdl :port binding =" tns:UIPS0AP" name = " UIPS0AP" >〈soap: address
location = “ http://130. 34. 4. 4:17001/uip_inws/ services/UIPSOAP" /></wsdl:port></wsdl:service)</wsdl:definitions)WebService 接口地址根據(jù)UIP實際部署環(huán)境確定。服務接口及接口方法說明服務入口UIP服務入口方法businessCallString businessCall(BusinessCallRequest businessCallRequest)請求參數(shù)businessCallRequest包括一個服務名稱、服務輸入?yún)?shù)，服務要求的 輸入?yún)?shù)見UIP WebService報文結構。返回參數(shù)為一 XML結構字符串，參見UIP WebService報文結構。報文UIP WebService 報文結構 報文頭說明 X_TRANS_C0DE :UIP對外提供的服務編碼。
PR0VINCE_C0DE 省別編碼。
IN_M0DE_C0DE 接入類型編碼。
TRADE_EPARCHY_CODE 地州編碼。填寫實際地州編碼(依各省具體情況而定) 或 “INTF”。
TRADE_CITY_CODE 業(yè)務區(qū)編碼。
TRADE_DEPART_ID 部門編碼。
TRADE_STAFF_ID 員工編碼。
TRADE_DEPART_PASSWD 渠道密碼。密文形式，建議使用MD5加密。
R0UTE_EPARCHY_C0DE 預留字段。填寫為4個空格。
CHANNEL_TRADE_ID 外圍系統(tǒng)生成的流水號，用來唯一代表該請求消息。流水 號中的合法字符為W 9]。
X_RESULTC0DE 服務調用結果編碼。分為兩種情況，0 成功；非0 失敗(包括 系統(tǒng)錯、業(yè)務錯)。服務調用結果描述。
X_REC0RDNUM 結果記錄數(shù)。報文體說明1.實際運行時如果字段名為SERIALNUMBER，則內(nèi)存中FIELDNAME% >部分為 “<SERIALNUMBER> 13851802186</SERIALNUMBER>字段值一律使用 String 表示。2.目前只支持通過<FIELD>描述多條記錄，絕大多數(shù)的業(yè)務數(shù)據(jù)都可以通過這種 方式來描述。Socket 接口 規(guī)范通訊協(xié)議采用TCP/IP標準協(xié)議。外圍系統(tǒng)作為Socket Client,UIP作為Socket Server, Client向Server發(fā)送請求報文，Server向Client返回應答報文。請求報文由Client按照UIP Socket接口規(guī)范組織控制信息、業(yè)務信息形成的數(shù) 據(jù)包。應答報文由Server按照UIP Socket接口規(guī)范組織控制信息、業(yè)務信息形成的返 回數(shù)據(jù)包。報文統(tǒng)一采用UTF-8編碼方式。報文UIP Socket 報文結構報文頭定長，報文體變長。
報文頭報文頭組織規(guī)則報文頭字段定長。不足位，右補空格。報文頭字段說明 LENGTH:報文總長度。LENGTH =報文頭長度(149字節(jié))+報文體長度+包結束 符長度(1字節(jié)) VERSION :UIP Socekt 接 口 規(guī)范版本號。
CHANNEL_TRADE_ID 外圍系統(tǒng)生成的流水號，用來唯一代表該請求消息。流水 號中的合法字符為W 9]。
X_TRANS_C0DE :UIP對外提供的服務編碼。
PR0VINCE_C0DE 省別編碼。
IN_M0DE_C0DE 接入類型編碼。
TRADE_EPARCHY_CODE 地州編碼。填寫實際地州編碼(依各省具體情況而定) 或 “INTF”。
TRADE_CITY_CODE 業(yè)務區(qū)編碼。
TRADE_DEPART_ID 部門編碼。
TRADE_STAFF_ID 員工編碼。
TRADE_DEPART_PASSWD 渠道密碼。密文形式，建議使用MD5加密。
R0UTE_EPARCHY_C0DE 預留字段。填寫為4個空格。
CUR_N0 當前包編號。
T0TALNUM 總包數(shù)。
FLAG 請求/應答標識。如果是外圍系統(tǒng)發(fā)給UIP的請求包，置0 ；如果是UIP返回給外圍系統(tǒng)的應答包，置1。
RESULTC0DE 結果編碼。請求包為8個空格，應答包為具體結果編碼，0 成功， 非0 失敗(包括系統(tǒng)錯、業(yè)務錯)。報文體報文體組織規(guī)則存在多條請求記錄或返回記錄的業(yè)務，一個報文可包括多條記錄。一個報文總長度不超過20K，大于20K的業(yè)務數(shù)據(jù)應以多報文方式發(fā)送。如果調用成功報文體返回正常業(yè)務數(shù)據(jù)。如果調用失敗報文體返回錯誤信息(錯誤編碼存放在報文頭“結果編碼”字段)。 分割符字段分割符0x09 (TAB鍵)記錄分割符0x0a (換行)包結束符0xla數(shù)據(jù)格式規(guī)則時間字段以14位數(shù)據(jù)表示(如20081121203621)費用字段以分為單位連接UIP支持外圍系統(tǒng)以長連接、短連接兩種方式請求平臺服務。短連接Client (外圍系統(tǒng))每次請求Server (UIP)服務時首先建立到Server (UIP)的連 接，Server返回應答報文后關閉與Client之間的連接。長連接Client (外圍系統(tǒng))第一次請求Server (UIP)服務時建立到Server (UIP)的連接， Client后續(xù)請求Server服務時復用該連接。連接空閑超過指定時間(600秒)Client需要向Server發(fā)送心跳報文，以維持該 連接，Server收到心跳報文后向Client返回心跳應答報文。如果連接空閑時間超過(600 秒)，Server將關閉該連接。心跳報文的組織遵照UIP Socket接口規(guī)范，心跳命令字見附錄。
1權利要求
SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是在外圍系統(tǒng)與支撐系統(tǒng)之間設置統(tǒng)一接口平臺UIP，UIP包括5個基礎組件和5個可獨立運行的子系統(tǒng)5個基礎組件配置管理、連接管理、安全管理、線程管理、協(xié)議適配器；5個子系統(tǒng)接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)、監(jiān)控管理子系統(tǒng)、業(yè)務處理子系統(tǒng)，子系統(tǒng)中使用基礎組件；通過JMS消息管理器將外圍系統(tǒng)接口調用過程劃分為接入處理、消息管理、接出處理三個過程的異步處理方式，每個過程只要處理一種協(xié)議接入過程實現(xiàn)外圍系統(tǒng)和JMS的消息轉換和交換，接收/加工外部消息，交給JMS消息管理器，從JMS管理器獲取應答消息，返回給外圍系統(tǒng)，由接入子系統(tǒng)負責；消息管理JMS消息管理器負責UIP的消息管理，具體包括消息接收、消息存放存放于內(nèi)存/文件/數(shù)據(jù)庫、消息生命周期管理過期消息將被刪除、消息優(yōu)先級管理、消息隊列管理；接出過程實現(xiàn)JMS和核心支撐系統(tǒng)的消息轉換和交換，從JMS消息管理器獲取/加工消息，訪問核心系統(tǒng)功能，加工核心系統(tǒng)返回的消息，交給JMS消息管理器，由接出子系統(tǒng)負責；UIP內(nèi)部流轉的數(shù)據(jù)是JMS消息，提供基于WebService和Socket協(xié)議族的接口規(guī)范。
2.根據(jù)權利要求1所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是 UIP的異步處理機制通過實現(xiàn)兩方面的解耦處理外圍系統(tǒng)接入請求1)外圍系統(tǒng)接入?yún)f(xié)議和核心系統(tǒng)接口協(xié)議解耦；2)外圍系統(tǒng)接入客戶端數(shù)/請求量和核心系統(tǒng)允許并發(fā)數(shù)/處理能力解耦。
3.根據(jù)權利要求1或2所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征 是接入子系統(tǒng)實現(xiàn)HTTP、S0cket協(xié)議的Server功能，負責監(jiān)聽外圍系統(tǒng)接入請求和接收請 求數(shù)據(jù)，并將外圍系統(tǒng)發(fā)給UIP的SOAP消息包、Socket數(shù)據(jù)包轉換成UIP標準消息包；UIP 標準消息包為由XML結構組織的數(shù)據(jù)包，UIP內(nèi)流轉的消息都采用UIP標準消息包，也就是 JMS消息都采用UIP標準消息包的形式，消息包包括包頭和包體兩部分包頭部分的字段名 和字段數(shù)固定不變，包括UIP消息內(nèi)部管理使用的信息和業(yè)務管理使用的基礎信息；包體 部分是與具體功能接口相關的字段，不同的功能接口字段數(shù)量和字段名稱不同，報文體根 據(jù)需要靈活定義。
4.根據(jù)權利要求1或2所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征 是接出子系統(tǒng)實現(xiàn)通用客戶端功能，UIP的協(xié)議適配器定義消息轉換接口和通用客戶端接 口，由協(xié)議插件實現(xiàn)所述接口，接出子系統(tǒng)通過不同的協(xié)議插件實現(xiàn)對不同核心支撐系統(tǒng) 的出訪。
5.根據(jù)權利要求3所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是接 出子系統(tǒng)實現(xiàn)通用客戶端功能，UIP的協(xié)議適配器定義消息轉換接口和通用客戶端接口， 由協(xié)議插件實現(xiàn)所述接口，接出子系統(tǒng)通過不同的協(xié)議插件實現(xiàn)對不同核心支撐系統(tǒng)的出訪。
6.根據(jù)權利要求1或2所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征 是UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的通用線 程池、Socket連接池、JOLT連接池、JMS消息。
7.根據(jù)權利要求3所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是 UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的通用線程 池、Socket連接池、JOLT連接池、JMS消息。
8.根據(jù)權利要求4所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是 UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的通用線程 池、Socket連接池、JOLT連接池、JMS消息。
9.根據(jù)權利要求5所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征是 UIP的監(jiān)控管理子系統(tǒng)監(jiān)控/管理接入子系統(tǒng)、JMS消息管理器、接出子系統(tǒng)中的通用線程 池、Socket連接池、JOLT連接池、JMS消息。
10.根據(jù)權利要求1或2所述的SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，其特征 是使用ActiveMQ進行JMS消息管理。
全文摘要
SOA在外圍系統(tǒng)訪問核心支撐系統(tǒng)的實現(xiàn)方法，在外圍系統(tǒng)與支撐系統(tǒng)之間設置統(tǒng)一接口平臺UIP，UIP包括5個基礎組件和5個可獨立運行的子系統(tǒng)，將外圍系統(tǒng)接口調用過程劃分為接入處理、消息管理、接出處理三個過程的異步處理方式，每個過程只要處理一種協(xié)議。本發(fā)明降低了核心功能域對外提供新接口功能的成本，降低支持新接入/接出協(xié)議的成本，提高外圍系統(tǒng)訪為核心系統(tǒng)時的穩(wěn)定性，降低維護成本，提高對外圍系統(tǒng)運營的統(tǒng)計分析功能，從而有效支撐了電信運營商的精細化運營。
文檔編號G06Q10/00GK101854348SQ20101014024
公開日2010年10月6日 申請日期2010年4月2日 優(yōu)先權日2010年4月2日
發(fā)明者孫力斌, 張有根, 曹磊, 李華, 李曉東, 杭國民, 梁斌, 王紅亮 申請人:南京聯(lián)創(chuàng)科技集團股份有限公司