本人正在开发一个号称基于SOA的企业级应用开发架构，其间很多感慨，于是成文，用以记录。本文不是什么非常学术的研究文章，虽然我的身边几个博士在搞这方面的研究，并且还有一个博士后在搞这个方向，但本人理论水平却着实有限，于是涉及到很理论的东西还请大家到相关的BEA或IBM的相关专题查阅。
我设计的架构却是希望能够将SOA落到地面上。不过，美女走在T台上，看起来绚烂多姿，但可能走到你的面前却可能是瘢痕点点，让人感觉不过如是。也可能是我本人水平不够，不能理解真正SOA之精髓，故本文漏洞一定颇多，也就是抛砖引玉。
第一次听到SOA大概是2003年，Sun的几个架构师（其中据说包括Sun中国区的一个主架构）来我公司技术交流，实际是售前的把戏而已。其间言之凿凿地讲，Sun的所有产品今后都将向SOA转型。我当时正和J2EE血拼，哪里知道什么SOA，只觉得晦涩难懂不知所云。幸好有一个英文单词本人背的非常熟练，那就是“Google”。之后对SOA的概念有所了解，但感觉距离过于遥远，所以轻轻放下。
******SOA怎么了
前段时间去XXX公司（业内圈子小，不能乱说话）的中国研究中心，研讨SOA方向的内容，在座的多是各大国内公司的CTO，主持的是业内的那个国际性的老大。老大提供了一个国内（50强）企业SOA实施成功的实例，我等怀着无比仰慕的心情听完之后却发现与我等对SOA的理解截然不同，老大将该公司的几十个异构应用统统整合，使用的方法是全都推到，使用老大提供的全套解决方案重来之。我听过之后只有感慨，50强的公司就是有钱啊。
我曾经为一个世界50强的企业作过一个大概有1500万RMB的项目，其间要和该公司的大概5-6个其它应用结合（注意不是整合），该公司是不允许把那几个应用推到整合的，我想这也是很有代表性的应用。当时整合的办法就是直接操作数据库，不要惊讶，在具备相关资源的情况下这是非常地道有效的绝招。我想到了使用SOA，但是我遗憾的发现，SOA在这种情况下并不实用，首先其它几个应用的开发方不可能妥协在你的解决方案中（大家都是对手，怎么可能妥协），然后就是即使妥协，谁来搞接口的开发测试，费用谁出？？？于是乎就有了我们前面的方案。
此时回想，老大提供的整体的SOA的解决方案反而可能是SOA实施的最好方式。可是这种解决方式不是普通规模公司可以承受的，类似于企业实施ERP，完全是抽筋拔骨式的应用。那么，各个大的软件商一拥而上的搞SOA的基础是什么呢？
SOA就是面向服务的架构，一堆英文的缩写，一如既往地晦涩。
一次，我们一伙傻小子坐在酒桌上聊天，话题转移到SOA上大家一顿海谈，并多次为SOA干杯。问到我的时候我说：哥们认为，SOA，啊，A--，就是架构的意思，所以SOA一定是个架构层次上的东西，绝对不只是技术层面上的东西；至于各大公司在忽悠SOA有多厉害，那也是扯淡，架构上的东西就是架构上的，提不到忧国忧民那个层次。
我个人认为SOA实际上一种架构思想，它不是什么盈利模式。作为架构思想它应该能够从软件架构的各方面提供理论基础。
比如，XP极限编程，大家说这是一种开发方法，是因为XP的原则可以在软件开发的生命周期各个阶段提供方法支持，如果XP仅局限在什么结对编程、测试优先等方面，那它就谈不上是什么开发方法，而只能说是开发管理的一些技巧。
同样道理，谈SOA应该从架构层次上来谈，扩大或者缩小范围都是片面地。（哇，这种词语一写出来顿时觉得自己牛B了很多）。很多人觉得SOA很虚幻，认为不切实际；还有不少人认为SOA没什么，不就是Web Service调用一下没啥新东西。另外，在SOA的问题上有种有趣的现象，很多非技术的人（比如sales、偏管理的PM），上网看了些东西后，就大谈SOA，而且还头头是道，一方面说SOA门槛高，一方面又是大家都SOA，这也满奇怪的。
我在前文已经说了，本人就是干活的，理论水平有限的很，发这个文章纯粹是表达自己对SOA的理解，完全有可能是我从一开始理论就是错误的，大家当个笑话看也就成了；理论大师就不要找我辩论了。
SOA既然是架构上的东西，那么必然涉及到一个问题，什么是架构？？？……
架构是什么？
这是个好问题，关于架构的许多定义请朋友们自行google或者是baidu。我可以肯定的说你会看到非常抽象晦涩的理论，并且感觉像是在看玄幻小说。本人乃是彻底的无理论者，基本接近于无神论者。我总试图在晦涩的理论和具体实践中找到切合的地方，然后提升自己的理论水平。
所以有可能我阐述自己对架构的理解和您对架构的理解不同，ok，不要认为我是错的，或者是您是错的，因为在应用程序开发这个层面上，几乎不能肯定的说什么就是一定对，什么就是一定错，这也是应用程序开发的奇妙之处；我们经常遇到这个情况，几个所谓的高手在一起讨论一个内容的实现，讨论的不亦乐乎，争吵的面红耳赤，却谁也说服不了谁，就是因为没有绝对的对错，所以项目开发要有一个强有力的执行者，能够拍板，能够承担责任。
扯远了，接着说我对架构的理解，我个人认为，软件架构应该具备以下的几个要素：方法论、过程工具、技术框架，最后还有执行者。
方法论：从需求获得到设计到编码测试的全面的方法及过程控制理论。
过程工具：辅助开发各生命周期控制，并且能够贯穿全程的协同开发工具。
技术框架：实现架构的技术手段及元素设计。
基于上述的理解，我对SOA架构思想的理解也是上述三个方面：
方法论：拿需求来说：如何去面向服务的获取需求、需求分析，包括怎样从需求中抽取服务。如何面向服务设计开发、怎么保证SOA实现以及测试。更多内容可能过于抽象，而本人理论水平也确实有限，感兴趣的朋友还请自行google。
过程工具：能够将从需求到系统分析到编码测试等人的工作有机结合，全生命周期控制，包括开发工具，设计工具、测试工具等等。
技术框架：实现架构的技术手段。这个就是和程序员结合的比较紧密了。
实际上一个理想的架构应该可以是这样的：需求人员得到第一手需求后，分析员在工具的帮助下进行需求分析和设计，正确的抽取出服务和业务对象；然后工具生成一定的代码框架；设计师简单搞搞代码框架后指导程序员在开发平台上搞开发；之后工具协助测试及部署。整个流程在同一的平台下流转，所有文档、代码都是全生命周期。
而且，其实这个想一想有些太理想化了，几乎是不可能完成的计划。虽然有些老大已经搞出了这种成体系的平台，但是国内有多少公司在用呢？首先，买的起么；买得起(或者用盗版)又会使用么；就算你会使用，你的整个团队能用起来么？所以，如果你想使用这种平台来作开发，首先要买工具，然后还有要请老大们来帮助你实施。
实际上能够有能力在上述几个方面SOA的，除了业内的几个老大，别人都不具备这个能力。虽然我一直在为国内前30强的软件公司服务，但我也不认为国内能够真正出现完整的SOA的解决架构（甚至按照我的标准，国内就没有商品化的软件架构），其中主要原因应该是国内几乎找不到这样一个公司：肯为一个概念整体的投入一群人，来搞一个盈利水平未知的东西。
那我一个小小的个体又能做什么呢，又怎么敢号称要搞有中国特色的SOA呢？
什么是中国特色？
中国特色这个词极为有趣，简单说就是一切有利于垄断机构的做法就是中国特色，而垄断机构不想搞的就是国际惯例。比如，中国的油价，理论上，世界各地油价基本都差不多其实也是，油价基本等于当地的可乐价格。当然中国的可乐价格比较低，油价也比较低，但是中国的油价不包括养路费、保险，中国的公路还要收费，过桥也收钱，所以总的来说养车的成本比发达国家高多了，而发达国家的收入却比咱们高多了。我自从自己开了车之后就不喝可乐了，一喝嘴里就有汽油味。
回看中国的程序员，必须承认我们的程序员是非常牛的，看看简历就知道：C++？没问题；。Net？没问题，Java？更没问题，各种数据库也全精通。这只能说明一种浮躁的心态，这种心态也同样的反应到项目的实际开发中。
首先，我们没有自己的方法论！！！
主流的方法论无外乎面向过程、面向对象、和面向服务。这些有哪一种是中国人提出来的呢？
再次，我们没有自己的开发过程理论！！！
主流的过程控制有RUP、敏捷方法，这些也都是大胡子老外的成果。
然后我们在最容易实现的框架技术上也没有自己东西
想想吧，什么spring、hibernate、structs，什么是中国人的？
我们的程序员崇洋媚外达到了相当的程度，这个话题比较敏感，。不过大家想想，以极限编程为例，xp思想其实比较简单易于接受，但，如果xp是中国人提出来的，那会怎么样？我想只可能烟消云散连个水花都打不起来。国内其实也有很多不错的技术框架，但是我想不可能出现一种有广泛影响的，外来的和尚会念经，同行是冤家。
我曾经在日本工作了一段时间。日本的公司有自己的开发过程，而且和我合作过的几个公司似乎在使用同一种开发过程；而我们的公司要么没有开发过程，要么就是觉得什么好就用什么，我们怎么连小日本都比不过呢？这是任何一个热血程序员都无法接受的。
我不过是个还算有些热情的小人物，我却想构造真正的SOA。我试图在项目中推行SOA，使用我定义的开发过程来管理软件生命周期各阶段，也设计实现了一种灵活的可以快捷转换的面向服务设计的技术基础实现框架；高效快速，安全稳定，部署、移植简单，程序员容易学习掌握、快速上手开发。
谈谈老三样（Structs Hibernate Spring）
话题回过来先谈谈某家最熟悉的技术框架，咱也是靠这个混饭吃地。2004赛季，由于工作需要我比较认真地看了看这老三样的源代码，当时Hibernate的版本是2.x，其它的版本那是记不住了，自以为是看懂了这三样的实现逻辑，所以也算是小有发言权。但是现在这三样版本都升级，可能我现在说的东西啊，哈哈，都是老东西了。
谈这个东西其实是很有风险的，因为和前面说的一样，这东西没有绝对的对和错，哪怕你是个小白，也可以指着我的某段话发表一顿个人意见。而且，这三样太出名了，会的人太多了，接十份简历，会这三种之一的有十个，三种全精通的最少也有8个。所以大家看我的文字就必要找我辩论了，咱说的都是一家之言，我也不靠码字吃饭，我自己也不当真的。
写议论文的原则之一哈，先立个论：本人认为，除了Hibernate还算一般之外，其它两个在实际应用中都是垃圾。
我这个观点的前提是在实际的应用开发中，当然还包含我个人的喜好在其中。其实还有些哲学道理在里面，首先，框架，尤其是这个层次上的框架是很通用的，都是力争做到应用服务器无关、数据库无关。但是真正的实际业务应用必然是特殊的，对于特殊的应用使用通用的框架，必定造成开发效率低下、执行效率低下，部署复杂。
另外，我一直强调中国特色，中国的应用软件开发是有自己的规律的，中国人的思维方式和老外是非常不同的。鬼子们的框架是编给鬼子们用的，只不过，咱们中国人看到了能用就说好，一下子炒热了。思维方式的不同，必然造成在阻抗。我很少使用开源的框架在我的项目中，因为我一般只使用自己的框架，我是中国人，我靠着开发软件项目吃饭十年了，我想我还是比较深刻的了解中国的程序员。
另外，能使用技术框架是程序员的应用开发能力么。现在有很大的误区，我接的简历中，很多孩子自我评价的第一句就是“精通Structs Hibernate Spring”，还有很多孩子会使用这三样后就感觉高人一等了，工资顿时从3K要到6K，还大声地喊8K都不多！这种是非常不成熟的表现，程序员会这三样其实和秘书会Office差不多，没有什么可吹牛的。我带过的程序员很多了，如果这个程序员有不错的编码能力，我带他保证3天就可以Structs Hibernate Spring开发作项目。
什么是应用程序员的根本？是编码能力，是靠代码行数垒出来的，你自己敲（非复制粘贴）的代码量有50万行拿不到8K+，你就来我们公司好了，一定行。
敲着、敲着，跑题了，呵呵，下次回来再说：我为什么认为应用开发中Structs是垃圾。
我为什么不使用Struts
我对Struts的反感是与生俱来地，呵呵，开个玩笑。
Struts作为MVC的框架有点就不要我来说了，说的太多了，我就说些我自己的比较偏偏的观点，Struts的坚定拥护者如果想看看正面言论，去网上找吧，多的很。
我最讨厌Struts的两点，一个是配置文件，一个是标签库。
配置文件那是极其讨厌的，不但麻烦而且效率低下，运行期的反射让人一看到就觉得慢。如此大量的配置文件，注定难以在大型项目上应用。我早年作一个大项目（2300w左右），当时就是使用了部分Struts，慢的难以忍受。不知道我现在怎么了，看到.do就觉得这个网页可能刷不出来，看到.jsp就觉得看来是需要等了。我个人极其讨厌配置文件，我基本不太会使用工具来生成配置文件，从来都是手写，这是从EJB1.0的年代养成的习惯。虽然现在很多工具帮助生成配置文件，但是还是增加了程序员学习使用工具的负担，而且工具的使用没有任何意义。
大家可能还记得刚学习使用电脑的情景吧？！那时候谁要是会点基本的dos（现在是windows了，呵呵）操作，那就牛的不得了，可是呢，过了一个阶段呢？会使用工具没有意义，有意义的是思想和能力的提升。
至于标签库，我是个绝对的反标签者，坚决反对使用任何标签，坚决抵制，坚决而且坚定。我觉得，jsp作为J2EE的一项重要技术，就是做动态网页的，而标签试图以html的方式取代jsp是不符合技术规律的，况且标签还是类，还需要编译，与jsp有什么区别么？程序员还要针对标签去学习一种陌生的规则。标签实现的所有功能完全可以通过对象来实现，效果、效率一样。标签的唯一好处就是Jsp页面上没有了<%%>,但是丧失了可读性，完全不利于代码交接。老外之所以搞个标签，是从分工角度出发，认为搞HTML的页面程序员不会Java，用了标签，他们就可以也写些页面逻辑了，cao，这完全是主观臆断，现在国内的开发，页面几乎都是美工来做地，美工是一个标签都不会写的，不存在这样的分工方式。标签，坚决不要用，这是一个老程序员的建议。
Struts是MVC框架，但是MVC有非常多实现方式，Struts我认为是非常笨重的实现。我来举一个例子：
-----------------------------JSP----------------------
<%@ page contentType="text/html;charset=gb2312" %>
<%@ page import="test.Control"%>
<%@ page import="test.Model"%>
<%
Model model=Control.getModel(); //通过控制,获得模型
%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>
<body>
<%=model.getName()%> ‘注释：输出名字
</body>
</html>
------------------------Model-------------
package test;
public class Model
{
private String name;
public Model()
{
}
public void setName(String name)
{
this.name = name;
}
public String getName()
{
return name;
}
}
--------------------control-------------
package test;
public final class Control
{
public static Model getModel()
{
return new Model();
}
}
这个就是一个MVC的实现，Model纯粹来装载数据，Control中是全部的业务逻辑，然后，用写类的方式在页面写Jsp，程序员非常熟悉这样的方式，这个也可以说是一种简单的架构问题的解决。剩下的重要的内容就是把MVC分清楚。所以话说来，最重要的是思维方式的改变，逻辑思考能力的提高，至于使用什么工具，采用什么框架那个都是末节。武功的最高境界就是化繁为简，无招胜有招。
现在接着说Hibernate，Hibernate对我的帮助很大，呵呵。当我一头扎在实体EJB的圈子出不来的时候是Hibernate拉了我一把，直到现在Hibernate对我自己在设计持久层架构的时候还有非常的参考价值，而且我还刻意的模仿Hibernate的语法来实现自己的持久层架构，以减少对程序员使用架构的培训。
Hibernate其实是非常优秀的，但是由于其过于的通用，必然造成针对具体应用时候的相对效率低下。记得当时我在看Hibernate源代码的时候曾经统计过，Hibernate中大概用来保证数据库兼容性的代码要比其核心的逻辑实现代码多两倍。而且Hibernate中还有大量的我非常讨厌的配置文件，呵呵。Hibernate是对JDBC的简单封装，但是其实现的机制还是相对重量的。我试图实现一个非常轻量的持久化框架，却包括O/R映射的核心内容，我的想法是对JDBC的简单封装，扔掉不常用的功能，比如实体类之间的父子关系（主子表），文档、实体类、配置信息的可视化管理并可以相互生成、转化。事实上我已经实现了这个框架，非常好用，呵呵。
我非常反对一种说法,认为持久层框架必须能够对应数据库的复杂操作，比如复杂关系的处理，并声称如果不能实现那么在做大项目的时候会有问题。我做的大型项目多了（小吹一个），但是从来没有在哪个项目中出现类似的问题，持久层框架是重要的，但是不是最重要的，数据库的合理设计才是最重要的，如果数据库设计的合理，只用JDBC一样很High。
我提倡在数据库的设计和持久层框架的定义中大量的使用约定来保证系统的合理和稳定。比如，强行要求实体类名称和数据库名称必须相同，实体类的属性名和数据库字段名必须相同，而不是说通过配置文件来定义他们之间的关系。我讲述的都是在做具体项目的时候总结出的实际经验，如果您是搞科学研究的，就略过这段内容好了。
最后总结一个，应用中，数据库的合理设计最重要，用什么持久层的框架，甚至说用不用持久层框架都不重要。
用Spring来干什么？
我对Spring的缔造者Rod Johnson Juergen Hoeller 还是非常敬仰的，他的著名的小说《Expert One-on-One J2EE Design and Development》和《J2EE without EJB》还是给了我很大启发，我唯一奇怪的就是从这两本书的思想中是怎么演化出来了Spring？！
Spring原本是一个轻量的，易于学习掌握，API简单，容易配置而且号称高效率的开发框架，而现在，Spring给我的感觉是要无所不包、无所不能了，使用复杂、配置复杂、学习复杂。我估计很快就会有一本书出来，就叫做《J2EE without Spring》。
最近我大概面试了有50个以上的程序员，他们都声称自己精通Spring（至少简历是这样写的），每个人我都问他们这样一个问题：你在你的最近的项目中使用Spring来做什么？回答是千变万化的。
一种是相对标准而且通常的答案：Struts写MVC，Hibernate来做持久层，Spring把他们结合起来；然后我又问：Spring是怎么把他们结合起来的，这样做有什么好处？没有人能够回答我。
另一种的说法也比较有意思，使用IOC和注入来管理配置信息，把Spring当成解析xml的API，这还真是个不错的思路。不过从另一个侧面说明此人不会写解析xml的代码，而且用Spring来干这个事情是比较重量的。另外我个人感觉如果反射搞得明白，IOC没什么用。
用Spring来管理Hibernate更是奇怪，一次动作如果访问10次数据库，就要开关10次session，这是对传统编程的颠覆，呵呵。我们一向都认为，一次和应用服务器的交互只能有一个数据库联接被打开，然后在交互结束后关闭该联接，而不管该次交互要和数据库交互多少次。
而所有的面试者几乎都没有在项目中使用过AOP方式。其实Spring的AOP还是不错的，能够实现AOP的思想，唉，但是，AOP已经过时了（现在流行的是SOA，还得是有中国特色的这种）。不要试图说服我，我很倔的。
其实我个人认为，Spring最大的好处就是能够让普通的初级程序员学会或者说是知道什么是编程到接口。
现在国内的SOA项目实施确实是有中国特色。为什么呢？我们可以把现阶段的SOA理解为SOA1.0版。现在SOA在国内业界的主要应用就是企业遗留系统整合，其实就是EAI的升级版，我们称之为SOI－－面向服务的系统集成。系统集成－－前提是有遗留系统，然后整合。那么为什么现在大家宁可从新搭建系统，而完全抛弃遗留系统呢？原因很简单，遗留系统完全没有整合性。不能整合的东西花多大的代价都没有办法整合。这又涉及到以前遗留系统开发时的问题（无扩展性，可维护性）。在学术界SOA是基于Services的，每一个服务是已经包装好存在的，可以直接集成应用的。显而易见，区别就在服务的包装上。现有SOA实施中，最重要的问题就是遗留系统的拆分和包装，最困难的是遗留系统的拆分。虽然现在有CBM&SOM，但是每个企业都有自身的特点，没有真正意义上的重用。
相比之下，对遗留系统进行分析，然后进行功能拆分，划分模块，包装服务－－整个过程的实施在某些情况下根本就是不可能完成的任务－－国内企业现有系统更是如此。从成本上分析，包装遗留系统花费的时间和价格有的时候比从新构建新系统大的多，尤其当遗留系统不可维护时。
另外，现在SOA集成的只能是组件或服务。现有企业遗留系统很多都不能满足条件。
中国特色－－引进的技术我们是需要本土化，但是这只是技术层面的东西。现在的中国特色，只不过是没有SOA实施的前提条件或者前提条件不完全满足，这可以说是历史遗留问题。要解决历史遗留问题，就要付出更大的代价。在遗留系统没有整合性的前提下，从新构建一个体系清晰，可扩展，可维护的系统也是一种很好的选择，起码，在未来不会存在新的历史遗留问题，在将来的企业发展过程中系统带来的效益远比投入的大很多。
我对自己写的favoor都认为和主流框架的区别而走在了十字路口，现在发现存在这种思想的大有人在，我的思想和楼住一样，不过对于标签却有不同的理解，大家可以看看favoor(www.favoor.net)，就是解析sql语句映射java bean，而且支持范型（对返回的数据不需要进行类型转换），分页查询，开发效率很高。贴部分代码给大家：
private SQLAccessor<UserForm> action = new SQLAccessor<UserForm>();
//添加操作
public int insert(UserForm userForm) throws DBProcessException, SQLException{
return action.execute(StmtFactory.getSql("user.inset"), userForm);
}
//更新操作
public int update(UserForm userForm) throws DBProcessException, SQLException{
return action.execute(StmtFactory.getSql("user.update"), userForm);
}
//删除操作
public int delete(UserForm userForm) throws DBProcessException, SQLException{
return action.execute(StmtFactory.getSql("user.delete"), userForm);
}
//查询操作
public UserForm query(UserForm userForm) throws DBProcessException, SQLException{
return action.query(StmtFactory.getSql("user.query"), userForm, UserForm.class);
}
//分页查询
public Result<UserForm> result(UserForm userForm) throws DBProcessException, SQLException{
return action.result(StmtFactory.getSql("user.result"), 1, UserForm.class);
}
以上只是最基本的方法，更多API方法请访问www.favoor.net，希望能合你的胃口