关于 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作为基础平台,这显然需要更大的工作量,更大的困难和挑战。

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

你可能感兴趣的:(关于 ZeroC ICE 的不成熟思考)