專利名稱：在客戶端/服務器模式業(yè)務系統(tǒng)中進行能力協(xié)商的方法
技術領域：
本發(fā)明涉及在移動通信網(wǎng)絡上的基于客戶端/服務器(C/S)模型的業(yè)務業(yè)務系統(tǒng)，比如即時消息系統(tǒng)。在這一類系統(tǒng)中，客戶端的幾乎所有操作都需要和服務器進行交互來完成。
背景技術：
隨著移動通信技術的發(fā)展，越來越多的應用遷移到移動通信網(wǎng)絡上。不同于在互聯(lián)網(wǎng)上的應用，大部分移動數(shù)據(jù)業(yè)務的客戶端往往由不同廠商提供，因此越來越多各式各樣的終端也作為應用的客戶端參與到移動數(shù)據(jù)應用中?；诓煌布蛙浖脚_的限制，不同廠商不同型號之間的實現(xiàn)和終端能力等特性并不一致，他們根據(jù)諸如開放移動聯(lián)盟-無線鄉(xiāng)村(OMA-WV)等國際標準規(guī)范完成與服務器之間的通信。
在即時消息的標準規(guī)范OMA-WV協(xié)議中，在每次會話中，當完成登錄過程后，需要在客戶端和服務器之間進行客戶能力上報的過程。規(guī)范制定的一個指導原則是由于硬件限制，移動業(yè)務的客戶端能力遠遠弱于服務器能夠提供的能力，是服務器能力的真子集。因此，客戶端只需要上報自身能夠支持的能力和特性，如客戶端的生產(chǎn)廠商型號、支持的通信方式、支持的消息大小限制等信息。該過程可以視為是一個客戶端向服務器進行通知的過程。服務器在得知相關數(shù)據(jù)后在同一會話期保證主動發(fā)起的與客戶端之間的業(yè)務操作和通信能力不會超過這些限制即可。
圖1是客戶端能力請求過程的示意圖。從上述過程可以看出這種客戶能力上報的過程實際上是一個單向的過程。服務器可以知道客戶端能力的限制，而客戶端不知道服務器側的限制，他的基礎就是客戶端的能力必然弱于服務器。這樣會存在以下問題。
由于該過程中并沒有能夠告知客戶端服務器側的限制，從而導致了客戶端無法得知服務器是否存在某種限制(例如一個聯(lián)系列表有多少好友，總共能有多少好友列表等)。隨著移動設備的發(fā)展，服務器能力無法保證一定是客戶端能力的超集。而且，在這種情況下，本來可以在客戶端進行處理的一些數(shù)據(jù)有效性檢查操作都必須交給服務器處理，增加了服務器的處理復雜性，也增加了移動網(wǎng)絡的負擔。

發(fā)明內(nèi)容
本發(fā)明的目的是提供在即時消息(IM)服務器和其客戶端之間以及其他類似的客戶端/服務器架構的移動應用中實現(xiàn)客戶端和服務器端能力的協(xié)商操作。
本發(fā)明的主要思路是在用戶登錄完成后，立刻進行客戶端和服務器的能力約定操作，盡量保證客戶端不會發(fā)出對服務器超限或者無意義的數(shù)據(jù)，導致網(wǎng)絡流量的浪費和服務器處理的額外負擔。
根據(jù)第一方面，本發(fā)明提供一種客戶端/服務器模式業(yè)務系統(tǒng)中進行能力協(xié)商的方法，所述客戶端/服務器模式業(yè)務系統(tǒng)包括客戶端和服務器，所述方法包括步驟客戶端向服務器發(fā)送服務器能力請求消息或客戶端能力限制上報請求消息，服務器按照自身能力集給出包括服務器能力限制的回應消息，并且將該回應消息發(fā)送給客戶端；客戶端依據(jù)該服務器能力限制對擬提交給服務器的操作進行數(shù)據(jù)有效性檢查。
在第一方面中，優(yōu)選的是，所述客戶端/服務器模式業(yè)務系統(tǒng)提供即時信息服務、個人信息管理服務(PIM)和視頻會議服務。
優(yōu)選的是，所述方法包括在客戶端向服務器發(fā)送客戶端能力限制上報請求消息的情況下，服務器在所述回應消息中添加對客戶端能力的確認。
優(yōu)選的是，所述方法包括在客戶端向服務器發(fā)送服務器能力請求消息之前，客戶端向服務器發(fā)送客戶端能力限制上報請求消息。
優(yōu)選的是，所述方法包括服務器處理并且存儲客戶端能力限制的步驟。
優(yōu)選的是，所述方法包括客戶端存儲服務器能力限制的步驟。
根據(jù)第二方面，提供一種包括服務器的客戶端/服務器模式業(yè)務系統(tǒng)中的客戶端，所述客戶端包括消息處理模塊，產(chǎn)生服務器能力請求消息或客戶端能力限制上報請求消息；通訊模塊，發(fā)送所述請求消息給服務器，并且接收服務器發(fā)回的包括服務器能力限制的回應消息；管理和控制模塊，存儲服務器能力限制，并且依據(jù)該服務器能力限制對擬提交給服務器的操作在本地進行數(shù)據(jù)有效性檢查。
在第二方面中，優(yōu)選的是客戶端包括界面顯示模塊。
根據(jù)第三方面，提供一種包括客戶端的客戶端/服務器模式業(yè)務系統(tǒng)中的服務器，所述服務器包括消息接入模塊，接收服務器能力請求消息或客戶端能力限制上報請求消息；消息處理模塊，將所述請求消息發(fā)送給管理和控制模塊；管理和控制模塊，按照自身能力集產(chǎn)生包括服務器能力限制的回應消息；所產(chǎn)生的包括服務器能力限制的回應消息由消息接入模塊發(fā)送給客戶端，從而客戶端依據(jù)該服務器能力限制對擬提交給服務器的操作在本地進行數(shù)據(jù)有效性檢查。
在第三方面中，優(yōu)選的是包括客戶能力限制存儲模塊，存儲來自客戶端的客戶端能力限制。
根據(jù)第四方面，提供一種客戶端/服務器模式業(yè)務系統(tǒng)，包括如第二方面所述的客戶端和如第三方面所述的服務器。


下面將以舉例的方式參照附圖對本發(fā)明進行更詳細的說明，其中圖1是客戶端能力請求過程的示意圖；圖2是根據(jù)本發(fā)明的一個實施方案的客戶端和服務器間進行能力協(xié)商的業(yè)務流程示意圖；圖3是服務器的模塊示意圖；圖4是圖3所示服務器進行能力協(xié)商的流程示意圖；圖5是客戶端的模塊示意圖；圖6是圖5所示客戶端進行能力協(xié)商的流程示意圖；圖7是服務器和客戶端之間的協(xié)商消息交互流程圖；以及圖8是根據(jù)本發(fā)明的另一個實施方案的客戶端和服務器間的協(xié)商消息交互流程圖。
具體實施例方式
圖2是根據(jù)本發(fā)明的一個實施方案的進行能力協(xié)商的業(yè)務流程示意圖。如圖2所示，在移動即時消息等C/S模式業(yè)務系統(tǒng)中進行能力協(xié)商的方法包括下列步驟1.用戶完成登錄；2.客戶端向服務器上報客戶端能力限制；服務器根據(jù)客戶端能力限制返回確認信令并在客戶端能力集的可選內(nèi)容中挑選合適的能力進行確認(此流程參考OMA-WV已有的ClientCaDabitlity流程)；
3.客戶端向服務器請求服務器能力限制，服務器返回能力列表；4.當客戶端在后續(xù)操作中發(fā)出的操作請求超出服務器能力限制，服務器給予明確的錯誤碼進行指示。
在該能力協(xié)商的過程中，客戶端需要主動向服務器請求服務器的能力限制列表。客戶端在得到服務器的能力限制后會存儲在本地，供本次登錄的會話過程使用。對用戶所有提交的操作先根據(jù)服務器的能力限制在本地進行一次數(shù)據(jù)有效性檢查。
當客戶端的操作請求超越了服務器能力限制時，客戶端需要明確返回不同的錯誤特征碼給予指示，客戶端可以根據(jù)相應錯誤碼決定后續(xù)操作或者給用戶適當提示。
圖3是服務器的模塊示意圖。如圖3所示，服務器包括消息接入模塊、消息處理模塊、管理和控制模塊與客戶能力限制存儲模塊。
消息接入模塊是與客戶端通過網(wǎng)絡設備進行交互消息的模塊，接收客戶端的發(fā)送的消息請求和響應消息，主動向客戶端發(fā)送消息等。根據(jù)本發(fā)明，該模塊增加對服務器、客戶端之間如圖7所示的獲取服務器能力限制消息的接入支持功能。
消息處理模塊是對所有消息進行處理的模塊，處理來自業(yè)務接入模塊消息請求，并響應消息；根據(jù)業(yè)務需要，向管理和控制模塊發(fā)送請求消息等；根據(jù)業(yè)務需要，向客戶能力限制存儲模塊請求存儲消息或獲取消息。根據(jù)本發(fā)明，該模塊增加對服務器客戶端之間如圖7所示的獲取服務器消息的處理功能的支持。
管理和控制模塊是對客戶端/服務器間交互的消息進行管理和控制的模塊，包括但不限于消息發(fā)送和接收的管理，通知消息處理模塊轉發(fā)消息等等。根據(jù)本發(fā)明，該模塊增加存儲客戶能力限制信息的管理等。
客戶能力限制存儲模塊負責對客戶能力限制記錄的存儲和管理，包括但不限于存儲客戶能力限制記錄，管理客戶能力限制記錄，支持獲取客戶能力限制記錄等。
圖4是圖3所示服務器進行能力協(xié)商的流程示意圖。在步驟S410，消息接入模塊接入來自客戶端的客戶能力限制上報消息。在步驟S420，消息處理模塊接收并處理來自客戶端的客戶能力限制上報請求。在步驟S430，管理和控制模塊給出客戶能力上報的回應消息。在步驟S440，客戶能力限制存儲模塊在本次會話期間保存該用戶的客戶能力限制信息。在步驟S450，消息接入模塊接入來自客戶端的服務器能力請求消息。在步驟S460，消息處理模塊接收并處理來自客戶端的服務器能力限制請求。在步驟S470，管理和控制模塊按照自身能力集給出服務器能力限制的回應消息。
圖5是客戶端的模塊示意圖。如圖5所示，客戶端包括通訊模塊、消息處理模塊、管理和控制模塊、與界面顯示模塊。
通訊模塊負責與服務器進行消息通訊，發(fā)送請求消息和接收響應消息，接收服務器主動發(fā)送的通知消息等。
消息處理模塊對所有消息進行處理的模塊，構造指示通訊模塊發(fā)送請求消息，接收和處理響應消息；根據(jù)業(yè)務需要向管理和控制模塊發(fā)送請求消息等；根據(jù)業(yè)務需要向顯示模塊發(fā)送消息顯示或用戶提示消息。依據(jù)本發(fā)明，消息處理模塊增加對客戶端請求服務器能力限制消息處理功能的支持。
管理和控制模塊對會話過程進行管理控制的模塊，負責業(yè)務邏輯的處理。依據(jù)本發(fā)明，該模塊增加其對服務器能力限制的存儲能力以及數(shù)據(jù)有效性的校驗能力。
界面顯示模塊顯示會話名字、會話內(nèi)容、會話方名稱等。依據(jù)本發(fā)明，該模塊增加會話歷史記錄策略選擇界面的顯示功能。
圖6是圖5所示客戶端進行能力協(xié)商的流程示意圖。在步驟S610，客戶端開始登錄。在登錄成功后進入步驟S620。在步驟S620，客戶端上報自身能力限制。在步驟S630，客戶端請求服務器能力限制。在步驟S640，客戶端進行相應操作。在步驟S650，管理控制模塊在客戶端向服務器發(fā)起請求前預處理檢查信令中數(shù)據(jù)是否可能超出服務器能力。如果是，程序進入步驟S660，否則進入步驟S670。在步驟S660，界面模塊提示用戶超限。
在步驟S670，消息處理模塊通過通訊模塊發(fā)出消息。
圖7是服務器和客戶端之間的協(xié)商消息交互流程圖。在客戶端請求登錄服務器之后，服務器以LoginResponse回應?？蛻舳讼蚍掌靼l(fā)出ClientCapabilityRequest，上報客戶能力限制。服務器回應以ClientCapabilityResponse。然后，客戶端向服務器發(fā)出GetServerCapabilityRequest，向服務器請求服務器能力限制。服務器回應以GetServerCapabilityResponse。
下面給出可能的GetServerCapabilityRequest/Response信令對的文檔類型定義(DTD)簡要定義<！ELEMENT GetServerCapabilityRequest EMPTY>
<！ELEMENT GetServerCapabilityResponseServerCapabilityList>
<！ELEMENT ServerCapabilityList(Property+)>
<！ELEMENT Property(Name，Value？)>
<！ELEMENT Name(#PCDATA)>
<！ELEMENT Value(#PCDATA)>
需要指出，上述交互消息的名稱、參數(shù)的名稱、參數(shù)的順序只是示意圖，并非意在限制本發(fā)明的保護范圍。另外，上述交互消息是應用層的消息，其底層可以是通過HTTP來承載，也可以是通過SIP、TCP等技術來承載。如何通過底層協(xié)議進行上述交互消息的承載，不在本專利的范圍之內(nèi)。
圖8是根據(jù)本發(fā)明的另一個實施方案的客戶端和服務器間的協(xié)商消息交互流程圖。如圖8所示，通過擴展類似OMA-WV標準的ClientCapabilityResponse信令，在ClientCapability流程中一次完成客戶端和服務器兩側的能力交互。
客戶端在登錄完成后，隨即發(fā)送自身的能力上報請求信令。服務器端在接收到該請求信令后，除了回應該能力上報請求，對于客戶端能力中的可選部分作為確認回應外，也同時根據(jù)要求在該信令中添加服務器能力限制的信息。
例如，構建實現(xiàn)上述過程的消息對可以采用如下的編碼DTD簡要定義<！ELEMENT CapabilityRequest(ClientCapabilityList)>
<！ELEMENT ClientCapabilityList(ClientType，AcceptedTransferEncoding*，SupportedBearer*，SupportedCIRMethod*，ServerPollMin？…)>
<！ELEMENT CapabilityResponse(AgreedCapabilityList，SeryCapabilityList)>
<！ELEMENT AgreedCapabilityList(SupportedBearer*，SupportedCIRMethod*，ServerPollMin？，CIRURL？…)>
<！ELEMENT SeryCapabilityList(Property+)>
<！ELEMENT Property(Name，Value？)>
<！ELEMENT Name(#PCDATA)>
<！ELEMENT Value(#PCDATA)>
在用戶開始使用移動數(shù)據(jù)業(yè)務前，做好客戶端和服務器的能力約定，有助于提高客戶體驗、減輕網(wǎng)絡負擔、降低服務器的邏輯處理復雜度。
本發(fā)明還可以適用于除即時消息外的需進行能力協(xié)商的其它類型C/S模式業(yè)務系統(tǒng)。例如，個人信息管理服務(PIM)客戶端和視頻會議終端。
基于C/S模型的PIM客戶端在同步數(shù)據(jù)前可能需要明確自身的內(nèi)存容量，自身和服務器共同支持的文件格式、客戶端版本號以及服務器能夠提供的功能列表等信息。
而視頻會議終端在和服務器進行正常的視頻會議流程前，也需要向服務器上報自身的顯示大小、支持的媒體類型、版本號等信息。對自身版本號的上報有助于服務器了解該版本客戶端的軟能力，對支持的媒體類型、文件類型、顯示尺寸之類的信息的報告有助于服務器提供內(nèi)容適配的能力。
顯而易見，在此描述的本發(fā)明可以有許多變化，這種變化不能認為偏離本發(fā)明的精神和范圍。因此，所有對本領域技術人員顯而易見的改變，都包括在本權利要求書的涵蓋范圍之內(nèi)。
權利要求
1.一種客戶端/服務器模式業(yè)務系統(tǒng)中進行能力協(xié)商的方法，所述客戶端/服務器模式業(yè)務系統(tǒng)包括客戶端和服務器，所述方法包括步驟客戶端向服務器發(fā)送服務器能力請求消息或客戶端能力限制上報請求消息，服務器按照自身能力集給出包括服務器能力限制的回應消息，并且將該回應消息發(fā)送給客戶端；客戶端依據(jù)該服務器能力限制對擬提交給服務器的操作進行數(shù)據(jù)有效性檢查。
2.如權利要求1所述的方法，其特征在于所述客戶端/服務器模式業(yè)務系統(tǒng)提供即時信息服務、個人信息管理服務(PIM)和視頻會議服務。
3.如權利要求1所述的方法，其特征在于包括在客戶端向服務器發(fā)送客戶端能力限制上報請求消息的情況下，服務器在所述回應消息中添加對客戶端能力的確認。
4.如權利要求1所述的方法，其特征在于包括在客戶端向服務器發(fā)送服務器能力請求消息之前，客戶端向服務器發(fā)送客戶端能力限制上報請求消息。
5.如權利要求1-4之一所述的方法，其特征在于包括服務器處理并且存儲客戶端能力限制的步驟。
6.如權利要求1-4之一所述的方法，其特征在于包括客戶端存儲服務器能力限制的步驟。
7.一種包括服務器的客戶端/服務器模式業(yè)務系統(tǒng)中的客戶端，所述客戶端包括消息處理模塊，產(chǎn)生服務器能力請求消息或客戶端能力限制上報請求消息；通訊模塊，發(fā)送所述請求消息給服務器，并且接收服務器發(fā)回的包括服務器能力限制的回應消息；管理和控制模塊，存儲服務器能力限制，并且依據(jù)該服務器能力限制對擬提交給服務器的操作在本地進行數(shù)據(jù)有效性檢查。
8.如權利要求5所述的客戶端，其特征在于包括界面顯示模塊。
9.一種包括客戶端的客戶端/服務器模式業(yè)務系統(tǒng)中的服務器，所述服務器包括消息接入模塊，接收服務器能力請求消息或客戶端能力限制上報請求消息；消息處理模塊，將所述請求消息發(fā)送給管理和控制模塊；管理和控制模塊，按照自身能力集產(chǎn)生包括服務器能力限制的回應消息；所產(chǎn)生的包括服務器能力限制的回應消息由消息接入模塊發(fā)送給客戶端，從而客戶端依據(jù)該服務器能力限制對擬提交給服務器的操作在本地進行數(shù)據(jù)有效性檢查。
10.如權利要求9所述的服務器，其特征在于包括客戶能力限制存儲模塊，存儲來自客戶端的客戶端能力限制。
11.一種客戶端/服務器模式業(yè)務系統(tǒng)，包括如權利要求7所述的客戶端和如權利要求9所述的服務器。
全文摘要
本發(fā)明提供一種客戶端/服務器模式業(yè)務系統(tǒng)中進行能力協(xié)商的方法、及采用該方法的客戶端、服務器和系統(tǒng)。所述方法包括步驟客戶端向服務器發(fā)送服務器能力請求消息或客戶端能力限制上報請求消息，服務器按照自身能力集給出包括服務器能力限制的回應消息，并且將該回應消息發(fā)送給客戶端；客戶端依據(jù)該服務器能力限制對擬提交給服務器的操作在本地進行數(shù)據(jù)有效性檢查。采用本發(fā)明，在用戶開始使用移動數(shù)據(jù)業(yè)務前，做好客戶端和服務器的能力約定，有助于提高客戶體驗、減輕網(wǎng)絡負擔、降低服務器的邏輯處理復雜度。
文檔編號H04L29/06GK1859403SQ20061003360
公開日2006年11月8日 申請日期2006年2月9日 優(yōu)先權日2006年2月9日
發(fā)明者陶佳琪 申請人:華為技術有限公司