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协议等。支持个人的个性化门户页面定制，支持个人Blog。
（14） 即时通讯与Mail客户端。企业的即时通讯不仅支持人与人的在线沟通，还应支持当特定的业务时间触发时，事件消息会通过即时通讯传达到相关角色或个人的桌面（即时通讯应开机即运行）。
（15） 在线知识库管理、在线论坛。
（16） 具有内容编辑-发布-页面静态化-自动刷新搜索引擎目录。
（17） 支持站内全文检索，包括html页面，文档及可定义表字段的数据库全文检索。
（18） 其他功能性应用组件及非功能性特性。如定时器配置，业务对象状态监控，消息日志，流量监控制、邮件定时群发，跨数据库事务管理，声明式事务配置等。
（19） 在线编译工具，能很方便地在平台运行页面中直接编译生成的代码，完全脱离IDE开发环境。
以上功能大概可归纳为五个方面：
（1） 信息的采集。包括基本信息，各种单据录入等。
（2） 信息的交流：Email,即时通信等。
（3） 信息的控制：功能权限，数据权限的管理。
（4） 流程的管理：工作流。
（5） 分析决策：报表，OLAP数据分析，商务智能等。
第四章 OpenJWeb快速开发平台介绍
4.1 什么是OpenJWeb?
OpenJWeb是一款开源的Java Web应用快速开发平台产品。此产品主要解决以下几个问题：
（1） 在企业应用开发中，组织结构，权限，功能菜单管理等基础模块，因为没有进行良好的设计，导致在不同的项目中不能直接重用，还要做大量修改才能在新的项目中使用。
（2） 对于单表，主明细表类的增删改查，由于开发模式相似，但由于没有代码、页面生成器，导致程序员即使开发一个相似的功能，也要花大量的时间进行编码和调试。开发效率非常低。开发人员经常因为查找一个BUG花费大量时间调试，调试完才发现不是有的地方在复制代码的过程中漏改了，就是有的地方大小写拼写错误等等。
（3） 在国内，大量的公司，大量的项目开发人员都不可避免地要实现组织结构，权限等基本每个业务系统都必备的基础功能，如果有一个好的开源的平台，大家就不需要在这些基础模块上投入不必要的开发时间，有这样的平台能大大降低社会资源的重复投入。
（4） 当字段校验规则，字段默认值规则发生变化，页面中需要增加一个新的查询条件列，应该不需要开发人员再修改程序代码，这样通过平台实现字段校验器设置，默认值规则设置，增加或减少一个查询字段，就不需要更改程序了。
（5） 新的开发人员加入团队后，稍微加以培训，就会了解应该在什么地方添加业务逻辑，在什么地方增加新的校验类等等，能否在很短的时间内就融入到开发环节中。
（6） 由于开源框架众多，选择什么框架，并将这些框架有机集成起来，然后针对这些框架做出开发平台，没有丰富的Java开发经验是难以完成的。但有了统一的集成好的框架，开发人员不需要再为java产品的选型头疼了（前提是相信我的选择）。
以上几点的最终目的，就是统一规范，减少重复投入，降低开发成本，提高项目利润。同时也会提高Java开发人员的技术水平，大大缩短开发人员成为架构师的所需要的时间。
4.2 OpenJWeb的主要技术框架
OpenJWeb 1.6版本的基础框架是struts2+Spring2.5.6+hibernate3+Spring security2.0，另外还有strut1(部分功能是以前开发的),dwr,fckedit,extjs,图表采用JFreechart,树控件采用dhtmlxTree。另外还集成了JOTM，这个是在tomcat中的JTA，支持跨数据库事务处理。
4.3 OpenJWeb的商业价值浅析
很多软件公司为企业开发应用系统，往往动辄一年甚至更久，如此长的开发实施周期，导致项目还没有实施完，需求已经发生很大变化，所以OpenJWeb从开发模式上采用平台定制+二次开发辅助的模式可大大减少项目的开发工作量，缩短项目的实施周期，甚至后期都可以由用户自己定制业务模块，因而避免了软件公司交付产品后，新的业务需求仍然需要软件公司开发的局面。
应该说，对于越大型的企业应用项目，OpenJWeb节省的成本越显著。这体现在：
（1） 一般企业应用都有大量的后台维护模块，而这些模块的开发很多都不可避免地要解决页面JSP文件的开发，分页、排序功能的处理，增删改查功能的实现，数据库建表，以及页面中涉及到代码-名称列表的下拉窗口的检索等等很多开发内容，如果没有一个平台工具提供快速开发支持的话，一个象简单的客户基本信息维护这样的功能至少也得两天的时间才能完成，而使用平台工具开发的话，只需要十几分钟的定制的时间就可以轻松搞定。两天和十几分钟的差异绝对不是一个小数目，对于一个百万元的项目而言，使用平台开发至少可以节省20万以上的项目成本。对于软件公司而言，减少20%的项目成本就意味着项目提高20%的利润率！OpenJweb的快速功能生成器在项目开发中的效率，是传统的软件开发模式是不能匹敌的，只要数据结构设计出来，功能就可以生成出来。在做项目需求原型的时候是极其有帮助的。
（2） OpenJWeb平台对开源社区的框架产品进行了很好的整合，同时也经过了若干大型项目的验证，使用OpenJWeb平台的用户因而可以避免重复选型的风险，也节省了重新搭建应用框架的时间。
（3） 基于平台产品进行应用开发和实施是以后软件行业的主要模式，使用平台产品进行开发可以使软件公司完全摆脱手工作坊式的研发时代，对于大型项目的实施也不再需要靠大量招聘开发人员这种非常耗费成本的实施方式。另外，成熟的平台减少了代码出错率，这也在很大程度上减少了修改错误代码的时间。
（4） 成熟的开发平台具有透明的一致的开发模式和框架，因而项目人员的变动不会对产品的体系架构产品影响。因而很大程度上减少了关键人员离职造成项目失败的风险。
（5） 平台产品已经实现了增删改查生成，组织结构权限，数据权限控制，字段校验器，业务逻辑生成器，默认值设置，代码表管理等很多功能，不需要用户再进行同类功能的重复开发。
（6） 此平台不仅对软件公司，最终用户有很大的应用价值，同时对于Java开发人
员来说是一个很好的学习平台，具有很大的学习价值和培训价值。OpenJWeb平台由于有机集成了开源领域的众多产品，为Java人员提供了Java开源技术“一站式”学习通道，能在很短的时间内掌握这些开源技术的使用方式。通过OpenJWeb的学习和使用可以使Java人员在很短的时内提高自己的技术水平，从而使自己在竞争激烈的职场中脱颖而出。基于以上这些价值，OpenJweb快速开发平台也是培训机构很好的实战教材。
4.4 OpenJWeb的主要用户群体
(1) 对于还没有或者刚选择Java平台的软件公司，本平台已经具有了很多开发好的功能，不需要重复开发。可直接使用平台提供的社区版。
(2) 对以于项目实施为主的软件公司(按项目定制开发)，使用此平台开发项目可以大大减少开发工作量。
(3) 咨询人员：咨询人员使用此平台可以在很短的时间定制一个原型应用，因而使得在打单或需求调研过程中迅速给客户展示一个应用系统模型。
(4) 企业用户。使用此平台使得在软件公司的服务到期后，仍可以使用平台来定制自己的新的业务应用,而不再依赖于软件公司，从而真正做到随需应变。
(5) 培训机构。OpenJWeb平台是一个不可多得的基于开源框架的快速Web应用开发平台，一般IT培训机构是很难获取到这种具有实战价值的代码，针对OpenJWeb平台进行Java培训一定可以使学员在相对短暂的培训期间体验到真正的企业级应用开发。
（6）个体创业者或者中小软件公司。对于中小软件公司是没有资金去聘请一个专职的高级架构师，引入一个优秀的开源平台进行软件开发是他们最好的选择。
4.5 OpenJWeb1.6版本的主要功能特点
本章节只介绍功能特点，具体的功能画面和操作方法见《操作手册》。
4.5.1 多语言支持
可在登录后的系统首页通过点语种连接来切换不同的语种（不过目前有许多页面没做文字翻译，只翻译了个别单词可以看到语种切换的效果）。
表单列表页面和编辑页面的标签支持多语，只需要在表字段定义中定义各语种文字，从平台编译代码后，能自动生成对应的多语资源文件。
4.5.2 Portlet风格的首页
带Portlet风格的后台首页，可实现Portlet窗口的拖拉，目前设置了我的待办任务，我的已办任务等Portlet（目前尚未设计OA及工作流系统，所以Porlet中的信息目前是演示数据）。
4.5.3 在线编译功能
通过平台生成功能代码后，不需要在IDE开发环境中执行代码编译，可直接在页面中点“编译代码”，编译完成后新代码生效。
4.5.4 提供了定时器开发接口
平台已提供了定时器的具体开发和配置的例子，用户只需要在指定的定时期类中增加自己的新的定时器方法，并在Spring配置文件中稍作配置即可。
4.5.5 提供了邮件发送API调用接口
平台已提供带HTML格式的多附件发送调用API,利用这个API可很方便地实现邮件群发。
4.5.6 集成了FckEdit在线编辑器
本平台提供了基于FckEdit的可视化的在线编辑器。
4.5.7 提供了业务逻辑组件接口和实现类的生成功能
当建表时，如果选择生成业务逻辑组件，则自动生成业务逻辑接口和实现类。并自动在Spring配置文件中进行配置
4.5.8 支持基于JTA的跨数据库事务
可实现跨数据库的事务控制，当指定异常抛出时，可在两个数据库中同时回滚。
4.5.9 表结构管理
定义了表和表字段后，可生成数据库表、Hibernate映射文件和Java实体类。表字段定义中可定义字段的类型，长度，是否非空，各语种标签文字，使用哪些字段校验器，默认值生成规则设置，表字段在列表页面和编辑页面是否显示，显示顺序，表字段的输入方式（输入框，日期选择，弹出窗口，下拉列表等多种输入形式）、表字段是否为查询条件字段等。
另外表字段维护中还增加了生成表字段功能，用于在表已经建立后，如果增加新的字段，就不再需要从开发环境中开发实体类，hibernate映射文件进行修改，也不需要打开数据库管理工具增加新的字段，只需要在页面上执行操作就可以完成以上内容。
4.5.10 代码表管理
也称数据字典管理，主要用于页面上下拉列表的下拉选项的定义。例如职称可定义001工程师,002高级工程师；用户既可定义代码表位于专用的数据字典表，也可以指定任意表的两个字段作为代码字段和名称字段。如果同一类型的代码不是很多（少于50条），可以用代码表管理，代码表的明细项如果太多，推荐专门建表维护，这时别的字段如参照使用本代码表，应该使用弹出窗口进行选择。
4.5.11 功能定义
可针对一个数据库表创建单表增删改查页面。也可创建主明细表增删改查页面（可带多个tab）。建主明细表时需要维护主表和明细表对照关系。在本页面配置好功能相关属性后，点“生成代码”，可生成struts2的action配置文件，action控制层类，列表页面，编辑页面，弹出窗口选择页面（每个功能都有可能作为别的页面字段的参照输入）。如果此页面中设置了要创建的表单类型（单表/主表/明细表），则可分别针对不同的表单类型创建对应风格的页面。
4.5.12 数据权限定义
可指定一个表设置针对不同用户的不同的数据权限，包括查询权限，修改和删除权限。
4.5.13 字段校验器
平台可从字段校验器表中读取字段校验器类进行保存前的数据校验。如果用户开发了新的校验器（需要实现校验器接口），可录入到数据库中，然后在表字段定义中选择性地绑定需要的校验器。
4.5.14 查询
平台生成的页面中有显示在列表页面查询列，如果想增加或减少查询列，只需要修改表字段定义中的是否查询字段，将是否查询条件设置为“否”，然后重新生成此功能的代码即可。另外组合查询中可定义关于查询表的任意字段，并可以带括号组合自己的查询条件的逻辑关系。本平台的查询条件字段的输入方式是随着配置的输入形态自动改变的，例如是日期输入，则查询条件自动显示日期选择器，如果是弹出窗口，自动显示弹出按钮，如果是下拉列表，查询条件列自动检索出列表项。
4.5.15 权限维护
维护一个权限树。权限树中可定义功能菜单权限，按钮权限等。如果设置了URL，则没有授权的用户不能访问URL,此表是Spring Security框架读取权限信息的表，是权限框架的核心数据哭表。
4.5.16 公司基本信息维护
维护顶级法人公司列表。是组织结构树的根，在这里可以录入本公司，客户公司。如客户公司因业务需要需在本系统建立自己的组织结构和用户，则需要在这里注册公司信息。
4.5.16 组织结构维护
可选择一个顶级公司维护组织结构树，组织结构树可定义行政部门、客户、供应商、角色、岗位、业务组等多种类型组织结构，可以在一个组织结构下维护人员信息，同时也可以维护一个多对多的组织结构-人员关系，比如某个组织结构节点为角色，则可以将属于此角色的人员添加进来。这样形成了一个多对多的矩阵型组织结构-人员关系，如果此组织结构被授予权限，则直属此组织结构的人员可以获得组织结构权限；另外，角色权限可以继承，即上级角色可以具有下级角色的权限；
另外系统还可直接对人员授权。这样一个人员的权限就包括了直接授权，从组织结构获得权限，从角色型组织结构获得权限及继承权限，这样构成了一个完整的授权体系。
第五章 开发路线图（Roadmap）及其他
<1> 将页脚(footer)的公司中文版权信息和英文版权信息放到配置文件中。
<2>可对字段的是否显示，是否可写实现权限控制，而不是手工打开JSP页面增加权限标签，另外考虑在流程审批中字段是否可读写的控制跟流程的进度进行关联。例如员工在填写请假单是可录入请假时间和事由，但不能填写（或应隐藏）审批意见字段。在总经理审批环境可以录入审批意见，但不能更改请假事由和请假时间字段。
<3>树型功能维护页面生成器：上版本已实现，本版本需参考上一版本实现。
<4>工作流设计，含图形工作流定义，考虑是否集成JBPM
<5>将Spring Security与CAS单点登录产品进行集成。
<6>基于AOP的日志拦截器的实现。
<7>针对多种关系数据库的建表工具
<8>可从系统中生成数据库表结构定义的PDF及WORD格式文档。
<9>功能定义可设置新的操作按钮，并设置与action方法的对照关系，是否在对应的业务逻辑中也增加接口方法和实现方法。
<10> 新功能生成可配置是否将功能与权限表挂接（有的功能不具有独立的功能菜单，如主明细表的子表，有对应的URL但不是通过功能菜单访问的，而是在主明细页面中选择主表记录后在子表iframe中显示明细。
<11>针对收费用户编写的二次开发培训手册。
<12>新建功能自动为超级管理员分配权限
<13>sitemesh样式控制及修改
<14>设置业务对象的状态监控器，状态变化时是否生成相关信息并通知对应的角色，并推到相关人员即时通信窗口中。设定监督哪些数据库表字段状态变化，产生提醒或警告消息，必要的时候自动发送邮件通知。
<15>多语的完整实现：目前标签的多语实现了，但数据库哪些字段需要多语并做灵活配置没有控制，平台模块的标签的全部翻译英日韩文字。白皮书，安装手册，操作手册的多语版本。
<16>sourceforge，华军软件园等网站发布平台免费版本。免费版本控制试用期限。
<17>增加数据状态控制（增加逻辑删除状态-垃圾箱）、已拖入垃圾箱数据的回收。数据状态初始值设置及启用。
<18>权限的委托与回收，个人权限列表查询（及权限来源）。
<19>特殊权限设置，设定个别权限不能为指定用户使用，虽然此用户通过角色拥有了权限。
<20>列表页面的分页器增加按分组显示的页码，并可设定每页面行数及跳转页面（参考上版本）。
<21> EXCEL数据的导入导出。
<22>增加子系统列表维护模块及必要的配置字段。
<23>寻找一个可读写XML的好用的程序代码。
<24>简易的CMS,可创建栏目树，信息发布，及静态化，并加到搜索引擎
<25>站内搜索引擎的优化,数据库全文检索的实现
<26>快速开发平台竞争对手资料分析
<27>工作流关键字搜索及资料学习
<28>prortal页面定义工具(可拆分表格，并在表格中添加页面元素)
<29> webform表但定义工具
<30>报表与图表,JFreechart集成，图表可展示到Ext的portal中。
<31>BI基础开发，OLAP钻取，旋转，切片的实现
<32>通过平台作出一个OA产品
<33>进销存，电子商务产品
<34>OpenJWeb技术网站搭建及运营
<35>销售推广方案及构建销售渠道，寻找合作伙伴
<36>考虑是否使用ext作为后台页面样式，如果这样需要设计生成器模板
<37>开发一个邮件群组维护功能，可以编辑邮件后向群组用户发送邮件，用于产品宣传。