專利名稱：包含分布式軟件應用的數(shù)據(jù)訪問、復制或通信系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及包含分布式軟件應用的數(shù)據(jù)訪問、復制或通信系統(tǒng)。
背景技術：
諸如智能電話、移動電話、無線PDA等的無線終端通常受到嚴格的存儲器、處理能力和電池的限制。其結(jié)果是，使用這一類型的終端來訪問、復制或傳遞數(shù)據(jù)就表現(xiàn)出巨大的挑戰(zhàn)。例如，如果一個人使用無線終端來存儲其聯(lián)系和日程表，還發(fā)送和接收電子郵件，那么，通常就出現(xiàn)將數(shù)據(jù)集與遠程服務器上的主數(shù)據(jù)集同步的需求。服務器與移動裝置之間的同步通常通過使用相對的高帶寬、低延遲、非計量的連接(例如，USB或IR)而進行。其結(jié)果是，同步系統(tǒng)經(jīng)常使用傳輸大量數(shù)據(jù)的方法，并且當數(shù)據(jù)在傳輸過程中丟失或當?shù)讓拥耐ㄐ疟恢袛鄷r并不是十分的健壯。例如，基于服務器的數(shù)據(jù)集同步通常要求所有連接的裝置通過單個會話將它們的整個數(shù)據(jù)集(例如，所有的電子郵件，所有的聯(lián)系等)下載到服務器，這樣就能夠執(zhí)行與上一次完整同步數(shù)據(jù)集的主拷貝的比較，以便更新主拷貝并由此更新所有其他數(shù)據(jù)集。這種方法對于無線裝置來說并無吸引力，原因是其強加的功率消耗、潛在的長連接時間和高昂的數(shù)據(jù)傳送。

發(fā)明內(nèi)容
本發(fā)明設想了一種包含軟件應用的數(shù)據(jù)訪問、復制或通信系統(tǒng)，該軟件應用跨越終端側(cè)組件而分布，運行于終端和服務器側(cè)組件之上。
其中所述終端側(cè)組件和所述服務器側(cè)組件(i)共同構成到服務器的客戶端并；(ii)通過使用消息隊列系統(tǒng)通過網(wǎng)絡發(fā)送消息來協(xié)作。
從而，我們就將客戶端-服務器構架(例如，在Microsoft Exchange電子郵件環(huán)境中)中充當客戶端的應用的功能劃分(即，分布)為運行在兩個或更多物理裝置上的部件，這些裝置使用諸如面向消息的中間件的消息隊列系統(tǒng)通過網(wǎng)絡連接相互通信。組成部件在大型的客戶端-服務器配置中充當客戶端，而服務器為例如Exchange郵件服務器。我們稱此為‘分布式客戶端’模型。分布式客戶端模型的核心優(yōu)勢在于其允許終端，如具有有限處理能力、功率和連接性的無線裝置，通過將通常與客戶端相關的功能中的一部分分布到服務器側(cè)而使用移動裝置上的最少資源來享受功能完備的客戶端訪問服務器環(huán)境的功能，服務器側(cè)不是如此地受資源限制。(同時本發(fā)明因此在當所述終端是無線終端(例如智能電話)而所述網(wǎng)絡是無線網(wǎng)絡(例如GPRS)時特別實用，但并非要受限于這些實施例。從而，本發(fā)明也覆蓋了例如通過有線網(wǎng)絡與遠程服務器通信的桌面PC的終端)。
與其他分布式模型不同，在本發(fā)明的一種實現(xiàn)中，每個部件都能夠提供與其它組件無關的功能(僅超過訪問緩存/存儲的數(shù)據(jù))，甚至是在不具備網(wǎng)絡連接的時候。例如，在常規(guī)的分布式客戶端中，例如使用web瀏覽器和訪問Microsoft Exchange郵件服務器的web服務器分布式客戶端的電子郵件web訪問，如果你中斷了瀏覽器與web服務器之間的連接，那么該瀏覽器除了繼續(xù)顯示任何緩存的電子郵件之外將而不具備任何功能。但是使用本發(fā)明的一種實現(xiàn)，如果通過網(wǎng)絡的連接中斷的話，通過同樣排隊等待為了將要重新創(chuàng)建的連接而準備就緒的消息，終端側(cè)組件也可同樣使終端程序(例如，聯(lián)系、日程表、電子郵件等)免受其影響而使終端程序繼續(xù)其下一個任務。由此，用戶在終端(例如智能電話、PC)上使用電子郵件或PIM應用的經(jīng)歷就會完全相同，而無論是否有連接。用戶可以繼續(xù)在其終端上創(chuàng)建電子郵件，編輯聯(lián)系等。用戶從網(wǎng)絡連接的狀態(tài)中隔離開是因為終端可以使用消息隊列系統(tǒng)排隊等待消息，直到當連接被重新建立時接著就可以自動將它們發(fā)送出去。同樣地，如果通過網(wǎng)絡連接中斷的話，服務器側(cè)組件同樣通過排隊等待為了將要重新創(chuàng)建的連接而準備就緒的消息，可以使服務器程序免受其影響而使其繼續(xù)其下一個任務。
由于這種方法通過提出跨越網(wǎng)絡的消息隊列平臺而使終端側(cè)不受各種網(wǎng)絡性能的影響，當所述網(wǎng)絡是具有高度不可預知的帶寬、覆蓋率和可用性的無線網(wǎng)絡時效果更好。從而，分布式客戶端模型直接致力于解決在終端上提供良好的用戶體驗的問題(例如，最終用戶總是能夠與其PIM、日程表或電子郵件應用交互，而不管網(wǎng)絡的覆蓋率如何)，不管所述終端具有較大的資源限制，也不管所述連接具有較大的限制。
針對分布式客戶端優(yōu)化的一個實現(xiàn)細節(jié)是，每個排隊的消息定義了‘事件’的部分或全部，其中事件足夠詳細地描述了存儲在終端或服務器的數(shù)據(jù)的改變以使數(shù)據(jù)復制無需常規(guī)的同步引擎而進行；數(shù)據(jù)復制由此就通過發(fā)送‘事件’完成，而不是通過同步所存儲數(shù)據(jù)的整個數(shù)據(jù)集(或數(shù)據(jù)集的子集)。終端側(cè)組件能夠創(chuàng)建事件并自己和/或在消息隊列系統(tǒng)中排隊這些事件，使得終端側(cè)組件即使是在網(wǎng)絡連接中斷的情況下也能夠繼續(xù)其下一個任務。同樣，服務器側(cè)組件能夠創(chuàng)建事件并自己和/或在消息隊列系統(tǒng)中排隊這些事件，使得服務器側(cè)組件即使是在網(wǎng)絡連接中斷的情況下也能夠繼續(xù)其下一個任務。所排列的事件可以保留在終端上的非易失存儲器中，即使是在無線終端被關閉的時候。同樣，所排列的事件可以保留在運行服務器側(cè)組件的主機上的非易失存儲器中，即使是在服務器被關閉的時候(應該注意運行服務器側(cè)組件的主機未必是運行服務器的相同主機，即使有可能是同一主機)。
終端側(cè)組件和服務器側(cè)組件可以在運行于無線終端上的終端程序和運行于服務器上的服務器程序之間共同構成中間件。
該應用也可以包括分布式應用平臺，其調(diào)用到提供消息隊列功能的分布式通信平臺，其中所述通信平臺使通過網(wǎng)絡的消息的分發(fā)變得可靠，即使是使用不可靠的傳輸協(xié)議，其中所述通信平臺以“會話無關”的方式運行。
具體實施例方式
1、引言本發(fā)明將參考來自Visto公司的實現(xiàn)而描述。該實現(xiàn)包括稱為MobileMQTM的中間件通信平臺和稱為Transcend MailTM的分布式應用層。
Transcend Mail是運行在(即，也分布在)SymbianOSTM智能電話無線終端和Windows 2000服務器上的端到端的GPRS-連接應用。它允許SymbianOS智能電話上的電子郵件、聯(lián)系和日程表應用使用MobileMQ平臺來通過GPRS與Microsoft ExchangeTM郵件服務器一起執(zhí)行自動數(shù)據(jù)復制。MobileMQ是再次分布于智能電話和服務器的面向消息的中間件平臺。它提供了實現(xiàn)了Transcend Mail用戶體驗的很多方面的GPRS-有效、可靠的和安全的通信方法。無論是否具有通過網(wǎng)絡(無論是有線還是無線)進行遠程數(shù)據(jù)訪問、復制或通信的需求，都可以使用MobileMQ。MobileMQ使用會話無關的不可靠的底層傳輸協(xié)議。
Transcend Mail允許移動的員工可以從他們的基于Symbian的GPRS智能電話訪問公司的郵件、聯(lián)系和日程表條目。其設計用來滿足移動員工的三方面需求1.其使得他們能夠在離開其辦公桌的同時保持“聯(lián)系中”，使得他們對顧客、市場和業(yè)務需求保持及時反應；2.其確保他們的聯(lián)系和日程表保持‘最新狀態(tài)”以便他們可以與同事共同有效地協(xié)作；3.其使得生產(chǎn)性使用能夠同時在約會、等待運輸或在旅行期間由‘停滯時間’組成。
Transcend Mail實現(xiàn)了以下特征●允許終端裝置用戶界面與本地數(shù)據(jù)一起工作，從而GPRS延遲，較低且可變的帶寬和斷斷續(xù)續(xù)的覆蓋率并不會阻止電子郵件、聯(lián)系和日程表應用做到總是可用的并有響應；●以及時的方式并且在后臺自動復制本地數(shù)據(jù)和服務器側(cè)數(shù)據(jù)之間的改變，而并不打擾用戶；
●極少使用GPRS以便顧客從網(wǎng)絡運營商的GPRS價目表得到合適的價格，并且不會得到有時被稱為“bill shock”的價格；●以顧客組織將他們的員工的GPRS移動電話連接到公司的局域網(wǎng)的方式提供了靈活性；●盡可能無縫地與移動電話應用程序組結(jié)合以便用戶不用必須學習新的系統(tǒng)；●盡可能無縫地與后臺最終郵件服務器結(jié)合以便IT管理員感覺舒適并且也具有良好的用戶體驗；●終端裝置上的不同應用可以獨立發(fā)送/接收，從而即使是下載非常大的電子郵件附件的用戶仍然可以更新其日程表。
2、核心設計原理在本發(fā)明的一種實現(xiàn)中，我們將在客戶端-服務器構架(例如，Microsoft Exchange環(huán)境中)中充當客戶端的Transcend Mail應用的功能劃分(即，分布)為運行在兩個或多個物理裝置上的部件，這些裝置使用MobileMQ面向消息的中間件通過廣域連接相互通信。這些部件在大型的客戶端-服務器配置中共同充當客戶端，而服務器為Exchange郵件服務器。我們稱此為“分布式客戶端”模型。分布式客戶端模型的核心優(yōu)勢在于其允許終端，如具有有限處理能力、功率和連接性的無線裝置，通過將通常與客戶端相關的功能中的一部分分布到服務器側(cè)而在移動裝置上使用最少資源，來享受功能完備的客戶端訪問服務器環(huán)境的功能，服務器側(cè)不是如此地受資源限制。
但是與其他分布式模型不同，在Transcend Mail中，每個部件都能夠提供與其它部件無關的功能(僅超過訪問緩存/存儲的數(shù)據(jù))，甚至是在不具備網(wǎng)絡連接的時候。例如，在常規(guī)的分布式客戶端中，例如使用web瀏覽器和訪問Microsoft Exchange郵件服務器的web服務器分布式客戶端的電子郵件web訪問，如果你中斷了瀏覽器與web服務器之間的連接，那么該瀏覽器除了繼續(xù)顯示任何緩存的電子郵件之外將而不具備任何功能。但是使用Transcend Mail，用戶在智能電話上使用電子郵件或PIM(聯(lián)系，日程表)應用的經(jīng)歷就完全相同，而無論是否有連接。該用戶可以繼續(xù)在其智能電話上創(chuàng)建電子郵件，編輯聯(lián)系等。用戶從網(wǎng)絡連接的狀態(tài)中隔離開是因為終端可以使用MobileMQ(如果MobileMQ隊列已滿的話也使用其自己的隊列)排列消息，直到當連接被重新建立時接著就可以自動發(fā)送下一個排隊的消息。同樣地，當重新建立連接時就能夠自動發(fā)送存儲在服務器側(cè)的下一個排隊的消息。
當網(wǎng)絡是具有高度不可預知的帶寬、覆蓋率和可用性的無線網(wǎng)絡時該方法也更加有效，因為它通過提出跨越網(wǎng)絡的消息隊列平臺(即，MobileMQ)而使得終端側(cè)免受網(wǎng)絡性能難以預測的變化的影響。從而，分布式客戶端模型不僅僅是直接致力于解決在終端上提供優(yōu)良的用戶體驗的問題(例如，最終用戶總是能夠與其聯(lián)系、日程表和電子郵件應用交互，而不管網(wǎng)絡的覆蓋率如何)，不管該終端具有較大的資源限制，也不管該連接具有較大的限制。這在

圖1中示意性地示意了。
MobileMQ面向消息的中間件(MOM)通信平臺使得部件能夠有效并高效地存儲將要在部件之間發(fā)送的消息并實際上可靠地將它們發(fā)送出去。MobileMQ MOM使得通過網(wǎng)絡的消息傳遞可靠，無論底層使用的傳輸協(xié)議是否可靠；并且與任何會話無關。該傳輸協(xié)議因此被稱為‘會話無關’的協(xié)議。這又標志著與諸如基于會話的WAP的常規(guī)網(wǎng)絡協(xié)議的主要的不同。因此‘會話無關’(如先前所注明)就與基于會話相對立。當數(shù)據(jù)傳送率降低到低于極限值時或在超時之后基于會話的協(xié)議就會取消會話。協(xié)議就會發(fā)起一次要求交換數(shù)據(jù)業(yè)務的新的會話，該會話(a)在用戶為所傳送的數(shù)據(jù)量付費的無線系統(tǒng)中開銷巨大，并且(b)由于與無線網(wǎng)絡有關的高度可變的帶寬而時常發(fā)生。然而會話無關的協(xié)議不會有意取消連接。(我們在此區(qū)分不同的情況，其中基礎PDP環(huán)境僅僅為了由其他應用使用而釋放或再分配，或者當前基礎PDP環(huán)境丟失或否則超時。在這些類型的情況下，更高層的會話無關的協(xié)議僅僅暫停通信活動，掛起PDP環(huán)境的重新取得-因此它無需重新創(chuàng)建“會話”)。
MobileMQ MOM和會話無關的組合致力于解決很多受連接約束的問題，如圖2所示。
另外，使用會話無關的協(xié)議，因此同樣沒有會話的重新創(chuàng)建；相反，發(fā)送組件一旦知道怎樣將其消息定位到分布式客戶端的接收組件就簡單地重新啟動發(fā)送。這在無線環(huán)境中尤其有用，因為無線裝置根本就沒有(除非并且直到可使用IPv6)持久的IP地址，而是僅能夠通過頻繁改變的任意選擇的IP地址接收基于IP的消息。從而，會話無關很適合使用臨時地址向無線裝置發(fā)送消息的需求，具有應付這些變化的地址所需的最小化開銷，因為它避免了重新創(chuàng)建會話的開銷。
Transcend Mail也采用基于‘事件’的數(shù)據(jù)復制-即保留了所有新的事件的日志，這些事件定義了存儲在客戶端或服務器側(cè)的數(shù)據(jù)的改變，并且僅有這些事件在日志中排隊。當分布式客戶端的每一方之間的連接建立的時候，那么每個排隊的事件(根據(jù)事件的復雜程度由一個或更多消息表示)就被發(fā)送出去，同時還有由一個或更多分組傳送的單個消息。由于MobileMQ允許消息的高效和可靠傳輸，尤其與基于事件的數(shù)據(jù)復制系統(tǒng)相配，其本身只是需要消息的高效和可靠傳輸。
使用MOM的更高層應用并不了解連接的狀態(tài)-即，MobileMQ為MOM層，它將使用MobileMQ的應用從需要了解底層連接存在或不存在情況的應用(如活動的PDP環(huán)境)分離開。在應用層，系統(tǒng)是“連接無關”的。因此術語“會話無關”在應用層在概念上等價于一個系統(tǒng)，其中具有在某種意義上保持著獨立于無論實際的連接是建立與否的單獨會話，即當連接經(jīng)過中斷后重新建立時，應用能夠正好在其停止的同一地點重新發(fā)起消息的傳輸-即，下一個由應用發(fā)送的消息是在沒有連接中斷的情況下應該已經(jīng)被發(fā)送的同一個消息。在基于會話的系統(tǒng)中，這些就不會發(fā)生。相反，首先考慮的是重新創(chuàng)建會話的相當大的開銷。一旦會話重新創(chuàng)建，消息傳輸就重新發(fā)起，即使重新發(fā)起消息傳輸可能也包含前一個傳輸?shù)南?shù)據(jù)的重新傳輸?shù)木薮蟛糠?還是更加非生產(chǎn)性的數(shù)據(jù)傳送。
在MobileMQ中，獲得可靠性(即，能夠保證消息已經(jīng)被接收)無需求助于基于會話協(xié)議的高開銷。反之，我們要求在發(fā)送裝置收到到個別消息已經(jīng)被接收的確認，并在允許另外一個消息被發(fā)送之前在接收裝置進行了適當?shù)奶幚?。這個“消息級別”可靠性更加具有數(shù)據(jù)效率，因為它與基于會話的系統(tǒng)不同，如果連接丟失的話，它只需要重新啟動通信的最小開銷。這是個非常重要的優(yōu)勢，尤其在無線網(wǎng)絡中，其中連接丟失的現(xiàn)象并不罕見。
在現(xiàn)有技術中，在會話啟動時使用高的數(shù)據(jù)傳輸開銷而實現(xiàn)驗證。因為MobileMQ MOM是會話無關的，其轉(zhuǎn)而為每個消息提供驗證“消息級別”的驗證。這可以基于無論裝置是否重新啟動都增加的會話數(shù)量而與會話級別的驗證組合。
當MobileMQ與Trascend Mail組合時對有效處理終端資源和連接約束這兩個問題來說是一種全面而高效的方案，如圖3所示。
圖4示出了組合的設計是怎樣允許由MOM提供通常是由基于會話的系統(tǒng)提供的會話無關的特征以適合諸如智能電話等的受資源限制的終端的目的方式部署的。這些特征包括(a)消息傳遞的可靠性；(b)發(fā)送方驗證；(c)消息安全性；(d)數(shù)據(jù)率流量控制；(e)分組路由。
同樣，圖4示出了組合的設計是怎樣允許特征被設計以適合于分布式客戶端的目的并怎樣解決連接限制的問題。主要的特征是使用基于‘事件’的數(shù)據(jù)，并且由于這個原因得到了作為會話無關的特性。
3、更進一步的核心設計原理3.1分布式客戶端分布式客戶端的目的是允許具有有限的處理容量，功率和連通性的移動裝置通過將通常與客戶端相關的一些功能分布到服務器側(cè)而在移動裝置上使用最小化資源，享受完全功能的客戶端到服務器環(huán)境的訪問的功能，這樣就不受資源限制。該客戶端應用為PIM(日程表，地址簿等)和消息傳遞(電子郵件，MMS，傳真，SMS等)。
實際上，我們具有在大型的客戶端-服務器應用中共同充當客戶端的單獨客戶端-服務器應用。典型的配置是在諸如智能電話的移動裝置(小型客戶端)上安裝軟件和在服務器裝置(小型服務器)上安裝對應的軟件。這兩個軟件與對方通信......通常是通過高延遲，低帶寬，計量的無線連通性，如GPRS或UMTS，經(jīng)由MOM，如MobileMQ。小型客戶端和小型服務器在傳統(tǒng)的客戶端-服務器環(huán)境中共同充當客戶端(“大型客戶端”或“分布式客戶端”)。大型客戶端就像平常一樣與相關的服務器如Microsoft的Exchange(大型服務器)通信。這樣，大型服務器就僅僅知道它在與大型客戶端通信。大型客戶端對大型服務器來說就像其他與之正常通信的客戶端，并且大型客戶端的分布式特性對大型服務器是不可見的。(在一種典型的配置中，假設小型服務器在大型服務器所駐留的同一裝置之上或者附近。)圖5示意性地例舉了這一點。
分布式客戶端內(nèi)部的功能在小型服務器和小型客戶端之間被劃分。這種劃分已經(jīng)被優(yōu)化以利用移動裝置的“智能”特性，同時限制了對裝置的有限資源的影響。
這樣，駐留在移動裝置上的小型客戶端(即，Transcend Mail，在這種情況下與本地的電子郵件應用聯(lián)合工作)通常給終端用戶用作用戶界面，用作本地數(shù)據(jù)倉庫，并承擔了本地的特定數(shù)據(jù)處理的任務。在其它特征中，小型服務器承擔以下功能●在移動的收件箱中顯示郵件列表●用作郵件文本主體的瀏覽器●接收用戶請求以轉(zhuǎn)發(fā)，創(chuàng)建或回復郵件●接收用戶新郵件文本的輸入●響應用戶輸入，將郵件僅從移動裝置存儲器中釋放(釋放動作)●響應用戶輸入，將郵件從移動裝置存儲器中釋放并產(chǎn)生將相同郵件從大型服務器中釋放的通知(刪除請求)●接收最終用戶用于大型服務器登錄密碼的輸入并將其傳送到小型服務器(查看下面關于“分布式登錄”的描述)●監(jiān)測用于那些數(shù)據(jù)(如新建的，修改的或刪除的條目)的變化的本地數(shù)據(jù)倉庫，創(chuàng)建詳細敘述該變化的事件，并將這些發(fā)送給小型服務器。
●從小型服務器接收事件，并使用更改的數(shù)據(jù)的細節(jié)來更新本地數(shù)據(jù)倉庫。
等價或類似的PIM和非電子郵件的功能將在小型客戶端處理/集成到PIM和非電子郵件(例如，其它類型的消息)的地方處理。
與之類似，小型服務器位于其它媒體(典型為連接到大型服務器的LAN)上，通過貫通無線設施(如GPRS)的數(shù)據(jù)網(wǎng)絡連接與移動設裝置通信，通常充當?shù)酱笮头掌?如Microsoft的Exchange)的直接接口并承擔很多通常與大型客戶端相關的數(shù)據(jù)處理任務。在其它功能中，小型服務器承擔以下功能●按照大型服務器的API完成由移動用戶所請求的電子郵件的結(jié)構，獲取從小型客戶端，小型服務器，和如果必要的話從大型服務器接收的組件●獲取來自大型服務器的電子郵件并將這些劃分為部件，僅將這些被認為是嚴格必要的部分發(fā)送到小型服務器●響應來自小型服務器的請求以傳遞其它電子郵件內(nèi)容(如長的電子郵件和/或附件的其它文本)●獲取登錄密碼數(shù)據(jù)(由最終用戶通過小型服務器提供)并將這些數(shù)據(jù)存儲在本地存儲器中，從而實現(xiàn)到大型服務器的擴展登錄(查看以下分布式登錄的描述)●監(jiān)測大型服務器上用于那些數(shù)據(jù)(如新建的，修改的或刪除的條目)更改的本地數(shù)據(jù)倉庫，創(chuàng)建詳細敘述該變化的事件，并將這些發(fā)送給小型服務器。
●從小型服務器接收事件，并在大型服務器上使用變化數(shù)據(jù)的細節(jié)來處理本地數(shù)據(jù)倉庫的更新等價或類似的PIM和非電子郵件的功能可能在小型客戶端運行/集成到PIM和非電子郵件(例如，其它類型的消息)功能的地方得到運行。
這種方法的一個結(jié)果是，在大型服務器上的郵件不能被說成是以常規(guī)推動電子郵件系統(tǒng)的方式“轉(zhuǎn)發(fā)”或“重寄”到設備而是與小型服務器一起，該設備(小型服務器所位于的)僅是到郵件服務器的另外一個客戶端(并且也不僅僅是無線設備客戶端)。
Transcend Mail小型服務器和小型客戶端通過MobileMQ MOM相互通信。如上所注，這使得小型服務器和小型客戶端(在分布式客戶端服務器系統(tǒng)中一起構建大型客戶端)的與眾不同的特征相互之間異步運行。
小型服務器有各種排列方式例如，如圖6所示，小型服務器可以作為終端側(cè)組件實現(xiàn)，該組件包含客戶端側(cè)MOM或與客戶端側(cè)MOM通信；小型服務器就可以作為服務器側(cè)組件實現(xiàn)，該組件包含服務器側(cè)MOM或與服務器側(cè)MOM通信。
圖7展示了小型客戶端是怎樣能夠包含程序—例如，電子郵件應用，和將其連接到終端側(cè)組件的插件。
圖8展示了小型客戶端也可以不包含程序，例如聯(lián)系程序。終端側(cè)組件就通過數(shù)據(jù)庫與聯(lián)系程序通信(使用來自發(fā)送到終端側(cè)組件的數(shù)據(jù)庫的事件觸發(fā))。圖9展示了這在概念上是怎樣等價于中間件結(jié)構的。
3.2分布式登錄分布式客戶端將小型客戶端和小型服務器之間的登錄功能劃分開。小型客戶端從最終用戶的輸入獲取用戶密碼。接收到輸入的密碼后，小型客戶端將這些數(shù)據(jù)發(fā)送到小型服務器。小型服務器將這些數(shù)據(jù)本地保留在存儲器中，然后將該登錄傳遞到大型服務器。
這樣，Transcend Mail在服務器上作為無線終端用戶的代理；它隱藏密碼并執(zhí)行其它登錄相關的動作，這些動作正常情況下是由用戶在與郵件服務器交互操作的時候執(zhí)行。僅有當密碼被郵件服務器認為過期時，用戶才因此需要親自使用新密碼再次登錄。這在安全性方面，比起其它要求作為能夠訪問所有郵件記錄的超級用戶登錄的郵件重定向方法來說是一個大的提高。
以這種方式分布式登錄的另外一個好處是，這樣允許分布式客戶端可以不需其它的登錄活動(和相關的無線數(shù)據(jù)業(yè)務)而繼續(xù)與大型服務器通信，即使在小型服務器和小型客戶端之間的通信中有中斷。這也允許持有和使用移動裝置(可以擁有自己的安全協(xié)議)作為大型服務器登錄活動的替代。一旦小型服務器具有了密碼信息，就有可能復制到大型服務器的登錄，這是在移動裝置的控制是作為登錄信息替代的假設的基礎上的。這允許了分布式客戶端在服務中斷之后無需提示用戶其它密碼數(shù)據(jù)而訪問大型服務器。這樣通過減少與登錄活動相關的數(shù)據(jù)業(yè)務而提供了很多優(yōu)勢，并且也加速了最終用戶對大型服務器的訪問，尤其是在具有便于輸入密碼數(shù)據(jù)的小鍵盤的移動裝置上。
3.3遠程消息結(jié)構Transcend Mail也通過應用遠程構建消息的方法將無線通信的使用最小化。當分布式客戶端從大型服務器“重新獲取”消息時，數(shù)據(jù)中的一些在小型服務器上列隊，而小型服務器就判斷這些數(shù)據(jù)中有多少要發(fā)送到小型客戶端。要發(fā)送到小型客戶端的指定數(shù)量的數(shù)據(jù)會受到最終用戶配置和特定要求的影響。例如，最終用戶可以指定發(fā)送到小型客戶端的電子郵件文本行數(shù)的最大數(shù)目，而最終用戶就可以要求小型服務器發(fā)送其它的文本和/或附件。遠程消息結(jié)構在最終用戶執(zhí)行如回復或轉(zhuǎn)發(fā)電子郵件的操作的時候起作用。當轉(zhuǎn)發(fā)帶有未修改附件的電子郵件時，小型服務器能夠在本地構建電子郵件消息的大部分而不需要來自小型客戶端的完整通信。列隊的消息只是參考由大型服務器具有的相關未修改的數(shù)據(jù)(在本例中，附件)。實際上，小型服務器就只是被要求用來發(fā)送已經(jīng)在小型客戶端裝置上由用戶修改的那部分消息。相同的規(guī)則應用于郵件回復。小型客戶端不需要發(fā)送原始消息的整個主體—小型服務器通過獲取從小型客戶端發(fā)送到小型服務器的新文本并將其與原始電子郵件文本組合來構建全部回復—由于其存儲在大型服務器上而早已為小型服務器所知。結(jié)果，小型客戶端發(fā)布指示，該指示最終導致小型服務器不但從小型客戶端還從大型服務器獲取部分消息而構建整個消息。避免不必要的鍵輸入對于小鍵盤智能電話來說是很有價值的。這些是有效減少小型客戶端和小型服務器之間的數(shù)據(jù)業(yè)務量的兩種方法。
3.4整理處理Transcend Mail也幫助在移動裝置上使用自動內(nèi)存“整理”功能保存存儲器。小型客戶端監(jiān)測移動裝置上非易失存儲器的使用情況。當使用中的非易失存儲器超過了觸發(fā)量(例如，使用中存儲器容量的80％)時，存儲器就在該裝置上自動開始“整理”涉及電子郵件信息的本地數(shù)據(jù)。這包括選擇某些已經(jīng)很長時間沒有在本地訪問的電子郵件，將與這些電子郵件相關的很多數(shù)據(jù)(例如，附件和消息文本)從本地存儲器中釋放，同時在本地存儲器中保留郵件頭信息。使用預先設定的標準比如相關郵件消息的年齡(最老的放在第一位)或用戶訪問這個郵件的歷史來選擇從本地存儲器中釋放的數(shù)據(jù)；很長時間沒有訪問的郵件消息在較新的或新近訪問的郵件消息之前從本地存儲器中移除。
如果相關消息標為未讀，正在打開被用戶瀏覽或其它動作，或者還有從大型服務器要求其它數(shù)據(jù)的涉及郵件的未完成的動作的話，消息數(shù)據(jù)就不從本地存儲器中釋放。
這些移除處理一直持續(xù)，直至小型客戶端檢測到使用中的非易失存儲器已經(jīng)下降到預先設定的“安全”級(例如，使用中存儲器的70％)以下為止。由于大型服務器上保留了所有的郵件數(shù)據(jù)而小型服務器上保留了郵件頭數(shù)據(jù)，郵件數(shù)據(jù)沒有被“刪除”。
移除的數(shù)據(jù)可以通過在用戶的請求(“重新獲取”的動作)下將其再一次從服務器上下載到移動裝置上而重新放置到本地存儲器中。用戶在這種重新獲取發(fā)生之前受到明確的警告。這就允許了用戶有機會判斷重新獲取該消息是否成本有效。
整理功能可包括處理一些情況的安全機構，其中特別大的郵件或者附件可以無需要回顧所下載內(nèi)容而將移動裝置推到整理的觸發(fā)點。換而言之，該設計意味著避免移動裝置可能在郵件被讀取之前就移除郵件的情況。在這種情況下，系統(tǒng)臨時調(diào)整存儲器的觸發(fā)器級別和安全級別以允許最終用戶有重新瀏覽大的入境郵件的機會。
3.5轉(zhuǎn)換的附件下載選項在與服務器共享所復制數(shù)據(jù)的移動裝置中長期具有的困難是用戶怎樣能夠最好的利用有限的內(nèi)存和處理移動裝置上的容量。在移動電子郵件應用中，這個問題常規(guī)(在MS ActiveSync和其他應用中)是通過限制與該移動裝置共享的郵件數(shù)據(jù)的數(shù)量來解決。這種限制通常采取僅復制所限制數(shù)量天數(shù)的郵件數(shù)據(jù)，并限制共享郵件數(shù)據(jù)的大小的方式。限制所復制數(shù)據(jù)數(shù)量的一個通用的方法是拒絕在移動裝置上復制郵件附件。通常，如果最終用戶愿意忍受傳送時間和所涉及的內(nèi)存開銷的話就可以要求下載附件。其他系統(tǒng)已經(jīng)生成了給用戶僅發(fā)送所限制格式的附件文件的方法，該文件就可以在簡單的瀏覽器程序上使用。
Transcend Mail給最終用戶提供了兩個用于將郵件附件下載到移動裝置上的選項。如果用戶希望下載附件的話，他或她就可以在以下下載選項中進行選擇(1)從文件的原始格式轉(zhuǎn)化而來的較小版本(例如，MS Word或PDF文件的純文本版本)，為了使用在無線終端上的瀏覽器程序來單純的瀏覽。
(2)未改變的原始附件。
在Transcend Mail中這些選項在菜單層的相同級上呈現(xiàn)給用戶。
3.6一觸釋放當常規(guī)的移動裝置開始受到舊郵件的阻礙時產(chǎn)生了新的問題。經(jīng)常是當用戶試圖從移動裝置上“刪除”這些郵件時，這些郵件也就在下一個同步從服務器上刪除。在面對用戶需要的時候這可以直接執(zhí)行(fly)-這些用戶僅僅希望釋放移動裝置上的內(nèi)存，并且仍在服務器上保留郵件。為了與之相適應，一些同步系統(tǒng)給最終用戶提供了選項，或者(1)在移動裝置和服務器上都將整個郵件刪除(我們稱為“刪除”指示)，或者(2)僅刪除保留在移動裝置上的郵件拷貝—服務器上保持未修改(我們稱為“釋放”指示)在Transcend Mail中這些選項在菜單層的相同級別上呈現(xiàn)—其他的系統(tǒng)或者在一系列不同的菜單級內(nèi)隱藏了這些選項，或者通過在每次請求刪除時詢問每一個用戶是否最終用戶實際上是想完全刪除還是僅僅清除本地內(nèi)存來執(zhí)行這種選項。這兩種方案都不是對用戶友好的，因為它們都降低了管理移動郵箱的靈活性并且要求輸入多個鍵來完成。
3.7會話無關使用諸如GPRS的技術與移動電信裝置進行的數(shù)據(jù)通信由于高延遲，斷續(xù)而中斷的覆蓋率，和計量帶寬的花費而變得極端困難。常規(guī)的通信方法和協(xié)議并不能很好的適應與這類環(huán)境。例如，通過諸如GPRS的無線鏈路要求網(wǎng)絡連接的應用通常使用TCP連接，因為這種連接提供可靠的基于會話的連接。然而，TCP規(guī)則是開發(fā)用于有線和相對低延遲的連接的，并不是“對無線友好”的。在覆蓋范圍很有限的地區(qū)，可用帶寬降低，而假設網(wǎng)絡擁堵并且““補償”的TCP又加劇了這種情況。這種現(xiàn)象的直接結(jié)果就是通過蜂窩無線網(wǎng)絡的TCP連接并不是有效的傳輸。這導致重新發(fā)送的分組的巨大開銷，該開銷導致緩慢而昂貴的數(shù)據(jù)傳送。另外，類如TCP的協(xié)議依賴于與服務器通信“會話”的概念。如果在已定義的時期內(nèi)沒有業(yè)務量流通(超時)的話，會話通常會過期。建立每一個新的會話都要求另外的數(shù)據(jù)業(yè)務量的使用，而且也都是費時的。
MobileMQ設想了僅使用原始UDP分組傳送的對TCP的無線優(yōu)化代替方案。MobileMQ在(1)使用無線網(wǎng)絡的移動裝置和(2)與該裝置通信(無論是否直接連接到無線網(wǎng)絡)的服務器之間發(fā)送基于UDP的消息，從而使得作為高延遲和斷續(xù)連接的結(jié)果而被浪費的數(shù)據(jù)業(yè)務量最小化。MobileMQ集中于在消息發(fā)送過程中提供高水平的適應力，由此有效保證了消息傳送。
這使用了管理數(shù)據(jù)通信的系統(tǒng)而完成，該系統(tǒng)不依賴于常規(guī)的“會話”概念—它是“會話無關”的。另外，本發(fā)明提供保證消息不但很好的傳遞到目的裝置，而且傳遞到目的應用，同時將所發(fā)送的數(shù)據(jù)業(yè)務量最小化的方法。這增強了保證高度適應力同時具備最小數(shù)據(jù)業(yè)務量的優(yōu)點。
MobileMQ是分布式的是因為其不但位于發(fā)送裝置上而且位于接收裝置上，通常推動了來自同一硬件平臺上的其他系統(tǒng)的消息業(yè)務。
發(fā)送裝置從發(fā)送應用(例如，電子郵件程序)獲取消息—核心通信單元。每個消息限定在意圖優(yōu)化數(shù)據(jù)業(yè)務量使用的最大大小范圍內(nèi)。當發(fā)送應用請求系統(tǒng)發(fā)送消息時，系統(tǒng)首先在位于該發(fā)送裝置上的本地非易失存儲器中保留(存儲)該消息。這就保證了即使該發(fā)送裝置被重啟了消息也能保留下來。該消息就被壓縮并可以選擇被加密。
該消息于是被分段用于發(fā)送。每個段都放置在UDP分組中，每個分組都不超過相對較短的字節(jié)長度，這些涉及底層的低帶寬高延遲的傳輸協(xié)議。在GPRS環(huán)境內(nèi)的典型實現(xiàn)中，UDP分組長度可以限制在1500字節(jié)，因為1500字節(jié)是GPRS分組中的典型最大有效載荷。另外如果UDP分組要占據(jù)，就說，2GPRS片段，那么一個GPRS分組的失敗將意味著兩個GPRS分組都必須要重新發(fā)送。MobileMQ通過將消息縮放以匹配承載分組的消息來避免這一點。
3.8流量控制分片大小和傳送率都是由流量控制系統(tǒng)控制，該系統(tǒng)分析發(fā)往和來自發(fā)送裝置的業(yè)務量并努力在傳輸速度和所傳輸?shù)目偙忍財?shù)之間尋找平衡以保持傳輸成本有效。UDP分組可以由接收裝置以任何順序接收，而該接收裝置在接收到每個分組后發(fā)分組確認。在發(fā)送裝置沒有成功接收到分組確認的地方，流量控制系統(tǒng)就延遲分組重傳直至已經(jīng)經(jīng)過了一個合理的時間間隔。延遲的確切長度依賴于由流量控制系統(tǒng)在發(fā)送裝置上檢測到的網(wǎng)絡響應時間。延遲時間間隔和分組大小都基于所檢測的返回時間中的更改而不斷重新計算。如果分組確認在預定時間內(nèi)接收到了，流量控制就漸漸增加數(shù)據(jù)率直至達到最大值。
流量控制系統(tǒng)也作為經(jīng)常用于數(shù)據(jù)發(fā)送裝置中的常規(guī)“會話”或“超時”概念的替代。如果通信裝置中的一個發(fā)生了嚴重的連接性錯誤(這可能由于，例如，移出了無線基站的范圍或在漫游的網(wǎng)絡之間移動而引發(fā))，流量控制裝置就將這理解為越來越慢的網(wǎng)絡響應，并從而降低傳輸速率。如果服務損耗繼續(xù)的話，流量控制就繼續(xù)延長“重試”之間的時間間隔。直接的影響就是這次傳輸努力就幾乎完全停止，直至發(fā)送裝置開始從接收裝置接收返回的業(yè)務。當更多的回復分組從接收裝置返回到發(fā)送裝置時該過程就顛倒了流量控制系統(tǒng)開始“喚醒”并在其意愿中變得更加愿意發(fā)送分組。當連接變成更加堅固的重新建立時，傳輸速率就再次升高直至其達到合理的理想水平—與嚴格限制包丟失的需求一起平衡整體速度(因為丟失的分組仍可以招致網(wǎng)絡傳輸負荷)。這樣MobileMQ就不依賴于“會話”的概念，也不識別“超時”的概念。
在所有包含消息的分組的接收之后，接收裝置發(fā)送整個消息都已接收的簡要確認。一旦該消息確認到達發(fā)送裝置，發(fā)送裝置就不再試圖進行任何進一步的組成消息的分組的重發(fā)—即使個別的分組確認沒有被發(fā)送到發(fā)送裝置或由發(fā)送裝置接收。這主要是意圖限制數(shù)據(jù)業(yè)務的數(shù)量。消息傳遞序列還不完善。
在發(fā)送了所接收的消息確認之后，接收裝置就將消息傳遞到相關的目的應用(例如電子郵件程序)。接收裝置就等候來自目的應用關于相關信息已經(jīng)被接收并按照由接收應用所使用的任何設定的規(guī)則進行了處理的信號。其目的在于接收應用處理接收到的消息以便其在接收裝置上經(jīng)過崩潰—例如系統(tǒng)重啟之后仍能保留下來。一旦接收應用對其已經(jīng)接收到不可逆的來自MobileMQ的消息感到滿意，接收應用就用該應用已經(jīng)“消耗掉(consume)”該消息的最終確認來響應。來自接收應用的這個最終確認就觸發(fā)MobileMQ的接收裝置側(cè)，以發(fā)送簡要的“消息已消耗掉”的確認到發(fā)送裝置。
一旦發(fā)送裝置接收到了“消息已消耗掉”的確認，就將該信息轉(zhuǎn)發(fā)到發(fā)送應用并就準備發(fā)送來自發(fā)送應用的下一個可用消息。以這種方式，MobileMQ確保了在從發(fā)送應用接收任何其它消息業(yè)務之前的整個消息的傳遞。
MobileMQ能夠同時處理來自多個應用的消息，但是不能夠同時處理來自同一應用的多于一個的消息。
3.9基于事件的數(shù)據(jù)復制服務器和移動裝置之間的同步常規(guī)是使用相對較高的帶寬，較低的延遲，無計量的連接性(如USB或IR)而進行。其結(jié)果是，同步系統(tǒng)經(jīng)常使用發(fā)送大量數(shù)據(jù)而且當數(shù)據(jù)在發(fā)送過程中丟失或者底層的通信被中斷時并不健壯的方法。例如，基于服務器的數(shù)據(jù)集同步通常要求所有相連的裝置通過單獨的會話將其整個數(shù)據(jù)集(例如，所有的電子郵件，所有的聯(lián)系等)下載到服務器，這就會執(zhí)行與上一次完整同步的數(shù)據(jù)集的主拷貝的比較以更新主數(shù)據(jù)集并從而更新其它的數(shù)據(jù)集。由于其強加的功率損耗，潛在的長連接時間和昂貴的數(shù)據(jù)傳送代價，這種方法對于同步無線裝置來說并不吸引人。
在Transcend Mail中，代替無線裝置下載其整個數(shù)據(jù)集的是，它僅將數(shù)據(jù)集的更改(或新的“事件”)記錄進日志(優(yōu)選但不必須為以時間順序)，并在連接到服務器時將這些事件的日志發(fā)送到服務器。事件提供足夠的細節(jié)以使數(shù)據(jù)復制無需同步引擎的需求而發(fā)生；數(shù)據(jù)復制(與真正的同步相對)通過發(fā)送事件而不是發(fā)送在小型服務器中由同步引擎所存儲的用于同步的數(shù)據(jù)的整個數(shù)據(jù)集(或數(shù)據(jù)集的子集)而更加簡單的完成。
只要在裝置上的記錄發(fā)生了改變(例如，創(chuàng)建了新的郵件并從設備上發(fā)送；老的郵件被刪除；新的聯(lián)系被創(chuàng)建等)，定義正好這個事件或者更改的條目就在以時間順序的日志里存儲在服務器上；這個事件日志就一直存儲直至連接出現(xiàn)，在這時日志內(nèi)容就被發(fā)送到服務器，從而更新了有關數(shù)據(jù)集的主拷貝。例如，時間可以是‘刪除記錄no.x’或在記錄‘z’中刪除字段‘y’。這些對于接收方來說為了在產(chǎn)生該事件的發(fā)送方復制該更改是足夠的信息。
對設備來說不需要傳遞整個數(shù)據(jù)集來判斷已經(jīng)更改了的記錄或保證單個會話的維持，同時數(shù)據(jù)集被發(fā)送和接收。在服務器上數(shù)據(jù)集的任何改變(例如，新郵件的接收)也作為事件日志存儲并且該日志使用MobileMQ發(fā)送到無線裝置。因為只生成和交換了相對較小的事件日志，CPU和數(shù)據(jù)傳送開銷要遠遠小于常規(guī)的同步機制。
從而，當要復制的數(shù)據(jù)被輸入，修改或刪除(在大型服務器或小型客戶端上)時，發(fā)送裝置就在發(fā)送裝置上創(chuàng)建“事件”并將“事件”記錄到日志。
事件就作為一個或更多的消息發(fā)送到接收裝置；消息使用UDP分組傳送而并非更常規(guī)的TCP發(fā)送。同時TCP提供可靠的連接并通常成為商業(yè)活動的焦點，它對于無線來說不是(如上所釋)有效的傳輸，因為在感知到網(wǎng)絡擁堵的時間內(nèi)其有明顯的補償，這種現(xiàn)象在無線覆蓋率很有限的時候并不罕見，并會導致重新發(fā)送分組的巨大開銷，導致慢而昂貴的數(shù)據(jù)傳遞。為了高效性，UDP將UDP分組大小限制在1400字節(jié)—恰好在GPRS中可用的傳輸分組大小之下(見上面)。
接收裝置將定義了事件的個別信息傳遞到相關目的應用(如電子郵件程序)。發(fā)送裝置就等待來自目的應用關于定義了事件的相關信息已經(jīng)被接收到并按照由接收應用使用的任何設定的規(guī)則進行了處理的信號。其意圖在于接收應用處理接收到的消息以便其在接收裝置內(nèi)的崩潰—例如系統(tǒng)重啟之后還能保留下來。一旦接收應用對其已經(jīng)不可逆接收到消息感到滿意，接收應用就響應該應用已經(jīng)“消耗掉”該消息的最終確認。來自接收應用的這個最終確認就觸發(fā)接收裝置方以發(fā)送簡要的“消息已消耗掉”的確認到接收裝置。
一旦發(fā)送裝置接收到了“消息已消耗掉”的確認，它就對所有定義了事件的消息重復該處理，直至消息已經(jīng)在接收裝置上被安全接收并‘消耗掉’為止。然后它就從發(fā)送裝置內(nèi)存中刪除[事件指示信息？]來終結(jié)“事件”處理。它對事件日志或列隊里的所有其它事件都重復這種處理。
以這種方式，Transcend Mail確保了從發(fā)送應用接收任何其它消息業(yè)務之前的整個消息的傳遞。同時處理來自多個應用的消息是可能的，但是不能夠同時處理來自同一應用的多于一個的消息。
因此整個的事件可以通過無線鏈路可靠發(fā)送，盡管是使用了不可靠的UDP。
3.10 A/B/X標志系統(tǒng)也會通過使用帶有三個狀態(tài)選項A，B或X的標志給每個消息編碼而預防重復的消息發(fā)送。在常規(guī)的操作中，每個消息[來自應用]由發(fā)送裝置使用可選的A或B標志發(fā)送。當接收裝置開始接收消息時，就將A或B標志寫入到本地存儲器中。當接收來自發(fā)送裝置的完整消息和來自發(fā)送應用的已消耗掉信號時，接收裝置就將恰好在發(fā)送消息完成/消息已消耗掉確認之前處理的消息的標志識別寫入到本地存儲器。如果接收裝置在發(fā)送消息完成/已消耗掉確認信號之后，但是在確認被接收回來之前重啟，那么它就不會知道所消耗的消息是否已經(jīng)被完整的接收。但是如果對關于給定消息的確認序列使用一類標志做出了標記的話，那么它就會知道任何返回的確認為了要與之相關都必須要符合該標志。具有不同標志的確認必須涉及下一個消息并且從而不應該被處理到。
X標志意味著接收裝置忽略該標志，并且沒有標志被寫入到接收裝置的存儲器。其目的在于如果發(fā)送應用不關心重復消息發(fā)送的風險則給發(fā)送應用使用X標志。
3.11客戶端裝置定位與網(wǎng)絡更新在很多現(xiàn)有的移動數(shù)據(jù)網(wǎng)絡(如那些使用GPRS的)上發(fā)送數(shù)據(jù)傳輸?shù)揭苿友b置非常困難，因為移動裝置沒有固定的IP地址。相反，當移動裝置連接到網(wǎng)絡上時(在本地網(wǎng)絡或漫游網(wǎng)絡)，網(wǎng)絡運營商就給這些設備動態(tài)的分配IP地址。此外，動態(tài)分配的地址通常是私有IP地址，不能在公共因特網(wǎng)上直接使用。而是，來自該設備的數(shù)據(jù)業(yè)務量被網(wǎng)絡運營商發(fā)送到網(wǎng)絡地址轉(zhuǎn)換(NAT)，而NAT將私有IP地址映射到公共IP地址和從非常有限的公用地址(有時只是兩個)列表中抽出的臨時端口號和一大組由網(wǎng)絡運營商使用的可用臨時端口號(通常是幾千)。
這樣即使移動裝置將同一個動態(tài)分配的IP地址和臨時端口號保留了很長時間(例如幾個小時)，也可以利用由網(wǎng)絡運營商分配的多個“公用”IP地址和臨時端口號。此外，雖然移動裝置知道由網(wǎng)絡運營商給它分配的私有IP地址，它也沒有由NAT分配的公用IP地址和臨時端口號的記錄。從任何一個與移動裝置通信的裝置的觀點來看，他們都只能“看到”由NAT分配的公用IP地址和臨時端口號。這就給任何一個希望發(fā)起并發(fā)送一個數(shù)據(jù)消息用于傳輸?shù)绞褂眠@樣一個網(wǎng)絡的移動裝置的人帶來了巨大的挑戰(zhàn)，因為不能確保最后了解的公用IP地址和與給定裝置相關的臨時端口號在多于幾分鐘的時間內(nèi)都還是有效的。
MobileMQ有規(guī)律地給小型服務器提供網(wǎng)絡地址數(shù)據(jù)以實現(xiàn)消息從小型服務器到移動裝置的例行發(fā)送。實現(xiàn)的例子將包括使辦公室郵件服務器發(fā)送郵件業(yè)務到移動用戶而無需移動用戶的介入。
該方法包括基于以下任何事件的發(fā)生而從移動裝置發(fā)送非常短的消息(‘網(wǎng)絡更新’)到小型服務器●當移動裝置第一次打開并從移動網(wǎng)絡運營商獲取地址時；
●當移動裝置從網(wǎng)絡運營商接收新的地址時(可能作為從本地網(wǎng)絡覆蓋到漫游網(wǎng)絡或者在漫游網(wǎng)絡之間移動該裝置的結(jié)果)；●無論是否分配新的地址到移動裝置，以規(guī)律的時間努力獲得可能由介入的NAT分配的新的公用地址和臨時端口號，并將這個新的公用地址和臨時端口號通知到小型服務器通過接收短的網(wǎng)絡更新消息，小型服務器記錄分組的原始IP地址和臨時端口號(將是來自NAT分配的公用IP地址和臨時端口號，假設有關的一方不直接連接到相同的私有IP網(wǎng)絡)并將這種信息輸入到反向查詢表。
由于假設以計量為基礎對數(shù)據(jù)業(yè)務收費，網(wǎng)絡更新消息特意很短。典型的實現(xiàn)可能包括只有17字節(jié)的由移動裝置發(fā)送的數(shù)據(jù)和在每個網(wǎng)絡更新消息周期中返回的5字節(jié)(假設沒有分組丟失)。
這些消息中的每個是用于確認(1)公用網(wǎng)絡地址的持續(xù)有效性和(2)移動裝置可以用來接收業(yè)務量。
小型服務器就能夠通過給在反向查詢表中發(fā)現(xiàn)的裝置使用最近的地址而嘗試其自己—未提示的—到移動裝置上的小型客戶端的數(shù)據(jù)傳輸，假設分配的公用IP地址和臨時端口號從網(wǎng)絡更新消息的時間開始沒有再次分配。于是，在小型服務器上來自該裝置的網(wǎng)絡更新消息的接收作為啟動發(fā)送在事件日志中列隊的任何事件的觸發(fā)器(查看基于事件的數(shù)據(jù)復制部分3.9)。可以配置系統(tǒng)以便只有在網(wǎng)絡更新被接收到的時間上出現(xiàn)在日志中的事件才被發(fā)送；任何晚一點的事件都必須等待，直至收到了下一個網(wǎng)絡更新。這與連續(xù)推動電子郵件不同。
反向查詢表中的登錄也是限時的，并且如果多于一定數(shù)量的時間已經(jīng)流逝了的話小型服務器就假設不再可能發(fā)送消息到小型客戶端，直至接收到新的網(wǎng)絡更新消息。在這種情況下，來自小型服務器超出范圍的消息就保持在隊列里，直到接收到新的網(wǎng)絡更新消息。時間被設置為基本上少于NAT使用來重新分配公共IP地址到移動裝置的正常時間間隔(例如，如果NAT重新分配時間間隔為20分鐘的話就是5分鐘)。系統(tǒng)可以動態(tài)調(diào)整該時間以便當具有很高的網(wǎng)絡使用率時，相關具有短得多的NAT重新分配時間間隔，那么該時間就可以縮短。
總的來說，這意味著小型服務器和小型客戶端能夠建立時間窗口，在此期間對小型服務器來說可能發(fā)送業(yè)務到小型客戶端。該窗口在網(wǎng)絡更新消息的時間上開始，并在預先編入程序的空閑時間過期的時候結(jié)束。例如，如果網(wǎng)絡更新消息每60分鐘由小型客戶端發(fā)送，而空閑時間設置為10分鐘，這就導致不超過60分鐘的期間內(nèi)復現(xiàn)的10分鐘通信窗口。通過提高網(wǎng)絡更新消息的頻率，小型客戶端也可以給小型服務器創(chuàng)建更多或更少的連續(xù)通信傳輸機會。
3.12安全性現(xiàn)存的通過非安全數(shù)據(jù)通信設施(如SSL)的端對端通信保證安全的安全性方法由于很多因素，包括高處理器開銷，高帶寬開銷，低延遲，和動態(tài)分配地址信息到移動裝置等，不能夠很好的適應移動遠程通信環(huán)境。
MobileMQ使用專門設計用于移動電信裝置的加密實現(xiàn)來在移動裝置和服務器之間提供安全的端對端消息傳遞。
該過程在系統(tǒng)第一次安裝到移動電信裝置上時開始。移動裝置(例如，連接到無線網(wǎng)絡上的移動郵件閱讀器)和服務器(例如，連接到固定有線因特網(wǎng)服務的共同郵件服務器)都使用共享的私密信息加載。為了在它們之間安全的通信消息，發(fā)送裝置(移動電信裝置或是服務器)首先通過使用哈什函數(shù)從下述輸入計算哈什(hash)來計算消息密鑰●對相關移動裝置唯一的編碼，例如GSM電話聽筒的IMEI編碼(如果移動裝置是發(fā)送裝置的話就使用它自己的唯一編碼，如果服務器是發(fā)送裝置的話就使用有意圖接收裝置的唯一編碼)●共享的秘密信息，和●可以由發(fā)送和接收裝置二者獨立計算的其他涉及(但是不必需要唯一)每個消息(即，增加的消息號，應用/端口號，和會話號)的數(shù)據(jù)這個密鑰就在對稱加密算法中用于加密消息。這樣每個消息使用密鑰序列加密，該序列在算法上涉及各自的移動裝置識別碼，安裝在移動裝置和服務器上的共享秘密，以及其他可以由發(fā)送和接收裝置獨立獲取的在算法上涉及每個消息的數(shù)據(jù)。
為確保所加密消息的正確性和完整性，發(fā)送裝置就會使用用密碼寫的哈什函數(shù)計算消息身份驗證碼(‘MAC’)，其中輸入為消息本身和用來加密消息的密鑰。作為結(jié)果的MAC值就被附加到加密消息中。
接收裝置給相關消息計算第一哈什函數(shù)(密鑰)(基于移動裝置唯一編碼號，共享秘密，和其他業(yè)務數(shù)據(jù)的確認)，并使用這個密鑰來解密該消息。最終，接收裝置獲取解密的消息和該密鑰并使用這些來計算第二哈什值用于與附加到信息上的MAC值比較。如果第二哈什值與和消息一起接收的MAC值相同的話，那么就會假設消息可信且沒有發(fā)生改變。另一方面，如果由接收裝置計算的第二哈什值不符合與消息一起接收的MAC值的話，那么接收裝置就努力向發(fā)送方發(fā)出詢問來重新創(chuàng)建安全通信。一旦安全性已經(jīng)建立，就會觸發(fā)消息的重傳。這樣驗證系統(tǒng)作為備份的角色來確保消息的數(shù)據(jù)完整性—傳輸中任何細小的錯誤都會導致MAC值的失敗，安全性詢問和消息的重傳。
在保證了消息本身的機密性，正確性和完整性之外，如果第三方試圖假扮為合法的移動裝置用戶，安全性系統(tǒng)也用來降低成本和對移動裝置用戶的性能影響。
小型服務器保持具有分配給該移動裝置的最新報告的地址(和臨時端口號)的反向查詢表。(查看在3.11部分中網(wǎng)絡更新的描述)小型服務器假設所有來自移動裝置的范圍內(nèi)的分組應該是來自與在該小型服務器反向查詢表中所列的裝置的當前合法的地址和端口號相符合的地址和端口號，該小型服務器基于此假設而運行。
如果接收到聲稱來自同一移動裝置，但是具有新的返回地址(和/或新的臨時端口號)的數(shù)據(jù)，小型服務器就使用上面所列出的相同加密機制發(fā)布安全性詢問到位于新地址的該裝置上。如果新的地址對該詢問返回正確的答案，那么小型服務器就繼續(xù)處理來自新地址的范圍內(nèi)的業(yè)務，并使用新地址更新反向查詢表。常規(guī)來說這只有在移動裝置以該移動裝置不了解更改的方式而被分配了新地址或臨時端口號的時候才會發(fā)生(例如，如果網(wǎng)絡運營商NAT box做了這樣的分配的話)，因為通知到移動裝置的更改已經(jīng)觸發(fā)了網(wǎng)絡更新消息。(查看3.11部分中網(wǎng)絡更新的描述。)另一方面，如果新地址不能夠正確地響應安全性詢問，那么小型服務器就不更新反向查詢表而只是忽略從新地址接收到的數(shù)據(jù)；(這可能會在，例如，惡意的第三方試圖通過發(fā)送欺瞞數(shù)據(jù)業(yè)務到小型服務器而中斷到合法移動裝置的通信的時候發(fā)生)與合法裝置的通信(在舊地址上與舊的臨時端口號)保持不中斷并且不需要使用到舊地址的其他詢問來重新創(chuàng)建安全性。沒有不被希望的數(shù)據(jù)業(yè)務從小型服務器上產(chǎn)生發(fā)送到小型客戶端；這很重要，因為，使用很多GPRS和UMTS價目表，用戶的花費依賴于所接收數(shù)據(jù)業(yè)務的量，所以能夠在小型服務器上禁止拒絕服務進攻就很有價值。
由于安全性詢問和應答使用相對大量的處理時間和數(shù)據(jù)傳遞，這個系統(tǒng)對合法用戶將具有巨大的花費和性能優(yōu)勢。
3.13終端應用鎖移動通信終端(例如使用GPRS的“智能”電話)對作為其主要通信服務器(例如雇主操作的商業(yè)郵件服務器)的移動用戶和組織呈現(xiàn)出一定的安全性風險。裝置的丟失可以導致到通信應用(例如郵件客戶端應用)的未授權的訪問，就有可能對提供后臺服務器容量的最終用戶和組織二者都產(chǎn)生負面的結(jié)果。此時，安全性風險由各種系統(tǒng)解決(1)給到移動裝置本身的訪問加鎖—通常是在最終用戶的請求之下，(2)依賴于移動運營商來拒絕與該裝置通信，或(3)拒絕到主通信服務器的遠程訪問。第一種方法對最終用戶來說不方便，因為給裝置加鎖可能讓用戶不能訪問位于該裝置上的其他應用。第二種方法依賴于移動運營商分塊指示的經(jīng)常變化并且適合的實現(xiàn)方法。在與移動裝置無關地進行無線網(wǎng)絡驗證的情況(如使用SIM卡的GSM網(wǎng)絡)下，該方法進一步受限—擁有該裝置的人仍可以訪問本地駐留的數(shù)據(jù)。第三種方法有缺陷，因為它只是阻止了到組織服務器的訪問，并不能阻止到本地駐留在移動裝置上的數(shù)據(jù)的訪問。
Transcend Mail提供了一套系統(tǒng)來在預先描述的環(huán)境下“鎖住”整個通信應用的操作以保護能夠?qū)ο鄳耐ㄐ欧掌髯龀龇磻淖罱K用戶和組織，而不需通常從移動裝置發(fā)送業(yè)務的無線網(wǎng)絡運營商的干涉。
在移動裝置上到相關通信應用的訪問可以僅在最終用戶已經(jīng)在移動裝置上輸入了合適的加鎖編碼之后進行。系統(tǒng)可以指定最小編碼長度，但是另外允許最終用戶改變該加鎖編碼。組織管理員(也管理著Transcend Mail服務器)也可以在遠程基礎上更改加鎖密碼，從而如果最終用戶忘記編碼或者該裝置丟失或被偷了的話可以實現(xiàn)編碼的重新設定。這就保護了位于該裝置上的電子郵件，也保護了郵件服務器，但是是在組織的控制之下，而不是最終用戶或網(wǎng)絡運營商—有嚴格的區(qū)分。
在加鎖狀態(tài)下，應用鎖可以通過將合適的加鎖編碼輸入到移動裝置上而不被激活。
如果加鎖編碼本地存儲在移動裝置上，就可以基于以下輸入使用加密的哈什值來存儲●用于移動裝置的唯一的裝置ID(例如GSM手機上的IMEI碼)●密鑰●解鎖碼這樣，鎖就不會僅僅通過從一個裝置上獲取哈什計算的編碼值并在另外一臺裝置上替換存儲的哈什值而被輕易的破解。
在解鎖之后，應用鎖就由一些的不同事件觸發(fā)，如●經(jīng)過了一段時間沒有訪問該應用(預先設定的空閑時間)●由系統(tǒng)管理員所做的加鎖碼的遠程更改●最終用戶請求應用加鎖
●移動裝置或有關應用由于任何原因重新啟動或者重新開始●引導應用進入加鎖狀態(tài)的遠程消息如果應用處于加鎖狀態(tài)，最終用戶就不能訪問本地數(shù)據(jù)并且也不能夠訪問遠程服務器。
附錄I附錄1列舉并討論了與MobileMQ和Transcend Mail系統(tǒng)關聯(lián)的各種其他觀點。Vega是Transcend Mail的早期名稱。
1.來自不同類別的消息的獨立傳送描述對不同類型的消息的不同傳輸‘信道’的使用，以確保某個消息類型以更加及時的方式發(fā)送，例如●新的消息信道●其他主體文本信道●附件信道這些信道的使用意味著新的郵件可以部分傳送，無論附件和主體文本是否被重新獲取。
分析這個概念已經(jīng)用于分離屬于不同應用的數(shù)據(jù)的傳送—例如，郵件具有區(qū)別于由聯(lián)系或日程表所使用的信道，并且是通用的復用技術。
然而，在現(xiàn)有技術中，使用這種技術來加速單個應用內(nèi)的通信并不是顯而易見的。
使用這種技術的優(yōu)勢在于發(fā)送或接收大的郵件可能不會阻止與大型消息的后臺傳送同時發(fā)生的與較短消息的更加交互式的經(jīng)歷。超過一定大小的消息可以通過不同的消息信道傳送，并且會與用于較短消息的單獨信道公平的競爭帶寬。這樣在發(fā)送大郵件之后開始發(fā)送的較小郵件可以在大郵件之前完成傳送。對于特別大的郵件，這可能意味著對小郵件的響應在大郵件完成傳送之前就被接收到。這在很多并發(fā)郵件系統(tǒng)中是不可能的，所有的這些系統(tǒng)中郵件無論大小都要列隊。
一些郵件系統(tǒng)可以與郵件中繼(mail relay)并發(fā)連接—給每一個郵件建立一個—但是還是沒有基于大小給郵件‘分類’。
2.‘魔力(magic)’郵件地址描述將由服務器轉(zhuǎn)換成確定的電子郵件地址的識別符字符串的使用?，F(xiàn)在這具有兩個方面●在‘回復’或‘轉(zhuǎn)發(fā)’郵件中的字符串<all>由Vega服務器解釋為要去到原始郵件并對新消息的‘Cc’域增加消息所有的接收者。
●將‘好友名稱’增加到終端上的郵件中。當郵件被發(fā)送的時候，沒有確認為有效郵件地址的所有文本字符串就與交換器中名單的名稱比較，如果找到了相符的，該名稱就被翻譯成那個用戶的郵件地址并發(fā)送過去。
分析使用固定字符串代替郵件地址使其具有依賴于以前郵件內(nèi)容的含義，這還是可能較新的東西。
這樣的字符串的使用有效的組成了直接發(fā)往服務器來完成新郵件尋址的‘命令’，基于一些服務器所知道的以前郵件的內(nèi)容。在這種情況下，該命令是‘回復所有’，該‘內(nèi)容’是在以前的郵件中的郵件地址列表，而‘以前的郵件’是客戶端正在做出反應的那些郵件。地址列表或郵件本身都不需要因為這個概念而保留在客戶端上工作。所需要的只是對以前郵件的引用(如，郵件頭)，以使客戶端對其具有某類句柄。
允許使用短的(或‘友好的’)名稱代替在傳遞給接收方之前由客戶端或服務器解析的郵件地址是常用的慣例。然而，在無線，分布式客戶端的領域內(nèi)這還是新的概念。
3.啟用/禁用描述不影響遠程另外一端的列隊而禁用本地列隊的能力。
分析這個功能的目的是允許同級在一個或兩個方向上暫時掛起對事件同步的預定。這可能應用于一個，更多或所有的信道。
這個功能的例子包括●用戶掛起聯(lián)系同步，同時執(zhí)行可能另外產(chǎn)生過度業(yè)務量而無法保持遠程端同步的本地維護(例如，刪除不需要的條目；在本地，與PC電纜同步)●在每個用戶的基礎上管理員掛起服務，以控制成本或阻止濫用4.預定的隊列加法描述執(zhí)行將導致條目列隊用于傳輸?shù)膭幼鞯哪芰?，不需要立即發(fā)送該條目。例如，當Vega禁用時創(chuàng)建郵件。該軟件不會試圖發(fā)送郵件直至Vega重新啟用。
分析這個功能在郵件客戶端中不是新的了，無論是有線或無線。然而，當應用于無線，分布式客戶端領域內(nèi)時這還是新的功能。
5.自動/手動模式操作描述在自動和手動連接模式之間切換的能力。
分析表面上，這個功能在郵件客戶端中不是新的了，無論是有線或無線。然而，還存在這個特征的確保調(diào)查的方面。
概念上與Outlook Express所提供的類似，用戶可以以固定的時間間隔檢查郵件，或者只是對用戶界面上按下一個按鈕作出響應。
然而，這樣的系統(tǒng)是輪詢系統(tǒng)，其中在定時器超時或由用戶界面激活時執(zhí)行明確的輪詢。在Vega中該功能應用于一種推動解決方案，其中定時選項或手動激活指的是‘打開門’了一段允許條目推入的預定時間周期。這個概念在無線，分布式客戶端領域內(nèi)還是新的。
6.在線附件置換描述使用聲明真正的附件不能被重新獲取的原因的管理消息代替附件的‘占位符’的能力。
分析這個功能在郵件服務器中不是新的—例如，一些服務器側(cè)的病毒掃描器會在郵件字符串的主體文本內(nèi)部呈現(xiàn)管理消息，該郵件聲明由于病毒感染沒有發(fā)送附件的原因。
然而，還有很多原因?qū)е赂郊]有發(fā)送到無線，分布式客戶端。
可以選出一些原因●大小超過了管理員設定的大小●用戶不打算下載附件(例如由于成本控制的原因)一些可能是因情而定●附件不與終端兼容，并且不能由服務器轉(zhuǎn)換●附件感染了病毒●附件在以前已經(jīng)被刪除7.遠程附件表示描述顯示附件表示，以示出附件沒有物理性地附加到郵件上，但是將在最終傳送之前附加。也在發(fā)送文件夾中，附件被發(fā)送的表示，不需要保持該附件的本地拷貝。
分析表面上，這個功能在郵件客戶端中不是新的了，無論是有線或無線。
對一些郵件客戶端的特征來說顯示紙夾子或其他圖標來表示具有附件的方法都是類似的。在IMAP4客戶端中，附件可以或不可以實際出現(xiàn)。
然而，這個特征在無線，分布式客戶端領域內(nèi)是新的—尤其如果與指示組合在一起的話，通過不同的圖標或通過本地包含的說明性主體文本來表明附件存在或者其他方面。
8.郵件接收方列表切斷描述郵件消息的其他接收方的數(shù)量的顯示，不需要給每個接收方發(fā)送解析的郵件地址。
分析這個功能在無線，分布式客戶端領域內(nèi)是新的。
其目的在于當展開的列表中的用戶數(shù)目超過了一定數(shù)時(例如，10)，郵件的接收方可能不關心列表中實際的個別用戶。這樣，數(shù)據(jù)量就通過不在郵件頭中包含其他接收方的姓名和郵件地址而得到減小。用一個更加簡單的文本條(如，“38個其他接收方”)來代替。接收方的整個列表可以應要求而下載。
特定的文本不會影響用戶‘回復所有’，由于真正的郵件中服務器還是知道真實的地址。
9.調(diào)用安全性時的內(nèi)容隱藏描述通過用戶使用可選的視圖隱藏屏幕上用戶數(shù)據(jù)的功能。這是用來當終端進入‘密碼詢問’或‘應用鎖住’狀態(tài)時隱藏所有用戶數(shù)據(jù)的。
分析這個功能在無線，分布式客戶端領域內(nèi)是新的。
這個功能的目的是隱藏特權信息直至獲得批準的人完成了安全性詢問。其目的在于防止屏幕上信息的被竊。
10.智能用戶創(chuàng)建列表描述給管理員提供適合Vega帳戶創(chuàng)建的用戶列表的功能。實際上這意味著去到現(xiàn)行目錄，根據(jù)用戶所在的服務器存儲用戶，無論該用戶的Vega帳戶是否早已存在。合成的列表(在‘新用戶’UI中顯示)僅顯示可以具有Vega帳戶的用戶。
分析使用適合于用戶中的每個或所有的特征而將用戶列表分類的能力不是新的了。然而，在無線領域內(nèi)這個功能的應用還是新的，尤其在該列表代指沒有與分布式客戶端一起配置的用戶的情況下。
11.定制的事件日志描述來自1個或更多遠程服務器的日志信息的顯示，已過濾以便只有與產(chǎn)品相關的事件才被顯示。
分析遠程顯示遠程服務器的已過濾日志信息的能力不是新的了。然而，這種情況下的‘服務器’是在大型客戶端/服務器系統(tǒng)中包含客戶端的分布式系統(tǒng)的組件。遠程顯示不是該客戶端/服務器系統(tǒng)的部分，也不是分布式客戶端的部分。這是新的技術。
12.文件級的OEM定制描述不必須重新編譯任何核心二進制文件而給新的OEM合作者定制產(chǎn)品的能力?！癘EM”文件的代替品是被要求定制產(chǎn)品的文件。
分析定制軟件的能力—在預先定義的范圍內(nèi)—而不需重新建立二進制文件且不需訪問源代碼，這不是新的概念。
然而，應用于無線，分布式客戶端/服務器系統(tǒng)的一個或更多組件的這項技術還是新的。
13.‘智能’列隊描述根據(jù)使用用于分析隊列內(nèi)容的‘智能’算法增加，記錄，替換和/或從未完成的發(fā)送隊列中移除條目的能力。
分析為了降低所需的數(shù)據(jù)傳送量而對發(fā)送隊列的內(nèi)容合并不是新的概念了。例如，如果隊列包含后面有立即刪除的新聯(lián)系，簡單的算法就可以檢測到這種情況并將新聯(lián)系和其刪除選項一起移除，因為二者有效地互相抵消。
然而，應用于無線，分布式客戶端/服務器系統(tǒng)的一個或更多組件的這項技術還是新的，尤其是由于其目的在于減少通過計量的網(wǎng)絡傳送的數(shù)據(jù)量。
14.在發(fā)送之前重新獲取刪除描述在數(shù)據(jù)傳送開始之前取消重新獲取請求的能力。
分析這與從發(fā)信箱中移除條目的能力相類似，并且可以應用于郵件，聯(lián)系和議程條目。當然這不是新的概念了，因為很多郵件和組件客戶端都提供這種功能。
然而，應用于無線，分布式客戶端/服務器系統(tǒng)的一個或更多組件的這項技術還是新的—尤其是由于在‘發(fā)信箱’中的條目的目的地不是郵件或組件服務器，但另外一個組件是分布式客戶端。只有在發(fā)送到遠程組件分布式客戶端之后，條目才真正的進入到一些其他目的地的‘發(fā)信箱’未完成發(fā)送(例如在因特網(wǎng)上)。這是可以由這個功能取消的初始傳送。
15.輪詢和推動(push)用戶描述在單個的組織或裝置內(nèi)創(chuàng)建‘輪詢’和‘推動’操作用戶帳戶的能力。
分析這項功能允許一些用戶在真正的推動模式下操作，其他用戶在嚴格的輪詢模式下操作，而其他的用戶根據(jù)輪詢的頻率在‘有效推動’的模式下操作。
這個概念在普通的郵件客戶端不是新的了—用戶對郵件傳送的偏好的選擇通常不對用戶所做的選擇有任何影響。
然而，●這項功能應用于尤其是在無線領域內(nèi)運行的Vega。這種系統(tǒng)通常如適用于該系統(tǒng)的設計哲學所指示，是“全部推動”或“全部輪詢”。
·術語“推動”和“輪詢”應用于分布式客戶端內(nèi)部的通信—而不是在大型客戶端/服務器模型內(nèi)部，在這種系統(tǒng)中總是‘推動’。
從而，這是全新的概念。
16.預定(provisioning)邏輯描述基于關于用戶所選帳戶和連接手機的信息而修改，否決或拒絕手機預定處理的能力。
分析這項發(fā)明的目的在于基于由現(xiàn)存的帳戶狀態(tài)和所連接手機的狀態(tài)直接給用戶提供打開給他看的可能選項的列表。
這個概念可能不是新的了，然而，這項發(fā)明的應用在于分布式客戶端模型的兩個組件和它們之間鏈路的鍛造和中斷●如果所選擇的用戶帳戶被允許使用Vega但是不具有分配的手機○如果該手機正分配給另外一個用戶■沒有可能的配置管理員必須移除該分配○如果當時沒有提供手機■安裝該軟件并執(zhí)行基本的同步●如果所選擇的用戶帳戶被允許使用Vega并且具有分配的手機○如果該手機當前分配給該用戶■如果必要的話修復手機軟件安裝■如果希望的話保持手機不被修改○如果該手機當前分配給另外一個用戶■沒有可能的配置管理員必須移除該分配○如果當前沒有提供該手機■修改該分配；該用戶的當前手機被擦除■安裝了該軟件并執(zhí)行基本的同步●如果所選擇的用戶帳戶不被允許使用Vega○該用戶的進一步操作不被允許17.擦除手機描述發(fā)送將會導致所有數(shù)據(jù)從用戶裝備上移除的命令給該用戶裝備的能力。
分析這項命令的目的是鼓勵裝備上的所有數(shù)據(jù)的遠程刪除。管理員在該手機丟失或者被偷的情況下會更愿意采取這類行為。用戶很少會這么做以防止其裝備變成毫無功能的。
這項特征是新的，尤其在無線，分布式客戶端領域。
18.數(shù)據(jù)傳送時間戳描述上一次數(shù)據(jù)被發(fā)送或從用戶終端接收的時間戳的存儲和顯示。
分析這項特征的目的在于記錄上一次從分布式客戶端的遠程組件接收的數(shù)據(jù)傳送時間和日期。這給用戶對系統(tǒng)在任何應用數(shù)據(jù)不具備的條件下工作提供了方便的檢查方式。
這項特征的大的單元對能勝任的人來說相當明顯。然而，由于底層傳輸?shù)牟豢煽勘举|(zhì)，不可能決定上一次從終端到服務器的傳送的確切時間，然而，由于任何方向上的所有通信都導致在另一方的多種確認中的至少一個，記錄最后引入的數(shù)據(jù)就提供了至少一些流出的數(shù)據(jù)被接收到的證據(jù)。
19.軟件安裝描述無需使用軟件安裝的標準(SIS文件)方法而從Symbian OS產(chǎn)品安裝(和隨后卸載)軟件的能力。
分析Symbian SIS文件的目的在于通過InstallShield的類似產(chǎn)品和其它產(chǎn)品以與其他軟件環(huán)境中頻繁使用的大概相同的方式簡化安裝過程。
然而，由Symbian OS裝置所使用的連接性平臺不再允許SIS文件的自動執(zhí)行，從而對管理員來說不可能鼓勵軟件不需要與該裝置的物理性交互而進行軟件的安裝(即，按下按鈕，與收件箱交互等)。
這項特征的本質(zhì)是為了避免安裝系統(tǒng)一起通過將文件拷貝進某個文件夾，以便在重啟該裝置時，某些完成安裝和對該裝置配置的‘運行一次’的組件可以執(zhí)行。這允許了可能還會要求復雜的SIS文件重新編譯的對每個裝置的安裝。
安裝者所要求行為的唯一過程是在將裝置交付給用戶之前關閉該裝置。這確保了安裝流程的完成。
20.域內(nèi)的安全性更新描述在域內(nèi)管理員在用戶終端上更新終端安全性方針的能力(例如，提高數(shù)字的最小數(shù)或應用鎖的超時時間間隔)。
分析本發(fā)明的目的在于允許管理員遠程更改裝置的某些安全性保證而無需裝置預先提供或返還到管理員來執(zhí)行該更改。
可以包含這樣一些更改●要求用戶選擇的應用鎖編碼的最小強度的策略的變化—這可能對一些用戶會強迫其更改編碼●在由裝置所使用的共享私密信息中的預定的更改●用戶更改其登錄密碼的要求這種特征在無線領域內(nèi)是新的，尤其在重新配置的目的地是分布式客戶端組件的情況下。
21.在域內(nèi)輪詢/推動更新描述管理員遠程更改微輪詢頻率的能力，或者給個別終端或用戶從輪詢到推動(反過來也是這樣)改變連接性特征的能力。
分析管理員可以對某些用戶要求改變輪詢的頻率以響應●關于某些用戶所允許的某種類型的支出的方針更改●對特定用戶改變音量習慣這項發(fā)明的特征允許管理員在每個用戶的基礎上更改任何或所有的以下方面●更改微輪詢的頻率以在缺乏任何應用數(shù)據(jù)的情況下改變后臺數(shù)據(jù)量●更改微輪詢的頻率以通過參考任何網(wǎng)絡運營商對NAT映射超時來使‘有效推動’可行或不可行●改變成或構成真實的‘推動’模式，在這種情況下沒有使用微輪詢這個特征對于無線領域內(nèi)分布式客戶端的組件的內(nèi)部通信來說是特別的。在一種實現(xiàn)中，用戶不具備對以上的控制管理員是這些設置的唯一特權者。
權利要求
1.一種數(shù)據(jù)訪問、復制或通信系統(tǒng)，包括分布于運行在終端上的終端側(cè)組件和服務器側(cè)組件的軟件應用，其中所述終端側(cè)組件和所述服務器側(cè)組件(i)共同構建到服務器的客戶端，并且(ii)通過使用消息列隊系統(tǒng)在網(wǎng)絡上發(fā)送消息來協(xié)作。
2.根據(jù)權利要求1的系統(tǒng)，其中所述消息列隊系統(tǒng)是面向消息的中間件。
3.根據(jù)權利要求1的系統(tǒng)，其中如果通過網(wǎng)絡的連接被中斷，所述終端側(cè)組件使終端程序不會被作好準備使所述連接被重新建立的隊列消息所影響，從而使所述終端程序進入其下一個任務。
4.根據(jù)權利要求1的系統(tǒng)，其中如果通過網(wǎng)絡的連接被中斷，所述服務器側(cè)組件使服務器程序不會被作好準備使所述連接被重新建立的列隊消息所影響，使所述服務器程序進入其下一個任務。
5.根據(jù)權利要求1的系統(tǒng)，其中列隊的每個消息定義了部分或全部的事件，其中事件足夠詳細地描述了存儲在所述終端或服務器上的數(shù)據(jù)的更改，以實現(xiàn)數(shù)據(jù)復制，而無需同步引擎；數(shù)據(jù)復制由發(fā)送事件實現(xiàn)，而不是由用于同步的存儲數(shù)據(jù)的完整數(shù)據(jù)集(或數(shù)據(jù)集的子集)實現(xiàn)。
6.根據(jù)權利要求5的系統(tǒng)，其中所述終端側(cè)組件可以創(chuàng)建事件，并由自己和/或在消息列隊系統(tǒng)中將這些事件列隊，使所述終端側(cè)組件進入其下一個任務，即使所述網(wǎng)絡連接被中斷。
7.根據(jù)權利要求5的系統(tǒng)，其中所述服務器側(cè)組件可以創(chuàng)建事件，并由自己和/或在消息列隊系統(tǒng)中將這些事件列隊，使所述服務器側(cè)組件進入其下一個任務，即使所述網(wǎng)絡連接被中斷。
8.根據(jù)權利要求6的系統(tǒng)，其中甚至在所述終端被關閉時，列隊的事件也存留在非易失存儲器中。
9.根據(jù)權利要求7的系統(tǒng)，其中甚至在所述服務器被關閉時，列隊的事件也存留在非易失存儲器中。
10.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件和所述服務器側(cè)組件共同地在運行于無線終端之上的終端程序和運行于服務器上的服務器程序之間構建中間件。
11.根據(jù)權利要求6的系統(tǒng)，其中在所述終端側(cè)上列隊的消息是對保留在所述服務器上的數(shù)據(jù)的引用。
12.根據(jù)權利要求10的系統(tǒng)，其中如果通過網(wǎng)絡的連接被重新建立，則在所述終端側(cè)上的消息隊列系統(tǒng)使所述終端程序不受自動地發(fā)送終端側(cè)隊列中的下一個消息的影響。
13.根據(jù)權利要求10的系統(tǒng)，其中如果通過網(wǎng)絡的連接被重新建立，則在所述服務器側(cè)上的消息隊列系統(tǒng)使所述服務器程序不受自動地發(fā)送服務器側(cè)隊列中的下一個消息的影響。
14.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件處理來自終端程序，即電子郵件或PIM程序的事件。
15.根據(jù)權利要求1的系統(tǒng)，其中所述服務器側(cè)組件處理來自服務器程序，即郵件服務器程序的事件。
16.根據(jù)權利要求1的系統(tǒng)，其中所述終端是無線終端，如移動電話或智能電話。
17.根據(jù)權利要求1的系統(tǒng)，其中所述網(wǎng)絡是無線WAN網(wǎng)絡，如GPRS或UMTS網(wǎng)絡。
18.根據(jù)權利要求1的系統(tǒng)，其中所述服務器側(cè)組件存儲從所述終端側(cè)組件發(fā)送的登錄密碼，并且可以使用這個登錄來訪問服務器程序。
19.根據(jù)權利要求1的系統(tǒng)，其中為了避免數(shù)據(jù)需要通過網(wǎng)絡從所述終端發(fā)送，所述服務器側(cè)組件可以通過使用保留在所述服務器上的數(shù)據(jù)來組裝所述終端側(cè)組件希望發(fā)送的消息。
20.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件監(jiān)測所述終端上的可用內(nèi)存，并自動刪除存儲在所述終端上的滿足預定年齡和/或使用和/或大小標準的數(shù)據(jù)，而不影響存儲在所述終端上的對應數(shù)據(jù)。
21.根據(jù)權利要求20的系統(tǒng)，其中用于刪除存儲在所述終端上的數(shù)據(jù)、且而不影響存儲在所述服務器上的對應數(shù)據(jù)的用戶選項與用于刪除存儲在所述終端上的數(shù)據(jù)和存儲在所述服務器上的對應數(shù)據(jù)的選項，在所述終端上顯示的菜單層的同一級上顯示。
22.根據(jù)權利要求20的系統(tǒng)，其中所述數(shù)據(jù)為消息數(shù)據(jù)，并且如果用戶請求的話，所述終端側(cè)組件保留允許所述消息數(shù)據(jù)由服務器重新提供的數(shù)據(jù)。
23.根據(jù)權利要求20的系統(tǒng)，其中如果數(shù)據(jù)沒有標為未讀，并且打開用于用戶瀏覽或操作，或者存在涉及數(shù)據(jù)從大型服務器請求其他數(shù)據(jù)的待處理動作，則數(shù)據(jù)就不從內(nèi)存中釋放。
24.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件使得文件附件以所述文件在所述服務器上存儲的原始格式，或者從原始格式轉(zhuǎn)換而來的更為可用的格式發(fā)送到所述無線終端。
25.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件使得用戶能夠(a)選擇釋放選項來刪除存儲在所述終端上的消息，而不刪除存儲在所述服務器上的對應消息，也能夠(b)選擇刪除選項來刪除存儲在所述終端上的消息，也刪除存儲在所述服務器上的對應消息，所述釋放和刪除選項出現(xiàn)在所述終端上顯示的菜單層內(nèi)的同一級。
26.根據(jù)權利要求1的系統(tǒng)，其中所述應用通過將ID映射到需要抵達所述終端的真實IP地址，實現(xiàn)尋址到由所述ID所識別的終端的消息的正確路由。
27.根據(jù)權利要求26的系統(tǒng)，其中所述地址是由NAT box分配的動態(tài)IP地址。
28.根據(jù)權利要求27的系統(tǒng)，其中如果存在有效映射的話，所述應用僅發(fā)起消息傳送。
29.根據(jù)權利要求28的系統(tǒng)，其中無論什么時候從所述終端接收到了特定類型的小的專用消息，映射都被刷新。
30.根據(jù)權利要求1的系統(tǒng)，其中所述終端側(cè)組件允許服務器管理員鎖定所述終端上的應用，而不影所述終端上的其他應用。
31.根據(jù)權利要求1的系統(tǒng)，其中所述終端組件向任何被懷疑試圖拒絕所述終端上的服務攻擊的第三方發(fā)送詢問，而且所述服務攻擊的拒絕不會導致任何到所述終端的其他數(shù)據(jù)業(yè)務。
32.根據(jù)權利要求1的系統(tǒng)，其中所述應用包括調(diào)用分布式通信平臺的分布式應用平臺。
33.根據(jù)權利要求32的系統(tǒng)，其中所述通信平臺使通過網(wǎng)絡傳送消息變得可靠，即使使用了不可靠的傳輸協(xié)議，其中所述平臺以與會話無關的方式運行。
34.一種數(shù)據(jù)訪問、復制或通信的方法，包括以下步驟(a)運行分布于終端側(cè)組件和服務器側(cè)組件的軟件應用，其中所述終端側(cè)組件和所述服務器側(cè)組件共同構建到服務器的客戶端，以及(b)在所述終端側(cè)組件和所述服務器側(cè)組件之間使用消息列隊系統(tǒng)在網(wǎng)絡上發(fā)送消息。
35.根據(jù)權利要求34的方法，其中所述軟件應用是根據(jù)前述權利要求1-33中任何一項所定義的系統(tǒng)的單元。
36.一種利用終端側(cè)組件編程的終端，所述終端側(cè)組件是根據(jù)前述權利要求1-33中任何一項所定義的系統(tǒng)的單元。
37.一種利用服務器側(cè)組件編程的服務器，所述服務器側(cè)組件是根據(jù)前述權利要求1-33中任何一項所定義的系統(tǒng)的單元。
全文摘要
本發(fā)明設想了一種數(shù)據(jù)訪問、復制或通信系統(tǒng)，該系統(tǒng)包含分布于運行在終端上的終端側(cè)組件和服務器側(cè)組件的軟件應用；其中所述終端側(cè)組件和所述服務器側(cè)組件(i)共同構建到服務器的客戶端，并且(ii)通過使用消息列隊系統(tǒng)通過網(wǎng)絡發(fā)送消息來協(xié)作。從而，我們就將客戶端－服務器構架中充當客戶端的應用的功能劃分(即，分布)為運行在兩個或更多物理裝置上的部件，這些裝置使用諸如面向消息的中間件的消息隊列系統(tǒng)通過網(wǎng)絡連接相互通信。組成部件在大型的客戶端－服務器配置中充當客戶端，而服務器為例如郵件服務器。我們稱此為“分布式客戶端”模型。分布式客戶端模型的核心優(yōu)勢在于其允許終端，如具有有限處理能力、功率和連接性的移動裝置，通過將通常與客戶端相關的功能中的一部分分布到服務器側(cè)而在移動裝置上使用最少資源，來享受功能完備的客戶端訪問服務器環(huán)境的功能，服務器側(cè)并沒有如此地受資源限制。
文檔編號G06F9/45GK1792076SQ200480013537
公開日2006年6月21日 申請日期2004年4月19日 優(yōu)先權日2003年4月17日
發(fā)明者萊昂內(nèi)爾·沃洛威茲, 馬克·格里頓, 鮑伯·斯坦登 申請人:維斯托公司