关于 ZeroC ICE 的不成熟思考

最近正在看 Distributed Programming with Ice，看到IceGrid这部分了。一直以来想找到关于Ice的负面评价——没找到。我不相信。我秉承任何系统都是有缺点的这个理念，相信Ice有不如其它系统的地方。

 

对于客户端需要直接访问硬件的系统，用C++开发比较好，目前搜索了许多与C++配合的中间件。但是C++能用的中间件比较少，使用CORBA，COM都不合适。最希望能够与 Java 中间件联系，考虑了 Hessian。但是发现 Hessiancpp 已经数年不更新了，不能作为一种可靠的通讯技术手段。相对于ACE、TAO等高端中间件技术，还是使用 ZeroC ICE 比较合适。

 

在阅读 ICE 文档过程中发现它作为中间件是非常合适的，在性能和可靠性方面有众多的考虑，果然不同凡响。但是涉及到数据库访问方面并没有过多提及。虽然我还没看到 Freeze，但是从介绍中可以知道，ICE的持久化使用的berkeley db，这是一个本地数据库系统。

 

对于需要大型数据库系统，如Oracle的环境中，应该如何使用ICE，在网上查找了N次，均无明确表示。在ZeroC 论坛上有一个介绍说，要自己写 Servant ，而不能使用 Freeze。也就是说ICE并不负责访问数据库。数据库访问层DAO要由开发者自己去做。

 

以前在使用 Java 时有 Spring + Hibernate 非常的强大的中间层、数据库访问架构，现在对比之下ICE应该相当于Spring，但是C++的世界里还没有很好的ORM工具。所以开发访问数据库的工作量还是比较大的，而且开发一个好的DAO也不容易，要考虑到许多问题。

 

另外，当需要C++访问Java服务器的时候，使用ICE做沟通应该是相对好的解决方案。C++ 客户端访问ICE，然后由ICE调用Java创建的Servant 去访问 Spring 中间件。在大型企业系统中，企业的基础系统往往不是由C++构成就是由Java构成，因此ICE能够成为两者的粘合剂。但是这种访问的效率如何，现在还不知道。

 

对于直接使用TCP,UDP —  这些太底层了，而且要考虑线程，并发，缓存，容错，分布……实现一个健壮的系统并不容易。为何不使用FTP，HTTP —  这些太高层了，存在效率问题，而且也不是真正的中间层融合。

 

一个选择方案是Java服务器作为基础平台，通过ICE为各种语言设施提供访问接口，它的效率应该在Web Service之上。

另一个更好的方案是使用ICE作为基础平台，这显然需要更大的工作量，更大的困难和挑战。

 

以上是看书期间对读到的内容所作的思考，可能相当不成熟。权且记录下来，以后加以验证是否可行。