專利名稱：一種敏捷式高效分層服務(wù)器端的接口架構(gòu)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種軟件架構(gòu)，具體來說，涉及一種敏捷式高效分層服務(wù)器端的接口架構(gòu)。
背景技術(shù)：
隨著移動互聯(lián)網(wǎng)的發(fā)展，移動終端應(yīng)用軟件層出不群，且越來越多地開始依賴于服務(wù)器端進行個性化的信息存儲、獲取和交互，從而實現(xiàn)整體服務(wù)的信息安全、連續(xù)、可共孕、易整合和聞可用。基于以上背景，作為終端軟件信息支撐的服務(wù)器端軟件開始通過開發(fā)和開放對外接口的方式與終端軟件進行數(shù)據(jù)交互，搭建信息應(yīng)答平臺。而傳統(tǒng)的服務(wù)器端接口開發(fā)具 有如下問題
I.集中于處理協(xié)議層的解決方案，未形成可滿足業(yè)務(wù)層面的整體成熟的軟件架構(gòu)，重構(gòu)代價大、可擴展性低。不易測試和快速迭代、很難進行復雜的功能擴展。2.基于以上問題，目前上已有較成熟的軟件架構(gòu)可供選擇。如apache軟件基金會(ASF)贊助的開源項目struts2。Struts2是一個優(yōu)雅的、可擴展的web架構(gòu)。它采用MVC (模型-視圖-控制器，Model-View-Controller)模型,使得整體結(jié)構(gòu)更清晰，能夠靈活方便地進行功能擴展和快速迭代；將主處理Action (動作)設(shè)計為簡單的POJO (Plain Ordinary Java Object)普通Java對象，使得編寫測試用例更為方便快捷，提高測試的易實施性和效率。其整體架構(gòu)思路和工作流程如下
I.客戶端發(fā)送請求。2.請求先通過 ActionContextCleanUp (過濾器)至 FilterDispatcher (核心控制器)。3. FilterDispatcher通過ActionMapper(動作映射器)來匹配該請求(Request)需要調(diào)用的Action (動作)。4.若 ActionMapper 匹配到某個 Action, FilterDispatcher 把請求的處理交給ActionProxy (動作代理)。5. ActionProxy 根據(jù) ActionMapping和 Conf igurationManager (配置管理器)找到需要調(diào)用的Action類。6. ActionProxy 創(chuàng)建一個 ActionInvocation (動作調(diào)用)的實例。7. ActionInvocation調(diào)用真正的Action,并進行相關(guān)攔截器的調(diào)用。8. Action 執(zhí)行完畢，ActionInvocation 創(chuàng)建 Result (結(jié)果)并返回。但是，此種架構(gòu)存在如下問題
I.整體處理性能不夠理想。struts2將每個請求協(xié)議封裝成獨立對象；每個請求都需創(chuàng)建一個新的action去做邏輯處理，以實現(xiàn)線程安全；集成各種不同類型的返回結(jié)果；大量使用代理、正則表達式、反射等技術(shù)，雖然功能非常強大，易于開發(fā)，但是犧牲了運行效率。2.整體組織結(jié)構(gòu)比較復雜和臃腫，配置文件多而復雜，不便組織，維護起來比較繁瑣。3.對于底層協(xié)議封裝過多，不便于進行高效靈活的協(xié)議擴展。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題在于，針對現(xiàn)有架構(gòu)的不足，提供一種改進的敏捷式高效分層服務(wù)器端的接口架構(gòu)。為實現(xiàn)上述目的，本發(fā)明提出了一種敏捷式高效分層服務(wù)器端的接口架構(gòu)，其包括請求分發(fā)層，接收客戶端的請求；業(yè)務(wù)處理層，包括多個動作(Action)，所述業(yè)務(wù)處理層根據(jù)客戶端的請求通過其中至少一個動作進行具體業(yè)務(wù)處理，生成最終統(tǒng)一
精簡協(xié)議的結(jié)果(result)返回給客戶端；其中所述請求分發(fā)層包括servlet調(diào)度器(ServletDispatcher),接收客戶端請求，并根據(jù)請求協(xié)議類型，調(diào)用Get處理函數(shù)(doGet)/Post處理函數(shù)(doPost)對所述請求進行處理；動作調(diào)用者(ActionInvoker),注入到servlet調(diào)度器,所述動作調(diào)用者(ActionInvoker)負責請求與業(yè)務(wù)處理層中各個動作(Action)的匹配和分發(fā)調(diào)用；其中所述servlet是一種服務(wù)器端的Java應(yīng)用程序，是客戶端與服務(wù)器端的中間件，擔當客戶請求與服務(wù)器響應(yīng)的中間層。根據(jù)本發(fā)明的實施例，其中所述Get函數(shù)/Post函數(shù)同時調(diào)用處理方法統(tǒng)一進行后續(xù)分發(fā)。根據(jù)本發(fā)明的實施例，其中所述動作調(diào)用者用單例模式實現(xiàn)。根據(jù)本發(fā)明的實施例，其中所述動作調(diào)用者與業(yè)務(wù)處理層中各個動作的匹配和分發(fā)調(diào)用的具體操作為將匹配規(guī)則數(shù)據(jù)結(jié)構(gòu)路由策略注入到動作調(diào)用者動作調(diào)用器類中；其中路由策略以索引/值對的形式組建，為鍵值對對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，其中索引為客戶端請求的統(tǒng)一資源定位符，值為各動作實例。根據(jù)本發(fā)明的實施例，其中所述值根據(jù)類路徑使用反射原理實現(xiàn)實例化。根據(jù)本發(fā)明的實施例，其中所述業(yè)務(wù)處理層內(nèi)部使用繼承特性、模板模式和攔截器組合調(diào)用策略。根據(jù)本發(fā)明的實施例，其中所述業(yè)務(wù)處理層根據(jù)動作調(diào)用者的統(tǒng)一資源定位符，配置相應(yīng)的動作，該動作通過動作父類調(diào)用請求執(zhí)行函數(shù)，同時所述業(yè)務(wù)處理層為該動作配置相應(yīng)的攔截器棧并注入類中；各動作繼承動作父類，通過各自執(zhí)行方法負責具體業(yè)務(wù)邏輯的實現(xiàn)；動作父類提供回傳協(xié)議封裝方法和回傳結(jié)果包裝器，將協(xié)議統(tǒng)一封裝成精簡統(tǒng)一的json格式，供子動作調(diào)用；其中攔截器棧為由一系列實現(xiàn)可注入的動作攔截器接口的實例組合而成的攔截器列表。根據(jù)本發(fā)明的實施例，其中所述攔截器列表中各攔截器用單例模式實現(xiàn)。根據(jù)本發(fā)明的實施例，其中所述動作父類調(diào)用請求執(zhí)行函數(shù)的具體操作流程包括第一步，調(diào)用前置攔截器棧調(diào)用函數(shù)，以遍歷調(diào)用各攔截器棧實例的攔截器前置處理函數(shù)，執(zhí)行前置攔截，若所有結(jié)果都返回“真”，則進行第二步；反之，攔截斷裂，直接返回客戶端；第二步，調(diào)用執(zhí)行方法，以負責具體業(yè)務(wù)邏輯實現(xiàn)；第三步，調(diào)用攔截器后置函數(shù)，以遍歷調(diào)用攔截器棧實例的攔截器后置處理函數(shù)，執(zhí)行后置攔截；其中該流程采用模板模式設(shè)計組合。根據(jù)本發(fā)明的實施例，其中所述統(tǒng)一資源定位符與動作的配置以及動作與攔截器列表的配置均與開源的應(yīng)用程序架整合。本發(fā)明具有以下有益效果本發(fā)明敏捷式高效分層服務(wù)器端的接口架構(gòu)避免了由不同請求重復創(chuàng)建對象而引起的效率低下和內(nèi)存消耗問題，且具有便捷的邏輯處理和良好的響應(yīng)效率。


下面將結(jié)合附圖及實施例對本發(fā)明作進一步說明，附圖中
圖I為根據(jù)本發(fā)明一實施例的敏捷式高效分層服務(wù)器端的接口架構(gòu)示意圖。
具體實施方式
為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下面結(jié)合實施例和附圖，對本發(fā)明進一步詳細說明
圖I為根據(jù)本發(fā)明一實施例的一種敏捷式高效分層服務(wù)器端的接口架構(gòu)示意圖，所述接口架構(gòu)包括請求分發(fā)層100，接收客戶端的請求；業(yè)務(wù)處理層200，包括多個動作(Action)，所述業(yè)務(wù)處理層200根據(jù)客戶端的請求通過其中至少一個動作進行具體業(yè)務(wù)處理，生成最終統(tǒng)一精簡協(xié)議的結(jié)果(result)返回給客戶端；其中所述請求分發(fā)層包括servlet調(diào)度器(ServletDispatcher) 101,接收客戶端請求，并根據(jù)請求協(xié)議類型，調(diào)用Get處理函數(shù)(doGet)/Post處理函數(shù)(doPost)對請求進行處理；動作調(diào)用者(ActionInvoker) 102,注入到 servlet 調(diào)度器 101,所述動作調(diào)用者(ActionInvoker) 102負責請求與業(yè)務(wù)處理層200中各個動作(Action)的匹配和分發(fā)調(diào)用。其中所述servlet是一種服務(wù)器端的Java應(yīng)用程序，是客戶端與服務(wù)器端的中間件，擔當客戶請求(Web瀏覽器或其他HTTP客戶程序)與服務(wù)器響應(yīng)(HTTP服務(wù)器上的數(shù)據(jù)庫或應(yīng)用程序)的中間層。在一個實施例中，所述前置攔截器棧調(diào)用/后置攔截器棧調(diào)用同時調(diào)用處理(process)方法統(tǒng)一進行后續(xù)分發(fā)。在一個實施例中，所述動作調(diào)用者(ActionInvoker) 102用單例模式實現(xiàn)，以使整個工程生命周期只需創(chuàng)建一個實例，避免了由不同請求重復創(chuàng)建對象而引起的效率低下和內(nèi)存消耗問題。在一個實施例中，所述動作調(diào)用者(ActionInvoker) 102與業(yè)務(wù)處理層200中各個動作(Action)的匹配和分發(fā)調(diào)用的具體操作為將匹配規(guī)則數(shù)據(jù)結(jié)構(gòu)路由策略CrouteMap )注入到動作調(diào)用者(ActionInvoker)類中；其中路由策略(routeMap)以索弓丨(key)/值(value)對的形式組建，為鍵值對對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，其中索引(key)為客戶端請求的統(tǒng)一資源定位符(url),值(value)為各動作(Action)實例。S卩，動作調(diào)用者(ActionInvoker) 102根據(jù)路由策略(routeMap)的配置規(guī)則，按不同的統(tǒng)一資源定位符(url)匹配生成不同的動作(Action)實例,其中每個統(tǒng)一資源定位符(url)對應(yīng)一種業(yè)務(wù)邏輯，相應(yīng)對應(yīng)一個動作(Action),所述動作(Action)實例使用單例模式生成。如下表I為路由策略(routeMap)的數(shù)據(jù)結(jié)構(gòu)視圖
權(quán)利要求
1.一種敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，其包括 請求分發(fā)層，接收客戶端的請求； 業(yè)務(wù)處理層，包括多個動作，所述業(yè)務(wù)處理層根據(jù)客戶端的請求通過其中至少一個動作進行具體業(yè)務(wù)處理，生成最終統(tǒng)一精簡協(xié)議的結(jié)果返回給客戶端；其中所述請求分發(fā)層包括 servlet調(diào)度器，接收客戶端請求，并根據(jù)請求協(xié)議類型，調(diào)用Get處理函數(shù)/Post處理函數(shù)對所述請求進行處理；其中所述servlet是一種服務(wù)器端的Java應(yīng)用程序，是客戶端與服務(wù)器端的中間件，擔當客戶請求與服務(wù)器響應(yīng)的中間層； 動作調(diào)用者，注入到servlet調(diào)度器，所述動作調(diào)用者負責請求與業(yè)務(wù)處理層中各個動作的匹配和分發(fā)調(diào)用。
2.如權(quán)利要求I所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述Get函數(shù)/Post函數(shù)同時調(diào)用處理方法統(tǒng)一進行后續(xù)分發(fā)。
3.如權(quán)利要求I所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述動作調(diào)用者用單例模式實現(xiàn)。
4.如權(quán)利要求I所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述動作調(diào)用者與業(yè)務(wù)處理層中各個動作的匹配和分發(fā)調(diào)用的具體操作為將匹配規(guī)則數(shù)據(jù)結(jié)構(gòu)路由策略注入到動作調(diào)用者動作調(diào)用器類中；其中路由策略以索引/值對的形式組建，為鍵值對對應(yīng)的數(shù)據(jù)結(jié)構(gòu)，其中索引為客戶端請求的統(tǒng)一資源定位符，值為各動作實例。
5.如權(quán)利要求4所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述值根據(jù)類路徑使用反射原理實現(xiàn)實例化。
6.如權(quán)利要求4所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述業(yè)務(wù)處理層內(nèi)部使用繼承特性、模板模式和攔截器組合調(diào)用策略。
7.如權(quán)利要求6所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于， 所述業(yè)務(wù)處理層根據(jù)動作調(diào)用者的統(tǒng)一資源定位符，配置相應(yīng)的動作，該動作通過動作父類調(diào)用請求執(zhí)行函數(shù)，同時所述業(yè)務(wù)處理層為該動作配置相應(yīng)的攔截器棧并注入類中； 各動作繼承動作父類，通過各自執(zhí)行方法負責具體業(yè)務(wù)邏輯的實現(xiàn)；動作父類提供回傳協(xié)議封裝方法和回傳結(jié)果包裝器，將協(xié)議統(tǒng)一封裝成精簡統(tǒng)一的json格式，供子動作調(diào)用；其中 攔截器棧為由一系列實現(xiàn)可注入的動作攔截器接口的實例組合而成的攔截器列表。
8.如權(quán)利要求7所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述攔截器列表中各攔截器用單例模式實現(xiàn)。
9.如權(quán)利要求7所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述動作父類調(diào)用請求執(zhí)行函數(shù)的具體操作流程包括 第一步，調(diào)用前置攔截器棧調(diào)用函數(shù)，以遍歷調(diào)用各攔截器棧實例的攔截器前置處理函數(shù)，執(zhí)行前置攔截，若所有結(jié)果都返回“真”，則進行第二步；反之，攔截斷裂，直接返回客戶端； 第二步，調(diào)用執(zhí)行方法，以負責具體業(yè)務(wù)邏輯實現(xiàn)； 第三步，調(diào)用攔截器后置函數(shù)，以遍歷調(diào)用攔截器棧實例的攔截器后置處理函數(shù)，執(zhí)行后置攔截；其中 該流程采用模板模式設(shè)計組合。
10.如權(quán)利要求7所述的敏捷式高效分層服務(wù)器端的接口架構(gòu)，其特征在于，所述統(tǒng)一資源定位符與動作的配置以及動作與攔截器列表的配置均與開源的應(yīng)用程序架整合。
全文摘要
本發(fā)明公開了一種敏捷式高效分層服務(wù)器端的接口架構(gòu)，其包括請求分發(fā)層，接收客戶端的請求；業(yè)務(wù)處理層，包括多個動作，所述業(yè)務(wù)處理層根據(jù)客戶端的請求通過其中至少一個動作進行具體業(yè)務(wù)處理，生成最終統(tǒng)一精簡協(xié)議的結(jié)果返回給客戶端；其中所述請求分發(fā)層包括servlet調(diào)度器，接收客戶端請求，并根據(jù)請求協(xié)議類型，調(diào)用Get處理函數(shù)/Post處理函數(shù)對所述請求進行處理；動作調(diào)用者，注入到servlet調(diào)度器，所述動作調(diào)用者負責請求與業(yè)務(wù)處理層中各個動作的匹配和分發(fā)調(diào)用。該服務(wù)器端的接口架構(gòu)避免了由不同請求重復創(chuàng)建對象而引起的效率低下和內(nèi)存消耗問題，且具有便捷的邏輯處理和良好的響應(yīng)效率。
文檔編號G06F9/44GK102799424SQ20121019143
公開日2012年11月28日 申請日期2012年6月12日 優(yōu)先權(quán)日2012年6月12日
發(fā)明者劉濤 申請人:上海雷騰軟件有限公司