在遠古時期人們靠結繩紀事，據說美洲的瑪雅文明在覆滅之前都一直沒有自己的文字，而采用這種古老的方法。
后來我們的祖先發明了文字，在竹簡上，布帛上書寫文字，竹簡和布帛就是信息的載體，這樣的載體造價不菲，所以我們的文言和白話就有這么大的差距，留下的論語也要微言大義。再后來我們的祖先發明了紙張，嚴重地降低了承載信息的開銷，于是人類的文明得以更好地記錄和更快地發展。今天，我們的信息載體又有了新的變化，一張光盤，一個硬盤都可以承載無數的學問。
信息有了載體，隨之產生了信息管理的問題：
如何對信息進行增刪改查的操作？如何處理附加在信息上的工作流？如何管理權限？
在IT系統出現之前，人們通過圖書館管理圖書，通過搬運工進行信息流動，通過鑰匙和鎖頭管理權限。
在IT系統出現之后，人類可以通過計算機來完成這些操作。這其中數據庫系統，工作流系統幫了我們大忙。
IT系統處理信息的過程是：
多樣式的文檔（抽象為XML）-> 內存數據 -> 持久化（文件數據庫）->內存數據 -> 多樣式的文檔(抽象為XML)
我們讓用戶在我們設定的UI窗口進行輸入，然后通過報表的形式產生各種各樣的輸出。中間一個步驟一個步驟，一個環節一個環節的走下去。
這其中，我們把很大一部分精力消耗在，如何讓用戶舒服的輸入，和產生用戶所需要的輸出上。
于是人們就要思考，難道不可以直接編輯一種全世界認可的文檔形式（大家現在正在和MS爭吵的東西）通過網絡流轉，然后獲得結果嗎？為什么要從程序員的角度加給用戶數據庫，工作流，錄入界面這些繁雜的東西？
從這點意義上說，我推崇Sharepoint或者Google sites。
就拿google docs來說吧，在線編輯word，每個環節通過分享的形式進行編輯，授權這部分可以通過歷史記錄來找到，隨時恢復到歷史版本，因此也不怕誤操作和無權限操作，真正的所見即所得，支持50人同時在線編輯。這難道不是OA的殺手級應用嗎？
學習這些框架技術，我覺得歸根結底就是做什么的，為什么做，如何做
前人說讀書有三個層次，我看這大概可以總結為是新的三個層次：）
因為沒有搞清楚為什么要用，就會誤用，用了還不如沒用。其實我覺得學spring讀讀rod那個原著挺好的，比單純學spring有幫助，最好自己有體會。比如你開發網站很熟練了，自然就知道為什么要用spring了。等完全領會了他那兩本書后，再讀讀他們的reference book應該差不多了。
這個過程其實就是做什么->為什么->怎么做的過程
最近在研究關于系統的基于日志的故障恢復，無意間在網上發現一篇論文中對于系統日志模型的精彩論述，翻譯過來并附上我的思路：
『
一個系統是一個具有明顯的邊界的實體，它根據一定的輸入，自身運行邏輯及系統的內部時鐘變化來產生相應的輸出。
所謂“明顯的邊界”是指系統所產生的輸出是明確而無二義性的。我們稱這個邊界為系統的設計規范（specification）。一個系統通過與其所處環境進行交互，從而獲取輸入并產生輸出。一個系統可以被拆解為不同的子系統。這些子系統通常被稱為系統模塊（system components），每個模塊又獨立地成為一個系統，作為一個系統，這個模塊又會和它的相關環境進行交互（比如，一個更大的系統中的其他的模塊組件）來獲取輸入并產生輸出，這些模塊還可以繼續被分解為更小的子系統。
一個系統可以被建模為一個狀態機（state machine），其中的狀態包含了系統所持有并處理的數據。這些狀態的遷移被分為兩大類：由系統內部邏輯所觸發且對外部環境透明的遷移和直接與外部環境相接觸的遷移。前者的例子如內存數據和寄存器數據的轉換，內存中數據結構的重組。第二種遷移的例子包含了各種各樣的系統和環境之間的交互，一般來說，如果這個過程能被建模成系統的I/O操作，則應屬于這一類別。因此，一個消息內容的形成是一個或多個第一類別狀態遷移的結果，但將消息輸出到系統的環境則是屬于第二類遷移。
第二類別的狀態遷移可以捕獲交互事件（interaction events），或者簡單的事件（events）。這些事件可以由系統外部的觀察者（observer）來獲取。顯然，這里的事件是消息、信號、數據及其內容以及一切系統和其環境交互（如機器人運動手腳，報警器報警，打印機打印等等）的發送和接受的模型。此外事件還可以用來描述系統缺乏交互的時間，比如一個計時器在日志中輸出系統的空閑時間等。
當一個大的系統被拆分成多個模塊時，每個模塊都被賦予了整個系統所處理數據的一部分，正因為模塊和模塊間的接口銜接和數據感知，一些原來屬于第一類別的狀態轉換，因為系統的拆分在更低的層次上變成了第二類別，成為系統和環境之間的交互。
對于一個特定的系統，他對于輸入的形式和獲取時間是不可預知的，但是這個系統卻應該能夠做到根據一個特定的輸入以及系統當前的特定狀態獲取一個特定的輸出。因此系統的執行可以被建模為狀態轉換序列，每個狀態的輸入是一個不確定性事件。為了記錄日志并做到故障恢復，我們還應做到能夠在環境中捕獲這個不確定性事件輸入。
此外，在系統與系統間進行交互式，事件的傳遞時間也應該是不確定性的。
』
怎樣用日志來預防系統崩潰，在崩潰后如何還原系統，我想關鍵問題就是怎么做好內存的快照，這樣，在斷電重啟后可以通過日志來還原內存的信息這樣第一步就是確認內存中的數據結構，哪些是必不可少的。確定系統恢復的粒度，按照子系統的分割和事件的記錄來進行replay，根據子系統的劃分，可以找出每個子系統中第二類別的事件進行記錄。
以向數據庫系統提交作業為例，實際上在整個作業提交的過程中，每個層次都要做到可以在失敗的情況下重現，這個功能在完善的數據庫系統和集群批處理系統中當然已經很完善。但如果是針對web系統的作業提交，則需要針對Web的作業持久方案，做一個日志恢復處理。需要特別指出的是，對于數據的查詢是不需要做備份的。
在具體實現上，我想應該包括：日志記錄，故障檢測，日志持久三個部分。一份日志就是一個對于系統檢查點（checkpoint）的連續記錄。日志記錄者負責記錄日志到日志持久者，故障檢測器隨時監控系統，發現故障后，從日志持久者中讀取日志，進行replay.
總算找到了工作.
我會好好努力的.
此時此刻,更加明白,以往的一切榮與辱都成為過去.
又要踏上新的征程.
剛看了myeclipse，eclipse是一個很可怕的東西，它試圖讓所有的開發人員一打開電腦就不能夠離開它，還要在里面完成所有的工作。人們不至于反感它的原因是它是開源的，不受商業控制的。如果我們對于myeclipse過度依賴，必然最終走向對微軟嚴重依賴的老路。我不反對利用軟件盈利。但是自由的精神不應被改變。
微軟和我們
是原始的獵人與獵物之間的關系，虎與倀的關系，最終極的占有。我們這才生是MS的人，死是MS的鬼。
摘要: 這篇隨筆談一談如何在Java環境下利用Unix/Linux的用戶名和密碼對用戶的權限作出過濾。為方便大家學習交流，本文中給出了源代碼，借此拋磚引玉，歡迎大家對這個簡單的登錄模型做出改進或者設計出自己的技術方案。
由標題我們不難看出，與本文相關的知識點主要有3個：
1 JAAS這個解耦設計的多層驗證方法（1.4后已歸入Java核心庫中）
2 應用JNI訪問底層代碼，及JNI中簡單的類型匹配
3 在shadow模式下，Unix/Linux系統的用戶驗證
閱讀全文
O/R映射框架的延遲加載技術實現大體上有這么4種(參看Martin Fowler的意見):
(http://www.martinfowler.com/eaaCatalog/lazyLoad.html)
There are four main varieties of lazy load. Lazy Initialization uses a special marker value (usually null) to indicate a field isn't loaded. Every access to the field checks the field for the marker value and if unloaded, loads it. Virtual Proxy is an object with the same interface as the real object. The first time one of its methods are called it loads the real the object and then delegates. Value Holder is an object with a getValue method. Clients call getValue to get the real object, the first call triggers the load. A ghost is the real object without any data. The first time you call a method the ghost loads the full data into its fields.
通過閱讀源代碼,發現iBATIS中的延遲加載是用上述方式中的虛擬代理實現的.
在動態代理的實現上, iBATIS有Java動態代理和CGLIB兩種實現方案,iBATIS把用CGLIB實現的方案稱為Enhanced的方案,可見CGLIB的效率會比java的動態代理效率要高.
在iBATIS首先判斷是否定義了延遲加載,如果定義了,則利用Lazy的Loader來提取數據(返回一個Proxy).如沒有執行對這個的任何操作,或者只是不再使用(finalize),則不做處理,否者就加載真正的對象.
可以通過閱讀類
com.ibatis.sqlmap.engine.mapping.result.loader.LazyResultLoader
的源碼獲取更多的細節.
接著上次的話題，今天我們聊聊gSOAP這個框架，我們把用C寫的舊有系統用gSOAP改造一下，通過SOA的形式發布出去。
上文提到，利用gSOAP可以做到以下3點：
1 一個Stand-alone的服務器外殼
2 一個根據API程序自動生成的Web Services服務
3 一個WSDL描述符文件
客戶根據 WSDL 描述文檔，會生成一個 SOAP 請求消息。Web Services 都是放在Web服務器后面，客戶生成的SOAP請求會被嵌入在一個HTTP POST請求中，發送到 Web 服務器來。Web 服務器再把這些請求轉發給 Web Services 請求處理器。請求處理器的作用在于，解析收到的 SOAP 請求，調用 Web Services，然后再生成相應的 SOAP 應答。Web 服務器得到 SOAP 應答后，會再通過 HTTP應答的方式把信息送回到客戶端。
WSDL是Web服務中客戶端和服務端溝通的橋梁，描述了對象提供的方法。SOAP幫我們制定了一份被官方認可的對象的封裝方法。有了WSDL，客戶端只關心如何把參數用Soap封裝起來發出去，并獲取結果。服務端只關心如何對Soap進行拆包->服務->封包。gSOAP可以幫我們實現上述過程中的拆包和封包，而我們可以只關心服務的實現。
言歸正傳，在這里我們以一個簡單的實現加、減、開放的Web Services的服務為例子，介紹gSOAP的使用：
為了發布這個Web服務，首先我們需要把服務的接口定義好，這個服務可能是一個現有服務的Adapter，為此我們定義頭文件
calc.h:
typedef double xsd__double;
int ns__add(xsd__double a, xsd__double b, xsd__double &result);
int ns__sub(xsd__double a, xsd__double b, xsd__double &result);
int ns__sqrt(xsd__double a, xsd__double &result);
注意到這里面我們把double定義成了xsd__double（兩個下劃線），這是為了告訴gSOAP，我們需要的soap格式和WSDL格式是基于Document/literal的而非rpc/encoded.為了不把事情搞復雜，在這里我只能說，Java1.6自帶的Web Services工具只支持Document/literal格式的WSDL，所以我們生成這種格式的WSDL。至于這兩種格式之間選擇和他們的long story，大家可以參考下面的文章：
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
編寫好頭文件后，我們就可以利用gSOAP提供的工具進行生成了：
/usr/lib/gsoap-2.7/bin/soapcpp2 -S -2 calc.h
生成的主要文件詳見附件。
下面我們實現calc.h中定義的函數：
// Contents of file "calc.cpp":
#include "soapH.h"
#include "ns.nsmap"
#include <math.h>
int main()
{
struct soap soap;
int m, s; // master and slave sockets
soap_init(&soap);
m = soap_bind(&soap, "localhost", 9999, 100);
if (m < 0)
soap_print_fault(&soap, stderr);
else
{
fprintf(stderr, "Socket connection successful: master socket = %d\n", m);
for (int i = 1; ; i++)
{
s = soap_accept(&soap);
if (s < 0)
{
soap_print_fault(&soap, stderr);
break;
}
fprintf(stderr, "%d: accepted connection from IP=%d.%d.%d.%d socket=%d", i,
(soap.ip >> 24)&0xFF, (soap.ip >> 16)&0xFF, (soap.ip >> 8)&0xFF, soap.ip&0xFF, s);
if (soap_serve(&soap) != SOAP_OK) // process RPC request
soap_print_fault(&soap, stderr); // print error
fprintf(stderr, "request served\n");
soap_destroy(&soap); // clean up class instances
soap_end(&soap); // clean up everything and close socket
}
}
soap_done(&soap); // close master socket and detach environment
}
// Implementation of the "add" remote method:
int ns__add(struct soap *soap, double a, double b, double &result)
{
result = a + b;
return SOAP_OK;
}
// Implementation of the "sub" remote method:
int ns__sub(struct soap *soap, double a, double b, double &result)
{
result = a - b;
return SOAP_OK;
}
// Implementation of the "sqrt" remote method:
int ns__sqrt(struct soap *soap, double a, double &result)
{
if (a >= 0)
{
result = sqrt(a);
return SOAP_OK;
}
else
{
return soap_sender_fault(soap, "Square root of negative value", "I can only compute the square root of a non-negative value");
}
}
前文提到過，我們不希望為了發布基于Web Services的C語言的API而開發或應用一個大的Web服務器。我們代碼中的main函數實現了一個最簡單的Web Server（基于Socket）.這個Server利用gSOAP生成的API來提供針對SOAP的處理。
下面我們把這個嵌入式的web server編譯，編譯的時候注意stdsoap2.cpp這個文件是從gSOAP包中拷貝而來，不是自動生成的，大家下載gSOAP后直接就能找到這個文件及其頭文件。
g++ -o calcServer calc.cpp soapC.cpp soapServer.cpp stdsoap2.cpp
一個以Web Servers形式提供的C API誕生了。
在server端執行./calcServer
下面討論如何用Java1.6的自帶工具生成一個客戶端stub:
把gSOAP生成的WSDL拷貝到我們的Java開發環境中來，按照Web Services Server中定義的端口和服務器，配置參數生成客戶端Web Services代碼：
/usr/lib/jvm/jdk1.6.0_03/bin/wsimport -extension -httpproxy:localhost:9999 -verbose ns.wsdl
生成后，把這個環境添加到eclipse的編譯環境中來，然后在eclipse中建一個新的類：
class Test {
public static void main(String args[]) {
Service service = new Service();
double h = service.getService().sub(20000, 1);
System.out.println(h);
}
}
運行后得到結果19999.0
總結：當集成Java和C兩種平臺時，我們可以有多種解決方案，但首先我們應該想到gSOAP因為它能夠很出色地完成任務。
文中相關代碼：
http://m.tkk7.com/Files/yangyi/gsoap.zip
廣告：本人明年畢業，正在找工作，個人簡歷：
http://m.tkk7.com/Files/yangyi/My%20Resume.zip
背景：
對于舊有系統的改造和升級，最苦惱的莫過于跨平臺，跨語言。我的一個朋友最近從Java專向了專攻.NET——因為.NET的CLR既有類似Java虛擬機概念這種已經被證明很成功的底層托管能力。又對于Windows的就有桌面應用提供了良好的兼容。
最近我的一個個人項目也面臨著這樣的需求。一個C語言開發的中間件，通過API暴露給二次開發及插件應用。現在由于對其應用的需求變得日趨復雜，而且正在脫離Unix的管理環境，走向基于JWS這樣的BCS管理。有朋友推薦我用JNI，但這樣一是增加了耦合度，二是讓Java睡在JNI感覺不太安穩。在認知了上下兩層的系統平臺后，問題變得明朗起來：如何在HTTP協議下實現Java和C之間的交互？
思路：
本人對Java比較熟悉，先從Java的角度入手，Java間的通信方法：
1 通過URL，Applet/JWS訪問被影射到URL的動態資源（Servlet）
2 通過URL，Applet/JWS訪問共享的靜態資源（Server定期更新靜態資源）
3 通過序列化和反序列化，實現簡單對象的傳輸（比如Resin的Hessian框架就提供了這種通信的方式）
4 通過一些工具做代碼生成，利用Web Services實現客戶端和服務端的交互
此外脫離HTTP，還可以做RMI，socket編程
現在問題是通信的一端由Java變成了C/C++, 于是， 解決方案1需要把動態資源由CGI來定義，而方案3變得不再適用。于是方案有：
1 通過URL，Applet/JWS訪問被影射到URL的動態資源（CGI）
2 通過URL，Applet/JWS訪問共享的靜態資源（Server定期更新靜態資源）
3 通過一些工具做代碼生成，利用Web Services實現客戶端和服務端的交互（×××這是我們討論的重點×××）
解決方案:
現在針對上文提出的3中通信方式中的1和3談一談實現的方法，2的實現方案比較靈活，需要發揮大家的想象力了：）
針對CGI：
首先CGI可以配置在各種主流的服務器中作為后端的腳本運行。大家可能對Servlet更熟悉一些。
CGI可以用腳本寫，也可以用C來實現。CGI被觸發后，通過系統的環境變量來獲得輸入，在處理完畢后向標準輸出中輸出結果。
由此可以想見，Web服務器在接受到來自HTTP協議的請求后，首先把請求的參數獲取到，然后設置到環境變量里。
根據對訪問的URL的解析和服務器自身的配置，找到服務于請求的CGI程序的位置，然后執行這個程序。
這個程序被執行后通過環境變量得到了服務器先前設置在環境變量中的參數。在經過一些復雜的邏輯操作后，向標準輸出輸出結果。
這個輸出又被Web服務器所捕獲，轉而傳遞回請求的客戶端。
更多關于CGI的知識和理解，大家可以通過google來尋找答案
上述CGI的方式可以讓我們直接獲取到結果，但是方案比較原始和基礎。其缺點有：
1 需要自己制定類型傳輸協議，做封裝和拆封，否則只支持字符串
2 我們不會為了要用C的API就給它裝一個或者自己實現一個Web服務器的，這讓我們的底層程序顯得蠢笨而冗余。我們希望能有一個超薄的Server外殼，
在對API封裝后，通過某個端口進行開放即可。
針對Web Servcies：
Based on上面的兩個不足，我們只能把希望寄托在Web Services身上了，
筆者在這里推薦給大家的是在C/C++很著名的Web Services工具gSOAP。大家可以到http://gsoap2.sourceforge.net/上去下載這個工具。
通過這個工具，我們可以做到：
1 一個Stand-alone的服務器外殼
2 一個根據API程序自動生成的Web Services服務
3 一個WSDL描述符文件
有關基于gSOAP的Web Services C服務端和Java客戶端的運行機理，及通過Java客戶端訪問gSOAP的Web Services的過程中需要注意的問題（筆者費了一天周折才搞清楚），將在下一篇中描述
廣告時間：
本人是哈工大的研究生，明年7月畢業。正在找工作，如果有工作機會，別忘了通知小弟哦（contactyang@163.com）