java事件处理机制:Java事件处理模式

　　Java事件模式是动态响应系统重要基础在图形界面领域事件模式已经有很多文章介绍但是在服务器端我们会碰到更多事件模式这里本人试图整理总结下:

　　事件直接驱动模式

　　事件模式第个要求就是性能要求需要直接而且快Command模式是必须经常使用主要适合于迅速处理 前台命令Command模式往往是系统架构重要部分也是流程控制主要模式

　　Command模式经常JavaReflect起使用系统事件处理系统是处于动态变化随着功能要求扩展就可能有动态变化事件处理响应系统以Struts中action为例我们知道Structs个主要配置文件是struts-config.xml 如下:

＜struts-config＞
　　＜action-mappings＞
　　　　＜action path="/login" type="com.javapro.struts.LoginAction"/＞
　　　　＜action path="/logout" type="com.javapro.struts.LogoutAction"/＞
　　＜/action-mappings＞
＜/struts-config＞　　它实际是个command和event映射关系通过这个配置文件运行时动态装载相应Action完成Command模式 我们检查LoginAction代码就可以看出Command模式基本特征:

public final LoginAction extends Action {
　　public ActionForward execute(ActionMapping mapping,
　　　　ActionForm form, HttpServletRequest request, HttpServletResponse response)
　　　　throws Exception {
　　　　　　　　.................
　　}
}　　很明显典型Command模式需要有个接口.接口中有个统思路方法这里统思路方法就是execute;

　　比如我们有个实时系统客户段向服务器发出区别编码代号意味着区别请求区别请求有区别Handler进行 处理Handler接口是:

　　public Handler{
　　public handleRequest;
　　}　　区别性质处理过程继承这个Handler接口如负责进入系统处理过程

　　public EnterHandler implements Handler{
　　public handleRequest{
　　//具体业务处理
　　......
　　}
　　}　　Handler时是:

//从cache中获取这个requestId对应Handler
Handler handler = (Handler)cache.get( Integer(reqId));
//handler统思路方法handleRequest
outInf = handler.handleRequest;　　以上是常用个事件驱动模式它特点是靠个事件直接启动对应事件处理器

　　Chain of Responsibility职责链模式也应该属于这类当事件到达后让这个事件在我们提供批处理器中逐个挑选适合处理器进行处理这个模式缺点是显然性能丧失在逐个挑选 上般不推荐使用这个模式适合在我们无法预知发生事件内容时使用不知道发生事件具体情况 我们就无法在运行前事先为其指派相应处理器只能靠运行时事件自己去摸索“撞运气”

　　监控式事件模式

　　监控式事件模式就区别于事件直接驱动模式它是借助第 3者来监控和触发事件这类事件特点是: 有个观察者置身事外在定期独立运行着我们将我们要监听事件向这个观察者注册这样观察者就 代替我们来监听这个事件应用客户端通过观察者来获得事件状况　　应用客户端有 3种和观察者交互方式:1.直接融合 2.推方式 3.拉方式

　　直接融合就是说应用客户端自己就是观察者两者融合这样无疑应用客户端获得触发时间是最快

　　推方式就是观察者旦侦测到事件发生立即将事件Push推到应用客户端；拉方式类似收取邮件应用客户端在需要时才从观察者拉取事件

　　JDK 1.4None Blocking I/O是监控式事件模式典型实现Selector显然是个监控I/O第 3者当有外部事件进来通过 Slector.select思路方法可以获得外部事件从而进行处理可参考我本栏文章

　　监控式事件模式适合使用在触发性质场合比如数据库后端触发器 界面触发 I/O触发 状态改变触发等

　　我们以个信件触发为例这其实是个Observer应用例子:

　　比如用户提请服务器计算个数据如果用户同时要求将计算结果向自己信箱发封那么我们看如何设计？按照通常思维这是个次序问题先在内存中计算数据然后将结果发送到他信箱最后返回结果到用户端我们知道信件发送是耗时因此有可能网络原因造成信件发送很慢这是用户就直等不到他计算结果很显然我们使用监控式事件模式来解决让发信事件由监控者去完成只要需要时触发就可以了:

　　public Computer extends Observable{
　　public Computer{
　　　　//将sendMailObserver设定为本类观察者
　　　　addObserver( sendMailObserver);
　　}
　　.......
　　public void compute(String input,boolean needEmail,String email){
　　//计算操作
　　　　.........
　　 (needEmail){
　　//设置变化点
　　　　　　 Changed;
　　　　　　//如果需要发送email我们把email地址作为参数传送过去
　　　　　　 notyObservers(email);
　　}　　　
　　}
　　｝　　我们再来看监控观察者代码是如何写？

　　public sendMailObserver implements Observer{
　　public void update(Observable obj,Object email){
　　 (email instanceof String){
　　sendMail(email);
　　}
　　}
　　}　　这样服务器在执行compute思路方法时就没有发送邮件等待直接继续执行

　　监控式事件模式和事件直接驱动模式可以在个系统起使用外界信号通过事件直接驱动模式启动系统处理模块 系统处理模块处理过程中可以通过监控式事件模式来触发其它后台任务这样个架构非常适合实时处理系统

　　既然事件处理模式是众多应用系统基本模式那么应该可以形成个框架标准JMXnotication Model就是这样个架构设计

　　JMX Notication Model

　　我们知道JMX是提供了种对MBean资源执行控制和配置管理机制但这只是复杂分布式系统中部分 还有需要资源能够感应状态改变或者特定事件变化机制这就是JMX Notication Model 在JMX Notication Model中均可以实现"事件直接驱动模式"和"监控式事件模式"这取决于你应用需求

　　JMX Notication Model允许MBean通过notications广播事件接受者只要注册为个listerner JMX MBean notication model 将会激活这个listerner注册次然后将直接受到 来自广播者发出各种事件

　　事件模式有 3个角色第个是事件发出者producer 然后是事件接受者Consumer,第 3个 是要传输事件JMX notication model也是这样分别依靠下列组件来实现这 3个角色:

　　A. NoticationBroadcaster接口, 事件广播发出者 这个接口允许监听者在需要发出notication中注册他们感兴趣事件

　　B. 通用事件(Notication)这是我们要传输事件 Notication事件能被直接使用也能成为子类这些都依赖于随同事件传输信息 通过使用通用事件类型监听者将能接受来自广播者所有类型事件

　　C. NoticationListener接口, 事件监听者或者接受者 用于接受来自广播者任何notication信号

　　D. NoticationFilter接口, 这个接口为notication监听者提供个对发出事件过滤器

　　E. NoticationEmitter 接口, 扩展了NoticationBroadcaster接口当删除监听者时允许更多控制功能

　　只要是MBean就既可以成为notication发布广播者也可以成为notication监听者接受者或者同时两者都可以

　　Attribute Change Notications

　　Attribute Change Notications是种特殊notication, 任何时候MBean属性attribute 被修改外界能够被通知到

　　在JMX架构中MBean能够在属性attribute变化发生时发出通知有关诊断属性变化机制以及触发 通知事件并不属于JMX规定部分每个MBean可以有自己独立实现方式

　　Timer Service

　　Timer Service触发器是在规定日期和事件发出通知它能够个恒定间隙不断重复发出通知 通知可以发往所有注册为接受timer通知对象Timer Service也是个可管理MBean允许应用系统设置 个可配置调度程度

　　Monitoring

　　通过使用monitoring service个或多个MBean属性将按规定间隔时间被监视 对于被观察Mbean,监视器monitor将从它上面获得个值叫derived gauge这个derived gauge可以是 被观察属性原值也可以是个数字性属性连续被观察值的差

　　当derived gauge值满足系列条件时每个monitor server将会发出个特定类型通知 这些条件都是在monitor被化时设定也可以通过monitor MBean管理接口动态设定

　　根据MBean内部属性值类型有 3种monitor:

　　A.CounterMonitor - 使用Java整数类型来观察属性有个行为特征:

　　a. 总是大于或等于零.

　　b. 能自增.

　　c. 能回滚.

　　B.GaugeMonitor - 使用java整数或浮点类型观察属性象gauge(测量仪器) 要么上升　要么下降减少

　　C StringMonitor - 使用String类型观察属性.

　　事件处理架构

　　JMS是基于Socket种消息处理框架原理类似于监控式事件模式但是JMS已经把这种模式上升到架构高度区别JVM间也依靠JMS消息可以实现事件系统(注意是系统不简单是个小事件了)触发和激活

　　

　　从上面JMS架构图可以看出事件 3个角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer的间建立个连接Connection．

　　JMS可实现同步或异步事件触发机制分别是通过Poin to Po(拉方式)和Pubilsh/Subscibe(推方式)具体完成在分布式计算环境中异步机制是非常重要可以起到解耦作用分布环境中单点或通讯问题是经常发生整个分布式系统不能总是依靠同步机制来可靠地传递事件或notication．

　　由此可见事件处理模式从Java诸多架构到我们具体应用随处可见根据区别应用需求选择区别事件处理模式才能真正挖掘Java潜在性能

延伸阅读

• 2011-5-19-- 事件驱动,《.NET4.0 面向对象编程漫谈》读书笔记 ——第9章 事件及事件驱动
• 2011-5-12-- 委托和事件,Java 委托事件处理
• 2009-1-12-- java事件处理:JAVA事件模式下PHP如何实现
• 2009-2-12-- 事件机制:用C++模拟C#事件机制
• 2009-9-25-- java事件模型:Java事件模型学习(2)--实现自己的事件
• 2009-8-17-- java事件处理机制:JAVA的事件处理机制
• 2009-2-12-- java事件机制:游戏框架设计Ⅰ—— 游戏中的事件机制
• 2008-9-10-- java事件:Java侦听系统终止事件
• 2008-9-10-- java适配器:JAVA事件适配器