关于 ZeroC ICE 的不成熟思考
2011-11-25 14:04
106 查看
分类:
Ice 中间件 2009-09-10 06:52
829人阅读 评论(1)
收藏
举报
最近正在看 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作为基础平台,这显然需要更大的工作量,更大的困难和挑战。
以上是看书期间对读到的内容所作的思考,可能相当不成熟。权且记录下来,以后加以验证是否可行。
Ice 中间件 2009-09-10 06:52
829人阅读 评论(1)
收藏
举报
最近正在看 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 的不成熟思考(续)
- 关于 ZeroC ICE 的不成熟思考
- 关于 ZeroC ICE 的不成熟思考
- 关于恶意经销商模型的一些思考
- 关于大型网站技术演进的思考(一)--存储的瓶颈(1)
- 关于“Return empty arrays or collections, not nulls”的思考
- 关于某蔡傅里叶变换课的思考(元旦前更新)
- 一个Tahoma字体bug引发的思考—关于样式bug的分析流程
- 关于雄安新区的一点观察和思考
- 关于自己封装Web前端框架的思考和探索
- 关于web服务器架构的思考
- Zeroc ICE 源码分析三 ICE的网络通信
- 关于自组织团队建立的先决条件的思考
- 关于项目管理的思考
- 关于为什么要使用脚本引擎与脚本的一点思考
- 关于值类型和引用类型的思考
- 关于创业的思考
- 关于职业的思考
- 关于自动化测试的一些思考(一)
- 从入门到放弃:关于消息推送(Push)的复盘思考