最近在一個充值平臺上使用了HSQL來記錄用戶的充值記錄,本來所有的記錄是寫到文件里面的,但是由于使用ORACLE的慣性思維導致我浪費了半天的時間.具體情況是這樣:
我使用的是HSQL的IN-PROCESS(Standalone)模式,這樣在WEB啟動的時候,我就會去創建數據庫,按照HSQL的文檔,如果存在<dbname>.script文件的話,數據庫就會將歷史數據插入到數據庫中,但是在這里我放了一個慣性的錯誤,我們在ORCALE或是其他的常用數據庫中創建表時,一般要先刪除就表,讓后在創建新的表,這樣我就把HSQL的歷史記錄都刪除了,郁悶啊,這可是用戶的充值記錄啊,以后我怎么對帳啊,:)還好我有備份.
在HSQL更本不需要這樣的操作,他自己會去做這樣的事情:如果<dbname>.script存在,他就直接執行了這個script,如果沒有他才回去創建新的數據庫和表結構.

最近將手上的項目(tomcat5.0+spring+struts)的jdk1.4升級到1.5的時候,出現了一堆的問題,經過不懈的努力和網上朋友的提示終于將問題解決了,現在記錄如下
1.java.lang.UnsupportedClassVersionError: com/mdcchina/userinfo/logic/UserManager (Unsupported major.minor version 49.0)提示如上的錯誤,很是郁悶
經過研究和比較在兩個不同環境下的編譯運行,終于發現這個主要是由于我的機子上安裝了兩個不同版本的JDK導致的,我想很多的朋友在嘗試新的JDK的時候,可能不會刪除1.4的版本,但是要注意的是要將JAVA_HOME,CLASS_PATH,PATH等等的環境變量都修改成相關的JDK1.5的目錄下面去,因為1.5相對于以前的版本的變化比較大.
2.上面的問題排除后,在運行TOMCAT5.0時候由出現了如下的錯誤:
2005-11-17 19:38:47 StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
org.apache.jasper.JasperException: Unable to compile class for JSP

Generated servlet error:
C:\application\Tomcat 5.0\work\Catalina\localhost\mlinkweb\org\apache\jsp\layouts\layout_005findex_jsp.java:7: cannot access java.lang.Object

Generated servlet error:
bad class file: C:\application\Java\jdk1.5.0\jre\lib\rt.jar(java/lang/Object.class)
class file has wrong version 49.0, should be 48.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
public final class layout_005findex_jsp extends org.apache.jasper.runtime.HttpJspBase
             ^
1 error

這個問題這是讓我郁悶之極啊(^_^)
最后在SUN的JAVA論壇里面找到了答案,只要將JDK1.5的LIB下面的TOOLS.JAR覆蓋TOMCAT5.0目錄/common/lib下面的tools.jar,然后重啟TOMCAT5.0就可以了

http://www.swig.org
這是一個很好的工具,可以再不同的平臺和不同語言之間進行協作,JAVA調C,C調JAVA,這樣就可以對資源進行重新的整合和利用了,而且還省了不少的事情吼吼...... 以下五步可以讓 Struts 1.1 和 Tiles 共同工作：
1. 創建一個 JSP 以表示站點的布局。這是主 JSP，并帶有頁頭、頁體和頁腳的占位符。分別用 Tiles 標記添加到主 JSP 頁面中。
2. 創建一個 Tiles 定義文件并定義每個集成頁面的每個占位符中必須包括哪個 JSP 頁面。用惟一的名稱標識出每一個合成頁面定義。
3. 在 struts-config.xml 文件中改變全局和本地轉發以使用上一步驟中給出的惟一名稱而不是別名。
4. 在啟動時用 TilesPlugIn 裝載 Tiles 定義文件。將 TilesPlugIn 項加入到 struts-config.xml 文件中。
5. 將 TilesRequestProcessor 項添加到 struts-config.xml 文件中。這是支持 Tiles 的 Struts 應用程序的默認請求處理程序。
 
在現在的一個項目中使用了STRUTS和titles結合的方式來構建VIEW,特別是第5項,讓我花了將近2個小時才搞定,正式郁悶,這都是沒有好好讀文檔的結果啊,引以為戒啊,最后還是在Srikanth Shenoy,和Nithin Mallya的文章<<集成 Struts、Tiles 和 JavaServer Faces>>中找到答案. 總于有時間來繼續這篇文章的翻譯，以后一定要計劃好，計劃好：），好了，下面進入正題吧：

在對syncml的協議的使用工程進行描述之前我們先來看看同步類型的分類：
syncML協議描述了七種不同的同步類型：
（1）Two-way sync:雙向同步是客戶端和服務器端交換有關任何修改的數據信息的一種常用的同步類型。
（2）Slow sync:慢同步是雙向同步的一種特別的形式。慢同步就是將客戶端數據庫的數據和服務器端的數據庫數據逐個進行比較。如果客戶端和服務器端的同步錨不匹配或客戶端或是服務器端的修改日志遺失時將會請求一個慢同步。實際上，慢同步就意味著客戶端發送所有的數據到服務器端，服務器端對客戶端的所有數據進行逐個字段的分析，比較，并將服務段的數據發送到客戶端。在同步分析完成后，服務端將所有的修改信息返回客戶端。然后，客戶端返回所有的數據的映射信息，并添加到服務端。
（3）One-way sync from client only:客戶端優先同步，是客戶端發送修改信息到服務端，但是服務端的修改信息并不被發送到客戶端。
(4)Refresh sync from client only: 從客戶端同步刷新，這里客戶端為服務端提供所有數據的瀏覽，服務器根據客戶端的修改來更新服務端的數據。
（5）One-way sync from server only:服務端同步優先，這個同步方式是客戶端從服務獲取所有的修改信息，但是客戶端不發送修改信息到服務端。
（6）Refresh sync from server only:從服務端刷新同步，這里假設服務端為客戶端提供所有的數據的預覽，客戶端將更新目標數據庫中的數據，更新數據由服務器端發送到客戶端。
（7）Server-alerted sync: 服務通告同步，服務器端通知客戶端需要發起的同步類型指令給服務端。

好了，同步的幾種基本類型我們都描述過了（不過其中有兩種4，6我自己也不知道描述被人是否能夠看的懂，很難表達，e文還需要加強啊），下面就讓我們一起來看看同步的全過程吧。


為了理解基本的同步過程，我們開始講解一些在客戶端和服務端的同步工程的一些細節。由于雙向同步是最通常的同步過程，我們就使用這種同步過程作為例子。

一個雙向同步的過程可以分為下面幾步：
1.同步初始化
2.雙向同步
3.數據映射

NOW,讓我們一步一的揭開同步的神秘面紗吧：
（1）同步初始化：
任何的同步過程首先都必須進行同步初始化的工作，在一個同步初始化的工程種，服務端和客戶端設備通常要叫化一下信息：
a.同步服務器和設備的能力描述
b.請求訪問的數據庫和同步類型
c.認證信息

同步錨也是在同步初始化中被交換的信息。
下面的過程圖介紹了基本的同步初始化過程：



（2）雙向同步：

sync4j.framework的基本結構描述:

sync4j.framework.core:這個包的基本功能是描述一個合法的SyncML消息.該模塊主要的功能是根據SyncML描述協議構建一個SyncML通訊的XML消息,并對消息的合法性進行檢查.
sync4j.framework.protocol:這個包主要是對同步初始化協議規則的描述.
sync4j.framework.config:這個包主要是對sync4j整體結構的描述,包括服務和功能模塊的配置說明
sync4j.framework.security:主要處理用戶的安全問題
sync4j.framework.logging:主要處理服務端的日志問題(和security模塊同屬于系統的services層)
sync4j.framework.engine:這個是sync4j的核心模塊,他提供了同步引擎的基本接口,容許通過插件的方式實現客戶定制同步引擎
sync4j.framework.server:這個包提供了在SYNC4J的同步引擎的基礎上開發應用服務的通用的類.

sync4j.server:
 提供了一個SyncML服務的基本架構

SyncML 是一種為了結束終端用戶,設備制造廠商,服務提供商(SP)和應用開發者之間的無線數據無法同步的數據同步協議.下面讓我們一起來看看無線開發者Chandan Pabla 對SyncML協議(version1.1)的理解和使用客戶端/服務器端兩邊覆蓋的同步過程.

1.SyncML的基礎:
   SyncML是一種主要的開發式的工業標準,為了使遠程數據和個人信息通過不同的網絡,平臺和設備進行同步而制定的.SyncML使的數據非常的容易在不同的網絡和網絡設備之間進行傳輸,因為它支持多種傳輸協議.
  SyncML的有點可以總結為一下幾點:
     (1)可以在不同的網絡上工作--包括有限網絡和無限網絡.
     (2)支持多種傳輸協議,包括HTTP,WSP(Wireless Session Protocol),OBEX(Bluetooth,IrDA),SMTP,pure TCP/IP.
     (3)支持通用的個人數據格式,如vCard,vCalendar和E-MAIL等.
     (4)對移動設備的存儲空間進行了優化.
     (5)建立在internet協議和web技術上,是可執行而且有很好的協作性的.
2.SyncML的協議描述:
   SyncML程序框架是建立在同步描述協議(SyncML Representation protocol)和同步協議(SyncML Synchronization protocol)兩個協議的基礎上的.同步描述協議定義了同步消息(in XML)的格式描述和在同步框架內工作的細節.同步協議定義了同步客服端和同步服務器端的交互.
   為了建立一個適當的SyncML產品,我們必須要了解這個兩個協議的相關要求,下面我們開始看看同步協議的最重要的幾個組成部分:
  (1)Change log
  開始一個同步協議的操作時,SyncML協議需要在客戶端和服務器端的各自的數據庫中維護信息的交換或修改(如替代,增加,刪除數據等).SyncML通過一種被稱為change log的信息跟蹤機制來解決客戶端和服務器端的信息交換或修改的問題.SyncML并沒有描述change log的格式信息,但是進行同步的每個設備必須能夠詳細的描述設備上每個數據項從上次同步時的修改的詳細情況.

  (2)Map operation(操作的映射)

   同步操作是基于客戶端和服務器端的數據庫中每個數據元素都有一個唯一標識(IDS)的原則來進行的.客戶端ID被稱為本地唯一標識(locally unique indentifier LUID),服務器ID被稱為全局唯一標識(globally unique identifier GUID).這個ID在服務器和客戶端可以相同,也可以不同.如果這個IDS是不同的,那么服務器端就必須保留一個ID的映射,保證服務端和客戶端的數據交換的一致性.LUIDS總是由客戶端設備來分配的.這就意味者即使是通過服務端添加一個數據項到客戶端設備,也是由客戶端為這個數據項分配LUID.分配完成后,客戶端將通過Map operation把LUID發送到服務端,服務端將更新MAPPING表中數據項的LUID.

  (3)Sync anchors(同步錨)

  當一個同步會話被初始化的時候,總是有兩個錨被發送,一個是最后一次同步的錨一個是下一次同步的錨.最后一次的錨描述了發起同步設備發起最后一次同步事件的時間點;下次同步錨描述了發起同步動作設備的當前的同步事件的時間點.通過這種方式,在服務端和客戶端交換各自的同步錨.當接收一個NEXT SYNC ANCHOR時,接收設備必須保存它直到下次同步,當下次同步到來的時候,接收設備將比較兩次的同步錨并發送最后一次的同步錨,以判斷是否在同步時有數據失敗.如果最后一次同步錨和下次同步錨匹配,接收設備將認為沒有錯誤并結束同步會話的初始化.如果不匹配,接收設備將從其他設備請求一個適當的動作,比如慢同步.當同步會話成功并結束后,同步錨將被保存.

  (4)Confict resolution(沖突解決方式)

  當同一個數據項在客戶端和服務器端同時被修改后,數據的版本沖突就產生了,對同一數據項將產生兩個不同版本的數據.同步協議必須有一種策略解決這樣的沖突.在SyncML中,沖突策略是同步引擎的一個基本功能,通常是由同步引擎的同步服務器來解決版本沖突問題,也有可能有寫客戶端設備提供解決這一問題的解決方式.

  在同步描述協議提供了通過通知同步客戶端沖突決定和狀態碼的通用解決方案.如果同步引擎的服務端確定一個沖突,服務端將使用狀態碼和通知功能通知同步客戶端并定義解決方案.下面是一些常用的狀態碼和沖突解決策略:

     <1>207:數據合并

     <2>208:客戶端優先

     <3>209:數據復制

  5.Security(安全性)

  SyncML為了安全的數據同步提供了框架.SyncML本身并沒有提供新的安全機制,但是它提供了安全驗證框架和在不同的網絡層進行安全驗證的機制.

  SyncML協議在三個不同的層次定義了用戶驗證機制,這個三個層分別是:服務器層,數據庫層和對象層.SycnML只要求它的安全驗證機制在服務器端被支持就可以了.為了使用SycnML協議,同步的客戶端和服務器端必須支持基本的MD5驗證.在數據庫層面和對象層面的安全驗證是可以選擇的.

  6.Device capabilities(設備性能)

   SyncML協議通過一個初始化設置可以使不同性能的客戶端設備和服務器端進行信息的交換.任意一個設備(客戶端或服務端)都能請求信息交換,只要客戶端設備性能和服務端能協同工作,他們就能讓一個同步會話繼續下去.

 有兩種類型的信息在設備和服務器端進行交換:

    (1)設備信息:包括設備類型,數據模塊和制造廠商信息.

    (2)服務器信息:描述了客戶端或服務器端支持的數據對象的特性.如果客戶端支持vCard version 2.1數據格式和慢同步及雙向同步,那么服務器就必須具有這樣的能力,否則,同步就不能繼續下去.

 同步的客戶端必須在第一次同步或者在設備的靜態的信息更新后的時候發送設備信息到服務端。同時，當服務器端請求客戶端設備信息的時候，客戶端應將自身的設備信息發送到服務端。而一個同步服務器應具備接受和處理設備信息的能力，不論它是否接受過客戶端的設備信息或是通過自己請求過客戶端設備信息。


今天先寫道這里，具體的協議使用流程明天給出(備注：這是本人首次翻譯相關技術文檔，請各路高手指教)