ZeroC ICE的远程调用框架 class与interface

我们在ice文件中定义的class或interface，slice都会为我们生成stub存根类和skeleton骨架类。在这里要注意slice并没有分别生成两份单独用在客户端或服务端的接口给开发分发。在ice中，client和server只是相对于ice object的使用关系，client即使用代理远程调用ice object的一方，server相对就是为ice object提供执行servant的一方。并非我们传统意义上的c/s结构中的client和server。ice object既可以存在地c/s结构的server端，c/s结构的client端同样也可以提供ice object给server端远程调用。

我们先来看一下，slice对定义的空类和空接口如何生成代码，下面是生成的stub存根类和skeleton骨架类的类图。

上面分别在ice文件定义一个空类"Empty"和一个空接口"I"，slice分别为我们在名字空间::IceProxy::Module和Module下都生成了class Empty和class I的类。

不论是类还是接口，对于空的定义目标，slice生成的stub存根类都只是重写（override）了静态方法ice_staticId和成员方法_newInstance。上图左边的两个类Empty和I则是stub存根类。再来看右边生成的skeleton骨架类，slice也几乎做了同样的处理，重写（override）了骨架类最小接口ice_id，ice_ids以及ice_isA，还有跟streaming流化相关两个实现函数_iceReadImpl和_iceWriteImpl。唯一不同的是对于定义为类的Empty，它的skeleton骨架类多了两个成员函数ice_clone和ice_factory。

当我们定义一个类或接口，slice就会最少为我们生成上面类图所示的函数。当我们再定义一对非空的类或接口，我们就可以观察到slice为我们生成了什么，下面的类图隐去上面给出的已知。

首先是定义一个有一个方法的简单接口Intf。

灰色的类是Ice项目内置的类，非slice生成的类。slice为我们针对这个接口的远程调用生成了上面的框架的代码。生成的代码比重偏于Stub存根类（即代理方）的使用（如何应用远程调用）上。Skeleton骨架类重写（override）_iceDispatch分派，开设一个待实现的接口方法函数。

然后是定义一个非空的类NotEmpty，简单地有一个成员，成员类型为我们开篇时定义的Empty。

与上面给出接口生成的类图相比，slice对类的生成框架代码主要集在实体端，并且都是与流化（streaming）相关的设施。而生成的Stub存根类和对Empty（空类）生成的Stub存根类一样，因为它并没有接口方法，可以提供给代理进行远程访问。

从上面可以看到不论类还是接口，在代码映射后都是一个类实体。在slice定义时，我们使用这些类或接口时，都看作一个类实体。而使用这些类或接口的指针时，则看作是它们的代理。我们看下面定义

class B;
interface A {
   B b;
   B* bprx;
};

class B {
};

A::b会映射成::IceInternal::Handle<B>，而A::bprx会映射成::IceInternal::ProxyHandle<B>。指针被看作是一个对象实体的代理（引用）。

不论是类实体还是代理，都可以进行流化（streamin）在远程调用过程中传递。当传递一个指针，就是在传递相对于某个对象实体的代理。通过代理在ice世界任何一处都可以使用远程调用访问目标的实体。但是传递一个实体而非代理时，就和我们的c++语言在函数中传递对象实体一样，会在传递的目的方进行实体的构造。所以在ice程序中，尽管有一方使用代理进行远程访问为主，但它同样需要依赖slice生成的skeleton骨架类的代码，stub存根类和skeleton骨架类的代码并不分开发给c/s两方的开发者。

下面是以ice代码项目的测试例子项目为例，cpp/test/objects。

slice中定义的类图

slice生成的Skeleton骨架类