对于旧有系统的改造和升级，最苦恼的莫过于跨平台，跨语言。我的一个朋友最近从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描述符文件