关于AJAX构架的一点构想

以前搞了一个XPP的编程平台，应该来说，不是一个成功的东东。XPP本身确实解决了目前编程的诸多问题，例如页面状态保持、统一的界面风格、良好的数据效验器，但并没有考虑到数据传输的问题，虽然采用了压缩流来传递数据，但同样也增加了服务器的压力。也许对于中小型的企业应用，XPP可以作为一个被选的平台，但作为大型的企业应用，XPP表现恐怕很难实用。
在有了上次失败的经历后，考虑是否可以采用AJAX作为一个轻量级的框架(XPP的体系太过庞杂，过多在服务端考虑了前端的UI逻辑，也是这才是失败的根本)，侧重于业务逻辑层的调用，不再考虑UI层的逻辑。
AJAX主要实现的主要技术:
1、XmlHttpRequest
主要考虑是否需要支持浏览器的差异性，目前至少提供对IE和Mozilla的支持，以后是否考虑对其他浏览器进行支持？
这是是个很easy的问题，暂时不进行深入探索。

2、XML数据传输层的封装(AJAX的核心)
AJAX的核心数据传递毫无疑问只能是基于XML的，如何有效地对XML数据输送层进行封装，来保证构架良好的可用性和扩展性？这里主要是需要考虑两个方面：良好的封装性和执行效率。
我初步的想法是服务端采用类似buffalo的技术实现JAVA POJO与XML的序列化，客户端采用js实现类封装实现JAVA对象的映射(考虑采用服务器端自动生成js文件，并动态加载js对象，以提高浏览器的处理能力)，并在此基础上实现XML-PRC。

3、服务端集成
考虑AJAX与其它架构集成的方案，并保证系统良好的安全性和执行效率。

暂时处于疑问中的几个问题：
1、UI层如何表现？
采用AJAX的话，是采用js构建页面还是采用XmlHttp获取服务端返回的页面信息？

2、数据效验问题？
对于AJAX作RIA的应用，UI层的数据效验肯定是必要的，由于采用AJAX，用户绕过UI效验是很容易的事情，如果在服务端同样做数据效验的话，是否会增加代码的编写工作量？是否能够采用统一的数据效验？如何可以的话，如何实现？

目前buffalo主要有如下问题：
a. JAVA Object的序列化逻辑与RPC的业务逻辑混在一起，不利于系统的扩展
b. buffalo只支持UTF-8编码的XML，不支持GBK编码的XML
c. buffalo可以调用服务的所有方法，可能会对服务器产生一定的安全隐患