笨笨的思想片断

零碎片断,杂七杂八。
posts - 25, comments - 79, trackbacks - 0, articles - 0

Java Service Request Broker简介

Posted on 2007-12-12 00:15 笨笨 阅读(2677) 评论(1)  编辑  收藏 所属分类: Java Service Request Broker

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的一些组件的实现方式和特性.


Feedback

# re: Java Service Request Broker简介[未登录]  回复  更多评论   

2008-01-27 06:56 by 哈哈
想法其实不错,不过有些说法需要实践来证明。上来就说“ Java跟C语言相比, 代码执行速度其实并不慢”,“实际上C语言访问数据库要比Java访问数据库快1到两个数量级”缺乏税赋力。

其实我反而觉得j2ee访问数据库慢不完全因为jdbc,更多的是数据库本身就慢,设计有问题或者查询策略有问题。
还有一个瓶颈就是对象序列化。目前应用最广的webservice可以说也是最缓慢最消耗资源的,相对的就得到了对各种平台的良好兼容和支持。
j2ee应用还有一个大毛病就是太费内存,当然换来的是程序的可靠性,平台无关性。

分布式事务我没那么多经验,就不发表太多评论。
你说的JSRB可能确实不错,不过我认为还需要再进行论证。至少从阅读了本文之后还没真正感觉到太多惊喜。

我觉得现在的企业应用大多会吧降低程序和设计复杂度放在首位。如果这方面做的比较好可能更吸引人。

"业务系统中用到的概览很小"中的概览是不是概率?

只有注册用户登录后才能发表评论。


网站导航: