qiezi的学习园地

前面简单写了点静态结构，这一次将主要关注动态模型以及调用方式。

这个系列的名字叫“为C++实现一个IDL”，实际上应该叫“为C++实现一个Remoting”可能更好一些，说是IDL，主要是想通过宏，使用简单的类型定义达到自动生成调用代码的目的。

一、首先来看看调用习惯。

从调用习惯入手，主要是因为看到目前有很多库/工具包在调用上都有很多不便之处。假如能在一开始就从这点出发，就能把调用接口设计得更好一些。

先来看看服务端如何开放一个服务。

我希望就是这么简单，客户端调用有多种方式：
1、 使用服务的IDL定义，直接调用：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);

    try{
        TestService test_service (“test_service”, &soap_service);
        test_service.method1 (/**/);
    } catch (SocketException& e)
    {
    }
    return 0;
}

这种方式比较简单，调用时会检查是否已经连接，然后发送调用请求，并处理调用结果。

2、 服务验证方式：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);
    TestService test_service;
    soap_service.getService (“test_service”, &test_service);

    if (test_service)
    {
        try{
            test_service.method1 (/**/);
        } catch (SocketException& e)
        {
        }
    }
    return 0;
}

3、 服务发现方式：

int main ()
{
    SOAPProxy soap_service (7911, “localhost”);
    vector <string> services_name = soap_service.getServiceNames ();
    // 
    IService* test_service = soap_service.getService (“test_service”);
    if (test_service)
    {
        vector <string> methods = test_service->getMethodNames ();
        IMethod* method = test_service->getMethod (“method1”);
        vector <Type*> types = method->getParameterType s()
        method->addArg (3);
        method->addArg (4);
        // 
        method->invoke ();
        // 
    }
    return 0;
}

二、基本需求。

简单分析一下，上面一共涉及了哪些类型？
IProxy:
这是所有Proxy类的基类(和接口)，它可以容纳多个服务对象，提供服务绑定、服务查询、服务发现、服务验证。
IService:
所有Service类的基类，可以容纳多个方法(Method)，提供方法查询、服务验证。
IMethod:
所有Method模板类的基类，容纳多个参数，包括返回值，可通过查询参数类型获得方法的类型定义。
IParameter:
所有参数的基类，包含一个参数类型描述和一个参数值。
IType:
所有类型的基类，预定义了一些基本类型，可自定义类型。

看起来挺多的，其实很难接触到这些，只需要使用宏来定义一个服务，就可以通过模板的类型推导，自动生成这些复杂的定义。

1. 直接调用。
   
   
   • 生成SOAPProxy，让它连接到远程主机。
     
   • 生成一个TestService对象，设置远程主机上的服务名称，并指定使用SOAPProxy，也即使用SOAP协议。
     
   • 调用TestService::method1方法。根据method1的定义，把服务名称、方法名称、各个in参数等打包成一个“集合”，交给SOAPProxy处理。
     
   • SOAPProxy把这个“集合”转换成SOAP消息，发送到远程主机，阻塞线程。
     
   • 远程主机上的SOAPProxy对象收到数据，进行解析。当解析出一个服务调用时，把它交给TestService服务处理。
     
   • TestService解析出一个方法调用，把它交给Method处理。
     
   • Method解析出各个参数，验证参数类型、完整性等，并执行调用或返回错误。
     
   • Method调用的返回信息(包括调用结果、返回值、out参数等)被打包成一个“集合”，交给TestService处理。
     
   • TestService处理后，交给SOAPProxy。
     
   • SOAPProxy把结果打包成SOAP消息，发回调用端。
     
   • 调用端解析SOAP消息，把OUT参数值赋给调用者提供的对象，调用完成。

    

2. 服务验证方式。
   
   • 生成SOAPProxy，让它连接到远程主机。
     
   • 生成TestService对象，调用SOAPProxy的getService验证版本。
     
   • SOAPProxy把TestService对象的信息(名称、成员及基类型等)发送到远程主机，阻塞。
     
   • 远程主机解析收到的信息，查找服务名，并比较查找到的服务类型与解析得到的类型。
     
   • 比较结果发回给调用端。
     
   • 调用端接着采用直接调用的方式，调用远程服务。
   
   这种方式看起来多了一些操作，不过验证的好处是能够减少调用时的异常。

3. 服务发现方式。
   
   • 生成SOAPProxy，让它连接到远程主机。
     
   • 查询远程开放的服务名称。(可省略)
     
   • 查找特定服务，得到服务描述信息。
     
   • 查找服务中的方法，得到方法描述信息。
     
   • 压入各个参数，并执行调用。
     
   • 调用前先判断参数是否与描述一致，然后调用SOAPProxy生成SOAP消息，发送到远程主机，阻塞。
     
   • 远程主机解析出调用。。。后面过程与第1种方式相同，远程主机并不知道客户端使用的是哪种方式来调用。远程主机处理结束，将返回SOAP消息给调用端。
     
   • 调用端解析出调用结果，并把各个OUT参数的值赋给method对象。
   
   使用这种方式，调用端不需要服务的类型定义。

四、异步调用/异步分派(AMI/AMD)。

同步调用时，调用端线程需要等待调用结果，服务端线程也要等待调用结束返回，才处理下一个调用。
为了在服务调用期间让线程能做更多的事：
调用端把调用交给线程池完成，并在调用完成后采用某种机制通知线程处理结果，或者直接由线程池中的调用线程调用结果处理函数。这种方式称为AMI(异步方法调用)。
服务端主线程则把接收到的消息解析后，放入处理队列，由线程池去处理调用过程。当调用完成后，结果放入结果队列，由主线程处理成消息，发送回调用端。这种方式称为AMD(异步方法分派)。
调用端和服务端依旧是使用通讯协议来沟通，双方都不知道对方是否采用了异步方式。

AMI和AMD对于静态定义的服务是有影响的，比如下面一个服务：

在同步调用时，它的调用方式：

异步调用时，调用方式：

正如上面演示的一样，异步调用的结果有2种方式去处理。
一是由线程池调用完以后，接着调用一个函数以通知结果。它不需要轮询，不过涉及到了线程问题，增加了一些复杂性。
另一种方式调用结束后，原调用线程在某个适当的“时机”去查询调用结果。这个时机可以是定时查询，也可以是被线程消息通知而去处理。

五、其它。

这一篇加上前一篇，应该是提到了全部的要点。
目前剩下的唯一一个难点，可能是在处理异步调用时，Method的定义。
正如上面演示的，一个方法在同步调用和异步调用时，就有3种调用方式：

特别地，它如何根据in和个数和out的个数，产生那2个参数个数匹配的异步调用函数？
再来回顾一下method1的定义：

显然有一定的复杂性，不过我认为还是可以处理掉的。拿3个参数的偏特化版本来说明：

通过对MethodBase类的IN＿COUNT参数定义偏特化，即可定义出这些不同的版本。

当然仅仅是知道了IN参数的个数，还没有提取出IN参数的类型，所以还不能生成函数的原型，或许需要把typelist加进来了（loki中的那个）。



这是后面要考虑的内容，今天先想到这。