背景：
對于舊有系統的改造和升級，最苦惱的莫過于跨平臺，跨語言。我的一個朋友最近從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）
@2008 楊一. 版權所有. 保留所有權利