Ice与CORBA的差异
Ice与CORBA的差异
之前已经想将ZeroC主页上的这篇文章翻译出来，前一段时间翻译了一半，就放下了。到了今天终于翻译完。现在已经是凌晨3点多，听着歌，想着她，并且将这篇文章发布到自己的Blog。
============================================================
首先声明,我们既不想引起一场"CORBA vs Ice"的争论，也不想怀疑CORBA。相反，我们认为CORBA在它的时代是一个很大的成就，而且，Ice也明显借用了CORBA的很多思想。
我们决定写这篇比较文章是因为我们期望更多的人能正确地询问我们为何他们要用Ice代替CORBA。对这个问题，我们通常的回答是：为什么不先自己试试使用 Ice呢？我们敢肯定，一旦你使用了Ice有一段时间，你就永远不会再想用回CORBA。请相信我们，很容易会喜欢上Ice，因为它优雅、简单，它的结构一致性，而且最后一点：至少它没有大量的特性和工具。
对于没有时间去试验Ice来了解它的人，这里有一些原因让我们相信Ice优于CORBA：
1、Completeness(完备性)
当我们说到完备性时，我们的意思是实际产品的完备性，而不是从来未被实现的标准的完备性。我们相信Ice比市场上任何单个CORBA更完备。你可以自己做一个检查：市场上有哪个CORBA产品提供了跟Ice可比较的特性？
2、Performance(性能)
由于具有CORBA所没有的结构优点，Ice具有突出的性能。Ice高效的协议、请求批量化、高效的事件分发都意味着Ice比CORBA ORB运行得更快，同时消耗更少的线路带宽。
3、No "Design by Committee"(非“委员会设计”)
Ice由一群专业的资深专家所设计。Ice没有设计成适合所有人的“万金油”。而CORBA则充斥着被具有特权的制定者加进到标准里的众多不切实际的特性，却又没有真正考虑到这些特性是否会被真正地实现。
通常，为了就CORBA标准达成一致的唯一方法就是将之前大量实现的特性放在一起，生硬地塞进标准里。这导致了标准越来越大，也越来越复杂，超出了实际的需要。这也意味着平台更大更慢，也因为复杂的API导致了难以使用。Ice提供的API集小得多，也更高效，比CORBA的API易于学习使用，并且功能并不少。
4、Slice
Slice，Ice的规范定义语言，比CORBA IDL更小、更简洁、更强大。Slice具有更少的语言结构，但却更灵活。例如，一个内建的字典类型提供直接快速访问数据结构，异常的继承允许更清晰地影射到支持异常处理的语言。同时，Slice抛弃了CORBA IDL不需要的复杂性，例如属性，inout参数，上下文和传值对象(Objects-by-Value)的复杂性。
5、Language Mappings(语言影射)
Ice支持到C++、Java、Python、PHP、C#和Visual Basic的语言影射。我们知道任何一个CORBA实现提供商都没有提供那么多的语言影射选择。
实际上大多数的CORBA提供商只提供C++和Java的影射，如果你想使用其它语言影射，你就要切换到不同的提供商的产品或使用没有实验支持的CORBA实现。
6、Persistence(持久性)
Slice并不单单是一个接口定义语言。它也可以用来描述Ice对象进行持久的属性，使得很容易写出支持对象持久的服务器端程序。
7、Metadata(元数据)
Slice支持可扩展的元数据设施，它允许Slice为实现应用程序相关的某些目的而使用元数据的标记。例如元数据可以用于定制不同于标准Java影射方式的影射来满足某些特定程序的要求。
8、No any Type(没有any数据类型)
Ice 没有CORBA里Any类型的等价数据类型。这对于CORBA用户来说可能感到很惊讶，因为Any数据类型在CORBA标准里被广泛地使用。但是，Any 数据类型是多余的：程序语言象Java和C++并没有Any数据类型，而且Any数据类型对分布式系统来说也不是属于一个良好的设计。Any数据类型通常用在两种情况下：一种是需要在系统的中介部分对接收到的数据直接进行传递，而不用关心数据的真实类型，例如CORBA的Event服务，另一种是用来作为 union(联合结构体)的一个等价物。
Ice可以通过发送和接收"blobs"的请求来满足第一种情况，Slice的类继承可以满足第二种情况。任何一种情况，Ice的程序都更高效，更加具有类型安全，更加容易设计和实现，而不会遇到使用CORBA Any数据类型时所具有的复杂性。
9、Ice Core(Ice的核心)
虽着时间的演化，CORBA的核心变得异常的复杂。一个初级的例子要在POA(CORBA的对象适配器)里面正确使用都需要很专业的知识，即使你只想支持一小部分的技术特性。Ice的对象适配器，在另一方面来说，更加简单、直观、也跟POA一样的功能强大：定义良好的API使得比POA开发一个可扩展的程序项目需要更少的工作。
10、Ice Protocol(Ice协议)
IIOP是CORBA的弱点之一，具有太多的设计缺陷。例如，没有缺少请求的封装来防止消息的分发。低效的对齐规则导致了多余的数据拷贝。数据的编码规则复杂，却没有带来相应的性能的提高，对象引用的编码异常复杂，妨碍了有效的的编码和在内存共享的执行。代码集的协商是在标准下达成，会遭遇到很多冲突。所有这些复杂性意味着IIOP很难实现，带来了互操作性和性能上的问题。Ice的协议是简单并且更加有效，它提供了一些IIOP没有提供的特性，例如数据压缩和批请求批量化。
11、Security(安全性)
安全性是CORBA的最大的一个难题。OMG已经通过了多个标准，但很多都没有被广泛地实现，CORBA的客户依然没有一个可工作的安全的ORBs。当设计 Ice时，和CORBA相比，安全性被认为是基本的特性。这就是Ice提供一个真正能运作的SSL实现的安全的防火墙的原因。
12、C++ Mapping(C++映射)
用 C++来使用CORBA非常困难。即使你是很有经验的C++开发者。CORBA的C++映射在内存管理和异常安全方面有很多的陷阱和缺陷。相较之下，Ice的C++映射非常简单和直观。它不会有因为错误而导致内存的泄漏。要记住的映射规则的数目比CORBA的C++映射少得多，而且Ice的C++ 映射是基于工业标准的STL。
14、Scalability(可伸缩性)
当你是一个专家时，CORBA是一种可伸缩性很好的技术。但采用Ice，任何人都可以写出高可伸缩性的应用。例如，Ice实现了一个持久化的逐出器，你可以使用它来很容易地处理上百万的对象，你所做的仅仅是在 Slice的定义里指定对象的数据，剩下的工作Ice一手包办：Ice运行库使用高速的数据库来自动加载和保存对象。
15、Versioning(版本化)
CORBA没有任何机制来支持对象状态的版本化。Freeze是Ice的持久服务，它允许持久数据在Slice的定义中改变时，很容易地进行数据库的移植。
16、Software Updates(软件更新)
IcePatch是一个允许你更行客户端软件的工具。它使用压缩来提高数据的传输，并使用校验值来保证一致性。CORBA完全没有提供一个在分布式环境来进行软件更新的机制。
17、Typed Event Service(类型化的事件服务)
CORBA有一个标准来提供类型化的事件服务，但很少甚至没有被实现。类型化的事件服务也有很多已知的问题，事实上它在真正环境的部署是不可用的。Ice从一开始就提供了类型化事件的服务。IceStorm是一个高效、类型化事件服务的实现，它支持事件联盟。
18、Facets(多接口)
CORBA支持继承，DCOM支持聚合。在过去，有很多关于那一种是更好的方法的争论。Ice以接口继承加上以多接口形式的聚合来同时支持这两种方式。Facets允许你在运行的时候用动态的聚合来扩展类型来替代静态的继承。
19、Asynchronous Messages(异步消息)
CORBA 支持异步消息调用(AMI)，但很少CORBA产品实现了AMI。Ice一开始就以简单和有效的方式支持AMI。Ice也支持异步消息分发(AMD)，这是CORBA里完全没有的东西。AMD等价于客户端的AMI，不过AMD是用在服务器端的。使用AMI，你可以发送了一个请求，然后在以后的一个事件收到服务器的结果时调用一个回调函数来处理返回的结果。而使用AMD，你可以将分发线程归还给Ice，并在结果已经准备好发送到客户端时再次调用分发线程。 AMI和AMD都能被连接起来，这允许你只消耗很少的资源就能构建高效的路由程序。
AMI和AMD对客户端和服务器端来说都是透明的。也就是，一个服务器程序不知道一个请求是否通过AMI调用发出的还是同步地调用发出的，客户端程序也不知道一个操作的调用在服务器端是通过AMD分发处理的还是同步地处理的。当需要使用AMI和AMD时，不用修改Slice。
结束语：
我们希望上面的解释能另你激发你对Ice的兴趣。如果你有任何的问题或解释，我们会邀请你加入我们的邮件列表。我们的目标是不断地改进Ice，因此你的反馈对我们来说是很有价值的。