原文: http://blog.csdn.net/david_lv/archive/2009/03/12/3982606.aspx
我关注Google的代码托管、Open API，我也关注sun会把MYSQL怎么样云数据库化，我也虚拟化技术多实例化独立的数据库，我也关注facebook的平台插件应用架构，我也关注salesforce的在线开发语言和调试环境，我也关注javascript和XML组成的客户端UI，落地为flex或sliverlight或其他什么Ext js或JQuery或YUI或Dojo之类。
从大型主机到个人电脑，从个人电脑到局域网，从局域网到wi-fi、笔记本电脑，甚至到如今的比笔记本更小更廉价的上网本，手机GPRS上网，手机WI-FI上网，手机上QQ/MSN，手机收发邮件，手机GPS地图导航。
未来什么样？
未来是每人手拿一部手机，可以随时上网看新闻看天涯看博客、看小说、聊天、玩网络游戏、搜索地图、搜索餐馆、搜索打折优惠活动、搜索好玩的好休闲的去处、随时随地上网淘宝当当红孩子购物、拍照片随时传到自己的blog上可以第一时间分享给朋友们。
手机上网速度越来越快，屏幕内存也越来越大拍照也越来越清晰，手机的价格也越来越低，手机的上网费用也越来越低。除非我们是搞开发的，需要装数据库装开发工具；除非我们是搞项目方案的，PPT/DOC/EXCLE/PROJECT熬夜制作幻灯演示，其实手机已经可以代替电脑了。电脑从大壳子PC到液晶屏电脑到笔记本电脑到上网本，越来越小，以后就是手机了。
人手一部可上网冲浪休闲娱乐简单办公的手机，这么个小终端，虽然可以拥有1G的扩展卡，越来越大内存越来越大的屏幕越来越快的CPU，但仍然手机、上网本、笔记本电脑、PC、服务器同时存在，就如同我们既买可以800万像素拍照的山寨手机，我们仍然会专门买数码相机。
既然PSP能联网和世界上某个角落的人一起对战，那么把数码相机的照片在大海边抓拍好，也可以直接直接发到网上个人空间或自己的朋友一起分享。
互联网，不可避免的走入了手机为终端云计算为服务器的潮流，就如同PC和服务器的关系一样。互联网就是个虚拟的大计算机，连入互联网的每个网站都是这个虚拟超级计算机的一个运算零件，每个网站的功能通过URL之间互相调用，每个应用都公布出自己的Open API，以便让其他网站的应用进行调用，这就是SOA。
3G在中国的普及，会是5年，就如同中国1999年北京买手机还必须是北京户口BP机还满街，2002年移动和联通的手机短信还不互通，2003年短信业务就爆发一样，5年不到，尤其当年的手机还都在4000元以上。而如今，遍地手机，中国从工人到农民到中学生都接受了手机，所以中国的3G发展会更快。
而云计算，也是5年的时间，从如今的大混战互相指责谁是伪云计算，谁是虚拟化技术，谁谁不安全了。这不重要。5年后，大量应用都在网上了，大量的数据也自然都随着应用在网上了，提这些没有啥意义，因为事实上就是那样了，就是手机+云的模式了。云时代开始了，和局域网时代一样颇具意义。
有Google这样的云文件系统，有Mysql这样的云关系型数据库，有salesforce这样的云应用开发，现在没有一款开发工具和开发语言是原生在云上的，salesforce有这个潜质。javascript+XML+HTML成为UI表现的标配。AJAX利用HTTP的POST和GET打通了数据的上与下，其设计哲学比WebService，比SOA还更加开放与简单。
我倒是不看好salesforce这样的封闭应用业务开发平台，这是10多年前的业务开发思路，但是我看到国内许多做SaaS和做业务开发平台的，还在这条路上走，而且还有许多没有做过业务平台的公司都期望拥有一个这样的平台。其实，这些想法全都错了。
正确的想法，应该是类似facebook这样的插件平台。大家也玩过国内的海内、校内、开心等等SNS网站，他们现在不断的开放API，并且有大量的实用应用产生和休闲游戏学习软件产生，大家可以选择自己喜欢的应用去使用，这才是正确的SaaS平台架构思路。阿里现在走的就是这条路。谁还在规定必须使用YUI，使用SOA，使用什么AOP框架，使用什么指定的持久化框架，使用什么样的开发语言，必须要维护什么实体表，必须要维护字段列表，这样的业务平台架构早就落后了。
十多年，在企业信息化领域做架构的架构师们早就实践、讨论、思考了N多种方式，从代码生成器到甚至自己开发一个IDE，到UI控件+组织结构权限+表单设计器+流程设计器+报表设计器，各种思路的应有尽有。有的可随便换数据库，有的可生成各种代码的，JAVA的,.net的都可以生成代码，开源的就有PHP+MYSQL的。但做到头，大家评估了各种方案，都是各有利弊，没有一个综合出来一个稍能前进一些的业务平台。其实，本身，这种思路就错了。限制太多，倒是可以快速开发了，甚至是傻瓜配置就可以，但限制太多了，想下去的时候下不去。如果有IDE开发工具，可以写代码，可以UI设计，那岂不是要和Eclipse竞争。
说起要和Eclipse竞争，很多做业务平台的都不约而同选择了Eclipse平台作为定制。因为Eclipse免费、开放源代码、而且良好的插件体系，可以改造。如果过去没有Eclipse，大家都要费好大力气自己做一个IDE，要知道，做IDE，全世界打听打听有多难。
但是，很遗憾的说，尽管做了这么多，但方向确实是错的。当年企业管理软件的鼻祖SAP，当时是一穷二白呀，没有办法啊，只好自己从头到尾从上到下都自己开发。毕竟，SAP面临的客户，都是UNIX、LINUX和WINDOWS都混用的主儿，各种遗留系统和IT资产都有，各种数据库都有。所以SAP没有办法，为了只维护一套代码，SAP必须自己开发自己标准的UI元素，开发适合各个平台都能跑的代码，而这个代码想在各个平台上跑，只能是虚拟机技术，唉，可怜这个做企业管理软件的孩子啊，还得自己研究开发虚拟机，JAVA出世太晚啊。有了虚拟机，有了自己的开发语言，就需要有自己的开发IDE，SAP为了各种数据库都能访问，还得做自己的数据库持久层，更得创造如今在.NET上才有的LINQ技术。累死累活的，SAP开发了这么一套平台。没有办法啊，当时什么也没有，只能自己干。
好容易开发出来了，基于这个平台开发出了各行各业的应用模块，然后不断实施、支持、升级、增强，SAP R3终于在世界上闯出了一番名堂。
但很不幸，各种技术都出来了，而且还是免费开源。JAVA、ECLIPSE、中间件、JBOSS、Hibernate、FLEX。SAP大叫一声不好，落后了。但没有办法，R3正是黄金收割期，耕耘了那么多年必须把这头现金牛得挤出最后一滴奶啊。但是，R3由于应对各种EAI技术、WEB运行需求，被改造的庞大无比，从根基上来说就是无法转型了，所以SAP看着ORACEL带着JAVA写的ORACLE管理软件+ORACLE数据库一路前进，自己只能靠R3来支撑。还必须说自己最成熟最稳定，成功案例最多业务最细致最实用，世界500强的业务都在SAP上运行。如果客户想改，一是要价高（主要是R3多年累积，修改已经不太容易了，而且SAP人员确实薪水高），二是自己代表最先进的（？？什么是最先进的。现在有句话叫最国际化的就是最本土化的），世界500强都用了，你这个客户现在还不是500强，就得向500强学习。
再说了，SAP自己也只是开发一个平台，然后在平台上开发一套标准的ERP应用，很多细致业务功能，各行各业的差异定制，并不是SAP在做。SAP不是一个人在战斗。
SAP是把软件销售、软件定制开发、软件实施培训、软件服务支持都拆开了分给了合作伙伴。什么HP、EDS、IBM、德勤、埃森哲等等等等。SAP来个四六开，你六我四。如果没有这些合作伙伴，有100个SAP也得累死还不赚钱。
是的，SAP是全世界企业管理软件的鼻祖与老大。SAP走入现今这个模式，必然有它的历史上的痛苦的各条路的尝试经历。这个盈利规模、这个利润增长规模、这个业务收入增长速度，我们都看在了眼里。所以，想想我们这些还在以SAP为标杆者的我们。
还有一些公司开发一个平台然后一家家的自己卖给最终客户，还有一些公司开发一个平台卖给其他的开发公司。还有一些公司自己本身有一套平台但就是开发自己的行业应用。
有人希望平台能够不写代码，实施人员画好业务流程图画好输入表单样式画好报表格式，管理软件就能跑起来。有人希望平台能够写代码。有人希望平台能够只写JAVASCRIPT和SQL这些动态的东西，可以不用IDE不用编译就能修改业务功能。有人说SAP的平台很好，可以满足快速低成本的定制化开发。但是，事实真的是这样吗？SAP有自己的开发语言，自己的IDE、自己的SQL语法，有自己的UI元素，有自己的业务实体设计器、表单设计器、报表设计器，即使现在用JAVA新开发了NETWAVER平台，大量用了开源项目，但想扔开开发人员，找个懂业务的人培训好了就自己画流程图做管理软件去了，这都是白瞎的想法。
SAP真的最懂各行各业的业务管理吗？还是那些SAP的合作伙伴最懂各行各业的业务管理？
SAP是个卖平台的公司呢？还是个卖企业管理软件的公司呢？但是，至少SAP人家自己还自己扎扎实实做一套ERP来做这个平台的案例和样本。我们国内一些小公司，自己做个简单OA，就说自己的平台从ERP到CRM到SCRM，什么都能开发。
什么都能，就意味着什么都不能。
还有一个值得大家注意的是：业务流程、工作流、程序流，是三个不同的事情。现在还没有一个统一的方法论把这三者统一看待在一起。但这三者其实是一件事物的不同侧面，但如果想单一的用某个方法表现这件事物，会都有缺憾。现在就缺乏这个统一的方法论，但是时候不到。就如同如果没有前人的大量积累，是不可能出现《物种起源》、《牛顿力学》、《相对论》这三大体系的。这三个体系都在自己的专业内统一了大部分的分支理论，都能解释。而现在在商业信息化方面，这个方法论还没有。
虽然，各大巨头，尤其SAP和IBM，一直在致力推动SOA、BPEL。希望世界上都有无法的小应用，然后用BPEL按照一定的流程顺序调用接口执行。这是多么美好的组件世界，我们不正梦寐以求这种时代吗？
但是，但是，人怕但是。BPEL，严格来说，是在程序流的这面上企图描述业务流。但归根到底，还偏向于程序流，是为了把SAO组件的接口串联在一起。我过去对BPEL用XML来描述非常恼火，因为没有UI工具，我看得头大的很，难道让我修改业务流程必须用UI界面吗？我非常希望用JAVASCRIPT来整合调用接口，就如同Mashups一样多简单。我曾经和普元的朋友还一起争论这个事情。但事后我也想了想，是啊，国际巨头众口难调，都各自都有各自的利益，如果出一个SCRIPT的脚本语言来串联调用SOA组件，那么这个脚本语言就要讨论N年了。君不见现在ActiveScirpt和微软的Script大战，浏览器不兼容的大战，背后其实都是利益。为了避免又被讨论N年，所以索性是XML，语义语法你自己拿XST/XTD/DOM自己扩展去。真正的四海一家解决之道。
听过IBM和各大巨头也正在研究这个统一的方法论，从BPM到BPEL到WORKFLOW，怎么统一起来成事务的三面性成为立体的。但这个方法论不可能如大家所愿比较早的出来。
SOA的大混战才在概念层面刚刚打完仗，在客户层面还没有多少落实，投入了那么多怎么不要产出呢？所以，必须等这一代SOA赚的盆满钵满的时候，新一代的SOA才会推出。至少在7-10年之后。因为，这是一代企业管理软件的最短生命周期。直到那个年头后，新一代SOA推出后，巨头们才会说：啊呀，过去我们所做的还不够完美，大家走了很多弯路，现在我们终于找到一条更先进的路了。
但是，10年以后世界会有哪些新变化会出现什么新生事物，谁又能预料得到呢？谁想等10年后完美了才去做？他如果10年后不出来那岂不是黄瓜菜都凉了？
所以，能干点吗就干点吗。
总结:
1 在这篇文章中我说了5年后的3G手机和云计算时代会来临。在这个环境下作些什么该有前途，大家好好想想。
2 仔细关注一下云开发平台，Google的代码托管、Google的Open API\AJAX\ATOM APP\REST\HTTP POST
3 我个人感觉现在的SaaS架构和业务平台的方向就不对，建议关注一下facebook的架构，或者搜狐BLOG的架构
4 我个人感觉现在的SOA、BPEL缺乏统一的方法论，关于这个统一的方法论的思考，我会专门再给大家贴一篇文章。