1998年幫花X銀行建立他的call center。
當時作架構分析的時候，幹了件豬頭事。
建議客戶用MSSQL 7。
豬頭在哪呢？ 豬頭在客戶的使用者端作業系統，當時他們的作業系統標準是 NT 3.51。
MSSQL 7的client 必須要使用WinSock 2，而NT 3.51只支援到WinSock 1.1。
就這樣開始了漫長的中介軟體之旅！
首先，這套系統是用Delphi開發的，理所當然的，我第一個想到的就是MIDAS，而它的文件也寫了，它支援WinSock 1.1，所以我就買了6套還是8套，來支援整個call center的客戶端。
然後，實際測試結果，文件是騙人的，MIDAS也是要WinSock 2，所以白花花的銀子就這樣飛了。
最後，當然就是倒楣的Architect兼工程師，我，手工打造一個database proxy。
就這樣，客戶端環境不斷地升級，後端資料庫也不斷的升級，這個小工具，還是站在那裡。
在一台P3，RAM 1G的機器乖乖的服務所有的使用者（全盛時期，快500個concurrent user)。
這個小工具，當然也一直還在被使用中，但是他有幾個限制。
只能用DELPHI連，只有一個中介伺服器可以連。
一個更好的database proxy，最好就是能提供ODBC/JDBC介面，讓前面的系統能夠使用。
當然，還應該要能容錯，可以多台伺服器並行使用。
英國有一套軟體叫做OpenLink就是作這檔事的，那幹麼不用？ 不是因為貴，是因為重。
我理想中的資料庫中介，第一要快、第二要穩、第三要小，之後才是通用性。
OpenLink作到了通用性第一，穩定性第二，自此無它。
我的小工具作到了，快、穩、小，但不通用。
所以，要改版啦，在WINDOWS可以借用MSMQ，但是要通用，要免錢，在Unix環境下，就要另尋出路了。
目標：
1. 借用通用的Queue達成分散式的目標
2. ODBC介面
3. 跨平台
完畢