ZeroC ICE的远程调用框架 AMD

继上一篇《ZeroC ICE的远程调用框架》,本篇再来说其中的AMD。

当在ice文件中声明某个接口方法Method为["amd"]后,接口方法在stub类生成的远程调用框架代码不会变,但在skeleton类生成的就不是_iceD_Method和Method,而是_iceD_Method和Method_async。而amd模式和非amd模式的代码生成模板区别在于,_iceD_Method调用Method_async代替Method,并且在调用后不进行out方向参数的处理。另外还会生成AMD_Module_Method类,用于Method_aysnc的参数。

在Ice远程调用中,有两种调用模式,Twoway和Oneway。Twoway的意是一个完整的请求包含一请求以及一应答,Oneway就是不需要这个应答。在Twoway模式下,即使声明接口方法返回void(即不返回结果),并且没有out方向的参数,skeleton类在完成接口调用后,还要写一个应答消息,消息包含应答状态,告诉代理端调用成功或失败。代理端的AsyncResult(即Future)也要阻塞或不阻塞等待这个应答消息。但是在amd模式(即Oneway)中,skeleton类在完成接口调用后,并不需要写回一个应答消息,代理端的AsyncResult也会忽略等待这个请求应答。

void
IceProxy::Ice::Object::_end(const ::Ice::AsyncResultPtr& result, const std::string& operation) const
{
    AsyncResult::check(result, this, operation);
    bool ok = result->waitForResponse();
    if(_reference->getMode() == Reference::ModeTwoway)
    {
        if(!ok)
        {
            try
            {
                result->throwUserException();
            }
            catch(const UserException& ex)
            {
                throw UnknownUserException(__FILE__, __LINE__, ex.ice_id());
            }
        }
        result->readEmptyParams();
    }
}
bool
Test::TestIntf::_iceD_startDispatch(::IceInternal::Incoming& inS, const ::Ice::Current& current)
{
    _iceCheckMode(::Ice::Normal, current.mode);
    inS.readEmptyParams();
    this->startDispatch_async(new IceAsync::Test::AMD_TestIntf_startDispatch(inS), current);
    return true;
}
时间: 2024-08-10 21:30:02

ZeroC ICE的远程调用框架 AMD的相关文章

ZeroC ICE的远程调用框架 ASM与defaultServant,ServantLocator

ASM与defaultServant,ServantLocator都是与调用调度(Dispatch)相关的. ASM是ServantManager中的一张二维表_servantMapMap,默认Servant则由_defaultServantMap和_locatorMap两张一维表维护.一个对 象可由这样的字符串指定"Category/Identity -f Facet".ASM是根据Identity和Facet对进行查找,而defaultServant和 ServantLocator

ZeroC ICE的远程调用框架 ThreadPool

ThreadPool提供Reactor/Proactor服务,并且强偶合了Reactor(反应器)/Proactor(前摄器).不同于Reactor/Proactor使用线程池 进行事件处理的设计.如ACE框架的ACE_TP_Reactor.同时ThreadPool提供一个共享的工作分派队列,可以用作Half-Async/Half-sync并发模式的线程池. ThreadPool为池中每个线程定制了一至的线程循环,运行在池中的线程者必须进行这个循环,接受线程池的统一控制.此外ThreadPool

Hessian轻量级二进制远程调用框架

Hessian轻量级二进制远程调用框架 Hessian是一个轻量级的二进制远程调用框架,官方文档地址,它主要包括Hessian远程调用协议.Hessian序列化协议以及客户端服务端代理等几部分,关于Hessian协议可以看下另外一篇文章Hessian远程调用及序列化协议.Hessian远程调用框架构建在Http协议之上,下面是示意图. 下面这个图是一次远程调用的过程 其中步骤3.4.5.6是核心过程,还要细化下, 步骤3:将远程方法调用转换为hessian调用,具体为,客户端首先要先和服务器端建

ZooKeeper伪分布集群安装及使用 RMI+ZooKeeper实现远程调用框架

使用 RMI + ZooKeeper 实现远程调用框架,包括ZooKeeper伪集群安装和代码实现两部分.  一.ZooKeeper伪集群安装: 1>获取ZooKeeper安装包 下载地址:http://apache.dataguru.cn/zookeeper 选择一个稳定版本进行下载,我这里下载的是zookeeper-3.4.6版本. 2>ZooKeeper伪分布式集群安装 伪分布式集群:在一台Server中,启动多个ZooKeeper的实例. 3>上传并解压安装包 4>创建实例

alibaba远程调用框架dubbo原理

alibaba有好几个分布式框架,主要有:进行远程调用(类似于RMI的这种远程调用)的(dubbo.hsf),jms消息服务(napoli.notify),KV数据库(tair)等.这个框架/工具/产品在实现的时候,都考虑到了容灾,扩展,负载均衡,于是出现一个配置中心(ConfigServer)的东西来解决这些问题. 基本原理如图: 在我们的系统中,经常会有一些跨系统的调用,如在A系统中要调用B系统的一个服务,我们可能会使用RMI直接来进行,B系统发布一个RMI接口服务,然后A 系统就来通过RM

使用 RMI + ZooKeeper 实现远程调用框架

在 Java 世界里,有一种技术可以实现"跨虚拟机"的调用,它就是 RMI(Remote Method Invocation,远程方法调用).例如,服务A 在 JVM1 中运行,服务B 在 JVM2 中运行,服务A 与 服务B 可相互进行远程调用,就像调用本地方法一样,这就是 RMI.在分布式系统中,我们使用 RMI 技术可轻松将 服务提供者(Service Provider)与 服务消费者(Service Consumer)进行分离,充分体现组件之间的弱耦合,系统架构更易于扩展. 本

RPC远程调用框架rsf和dubbo

1.rsf(Remote service framework)框架整体的架构 思考点: 1.注册中心使用的zookeeper,多机房部署,各注册中心要求数据一致,如何在一个节点发生异常情况下,不影响其他节点? 服务发现模块会定时的将最新的服务提供方列表刷新到注册中心,如PUMP定时的将提供方的接口列表写入到注册中心.注册中心考虑到 ZK 的优势.局限和 Redis 优势,通过 Pump 定时批量刷新数据到 ZK 集群,减少 ZK 写入压力:通过 Redis 集群管理提供方上下线,由 Pump 订

自研发RPC调用框架

自主研发设计RPC远程调用框架,实现服务自动注册,服务发现,远程RPC调用,后续实现服务负载均衡 主要包括:客户端服务,服务端,服务发现,服务注册 github地址:https://github.com/btshoutn/rpc_project 原文地址:https://www.cnblogs.com/shoutn/p/8297345.html

【PHP】远程调用以及RPC框架

前言 一个项目,从开始到版本更新,一直到最后的版本维护.功能在不断增多,对应的代码量也在不断增加,也就意味着项目变得更不可维护,这时候,我们需要用拆分的方式将一个项目打散,以便开发团队更好的对项目进行维护. 分模块 这个阶段,一般也是项目的初级阶段,由于人手不够,一个服务端的接口项目只有一个开发进行维护,根据开发的习惯,会把项目分成若干个模块进行开发,在一个项目下进行部署. 这样做的缺点在于项目会随着版本更新而变得不可维护. 分项目 随着每个模块功能的不断完善,代码变得更加臃肿.这时候需要对项目