#
构建一个项目，是一件极其复杂的事情。尤其是那种非常复杂的工程。
拿Java来说，构建一个项目的问题有一下这么几个：
- 项目的组织方式
- 项目的源代码控制策略
- 项目的依赖控制（工程之间的依赖以及第三方库的依赖）
- 项目的构建方式
- 项目的构建和发布周期
现在，有一些人还是在使用IDE来进行项目的配置管理的，它的缺点是什么呢？
- 一般的IDE都拥有项目组织的功能。但是，可惜的是。IDE自带的项目组织功能往往比较弱，IDE采取的项目组织方式都是平行式的，没有项目的层次感，必须通过逐级命名来体现，比如foo项目下，有两个子项目，于是分别命名为foo.bar和foo.demo，同理再深一层为foo.bar.web等，项目完全平行化管理（结构未必一定是平行的，但是对于IDE而言，它们是平等的）
- 现在流行的IDE对源代码控制工具都有非常不错的支持
- IDE对同一个工作区里的项目依赖的控制作的非常不错，但是形式相对单一
- 一般都是采用IDE自行手工构建，某些IDE可以给你提供Ant脚本（比如NetBeans），如果采用复杂的构建策略，那么要做很多手工的操作
- 没法实现自动化构建，随着项目的增大，构建成本越来越大，构建和发布周期倾向于延长
现在，大多数的Java开发人员都采取了使用Ant脚本进行构建的方式。因为Ant脚本：
- 不会影响你的项目的组织方式，你可以随意的按照任何方式组织你的项目
- Ant对源代码控制工具有很好的支持
- Ant可以明确的管理和控制项目的依赖，通过Ivy可以自动下载项目依赖
- 自动化批处理的方式
- 支持构建服务器，可以实现每日构建
但是，Ant脚本也不是一点儿问题也没有。首先，Ant脚本的重用性不好。一般意义上的Ant脚本重用，就是Copy&Paste。Ant对此没有什么封装。其次，Ant使用起来也比较困难，XML格式的脚本不是十分的好写（有了Eclipse支持以后，强了很多），作为脚本语言，Ant非常的不完善（连字符串处理的功能都非常弱，这一点Ant-Contrib提供了一些好一点儿的支持）。Ant的扩展机制完全基于Java，不能做到即时修改。
除了Ant，在Java中，还可以采用Maven进行项目的构建。Maven项目是一个非常出色的项目。首先，它体现了Apache资深开发人员的项目组织和管理智慧。另外，它以统一有效的方式实现了项目的整个构建生命周期。Maven的黑盒化操作也给项目的配置管理减轻了负担。如果采用了Maven的话，项目的组织方式、项目的构建方式、项目的发布控制全部迎刃而解。而且你所作的扩展，也是以插件的方式来透明化的起作用的。重用性比Ant高很多。使用起来也非常简便。
但是，Maven也并不是没有缺点。首先，Maven的项目组织方式是固定的，虽然这种固定的方式确实非常有道理。但是，如果与现有项目不兼容或者与IDE的项目组织方式不兼容的话，那么就完全不起作用了。比如Eclipse的Plugin项目，PDE的项目组织格式就与Maven2的项目格式完全不兼容。而且，Maven2自身的Manifest文件生成功能比较弱，对于OSGI项目而言，根本没有可用性（因为要造成重复工作）。由于Maven采用的是黑盒操作方式。操作不透明。你如果想作一些简单的自定义操作，也必须写一个Maven的插件。插件的测试、调试和修改都要比Ant困难得多。
那么有什么好办法呢？我推荐采用Ruby。
首先，Ruby是一种脚本语言，支持的环境有很多，而且还可以采用JRuby来运行。而且，Ruby支持一个类似Make语法的脚本语言，那就是Rake。
Rake脚本其实就是标准的Ruby脚本，拥有所有Ruby拥有的特性（面向对象等）。而Ruby也有非常好的依赖控制系统Gem（我个人认为比目前的Maven的依赖控制系统要好）。由于Ruby是标准的解释型语言，所以操作都是非常透明的，也可以做到即时修改的效果。所以，用来作构建脚本是非常合适的。
但是，怎么用它来构建Java项目呢？现在已经存在一个基于Rake的Java构建系统了，那就是：Raven。
Raven除了提供一些处理Java的Rake Task之外，它还提供了对Maven Repository的Gem封装，这样，你就可以采用Gem的方式来获取Java的项目依赖了。
Rake是我所看到的第一个用面向对象语言来写构建脚本的。但是，它也并不是完全没有缺点的，对Java的支持太少，就是一个很讨厌的缺点。
如果想要采用Rake，而且还要做到象Maven那样好，那么至少要有以下几个功能（除去Raven已经提供的功能）：
- 新项目的Archetype功能
- Java项目构建生命周期模型
- IDE支持
- 根据源信息生成项目信息网站
目前我能想到的办法只有一个，就是自己写（呵呵）。大家有什么高见？
中等收入家庭该如何理财？
专家建议：增加房产投资，安排适当保险，构建基金组合。 作者：陈婷
张平是某建筑企业的生产管理人员，月收入3000元。妻子是一名普通的公司职员，月收入2000元。两人有一个活泼可爱的孩子，还未满 周岁。一家三口每个月的基本生活开销为1500元。另一笔大开销是交通费，由于张平的工作地点经常都在郊外，也没有班车可以搭乘，所以他的交通费用每月将 近800元。两人均为28岁，年轻力壮很少生病，没有什么医疗费支出，只是小宝宝需要平均每月200元左右的医疗保健费用。这样算下来，他们每个月可以结 余2500元。
此外，两人的年终奖励合计有8000元左右，存款和债券利息有5000元，股利、股息有1000元左右，年度性收入在14000元左右。年度性支出方面，则主要有一些人情往来，大约在1000元左右。另外还要孝顺给父母1000元左右。
家庭资产多为存款
细观他们的家庭资产，"最大头"的比例就是存款了。其中现金和活期存款在5000元左右，定期存款则有20万元之多，股票上投资了 25000元，去年还买进了10000元的基金。加上35万元的自住房，房子面积48平方米。目前，他们的家庭总资产为59万元左右。由于他们是在结婚前 花了3.5万元"成本价"从父母处购得的售后公房，所以目前也没有什么债务。
5年后换购大房子
张平和妻子短期内没有什么特别大的计划，倒是希望5年内可以再买一套房子，或者以现有房产换购一套面积较大的房子。因为随着孩子的逐渐长大，一家三口需要的生活空间肯定要增大，而且对居住环境的要求可能会越来越高。
未雨绸缪累积教育金
今年最让张平和妻子开心的事情，莫过于两人在去年有了个爱情的结晶。小孩现在还未满周岁，要把孩子培养到大学毕业，还需要不少钱。正所 谓"可怜天下父母心"，张平和妻子甚至还希望在小孩成家时，至少能给孩子20万元。这"教育金"和"子女婚嫁基金"可是不小的费用，还需要努力积累。
考虑增加一定的保障
张平夫妻两人的单位都有社保和医疗保险，父母均健在，也有社保。但父母现在健康不代表未来没事，考虑到社保的保障力度不够，还是有些担 心他们以后的养老和医疗支出。小夫妻本身的健康医疗及养老储备也是张平考虑的一个重点问题。张平目前的想法是，他希望自己和妻子退休后每年能有相当于现在 2-3万元的生活费用。
期待专家的分析和建议
此外，张平认为自己家的财务管理过于松散，为了顺利解决孩子的教育费用、自己的买房费用、夫妻俩和父母的医疗和养老费用，希望专家能帮他给出一定的分析和建议，以便他们能更加轻松地完成家庭的各项理财计划。
专家建议一：资产配置分析
一、财务状况分析
1.收支分析：张平夫妇目前家庭年度总收入为74000元。家庭总支出为32000元。结余比例为57%。可以看出该家庭是相当节省 的。而且该家庭的收入也比较稳定，主动性收入（68000元）占总收入的92%。但应当看到，随着家庭新成员的到来和不断成长（目前还没有教育性支出）， 该家庭的日常开支将会慢慢提高。而且该家庭目前没有安排任何商业保险，在这个方面显然也需要有一些安排。所以该家庭未来的支出预期将会上升。
2.资产分析：张平夫妇目前家庭净资产已经有59万元。其中金融资产为24万元，房产资产为35万元，金融资产比重为40.7%，还算基本合适。该家庭没有任何负债，财务稳健。家庭资产配置的主要问题是现金存款部分太高，占所有金融资产的83.3%，需要调整。
3.保障分析：尽管张平夫妇和他们的父母都有社保。但保障程度显然不足，需要通过商业保险做一定的补充。特别在他们的孩子出生以后，这对小夫妻就更加需要保障了。
二、理财阶段、理财重点和理财目标分析
张平夫妇目前才28岁，孩子也刚刚出生。此时正是家庭建设和事业发展的重要阶段。在该阶段理财的重点应当是安排好家庭生活，同时应当集中精力到各自事业的发展方面，因此投资的安排不宜过于复杂，应当以简单易操作为主要考虑原则。
张平夫妇对未来有很多设想和安排。他们提出的理财目标主要有：
1.五年后再买一套房产或换购一套大房子，用于改善居住条件。
2.孩子未来直到大学毕业的教育费用。
3.孩子未来的婚嫁基金：20万元。
4.夫妻两退休后每年能有相当于现在2-3万元的生活费用。
其实，目前张平夫妇孩子刚刚出生，自己也很年轻，此时谈论30年以后的孩子婚嫁或自己的退休都尚显太早。目前阶段理财的目标应当是将家庭现有的财务和孩子出生以后的家庭保障等方面要安排好。
三、当前财务安排建议
1.增加房产投资：孩子出生以后的确需要更大的生活空间，目前48平方米三人居住显得太拥挤。同时考虑到他们实际的资产状况和未来月供 能力，我们建议目前就通过出售现有住房、然后支出现有存款10万元左右，再负债15万元来购买一套70万元左右的房产，使得总居住面积达到75平方米以 上。而完全不必等到5年后再买。那时的房价和现在绝不是一个概念。而且该家庭目前资金充裕，又没有任何负债，换购一套房产在财务的安排上没有任何问题。
2.安排适当保险：孩子出生以后家庭保障就显得格外重要了，应当安排好充足的保障。具体来说，张平夫妇的寿险、大病和意外保险都需 要。孩子也需要安排一定的医疗保险。保险的支出额度应当安排在一个月左右的家庭收入为宜。主要应当安排家庭保障类的保险，储蓄理财类的保险暂缓。
3.构建基金组合：因为张平夫妇还很年轻，应当争取在事业上更上层楼。所以在投资上应当尽量简单。因此，我们建议张平夫妇的金融资产 除保留一部分存款外应当主要通过购买基金来安排，构建一个基金组合，长期投资，让专家来帮助理财，省心省力。目前的股市投资可暂时保留，但今后也应当择机 退出，全部通过基金来投资。而且今后每月收入的结余也应当采用定期定量的方式投入到家庭的基金组合中。
——本刊首席理财师 徐建明
专家建议二：投资建议
对于张平先生的理财需要，我们提出以下几点建议，希望能够对他有所帮助。
1.对于孩子的“教育和婚嫁基金”
我们建议做个"傻瓜型"的计划。那就是在与理财专家沟通后，做一个基金的“一篮子”方案，即将货币基金、债券基金、股票基金按1:2: 7的比例进行定期定额的投资。由于张平夫妇年纪较轻，承担风险的能力较强，所以我们的建议中适当增强了股票基金的投资比例。同时，我们也提醒张平先生要在 家庭情况发生巨大变化时，对投资比例进行适时的调整。长期性定期的投入会更好地增加收益，控制风险也无须花费太多精力。
2.对于夫妻俩的购房需求
张平夫妇的购房是为了自住需要，因此我们建议可以每年投入一定比例的资金进入保本增值市场，来进行购房基金的积累。如保本基金、货币市场基金、记账式国债、以及最新发行的储蓄国债等。这样既可保持其灵活性，又可以在5年之内寻求适当的时机以按揭贷款形式购入新房。
至于未来是卖了现有房产换购新房，还是增大负债比例购置新房保留现有住房，则要看未来的家庭资产总量和月收入能力。若未来能力足够，当 然也可以保留现有老房子用于出租，用租金来缓解部分月供能力。若未来家庭积累的资金量不够，则可以选择出售后换购大房子，负债额度可以由当时的月收入能力 来计算。
虽然理论上认为月供额度只要不超过月收入的50%就是安全的了，但我们建议月供最好不要超过月收入的1/3，否则对一家三口的基本生活将会产生不小的压力，甚至沦为“房奴”一族。
3.在张平先生的家庭情况中我们注意到，其本人是建筑企业的生产管理人员，建筑行业是一个受经济波动影响较大的行业。这对他家庭收入长 期的稳定性有不利的因素存在。因为夫妇二人均只有28岁，所以我们建议张平夫妇现在每年也为自己准备一笔“教育基金”。进一步的“充充电”，学习一些新的 知识和技能来提高自己。在我们看来理财不仅仅是对金钱进行投资规划，也可以是对自身进行投资规划，而且或许收益回报会更高，也能更好、更快地实现家庭理财 计划。
——建行上海市分行卢湾支行 马钧洁
专家建议三：保险建议
家庭所面临的风险不外乎人身损失风险、财产损失风险和责任损失风险。从表面上来说张平一家的财务状况基本稳定，没有什么债可“负”，但 是一旦碰到重疾或者意外等不确定因素的发生，不仅会严重影响家人的心理状态，而且会对家庭的财务状况造成不同程度的冲击，所以绝对是可不言、但不可不理 的。况且，他们未来还打算购买大面积的房子，估计需要增加债务负担。
风险的分析应该从两个角度入手：损失发生的可能性和损失发生后的严重程度。正值盛年的张平夫妇的身故可能性很低，但是发生意外事故的风险不容忽视，尤其是张平本人从事的是建筑企业的生产管理工作。万一有一方发生不测，家庭收入就会减少一半以上。
解决这个问题的最佳途径之一莫过于人身意外伤害保险，它的最大优势就是在引起损失的事故发生时提供一笔收入，从而可以弥补损失，缓解生者面临的财务压力。
将来购买新房有了负债之后，还应该增加一定的寿险保障。
根据张平的需求，他想为自己和妻子购买养老和医疗方面的保障，以及为儿子选择教育金之类的险种。但按照他的家庭收入能力，我们建议他暂缓夫妻俩人的养老保险计划，等到十年以后，也就是37岁、38岁以后再考虑养老保障。
夫妻俩人的医疗保障，则应该从现在开始做起，毕竟他们也是"奔三"的人了，虽然现在年富力强甚至没有什么医疗费用指出，但再过两三年肯 定会明显感觉到身体的亚健康状态来临。而且，随着抚育幼儿所付出的超额体力和精力，张太太的身体状况可能面临直线下滑的趋势。为此，张平可以先为自己和太 太选择一定的医疗补贴保险和大病保险。孩子方面，如果体质较弱，夫妻双方的单位又不能负担任何医疗费用，那么也可以为孩子选择一份儿童医疗保险，向保险公 司转移家庭的医疗负担风险。
——上海合泰保险超市 高逢洁
软件项目开发过程模型
1.
什么是软件项目开发过程模型
项目开发过程模型就是对于项目开发过程的概念建模，从而能够实现在理论上对于软件项目开发过程进行量化分析。
软件开发过程模型以
Rational Unified Process
（简称
RUP
）为代表，如下图
图
1
、
Rational
Unified Process
但是也并不是只有
RUP
一种，比如
Agile Unified Process (
简称
AUP)
图
2
、
Agile Unified Process
总体来说，
RUP
是最细化的项目开发过程模型，不管你采用什么样的开发方式，整个开发过程的每一个过程你都是无法逃掉的（我们后面会讨论这个），因为这代表了整个软件开发实践的客观规律，只是在定义上有所不同，侧重点上有所不同，对于迭代的看法有所不同罢了。
2.
为什么要关注软件项目开发过程模型
如同它的概念所示，软件项目开发过程就是对软件项目开发过程的概念建模，从而能够实现在理论上对于软件项目开发过程进行量化分析。
那么，这种量化的分析到底有能有什么好处呢？
我们在引子里说过：任何的软件项目都有它存在的目的，都是为了解决一些现实中的问题。可以把这个成为这个项目的目的，可以把需要解决的问题的需求称作这个项目的需求。
而对于商用（尤其是企业级应用）软件项目开发而言，最基本也是最重要的目的就是以最小的成本，在项目交付的期限内，提供稳定的、可靠的软件，用以解决用户提交的所需要解决的问题，并且如有可能，必须为现实生活中问题的变更引起的用户需要解决的问题的变更从而要求的软件功能的变更做好准备。
l
为了能够把客户的问题描述清楚，必须进行业务建模和需求收集；
l
为了能够把收集完的问题需求转变成为可以信息化解决的问题并且解决，必须对其进行软件化设计并进行实现；
l
为了保证软件产品的质量，必须进行足够多的测试（看看硬件厂商是怎么测试的？）；
l
为了能够让软件产品正常运转，必须进行软件的部署；
l
而在软件开发的过程当中，对于项目的管理、代码的管理、还有资源的管理，在哪一个软件项目开发中能缺少？
综上，对这些过程的建模和定量的分析，并且确定在整个开发过程中各个阶段所占的份额和所拥有的重要性，对于保证项目（尤其是大项目）的平稳开发和增强项目开发管理有着重要的作用。
并且，确定了项目开发过程模型，对于确定项目管理方式和提供技术、工具支持有着非常重要的作用。
3.
接下来要讨论的
既然我们已经有了一个明确的定义，并且能够把它分解成为几个部分（当然，我们将会看到，这些部分本身也是十分复杂的）。那么，看上去下一步，我们的任务就是一步一步的分析每一个部分。
但是，且慢，这些部分有些是没法讨论的（比如业务建模，它与用户的域专家有关，或者跟一些国家、国际标准有关，跟计算机软件开发没太多的关系——除非是
IDE
之类的），有些是仁者见仁、智者见智的部分（比如设计和实现），有一些可以不必花太多口舌去讨论（比如软件项目的部署和资源管理），这一点
AUP
给我们开了个好头，我们现在需要讨论的就是：
l
需求分析
l
测试
l
配置管理
l
项目管理
但就是这么几个，就足够我们讨论的。事实上，如果能够对这些问题都全面的分析并且提出自己的见解和解决方案的话，分量足够一个博士论文（起码重量上差不多），也许那样我可以出本书，呵呵，玩笑。
我只能尽力的往下分析，但是，我更希望的是大家能够有所反馈。因为，在软件设计中很多问题都是隐藏的（像地雷一样），直到你踩上它为止，你都不会发现它。
我很希望能够有反馈使我避免低级的错误。
“
是我们创造了工具，并且使用它们，而不是相反”
任何的软件项目都有它存在的目的，都是为了解决一些现实中的问题。可以把这个成为这个项目的目的，可以把需要解决的问题的需求称作这个项目的需求。任何的软件项目的开发都必然离不开了解需求、根据需求进行设计、根据设计进行实现这些过程。不管是多大的项目，也不管是采用何种开发方式。
但是，设计的方式却有多种，没有谁会规定，只有采用UML图进行建模才叫设计。也没有谁规定，只有“设计”好了的项目才能开始代码实现。
对于软件项目开发而言，大型的项目和小型的项目所面临的项目开发的问题是不同的。
一个人几天就可以完成的项目和几个小组好几个月才能完成的项目相比，它们面临的实际中的开发问题，和开发结束后面临的维护问题都是不可同日而语的。
而且，技术的角度上看，适合大的项目的开发方式也未必一定适合小的项目。
好了，说了这么多，我只是想说：
综上所述，软件开发过程是一个非常复杂的问题，对于做技术的人来说（尤其是做计算机软件技术的人），解决问题的方式只有一种，分析问题、根据问题设计解决方案、然后实现解决方案来解决问题（解决方案未必一定是软件）。
分析问题的第一步，就是把现实中的东西转换成为概念模型，这样我们才有一个讨论和研究的平台。如果没有一个明确的统一的概念模型，那么，无论做什么研究都会显得毫无意义（古代的智者和诡辩论者经常这么干）。
既然我们面临的问题是软件项目开发，那么我们第一个要做的就是把它建模，并且对它进行一下研究。
我会在接下来几篇文章中对它进行详细的阐述，并且针对我在项目开发中的一些经验、总结和思考提出我对这个问题设计的解决方案。
目的只有一个，希望针对这个问题作出一些探讨。希望能够抛砖引玉。
当前问题：
流程－
ERP
软件的死穴？
时间：
2004-03-12
提问者：
quicker
地址（需要注册）：
http://www.ceconline.com/DG/NOTE_900001_900002_793863.HTM?dmsource=CECOL_060419_EETCOL
这些年，接触了不少
ERP
软件，听了不少关于
ERP
软件的推广说明会，自己也尝试了好几种软件模块的实际运用，但效果一直不如人意，专家对此也评论不同。说什么的都有，但几乎没人点出
ERP
的死穴。
有几个问题我们必须首先理清。
一、任何一种
ERP
软件都有其适用范围，至少到目前为止，还没有一个软件可以成为放之四海而皆准的通用软件。即使，某些声称自己是通用软件的公司也不行。
二、任何一种
ERP
软件都是建立在一种管理思想或者管理结构上的。我们知道，管理本无定法，也没有优劣之分，主要看其是否能够解决问题。软件不过是这些思想的一种体现形式，同样也摆脱不了这个约束。
三、实施
ERP
不是目的，
ERP
只是一个系统工具。这几乎已成共识。我们试图用一个系统思考的办法来解决企业各部门之间的协调与资源共享，以达到企业整体经营绩效的目的。
四、多数情况下，
ERP
都有个在实际运用中进行二次开发的问题。如果说，实际
ERP
表现有好、坏之分的话，主要还是看软件公司二次开发的能力。
但是，以上这四点观念，都无法回避一个事实：现在的
ERP
是建立在流程基础之上的。因为，有
“
业务流程重组
”
做理论指导，这方面还有
6
西格玛做旁证。
而我的观点是，建立在流程基础上的
ERP
软件会被流程所困住，流程思路便成了
ERP
的死穴。如果我要界定一下我说的论点的适用范围的话，那么，我
要说，对中国，对民营企业，
ERP
还很遥远。因为，我无法穷举，所以，为防止招来批评，我不得不界定成上述的一个相对狭窄的范围。
为什么？这是中国的客观现实所然。
今天的中国市场变化太大了，昨天的英雄，今天可能就成为了失败者。中国的企业外部环境是多变的。在这种情况下，一个企业想要经营良好，没有多变的
机制或者更准确说，具备灵活的应对机制，恐怕是很难持久的。进一步讲，由于企业经营机制多变，那就要求企业具备动态调整的能力，这种能力从企业实际来讲，
就是：组织结构多变、权责多变（也是权责不清的一个原因）、人员多变、流程多变等等。
有人讲：唯一不变的真理就是变化。
那么，作为
ERP
软件开发的公司来讲，是不希望你变来变去的，一是软件设计师在模块规划时很难协调，二是二次开发可能因为多变而成了多次开发，软
件公司也受不了。有的软件公司为逃避这种责任，干脆把源代码交给企业，由企业去自行修订。可是，有多少企业有这样的强大开发能力呢？
其实，问题既不在于企业多变，也不在于软件公司不负责任，而是建立在流程基础上的框架是个死穴。
包括四川维尼纶公司在内一些早期应用过
ERP
的企业曾经谈过：
“
。。。我们不得不加班登录数据，否则第二天其它部门上班便没法运作。。。
”
这就是
一个很典型的情况。由于流程的限制，上、下部门之间的数据库是被流程捆绑起来的，所以，流程要求这样，你不得不先行一步。但是，我们似乎应该思考一下，我
们真的应该这样吗？
我们不妨换个角度看看。如果，我们不把流程作为数据库链接的基础，而是把流程所产生的结果作为基础，那会是一种什么样的情况呢？
关注结果而不是关注流程，那么无论流程如何多变，均没有什么可以担忧的。
只要结果能够反应企业的整体经营需要，随着市场环境的变化，企业可以动态调整自己的组织结构、调整自己的运作流程。需要说明的是人员的调整也同样不会产生大的影响，而现在的关注流程的方式，倒要受到这方面的影响，使得企业不得不再行投入成本进行培训。
只有三种情况是例外：企业流程本身比较稳定或变革后流程重新稳定的能力很强；软件公司的后续开发能力很强（往往有管理顾问做后盾）；企业自身的软件开发调整能力超强。
否则，应用
ERP
，真应该小心啦。
你们说呢？
评注： 作者提出了ERP对业务处理流程提出了要求，也对ERP依赖于业务流程的程度提出了质疑。本身观点是比较清晰的。但是，我个人觉得，抛开业务流程的处理而只关注业务处理的结果的话，只会降低ERP系统的价值，失去ERP系统对企业内部资源的统一调配能力和协调能力。所需要关注的应该是怎样提高业务流程的灵活性和可定义性，在深层次上解决当前企业内部流程不确定的问题，没有一家成熟的企业规则朝令夕改，虽然目前来看，中国的国情（最好的不一定是正确的，正确的不一定是挣钱的）决定了一个企业要想生存，必须能够灵活的进行适应，但是这并不一定代表着确立业务处理流程没有必要，确立公司内部业务处理规则没有必要，在
解决当前企业内部流程不确定的问题上，ERP的开发企业必须要达到技术上提高业务处理流程的灵活性和可定制性，降低修改带来的时间和经济成本，还要结合自身的开发经验，向客户推荐当前业内先进的管理思想和管理方式，在另一个方面上提升用户的价值。
这方面，大家有什么想法？
在这里只是简单的介绍一些企业应用开发应该采纳和借鉴的一些展现层技术、架构和开发方式，之所以称它们为新，主要是针对技术和趋势而言，其实他们的概念已经不算是太新的了（已经存在一段时间了），正是因为如此，它们更加具有可借鉴的价值。
浏览器胖客户端技术：
无论如何说、无论采用何种技术目前的三层分布式企业级应用也都是网络应用，它在本质上与其他的网络应用是有相似性的，我们可以在它们之间作一个类比。
就在不远的以前，网站的用户界面也是静态的，虽然很多网站提供了服务端动态网页的支持，但是用户看到的却还是一张张静态的网页。用户与网站之间是一个请求
和交互的过程（本质上就是这样，看上去也是这样），用户通过超链接在一个个动态/静态的页面之间浏览。而所有的处理全部是由服务器来进行的。大多数能够即
时响应客户的是Flash或者Applet这种浏览器的插件。当然客户端动态网页的技术当时也已经存在很长时间了，但是并没有得到太多的重视。
但是，近几年来，动态网页无刷新技术逐渐兴起起来，它充分利用了客户端浏览器所具备的计算能力，通过借助于DHTML容器的事件机制和非提交形式HTTP
访问服务器的方法实现了可以在客户端自行处理用户请求的基于浏览器的胖客户端，使得使用界面更加友好和易用，而且还在相当的程度上减轻了服务器处理的负
担。
再拿二层的分布式企业级应用来作纵向比较，虽然抽象出应用服务器这一层对于数据库服务器是一种解脱（也为SOA打下了基础），但是由于当时的网络应用的技
术所限，真正的用户体验是下降了的，胖客户端的安装和升级确实比较麻烦，但是一般说来客户端的安装问题只是部署和维护企业级应用系统的一个很小的问题。但
对于底层的实际用户而言，基于网络HTML技术的客户端界面可能会好看一些，但是效率、操作性、实时反应的能力都是下降了的。对于底层的用户而言，键盘操
作要比鼠标操作工作效率更高。企业级应用的系统是要给企业做的，而企业的主要目标是创造最大利润，在这一点上其实很多三层的企业级应用都是对企业级应用所
要达成的目标的一种背离。但是，这主要是因为当时的技术所限，就算是最能代表当时网络技术的大型商业网站，他们的用户界面也几乎全是静态的HTML网页。
综上所述，可以看出三层分布式的企业级应用系统应该在展现层进行一次革新，应该尽可能的采用浏览器胖客户端的技术，这样一方面可以充分利用客户端的计算能
力和资源，缓解服务端压力，还可以通过快捷键、自定义快捷方式甚至自定义宏的方式提高用户的使用效率和使用体验。
服务端组件化开发技术：
Struts
是一个很好的框架，它的灵活性和稳定性是有目共睹的。但是无论如何它给开发人员带来的工作量和调试起来的难度也是很多的（尤其是在没有充分体现出分层概念
的企业级应用系统中）。其实难度最终是要转化到网络应用的开发上去的。三层的企业级应用系统也是网络应用，而对于网络应用而言，业务开发人员和美工（又叫
WebUI？）人员的分工也是比较头疼的问题。JSP等模板技术于是应运而生，但其实这不过是一种善意的谎言。对于JSP而言业务开发人员还是必须对
HTML有比较深的了解，而且最头疼的是，除非你把它放在Web容器中运行，否则你决不会知道它到底是一个什么样子（除非你把你自己的大脑变成一个Web
容器加上一个浏览器），JSP Tag的出现并不能解决什么问题，从本质上来说它就是JSP概念的一个延展，可以节省代码而已（而且带来更多的复杂度）。
难道真的没有办法了吗？
我们纵向对比一下二层的企业级应用，它开发和维护起来就没有三层那么麻烦。原因何在？组件已经封装了绝大多部分的工作，你所需要的只是应用组件、配置组件、添加事件处理代码而已。
从这个方面上来说，还有什么DHTML更好的用户界面描述语言？设想一下，你可以试图拿Swing（为什么Swing？——平台无关）写一个可以在运行时
动态的改变界面结构、通过样式描述文件动态改变组件样式的程序（这一切可以跟一个或多个很完善的脚本语言无缝集成），它会多复杂？
还记得桌面应用的开发吗？没有一个像样的桌面程序没有自定义组件的，但是它们的自定义组件大多数其实只是基础组件的组合。
同理，也可以对HTML进行如此开发。
下面给出解决的架构。
展现层开发架构：
开发要明确体现出客户端、应用服务器端、数据库服务器端的三层概念。数据库服务端的开发与展现层无关略去不讲。
- 客户端开发：使用JavaScript进行事件处理响应用户的操作，对组件进行相应的操作，如有必要可以采取远程服务器端服务调用（既可以调用自己服务器提供的服务也可以调用其他的公用网络服务，符合SOA的要求）的方式。
- 服
务端开发：展现层组件分为两部分，动态网页组件和JavaScript组件。动态网页组件采用基于组件化的动态网页框架（比如Tapesrty，为什么不
用JSF稍后再讲）。另外服务端开发还有业务逻辑处理服务，其中业务逻辑处理属于业务逻辑层不再多说，而业务逻辑处理服务和服务的远程调用以及相应的安全
处理可以采用Spring + Acegi +
DWR的方式（这样可以既可以实现JavaScript客户端远程调用业务逻辑服务，还可以很容易的实现服务的安全公开化，符合SOA的要求）。
为什么这么看重Tapestry而不用JSF呢？
- JSF
的标准还是跟JSP绑在一块的，虽然有Facelet的存在，但是本身摆脱不了JSP的JSF还是会被JSP所拖累的。我并没有说JSP一无是处，作为模
板技术而言，JSP已经非常成功了，但是对于JavaScript胖客户端开发而言，JSP本身容器相关的特性实在是没什么好处。
- 目前
而言JavaScript是可以进行单元测试的，而Tapestry的Html模板技术使得JavaScript和Html的集成测试达到可能。你可以完
全不管Tapestry而调试JavaScript，调试成功以后再加上Tapestry的组件标签就可以了。你可以为重要的JavaScript（一些
起粘结作用的Script就没有必要测试了）写测试脚本进行测试，而这些全部都是远离Web容器的。
我们的开发人员为什么要远离JavaScript呢？因为它是动态解释语言？Ruby也是。只要测试到位，动态语言也可以实现稳定的系统。
运行的效率低？也许吧，但总高过整个页面刷新，我说的不过分吧。
开发人员对JavaScript认识不够，没有很好的IDE支持？事实上，根本不必让开发人员对它认识“够”，因为他所写的主要是一些GlueCode，
配置一下组件，把组件之间通过事件结合起来。当然，这些有一部分你可以自己发明一些XML来达到，值得吗？我个人认为写动态脚本也好过写XML（别跟我说
你还可以写个DTD）。至于IDE的话，我认为，写JavaScript根本用不着，尤其是在你根本不会写很多的时候。只要有一个浏览器和浏览器支持的
JavaScript调试器足够了。只要组件化做好了，再结合工程模板，那么开发人员就象回到了二层的时代，选择相应的组件，组合然后就是调试了。比两层
有优势的一点是，他不必启动服务器就可以调试客户端。
这一方面的网络应用开发先驱是Google（可惜，他们没用JavaEE技术，呵呵），到现在已经成为一种风潮，对企业级应用开发赶时髦是没有必要的，但
是技术的发展带来了新的可能，不管是在开发方面还是在客户体验和客户效率提高上都会有更好的机会，为什么不把握这个机会呢？
末了，SOA完全可以评为今年的软件开发最流行关键词。呵呵。它的核心概念是什么呢？不要浪费现有的IT资源。
我们现在对于网络和计算机技术的资源开发和应用的大部分都处于浪费状态，有政治原因、有商业原因但是还有技术原因。能够尽可能有效的利用手中现有的资源，对于企业的发展也有相当的积极作用。
地址：http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
评论：
很久没有看到这么好玩的东西了。开始还是讨论，但是由于
Gavin King的坏脾气，最后直接变成了批斗大会了。哈哈。
其实Hibernate怎么能够封杀得掉Spring呢？他们只能自己生气罢了。
我倒不是太讨厌EJB3，可是还要涉及到JDK5.0的技术，对以前的东西的兼容性也不能保证。目前来看，也不见得就比Spring强。
我对他们倒是没有偏见，但是我还是选择用Spring。
AOP是一个什么概念呢？
AOP是Aspect Oriented Programming的缩写，翻译成中文就是面向方面编程。它是最近几年流行起来的另一种编程方式。
- 首先，AOP只是OOP的补充，换句话说，Procedure Oriented Programming的工程是很难，也是几乎不可能使用AOP的。
- 其次，AOP是对OOP系统的纵向切割，从另一个方面上实现了系统解耦
- 再次，AOP给OOP提供了另一种重用的可能。
对于OOP系统而言，系统的解耦主要依赖分层和良好的设计，一般良好的OOP架构没有不采用分层和设计模式的（当然，分层分得恰当不恰当、模式用得好不好，跟框架的设计者有着直接的关系）。但是，对于OOP系统而言，它只能到达这一步了。
对于系统的必须要求，比如日志、错误跟踪、访问拦截、权限控制等操作，OOP就很难达到八面玲珑。
其实，倒不是OOP一定不能实现上述功能的分离和重用，但是由于那又需要更高层次的抽象和封装，凭空增加系统的复杂性和使用难度，又不利于版本控制和发布控制，一般来说，是得不偿失的。
所以，很多开源项目比如Commons Logging等应运而生，它们的存在从一定的意义上解决了这个问题。
但是，还有一种很好的解决方案，那就是AOP（实际上AOP就是为了解决这种问题而诞生的）。
AOP既然是OOP系统的纵向切割，那么它就应该具备以下几点：
- 切入点（Point Cut）：它需要一个点来切入到OOP系统中去，目前流行的AOP框架都采用从方法切入的方式。
- 切面（Advice）：切入之后，它要做些什么呢？必须可以有一种方式进行定制，目前流行的AOP框架都采用Java代码实现的方式
- 重用性：一般来说，AOP能带来的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，这就提供了一种可能，所有的Advice都可以通过打包成Jar的形式实现重用。
由此可以看出，使用AOP能够带来的好处是提供了一种抽象模型的方式、一种重用以前工作的方式（在不更改过去的代码的基础上添加新的功能、同时也可以重用过去写的Advice）。
AOP还有一个好处，就是减少工作量。
因为目前流行的AOP框架的PointCut定义一般都支持通配，这样就可以实现批量定义和修改。如果代码有着良好的规范、在良好的设计下，开发和维护工作量的减少会非常可观。而且对于添加新的功能不必修改原有的架构设计，从另一方面也降低了非常可观的工作量。
那么AOP在JavaEE企业级应用中能够起什么作用呢？
- 事务控制：很多业务逻辑方法都需要事务控制，通过通配实现事务控制绝对是一个节省工作量的好办法，如果再结合IOC更加可以脱离事务控制的依赖，实现事务控制灵活更换，提高了业务系统的重用性
- 权限控制：权限控制到底算不算业务逻辑？如果不算，为什么还要体现在业务逻辑中？通过AOP的方式，可以灵活的实现FilterChain机制，而业务逻辑的代码可以对其毫无察觉。
- 持久层对象的装饰和过滤：可以根据需要对持久层操作返回的结果进行装饰和过滤，甚至替换，而对系统架构没有任何要求。这是最漂亮和最干净的做法。
- 系统级别诊断日志：实现可插拔式系统级别日志，这样在系统正常运行后就可以为了提高系统性能而不费事的去掉它却不会影响到系统的稳定。
- 业务级别高级抽象：比如可以把工作流支持API封装，通过AOP的机制实现Mixin，这样就可以实现工作流支持和原业务逻辑分离，可以分开进行管理，也可以在更高的抽象级别上实现重用。
AOP也不是没有缺点，它本身就有一定的学习曲线，而且目前为止有具体意愿的好的实践并不多，而且它也会给你的工程带来复杂性，它还会给你的代码增加理解的难度（不管你承认不承认，代码阅读的难度确实是跟代码的耦合程度反相关的——虽然这是设计模式所力图解决的问题）
但是，目前来看适当的使用AOP，给你的项目提高灵活性和可维护性，是值得的。
什么是容器？
JavaEE原话：“
Containers are the interface between a
component and the low-level platform-specific functionality that
supports the component. ”
翻译过来就是“容器就是底层的、与支撑平台相关的、对组件进行功能化支持的接口”。
难以理解？
通俗的解释就是，容器是一系列为了实现分层的概念而定义的一系列功能的平台无关的标准。它的主要用处就是平台无关性和底层操作封装性（Java的核心哲学）。
说白了，容器就是
Java的核心哲学在企业级应用范围内的具体实现。
那么使用容器，能给我们带来多大的好处呢？
- 强制性分层：通过Java的接口定义机制和强类型编译器的支持，在底层就实现了分层的概念。即使顶层的实现十分没有经验，底层的分层还是可以辨认的。
- 底层操作封装：以服务端应用服务器为中心的三层企业开发涉及到的技术相当麻烦和复杂，但是之间又有相当多的共性，所以进行有效的底层次的封装是可行的而且是有必要的。这样开发人员的工作就可以建立在一个稳固的基础上，而不是靠自己的经验去应对这些问题。
- 平台无关性：这个也是Java的核心哲学，至于好处吗，我就不多说了
- 代码的重用可能性提高：记住，是可能性。具体的重用性要看开发的方式和开发后代码的质量。
就JavaEE而言，它的标准里面只有WEB容器和EJB容器，这两个容器已经充分体现了它们的概念。
但是，还有一种概念上的容器，它的概念与上述概念不同，所以被称作轻量级容器。
首先，轻量级容器不是接口的抽象，没有JavaEE概念中的部署和移除，从概念上说轻量级容器就是一个拥有IOC支持的Bean工厂。
从形象的角度上来看，轻量级容器是一个盒子，盒子里面装满了贴有标签的JavaBean，对外界而言，它是一个魔盒，只要给它一个咒语（咒语必须正确），它就能给你一个礼物。
轻量级容器目前而言没，有相应的标准，但是它的使用范围却比真正的JavaEE标准要宽泛得多（谁不喜欢礼物呢？）。
- 首先，它是一个非常好的JavaBean工厂（谁没用过工厂模式？）
- 其次，它能够给你的代码带来IOC支持（懒人最喜欢的生活方式莫过于东西自己来找它）
- 再次，一般来说，轻量级容器都可以通过动态代理和字节码增强的方式提供AOP的支持
总而言之，轻量级容器是JavaEE容器概念的一种有力补充，它的用法更加灵活，适用的范围更广，从目前的经验上看，开发、测试和管理起来也要比标准容器对象开发起来简单。
-
轻量级容器一般不会给你提供分布式和集群的支持，因为它的优点就是灵活而不笨重。
-
轻量级容器就像作汉堡的那两块面包，你想吃什么就往里夹，但是汉堡好吃不好吃，主要就在你放进去的东西和搭配的手艺。
-
轻量级容器不能强制的要求你分层
- 轻量级容器的底层封装一般以模块加载进容器的方式实现。
-
有的人不爱吃汉堡。
总体评价：
容器是Java的核心哲学的体现，而轻量级容器则是工程师开发文化的体现，它可以很灵活的帮助你，对你没有什么具体的要求。二者不会出现谁替代谁的情况。具体的使用方式，还得看你在设计时所处的情况。
更正一下：
就JavaEE而言，它的标准里面只有WEB容器和EJB容器是对它的服务端而言的。客户端还有Application Container和Applet Container两个容器。
除了关系型数据库（企业级应用主要的数据持久工具）之外，企业级应用还需要其他的方式进行持久层操作。比如，数据保存在文件中、数据来自或者流向远程的其
他服务等。这样持久层的操作就会有3——5种之多（还分有事务管理支持的和没有事物管理支持的）。
怎么对这么多的操作进行有效的管理，怎么才能使持久层的变更只
限定在持久层的范围内，怎么才能实现业务逻辑开发人员在开发上不必具有很多的持久层框架经验（注1），还有就是怎样实现既可以利用强制和工具辅助的方式使一个新人能够开发出跟掌握持
久层开发的精髓的核心开发人员同样质量的代码（注2）又可以让老手开发起来非常快捷（熟练工种），更重要的是在业务逻
辑方面物质化、代码化积累公司的业界开发经验，这就是我们下面要讨论的问题。
我认为，要想实现持久层的修改（注3）与业务逻辑层分离。还要最大可能的把公用的东西抽象出来，最大可能的为培养业务专精人员提供基础，就必须
要有一个机制，实现把持久层的任务交给持久层去作。
这是什么意思呢？
就是在系统基础架构上，实现业务逻辑层和持久层的明显松耦合（业务逻辑层根本不必知道持久层到底是什么介质和实现方式）。
但是作为业务逻辑层的对象，数据的持久化操作是它所不能避免的东西，也就是说，它不可避免的会和持久层打交道。
那么怎样在代码的级别实现和持久层打交道还不跟持久层相关呢？
这就是要在下面给出的总体设计。在这里简单的介绍一下用到了三个技巧，一个是
IOC，一个是
Command模式，还有一个就是CallBack的概念。
IOC就是著名的好莱坞模式——你不用来找我，我会自己去找你的，而CallBack通俗一点说就是“你要做什么，你告诉我，到时候我会通知你，并把你想要的东西带来的”。
业务逻辑对象不可避免的要对持久层进行操作，但是它对持久层的操作本身可以抽象成为一个Command对象，由注入到业务逻辑对象中的DAO来负责操作。说通俗点儿就是
说，对业务逻辑对象（BO）而言它是把一个任务说明书（CommandCallBack）给了一个它自己都不知道是从哪里来的叫做DAO的家伙（IOC），然后跟他说：
“你拿着它，按它的指示去把这事儿给办了吧。”；业务逻辑对象知道“这事儿”是什么事儿，因为任务说明书是有名称的，但是至于任务说明书的内容，它就不清
楚了。具体的事情DAO和任务说明书清楚，但是业务逻辑对象只是一个交接。换句话就是说，通过这么一个交接手续，把持久层的东西还给持久层了。业务逻辑对
象只想知道“这事儿”办完的结果，事实上本来就应该这样。
整体设计上面，涉及到了几个持久层开发的基本的技巧，除了IOC、CallBack之外，还有DAO和容器管理。
DAO的模式其实也不是什么新鲜的摇滚Rock'n'Roll了，企业级应用要的就不是新鲜的东西（注4）。这个方式里面用的DAO是通用型的DAO，通
用型的DAO的优点就是接口统一，框架比较容易理解。但是缺点也十分明显，那就是它本身的灵活性是值得怀疑的，JDBC就是一个统一的接口，结果呢，直接
用它就会导致SQL遍布代码，这本身就增加了管理的复杂度，本来就是来封装持久层的，结果跟没封装没有区别，那么这个工作就是值得怀疑的。非通用型的
DAO倒是可以解决这个问题，但是非通用型的DAO就太灵活了，没有办法对它进行良好的封装，而且对于建筑在持久层的基础之上的业务逻辑层架构而言，这种
灵活性导致了只能对业务逻辑操作进行粗放式的封装，可重用的东西相对没有使用通用型DAO的时候多了。还有就是非通用型DAO的开发上面想要实现代码重用
也是比较麻烦的（需要良好的设计）。
至于容器管理吗，明天再谈。
注1：如果业务开发人员具有很多的持久层框架经验，当持久层框架更
换时，必然会造成他的极度不适应，这通常是系统移植成本很高的原因之一
注2 ：这是有可能的，类比一下C++和汇编语言，用Eclipse和用手工进行重构
注3：包括库表修改、框架更换和方式的修改——事实上，如果业务逻辑发生了修改，那么持久层可能必须得改，但是如果持久层封装的好的话，反之未必亦然
注4：公司重要的事情是盈利，根据技术辩证法，任何一个技术有有其优点也有其缺点，都有其适用和不适用的地方，新鲜的技术往往由于是对已有技术的革新，所
以在一段时间内会有很多潜在问题，作为爱好者去试用去跟技术的负责人联系当然是没问题，但是作为企业，对产品是质量要负有法律责任的，一般的公司当然都不
会愿意当新技术的小白鼠。相对而言，旧的技术由于拥有广泛的使用，优点和缺点广为人知，熟练开发人员也比较容易找到，可以在开发中规避其自身的缺点。当
然，不新鲜的也得看着要，得根据实际情况再作决定。