【IT168 技术文档】

　　这几天，我先是否定了基于JS+XMLHTTP为核心的浏览器端解决方案，接着又给Javascript的前途判了死刑，搞得一批Javascript/XMLHTTP的死忠份子十分的不爽和反感，其实我一点都不反对Javascript/XMLHTTP，我也一直在寻找比较好的解决方案，当然现阶段，我是不可能找到满意的方案的，否则的话，表示层早就像IoC容器，ORM那样主流观点都统一到一起去了。因为没有满意的方案，所以大家五花八门，所谓八仙过海，各显神通，各有各的绝招，所以呢，如果我不同意你的解决方案，无损于你的形象，大可不必心里郁闷着。

　　既然现阶段各方案各有利弊，无法统一观点，那我就不谈了，只谈谈未来比较有希望的技术，如果对未来技术发展趋势不感兴趣，对我的清谈不感冒，只对满足客户需求感兴趣的，满意于现阶段解决方案的大可不必往下看了。

　　众所周之，大家比较看好的未来的表示层客户端技术大概就是XAML和Flex了。但是其实这两种技术我都不懂，XAML还算看了一些MSDN上面的资料，Flex完全就是门外汉了，有人说，你什么都不懂，你还敢大言不惭的预测？ 前面有朋友我说的技术直觉还不错，既然还有人相信我的技术直觉，我就硬着头皮预测预测了。

　　客户端解决方案能否成为主流，取决于两大因素：

　　1、技术本身能够真正解决问题并且技术门槛足够底能够迅速普及，这是必要条件
　　2、这种技术必须得到桌面操作系统和浏览器的充分支持，这是充分条件

　　要成为主流，必须既满足必要条件，也要满足充分条件，就是充分必要才行。先看看XAML，它满足充分条件，但是能否满足必要条件有待观察，不过从我们对MS公司过去案例的分析来看，他满足必要条件的可能性非常之大。

　　Flex在充分条件和必要条件两个方面都有待观察，不过Flex可能相比XAML的唯一优势就是Flex支持多种服务器端技术，这比单纯支持MS技术的XAML要更讨反MS阵营的喜好，如果没有IBM/Sun/Oracle/BEA等J2EE阵营的联手支持，Flex就很难成为主流。

　　所以未来的主流最可能的还就是XAML。那么基于这种预测，来看看J2EE阵营应该怎么应变？XAML通过XML Web Services和服务器端通讯，对于未来的Rich Client来说，业务逻辑不会放在本地，还是在服务器端，所以主要的业务还是在服务器端跑，既然XAML必须走HTTP协议，使用Web Services，那么J2EE来做XAML的服务器端从理论上来说也是完全可行，我甚至已经可以想像到Borland这种骑墙份子肯定会做出来连接两种技术的工具。

　　但是不会有很多公司做这种费力不讨好的事情，本来可以用一种技术解决问题的，非要人为的用两种技术粘合起来去搞，不是自讨苦吃？相信除了少数特殊情况，例如陈旧系统的改造之类，大部分采用了XAML客户端方案的公司一定会投奔dotnet而去。

　　MS确实比较狠，从低端的垄断慢慢往高端蚕食，那是不是J2EE必死呢？这却未必。J2EE阵营有三条路可以走：

　　1、改造J2SE，使之往兼容XAML客户端的路子上面走

　　谁都知道Java的客户端难用，既然MS已经给J2EE阵营指了条Desktop的路子走，J2EE跟着兼容是肯定没跑的。这样虽然被动些，但是不至于被慢慢抛弃了，不失为上策。

　　2、封装Swing，提供一个良好的Desktop Application框架

　　现阶段开发Java桌面应用是比较麻烦的，但是也不是不能做，特别是很多成功的应用证明了用Java做桌面应用程序完全是可行的，如果能够有一套完整的，高效的Desktop Application框架，提高桌面应用程序开发效率，降低桌面应用程序开发门槛，那么J2EE即使在XAML时代，也可以占据一席之地。

　　现在这方面的框架我知道的有两个：一个是SpringFramework的 Spring Rich Client Project；一个是Eclipse的Rich Client Project。随着未来Linux操作系统在桌面占据一席之地，以及MacOS据守的桌面一角，这种支持跨平台的RCP仍然会成为一种非常好的解决方案。

　　可以想像使用RCP做桌面应用程序，处理和用户的交互，然后通过Hessian/Burlap/SOAP和服务器端业务逻辑通讯，这种方式完全可以对抗XAML。这是中策。

　　3、J2EE阵营联合起来力推Flex，共同对抗XAML

　　J2EE阵营能否联合起来这只是一个美丽的幻想，因此是下策


　　其实说了那么多，最后说说我对当前这么多客户端解决方案的倾向性问题：

　　1）HTML为主，Javascript为辅

　　这种方式是大部分人采用的，也是我默认的方案

　　2）XMLHTTP为核心，Javascript驱动

　　这种方式少部分有技术积累的公司采用，但是我认为不具备大规模推广使用的可能

　　3）Activex

　　ActiveX往往也是方式1的辅助手段，也少碰到主要靠ActiveX驱动的，我只见国一个叫做“线线通”的在线游戏网站采用

　　4）Applet

　　这种方式往往被大公司广泛采用。如果有RCP的良好支持，我认为可以做为方式1的良好辅助

　　5）Flash

　　完全用Flash这种方式来驱动网站的我到见过不少，Javalobby也有一部分这样搞的，其实flash本质上也就是一个ActiveX，这种方式能否流行关键还是看能否得到广泛的支持

　　综上所述，我是会坚持采用方式1，即HTML为主，Javascript为辅的方式，并且会尝试在业务逻辑复杂的地方使用Applet/Flash来解决问题。

　　考虑到未来的可能性，其实我个人还是十分看好Spring的RCP项目的，也希望RCP项目的成功，通过Java Web Start来发布项目，使用RCP有效降低Desktop Application的开发成本，利用SpringFramework统一的解决方案，未始不会创造出来J2EE的一片新天地。