ICE 分布式中间件开发VS 分布式开发之ACE
ICE(Internet Communications Engine)是ZeroC 提供的一款高性能的中间件，基于ICE 可以实现电信级的解决方案。前面我们提到过在设计网站架构的时候可以使用ICE 实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架构。基于ICE 的数据
层可以在未来方便的进行扩展。ICE 支持分布式的部署管理，消息中间件，以及网格计算等等。
大道理讲完，言归正传，最近育儿网新增了不少新服务，服务间经常会需要相互调用数据，例如用户中心要取博客系统里的文章啊，论坛里发文后要在积分系统里增加用户积分啊。由于设计时这些服务仅仅基于统一的用户中心，服务间基本是独立的，所以要实现这些调用只能在每个服务上新增为其它服务提供服务的服务 -_-!。这个时候有几个可选方案，我们开始选择了xml-rpc，基于http 和xml 的远程调用，用了一段时间，发现维护成本和访问性能都存在问题。
由于这些中间服务部署的时候是和各自所属的服务部署在一起的，对这些服务做整体的改动就非常困难，要维护起来就比较麻烦。另外由于是什么http 和 xml 作为通信协议，由php实现业务逻辑，性能问题也很明显，而且这些http 请求都会在http 日志留下足迹，导致我们的日志分析很不精确。这个问题不是太大，但很郁闷，所以我们考虑使用ICE 来解决这个问题，至于SOAP 什么的就不考虑了，同样效率低下。
实现的过程还是比较顺利，花了三天的时间用c++实现了大部分常用的接口，服务端采用deamon 的方式运行，错误日志记在syslog 里 (/var/log/messages)，客户端PHP，编译进去了IcePHP，调用的方法很简单。现在还存在一些问题，运行的时候会异常退出，还需要一段时间来解决，暂时加了只狗看着，一旦进程里没了就重新启动。
既然要跨平台通讯，就涉及对象描述，ICE 使用Slice 来对结构，类，方法等进行定义。完了以后服务器端，客户端都按这个来调用和实现。ICE 内置的Linux 下后台Deamon 实现方案非常简单，只需要从Ice::Service 里派生出一个类来，实现run 方法，在这个方法里创建adapter 对象，并在 adapter 对象里添加Servants，然后激活这个adapter 就可以了，网络层的通信都由ICE 接管了。由于是基于tcp/ip 的直接通信，比更高层的 http 通信效率要高很多。
在客户端实现时，我们也碰到了一些小麻烦。一个是内置的$ICE 对象用的时候有时需要用global 声明，否则可能会出错，另外由于默认情况下 Slice 中struct 对应到php 的类型是一个类的实例，而不是一个数组，所以在赋值给页面的时候，smarttemplate 以及其它模板系统中可能都会存在问题，可以通过修改模板系统的数据赋值显示代码解决。我们做了一些性能的测试，同样运行 1 千次请求，使用xml-rpc 实现需要28 秒左右，使用ICE 实现，只需要3 秒多，性能的差距还是很大的，同时在这个过程中没发现有内存泄露的情况，效果还比较理想。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ACE 发布了5.5，ICE-E 发布了1.1
ACE 5.5 于2006 年3 月7 日发布。Doug Schmidt 说5.5 比5.4“大大的好” 。我down 了一个下来，编译了一看，内容果然增加不少。子项目数增加了几十个，光文档压缩包的体积就从原来的54MB 增加到83MB，可见内容大大丰富了。对于我来说，
增加的那些内容恐怕没有什么意义。ACE 的核心思想1994 年就基本确定下来，后面的发展大多数属于非结构性的扩充和应用。今天的普通开发者，真能够弄懂ACE 核心和那几个基本框架的人就已经算是高手了。特别是当出了问题以后，能不能有条不紊地解决，这个可不是容易的事情。这不，今天在 MSN 上跟一个老朋友讨论了5.4.1 中一个例子的错误，他最后只能是通过比较5.5 和5.4.1 版本源码，发现不同，从而判断错误位置，要不就没辙。 ACE已经太庞大，不投入相当的精力很难真正掌握。相比之下，ICE 显得年轻有活力。ICE-E 1.1 今天刚刚发布，这表明他们正在坚定地迈向DRE领域。在前不久的一次访谈中，Doug Schmidt 还坚持说在DRE 领域，RT-CORBA 是唯一的玩家，似乎在故意回避ICE-E。我虽然热爱Doug Schmidt，但是也不得不说，他对于老朋友Michi Henning 一帮人搞出来的ICE 态度确实不太友善。前年两派人在comp.soft-sys.ace 和
comp.object.corba 中曾经爆发口水战，Doug Schmidt 对Michi Henning 恶语相向，有失大师风度，这事让我印象深刻。
DRE［Dynamic Reasoning Engine(DRE)，缺陷排除效率？］领域里有两个东西在互相竞争，而且都是开源的，这是多好的事情！这个技术本身的军用背景非常深厚，不知道我们的政府军队有没有组织力量研究掌握消化之？迈向信息化别光停留在口头上，还得实干一点。回过来说 ICE，虽然我很欣赏他，但是前几天一个在大型分布式开发领域很有经验的前辈说，跟ACE 相比，这个东西太高层了，真正开发超大规模、超高性能应用的时候，还是得ACE上。再不然就直接用C。可还是那句话，C 的抽象能力太有限，程序维护超过几年，经过几个人的手，就没人说得清里面是怎么回事了。说来说去，ACE 还是不错的选择。
＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠22
Distributed Programming with Ice by Michi Henning and Mark Spruiell
《Ice 分布式程序设计1.3.0 版》
"The Internet Communications Engine (Ice) is a modern alternative to object middleware such
as CORBA™ or COM/DCOM/COM+. Ice is easy to learn, yet provides a powerful network
infrastructure for demanding technical applications. Ice shines where technologies such as SOAP
or XML-RPC are too slow, or do not provide sufficient scalability or security. For a comparison
between Ice and CORBA, please see this page."
、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
ICE是远程对象的封装
ACE是通讯（如SOCKET）的封装
也就是说，ACE比ICE更底层，怎么比较？
ICE侧重于远程RPC解决方案，而ACE是通用网络编程框架。
在应用层面上，ACE所处位置比ICE要低。
基于ACE的CORBAR实现TAO和ICE倒是可以比较比较。
ICE是与CORBA，.NET Remoting,Web Service同层次的东西，ACE是个网络编程库，准确的说是个C++对Socket网络操作的封装。而ICE是个RPC与DO（分布式对象）的协定， 与语言没有关系，这一点和CORBA，Web Service，.NET Remoting相同，但ICE更简单。需要注意的是，.NET Remoting只能由.NET支持的语言实现，也是非常棒的RPC解决方案。
层可以在未来方便的进行扩展。ICE 支持分布式的部署管理，消息中间件，以及网格计算等等。
大道理讲完，言归正传，最近育儿网新增了不少新服务，服务间经常会需要相互调用数据，例如用户中心要取博客系统里的文章啊，论坛里发文后要在积分系统里增加用户积分啊。由于设计时这些服务仅仅基于统一的用户中心，服务间基本是独立的，所以要实现这些调用只能在每个服务上新增为其它服务提供服务的服务 -_-!。这个时候有几个可选方案，我们开始选择了xml-rpc，基于http 和xml 的远程调用，用了一段时间，发现维护成本和访问性能都存在问题。
由于这些中间服务部署的时候是和各自所属的服务部署在一起的，对这些服务做整体的改动就非常困难，要维护起来就比较麻烦。另外由于是什么http 和 xml 作为通信协议，由php实现业务逻辑，性能问题也很明显，而且这些http 请求都会在http 日志留下足迹，导致我们的日志分析很不精确。这个问题不是太大，但很郁闷，所以我们考虑使用ICE 来解决这个问题，至于SOAP 什么的就不考虑了，同样效率低下。
实现的过程还是比较顺利，花了三天的时间用c++实现了大部分常用的接口，服务端采用deamon 的方式运行，错误日志记在syslog 里 (/var/log/messages)，客户端PHP，编译进去了IcePHP，调用的方法很简单。现在还存在一些问题，运行的时候会异常退出，还需要一段时间来解决，暂时加了只狗看着，一旦进程里没了就重新启动。
既然要跨平台通讯，就涉及对象描述，ICE 使用Slice 来对结构，类，方法等进行定义。完了以后服务器端，客户端都按这个来调用和实现。ICE 内置的Linux 下后台Deamon 实现方案非常简单，只需要从Ice::Service 里派生出一个类来，实现run 方法，在这个方法里创建adapter 对象，并在 adapter 对象里添加Servants，然后激活这个adapter 就可以了，网络层的通信都由ICE 接管了。由于是基于tcp/ip 的直接通信，比更高层的 http 通信效率要高很多。
在客户端实现时，我们也碰到了一些小麻烦。一个是内置的$ICE 对象用的时候有时需要用global 声明，否则可能会出错，另外由于默认情况下 Slice 中struct 对应到php 的类型是一个类的实例，而不是一个数组，所以在赋值给页面的时候，smarttemplate 以及其它模板系统中可能都会存在问题，可以通过修改模板系统的数据赋值显示代码解决。我们做了一些性能的测试，同样运行 1 千次请求，使用xml-rpc 实现需要28 秒左右，使用ICE 实现，只需要3 秒多，性能的差距还是很大的，同时在这个过程中没发现有内存泄露的情况，效果还比较理想。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ACE 发布了5.5，ICE-E 发布了1.1
ACE 5.5 于2006 年3 月7 日发布。Doug Schmidt 说5.5 比5.4“大大的好” 。我down 了一个下来，编译了一看，内容果然增加不少。子项目数增加了几十个，光文档压缩包的体积就从原来的54MB 增加到83MB，可见内容大大丰富了。对于我来说，
增加的那些内容恐怕没有什么意义。ACE 的核心思想1994 年就基本确定下来，后面的发展大多数属于非结构性的扩充和应用。今天的普通开发者，真能够弄懂ACE 核心和那几个基本框架的人就已经算是高手了。特别是当出了问题以后，能不能有条不紊地解决，这个可不是容易的事情。这不，今天在 MSN 上跟一个老朋友讨论了5.4.1 中一个例子的错误，他最后只能是通过比较5.5 和5.4.1 版本源码，发现不同，从而判断错误位置，要不就没辙。 ACE已经太庞大，不投入相当的精力很难真正掌握。相比之下，ICE 显得年轻有活力。ICE-E 1.1 今天刚刚发布，这表明他们正在坚定地迈向DRE领域。在前不久的一次访谈中，Doug Schmidt 还坚持说在DRE 领域，RT-CORBA 是唯一的玩家，似乎在故意回避ICE-E。我虽然热爱Doug Schmidt，但是也不得不说，他对于老朋友Michi Henning 一帮人搞出来的ICE 态度确实不太友善。前年两派人在comp.soft-sys.ace 和
comp.object.corba 中曾经爆发口水战，Doug Schmidt 对Michi Henning 恶语相向，有失大师风度，这事让我印象深刻。
DRE［Dynamic Reasoning Engine(DRE)，缺陷排除效率？］领域里有两个东西在互相竞争，而且都是开源的，这是多好的事情！这个技术本身的军用背景非常深厚，不知道我们的政府军队有没有组织力量研究掌握消化之？迈向信息化别光停留在口头上，还得实干一点。回过来说 ICE，虽然我很欣赏他，但是前几天一个在大型分布式开发领域很有经验的前辈说，跟ACE 相比，这个东西太高层了，真正开发超大规模、超高性能应用的时候，还是得ACE上。再不然就直接用C。可还是那句话，C 的抽象能力太有限，程序维护超过几年，经过几个人的手，就没人说得清里面是怎么回事了。说来说去，ACE 还是不错的选择。
＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠＠22
Distributed Programming with Ice by Michi Henning and Mark Spruiell
《Ice 分布式程序设计1.3.0 版》
"The Internet Communications Engine (Ice) is a modern alternative to object middleware such
as CORBA™ or COM/DCOM/COM+. Ice is easy to learn, yet provides a powerful network
infrastructure for demanding technical applications. Ice shines where technologies such as SOAP
or XML-RPC are too slow, or do not provide sufficient scalability or security. For a comparison
between Ice and CORBA, please see this page."
、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
ICE是远程对象的封装
ACE是通讯（如SOCKET）的封装
也就是说，ACE比ICE更底层，怎么比较？
ICE侧重于远程RPC解决方案，而ACE是通用网络编程框架。
在应用层面上，ACE所处位置比ICE要低。
基于ACE的CORBAR实现TAO和ICE倒是可以比较比较。
ICE是与CORBA，.NET Remoting,Web Service同层次的东西，ACE是个网络编程库，准确的说是个C++对Socket网络操作的封装。而ICE是个RPC与DO（分布式对象）的协定， 与语言没有关系，这一点和CORBA，Web Service，.NET Remoting相同，但ICE更简单。需要注意的是，.NET Remoting只能由.NET支持的语言实现，也是非常棒的RPC解决方案。