OpenJWeb(1.6) Java Web应用快速开发平台技术白皮书
OpenJWeb中国开源组织(http://blog.csdn.net/baozhengw)
苏州创智科技有限公司(http://www.cmissoft.com)
QQ:29803446
Email:[email protected]
联系人:王先生
手机:13651070328
目录
第一章 面向平台开发的时代
随着IT应用技术的不断发展，中国企业应用软件正在向面向平台开发的时代转变。在过去，中国软件行业的开发模式常被称作是手工作坊式的开发模式。尽管我们从国外引进了瀑布式开发、迭代式开发、敏捷开发等软件开发管理思想，但大多数软件公司仍然没有实现从手工作坊式开发向软件工厂化开发模式的跳跃式转变。
Java开源思想和开源技术的迅猛发展，加速了软件开发向工厂化时代迈进，我们也可以称这个时代为面向平台的开发时代。
目前，我们正处于不知不觉地向面向平台开发时代转变的过渡时期。在这个时期，新兴的Web应用开发技术可以说是铺天盖地，极大地考验着软件开发人员的学习能力。而正是这些新技术的产生，才使得我们有条件去催生应用软件快速开发平台。
细数目前的Web应用技术，Java开源领域有大名鼎鼎的Spring Framework，它使得软件组件可以“装配”到容器中运行。另外有Hibernate为主的跨数据库产品(ORM)，使得我们的产品可以轻松地支持多种数据库产品。在MVC领域，我们的选择就更多了，有struts,webwork,以及struts和webwork统一后的struts2,其他还有tapestry,JSF,甚至还有国内的easyJWeb;权限管理框架有一枝独秀的Spring Security(前身是Acegi)，异步调用技术有AJAX,DWR（DWR多少冲击了传统的MVC模式），富客户端技术有extjs,jQuery,FLEX等。这些技术正在极大地考验着我们的整合能力。
我们可以很形象地将这些技术比喻为画家手中的颜料，要想利用这些颜料画出好的作品，那就要看我们中国的软件架构师的功力了。不可否认，我国的IT科技与美国有相当大的差距，从操作系统，到数据库，再到中间件，开发工具，底层的Java开源框架（Spring,hibernate）等，我们都落后于美国(有很多是国内空白)，但快速应用开发平台产品，我们的确是走在了前列。我们完全可以用这些技术做“颜料”，来画出精美的“画卷”。
国外的应用快速开发平台，大概了解一下Appfuse,JBoss Seam就可以了。笔者的感觉是，国外的快速开发平台，喜欢玩技术，而国内的快速开发平台更注重的是从深度上解决企业应用的需求。所以，笔者的看法是，在快速应用开发平台领域，我们可以超过美国，而且必须超过美国，既然我们其他IT科技落后于美国，为什么就不能让快速开发平台一枝独秀呢？
设计一套优秀的快速开发平台，不仅考验的是技术能力，更考验的是整合能力，没有长期的技术积累和项目开发实战经验，是很难设计出优秀的快速开发平台的。 软件超级架构师的稀缺（国外可能称此类人为XXX之父），导致国内的平台产品仍然没有任何一家占绝对主导优势。因为没有任何一家的平台产品能以压倒性的技术优势和市场优势超越竞争对手。
面向平台开发是今后软件开发的新方向，但目前尚未形成主流，笔者所以辞职专门从事OpenJWeb Java Web应用快速开发平台的开发，也是因为平台产品巨大的潜在市场(并不是为了成为OpenJWeb之父)。为什么说平台产品的市场潜力巨大呢？国内不是有北京思维加速(起步科技)，上海普元，北京金富瑞(UCML),上海群萃(Extraction,简称ET),深圳极致，上海锐道（BsTek,产品DoRaDo）,FastUnit,Spring Side等很多平台产品吗？笔者认为虽然有不少平台产品，但一是由于目前中国的软件公司还不太习惯购买同行的产品（都是做软件的，你凭什么分我一杯羹，我买你的产品不就说明我的技术落后于你吗），而是对于平台用户，也是口味各异，一个公司的平台产品很难满足大多数的平台需求，起步早的公司平台成熟，但技术有些滞后，起步晚的公司平台不成熟，但使用的是目前最流行的技术。另外从技术选型看，有的公司采购平台产品希望是基于EJB的,有的是希望是SSH的,等等，正所谓众口难调。所以现有的平台厂商并没有在市场上占绝对优势的。还有一个重要原因就是，绝大多数的软件公司没有平台开发的意识，导致通过采购平台产品开发应用软件的公司还是占相当少数的。
中国的IT企业应用软件开发商好象都在围着最终用户进行着两败俱伤的价格战，低的利润空间导致软件公司难以从长远考虑更好的开发模式，低效的开发模式进一步蚕食利润空间本来就低的软件项目。而企业似乎也没有彻底明白挤占软件商的利润空间实际就是增加软件项目的实施风险，最终吞下苦果的是企业自己。所以企业应该给软件公司一个合理的利润空间，不过既然最终用户(也就是我们的上帝)事实上仍然抱着尽量挑便宜的买的想法，作为软件公司，也只有靠内部挖潜的方式来提高项目的利润率了。怎样进行内部挖潜？就是购买专业技术咨询服务，并选购平台产品，从根本上改变传统的面向功能的手工作坊式开发，从而大幅度地降低软件开发成本。那么降低的幅度能有多大呢？举个例子，用传统的开发模式来开发一个商品基本信息录入功能，传统的方式是从原来的产品中复制粘贴代码，并手工修改页面,还要修改数据库查询语句，中级程序至少要两天的开发时间，还不包括测试时间，但用一个好的平台，只要把商品基本信息所需要的字段录入到平台的数据库中，然后一点生成按钮，关于商品的增删改查页面就生成了，生成的页面带分页，基本查询，自定义查询，排序，编辑，字段校验，权限控制，等等，只需要十分钟的录入表字段属性的时间，可以说，两种开发模式的差异，是冷兵器时代与热兵器时代的差异，是小米加步枪与远程精确制导武器的差异。我们可以想象一个大型的项目中有多少是增删改查类型的功能（应该说是占有很大比例的），这么一算，通过平台开发项目的节约成本就非常可观了。如果项目的计划利润率是20%,通过改变开发模式使利润率实际达到40%,这是不是说明我们相当于在同一时间完成了两个项目？
使用平台进行开发，在需求调研的后期制作系统原型产品时，基本的增删改查模块都可以通过平台定义出可使用的应用程序了，而没有平台的软件公司却还在用美工在一点点地雕刻着他们设计的页面，花几天几夜倒是做出了原型，但与别人已经生成了可使用的模块相比，效率之差异实在是不可同日而语，效率固然可佳，方法实不足取。
软件厂商之间在终端市场的近似白刃战式的厮杀已经严重影响了IT软件市场的生态环境。于是有越来越多的富有资深技术经验的人及有眼光的软件公司开始考虑向软件业供应链上游迈进。在今后的几年，将会有更多的软件公司向平台产品过渡，采用平台快速开发+咨询实施服务的模式，今后几年，平台产品谁是后来居上，我们大可拭目以待之。谁能长江后浪推前浪，把前浪拍死在沙滩上，我们也可拭目以待之。不管谁是后来居上，我们应该主动向面向平台的开发模式转变，因为这种模式带来的好处是显而易见的。
有很多管理层大概都读过《致加西亚的一封信》吧？我想很多管理层都希望自己的下属具有送信人罗文的精神。于是很多领导最喜欢说的一句话是：“我只要结果。”这个故事实际是“我只要结果”的翻版。是的，管理层对于分配的工作当然是要下属给出结果的，但问题是，领导真的不需要知道过程、关注过程吗？他知道达到这个结果所必须给予的资源吗？也许没有资源的保障也下属也能完成任务，但时间能保证吗？领导不需要关注下属的做事方式是否正确吗？不需要告知下属怎样做是最高效最节省成本的吗？表面上看说这句话似乎领导很雷厉风行很强势很有派头，但存在一个问题，就是管理者的管理方式不够专业。其实决策固然重要，过程控制也是管理的核心所在，比如人人都希望达到“成功”这个目标，这是每个人都想要的结果，但过程不同，结果就大不相同。所以说过程控制比结果更重要，因为控制好过程才会有好的结果。其实“只要结果”的起因是因为不知道如何实现结果才这么说的。那么对于软件开发领域，使用平台产品进行快速二次开发就是一种软件开发过程的选择，选择面向平台开发的方式，其结果就是提高了项目的利润率，并大幅度缩短项目工期。
面向平台开发的时代，在网络上有人提及，由于此时代只是刚揭开一个序幕，谁将是这个时代的主角？我想会包括我，但不仅仅是我，也包括本白皮书的读者，包括真正理解面向平台开发价值的软件公司和软件开发人员。 我们将一起携手拓展新的市场！
第二章 针对企业的平台需求
在传统的开发模式中，当软件公司将产品交付给企业后，经常遇到业务变更不得不增加功能，或者变更了流程或业务规则，怎么办？找软件公司，但项目已交付且过了维护期。找他们增加模块，还要再次讨价还价。软件公司完全有理由说当时需求就是这么定的，谁让你需求老变，难道非要变吗？不变不行吗？
其实，企业的需求就是变化的。平台产品的目标就是要能做到随需而变。那么企业可能有哪些需求变化呢？
（1） 业务流程路线发生改变。
（2） 业务流程路线没改变，但流程分支的流转条件变了。
（3） 有新的模块需要加到新的系统里。
（4） 表单字段的校验规则变了，比如古时候的身份证是15位的，现在有18位的了，设计的时候没想到吧。还有姓名校验规则，要么全中文，要么全英文，但公司招聘了一个叫赵D的，让人力资源的MM瞪着屏幕很是为难，因为名字一般是不可以这样子叫的，但特殊的情况出现了，录不进去啊，怎么办？找信息中心想办法解决。
（5） 销售订单的单号规则变了，流水号原来是XXXX年XX月+6位流水号，现在变为XXXX年XX月XX日+4位流水号，怎么办？
（6） 公司决定要买Oralce数据库替换Mysql数据库以提高数据库性能。(假定，也许事实是，Oracle比Mysql性能优越)。
（7） 公司决定系统要支持多语言，天啊，怎么不早说呢？仔细看看产品手册，原来多语从设计上已经支持了，只要找到对应的外文单词，录到系统里，一编译，一切换，眼睛就这么一闭，一睁的功夫，外文在页面上显示出来了。
（8） 页面的皮肤有些难看，想换种风格。
（9） 领导又想出一个怪报表，让信息中心迅速按这个格式在明天上午之前统计出来。
（10） 业务部门要求在销售订单查询页面增加一个查询字段。
（11） …,好象还有很多的样子。
以上问题如何处理？如果某企业购买的产品是基于平台的可定制性很强的产品，以上问题也许不会成为问题。如果您是信息中心主任，您可能会认为您在本公司做的最值得骄傲的事情是选对了软件公司，选对了软件产品。基于以上问题，流程变化了嘛，有工作流产品来进行流程变更，模块要新增？平台里有单表，主明细表生成器，生成完就可以用了，字段校验规则要变，不用担心，平台早就考虑了，设置一下就可以了，别说中英文混合的名字可以录，即使将来有中韩文，或中日文混合的也可以录，毕竟咱的平台支持多语啊，一个页面可以显示多国文字，很酷的，这是UTF-8格式的页面，不是GBK的。订单流水号规则变了，简单的规则系统已经考虑了，复杂的在系统指定的代码路径下自己创建个默认值生成器类就可以了，我信息中心主任多少也会点java,当然我下面有人会，而且当年软件公司培训过我们的开发人员，不需要我事必躬亲；至于替换数据库，平台据称是跨数据库的，因为用的是hibernate,这个ORM产品可是支持多数据库的。至于页面上增加一个查询字段，这个太容易了，不需要改动程序的，我只需要在系统里设置这个字段是查询字段就可以了。其他的皮肤切换啊，报表啊，似乎都可以搞定。
对于这样的随需应变的软件产品(IBM老这么说)，您是不是觉得做产品的软件公司很牛？可能你会觉得您更牛，因为选择这个软件商是您的决定，您的眼光使您认为你更牛，因为您已经把一切的变化都考虑在其中了。您早就知道这样的哲理：变是永远的不变，所以软件产品必须能应对需求变更。
您认为如此灵活的软件是否降低了公司对软件商的依赖呢？也许是的，软件商之于企业，就好比是医生与病人的关系一样，医生是专门为病人而存在的职业，软件商也是一样。但如果没了病人，医生可以指导大家如何活的更健康，生命更长久，软件商也可以为企业做流程优化啊，做信息化咨询，第一阶段的信息化蓝图实现了，还有以后的信息化蓝图有待规划和实现。其实企业对于自己的软件供应商提供的产品永远都是苛求的，企业的信息化成功实施也是我们希望的，产品的趋于完美也是企业和我们共同期望的，一句话，你的苛求会使我成功，你的成功会使我骄傲。
除了以上的随需应变，平台产品还能给企业带来其他的好处吗？答案是的。但需要补充说明的一点是，此平台必须是开放的平台（说到开放性，就是说平台厂商应该提供大部分平台源代码给企业，业务产品另当别论）。开放的平台为企业提供了一个框架标准，这个框架标准是透明的，大家都知道针对这个平台，字段校验器程序代码该在什么地方修改，新增一个业务逻辑该在哪里添加新代码。无论项目期间哪位技术牛人离职了，都不会对项目造成重大影响（感觉这样技术牛人就不牛了，但框架标准化和透明化确实带来的是这个效果）。这个标准化和透明化的平台是企业的重要IT资产，而对于软件商的传统开发模式，企业实际上是不能参与到产品开发过程中（只起到提需求的作用），软件商提供的产品对企业而言完全是个黑盒子，谁也无法知道这个黑盒子里到底埋藏着什么隐患。另外，不同软件商采用的软件开发技术五花八门，根本没办法统一。企业都知道做VI形象设计的时候，要有统一一致的颜色格调，其实做软件也是一样。我们经常看到有的企业，光数据库就什么都有，oracle,sql server,mysql，凡市场有的数据库他们一个都没缺，这是为什么呢？因为他们选用的软件商的产品有的对数据库，应用服务器类型等有严重的依赖，就是说软件公司的产品本身就没有考虑复杂的企业实际情况，而是为了节省开发成本，只选择在特定的数据库下开发，更没有做过多数据库的测试，这导致企业必须什么数据库都要准备着。不光数据库，对于web应用的实现，如果有的产品用.NET,有的产品用java ，而java里同一个技术领域又有很多分支，比如应用服务器有websphere,weblogic,数据库ORM产品又有hibernate,ibatis,这些产品如果一直由软件供应商维护还好说，但如果过了维护期不续签维护协议，由信息中心来维护的话，那将是一个很头疼的问题。所以说，一个企业，必须有统一的平台架构标准，这也许是在描绘企业信息化蓝图中很重要的内容。一个好的平台产品，要能支持多数据库，多种主流应用服务器，操作系统除了windows,至少还要支持linux,等等，这样就会使企业具有选择软件运行环境的自由，同时也减少了同类产品的重复投资，比如不需要买两种数据库产品(盗版另当别论)。
作为软件供应商，我们要设身处地的为企业着想，企业是要买这个平台，在这个平台上有能力进行自主开发(平台已经降低了开发的难度)，需要在一定程度理解平台的架构，而且企业的软件往往是多个软件厂家提供的，软件之间的集成是不可避免地，熟悉了软件的架构，更有利企业的应用集成，好的平台应该能相对方便地开发新的接口与其他应用系统交互。如果企业有了统一的平台架构，基于这个基础架构，大家都在这个架构上做开发，我想在实施SOA也会更容易，会节省更多的开发时间。
第三章 平台产品的构成
一个完整的平台产品应该具有哪些内容或功能呢？有哪些内容是业务无关的，适合归纳到平台产品中？我认为，平台产品应该具有以下功能或特性：
（1） 兼容性：应支持多种主流关系数据库，应用服务器，至少支持windows和linux操作系统。
（2） 具有完整的统一认证和单点登录（SSO）解决方案，支持LDAP认证,CAS单点登录等。
（3） 具有完整的工作流实现。包括GUI图形工作流设计器，工作流引擎，工作流监控等。
（4） 提供表单定义器或表单模板，可由用户在线定制表单。
（5） 至少提供一套统一风格的页面样式，最好能灵活切换页面皮肤。在产品中应有统一的UI框架(如EXT,FLEX或者自行设计的UI框架)。
（6） 数据库管理工具。可通过数据库管理工具维护表和表字段数据，并通过平台可以建数据库表，并自动生成针对数据库表的java实体类、相关xml配置文件等。最好能提供数据库表结构文档生成器。
（7） 各种单表，主明细表，树型结构等风格的页面创建向导，这样普通的增删改查类页面通过平台生成就可以了，不需要或很少需要手工编写代码。支持页面字段校验灵活设置和页面字段默认值生成器。生成的页面应具有分页，排序，定制查询、编辑、删除等功能。
（8） EAI管理工具。提供数据同步，数据交换的实现。EAI工具应既能支持内网的数据库间的数据交换，也能支持基于MOM(消息中间件)技术的数据交换。
（9） 分析决策：主要包括WEB报表定义工具、 OLAP及决策支持（管理驾驶舱），提供ETL数据抽取，带图表的多维数据分析工具（支持数据钻取，旋转，切片，数据挖掘）。
（10） 具有完整的多语解决方案。
（11） 具有完整的组织结构、用户、角色体系。
（12） 权限管理与安全框架：支持按权限显示功能菜单，URL及WEB目录权限控制，页面按钮、接口方法级别的权限控制，权限分配到组织结构、角色、个人的多角度的授权方式，支持角色权限继承，支持权限的委托与回收等。支持行记录级的数据查询、修改、删除权限。
（13） 对门户技术的支持，如portal首页定制，portlet管理，支持树型的门户（如子公司门户，部门门户），支持标准JSR168规范，WSRP</