C++博客-MemoryGarden's Blog-随笔分类-ICE

Ice -- Hello World 之客户端

memorygarden — Thu, 17 Dec 2009 10:20:00 GMT

客户代码看起来与服务器非常像。下面是完整的代码:

1 #include <Ice/Ice.h>
2 #include <Printer.h>
3 using namespace std;
4 int
5 main(int argc, char * argv[])
6 {
7     int status = 0;
8   Ice::CommunicatorPtr ic;
9   try {
10       ic = Ice::initialize(argc, argv);
11       Ice::ObjectPrx base = ic->stringToProxy(
12                               "SimplePrinter:default -p 10000");
13       PrinterPrx printer = PrinterPrx::checkedCast(base);
14       if (!printer)
15           throw "Invalid proxy";
16       printer->printString("Hello World!");
17   } catch (const Ice::Exception & ex) {
18       cerr << ex << endl;
19       status = 1;
20   } catch (const char * msg) {
21       cerr << msg << endl;
22       status = 1;
23   }
24   if (ic)
25       ic->destroy();
26   return status;
27 }
28

   注意,总体的代码布局与服务器是一样的:我们包括 Ice run time 的头
和 Slice 编译器生成的头,我们用同样的 try 块和 catch 处理器处理错
误。
   try 块中的代码所做的事情是:
1. 和在服务器中一样,我们调用 Ice::initialize 初始化 Ice run
   time。

2. 下一步是获取远地打印机的代理。我们调用通信器的 stringToProxy
   创建一个代理,所用参数是 "SimplePrinter:default -
   p 10000"。注意,这个串包含的是对象标识和服务器所用的端口号
(显然,在应用中硬编码对象标识和端口号,是一种糟糕的做法,但它
   目前很有效)。

3. stringToProxy 返回的代理的类型是 Ice::ObjectPrx,这种类型
   位于接口和类的继承树的根部。但要实际与我们的打印机交谈,我们需
   要的是 Printer 接口、而不是 Object 接口的代理。为此,我们需要调
   用 PrinterPrx::checkedCast 进行向下转换。这个方法会发送一
   条消息给服务器,实际询问 “这是 Printer 接口的代理吗?”如果是,
   这个调用就会返回 Printer 的一个代理;如果代理代表的是其他类型的
   接口,这个调用就会返回一个空代理。

4. 我们测试向下转换是否成功,如果不成功,就抛出出错消息,终止客
   户。

5. 现在,我们在我们的地址空间里有了一个活的代理,可以调用
    printString 方法,把享誉已久的 "Hello World!" 串传给它。服务
    器会在它的终端上打印这个串。

    客户的编译和链接看起来与服务器很像:
$ c++ -I. -I$ICE_HOME/include -c Printer.cpp Client.cpp
$ c++ -o client Printer.o Client.o -L$ICE_HOME/lib -lIce -lIceUtil

memorygarden 2009-12-17 18:20 发表评论

Ice -- Hello World 之服务端

memorygarden — Thu, 17 Dec 2009 08:29:00 GMT

首先声明我很挫，刚学的。有很多不会，不明白的地方，虽然是照搬书上的东西，但是自己也写了一些理解，如果您看到错误的话，请您一定要帮我指正。

首先贴个服务端的代码，就是书上的。

1 #include <Ice/Ice.h>
2 #include <Printer.h>
3 using namespace std;
4 class PrinterI : public Printer {
5 public:
6      virtual void printString(const string & s,
7                               const Ice::Current &);
8 };
9 void
10 PrinterI::
11 printString(const string & s, const Ice::Current &)
12 {
13      cout << s << endl;
14 }
15 int
16 main(int argc, char* argv[])
17 {
18      int status = 0;
19      Ice::CommunicatorPtr ic;
20      try {
21          ic = Ice::initialize(argc, argv);
22          Ice::ObjectAdapterPtr adapter
23              = ic->createObjectAdapterWithEndpoints(
24                  "SimplePrinterAdapter", "default -p 10000");
25          Ice::ObjectPtr object = new PrinterI;
26          adapter->add(object,
27                       Ice::stringToIdentity("SimplePrinter"));
28          adapter->activate();
29          ic->waitForShutdown();
30      } catch (const Ice::Exception & e) {
31          cerr << e << endl;
32          status = 1;
33      } catch (const char * msg) {
34          cerr << msg << endl;
35          status = 1;
36      }
37      if (ic)
38          ic->destroy();
39      return status;
40 }
41

对于一个只打印一个串的服务器而言,这里的代码似乎有很多。不要担
心这一点:大多数代码都是不会变化的公式化代码。对于这个非常简单的
服务器而言,其代码几乎就由这些公式化代码组成。
每个 Slice 源文件的一开始都有一条用于包括 Ice.h 的指令,在
Ice.h 中包含了 Ice run time 的各种定义。我们还包括了由 Slice 编译器生成
的 Printer.h,其中含有我们的打印机接口的 C++ 定义;为了使以后的
代码保持简洁,我们还导入了 std 名字空间的内容:

1 #include <Ice/Ice.h>
2 #include <Printer.h>
3 using namespace std;
4

我们的服务器实现了一个打印机 servant,其类型是 PrinterI。我们查
看 Printer.h 中的生成的代码,发现了以下内容 (为去掉无关细节,进
行了整理) :

1 class Printer : virtual public Ice::Object {
2 public:
3     virtual void printString(const std::string &,
4                              const Ice::Current & = Ice::Current()
5                             ) = 0;
6 };
7

这个类是ice对Printer.ice编译后生成的骨架类的部分。

骨架类：

在服务器端，接口映射到骨架类。对于相应的接口上的每个操作，骨架类都有一个对应的纯虚方法
• 和客户端一样，Slice 模块映射到名字相同的C++ 名字空间，所以骨架类定义会放在名字空间Demo 中。
• 骨架类的名字与Slice 接口的名字（Printer）相同。
• 对于Slice 接口中的每个操作，骨架类都有一个对应的纯虚成员函数。
• 骨架类是抽象基类，因为它的成员函数是纯虚函数。
• 骨架类继承自Ice::Object （这个类形成了Ice 对象层次的根）。

再回到servant上来。
servant ：

1 class PrinterI : public Printer {
2 public:
3 virtual void printString(const string & s,
4 const Ice::Current &);
5 };
6

printString 方法的实现很简单:它会简单地把它的串参数写到stdout:

1 void
2 PrinterI::
3 printString(const string & s, const Ice::Current &)
4 {
5 cout << s << endl;
6 }
7

servant 是Ice 对象的物理体现，也就是说，它们是
用具体的编程语言实现的实体，并且在服务器的地址空间中进行实例化。
Servants 为“客户发送的操作调用”提供服务器端行为。
同一个servant 可以向一个或更多对象适配器注册。

按照惯例， servant 类的名字是它们接口的名字加上后缀I，所以Printer
接口的servant 类叫作PrinterI （这只是一个惯例：从Ice run time 的角度来
说，你可以为你的servant 类选用任何你喜欢的名字）。

注意， PrinterI 继承自Demo::PrinerI，也就是说，它派生自它
的骨架类。在定义servant 类时总是使用虚继承是个好主意。严格地说，只
有其实现的接口使用了多继承的servant 才必须使用虚继承；但virtual
关键字并无害处，同时，如果你在开发的中途给接口层次增加多继承，你
无需回去给你的所有servant 类增加virtual 关键字。
从Ice 的角度来说， PrinterI 类只须实现一个成员函数：继承自骨架的
name 纯虚函数。这使得servant 类成了一个能实例化的具体类。你可以按照
你的实现的需要，增加其他成员函数和数据成员。

接下来是服务器的主程序。注意这段代码的总体结构:

1 int
2 main(int argc, char* argv[])
3 {
4     int status = 0;
5     Ice::CommunicatorPtr ic;
6     try {
7         // Server implementation here
8     } catch (const Ice::Exception & e) {
9         cerr << e << endl;
10         status = 1;
11     } catch (const char * msg) {
12         cerr << msg << endl;
13         status = 1;
14     }
15     if (ic)
16         ic->destroy();
17     return status;
18 }
19

我们的 try 块的主体含有实际的服务器代码:

1 ic = Ice::initialize(argc, argv);
2 Ice::ObjectAdapterPtr adapter
3     = ic->createObjectAdapterWithEndpoints(
4         "SimplePrinterAdapter", "default -p 10000");
5 Ice::ObjectPtr object = new PrinterI;
6 adapter->add(object,
7              Ice::stringToIdentity("SimplePrinter"));
8 adapter->activate();
9 ic->waitForShutdown();
10

这段代码包含以下步骤:
1. 我们调用 Ice::initialize,初始化 Ice run time (我们之所以把
   argc和argv传给这个调用,是因为服务器可能有run time感兴趣的命令
   行参数;就这个例子而言,服务器不需要任何命令行参数)               。
   initialize 调用返回的是一个智能指针,指向一个 Ice::Communicator 对象,这个指针是 Ice run time 的主句柄。
2. 我们调用 Communicator 实例上的
   createObjectAdapterWithEndpoints,创建一个对象适配器。我
   们传入的参数是 "SimplePrinterAdapter" (适配器的名字)和
   "default -p 10000",后者是要适配器用缺省协议 (TCP/IP)在端
   口 10000 处侦听到来的请求。
3. 这时,服务器端 run time 已经初始化,我们实例化一个 PrinterI 对
   象,为我们的 Printer 接口创建一个 servant。
4. 我们调用适配器的 add,告诉它有了一个新的 servant ;传给 add 的参
   数是我们刚才实例化的 servant,再加上一个标识符。在这里,
   "SimplePrinter" 串是 servant 的名字(如果我们有多个打印机,每个
   打印机都可以有不同的名字,更正确的说法是,都有不同的对象标
   识) 。

5. 接下来,我们调用适配器的 activate 方法激活适配器 (适配器一开
   始是在扣留 (holding)状态创建的;这种做法在下面这样的情况下很
   有用:我们有多个 servant,它们共享同一个适配器,而在所有 servant
   实例化之前我们不想处理请求)     。一旦适配器被激活,服务器就会开始
   处理来自客户的请求。
6. 最后,我们调用 waitForShutdown。这个方法挂起发出调用的线程,
   直到服务器实现终止为止——或者是通过发出一个调用关闭 run time,或者是对某个信号作出响应

假定我们的服务器代码放在一个叫作 Server.cpp 的文件中,我们可以这样编译它:

$ c++ -I. -I$ICE_HOME/include -c Printer.cpp Server.cpp

   最后,我们需要把服务器链接成可执行程序:
$ c++ -o server Printer.o Server.o -L$ICE_HOME/lib -lIce -lIceUtil

ps ：因为这个命令被袁飞狠狠的BS了一下。。。原来可以合在一起些。。。 55555 我好菜阿

memorygarden 2009-12-17 16:29 发表评论

Ice run time -- 对象标识

memorygarden — Thu, 17 Dec 2009 08:21:00 GMT

每个Ice 对象都有一个对象标识，其定义如下所示：

1
2 module Ice {
3     struct Identity {
4         string name;
5         string category;
6     };
7 };

你可以看到，对象标识由一对串组成：name 和category。name 或category
都可以是空串（如果某个代理包含的标识的name 和category 都是空
的， Ice 就把这个代理解释成null 代理）。完整的对象标识由name 和
category 组合而成，也就是说，两个标识要相等，它们的name 和category
都必须相同。category 成员通常是空串，除非你在使用servant 定位器

这个对象标识应该就是ASM 里面的键当然，值就是代理了（也就是指针，也就是在内存中的位置）。。。（不敢多说了。。。砖头阿。。。）

1 namespace Ice {
2 std::string identityToString(const Ice::Identity id);
3 Ice::Identity stringToIdentity(const std::string& s);
4 };

这里的 stringToIdentity(const std::string& s) 这个方法很雷的只传入了一个参数，这样的话是不是category 成员就直接“”了。。。实在是太不受重视了。。。不过我看的只是少部分。。乎略我。。。

memorygarden 2009-12-17 16:21 发表评论

Ice run time -- 对象适配器

memorygarden — Thu, 17 Dec 2009 08:13:00 GMT

好多不懂的。。。mlgbd

对象适配器

一个通信器含有一个或更多对象适配器。对象适配器处在Ice run time
和服务器之间的界线上，负有这样一些责任：一个通信器含有一个或更多对象适配器。对象适配器处在Ice run time
和服务器之间的界线上，负有这样一些责任：
• 它把Ice对象映射到到来请求的servant，并把请求分派给每个servant中的
应用代码（也就是说，对象适配器实现了一个向上调用接口，把Ice
run time 与服务器中的应用代码连接在一起）。
• 它协助进行生命周期操作，使得Ice对象和servant在创建和销毁时不会出
现竞争状况。
• 它提供一个或更多传输端点。客户通过这些端点访问适配器所提供的Ice
对象（创建没有端点的对象适配器也是可能的。这样的适配器被用于
双向回调——参见第24 章）。
每个对象适配器都有一个或更多servant，对Ice 对象进行体现；同时还
有一个或更多传输端点。如果对象适配器拥有的传输端点不止一个，所有
向该适配器作了注册的servant 可以在任何一个端点上响应到来的请求。换
句话说，如果对象适配器有多个传输端点，这些端点代表的是通往同一组
对象的不同通信路径（例如，通过不同的传输机制）。
每个对象适配器都只属于一个通信器（但一个通信器可以有多个对象
适配器）。
每个对象适配器可以非强制性地拥有自己的线程池，你可以通过

.ThreadPool.Size 属性来使用这个特性（参见附录
C）。如果使用了这个特性，在分派针对该适配器的客户调用时，使用的是
适配器的线程池中的线程，而不会使用通信器的服务器线程池中的线程。

活动Servant 映射表：

每个对象适配器都维护有一个叫作活动servant 映射表（active servant
map）的数据结构。活动servant 映射表（简称为ASM）是一个查找表，用
于把对象标识映射到servant：在C++ 里，查找值是智能指针，指向对应的
servant 在内存中的位置；
当客户把操作调用发给服务器时，请求的目标是特定的传输端点。传输端
点隐含地标识了请求所针对的对象适配器（因为同一个端点只能绑定到一
个对象适配器）
客户藉以发送请求的代理含有对应的对象的标识，客户
端run time 会在线路上随调用一起发送这个对象标识。对象适配器继而使
用这个对象标识、在它的ASM 中查找正确的servant，把调用分派给它
经由代理、把请求关联到正确的servant 的过程叫作绑定。图16.1 的例
子所描述的是直接绑定：传输端点是嵌在代理中的
如果在适配器的ASM 中，客户请求所包含的对象标识没有对应的条
目，适配器就会把ObjectNotExistException 返回给客户

对象适配器接口：
对象适配器是本地接口

module Ice {
    local interface ObjectAdapter {
        string getName();
        Communicator getCommunicator();
        Object* add(Object servant, Identity id);
        Object* addWithUUID(Object servant);
        void remove(Identity id);
        void activate();
        void hold();
        void waitForHold();
        void deactivate();
        void waitForDeactivate();
        // ...
    };
};

• getName 操作返回适配器的名字，这个名字是在调用Communicator::createObjectAdapter 或Communicator::createObjectAdapter-WithEndpoints 时传入的。
• getCommunicator 操作返回先前用于创建该适配器的通信器。注意，在ObjectAdapter 接口中还有其他操作；我们将在本章余下的各个部分讨论这些操作。

对象适配器提供了一些操作，用于管理servant 激活和解除激活：

Servant 激活与解除激活

术语servant 激活指的是，向Ice run time 告知某个Ice 对象的servant 的
存在。如果你激活一个servant，在图16.1 所示的活动servant 映射表中就会
增加一个条目。看待servant 激活的另一种方式是，把它看成是在“Ice 对
象的标识”与“对应的用编程语言编写的、负责为该Ice 对象处理请求的
servant”之间创建链接。一旦Ice run time 知道了这个链接，它就可以把到
来的请求分派给正确的servant。如果没有这样的链接，也就是说，在ASM
中没有对应的条目，针对该标识的到来请求就会引发
ObjectNotExistException。一旦servant 被激活，我们就认为它体现了对应
的Ice 对象。
与之相反的操作叫作servant 解除激活。如果你解除某个servant 的激
活，就会从ASM 中移除针对特定标识的一个条目。自此以后，针对该标识
的到来请求就不会再分派给servant，并且会引发
ObjectNotExistException。

这些操作的行为是：
• add add 操作把一个具有指定标识的servant 增加到ASM中。一旦add 被调用，请求就会分派给这个servant。返回值是这个servant 所体现的Ice对象的代理。这个代理嵌有传给add 的标识。
注意，通过不同的标识多次激活同一个servant，这是可能的。在这
种情况下，同一个servant 将体现多个Ice 对象。我们将在16.7.2 节更详
细地探索这个特性的影响。

• addWithUUID addWithUUID 操作的行为和add 操作一样，但你不需要为servant 提供标识。addWithUUID 会生成一个UUID （参见[14]），作为对应的Ice 对
象的标识。你可以调用返回的代理的ice_getIdentity 操作，取得生成的标识。addWithUUID 可用于创建临时对象的标识，比如短期存在的对象

• remove remove 操作中断标识与其servant 之间的关联，从ASM 中移除对应的条目。一旦servant 解除了激活，新到来的针对已移除标识的请求会引
发ObjectNotExistException。当remove 被调用时，正在servant 中执行的请求可以正常完成。一旦servant 的最后一个请求完成，对象适配器就会丢弃它的智能指针这时，如果你不再持有指向这个servant 的引用或智能指针，它就可以被销毁实际效果就是，一旦解除了激活的servant 空闲下来，它就会被销毁。如果你解除对象适配器的激活，将会隐含地调用它的活动servants 的remove 操作

对象适配器具有以下处理状态（processing state）：

适配器状态
• 扣留状态（holding）
在这种状态下，适配器的任何到来的请求都会被“扣留”，也就是
说，不会被分派给servant。
在使用TCP/IP （及其他面向流的协议）当被调用时，如果适配器处
在扣留状态，服务器端run time 就会停止从对应的传输端点读取数据。
此外，它也不接受客户发送的连接请求。这意味着，如果客户向处在扣
留状态的适配器发送请求，客户最终会收到TimeoutException 或
ConnectTimeoutException （除非在定时器超时之前，适配器变成了活
动状态）。
在使用UDP 时，如果客户请求到达处在扣留状态的适配器，请求将
被丢弃。
刚创建的适配器都处在扣留状态。这意味着，在你让适配器变成活
动状态之前，请求不会被分派。

• 活动状态
在这种状态下，适配器会接受到来的请求，把它们分派给servant。
新创建的适配器一开始处在扣留状态。只要你让适配器变成活动状态，
它就会开始分派请求。
你可以随意在活动和扣留状态之间转换。

• 不活动
在这种状态下，适配器在概念上已经被销毁（或处在销毁过程
中）。解除适配器的激活会销毁与该适配器相关联的所有传输端点。当
适配器变成不活动状态时，仍在执行的请求可以完成，但适配器不会再
接受新的请求（发出新请求的客户会收到异常）。一旦适配器解除了激
活，你不能再在同一进程中重新激活它。
ObjectAdapter 接口提供了一些操作，允许你改变适配器状态，或者等
待状态改变完成：

• activate
activate 操作让适配器变成活动状态。激活已经处在活动状态的适
配器没有任何效果。一旦activate 被调用， Ice run time 就会开始把请
求分派给适配器的servants。

• hold
hold 操作让适配器变成扣留状态。在调用hold 之后到达的请求都会
像第373 页所说的那样被扣留。在hold 被调用时正在执行的请求可以
正常完成。注意， hold 会立即返回，不会等待正在执行的请求完成。

• waitForHold
waitForHold 操作挂起发出调用的线程，直到适配器迁移到扣留状态
为止，也就是说，直到正在执行的所有请求完成为止。你可以从多个线
程调用waitForHold，也可以在适配器处在活动状态时调用
waitForHold。如果适配器处在不活动状态，对它调用waitForHold 不会
做任何事情，并且会立即返回。

• deactivate 操作让适配器变成不活动状态。在调用deactivate 之后
到达的请求会被拒绝，但正在执行的请求可以完成。一旦适配器处在不
活动状态，它不能再被重新激活。如果适配器处在不活动状态，对它调
用activate、hold、waitForHold，或deactivate 没有任何效果。一
旦变得空闲，与该适配器相关联的任何servants 都会被销毁。注意，
deactivate 会立即返回，不会等待正在执行的请求完成。

• waitForDeactivate
waitForDeactivate 操作挂起发出调用的线程，直到适配器迁移到不
活动状态为止，也就是说，直到所有正在执行的线程完成、所有的传输
端点关闭、所有相关联的servants 销毁为止。你可以从多个线程调用
waitForDeactivate，也可以在适配器处在活动或扣留状态时调用
waitForDeactivate。如果适配器处在不活动状态，对它调用wait-
ForDeactivate 不会做任何事情，并且会立即返回。

memorygarden 2009-12-17 16:13 发表评论

Ice run time -- 通信器

memorygarden — Thu, 17 Dec 2009 07:39:00 GMT

只贴出一些自己懂的。以后懂多少贴多少

通信器的接口是用Slice 定义的。下面是其部分接口：

1 module Ice {
2     local interface Communicator {
3         string proxyToString(Object* obj);
4         Object* stringToProxy(string str);
5         ObjectAdapter createObjectAdapter(string name);
6         ObjectAdapter createObjectAdapterWithEndpoints(string name,string endpoints);
7         void shutdown();
8         void waitForShutdown();
9         void destroy();
10
11     };
12     //
13 };

通信器提供了一些操作：
• proxyToString
• stringToProxy
这两个操作允许你把代理转换成串化表示，或进行反向转换。
• createObjectAdapter
• createObjectAdapterWithEndpoints
这两个操作创建新的对象适配器。每个对象适配器都与一个或更多
传输端点关联在一起。一个对象适配器通常拥有一个传输端点。但是，
一个对象适配器也可以提供多个传输端点。如果是这样，这些端点可以
通往同一组对象，但代表访问这些对象的不同手段。这很有用，例如，
服务器在防火墙后面，但必须让内部和外部的客户都能访问它；把适配
器同时绑定到内部和外部接口，就可以其中任何一个接口访问在服务器
中实现的对象了。
createObjectAdapter 根据配置信息（参见第20 章）来确定把自己
绑定到哪个端点，而createObjectAdapterWithEndpoints 允许你为新
适配器指定传输端点。你通常会优先于createObjectAdapterWithEndpoints
使用createObjectAdapter。这样，就能把与传输机制相关的信
息（比如主机名和端口号）放在源码外面，通过改变属性，你可以对
应用进行重配置（于是，在传输端点需要改变时，不用重新进行编
译）。
• shutdown
这个操作关闭服务器端的Ice run time：
• 在shutdown 被调用时，仍处在执行过程中的操作调用可以正常完成。
shutdown 不会等待这些操作完成；在shutdown 返回时，你所知道的
是：不会再有新的请求被分派，但在你调用shutdown 时已经在执行
之中的操作可能仍在运行。你可以调用waitForShutdown，等待仍在
执行的操作完成。
• 在服务器调用shutdown 之后到达的操作调用或者会失败（抛出
ConnectFailedException），或者会被透明地重定向到服务器的某个
新实例（参见第20 章）。
• waitForShutdown
这个操作挂起发出调用的线程，直到通信器关闭为止（也就是说，
直到在服务器中不再有操作在执行为止）。这样，你可以在销毁通信器
之前，等待服务器空闲下来。
• destroy
这个操作销毁通信器及其相关资源，比如线程、通信端点，以及内
存资源。一旦你销毁了通信器（因此也就销毁了该通信器的run
time），你不能再调用其他任何Ice 操作（除了创建另外的通信器）。
在离开程序的main 函数之前要调用destroy，这是强制性的。不这
样做会导致不确定的行为。
在离开main 之前调用destroy 是必需的，因为destroy 会在返回
之前等待所有运行中的线程终止。如果你没有调用destroy 就离开
main，你就会留下许多仍在运行的线程；许多线程包不允许你这样做，
你最终会使程序崩溃。
如果你没有调用shutdown 就调用destroy，在这个调用返回之前，它会
等待所有执行中的操作调用完成（也就是说， destroy 的实现隐含地调用
shutdown，然后调用waitForShutdown）。shutdown （因此，也包括
destroy）会解除与通信器相关联的所有对象适配器的激活。
在客户端，如果你在操作执行过程中调用shutdown，这些操作会终止，
抛出CommunicatorDestroyedException。

memorygarden 2009-12-17 15:39 发表评论

Ice -- Hello World 之 Slice 定义

memorygarden — Thu, 17 Dec 2009 06:58:00 GMT

Slice1 （Specification Language for Ice）是一种用于使对象接口与其实现
相分离的基础性抽象机制。 Slice 在客户与服务器之间建立合约，描述应用
所使用的各种类型及对象接口。这种描述与实现语言无关，所以编写客户
所用的语言是否与编写服务器所用的语言相同，这没有什么关系。
Slice 定义由编译器编译到特定的实现语言。编译器把与语言无关的定
义翻译成针对特定语言的类型定义和API。开发者使用这些类型和API 来
提供应用功能，并与Ice 交互。用于各种实现语言的翻译算法称为语言映射
（language mappings）。Ice 目前定义了C++ 和Java 的语言映射。
因为Slice 描述的是接口和类型（不是实现），它是一种纯粹的描述性
语言；你无法用Slice 编写可执行语句。
Slice 定义关注的焦点是对象接口、这些接口所支持的操作，以及操作
可能引发的异常。此外， Slice 还提供了一些用于对象持久的特性（参见第
21 章）。这需要相当多的支持机制；特别地， Slice 的相当一部分关注的是
数据类型的定义。这是因为，只有在其类型用Slice 进行了定义之后，数据
才能在客户与服务器之间交换。你不能在客户与服务器之间交换任意的
C++ 数据，因为这可能会摧毁Ice 的语言无关性。但是，你总能创建一种
Slice 类型定义，与你想要发送的C++ 数据相对应，然后你就可以传送这种
Slice 类型了。
在此我们将介绍Slice 的完整语法和语义。因为Slice 的许多语法和语义
都是以C++ 和Java 为基础的，我们将特别关注Slice 与C++ 或Java 不同的
部分，或是Slice 以某种方式限制了等价的C++ 或Java 特性的部分。与
C++ 和Java 特性相同的Slice 特性通常会用例子来说明。

文件命名
含有Slice 定义的文件必须以.ice 扩展名结尾，例如， Clock.ice
就是一个有效的文件名。编译器拒绝接受其他扩展名。

预处理

Slice 支持#ifndef、#define、#endif，以及#include 预处理指令。它
们的使用方式有严格的限制：
• 你只能把#ifndef、#define，以及#endif 指令用于创建双包括
（double-include）块
• #include 指令只能出现在Slice 源文件的开头，也就是说，它们必须出现
在其他所有Slice 定义的前面。此外，在使用#include 指令时，只允许
使用<> 语法来指定文件名，不能使用""。

关键字：

以下标识符是Slice 关键字：
关键字的大小写必须按照给出的方式拼写。
bool enum   implements module string
byte exception   int   nonmutating   struct
class extends   interface Object throws
const   false local out true
dictionary float LocalObject sequence void
double   idempotent long short

结构：

Slice 支持含有一个或多个有名称的成员的结构，这些成员可以具有任
意类型，包括用户定义的复杂类型。例如：
struct TimeOfDay {
short hour; // 0 - 23
short minute; // 0 - 59
short second; // 0 - 59
};
与在 C++ 里一样，这个定义引入了一种叫作TimeOfDay 的新类型。结构
定义会形成名字空间，所以结构成员的名字只需在围绕它们的结构里是唯
一的。
在结构内部，只能出现数据成员定义，这些定义必须使用有名字的类
型。例如，你不可能在结构内定义结构：

这个规则大体上适用于Slice：类型定义不能嵌套（除了模块确实支持
嵌套——参见4.11 节）。其原因是，对于某些目标语言而言，嵌套的类型
定义可能会难以实现，而且，即使能够实现，也会极大地使作用域解析规
则复杂化。对于像Slice 这样的规范语言而言，嵌套的类型定义并无必要
——你总能以下面的方式编写上面的定义（这种方式在风格上也更加整
洁）：
struct Point {
short x;
short y;
};
struct TwoPoints { // Legal (and cleaner!)
Point coord1;
Point coord2;
};

代理：
代理就像是能代表对象的指针（个人认为）。代理的语义与C++ 类实例指针的语义非常像：

• 代理可以为null （参见第88 页）。
• 代理可以悬空（dangle）（指向的对象已经不存在）
• 代理充当的是远地对象的本地“大使”；如果你调
用代理上的某个操作，你的调用会转发给实际的对象实现。如果对象实现
是在另外的地址空间中，就会产生一个远地过程调用；如果对象实现是并
置在相同的地址空间中的， Ice 就会使用普通的本地函数调用，从代理那里
调用对象实现
代理不能访问数据成员。这是因为代理没有数据成员的概念，它们代表的是接口，通过代理只能访问它的操作。

Slice 有很多东西，就写了一些能看懂，或者个人感觉常用的。

我们针对Hello World 来编写它的Slice 它就是要客户端给告诉服务端执行一个在服务端输出一句话。

所以这个Printer.ice 文件的编写非常简单

1 module Demo{
2     interface Printer{
3         void printString(string s);
4     };
5 };
6

编译： slice2cpp Printer.ice

编译后生成Printer.h 和 Printer.cpp 两个文件。这两个文件要被客户端以及服务端用到内部封装了我们定义的Printer这个接口，对于c++来说，也就是一个有着类似virtual void printString(string s) = 0 这样的一个纯虚函数的一个骨架类，用来服务器端我们来继承并搞一个servant 。同样，对于客户端，有一个PrinterPrx它是一个类似c++指针的东西，反正很像的，我们可以通过它，和ice帮助我们封装好的一些通讯的方法，以及它的一些别的方法来编写我们的逻辑代码，就像编写在客户端一样，很方便。

memorygarden 2009-12-17 14:58 发表评论

Ice 在架构上提供的好处

memorygarden — Thu, 17 Dec 2009 05:38:00 GMT

Ice 在架构上为应用开发者提供了一些好处：
• 面向对象的语义
Ice “在线路上”完全保留了面向对象范型。所有的操作调用都使用
迟后绑定，所以操作的实现的选定，是根据对象在运行时的（而不是
静态的）实际类型决定的。
• 支持同步和异步的消息传递
Ice 提供了同步和异步的操作调用和分派，并且通过IceStorm 提供了
发布－订阅消息传递机制。这样，你可以根据你的应用的需要来选择通
信模型，而不必把你的应用硬塞进某种模型里。
• 支持多个接口
通过facets，对象可以提供多个不相关的接口，同时又跨越这些接
口、保持单一的对象标识。这提供了极大的灵活性，特别是在这样的情
况下：应用在发生演化，但又需要与更老的、已经部署的客户保持兼
容。
• 机器无关性
客户及服务器与底层的机器架构屏蔽开来。对于应用代码而言，像
字节序和填充这样的问题都隐藏了起来。
• 语言无关性
客户和服务器可以分别部署，所用语言也可以不同（目前支持
C++、Java，以及PHP （客户端））。客户和服务器所用的Slice 定义建
立两者之间的接口合约，这样的定义也是它们唯一需要达成一致的东
西。
• 实现无关性
客户不知道服务器是怎样实现其对象的。这意味着，在客户部署之
后，服务器的实现可以改变，例如，它可以使用不同的持久机制，甚至
不同的程序设计语言。
• 操作系统无关性
Ice API 完全是可移植的，所以同样的源码能够在Windows 和UNIX
上编译和运行。
• 线程支持
Ice run time 完全是线程化的，其API 是线程安全的。作为应用开发
者，（除了在访问共享数据时进行同步）你无需为开发线程化的高性能
客户和服务器付出额外努力。
• 传输机制无关性
Ice 目前采用了TCP/IP 和UDP 作为传输协议。客户和服务器代码都
不需要了解底层的传输机制（你可以通过一个配置参数选择所需的传
输机制）。
• 位置和服务器透明性
Ice run time 会负责定位对象，并管理底层的传输机制，比如打开和
关闭连接。客户与服务器之间的交互显得像是无连接的。如果在客户调
用操作时，服务器没有运行，你可以通过IcePack 让它们随需启动。服
务器可以迁移到不同的物理地址，而不会使客户持有的代理失效，而客
户完全不知道对象实现是怎样分布在多个服务器进程上的。
• 安全性
通过SSL 强加密，可以使客户和服务器完全安全地进行通信，这
样，应用可以使用不安全的网络安全地进行通信。你可以使用Glacier
穿过防火墙，实现安全的请求转发，并且完全支持回调。
• 内建的持久机制
使用Freeze，创建持久的对象实现变成了一件微不足道的事情。Ice
提供了对高性能数据库Berkeley DB[18] 的内建支持。
• 开放源码
Ice 的源码是开放的。尽管要使用Ice 平台，并不一定要阅读源码，
通过源码你可以了解各种事情是怎样实现的，或把这些代码移植到新的
操作系统上。
总而言之， Ice 提供了一流的分布式计算开发和部署环境，比我们所知
道的其他任何平台都更完整。

memorygarden 2009-12-17 13:38 发表评论

Ice Box

memorygarden — Thu, 17 Dec 2009 05:36:00 GMT

IceBox
IceBox 是一种简单的应用服务器，可用于协调许多应用组件的启动和停
止。应用组件可以作为动态库、而不是进程进行部署。例如，你可以在单
个Java 虚拟机中运行若干应用组件，而无需使用多个拥有自己的虚拟机的
进程，从而减轻整个系统的负担。

memorygarden 2009-12-17 13:36 发表评论

Ice 客户与服务器结构

memorygarden — Thu, 17 Dec 2009 04:06:00 GMT

客户与服务器都由这样一些代码混合而成：应用代码、库代码、根据
Slice 定义生成的代码：
• Ice 核心为远地通信提供了客户端和服务器端运行时支持。其中的大量代
码所涉及的是网络通信、线程、字节序，以及其他许多与网络有关的问
题，我们想要让应用代码与这些问题隔离开来。Ice 核心是作为客户和
服务器可与之链接的库提供的。
• Ice 核心的通用部分（也就是说，与你用Slice 定义的特定类型无关的部
分）可通过Ice API 访问。你用Ice API 来照管各种管理事务，比如Ice
run time 的初始化和结束。用于客户和服务器的Ice API 是一样的（尽
管服务器使用的API 比客户要多）。
• 代理代码是根据你的Slice 定义生成的，因此，与你用Slice 定义的对象和
数据的类型是对应的。代理代码有两个主要功能：
• 它为客户提供了一个向下调用（down-call）接口。如果你调用“生
成的代理API”中的某个函数，就会有一个RPC 消息被发给服务器，
调用目标对象上的某个对应的函数。
• 它提供了整编（marshaling）和解编（unmarshaling）代码。
整编是使复杂的数据结构（比如序列或词典）序列化、以在线路上进
行传送的过程。整编代码把数据转换成适于传送的标准形式，这种形
式不依赖于本地机器的"endian-ness" 和填充（padding）规则。
解编是整编的逆过程，也就是说，使通过网络到达的数据解除序列
化，并且对数据重新进行构造，用与所使用的编程语言相适应的类型
来加以表示。
• 骨架（skeleton）代码也是根据你的Slice 定义生成的，因此，与你用
Slice 定义的对象和数据的类型是对应的。骨架代码是客户端代理代码
的服务器端等价物：它提供了向上调用（up-call）接口，允许Ice run
time 把控制线程转交给你编写的应用代码。骨架也含有整编和解编代
码，所以服务器可以接收客户发送的参数，并把参数和异常返回给客
户。
• 对象适配器（object adapter）是专用于服务器端的Ice API 的一部分：只
有服务器才使用对象适配器。对象适配器有若干功能：
• 对象适配器把来自客户的请求映射到编程语言对象上的特定方法。换
句话说，对象适配器会跟踪在内存中，都有哪些servant，其对象标识
又是什么。
• 对象适配器与一个或多个传输端点关联在一起。如果与某个适配器关
联的传输端点不止一个，你可以通过多种传输机制到达在该适配器中
的servant。例如，为了提供不同的服务质量和性能，你可以把一个
TCP/IP 端点和一个UDP 端点与一个适配器关联在一起。
• 对象适配器要负责创建可以传给客户的代理。对象适配器知道它的每
个对象的类型、标识，以及传输机制的详细情况，并且会在服务器端
应用代码要求创建代理时在其中嵌入正确的信息。
注意，从进程的层面来看，所涉及的进程只有两个：客户与服务器。对
分布式通信的所有运行时支持都是由Ice 库以及根据Slice 定义生成的代码
提供的（在使用间接代理时，需要使用第三个进程IcePack 来把代理解析
为传输端点）。

memorygarden 2009-12-17 12:06 发表评论

Ice 代理

memorygarden — Thu, 17 Dec 2009 04:03:00 GMT

代理（Proxies）
要想与某个Ice 对象联系，客户必须持有这个对象的代理1。代理是客户
的地址空间中的一种制品（artifact）；对客户而言，代理就是Ice 对象的
代表（该对象可能在远地）。一个代理充当的是一个Ice 对象的本地大使：
当客户调用代理上的操作时， Ice run time 会：
1. 定位Ice 对象
2. 如果Ice 对象的服务器没有运行，就激活它
3. 在服务器中激活Ice 对象
4. 把所有in 参数传送给Ice 对象
5. 等待操作完成
6. 把所有out 参数及返回值返回给客户（或在发生错误的情况下抛出异
常）
代理封装了完成这一系列步骤所必需的全部信息。特别地，代理包含
有：
• 寻址信息：用于让客户端run time 联系正确的服务器
• 对象标识：用于确定服务器中的哪一个对象是请求的目标
• 可选的facet 标识符：用于确定代理所引用的是对象的哪一个facet

串化代理（Stringified Proxies）
代理中的信息可以用串的形式表示。例如：
SimplePrinter:default -p 10000
这个字符串表示的是一个代理，我们可以阅读这种表示方式。Ice run
time 提供了一些API 调用，允许你把代理转换成它的串化形式，或是进行
相反的转换。例如，如果你要把代理存储在数据库表或文本文件中，这种
功能会很有用。
倘若客户知道某个Ice 对象的标识及其寻址信息，使用这些信息，它可
以“凭空”创建代理。换句话说，代理内部的所有信息都被认为是透明的
；要与某个对象联系，客户只需要知道这个对象的标识、寻址信息，以及
对象的类型（为了能调用操作），就可以了。

在客户端，接口映射到这样的类：它的成员函数与接口上的操作相对
应。考虑下面的简单接口：

1 interface Simple {
2 void op();
3 };

Slice 编译器生成下面的定义，供客户使用：

1 namespace IceProxy {
2     namespace M {
3         class Simple;
4     }
5 }
6 namespace M {
7     class Simple;
8     typedef IceInternal::ProxyHandle< ::IceProxy::M::Simple> SimplePrx;
9     typedef IceInternal::Handle< ::M::Simple> SimplePtr;
10 }
11 namespace IceProxy {
12     namespace M {
13         class Simple : public virtual IceProxy::Ice::Object {
14             public:
15                 typedef ::M::SimplePrx ProxyType;
16                 typedef ::M::SimplePtr PointerType;
17                 void op();
18                 void op(const Ice::Context&);
19                 //
20         };
21     };
22 }

(其实我生成的和这个不一样的。。。因为我不适很懂这个东西，所以根本不敢乱贴)

在客户的地址空间中， IceProxy::M::Simple 实例是“远地的服务器
中的Simple 接口的实例”的“本地大使”，叫作代理类实例。与服务器端
对象有关的所有细节，比如其地址、所用协议、对象标识，都封装在该实
例中

注意， Simple 继承自IceProxy::Ice::Object。这反映了这样一
个事实：所有的Ice 接口都隐含地继承自Ice::Object。对于接口中的每个
操作，代理类都有两个重载的、同名的成员函数。就前面的例子而言，我
们会发现操作op 映射到了两个成员函数op。
其中一个函数的最后一个参数的类型是Ice::Context。Ice run time
用这个参数存储关于请求的递送方式的信息；你通常并不需要为此提供一
个值，可以假装这个参数不存在

客户端应用永远不会直接操纵代理类。事实上，你不允许直接实例化代
理类。下面的代码无法编译，因为IceProxy::Simple 含有纯虚的成员
函数：
IceProxy::Simple s; // Compile-time error!
代理实例总是由Ice run time 替客户实例化，所以客户代码永远都不需
要直接实例化代理。当客户从run time 那里接收代理时，它会得到指向该
代理的代理句柄，其类型是Prx （对于前面的例子
就是SimplePrx）。客户通过代理的句柄来访问代理；句柄负责把操作调
用转发给其底层的代理，并且会对代理进行引用计数。这意味着，你不会
遇到内存管理问题：代理的释放是自动的，会在指向代理的最后一个句柄
消失时（退出作用域时）发生。
因为应用代码总是使用代理句柄，而决不会直接使用代理类，我们通常
既会用代理这个术语来表示代理句柄，也会用它来标识代理类。这反映了
这样一个事实：在实际的使用中，代理的“观感”就像是底层的代理类实
例。如果区分它们很重要，我们会使用术语代理类、代理类实例，以及代
理句柄。

代理句柄上的方法 :

我们在前面的例子中已经看到，句柄实际上是类型为
IceInternal::ProxyHandle 的模板，其参数是代理类。这个模板有缺
省构造器、复制构造器，以及赋值构造器：

• 缺省构造器
你可以通过缺省方式构造代理句柄。缺省的构造器创建的是哪里也
不指向的代理（也就是说，根本不指向对象）。如果你调用这样的null
代理上的操作，你会收到

• 复制构造器
复制构造器负责确保你能根据另一个代理句柄构造出一个代理句
柄。在内部，这会使代理的引用计数加一；析构器会使引用计数减一，一旦计数降到零，就释放底层的代理类实例。这样就不会发生内存泄漏
了

赋值操作符
你可以随意把一个代理句柄赋给另一个句柄。句柄的实现会保证进
行适当的内存管理。自赋值（self-assignment）是安全的，你无需针对
这种情况进行保护：

宽化赋值（Widening assignments）会隐式地进行。例如，如果我们
有两个接口Base 和Derived，我们可以隐式地把一个DerivedPrx 变
宽成一个BasePrx：

• 检查转换（checked cast）
代理句柄提供了一个checkedCast 方法：

1 namespace IceInternal {
2     template<typename T>
3     class ProxyHandle : public IceUtil::HandleBase<T> {
4         public:
5         template<class Y>
6         static ProxyHandle checkedCast(const ProxyHandle<Y> & r);
7         //
8     };
9 }

对于代理来说，检查转换的作用就像是C++ dynamic_cast 相对于
指针的作用：它能够让你把基代理赋给派生代理。如果基代理的运行时
类型与派生代理的静态类型相容，赋值就能成功，而在赋值之后，基代
理代表的对象与派生代理相同。而如果基代理的运行时类型与派生代理
的静态类型不相容，派生代理就会被设成null。下面用一个例子来加以
说明：

1 BasePrx base = ; // Initialize base proxy
2 DerivedPrx derived;
3 derived = DerivedPrx::checkedCast(base);
4 if (derived) {
5     // Base has run-time type Derived,
6     // use derived
7 } else {
8     // Base has some other, unrelated type
9 }
10

表达式DerivedPrx::checkedCast(base) 测试base 指向的
是否是 Derived 类型的对象。如果是，则转换成功， derived 指向的
对象会被设成与base 指向的相同。否则，转换就会失败，而
derived 被设成null 代理。
注意， checkedCast 是一个静态方法，所以，要进行向下转换，
你总是使用这样的语法：Prx::checkedCast。
还要注意，你可以在布尔上下文中使用代理。例如，如果代理不为
null， if (proxy) 会返回真

在你调用checkedCast 时，通常会有一条远地消息发往服务器2。
这条消息会实际询问服务器：“这个引用所代表的对象的类型是不是
Derived?”服务器的答复会以成功（非null）或失败（null）的形式传
达给应用代码。发送远地消息是必要的，因为作为一条原则，如果没有
服务器的确认，客户无法找出代理实际的运行时类型（例如，服务器
可能会用一个派生层次更深的对象实现取代现有的某个代理的对象实
现）。这意味着，你必须准备好处理checkedCast 失败的情况。例
如，如果服务器没有运行，你就会收到ConnectFailedException
；如果服务器在运行，但代理所代表的对象已经不存在，你就会收到
ObjectNotExistException。

• 不检查转换（Unchecked cast）
在有些情况下，你知道某个对象支持一个接口，其派生层次比其代
理的静态类型的派生层次更深。对于这样的情况，你可以使用不进行检
查的向下转换：

1 namespace IceInternal {
2     template<typename T>
3     class ProxyHandle : public IceUtil::HandleBase<T> {
4         public:
5         template<class Y>
6         static ProxyHandle uncheckedCast(const ProxyHandle<Y> & r);
7         //
8     };
9 }

只有在你确知代理真的支持派生层次更深的类型时，你才应该使用
uncheckedCast：顾名思义， uncheckedCast 不会进行任何检查；
它不会联系服务器中的对象，如果失败，它不会返回null （不检查转换
在内部的实现就像是C++ static_cast，不会进行任何一种检查）。
如果你使用的代理是通过不正确的uncheckedCast 得到的，其行为
将是不确定的。你很可能会收到ObjectNotExistException 或
OperationNotExistException，但取决于具体情形， Ice run time
也可能报告一个异常，说解编失败，甚至还可能会不声不响地返回垃圾
结果。
尽管有危险， uncheckedCast 仍然是有用的，因为它不用付出向
服务器发消息的代价。而且，在初始化过程中（参见第7 章），应用常
常会收到静态类型是Ice::Object 的代理，但你知道它的具体的运行
时类型。在这样的情况下， uncheckedCast 可以节省发送远地消息
的开销。

对象标识与代理比较 :

代理句柄还支持比较操作 == !=

这两个操作符允许你比较代理是否相等和不等。为了测试代理是否
为null，你可以与直接量0 进行比较，例如：

1 if (proxy == 0)
2 // It's a nil proxy
3 else
4 // It's a non-nil proxy
5

• <
代理支持operator<。这使得你能把代理放入STL 容器，比如映
射表或有序列表。
• 布尔比较
代理有一个转换操作符，可以把自己转换成bool。如果代理不是
null，这个操作符返回真，否则就返回假。所以你可以编写这样的代
码：
BasePrx base = ...;
if (base)
// It's a non-nil proxy
else
// It's a nil proxy
注意，在通过重载的操作符==、!=，以及< 进行代理比较时，会使用
代理中的所有信息。这意味着，对象标识不仅要匹配，代理中的其他资料
也必须相同，比如协议和端点信息。换句话说，如果你用== 和!= 进行比
较，测试的是代理的同一性，而不是对象的同一性

1 Ice::ObjectPrx p1 = ; // Get a proxy
2 Ice::ObjectPrx p2 = ; // Get another proxy
3 if (p1 != p2) {
4 // p1 and p2 denote different objects // WRONG!
5 } else {
6 // p1 and p2 denote the same object // Correct
7 }

尽管p1 和p2 是不同的，它们代表的可能是同一个Ice 对象。例如，如
果p1 和p2 包含了相同的对象标识，但各自使用了不同的协议联系目标对
象，就可能会发生上述情况。与此类似，协议可能是一样的，但使用的端
点不同（因为单个Ice 对象可以通过若干不同的传输端点联系）。换句话
说，如果两个代理用== 比较是相等的，我们就知道这两个代理代表的是同
一个对象（因为它们在所有方面都相同）；但如果两个用== 比较不相等，
我们什么也不知道：这两个代理所代表的可能是、也可能不是同一个对
象。
要比较两个代理的对象同一性，你必须使用Ice 名字空间里的一个辅
助函数：

namespace Ice {
bool proxyIdentityLess(const ObjectPrx &,
const ObjectPrx &);
bool proxyIdentityEqual(const ObjectPrx &,
const ObjectPrx &);
}

只要嵌在两个代理中的对象标识是一样的， proxyIdentityEqual
函数就会返回真，代理中的其他信息会被忽略，比如facet 和传输机制信
息。proxyIdentityLess 函数建立了代理的总序（total ordering）。其
目的主要是为了让你把对象标识比较用于STL 的有序容器。
proxyIdentityEqual 能让你正确地比较代理的对象标识：

1 Ice::ObjectPrx p1 = ; // Get a proxy
2 Ice::ObjectPrx p2 = ; // Get another proxy
3 if (!Ice::proxyIdentityEqual(p1, p2) {
4 // p1 and p2 denote different objects // Correct
5 } else {
6 // p1 and p2 denote the same object // Correct
7 }

memorygarden 2009-12-17 12:03 发表评论

Ice Servants

memorygarden — Thu, 17 Dec 2009 04:03:00 GMT

Servants
Ice 对象是一种具有类型、标识，以及寻址信息
的概念性实体。但客户请求最终必须到达具体的服务器端的处理实体，由
这样的实体提供操作调用（operation invocation）的行为。换句话说，客户
请求最后必须到达服务器，在其内部执行代码，而这些代码用特定的编程
语言编写，并在特定的处理器上执行。
在服务器端提供操作调用的行为的制品叫作servant。一个servant 提供
一个或多个Ice 对象的实质内容（或体现这些对象， incarnate）。实际上，
servant 就是服务器开发者编写的类的实例，这些类作为一个或多个Ice 对
象的servant、向服务器端run time 进行注册。类的方法对应于Ice 对象的接
口上的操作，并且提供这些操作的行为。
一个servant 可以只体现一个Ice 对象，也可以同时体现若干Ice 对象。
如果是前一种情况， servant 所体现的Ice 对象的标识在这个servant 中是隐
含的。如果是后一种情况，在每次收到请求时， servant 也会收到Ice 对象
的标识，这样， servant 可以决定在处理该请求期间，体现哪一个对象。
反过来，一个Ice 对象也可以拥有多个servant。例如，我们可以为某个
Ice 对象创建一个代理，这个对象有两个不同的地址，分别在两台机器上。
在这种情况下，我们将拥有两个服务器，每个服务器都有一个servant，但
两个servant 体现的是同一个Ice 对象。当客户调用这样的Ice 对象上的操
作时，客户端run time 只把请求发给一个服务器。换句话说，使用体现同
一个Ice 对象的多个servant，你可以构建冗余的系统：客户端run time 试着
把请求发给一个服务器，如果失败，就把请求发给第二个服务器。只有在
第二次尝试也失败的情况下，错误才会报告给客户端应用代码。

memorygarden 2009-12-17 12:03 发表评论

Ice对象（Ice Object）

memorygarden — Thu, 17 Dec 2009 02:51:00 GMT

Ice 对象（Ice Objects）
    Ice 对象是一种概念性的实体（或称抽象）。Ice 对象具有以下特征：
        • Ice 对象是本地或远地的地址空间中、能响应客户请求的实体。
        • 一个Ice 对象可在单个或多个服务器中实例化（后者是冗余方式）。如果某个对象同时有多个实例，它仍是一个Ice 对象。
        • 每个Ice对象都有一个或多个接口。一个接口是一个对象所支持的一系列有名称的操作。客户通过调用操作来发出请求。
        • 一个操作有零个或更多参数，以及一个返回值。参数和返回值具有明确的类型。参数是有名称的，并且有方向：in 参数由客户初始化，并传给服务器； out 参数由服务器初始化，并传给客户（返回值只是一种特殊的out 参数）。
        • 一个Ice 对象具有一个特殊的接口，称为它的主接口。此外， Ice 对象还可以提供零个或更多其他接口，称为facets （面）。客户可以在某个对象的各个facets之间进行挑选，选出它们想要使用的接口。
         • 每个Ice 对象都有一个唯一的对象标识（object identity）。对象标识是用于把一个对象与其他所有对象区别开来的标识值。Ice 对象模型假定对象标识是全局唯一的，也就是说，在一个Ice 通信域中，不会有两个对象具有相同的对象标识。

Ice ObjectProxy 并不是继承自 IceObject 前者是代理的继承层次的根

memorygarden 2009-12-17 10:51 发表评论

C++博客-MemoryGarden's Blog-随笔分类-ICE

Ice -- Hello World 之 客户端

Ice -- Hello World 之 服务端

Ice run time -- 对象标识

Ice run time -- 对象适配器

Ice run time -- 通信器

Ice -- Hello World 之 Slice 定义

Ice 在架构上提供的好处

Ice Box

Ice 客户与服务器结构

Ice 代理

Ice Servants

Ice对象 （Ice Object）

Ice -- Hello World 之客户端

Ice -- Hello World 之服务端

Ice对象（Ice Object）