AJAX方案选择

  在采用AJAX技术的应用中, 常见的是两种架构设计, 一种是采用RPC(Remote Procedure Call)方案, 后台应用直接将java对象包装为service接口, 在js对外暴露(java对象完全不知道web层), 在js中通过类似函数调用的方式访问后台服务.而另外一种方案是在后台维持一个前台DOM节点的映象,触发前台事件之后, 前台引擎自动截获该事件, 并翻译为对后台事件监听器的调用, 将请求提交到后台, 后台程序处理请求之后更新后台DOM节点, 然后将页面变更部分传回前台页面. 这两种方案一种是倾向于在js中提供自我封闭的程序模型(对远程服务的调用体现为对一个js函数的调用), 一种是倾向于在后台提供封闭的程序模型(对前台页面的更新体现为对一个后台java对象的属性和结构的改变). 这两种方案的共同之处在于它们都试图在一定程度上屏蔽前后台程序的交互细节, 而提供一种统一的程序模型.
  但是我们需要记住软件设计的第一要义在于系统的分解, 而Browser和Server之间客观存在的http信道是天然存在的一种分界线. 任何强迫我们忘记B/S之间的界限的技术都是需要谨慎对待的. 例如控制后台对象的权限问题, 很多RPC方案限制了应用程序对于web接入层的直接接触, 而只能通过AOP(Aspect Oriented Programming)技术来动态织入权限控制代码. 在实际使用中, 这种方式往往因为service接口函数的多样化而造成配置上的繁琐.  而在我们的体系架构中, 系统边界划分在web访问层上(而不是java service层), 借助于web访问协议自身的一致性和透明性, 我们只需要如下实现
   Object invokeWebEvent(){       
     return new ActionMethodInvocation(getWebObject(), getObjectEvent(), getInterceptors()).proceed();
   }
就为所有WebObject加入interceptor堆栈, 完全不需要AOP的动态织入技术.
  在witrix平台的设计中, 因为大量采用pull方案, 我们对于前后台交互方式采取的是完全开放的态度, 前后台的交互接口完全定义在web访问层上(即前台程序直接访问一个url获取数据), 尽量避免将系统架构的限制引入到应用程序设计中来. 确实, Browser和Server之间的原始交互方式是受限制的, 狭窄的, 但是从系统设计的角度上说, 这正是异构系统集成和进行系统核心控制的最好场所, 任何试图独占该连接信道并在层层封装之后提供更加丰富的访问语义的努力在我看来都是可疑的.