整理一下技术路线

一、软件开发技术

1）服务器端

在最近5年内，Java还是主流，不光是因为当前的普及程度和遗留系统问题，而且除Microsoft几乎所有大公司都投资到Java上面的原因，此外开源也是一股无法忽略的力量：除了Java方面的开源框架在推动Java，也有Linux在带动java企业应用在普及（别忘记dotnet只能在 Windows Server上面运行）

dotnet有自己的优势，但是在五年内无法和Java取得均势，不光是因为Java普及带来的优势，也不光因为开源界对java的推动，也不光因为其他大公司在java上面的投资，而是很多公司的行业性质决定了dotnet的出局，例如电信行业，金融行业，电子政务行业等等，是根本没有可能采用 dotnet的。

Python和Ruby算不上后起，但是很有竞争实力，不过基于上面的原因，仍然不能成为主流。

在Java服务器端技术中，清晰的分为两条路线：高端的商业路线，这条路线是EJB3，J2EE5.0；低端的开源路线，这条路线是Hibernate， Spring。这两条路线也有重叠的地方，例如开源的Struts几乎成为J2EE Web层的标准，开源的Hibernate奠定了EJB3的基础。但是划分路线不是基于技术上的区别，而是基于商业运作上的区别。注重技术支持和商业服务的公司会选择前者，注重成本控制和选择自由的公司会选择后者。

商业路线的技术方案是：EJB3＋Struts；
开源路线的技术方案是：Spring＋Hibernate＋Struts/Webwork

Struts是一个很成功的开源框架，它的地位短期内还无法动摇，JavaEye有一项使命，就是动摇Struts在Java Web领域的地位，把它赶下王座，把Webwork扶上位！

商业的Web层技术，JSTL算是一个不错的东西，但是和灵活的模板语言如FreeMarker相比，却有很大的差距。JSF基本上是一个没有前途的东西。商业Web层技术因为一直没有出现好的应用，这样也导致了Struts的上位。

服务器端业务层和持久层框架，我非常看好EJB3，原因也不用多谈了，从商业上来说，需要这样一个东西，跨国公司们也需要这样一个产品来卖，来取代糟糕的 EJB2。开源的方案里面，Spring＋Hibenrate是一个很好的商业方案的开源替代，他们不存在很直接的竞争，而是一个互补的关系。这里比较尴尬的反而是JDO：JDO是商业产品（目前没有好的开源实现），造成开源应用不会对它感兴趣，JDO没有一个像EJB容器那样的脱管环境，造成商业方案对它不感兴趣。不过有了JDO，我觉得是对EJB3，对Hibernate形成一个良好的竞争环境，这一点是非常有利的。

2）客户端技术

准确的说是RIA应用。虽然我前面对XAML进行了正面的评价，但是我认为我前面有些结论给错了。经过这段时间，我觉得，XAML即时在多年之后，也未必能够成为一个非常成功的解决方案。道理很二：

1、XAML会带来比ActiveX更严重的安全性问题。
XAML本质上就是一个本地应用程序，虽然号称可以在IE浏览器里面运行，但IE就是一个皮而已，XAML应用具备对本地资源完全的访问能力（就算IE限制也没有用，IE限制就丧失功能，那样的话，功能并不会比Javascript来得更多；不限制的话，就为所欲为了），因此只要IE具备了运行XAML的能力，黑客将可以非常轻易的通过IE进行入侵，这仅仅需要引导用户在不知不觉中访问一个恶意的网页就搞定了！用户必须面临选择：要么禁止IE对XAML的运行能力，要么接受随时被攻击的危险。

2、XAML应用本质上也是RIA应用，因此必须进行大量的RPC调用
当前XAML采用XML Web Services进行通讯，这是一种低效的RPC。当前的XAML案例中并没有注意到RPC领域，实际上根据我现在做RIA的体验来说，RPC绝对不是一个简单的事情，要考虑的问题非常多。

从当前的阶段来说，最实际可用的方案有两个：

1、AJAX
实际上就是基于XMLHTTP的JS异步交互，这个东西已经出现很多年了，最近随着Google应用和Sun Blueprint的推出开始火热。我原来对这个东西持否定态度，但是后来转变了。我原来否定态度的一个前提就是：XMLHTTP缺乏成熟的组件库！但是没有想到的是，现在XMLHTTP从去年下半年开始，如雨后春笋般冒出来。AJAX应用最大的好处就是充分利用现有资源，我认为应成为RIA应用的首选。

2、Flash
Flash的优势也很明显，强大的AS支持，强大的组件可视化设计，强大的交互能力和很炫的用户体验，并且Flash Remoting也已经非常成熟了。Flash的缺点就是Flash虽然嵌入网页，但是和网页没有数据交互能力，Flash另一个缺点就是不适合处理大量文本内容（HTML最适合）。现在有些人开始滥用Flash了。

因此比较好的方式可能是两种混用，一般不过度复杂的交互交给AJAX，非常复杂，甚至需要托拽操作的，交给Flash。

总结一下：

软件开发领域服务器端技术Java是主流，两个技术路线，一个是EJB3，一个是Spring＋Hibernate，此外iBATIS也有一席之地；客户端技术就是AJAX和Flash。

二、数据库技术

基本上格局不会发生多大变化，Oracle还是高高在上，SQL Server进一步蚕食NT平台其他数据库的领地。开源方面，MySQL将一枝独秀，但是开源数据库在很多方面还是和商业数据库有无法拉近的巨大差距。这也使得商业数据库的地位不可替代。我会比较关注Oracle，MySQL这两个数据库。面向对象数据库仍然不会有什么起色。

三、桌面编程技术

我还是相信一点，对于桌面应用来说，本地代码的位置永远无法被取代，所以我总觉得XAML那样的东西效率实在很成问题。Longhorn要像成熟，也不是第一个版本就可以达到的。当前桌面应用开发技术，还是首推Delphi，不过我觉得Python是后起之秀，非常有可能在未来取代Delphi。

初探在下一代 Windows 中编写和部署应用程序
http://www.microsoft.com/china/MSDN/library/windev/longhorn/DevelopAppLonghorn.mspx

首先，以Microsoft公司的实力和Windows操作系统的占有率来说，Longhorn迟早会被普及，而XAML的开发方式也有可能普及的。记得当初WindowsXP刚出来的时候，因为资源占用率和新的激活制度招致一片骂声，但是慢慢的，现在也都接受了下来。由此可以推断，Longhorn以其更加丰富的桌面功能和诱人的外观，会在将来成为主流。

但是Longhorn什么时候才会全面普及，这是很值得琢磨的问题。WindowsXP是2001年推出的，在随后的几年，Microsoft采用了一些商业手段来迫使用户升级，例如企图取消Windows98的技术支持，不再提供WindowsNT技术支持，不再销售 WindowsNT/Windows98，将Windows2000保持在一个比较高的售价的同时，对WindowsXP推出优惠价格，让 WindowsXP的售价低于Windows2000等等手段。但是直到现在，Windows2000仍然占据了非常高的份额，据我个人的观察是比 WindowsXP略高。按照这种情况来推断，Longhorn要普及，恐怕难度更大，非常多的用户现在仍然是Windows2000的死忠派， WindowsXP推广了四年还未能超过Windows2000，那么Longhorn究竟要几年才能超过WindowsXP呢？我估计四年以上是起码的。

XAML应用程序不同以往，它只能跑在Longhorn上面，甚至比Java和dotnet要求更严格，后者仅仅下载安装一个运行环境就可以了，但是前者要求你必须更新操作系统。XAML在IE浏览器中运行虽然肯定是下一代RIA的主流，但是不可忽视的问题是，只要Longhorn没有彻底淘汰 Windows2000/XP，软件开发商和网站开发商就不敢大面积采用XAML。而根据我的观察，现在企业中，Windows98仍有少部分市场份额。因此Longhorn必须要等待到彻底的，毫不残留的淘汰Windows98，Windows2000，WindowsXP之后，才会全面普及，而在此之前，不得不经历一个漫长的过渡期。

就好像现在，假设你开发桌面应用程序，你敢只针对WindowsXP开发吗？而彻底不支持98和2000吗？我想，没有哪个软件开发商敢这样做。除非 Windows2000几乎被彻底淘汰了，你才敢这样做，但是WindowsXP已经推出四年了，还没有Windows2000占用率高，哪全面淘汰究竟要几年呢？再看看现在dotnet winforms应用，推出也已经五年时间了，但是到现在仍然没有普及开来，根本的原因就是Windows2000/WindowsXP没有预装 dotnet framework。仅仅是需要打包安装一个运行环境就使得winforms五年都推广不了，更何况要求你升级操作系统呢？

我个人的估计是，假设2006年Longhorn如期上市，那么将需要7-9年时间来彻底淘汰Windows2000/WindowsXP。 Longhorm上面XAML应用的初步普及也至少需要4-5年时间以后才会有软件开发商大量去做（想向dotnet是2000年开始宣传和推广的，到 2004年开始普及，今年和明年才会全面普及)。因此，基于XAML应用的普及可能是在2010年以后！上面的估计中还没有包括MacOS 和Linux在桌面会否有什么表现。

先说说服务器端吧：

从可预见的未来来看，服务器和客户端TCP通讯的主流方式一定是HTTP协议（即时通讯软件走UDP端口，不在讨论范围）。在基于HTTP协议之上，又分为两类：一类是SOAP协议，异构系统支持良好，但是性能很差，目前Microsoft很喜欢用这种方式；一类是轻量级二进制协议，例如Flash的 AMF协议，Resin的Hessian协议。值得一提的是，不管哪种方式，他们都支持异构的系统，所以完全可用在客户端采用dotnet，在服务器端采用Java或者Python。因此，XAML的流行不会对服务器端技术产生致命的影响（肯定会提高dotnet的服务器的市场份额）。所以我们可用抛开客户端影响，单独来看服务器端技术：

1、Java
Java是当前服务器端技术当之无愧的王者，在未来五年内，也不会有任何动摇（受到dotnet和python的影响，市场份额会下降一些）。Java特别有利的一点是，现在有太多的现存系统基于Java，这些系统都不会轻易迁移到其他平台上。另外还有一个决定因素是除了Microsoft之外的几乎全部 IT大公司都在Java方面的投资巨大，放弃Java对他们来说也意味着沉重的打击，甚至毁灭性的打击。这些公司可以列很长很长，IBM，HP， Oracle，SAP，Sun，BEA，Macromedia等等。

2、dotnet
由于Microsoft的影响力，dotnet会成为为仅次于Java的第二大服务器端技术，但是Microsoft有一个隐忧，就是Linux操作系统在服务器端的高速成长。虽然现在Linux在整个服务器端市场的出货量只有13%左右，但是成长率惊人，根据我看到的资料显示，到2008年，将占据 25%以上的市场份额。考虑到很多公司是自己安装Linux，因此不会被硬件服务器厂商统计进来，因此Linux的服务器端的市场份额应该比25%高一些。并且现在主要的服务器厂商都对Linux有非常巨大的投入和支持，这些公司包括IBM，HP，Dell（只有Sun不支持），因此Linux在未来会对Windows在服务器端的市场构成最严重的威胁。

不要忘记dotnet只能在Windows平台上面跑，虽然有mono，但是你不可能移植MTS，COM+，SQL Server etc。所以只要Linux在服务器市场对Windows构成持续的威胁，dotnet就不可能超过Java，Java的地位还是稳稳的老大。从某种程度上来说，Java的命运是和Linux联系在一起的，只要Linux在服务器端不输于Windows，Java就稳稳压制dotnet。

BTW:从未来来看，Linux和Windows会在低端和中端服务器市场成为主要竞争对手，由于各自都有其不可替代性，所以双方都不可能彻底消灭对方，最大的可能性是Linux和Windows平分市场，或者Windows市场份额略高一点。

3、Python
我个人认为Python会成长为第三大服务器端技术，Python成长于开源，但是又有商业公司来商业运作，并且背后还有大公司的支持，在欧洲普及的非常好。当然最重要的原因是我觉得Python在技术上非常先进，并且技术发展方向上比较统一，不会出现Java那种吵架的事情。

4、PHP
PHP这东西是不错，Yahoo也在用，IBM现在也对他感兴趣，但是我还是要说PHP没有太广阔的前途，原因很简单，PHP没有服务端中间件，例如 Java有App Server，dotnet有IIS/MTS，Python有Zope，但是PHP他就是一个脚本，没有自己的中间件就是致命问题。Yahoo用PHP有其特定的原因，主要是从原先自己的技术迁移到PHP很方便，而IBM支持PHP，显然醉翁之意不在酒，IBM意不在推广PHP，而在于争取到那些使用 PHP的商业大客户们，向他们卖服务。

BTW：感觉欧洲用Python/PHP的很多，似乎开源在欧洲非常深入人心。

从服务器端技术来说，Java还是我们最需要下功夫去学习和掌握的，此外，我会比较倾向于钻研和应用Python，而不是dotnet。原因也很简单，跟随Micorsoft的技术会很辛苦，Microsoft产生的新概念多，他总是会猛的推出n多种技术，然后让他们在市场上自己生存，最后根据市场反馈，无情的抛弃某些东西，大力推进有市场前景的东西，这样的例子太多了，举不胜举了。我的感觉就是这种方式会让Microsft经过市场尝试在技术竞争中筛选最优秀的技术，但是对于Microsoft技术的跟随者来说，未免有点太不公平，整天吭哧吭哧被Microsoft拿来当免费的试验品来用。我特别不理解的是MSDN宇宙版，Microsoft总是把无穷无尽的文档灌给你，让你永远学不完，但实际上我真的不需要那么多概念，我只需要能够很好的完成我工作的技术，并且这个技术可以持续的完善就好了。而不是今天给我这样一个东西，明天灌给我无穷的文档，后天当我用顺手以后，又告诉我这东西作废了，你给我重新学习新东西，然后又是无穷的文档，总之很恼火。

所以就是：重点学习Java，有时间去学习Python，保持对dotnet的关注即可。


客户端：

前面说了那么多XAML的东西，都是和这有关，七年以后肯定是XAML的天下，但是五到七年之内还不是：

1、Java
Java在客户端真的是扶不起的阿斗，这都怪Sun。Sun造就了Java的成功，又一手毁了Java在客户端的市场。那些个Swing和SWT的死忠团也不要和我争什么，我也懒得和你们争，你们觉得好就好吧，道不同不相与谋，你觉得好你就用你的，我觉得不好我就用别的。用不着缠着我非逼我说Java做客户端好，没必要，况且就算你逼我承认又怎样？我就是玉皇大帝金口玉言了？得到我的承认，Java就有前途了？我好像还没有那么大本领吧？就是IBM， Sun也没有那么大本领，所以好不好也不是我说了算，用不着逼我。

2、dotnet winforms
由于Windows2000/WindowsXP不带dotnet CLR，所以winforms一直没有能够普及得很好，等Longhorn一出来，又变成了XAML了，winforms又被淘汰了，所以 winforms的地位特别尴尬，但是在这5-7年中，你想开发既能够在Windows2000/WindowsXP，又能够在Longhorn上面跑的桌面程序，winforms好像又是Microsoft技术中最好的选择。所以只好一直尴尬下去。

3、VC，VB
dotnet出来以后就开始尴尬了，说用吧，好像很落伍了，都dotnet时代了，说不用吧，又没有好的替代品，现阶段开发桌面程序，还真得不得不用，而且还挺好用的。所以VC6SP5，VB6的死忠团也比较多。

4、Delphi
dotnet出来以后Borland就开始跟风了，这一跟风，连老本都跟没有了。未来的XAML时代，我也不知道Borland怎样找自己的定位，但不管怎么说，从历史来看，本地代码的应用程序永远有它一席之地！就算XAML又如何如何做得漂亮了，关键的地方，和特定资源处理相关的部分，还是本地代码的程序管用。你看VB出来多少年了，用VB开发的都是一些上层的项目级别的应用软件，一旦涉及产品领域，还是VC和Delphi管用。所以现在大家还是不得不用Delphi7阿。

BTW：XAML应用致力于快速开发项目级别的应用，特别是可以跑在IE浏览器里面的，因此是RIA的首选。但是毕竟也有很多不适合用RIA的场所，特别是例如我要备份某些文件，你用XAML？那性能就不用提了。所以Delphi如果好好发展VCL，封装Windows32 API，我觉得也是一条路，未必比现在跟随dotnet差。

5、Flash RIA
其实我觉得Flash不适合做RIA的，但是Flash普及率太高，XAML又离普及太遥远，而Flash现在就可以用了，所以是当前RIA的首选。不过我对Macromedia公司比较失望，如果Macromedia能够公布Flash实现细节，作为一个公开的标准向ISO提交，同时免费开源Flex，我敢说，Flash RIA会迅速普及的。等5-7年XAML的时代，由于Flash的市场占有率，XAML就未必能拼得过Flash。可惜的是Macromedia公司目光过于短浅，只知道赚眼前的小钱。

6、Python
这5-7年内，RIA应用和RCP应用不会统一，XAML才具备将RIA和RCP统一的实力。从这5-7年来看，Flash是RIA的首选，而RCP的首选，我要推荐Python。原因前面已经提过，简单总结一下：
1）wxWidgets是一个比MFC优雅的库，TortoiseCVS用wxWidges而不用MFC，就是因为wxWidgets好用，而不是为了可以移植。
2）Python的面向对象脚本语言编程适合快速界面开发
3）Python在服务器端和客户端都非常有前途，可以形成一个统一的解决方案，这一点明显比Java有优势
4）Python桌面应用程序可以完全编译为本地代码，脱离Python运行环境，这一点比dotnet winforms都有优势
5）Python可以不受限制的任意调用Windows32 API，所以凡是VC6可以做的事情，Python就可以做

试想一下，现在我们开发桌面应用程序有什么要求？
一、不要附带一个JRE或者CLR的累赘
二、可以快速开发
三、性能要有保证
四、方便的远程方法调用支持
此外如果能够跨平台就最好了

Java前三点都不符合；dotnet winforms不符合一；VC6不符合二和四，VB6不符合三和四；Delphi7符合前四点；Flash RIA不符合三；Python全部都符合！并且请记住Python是一个完全开源免费的方案！

客户端技术在这5-7年中，在RIA领域我会学习一下Flash，在RCP领域我会重点学习Python，此外会观望一下XAML。

Longhorn 的普及要十年,然后就消失了,然后有一个消息<Longhorn是MS最失败的产品>.

随着开发越来越走向平台无关性,像xaml这种东西会有前途吗?

随着开发人员越来越走向Linux开发,唉..这年头又少了一批人买windows了.

随着各东东越来越多东西有中间件,中间件又大部是夸平台的,唉....所以服务器更不会用windows了

Delphi 也可以跨平台吧？Kylix?
Python的问题，在于脚本相对于编译语言，在语法检查方面的欠缺。大规模代码管理上也许有难度。
XAML只是用来描述界面，Script也只是少部分交互功能。核心功能还是可以用C#写，编译为CLR指令发布吧。应该不会影响效率。
Dreamweaver MX几乎全是采用XML Menu + Script的方式。不是太慢。





如果RIA应用，的意义宽泛一些，不仅是指Browser，也包括其他internet web协议。那么这个理由不太充分。
本来XAML只是Winforms的另一种写法，和Delphi, VB, VC desktop 等一样。安全问题也一样。MS推行“桌面及浏览器”，本来就不鼓励在IE中使用XAML。
WebService RPC调用也是基于HTTP的文本协议，效率和访问HTML, Post Data差不多。当然比二进制协议效率低。假如XAML Desktop程序的XAML Skin & Data都是异步从internet获取。那么用户体验应该可以接受。

XAML的主要问题就是Robbin分析透彻的商业和市场因素。另外，还是在于跨平台。XAML只是winforms的XML描述。而Winforms是MS专利，不知道是否允许Mono移植。

我想，UI 的 XML化，远程通信协议的文本（XML + general script）化，是大势所趋。

Robbin另一篇Web Service的帖子。
http://forum.iteye.com/viewtopic.php?t=156

未来的Web Service，可能是脚本的天下。如Python, Ruby, JavaScript。
我觉得，JavaScript的可能性最好。因为在Client & Server端都可以运行。

JSTL的确有很多问题，但是JSF还是有余地的。
Tapestry是个很有意义的项目，JSF在这个方向上更有优势。
不过说句实话，javaeye是不是有点一叶障目？技术路线说了半天逃不出java,python,flash，where is c?

完了，一句话就否定了偶们公司的这三年，还有偶的这一年多的工作

为什么呀？广州这里确实有不少用dotnet做电子政务的。

这话说得恐怕有点过。Struts和WebWork，如果从足够近的距离来看，并不是完全vs的关系。这page controller模式和front controller模式还是各有用途。我同意Struts不好用，不过说WebWork来取代它，我不看好，这样的取代没有什么实质意义。

首先介绍下自己，我做了4年左右C/C++开发，最终产品主要都是在MS平台上。


Robbin这篇文章，很多地方有可以借鉴之处，比如有关Python。
不过对于初学者来说不是很好的建议。初学者和刚刚工作的人员是无法决定其采用什么平台，什么语言或者什么技术的。如果有初学者或者刚刚参加工作不久的人，看了这篇文章之后想实际加以使用或者改变学习方向的话，那么也要在空余时间搞，不够如果自己喜欢的技术和在工作上用不上，估计会去换工作吧 。题外话到此。

我觉得dotnet编写服务器端应用是一个不错的选择。

本来就是这本来就是个Java社区，怎么又来了个C？要C的，可以去C社区嘛。