asgard项目遗留问题 （2005-09-27更新）

asgard项目已经准备了一段时间了，不过有些基本问题还需要考虑，也有一些是新发现的问题，以及自认为比较好的解决办法。

通过第2、第4条的仔细研究，已经渐渐完善、明确了动态部分和静态部分的关系，使得Method包装类所完成的功能渐渐接近于一个函数，而元信息则脱离具体的对象提升到全局（当然还有些小问题没有解决）。

1、参数名称的问题。

为了与SOAP等基于XML的协议兼容，必须开始就把参数名称考虑在内。

代码经过C＋＋编译器编译以后，类型、变量名称等都不复存在，唯一留下的是RTTI，显然不能解决这个问题。所以只能在定义时把它加入。

BEGIN_SERVICE(TestService)
    METHOD ( void ( in < int > , inout < string > ,  out < short > ), method1, index, info, result);
END_SERVICE()

如果使用这种方式，index, info, result分别表示变量名字，在宏里面转成字符串，看起来好像不太舒服，而且宏不支持参数个数变化。

BEGIN_SERVICE(TestService)
    METHOD ( void ( in < int > , inout < string > ,  out < short > ), method1,  " (index, info, result) " );
    METHOD ( int ( in < int > , inout < string > ), method2,  " result(index, info) " );
END_SERVICE()

这种可能稍稍舒服一点，在Method构造函数或其它地方解析这个字符串，赋给各个参数。不过它的缺点是把编译期应该检查出来的错误，延迟到运行期。如果在编译期来做，又会使接口描述变得很复杂。

只是为了得到参数的名字，就要增加这么些麻烦。

c++0x只是一个库的标准，估计XTI也不会加入这些特性，而且c++0x很遥远，所以暂时以这种方式来做。

暂时的解决办法：

BEGIN_SERVICE(TestService)
    METHOD ( void ( in < int > , inout < string > ,  out < short > ), method1);
    METHOD ( int ( in < int > , inout < string > ), method2);
    BEGIN_SERVICE_DEFINE(TestService)
        METHOD_DEFINE (method1,  " (index, info, result) " , test_func);
        METHOD_DEFINE (method2,  " result(index, info) " ,  & Test::test_method);
    END_SERVICE_DEFINE()
END_SERVICE()

缺点是参数名称中的错误，要延迟到运行期才能解决掉。

2、服务对象的大小。

如果客户端要调用其中一个方法，生成一个TestService，则构造成本太高，特别是一个服务中有多个方法的时候。一个服务容纳了多个方法，而每个方法包含一个vector，以及各个参数，这还没考虑以后的扩展。

所以应该修改调用方式，让它只只需要生成调用所需的最小（少）对象。

这部分考虑还不成熟，暂时可以不管它，而以方法作为考虑的对象。

暂时想到的解决办法：

Method对象中的parameters容器和各个参数，只在调用operator ()或async_call时，才真正生成出来。

这样的话，Method对象中仅保存一个空的vector。

甚至这个vector也可以只是一个空指针，当调用那几个函数时，才生成一个。

暂时把这个过程命名为Create On Call(COC)。

COC的好处是显而易见的，每个对象将只有8字节，虚表指针＋数据对象的指针，“数据对象”是实际调用时才生成的对象，包括参数vector容器、回调函数指针（可能由动态生成一个委托对象，以适应广泛类型的回调函数）、对象锁（防止干扰到前一个调用）。初始化成本接近0（虚函数表的初始化忽略不计）。

当调用operator()或async_call时（以下简称CALL），将调用create_parameters虚函数，动态生成一个vector。这样，没有调用到的Method不会象原来一样影响到服务对象的构建性能。

这就要求把Method的“元”信息提到全局，当然更符合“元”的本意，原来由服务对象查询Method以获得“元”信息的过程，现在看来也是不合理的。

3、in模板可以省略。

in是默认的参数类型，返回值则默认为out类型，这都是不需要明确指定的。

解决办法：

这个问题是比较好解决的，在InOutTypeTraits模板类中，为各个偏特化版本定义一个type类型，InOutTypeTraits＜T＞::type的类型为in＜T＞，InOutTypes＜in＜T＞＞::type的类型为in＜T＞，InOutTypes＜inout＜T＞＞::type的类型为inout＜T＞，InOutTypes＜out＜T＞＞::type的类型为out＜T＞，InList模板类中进行这种转换。

4、异步调用队列。

在第2点中介绍道：

每个对象将只有8字节，虚表指针＋数据对象的指针，“数据对象”是实际调用时才生成的对象，包括参数vector容器、回调函数指针（可能由动态生成一个委托对象，以适应广泛类型的回调函数）、对象锁（防止干扰到前一个调用）。初始化成本接近0（虚函数表的初始化忽略不计）。

提到了对象锁，这是一种低效的做法，可以使用异步调用队列来替代它。

解决办法：

当开始一个调用时，临时生成上面所说的“数据对象”，交由一个调用队列去完成。这时，由于Method对象基本不管理数据，所以它成了一个空壳，作用是保存类型信息。

异步调用最好的实现就是整个系统都由异步调用构成，而同步调用是由异步调用模拟而成。原本打算绕过这种方式，用最简单的方法来做，现在好像又绕回来了。

上面这个做法，很好地把元信息和真实数据分开了，所以打算改成这种结构。

5、全局元信息。

通过第4条的研究，已经使得Method对象成为一个空壳，而“数据对象”在没有调用时又不生成，使得自省结构必须重新做。

考察了java等语言的自省，也打算把元信息的位置提升到全局，而每个Method对象将只保留一个全局元信息的指针，这样应该更自然。


（以后遇到的问题只更新到这个文档中）