(转)hessian源码分析(一)------架构

在计费中心的对外交互这块采用了hessian,有必要对hessian的运行机理和源码做一定的解析。

大致翻了翻源码后,发现hessian的主要结构分客户端与服务端,中间基于http传输。客户端主要做的事情是把对远程接口调用序列化为流,并传输到服务端;服务端主要做的事情是把传输过来的流反序列化为对服务的请求,调用相应服务后把结果序列化为流返回给客户端。一次完整的调用如下图所示:

HessianProxy是hessian client处理客户端请求的核心类,它采用proxy的设计模式,代理客户端对远程接口的调用,hessian client的主流程的时序图如下所示:

HessianSkeleton是hessian server端的核心类,从输入流中返序列化出客户端调用的方法和参数,对服务端服务进行调用,然后把处理结果返回给客户端,主要流程时序图如下所示:

时间: 2024-07-30 19:11:24

(转)hessian源码分析(一)------架构的相关文章

spring transaction源码分析--事务架构

1. 引言  事务特性 事务是并发控制的单元,是用户定义的一个操作序列.这些操作要么都做,要么都不做,是一个不可分割的工作单位.通过事务将逻辑相关的一组操作绑定在一起,以便服务器 保持数据的完整性.事务通常是以begin transaction开始,以commit或rollback结束.Commint表示提交,即提交事务的所有操作.具体地说就是将事务中所有对数据的更新写回到磁盘上的物理数据库中去,事务正常结束.Rollback表示回滚,即在事务运行的过程中发生了某种故障,事务不能继续进行,系统将

转:Backbone源码分析-Backbone架构+流程图

作者:nuysoft/高云/[email protected] 原文链接:http://www.cnblogs.com/nuysoft/archive/2012/03/18/2404274.html JSMVC职责划分 M 模型 业务模型:业务逻辑.流程.状态.规则 (核心)数据模型:业务数据.数据校验.增删改查(AJAX) V 视图 (核心)视图:定义.管理.配置 模板:定义.配置.管理 组件:定义.配置.管理 (核心)用户事件配置.管理 用户输入校验.配置.管理 C 控制器/分发器 (核心)

nginx源码分析:架构解析

nginx启动流程: 根据上面的手稿得知,nginx在循环中调用ngx_process_events_and_timers该函数来处理事件,在该函数中,最主要的一个操作是调用了ngx_process_events函数,该函数是一个宏定义,然后我再工程里面搜一下ngx_event_actions,结果如下: ngx_event_action在每一个多路复用后端中被分别赋值. 在ngx_event_accept函数中,没接收到一个新的连接,就会建立一个ngx_connection对象,并将ngx_r

hessian源码分析-服务器端

服务器端逻辑很简单,核心类是HessianSkeleton,客户端的请求最终会调用到HessianSkeleton.invoke方法,此方法其实没有什么特别,反序列化,调用相应的方法,再把返回值序列化,放响应里,HessianSkeleton继承AbstractSkeleton,在实例化时,AbstractSkeleton的构造函数会把相关类的方法名和方法实例都取出来,缓存到_methodMap里,方便使用: /** * Create a new hessian skeleton. * * @p

sshe源码分析——全局架构

在Web.xml中 <!-- 需要拦截的JSP --> <filter> <filter-name>sessionFilter</filter-name> <filter-class>sy.util.base.SessionFilter</filter-class> <init-param> <param-name>include</param-name> <!-- 在securityJsp这

RMI 系列(02)源码分析

目录 RMI 系列(02)源码分析 1. 架构 2. 服务注册 2.1 服务发布整体流程 2.2 服务暴露入口 exportObject 2.3 生成本地存根 2.4 服务监听 2.5 ObjectTable 注册与查找 2.6 服务绑定 2.7 总结 3. 服务发现 3.1 注册中心 Stub 3.2 普通服务 Stub RMI 系列(02)源码分析 1. 架构 RMI 中有三个重要的角色:注册中心(Registry).客户端(Client).服务端(Server). 图1 RMI 架构图 在

Caching-缓存架构与源码分析

Caching-缓存架构与源码分析 首先奉献caching的开源地址[微软源码] 1.工程架构 为了提高程序效率,我们经常将一些不频繁修改,但是使用了还很大的数据进行缓存.尤其是互联网产品,缓存可以说是提升效率优化第一利器.微软为我们实现了俩种缓存方式:内存缓存.分布式缓存.个人理解如果缓存在前端电脑内存的缓存叫做内存缓存,如果缓存在其它设备上,那么叫做分布式缓存. 俩种缓存方式的优缺点 我开发程序经历过三个时间点,开始的时候从来不使用缓存,之后将数据缓存在内存中,最后使用分布式缓存.内存缓存的

JDK源码分析之concurrent包(一) -- Executor架构

Java5新出的concurrent包中的API,是一些并发编程中实用的的工具类.在高并发场景下的使用非常广泛.笔者在这做了一个针对concurrent包中部分常用类的源码分析系列.本系列针对的读者是已经对并发包中的Executor框架和工具类有所了解并懂得如何使用的人群,如果对并发包还不了解的朋友,请先做些了解.网上对这方面的讲述有丰富的资源. 本篇博文是第一期,首先对Executor架构做一个概述.这里只简单介绍接口和类的继承.使用关系. 盗用一张类图来描述结构: 解析: Executor是

Docker源码分析(一):Docker架构

[编者按]在<深入浅出Docker>系列文章的基础上,InfoQ推出了<Docker源码分析>系列文章.<深入浅出Docker>系列文章更多的是从使用角度出发,帮助读者了解Docker的来龙去脉,而<Docker源码分析>系列文章通过分析解读Docker源码,来让读者了解Docker的内部实现,以更好的使用Docker.总之,我们的目标是促进Docker在国内的发展以及传播.另外,欢迎加入InfoQ Docker技术交流群,QQ群号:272489193. 1