Java Service Request Broker 简介

Java Service Request Broker(JSRB)是一个 Java/C/C++ 的开源项目
Project URL http://jsrb.sourceforge.net

项目目标按照优先顺序依次是:
1 高效,透明的通讯框架,屏蔽本地/远程网络架构的复杂性(高效来源于基于poll/epoll的NIO通讯框架,透明来源于多个JSRB Server之间的动态级联机制).
2 高效率,稳定的服务请求处理机制(高效来源于服务端为C语言实现,稳定来源于对服务进程的不间断监控和自动重启动机制)
3 分布式事务处理能力(JSRB 作为分布式事务管理器,初步实现了DTP XA协议,还在开发过程中).
4 客户端语言中立(语言无关通讯协议,客户端提供Java或C API库).

JSRB 大致架构如下:

JSRB SERVICE 特性/访问方式

1 SERVICE 无状态,通过二进制数据传递输入输出数据
2 运行时,可以有多个SERVICE实现进程, JSRB会平衡调度这些进程.

SERVICE支持同步/异步两种访问方式:
SERVICE之间也支持forward和嵌套调用两种方式

同步访问SERVICE:
Response Data = JsrbConection.syncCall("SERVICE NAME",Request Data);
当客户端从syncCall中返回时,它已经获得SERVICE的返回数据



异步访问SERVICE
long key = JsrbConnection.asyncCall("SERVICE",Request Data);
...
Response Data = JsrbConnection.fetchReply(key);
客户端可以提交服务请求后,过一段时间再去尝试获取数据, 便衣客户端同时提交多个服务请求,增加并发性.




SERVICE FORWARD
客户端访问SVC1, SVC1完成后将该请求forward到SVC2, SVC2完成后直接返回客户端数据.



SERVICE的嵌套调用
SVC1 调用SVC2 并获得SVC2的返回数据.







一般问题:
1 为什么会选择用Java 实现Service Request Broker
答: Java跟C语言相比, 代码执行速度其实并不慢. 我们一般感觉J2EE 应用慢,主要是由于IO(特别是socket和JDBC)慢造成的.
Java 在多线程编程, 开发的方便性方面比C/C++强.
JSRB在实现过程中,自行定义和实现了一套NIO框架, 增加了对于Linux epoll(Edge Triggered Mode)的支持, 同时为了实现与C进程的高效通讯,自行实现了Sysv IPC和创建子进程方面的Native代码.


2 为什么要用C实现业务代码,作为Service的实现语言.
从企业端的应用来看, 企业应用必定要跟数据库打交道, 实际上C语言访问数据库要比Java访问数据库快1到两个数量级. 甚至可以说, J2EE应用响应的大部分的延迟时间都耗费在JDBC上.
从大型项目的实施经验来看, 将这部分代码放在C进程中, 尽管要多付出通讯方面的代价,总体还是要比纯Java的方案快得多.


3 为什么分布式事务的优先级最低
从大型项目的实施经验来看, 分布式事务由于运行代价过高, 业务系统中用到的概率很小(基本上直接用数据库的事务). 对于CICS/TUXEDO应用而言,首先还是将CICS/TUXEDO 作为一个高效/稳定的通讯和服务请求处理排队框架来用.
如果真要有分布式的交易的需求,一般采用流水对帐+冲正处理方式解决.


4 为什么选择无状态方式实现SERVICE
无状态是提高并发效率, 实现透明故障迁移的最佳方式. Server端资源有限,为并发的成千上万个用户同时维护状态是非常困难的,这样也会造成集群实现的困难.
由于Client端是有状态的,所以这在实现上其实问题不大.



今后得空还会慢慢写更多文档介绍JSRB的一些组件的实现方式和特性.