JBOSS 做项目时的问题 有关Jboss, Mbean, Session bean 求助

05-12-21 bjshasha
系统目前的设计如下:
------ Client --------
| |
JMS 数据通道
| |
------ Server --------
|Jboss |
| Stateful Session bean |
| |(1)| |

[MBean与Session bean通讯]
| |(1)| |
| MBean |
------ Server --------
| |
Socket数据通道
| |
----- Collection --------

目前的问题集中在于(1)部分的实现如何处理
需求:由于从Collection会有大量的消息传递到Mbean,Mbean要处理消息并且要传递消息到不同的客户端连接的Session bean
问题:
1.是否有办法获取到Jboss容器创建的Session bean 的对象列表
2.Server 层中的 MBean实现与Session bean实现间是否有更好的通讯机制
(曾经考虑过JMS通讯 不过JMS属于异步的方式同时Session bean部分还要加入JMS接收和判断处理不知道是否是好的设计而且如果Mean采用topic与Session通讯 则Session bean也要判断对自己无用的消息。)

系统目前采用Ejb3 编写Stateful Session Bean

大家帮帮忙啊

bjshasha
2005-12-21 10:45
还有一个疑问没有搞清楚
顺便也提出来:
就是在JBOSS 中 Session Bean 容器和 MBean 是否在一个JVM中
印象中好像EJB是可以跨越Jvm的 在Stateful Session Bean的容器和 Mbean的管理器之间是否是一个JVM
因为设计中想用单例模式做一部分东西
如果跨越了多个JVM单例的类也要被实例化多次了

求解

banq老大 看到你上午在啊 帮帮忙
叩谢

banq
2005-12-21 10:55
尽管我非常推崇JBoss,但是,再大热情也不会让我做绑定JBoss的事情,除了JNDI以外,不能做移植性很差的In Box系统。

>1.是否有办法获取到Jboss容器创建的Session bean 的对象列表
很危险,如果你有这种需求,一定要这样做,可以考虑是否需要EJB架构了,EJB对于通用商业应用是简单有效规则的,但是灵活性/定制性都是很差的,尽管是EJB3。能详细说说为什么要这样做吗?

>2.Server 层中的 MBean实现与Session bean实现间是否有更好的通讯机制

是可以的,但是和JMX打交道,现在趋势已经抛弃单纯的JMX架构,而是使用Ioc容器+JMX的架构,这篇文章如下:

http://www.jdon.com/artichect/micocontainer.htm

不好意思,没有真正帮助你,如果你将需求完整表达出来,我们可以探讨一个可维护性更好 可伸缩性更好的方案。

yuxie
2005-12-21 13:34
MBean ???
楼主说的MBean 是 Message DriverBean还是JMX中的ManagedBean??
JMS并不一定非要异步,可以做同步处理的

bjshasha
2005-12-21 15:12
谢谢benq老大的回复

yuxie 这里的Mbean指的是JMX中的manageBean 不是MDB
JMS的确是可以实现同步处理不过对于上面提到的session bean与Mbean之间的通讯MBean是要与Session bean的多个实例进行消息交互除非每一个请求来了后建立自己的Q 不然还是要做Topic处理这样对于同步处理又比较麻烦
本来想自己设计一个pool将session bean的实例放到pool中这样又可能造成jboss的池在释放实例的时候不能完全释放掉
所以还是没有好的办法

可能的确要像benq老大说的换一种架构方式来实现比较容易不过这样又牵扯到Client之间的通讯问题。

大家再帮我想象办法啊

bjshasha
2005-12-21 15:53
系统的层结构就像开始我用字符所画的
系统共分为三层结构
Client ---> Server <---- Collection
Server层部署在Jboss中
Client 与 Server之间需要大量的数据交互 其中有Client主动请求的信息 也有从底层上来通过Server层主动发给Client的信息。
目前的设计为Server层到Client层的消息利用JMS通道进行消息传递,其中既有PTP模式的也有SUB模式的JMS信息。
Server层与Collection之间同样为不定时的多类型交互信息 出于性能考虑collection层采用C++实现。因此Server 与 Collection之间通过Socket进行消息通讯。

在这种情况下Server层上层为Session bean提供的调用层 下层为Mbean实现的Socket Server层
目前由于业务要求 Collection 所传递的消息和数据在经过Mbean处理后要通知不同的Client连接做相应处理。

同时Session在接收到请求后也要将请求处理后再传递到Mbean然后进行Socket传递。而且部分操作要实现同步处理。

本来对于Session bean想在Jboss容器管理的基础上建立自己的池保存每个Client对stateful Session bean的请求并与Mbean共享,客户端在断开连接时或主动调用Ejb的@remove方法时触发Session bean的@PreDestroy方法移除自定义池中的相应对象。
目前的没有查清楚Jboss的容器管理机制。不知道在有外部引用的情况下如果Client出现异常断开Jboss容器是否能正常销毁容器中的对象。同时建立自己的池后Mbean会引用池中的对象,在引用的过程中如果客户端断开,Jboss容器会不会产生异常。

bjshasha
2005-12-21 15:56
希望大家多帮帮忙
或者提出下别的更好的方案

banq
2005-12-22 10:11
>在这种情况下Server层上层为Session bean提供的调用层 下层为Mbean实>现的Socket Server层

还有一种常用的方案,Server层使用EJB,其实你需要一个中间者在Collection的socket和EJB之间作为数据交换,有两种常用的方案:使用基于socket的Http Web技术;使用自编的一个基于socket的Java Application。

因为EJB对于这两种客户端技术是最好解决,也是最通用的,而且无需绑定JBoss,在这里没有看出一定要使用Mbean的理由。

这两种技术选用区别是事件触发机制不一样:主要取决于你的另外一端Collection Socket的动作,Web技术是一种被动需要Collection主动触发提交;而直接基于socket的application,则可以做成主动从Collection端读取数据,这样Collection端则可简单点。


>如果Client出现异常断开Jboss容器是否能正常销毁容器中的对象。同时
>建立自己的池后Mbean会引用池中的对象,在引用的过程中如果客户端断
>开,Jboss容器会不会产生异常
使用stateful最好客户端主动调用remove,当然容器自身可在session timeout达到时,自动清除stateful,但是在这之前,如果你的客户端连接比较多,则可能发生容器将内存中的stateful钝化到硬盘上,当然如果Stateful作为一个对象,如果别处有其引用,则不会被清除,导致内存泄漏。

总之,Stateful是一个双刃剑,玩的不好容易引火上身,对于你这样的实时事件机制,个人认为不太适合使用企业级的技术如EJB,直接使用JMS,server这里直接使用一个Web Server即可:

client ---> JMS -----> Web server ---> Collection

Web Server即作为交换数据用(接受Collection的数据提交),又替代你前面的Stateful作为业务逻辑处理,可以将自己的Service对象保存在HttpSession,自己控制这些Service对象的生命周期,如果你觉得控制生命周期麻烦,可使用Jdon框架的Stateful Service ,只要将你的对象继承Stateful即可,可参考JPetstore的CartService。

不使用EJB的一个可能缺憾是:没有伸缩性了,其实在这个架构中,我们引入了JMS,JMS支持集群,有很强的集群性,因此如果Web Server这里运算成为瓶颈,我们可将更多负载移植到另外一套JMS上,Web Server不作太多的运算。

以上方案初步具备简单性 可扩展性,仅仅做参考。




bjshasha
2005-12-27 17:26
谢谢banq老大
最近忙于与客户交流
没有来
最后业务中相关的的流程取消了
所以由Server层到Client层的消息只有Topic Message了
所以不需要考虑从Server 到Client的PTP通道的分发了

在之前讨论的结果是建立一个单独的Mbean, Stateful的操作由的Stateless Session bean传入调用Mbean中由Mbean保持Client的状态
Mbean中维持一个与Client的beat heart来检测Client的连接状态
分发操作由Mbean完成 不过这个现在也不需要了

banq老大提到的结构的问题 由于项目开始时的各种原因选择的
项目进展了一段时间除非是重大问题换架构的可能性比较小
因为已经经过客户确认了
没办法只能在这个结构上做了

banq
2006-01-02 20:52
是这样,JMX的MBean据我了解有不少架构选择,因为除了EJB之外就没有可管理的组件框架选择了,所以,对于特殊要求,EJB不能完成的,大家只能去选择JMX架构,我曾经大力抨击过,但是自己也一下提不出方案。

现在好了,Ioc出来后,picocontainer、Spring /Jdon Framework都能够弥补这种缺失。Ioc容器和JMX结合可以产生除EJB以外更灵活的组件架构选择。

http://www.jdon.com/artichect/micocontainer.htm

猜你喜欢