一個C語言開發(fā)的中間件，通過API暴露給二次開發(fā)及插件應(yīng)用?，F(xiàn)在由于對其應(yīng)用的需求變得日趨復(fù)雜，而且正在脫離Unix的管理環(huán)境，走向基于JWS這樣的BCS管理。有朋友推薦我用JNI，但這樣一是增加了耦合度，二是讓Java睡在JNI感覺不太安穩(wěn)。在認知了上下兩層的系統(tǒng)平臺后，問題變得明朗起來：如何在HTTP協(xié)議下實現(xiàn)Java和C之間的交互?
思路：
先從Java的角度入手，Java間的通信方法：
1 通過URL，Applet/JWS訪問被影射到URL的動態(tài)資源(Servlet)
2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)
3 通過序列化和反序列化，實現(xiàn)簡單對象的傳輸(比如Resin的Hessian框架就提供了這種通信的方式)
4 通過一些工具做代碼生成，利用Web Services實現(xiàn)客戶端和服務(wù)端的交互
此外脫離HTTP，還可以做RMI，socket編程
現(xiàn)在問題是通信的一端由Java變成了C/C++, 于是， 解決方案1需要把動態(tài)資源由CGI來定義，而方案3變得不再適用。于是方案有：
1 通過URL，Applet/JWS訪問被影射到URL的動態(tài)資源(CGI)
2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)
3 通過一些工具做代碼生成，利用Web Services實現(xiàn)客戶端和服務(wù)端的交互
解決方案:
現(xiàn)在針對上文提出的3中通信方式中的1和3談一談實現(xiàn)的方法，2的實現(xiàn)方案比較靈活，需要發(fā)揮大家的想象力了：)
針對CGI：
首先CGI可以配置在各種主流的服務(wù)器中作為后端的腳本運行。大家可能對Servlet更熟悉一些。
CGI可以用腳本寫，也可以用C來實現(xiàn)。CGI被觸發(fā)后，通過系統(tǒng)的環(huán)境變量來獲得輸入，在處理完畢后向標準輸出中輸出結(jié)果。
由此可以想見，Web服務(wù)器在接受到來自HTTP協(xié)議的請求后，首先把請求的參數(shù)獲取到，然后設(shè)置到環(huán)境變量里。
根據(jù)對訪問的URL的解析和服務(wù)器自身的配置，找到服務(wù)于請求的CGI程序的位置，然后執(zhí)行這個程序。
這個程序被執(zhí)行后通過環(huán)境變量得到了服務(wù)器先前設(shè)置在環(huán)境變量中的參數(shù)。在經(jīng)過一些復(fù)雜的邏輯操作后，向標準輸出輸出結(jié)果。
這個輸出又被Web服務(wù)器所捕獲，轉(zhuǎn)而傳遞回請求的客戶端。
更多關(guān)于CGI的知識和理解，大家可以通過google來尋找答案
上述CGI的方式可以讓我們直接獲取到結(jié)果，但是方案比較原始和基礎(chǔ)。其缺點有：
1 需要自己制定類型傳輸協(xié)議，做封裝和拆封，否則只支持字符串
2 我們不會為了要用C的API就給它裝一個或者自己實現(xiàn)一個Web服務(wù)器的，這讓我們的底層程序顯得蠢笨而冗余。我們希望能有一個超薄的Server外殼，
在對API封裝后，通過某個端口進行開放即可。
針對Web Servcies：
Based on上面的兩個不足，我們只能把希望寄托在Web Services身上了，
考試,大在這里推薦給大家的是在C/C++很的Web Services工具gSOAP。
通過這個工具，我們可以做到：
1 一個Stand-alone的服務(wù)器外殼
2 一個根據(jù)API程序自動生成的Web Services服務(wù)
3 一個WSDL描述符文件
思路：
先從Java的角度入手，Java間的通信方法：
1 通過URL，Applet/JWS訪問被影射到URL的動態(tài)資源(Servlet)
2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)
3 通過序列化和反序列化，實現(xiàn)簡單對象的傳輸(比如Resin的Hessian框架就提供了這種通信的方式)
4 通過一些工具做代碼生成，利用Web Services實現(xiàn)客戶端和服務(wù)端的交互
此外脫離HTTP，還可以做RMI，socket編程
現(xiàn)在問題是通信的一端由Java變成了C/C++, 于是， 解決方案1需要把動態(tài)資源由CGI來定義，而方案3變得不再適用。于是方案有：
1 通過URL，Applet/JWS訪問被影射到URL的動態(tài)資源(CGI)
2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)
3 通過一些工具做代碼生成，利用Web Services實現(xiàn)客戶端和服務(wù)端的交互
解決方案:
現(xiàn)在針對上文提出的3中通信方式中的1和3談一談實現(xiàn)的方法，2的實現(xiàn)方案比較靈活，需要發(fā)揮大家的想象力了：)
針對CGI：
首先CGI可以配置在各種主流的服務(wù)器中作為后端的腳本運行。大家可能對Servlet更熟悉一些。
CGI可以用腳本寫，也可以用C來實現(xiàn)。CGI被觸發(fā)后，通過系統(tǒng)的環(huán)境變量來獲得輸入，在處理完畢后向標準輸出中輸出結(jié)果。
由此可以想見，Web服務(wù)器在接受到來自HTTP協(xié)議的請求后，首先把請求的參數(shù)獲取到，然后設(shè)置到環(huán)境變量里。
根據(jù)對訪問的URL的解析和服務(wù)器自身的配置，找到服務(wù)于請求的CGI程序的位置，然后執(zhí)行這個程序。
這個程序被執(zhí)行后通過環(huán)境變量得到了服務(wù)器先前設(shè)置在環(huán)境變量中的參數(shù)。在經(jīng)過一些復(fù)雜的邏輯操作后，向標準輸出輸出結(jié)果。
這個輸出又被Web服務(wù)器所捕獲，轉(zhuǎn)而傳遞回請求的客戶端。
更多關(guān)于CGI的知識和理解，大家可以通過google來尋找答案
上述CGI的方式可以讓我們直接獲取到結(jié)果，但是方案比較原始和基礎(chǔ)。其缺點有：
1 需要自己制定類型傳輸協(xié)議，做封裝和拆封，否則只支持字符串
2 我們不會為了要用C的API就給它裝一個或者自己實現(xiàn)一個Web服務(wù)器的，這讓我們的底層程序顯得蠢笨而冗余。我們希望能有一個超薄的Server外殼，
在對API封裝后，通過某個端口進行開放即可。
針對Web Servcies：
Based on上面的兩個不足，我們只能把希望寄托在Web Services身上了，
考試,大在這里推薦給大家的是在C/C++很的Web Services工具gSOAP。
通過這個工具，我們可以做到：
1 一個Stand-alone的服務(wù)器外殼
2 一個根據(jù)API程序自動生成的Web Services服務(wù)
3 一個WSDL描述符文件