專利名稱：一種應用服務平臺系統(tǒng)和一種開發(fā)應用服務的方法
技術(shù)領域：
本發(fā)明涉及后臺服務開發(fā)領域，特別是涉及一種應用服務平臺系統(tǒng)和一種開發(fā)應用服務的方法。
背景技術(shù)：
在后臺服務開發(fā)領域，大部分互聯(lián)網(wǎng)應用和企業(yè)應用都會遇到系統(tǒng)規(guī)模變得日益復雜，并且系統(tǒng)規(guī)模日益增大后，開發(fā)成本和運維成本都急劇增高。本發(fā)明致力于降低應用開發(fā)難度，提高部署的靈活性并降低部署的難度。

發(fā)明內(nèi)容
本發(fā)明提供了一種應用服務平臺系統(tǒng)，該系統(tǒng)降低了應用開的難度，提高了部署的靈活性并降低了部署的難度。本發(fā)明還提供了一種開發(fā)應用服務平臺的方法。為達到上述目的，本發(fā)明的技術(shù)方案是這樣實現(xiàn)的本發(fā)明公開了一種應用服務平臺系統(tǒng)，該系統(tǒng)包括代理服務器、由多個應用服務器組成的服務器集群、中心服務器和資源服務器，其中代理服務器，用于接收客戶端請求消息，通過查詢中心服務器上的應用服務配置信息列表識別該客戶端請求消息所對應的應用服務，然后通過查詢中心服務器上的應用服務配置信息列表和應用服務運行信息列表獲得對應的應用服務的路徑，根據(jù)所獲得的路徑將客戶端請求消息分發(fā)給對應的應用服務所在的應用服務器；接收應用服務器端返回的處理結(jié)果，并返回給客戶端；其中，應用服務配置信息列表包括如下信息應用服務ID、應用服務名稱、應用服務類型、應用進程名、應用服務元數(shù)據(jù)標注；應用服務運行列表包括如下信息應用進程名稱、應用服務路徑；每個應用服務器，用于負載應用服務并運行，將應用服務的運行信息寫入中心服務器上的應用服務運行信息列表中；用于在接收到代理服務器發(fā)送的客戶端請求消息時， 將該客戶端請求消息交給對應的應用服務進行處理；應用服務處理該客戶端請求消息所請求的任務，并將處理結(jié)果返回給代理服務器；中心服務器，用于接收外部上傳的應用服務，將外部傳入的該應用服務的描述信息保存到應用服務配置信息列表中，并在對應的應用服務器上部署該應用服務；資源服務器，用于保存應用服務器上的各應用服務需要訪問的數(shù)據(jù)資源。本發(fā)明還公開了一種運行于上述的應用服務平臺系統(tǒng)的應用服務的方法，該方法包括基于應用組件AppBean開發(fā)應用服務，一種AppBean處理一種類型的業(yè)務請求；在基于一種AppBean開發(fā)一個應用服務時，需要確定的參數(shù)包括應用服務上下文。
由上述可見，本發(fā)明這種由上述代理服務器、應用服務器集群、中心服務器和資源服務器構(gòu)成的應用服務平臺系統(tǒng)，將分散的服務器資源在邏輯上整合到一起，極大降低了應用的開發(fā)難度，提高了部署的靈活性并降低了部署的難度。


圖1是本發(fā)明實施例中的應用服務平臺系統(tǒng)的邏輯結(jié)構(gòu)示意圖；圖2是本發(fā)明實施例中的應用服務平臺系統(tǒng)的一個實際組網(wǎng)示意圖；圖3是本發(fā)明實施例中的單個應用服務器的結(jié)構(gòu)示意圖。
具體實施例方式為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖和具體實施例對本發(fā)明進行詳細描述。圖1是本發(fā)明實施例中的應用服務平臺系統(tǒng)的邏輯結(jié)構(gòu)示意圖。在圖1中，各邏輯部分的描述如下※代理(Proxy)-用于分發(fā)客戶端的消息，并維護客戶端狀態(tài)(如長連接)；-服務· SAP 維護與客戶端的SIP長連接；· HAP 負責分發(fā)Http應用；· SMSP 負責分發(fā)短信上行應用；※應用主機集群(AppEngineHosts)-負載實際的應用服務運行，可進行服務器分組；※基礎服務(Base Service)-平臺內(nèi)部需求的一些核心應用或獨立應用；※資源(Resource)-提供給平臺使用的系統(tǒng)資源，如·數(shù)據(jù)庫(Database)·文件(File)·內(nèi)存對象緩沖服務器(Memcache)※中心(Center)-整個系統(tǒng)的管控中心，用于看管所用應用服務的部署、分發(fā)、更新等系統(tǒng)管理操作。圖2是本發(fā)明實施例中的應用服務平臺系統(tǒng)的一個實際組網(wǎng)示意圖。如圖2所示， 該應用服務平臺系統(tǒng)包括代理服務器、由多個應用服務器組成的服務器集群、中心服務器和資源服務器，其中代理服務器，用于接收客戶端請求消息，通過查詢中心服務器上的應用服務配置信息列表識別該客戶端請求消息所對應的應用服務，然后通過查詢中心服務器上的應用服務配置信息列表和應用服務運行信息列表獲得對應的應用服務的路徑，根據(jù)所獲得的路徑將客戶端請求消息分發(fā)給對應的應用服務所在的應用服務器；接收應用服務器端返回的處理結(jié)果，并返回給客戶端；其中，應用服務配置信息列表至少包括如下信息應用服務ID、應用服務名稱、應用服務類型、應用進程名、應用服務元數(shù)據(jù)標注；應用服務運行列表至少包括如下信息應用進程名稱、應用服務路徑；在本實施例中，代理服務器包括超文本傳輸協(xié)議HTTP代理服務器、初始會話SIP 代理服務器和短信系統(tǒng)SMS代理服務器。其中，HTTP代理服務器負責分發(fā)HTTP應用服務， SIP代理服務器負責與客戶端的SIP長連接，SMS代理服務器負責分發(fā)短信上行應用服務。每個應用服務器，用于負載應用服務并運行，將應用服務的運行信息寫入中心服務器上的應用服務運行信息列表中；用于在接收到代理服務器發(fā)送的客戶端請求消息時， 將該客戶端請求消息交給對應的應用服務進行處理；應用服務處理該客戶端請求消息所請求的任務，并將處理結(jié)果返回給代理服務器；中心服務器，用于接收外部上傳的應用服務，將外部傳入的該應用服務的描述信息保存到應用服務配置信息列表中，并在對應的應用服務器上部署該應用服務；資源服務器，用于保存應用服務器上的各應用服務需要訪問的數(shù)據(jù)資源。在本實施例中，資源服務器包括數(shù)據(jù)庫服務器、文件服務器和內(nèi)存對象緩沖服務器。在圖2所示的應用服務平臺系統(tǒng)中，代理服務器，進一步用于在接收到客戶端請求消息時，根據(jù)客戶端請求消息中的信息以及中心服務器上的應用服務配置信息列表，創(chuàng)建應用服務上下文，在所述客戶端請求消息中添加應用服務上下文后分發(fā)給對應的應用服務器上的應用服務；應用服務在接收到客戶端請求消息后，在完成該客戶端請求消息所請求的任務的過程中，根據(jù)應用服務上下文進行數(shù)據(jù)資源定位。在圖2所示的應用服務平臺系統(tǒng)中，所述代理服務器，用于在接收到客戶端請求消息時，根據(jù)該請求消息中的統(tǒng)一資源定位符URL，查找出中心服務器上的應用服務元數(shù)據(jù)標注字段包含與所述URL —致信息的應用服務配置信息列表，根據(jù)所查找出的應用服務配置信息列表中的應用服務名稱識別出該客戶端請求消息所對應的應用服務；所述代理服務器，用于根據(jù)所查找出的應用服務配置信息列表中的應用進程名，查找出中心服務器上的應用進程名稱字段包含與所述應用進程名一致信息的應用服務運行信息列表，從所查找出的應用服務運行信息列表中獲取應用服務的路徑信息。所述代理服務器，根據(jù)所查找出的應用服務配置信息列表中的元數(shù)據(jù)標注字段中的關(guān)于加載應用服務上下文信息，創(chuàng)建應用服務上下文。在圖2所示的應用服務平臺系統(tǒng)中，中心服務器，進一步用于保存資源列表；資源列表包括如下信息資源名稱、資源類型、應用服務上下文類型、定位算法名稱、定位算法參數(shù)；應用服務在接收到客戶端請求消息后，在完成該客戶端請求消息所請求的任務的過程中根據(jù)應用服務上下文以及資源列表中的對應信息進行資源定位。在圖2所示的應用服務平臺系統(tǒng)中，服務器集群中的多個應用服務器被分為多個不同的組，每組包含一臺到多臺服務器；中心服務器上保存有應用服務器列表和應用服務器分組列表；應用服務器列表包括如下信息應用服務器名稱、應用服務器所屬的分組名稱、應用服務器地址；應用服務器分組列表包括應用服務器分組名稱、分組中的應用服務器描述信息；中心服務器在接收到外部上傳的應用服務時，根據(jù)外部指令將該應用服務部署到單個應用服務器上，或者部署到屬于同一組的多個服務器上。這樣，一個應用服務可以選擇性地負載在某個組當中，也就是可以將核心的應用服務單獨使用一組服務器，保證核心應用的資源使用及穩(wěn)定性；而對剛上線的不穩(wěn)定的應用服務使用一組單獨的服務器，以剝離其中的影響，降低整個系統(tǒng)的風險。這種做法有利于進行整體資源的分配及網(wǎng)絡策略的調(diào)整。圖3是本發(fā)明實施例中的單個應用服務器的結(jié)構(gòu)示意圖。如圖3所示，主機進程是部署在每臺應用服務器上的后臺監(jiān)控進程，負責進行應用服務的下載運行與部署。主機進程會與中心服務器建立一個長連接，通過這個長連接接受部署、更新、監(jiān)控等系統(tǒng)指令。在一個應用服務器中幾個應用服務可以運行在一個應用進程中，該應用進程也可以稱為服務外殼。一個應用服務器上可以有多個應用進程。在本發(fā)明中，基于圖1和圖2所示的應用服務平臺系統(tǒng)，提供了基于應用組件 (AppBean)的應用服務開發(fā)模式。在本發(fā)明中，應用服務的開發(fā)需要通過擴展定制好的幾種 AppBean進行，一種AppBean用于處理一種類型的業(yè)務請求，業(yè)務請求可能來自用戶的客戶端軟件、瀏覽器、內(nèi)部引用、或外部信令調(diào)用。在應用服務的開發(fā)時刻，AppBean可以認為是一個抽象基類，所有的應用服務都會從AppBean這個基類派生。下面對AppBean進行介紹?！?AppBean 的抽象接口-setup ()實現(xiàn)自安裝-prepare ()實現(xiàn)資源初始化-run ()實現(xiàn)運行· AppBean的幾個子類，每個子類可能會處理不同形式的信令，應用開發(fā)人員需要選擇合適的子類去實現(xiàn)自己的應用，其中主要的子類有如下幾種-RemoteAppBean 每個 RemoteAppBean 處理一條特定的 Rpc 請求；-HttpAppBean 處理一條特定的 Http 請求；-MessageAppBean 處理一個特定的消息事務；下面對以上的幾種AppBean進行舉例說明RemoteAppBean·處理一個特定的Rpc請求，可能來源于下列幾個場景-來源于其他AppBean的引用；-來源于proxy ；-來源于其他的系統(tǒng)外部服務；·參數(shù)解釋-<A>請求參數(shù)，強類型定義；-<R>應答參數(shù)，強類型定義；-<C>特定類型的應用服務上下文AppContext ；調(diào)用一個從RemoteAppBean派生的應用服務時，必須提供這個應用服務在實現(xiàn)時所聲明的特定類型的應用服務上下文(AppContext)，例如
—個獲取用戶信息的應用服務會如下聲明1.從 RemoteAppBearKGetOption, Userlnfo, UserContext)中派生；a.請求參數(shù)<A>為GetOption，為獲取用戶的一些選項參數(shù)b.應答參數(shù)<R>為Userlnfo，為用戶信息的集合c.應用服務上下文<C>為herContext，為當前上下文的用戶信息，UserContext 用于標識用戶ID2.實現(xiàn)process方法處理業(yè)務邏輯HttpAppBean· HttpAppBea用于處理一條特定的Http請求，Http請求可能來自于-來自用戶客戶端和瀏覽器的直接請求，請求會通過HAP的智能7層負載進行反向代理轉(zhuǎn)換-直接來源于其他服務器的請求·實現(xiàn)一個特定的基于HttpAppBean的應用服務需要定制如下參數(shù)-應用服務上下文<C>特定類型的上下文；-Context來源從何處獲取上下文<C> ；-URL前綴此應用服務處理的URL前綴。(URL前綴通過OHttpPrefix元數(shù)據(jù)標注處理，后續(xù)會提到)例如開發(fā)一個用于用戶統(tǒng)一登錄認證的應用服務的流程為1.從 HttpAppBean 的基類派生；2.指定應用服務上下文類型<C>為kssionContext ；3.指定Context來源為cookie中的ssic字段；4.實現(xiàn)process方法，讀取HttpRequest,處理后返回HttpResponse給客戶端。MessageAppBean'MessageAppBean用于處理松耦合的消息事務，一個MessageAppBean處理一個特定類型的Message，MessageAppBean會監(jiān)聽此類型的消息隊列，并在消息隊列到達時開始處理；·實現(xiàn)一個特定的MessageAppBean需要指定如下參數(shù)-應用服務上下文<C>特定類型的上下文；-消息類型<A>指定強類型Message ；-事件名稱(MessageName)一個用于標記一類消息的全局唯一名稱；· MessageAppBean采用生產(chǎn)者/消費者模式-生產(chǎn)者會將產(chǎn)生的Message壓入消息隊列MessageQueueService. Enqueue(context,entity)；-作為消費者的MessageAppBean會在啟動的時候回到消息隊列服務中注冊，并訂閱特定類型的Queue，開始接受Queue中的內(nèi)容；-生產(chǎn)者和消費者，允許一對多，多對多的映射關(guān)系。以上對三種AppBean進行了舉例介紹。由上述的舉例說明可以看出，各AppBean的參數(shù)都不太一樣，但都包括 AppContext這個參數(shù)。
AppContext在本發(fā)明的應用服務平臺系統(tǒng)中，應用服務上下文(AppContext)是應用調(diào)用及資源定位的關(guān)鍵。這里應用調(diào)用包括代理服務器調(diào)用應用服務，以及應用服務內(nèi)調(diào)用其他的應用服務，這兩種應用都需要AppContext來實現(xiàn)目標應用服務的定位。AppContext從數(shù)據(jù)構(gòu)成上分為兩部分-Uri 為字符串格式，包含了用戶的索引信息，負責定位，例如-id :230302023-session :13910000001.Data:附加數(shù)據(jù)-預定義好的強類型數(shù)據(jù)結(jié)構(gòu)；-在某些場合，附加數(shù)據(jù)會由Proxy提供給后面的應用服務。在本發(fā)明的系統(tǒng)中有一些預先定義好的上下文-NullContext 預定義的空上下文，用在不需要上下文的場合；-SessionContext 預定義的只保存會話ID的上下文。除標準AppContext，在使用本發(fā)明的應用服務系統(tǒng)平臺進行擴展開發(fā)的時候，需要先定制業(yè)務相關(guān)的一些基礎，AppContext就是其中之一。下面例舉一個關(guān)于AppContext 的具體實施例。例如使用本發(fā)明的應用服務平臺系統(tǒng)開個一個即時消息(IM)系統(tǒng)，這個IM 系統(tǒng)中的用戶都采用一個整數(shù)id進行定位，那么可以根據(jù)如下方式定制這個IM系統(tǒng)的 AppContex,從 AppContext 派生，命名為 UserContext · Uri部分:"id :230302023”，表示用戶的id，那么通過這個用戶的id，可以定位用戶的應用服務位置與數(shù)據(jù)庫存儲位置；· Data 部分-用戶的登錄網(wǎng)絡地址；-客戶端類型等；當定制了用戶的herContext，所有該系統(tǒng)內(nèi)基于用戶進行操作的AppBean都會用 UserContext 作為 AppBean 的 <C> 參數(shù)，如-獲取用戶資料；-設置用戶資料；-獲取好友列表等；此外，在本發(fā)明的應用服務平臺系統(tǒng)中，除了提供基于單個用戶的AppContext 外，還提供了基于群組的業(yè)務類型，開發(fā)基于群組的應用服務，也需要定制基于群組的AppContext，IM系統(tǒng)使用一個整數(shù)用于標識群組，從AppContext派生，命名為 GroupContext, GroupContext 的結(jié)構(gòu)如下· Uri部分“group 123123”，標識群組id，表示用戶的id，那么通過這個群組的 id，我們可以定位群組的應用服務位置，與數(shù)據(jù)庫存儲位置；· Data 部分-群組的會話參數(shù)；-群組的授權(quán)等；
當定制了基于群組的GroupContext后，該系統(tǒng)內(nèi)基于群組進行操作的所有 AppBean 都會用 GroupContext 作為 AppBean 的 <C> 參數(shù)，如-設置群組名稱；-更新群組權(quán)限；-獲取群離線消息等。應用元數(shù)據(jù)標注在本發(fā)明中，一個應用服務可能會包含如下的元數(shù)據(jù)標注1. AppName (應用服務的名字和分類名)·聲明AppBean的名字以及分類名；-OAppName (category = 〃 Core “ ,name=" AddBuddy “)這里@ΧΧΧ為Java語言對程序元數(shù)據(jù)的標注?！?Category :name 全局唯一；· Category 可以用于 AppBean 的分類；-方便運維人員進行配置與分類；-在一個Category中，如果允許一個AppBean能夠被其他Category中的AppBean 訪問，必須將這個AppBean聲明成為公開或友好；· iPubIicO 允許所有的 AppBean 訪問；· iFriendlly( “Core，，)只允許指定 Category 訪問；· OFriendlly( "Core =AddBuddy")只允許指定應用訪問；2. Stateful (應用服務的狀態(tài)信息)OStateful(〃 Presence")·當聲明一個AppBean為有狀態(tài)的，則此個AppBean可以將狀態(tài)保存在本機內(nèi)存中；·沒有標注OStateful的應用均視為無狀態(tài)應用，禁止使用本機內(nèi)存進行狀態(tài)的保存； 如果一個 Category 中的多個 AppBean 聲明的 Stateful 參數(shù)一樣(“Presence”)， 則這個幾個AppBean啟動到一個進程中，并且不允許單獨熱更新；· iStateful的應用在熱更新的時候會丟失狀態(tài)，所以盡量用memcache方式去代替，建議僅在某些性能要求很高的領域啟動；·當某個AppBean被聲明為Stateful時，針對這個AppBean的訪問會采用這個 AppBean的AppContext綁定的一致性Hash的方式進行路由；3. BeforeHandler (前置業(yè)務處理項)·在某個AppBean接管控制之前優(yōu)先處理前置業(yè)務，比如配額判斷，日志記錄，安全審核等；·這個Handler可以中斷業(yè)務的運行，修改業(yè)務的入口參數(shù)，可以異步處理；iBeforeHandler (type = SecurityQuotaHandler. class, params = ("AddBuddy “))；·實現(xiàn)一個 BeforeHandler 需要實現(xiàn) emoteAppBeanHandler<A, R，C> 接口 ；-void run (RemoteAppHandlerTx<A, R, C>tx)；
4. AfterHandler (后置業(yè)務處理項)·可以指定在業(yè)務成功后進行處理，或失敗后進行，或不管成功失敗都進行；OAfterHandler (type = OperationLogHandler. class,result = OpResults. All, params = (〃 AddBuddy “))；· Handler能夠拿到完整的請求參數(shù)，及應用在context中添加的上下文數(shù)據(jù)；· Handler的處理結(jié)果不會再影響到AppBean的返回結(jié)果·實現(xiàn)方法與BeforeHandler相同。5.HttpPrefix (HTTP 前綴，只針對 HttpAppBean)·用于標注一個HttpAppBean處理的Http請求范圍；.^niOHttpPrefixr /login, do");-表示該HttpAppBean處理以login, do為起始的http請求。Message Name (事件名稱，只針對 MessageAppBean)·用于標注一個MessageAppBean的名稱；·如@Message Name6. ContextLoader (加載應用服務上下文信息) 用于標注一個AppBean如何加載AppContext 如@ContextLoader (name = 〃 CookieParser〃 )-表示通過名為CookieParser的程序去處理處理Context；-CookieParser程序內(nèi)置在Proxy當中，通過處理HttpRequest中的Cookie字段去加載用戶相關(guān)信息。前面介紹了基于AppBean的應用服務開發(fā)過程?？梢钥闯鲈诒景l(fā)明中應用服務開發(fā)的最小粒度為AppBean。接下來介紹開發(fā)完成的應用服務如何在應用服務系統(tǒng)平臺上部署以及運行的過程。前面提到應用服務系統(tǒng)平臺中的服務器集群中的應用服務器可以分成多個組，一個應用服務可以部署在一組應用服務器上，因此首先介紹一下本發(fā)明中的應用服務器的分組配置情況。在本發(fā)明中，能夠運行應用服務的應用服務器需要在全局統(tǒng)一配置，具體來說在中心服務上配置全局的應用服務器列表和應用服務器分組列表。應用服務器列表如表1所示
權(quán)利要求
1.一種應用服務平臺系統(tǒng)，其特征在于，該系統(tǒng)包括代理服務器、由多個應用服務器組成的服務器集群、中心服務器和資源服務器，其中代理服務器，用于接收客戶端請求消息，通過查詢中心服務器上的應用服務配置信息列表識別該客戶端請求消息所對應的應用服務，然后通過查詢中心服務器上的應用服務配置信息列表和應用服務運行信息列表獲得對應的應用服務的路徑，根據(jù)所獲得的路徑將客戶端請求消息分發(fā)給對應的應用服務所在的應用服務器；接收應用服務器端返回的處理結(jié)果，并返回給客戶端；其中，應用服務配置信息列表包括如下信息應用服務ID、應用服務名稱、應用服務類型、應用進程名、應用服務元數(shù)據(jù)標注；應用服務運行列表包括如下信息應用進程名稱、 應用服務路徑；每個應用服務器，用于負載應用服務并運行，將應用服務的運行信息寫入中心服務器上的應用服務運行信息列表中；用于在接收到代理服務器發(fā)送的客戶端請求消息時，將該客戶端請求消息交給對應的應用服務進行處理；應用服務處理該客戶端請求消息所請求的任務，并將處理結(jié)果返回給代理服務器；中心服務器，用于接收外部上傳的應用服務，將外部傳入的該應用服務的描述信息保存到應用服務配置信息列表中，并在對應的應用服務器上部署該應用服務； 資源服務器，用于保存應用服務器上的各應用服務需要訪問的數(shù)據(jù)資源。
2.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，代理服務器，進一步用于在接收到客戶端請求消息時，根據(jù)客戶端請求消息中的信息以及中心服務器上的應用服務配置信息列表，創(chuàng)建應用服務上下文，在所述客戶端請求消息中添加應用服務上下文后分發(fā)給對應的應用服務器上的應用服務；應用服務在接收到客戶端請求消息后，在處理該客戶端請求消息所請求的任務的過程中，根據(jù)應用服務上下文進行數(shù)據(jù)資源定位。
3.根據(jù)權(quán)利要求2所述的系統(tǒng)，其特征在于，中心服務器，進一步用于保存資源列表；資源列表包括如下信息資源名稱、資源類型、應用服務上下文類型、定位算法名稱、定位算法參數(shù)；應用服務在接收到客戶端請求消息后，在完成該客戶端請求消息所請求的任務的過程中根據(jù)應用服務上下文以及資源列表中的對應信息進行資源定位。
4.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述多個代理服務器包括超文本傳輸協(xié)議HTTP代理服務器、初始會話SIP代理服務器和短信系統(tǒng)SMS代理服務器；所述資源服務器包括數(shù)據(jù)庫服務器、文件服務器和內(nèi)存對象緩沖服務器。
5.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述服務器集群中的多個應用服務器被分為多個不同組； 所述中心服務器上保存有應用服務器列表和應用服務器分組列表； 應用服務器列表包括如下信息應用服務器名稱、應用服務器所屬的分組名稱、應用服務器地址；應用服務器分組列表包括應用服務器分組名稱、分組中的應用服務器描述信息； 中心服務器，用于在接收到外部上傳的應用服務時，根據(jù)外部指令將該應用服務部署到單個應用服務器上，或者部署到屬于同一組的多個服務器上。
6.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述代理服務器，用于在接收到客戶端請求消息時，根據(jù)該請求消息中的統(tǒng)一資源定位符URL，查找出中心服務器上的應用服務元數(shù)據(jù)標注字段包含與所述URL —致信息的應用服務配置信息列表，根據(jù)所查找出的應用服務配置信息列表中的應用服務名稱識別出該客戶端請求消息所對應的應用服務；或者，用于在接收到客戶端的請求消息時，根據(jù)該請求消息中的遠程調(diào)用服務名稱，查找出中心服務器上應用服務名稱字段與所述遠程調(diào)用服務名稱一致的應用服務配置信息列表， 根據(jù)所查找出的應用服務名稱字段識別出該請求消息所對應的應用服務；或者，用于在接收到客戶端的請求消息時，根據(jù)該請求消息中的事件名稱，查找出中心服務器上的應用服務元數(shù)據(jù)標注字段包含與所述事件名稱一致信息的應用服務配置信息列表， 根據(jù)所查找出的應用服務配置信息列表中的應用服務名稱識別出該客戶端請求消息所對應的應用服務；所述代理服務器，用于根據(jù)所查找出的應用服務配置信息列表中的應用進程名，查找出中心服務器上的應用進程名稱字段包含與所述應用進程名一致信息的應用服務運行信息列表，從所查找出的應用服務運行信息列表中獲取應用服務的路徑信息。
7.根據(jù)權(quán)利要求2所述的系統(tǒng)，其特征在于，所述代理服務器，用于在接收到客戶端請求消息時，根據(jù)該請求消息中的統(tǒng)一資源定位符URL，查找出中心服務器上的應用服務元數(shù)據(jù)標注字段包含與所述URL —致信息的應用服務配置信息列表，然后根據(jù)該應用服務配置信息列表中的元數(shù)據(jù)標注字段中的關(guān)于加載應用服務上下文的信息，創(chuàng)建應用服務上下文。
8.一種開發(fā)運行于權(quán)利要求1至6中任一項所述的應用服務平臺系統(tǒng)的應用服務的方法，其特征在于，該方法包括基于應用組件AppBean開發(fā)應用服務，一種AppBean處理一種類型的業(yè)務請求；在基于一種AppBean開發(fā)一個應用服務時，需要確定的參數(shù)包括應用服務上下文。
9.根據(jù)權(quán)利要求8所述的方法，其特征在于，該方法進一步包括在基于一種AppBean開發(fā)一個應用服務時，令該應用服務的元數(shù)據(jù)標注包括應用服務的名字和分類名、應用服務的狀態(tài)信息、前置業(yè)務處理項、后置業(yè)務處理項、HTTP前綴/ 事件名稱、加載應用服務上下文信息。
10.根據(jù)權(quán)利要求8所述的方法，其特征在于，所述應用服務上下文在數(shù)據(jù)構(gòu)成上包括兩部分字符串格式的通用資源標志符URI和附加數(shù)據(jù)部分。
全文摘要
本發(fā)明公開了一種應用服務平臺系統(tǒng)和一種開發(fā)應用服務的方法。所述系統(tǒng)包括代理服務器、由多個應用服務器組成的服務器集群、中心服務器和資源服務器，其中代理服務器，用于向各應用服務器分發(fā)客戶端請求；每個應用服務器，用于負載應用服務并運行；中心服務器，用于接收外部上傳的應用服務，并在對應的應用服務器上部署該應用服務；資源服務器，用于保存應用服務器上的各應用服務需要訪問的數(shù)據(jù)資源。本發(fā)明的技術(shù)方案降低了應用開發(fā)的難度，提高了部署的靈活性并降低了部署的難度。
文檔編號H04L29/08GK102185900SQ20111009715
公開日2011年9月14日 申請日期2011年4月18日 優(yōu)先權(quán)日2011年4月18日
發(fā)明者高磊 申請人:北京新媒傳信科技有限公司