20111123

IceBox offers a refreshing change of perspective: developers focus on writing
services, not applications. The definition of an application changes as well; using
IceBox, an application becomes a collection of discrete services whose composi-
tion is determined dynamically by configuration, rather than statically by the
linker.

IceBox 提供了一种让人振奋的视角变化:开发者专注于编写服务,而不
是应用。应用的定义变了;使用 IceBox,应用变成了一组离散的服务,其
组合将由配置动态决定,而不是由链接器静态决定。

ICE服务的线程池配置

      在手册的"The Ice Run Time in Detail"的"The Ice Threading Model"章节有详细介绍，摘录常用部分：
      1.每个communicator会创建两个线程池：分别命名为Ice.ThreadPool.Client和Ice.ThreadPool.Server
      2.name.Size：初始线程池的数量，默认为1
      3.name.SizeMax：线程池中最大线程数量，默认为1。线程的数量在Size和SizeMax之间动态调整
      4.name.SizeWarn：线程池的警戒线，超过此值，Ice运行时会输出警告日志信息
      5.name.StackSize：线程池中线程的栈的大小，单位字节，默认为OS的默认值
      6.name.Serialize：大于零表示序列化同一个连接的所有请求，默认为不序列化，即无序的。
     7.默认情况下，所有adapter共享communicator的线程池，但也可以根据具体情况指定单独的线程池，暂时用不到，不多解释了

IceBox开发简记

IceBox是Ice服务的容器，它的设计来源于Service Configurator模式，该模式采取集中式的策略对服务进行加载，管理，服务被设计为可动态加载的组件，服务主要是动态库的形式，然后按需配置到IceBox，这种方式解耦了服务器和服务，使开发人员更专注于业务逻辑服务的开发。
  IceBox的基本开发步骤：
      1。服务类从IceBox::Service派生
      2。实现服务启动接口：start接口
              3。实现服务关闭接口：stop接口
              4。当IceBox加载服务完成时，start接口被调用，start接口一般包含服务初始化的内容，例如申请资源，创建适配器和servants。Stop正好和start相反，如果将start理解为服务的构造函数，则stop就是析构函数

1 编写ICE 接口文件，定义模块，序列和接口；

2 编写服务器端排序服务的头文件和成员函数实现文件，利用vector自带的sort算法，采用默认的less排序方法；

3 编写ICEBOX服务辅助实现的头和成员函数实现文件，负责ICEBOX中服务对象的创建、服务通信器的启动和停止，服务对象的销毁工作；

4 编写ICEBOX、ICEBOX的服务器和客户端的配置文件，配置服务器端的生产的动态库文件、服务器代理和服务器标识，通信方式和通信端口；

5 编写ICEBOX的客户端程序，利用ICE自带的Application Help类创建一个应用，读入客户端的配置文件，启动和请求ICEBOX的服务以及资源回收工作。

6 将生产的动态库文件加载到动态库的默认搜索路径

在启动ICE BOX服务时加载ICE BOX的配置文件，论证最后的排序结果。

试用了ICE的AMI

之前考虑服务端架构时，将数据库服务器单独作为一个服务DbServer，其他服务不能直接访问数据库，只能通过DbServer间接访问，这样不会造成短时间内对数据库访问的骤增，安全性提高了。现在遇到的问题是，游戏逻辑复杂，导致了大量的数据库相关的操作，对于每一个访问，都必须有一对 DB_**_REQ,和DB_**_RES，如果不需要数据库的返回值，比如delete操作，或者update操作，工作量还小一些，但对于 select操作，需要异步处理DB_**_RES，这样一次数据库访问，游戏逻辑需要处理2个消息，而且目前只能是异步处理，对于同步访问的方式不支持，调试代码比较费事。另一个问题，对于比较复杂的消息结构也不方便处理，比如多个变长字段，需要在逻辑服务器和数据库服务器都处理，指针操作很多，对于逻辑服务器由于面向client，无法避免，但数据库服务器应该采用更简洁，更直观的方案，以最大程度的维持稳定性。现在公司准备调研ICE了，我力荐，也符合和C#交互的需求，初步试用了ICE中的AMI，很强大，对于slice的接口，既支持同步调用，也支持异步调用，另一个推荐的原因是，ICE天生是一个分布式系统的框架，由于其自身的稳定性，方便后期在数据库前端添加缓冲系统。

ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中间件，是一种现代的面向对象中间件，类似于CORBA或COM/DCOM/COM+这样的中间件。基于 ICE可以实现电信级的解决方案。在系统架构的时候可以使用ICE实现应用的基础对象操作，从而实现比较好的架构。基于ICE的架构可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。

1.ICE是RPC服务的一个实现和框架，它通过本地代理实现网络操作。
• Ice 核心为远地通信提供了客户端和服务器端运行时支持。
• Ice 核心的通用部分（也就是说，与你用Slice 定义的特定类型无关的部分）可通过Ice API 访问。你用Ice API 来照管各种管理事务，比如Icerun time 的初始化和结束。
• 它为客户提供了一个向下调用（down-call）接口。如果你调用“生成的代理API”中的某个函数，就会有一个RPC 消息被发给服务器.
• 骨架（skeleton）代码也是根据你的Slice 定义生成的.骨架代码是客户端代理代码的服务器端等价物:它提供了向上调用（up-call）接口.
• 对象适配器（object adapter）是专用于服务器端的Ice API 的一部分,对象适配器会跟踪在内存中,都有哪些servant，其对象标识又是什么。

• 通信器(communicator)、对象适配器(object adapter)、和服务(servant)是ICE中的3个主要对象
Ice 核心为分布式应用开发提供了一个完善的客户－服务器平台，同时通过ICE提供的各种服务具备了随需启动服务器，配置应用。分发应用补丁等功能。
2.ICE服务
ICE主要提供了五种服务 IcePack ,IceBox, IceStorm, IcePatch , Glacier.

ICE服务为我们应用设计提供了很好的框架基础设施.
2.1 IceBox
IceBox 是一种简单的应用服务器，可用于协调许多应用组件的启动和停止。应用组件可以作为动态库、而不是进程进行部署。
2.2 IcePack(用于服务的部署)
IcePack 由两个主要组件组成：
IcePack registry，用于管理部署在特定域(domain) 中的应用的所有相关信息。
IcePack node，用于激活和监控服务器进程。
通过配置运行iceregistry(config)来管理各个服务节点的信息。
各个服务器通过配置运行icepacknode(config) 向icepackregistry注册使自己
作为其中的一个node运行。
再通过icepackadmin (add"application add ´application.xml´")将服务加载在任意的服务器上。同时也可以动态的管理各个server或servant.
执行客户端程序,客户端可通过服务器中的对象id准确的与相应的服务通讯,且会随需随需启动服务.
2．3 IcePatch
IcePatch 是一种软件修补服务。
2.4 Glacier
Glacier 是Ice 防火墙服务：它能让客户与服务器通过防火墙安全地进行通信，且又不牺牲安全性。客户－服务器之间的通信数据使用公钥证书进行了完全的加密，并且是双向的。Glacier 支持相互认证，以及安全的会话管理。
2.5 IceStorm
IceStorm 是一种发布－订阅服务，能够解除客户与服务器的耦合.在本质上， IceStorm 充当的是事件分发交换机。发布者把事件发给这个服务，由它发给订阅者。这样，发布者发布的单个事件就可以发送给多个订阅者。事件按照主题进行分类,订阅者会指定它们感兴趣的主题。只有那些与订阅者感兴趣的主题相吻合的主题才会发给这个订阅者.这个服务允许你指定服务质量标准，让应用在可靠性和性能之间进行适当的折衷。