ICE官方文档中2.2【The Ice Architecture】章节翻译之二 收藏
2.2.3 Slice(Specification Language for ICE)
就像前面提到的，每个ice对象都有一个接口，接口中包括很多的操作；接口、操作、数据类型要想在客户端和服务端进行交互，就需要用Slice语言来进行定义；Slice允许用某种方式定义客户端和服务端交互的契约，该契约是与编程语言无关的，比如C++、Java、C#；Slice的定义被编译器编译成特定编程语言对应的API，也即：针对定义好的接口、数据类型的API内容都是由自动生成的代码组成。
2.2.4 Language Mappings
控制每个Slice构造器如何转换成对应语言的规则被称为语言映射【Language Mappings】；比如，对于C++映射（详见Chapter 6），Slice中的序列【Sequence】以STL vector的形式出现；而对于Java映射（详见Chapter 10），Slice中的序列以Java array的形式出现；为了确定对于特定Slice构造的API看起来到底像什么，你只需要了解Slice定义、以及Slice语言映射规则即可；语言映射的规则非常地简单、有规律性，以至于你根本不需要去阅读自动生成的代码就可以知道怎样去使用这些生成的API。
当然，你完全可以去阅读自动生成的代码；但是，一般来说【as a rule】，自动生成的代码还不是非常适合于人的阅读的；我们推荐你熟练掌握语言映射规则，这样你就可以最大限度的忽略自动生成的代码，你只需要关注那些你很感兴趣的一些特定细节即可。
目前，Ice对C++、Java、C#、Python提供语言映射；对于客户端，目前还支持PHP、Ruby。
2.2.5 Clients and Servers Structure
Ice客户端、服务端都有如下的内部逻辑结构：
从上图可以看出，两者都由应用代码、lib代码、从Slice定义自动生成的代码这三者一起混合组合：
Ice Core包含客户端、服务端为支持远程通信而需要的运行时；这些代码关注的是网络、线程、字节排序、以及其他一些和网络相关的问题，这样就可以让应用代码远离这些问题；Ice Core以很多lib包的形式提供给客户端、服务端使用。
Ice Core中的通用部分可以通过Ice API进行访问；你可以使用这些API来处理一些零星的琐事，比如初始化、关闭Ice运行时；Ice API对于客户端、服务端来说都是一样的，只是服务端比客户端使用API更多。
Proxy代码是从Slice定义中自动生成的，所以他主要是和你在Slice中定义好的对象、数据类型有关；代理代码主要有两个主要功能：
对于客户端他提供向下调用【down-call】的接口；在生成的代理API中调用一个功能最终会以发送一个RPC消息请求给服务端而结束，服务端会在对应的目标对象上调用一个对应的功能；
他提供marshaling、unmarshaling代码
Marshaling是指序列化一个复杂对象的过程；比如要想传输一个序列，Marshaling代码会将数据转换成一种可传输的标准形式；
Unmarshaling是Marshaling的逆过程；也即，当数据通过网络到达时需要反序列化，重新构造一个本地的数据类型展现形式，以便适合于编程语言的使用；
Skeleton代码也是从Slice定义中自动生成的，所以他也是和Slice中定义的对象和数据类型有关；存根代码就相当于服务端的代理代码；他提供一个上行调用【up-call】接口，该接口允许Ice运行时将线程控制权转向应用代码，存根也提供marshaling、unmarshaling代码，这样服务端就能接收由客户端发送过来的参数，同时返回参数或者异常给客户端。
Object Adapter是服务端相关ICE API中的一部分，只有服务端才会使用对象适配器，一个对象适配器主要有以下一些功能：
对象适配器将客户端发起的请求映射到具体对象的方法上面；换句话说，对象适配器根据对象标识来跟踪到底是哪个伺服器【servant】。
对象适配器可以与一个或多个传输协议端点关联；如果超过一个传输协议端点与一个对象适配器关联，伺服器可以通过多种传输协议到达；比如，一个适配器同时关联了TCP/IP和UDP端点，此时适配器就可以提供可选的Qos和性能特性了；
对象适配器负责创建能够被传输到客户端的代理；对象适配器知道他的每一个对象的类型、标识、传输协议详情，当服务端应用代码请求创建一个代理时对象适配器只需要将这些信息嵌入即可；
注意到，就关注的过程视图中，过程中只涉及到两个点：客户端、服务端；为了支持分布式通信，所有的运行时被Ice lib和从Slice定义中生成的代码提供。
2.2.6 The Ice Protocol
ICE提供的是RPC协议，他使用TCP/IP、或者UDP作为底层传输协议；除此之外，Ice还允许使用SSL来作为传输协议，这样客户端和服务端之间的所有通信都是被加密的。
Ice协议定义如下一些内容：
很多的消息类型，比如请求和回复消息类型；
一个协议状态机，能够确定不同消息类型在客户端和服务端之间交换信息时以何种顺序进行；以及针对TCP/IP协议的连接建立以及释放；
编码规则，他决定了每种类型的数据在传输过程中的表现形式；
对每条信息的消息头，包括详细信息有：消息类型、消息尺寸、以及协议和编码版本；
Ice也支持传输过程中的数据压缩功能：通过设置一个可配置的参数即可，这样你就能压缩网络流量从而节省带宽；如果你的应用程序在客户端和服务端之间有大量数据需要交互，那这是非常有用的。
Ice协议很适合于构建高效的事件转发机制，因为他允许在不知道消息体内任何详细信息的情况下对消息进行转发；这就意味着消息的转发不需要任何的消息反序列化和重新序列化【unmarshaling and remarshaling】，他们转发一条消息，只是简单的把他作为一个不透明的字节缓冲器而已。
Ice协议也支持双向操作：如果服务端想要发送一条消息给客户端提供的一个回调对象，就可以直接通过由客户端调用请求时创建的那个原始连接进行回调；当客户端位于防火墙之后，而防火墙只允许友好【outgoing】连接、而不允许外来【incoming】连接访问，此时这个特性就显得异常重要了。
2.4 Architectural Benefits of Ice
Ice的架构对应用开发者来说提供了很多的好处：
面向对象语义
Ice全面维持【preserve】面向对象的样式【paradigm】“Across the wire”；所有的操作调用都使用后期绑定【late binding】，这样所有操作的实现都是依赖于实际运行时（不是静态的【not static】）的对象类型；
支持同步和异步消息
Ice同时提供同步和异步的操作调用和操作分发，通过IceStorm还可以实现发布-订阅【publish-subscribe】消息；这就允许你去根据应用需要选择通信模型，而不是一定得让应用程序去适应某个单独的模型；
支持多个接口
通过facet，对象能够提供多个不相关的接口，同时这些接口却保持着同一个对象标识；特别地，随着应用的不断演变，却需要去保持对老的、已经部署过的客户端保持兼容时，对此Ice就提供了非常好的灵活性；
机器无关性
通过底层的机器架构，客户端和服务端是完全隔离的【shield】；类似字节排序和填充这些问题对于应用代码而言都是隐藏的；
语言无关性
客户端和服务端能够独立的用不同编程语言开发；客户端和服务端通过使用Slice定义来确定双方都需要遵循的契约，而这也是双方唯一需要达成一致的；
实现无关性
客户端对于服务端如何实现他们的对象是不知道的；这就意味着客户端被部署之后服务端的实现仍然可以被改变；比如，可以使用不同的持久机制，甚至使用不同的编程语言；
操作系统无关性
Ice API是非常轻便的，所以相同的源代码可以在Windows和Unix下面编译和运行；
线程支持
Ice运行时是完全基于线程的，Ice API也是线程安全的；对需要开发基于线程的、高性能的客户端和服务端应用程序的开发者而言是不需要什么努力【no effort】的；
传输协议无关性
Ice目前支持TCP/IP和UDP作为传输协议，可以通过配置参数选择想要的传输协议；客户端和服务端代码都无需关注底层的传输协议；
定位和服务器透明性
Ice运行时负责定位和查找对象、以及管理底层传输协议机制，比如打开和关闭连接；客户端和服务端的交互就像是没有连接一样；通过IceGrid，你能够让服务端按需【on demand】启动，也即当客户端调用一个操作时服务端若不在运行状态，此时服务器自动开始运行；服务器还能在不破坏被客户端持有的代理情况下迁移到不同的物理地址上，此时客户端是完全不知道对象的实现是如何通过服务端进程分发的；
安全性
客户端和服务端能够在具有强大加密功能的SSL协议下进行通信，这样应用程序就能够在不安全的公共网络上进行安全的通信了；通过Glacier2，你能够穿越防火墙，实现对请求的安全转发，而且还对回调提供全面支持；
内置持久化
有了Freeze，创建持久化对象实现变得毫无价值；Ice通过内置高性能的Berkeley DB数据库来提供支持；
源码可用性
Ice的源代码是可用的；虽然对于使用该平台时看源码不是必要的，但是他让你可以知道事情到底是如何完成的；
终上所述，Ice对于分布式计算提供了比我们熟知的其他平台更加完善的、更具有生产力的【state-of-the art】开发和部署环境。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/sfdev/archive/2008/12/07/3468777.aspx