一個(gè)C語言開發(fā)的中間件，通過API暴露給二次開發(fā)及插件應(yīng)用?，F(xiàn)在由于對(duì)其應(yīng)用的需求變得日趨復(fù)雜，而且正在脫離Unix的管理環(huán)境，走向基于JWS這樣的BCS管理。有朋友推薦我用JNI，但這樣一是增加了耦合度，二是讓Java睡在JNI感覺不太安穩(wěn)。在認(rèn)知了上下兩層的系統(tǒng)平臺(tái)后，問題變得明朗起來：如何在HTTP協(xié)議下實(shí)現(xiàn)Java和C之間的交互?

思路：

先從Java的角度入手，Java間的通信方法：

1 通過URL，Applet/JWS訪問被影射到URL的動(dòng)態(tài)資源(Servlet)

2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)

3 通過序列化和反序列化，實(shí)現(xiàn)簡(jiǎn)單對(duì)象的傳輸(比如Resin的Hessian框架就提供了這種通信的方式)

4 通過一些工具做代碼生成，利用Web Services實(shí)現(xiàn)客戶端和服務(wù)端的交互

此外脫離HTTP，還可以做RMI，socket編程

現(xiàn)在問題是通信的一端由Java變成了C/C++, 于是， 解決方案1需要把動(dòng)態(tài)資源由CGI來定義，而方案3變得不再適用。于是方案有：

1 通過URL，Applet/JWS訪問被影射到URL的動(dòng)態(tài)資源(CGI)

2 通過URL，Applet/JWS訪問共享的靜態(tài)資源(Server定期更新靜態(tài)資源)

3 通過一些工具做代碼生成，利用Web Services實(shí)現(xiàn)客戶端和服務(wù)端的交互
　　
解決方案:

現(xiàn)在針對(duì)上文提出的3中通信方式中的1和3談一談實(shí)現(xiàn)的方法，2的實(shí)現(xiàn)方案比較靈活，需要發(fā)揮大家的想象力了：)

針對(duì)CGI：

首先CGI可以配置在各種主流的服務(wù)器中作為后端的腳本運(yùn)行。大家可能對(duì)Servlet更熟悉一些。

CGI可以用腳本寫，也可以用C來實(shí)現(xiàn)。CGI被觸發(fā)后，通過系統(tǒng)的環(huán)境變量來獲得輸入，在處理完畢后向標(biāo)準(zhǔn)輸出中輸出結(jié)果。

由此可以想見，Web服務(wù)器在接受到來自HTTP協(xié)議的請(qǐng)求后，首先把請(qǐng)求的參數(shù)獲取到，然后設(shè)置到環(huán)境變量里。

根據(jù)對(duì)訪問的URL的解析和服務(wù)器自身的配置，找到服務(wù)于請(qǐng)求的CGI程序的位置，然后執(zhí)行這個(gè)程序。

這個(gè)程序被執(zhí)行后通過環(huán)境變量得到了服務(wù)器先前設(shè)置在環(huán)境變量中的參數(shù)。在經(jīng)過一些復(fù)雜的邏輯操作后，向標(biāo)準(zhǔn)輸出輸出結(jié)果。

這個(gè)輸出又被Web服務(wù)器所捕獲，轉(zhuǎn)而傳遞回請(qǐng)求的客戶端。

更多關(guān)于CGI的知識(shí)和理解，大家可以通過google來尋找答案

上述CGI的方式可以讓我們直接獲取到結(jié)果，但是方案比較原始和基礎(chǔ)。其缺點(diǎn)有：

1 需要自己制定類型傳輸協(xié)議，做封裝和拆封，否則只支持字符串

2 我們不會(huì)為了要用C的API就給它裝一個(gè)或者自己實(shí)現(xiàn)一個(gè)Web服務(wù)器的，這讓我們的底層程序顯得蠢笨而冗余。我們希望能有一個(gè)超薄的Server外殼，

在對(duì)API封裝后，通過某個(gè)端口進(jìn)行開放即可。

針對(duì)Web Servcies：

Based on上面的兩個(gè)不足，我們只能把希望寄托在Web Services身上了，

筆者在這里推薦給大家的是在C/C++很著名的Web Services工具gSOAP。

通過這個(gè)工具，我們可以做到：

1 一個(gè)Stand-alone的服務(wù)器外殼

2 一個(gè)根據(jù)API程序自動(dòng)生成的Web Services服務(wù)

3 一個(gè)WSDL描述符文件

【編輯推薦】

1. PHP與Java集成開發(fā)詳解
2. 從VC++移植到GCC后的語法差異
3. Java與C++編程的不同