beetle-j2ee-application-framework框架介绍.md

Posted 2023-03-01 jieniyimiao

1.楔子

甲壳虫，一个功能强大而简单易用的J2EE应用开发框架。它涵盖了J2EE体系结构的表示层、业务层和持久层，为构建一个可靠、高性能、可扩展、灵活缩放的高质量企业应用系统提供了一套理想的解决方案。
BJAF(beetle-j2ee-application-framework)是一个在2008年开源的J2EE框架，类似于现在的Spring，只不过没有流行起来而已，具备了企业级开发的大部分特性，框架写的比较简单、非常适合学习使用。

2.首页&文档&源码

https://code.google.com/archive/p/beetle-j2ee-application-framework/

文档和代码
https://code.google.com/archive/p/beetle-j2ee-application-framework/downloads

3.BJAF概述

当前J2EE技术虽然说十分成熟，但可惜的是在实际中很多采取J2EE技术开发的信息系统效果不尽人意，其投资与回报往往令人失望。为了解决J2EE开发领域中所遇到的各种难题，市场上涌现了不少J2EE应用开发框架，BJAF甲壳虫J2EE应用框架便是其中的优秀一员。
BJAF对J2EE体系结构中各层次的技术进行了透明的封装，为开发人员提供了一套灵活缩放、高可靠、可扩展、高性能的J2EE企业级应用开发的解决方案。
在本开发指南中，我们会向读者展现和介绍BJAF框架中各个功能模块及其具体的技术细节，以便读者使用BJAF框架快速投入具体项目开发中。

4. BJAF是什么

BJAF 是甲壳虫 J2EE 应用框架（Beetle J2EE Application Framework）的简写，它并不是一个可以即时看见和运行的应用系统，它为构建于 J2EE 之上的应用系统定义了一个固定而有效的设计开发框架，简化 J2EE 应用，尤其加速了 J2EE 应用的开发过程。
BJAF 的最终目标是为开发人员提供一个填空式的开发框架。让开发人员在 BJAF 架构下，只需关注编写和具体业务逻辑相关的程序，而将业务无关的需求（非功能需求，non-functional requirement）交给 BJAF 来完成。

5.Q&A

5.1 当前流行Struts、Spring、hibernate等框架已经相当成熟，还有必要开发新的框架吗？

这是相当有必要的。设计策略的不同，导致了解决问题的方法不同，这无疑决定了框架的多样性。像Web表示层框架，除了Struts还有WebWork、Turbine、Echo、MaveRick等等；类似于Spring的框架还有realMethods、Keel、Expresso等；而相似于hibernate的持久层框架就更多了ibatis、jdo、jpa、JULP、Mr.Persister、TopLink等等。没有一种框架能够同时满足所有开发设计策略的需求，所以是百花齐放才是常态。
另外，所谓的“成熟”也是相对的，当前流行的Struts、Spring、hibernate也是存在不少缺点的，对它们的批评的声音从来都是不绝于耳的。只有根据项目需求、开发团队技术能力等因素的具体情况，选择或开发一个适合自身需要的框架才是解决问题之道。

5.2国人开发框架比得上国外的产品吗？

这是一个我们在推广框架经常被客户问到的问题。我们民族工业多年相对落后，造成国外产品优胜印象，客户的这种疑虑我们是可以理解的。不过，相对其它传统行业，信息技术产业，特别是互联网技术行业，国内是和国外技术发展是同步的。
特别地，对于J2EE这种标准规范来说，其技术基本上都是公开的，构建于这个标准规范上面的框架产品说白了就是一套共通重用性功能组件而已，基本上没有什么高深技术，只是开发策略和设计理念的不同而已。所以，在J2EE领域强行区分国内、国外来讨论国产好还是国外好没有必要，它们应该放在同一个水平线来评估。
反而，国产框架由于源于国内需求经验而开发，往往更符合国情。

5.3甲壳虫框架与当前“Struts+Spring+hibernate”典型框架组合有什么区别和优势？

甲壳虫框架涵盖了J2EE技术体系的表示层、业务层和持久层，是针对J2EE应用开发的一套完整的解决方案。
（1）在持久层我们提供的类似于微软ADO模式数据存取框架，真对数据存取操作的实际需求提供了组件化的操作组件，而且同样解决了常见O/R映射框架自动装配数据的便利特点。与hibernate试图提供给完整O/R映射解决方案不同，我们追求的是编程的便利性、可维护性、执行效率和解决问题的实用性。因为我们理念是，当前所有的企业级数据库系统都是关系模型的数据库产品，这是决定O/R映射框架先天不足的根本而无法改变的原因。随着业务需求、数据存储形式、查询条件等多样性和复杂化，hibernate在内存消耗、解决能力、灵活性和执行效率方面都显得中气不足。面对这些hibernate不胜任地方，开发不得不采取其它框架或低级jdbc api来解决，一个应用涉及多套解决方案，这无疑又对代码的整合性和可维护性带来挑战。实践经验告诉我们，一个业务简单应用hibernate解决问题能力的比率大概8:2或再高点，如果是一个业务复杂企业系统，这个比率往往只有4:6甚至更低点。使用我们持久层框架就不存在这中问题，凡是jdbc和sql能解决的问题，我们都能解决，因为我们只是对这些低级api方便性封装而没有改变和约束它们访问数据库能力。

（2）在Web表示层当前流行的Web框架类型主要有事件驱动和请求驱动两种。甲壳虫Web子框架和Struts一样都是基于MVC Model2模型的请求驱动框架。所以，它们在开发方式上很相像，但是具体开发细节和设计策略上面却有很大不同。Struts臃肿而且配置复杂，甲壳虫Web简洁而配置简易，开发快速、实用出发功能更为强大，性能更优秀、可控性更好。

（3）在业务领域，J2EE标准规范中是EJB 会话Bean组件的范畴，Spring针对EJB使用难度较大的情况，利用IOC模式重新构建了一个POJO（普通java Bean）的生命周期管理微容器，并以之为基础，集成当前开源世界各个功能开发组件，使得开发和测试上大为便利，因而倍受欢迎。显然Spring Bean容器和EJB容器对应的，也就是说Spring提供了一个替换EJB容器的解决方案，这也就是为什么Spring社区鼓吹“without EJB”的原因了。Spring把自己在业务领域叫做集成（integration），它的目的是用POJO来衔接表示层和持久层（EJB容器目的一样，只是用的是Session Bean而不是POJO，这也是EJB3出来Spring受到很大冲击的根本原因）。所以，严格意义来说，Spring Bean和EJB只是一个容器组件模型而不足以称为一个业务层的框架。 因为我们认为一个业务层框架必须具备以下基本特征：
清晰明确业务开发界定，具备控制或限制开发人员出现越界设计情况的能力。在众多的逻辑中，明确界定业务逻辑领域范畴。甲壳虫业务框架对Use Case的业务过程的事件流提供了明确的指引和封装。

模式化的编程模型，保障所有的业务逻辑的开发方式和风格的一致性和代码的质量的可控性。无论EJB还是Spring在业务层都没有提供一个模式化的编程模型，编写业务bean各种各样，代码难以控制、维护和调优。 模式编程模型简单来说就是提供一个封装好的抽象方式或接口。例如：Struts的Action抽象类“public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception”一样，甲壳虫业务层框架对外也提供了Command和Delegate两种形式的业务接口“public void execute() throws CommandException”和“public BsResponse execute(BsRequest BsRequest) throws BusinessException”模式化编程模型是代码维护、控制和调优的基础，也是团队开发的基础。
甲壳虫业务框架凌驾于业务容器（EJB容器或Bean容器）之上，我们既不拒绝EJB容器也不反对Bean容器，消除了开发上的“轻量”与“重量”之分。对于EJB容器我们进行模式化封装，消除了开发EJB难度和Bean容器配置文件的依赖性、复杂性，对于普通开发人员来说，这些都是完全透明的。
作为一个领先的业务框架，甲壳虫业务还具备以下特有功能：
透明的事务处理能力。我们把事务处理界定于业务领域，甲壳虫的业务类中集成了事务功能，保证Use Case业务过程数据的完整性。而且，事务处理方式对于开发人员来说完全是透明的。
透明的分布式和集中式开发能力。无需修改代码，即可支持表示层和业务层体系结构的分离。分布式和集中式应用自由相互切换，使得应用系统具备良好的缩放性。开发人员只需关心业务逻辑的编码，因为其它的一切都是透明的。例如：下面两种部署方式，就是典型情况，对甲壳虫来说，只需设置一个配置文件参数即可支持，无需改动任何代码。
1，集中式
2，Web层和业务层分离
3，多Web层
4，多web层多业务层
框架业务类使用到各种资源连接透明共享的能力。例如：一个业务类体内调用多个数据接口，一般地，一个数据接口消耗一条连接，多个数据接口消耗多条数据库连接。这无疑给并发性能带来很大的挑战。而甲壳虫框架会透明地把这些数据接口共同共享一个数据库连接，大大提供程序的执行效率和系统并发的能力，节省了数据库连接资源。

（4）甲壳虫框架还包含了一个基于Java标准多线程技术构建的用于应用服务器性质程序开发的高效易用框架，这也是“Struts+Spring+hibernate”所不具备的。“Struts+Spring+hibernate”组合，特别是使用了Spring无疑是自己的应用绑定在Spring Bean容器里面，意味着永远抛弃了EJB容器，背着一个“轻量”包袱，这是得不偿失的。

5.4甲壳虫框架的发展历程如何，它成熟吗？

甲壳虫框架具体项目实践和经验积累中，一步步的开发出来的。作者2000年从微软的DNA平台转向Sun公司的J2EE平台，也算是J2EE比较早的一批开发者。甲壳虫框架的核心雏形和设计理念形成于2003年初，当时为了构建一个集中式的证券交易系统，笔者决定构建自己核心应用开发框架。经历2004、2005、2006和2007多年的发展和完善，现在甲壳虫的框架已经相当成熟稳定了，已经应用到诸如：教育、证券、金融财务、互联网等多个行业系统中。

5.5 甲壳虫框架4个子框架能否拆分？与其它框架的集成如何？

甲壳虫J2EE框架涵盖了J2EE体系结构的表示层、业务层、持久层。由于设计领域模型的清晰的界定，甲壳虫框架4个子框架是可以拆分和自由组合的。例如：对于持久层，你偏重于使用O/R映射的hibernate，那么你可以使用“BeetleWeb+BeetleBusinessLogic+Hibernate”，有例如“Struts+Spring+hibernate”当前流行组合换成“BeetleWeb+Spring+Hibernate”，又或者“Struts+BeetleBusinessLogic+hibernate”等。当然按照的设计理念和开发经验，我们认为完全采取甲壳虫框架是最优的解决方案。特别地，我们推荐使用Beetle替换掉Sping作为业务层。因为Spring不足以成为一个业务框架，Beetle带来的好处是不言而喻的。

5.6甲壳虫框架学习曲线如何？

甲壳虫框架学习非常简单，拥有J2EE开发经验的程序员，看看例子代码就能上手。对于新的java初学者，经过1小时的培训就能够投入J2EE应用系统开发。

5.7甲壳虫框架运行环境和兼容如何？

甲壳虫框架采取标准Java技术开发，严格遵守J2EE1.4规范定义。兼容最新的1.5（也称5.0）规范。运行于jdk1.4（含1.4）以上的JVM容器。由于遵守J2EE规范，理论上支持所有通过Sun J2EE验证的J2EE应用服务器。经过我们测试支持的J2EE服务器有：WebLogic（8、9、10）、JBoss（3、4、5）、WebSphere（5、6）、JOnAS4.1、Oracle9iAS、；Web容器有：tomcat（4、5、6）、resin（2、3）

5.8甲壳虫框架免费的吗？其授权协议如何？

无论对商业用户还是个人用户，甲壳虫框架都是免费使用的。我们采取的协议是《甲壳虫J2EE应用框架软件授权协议》（甲壳虫协议）。为什么没有采取当前流行的开源协议呢？事实上，我们开始是准备采取著名Mozilla Public Licence（MPL）协议的，咨询了法律界的朋友，发现MPL协议规定的内容不太适合国内的法律。所以，我们根据MPL内容重新定义了《甲壳虫协议》，主要是避免了一些法律风险。

6.参考文档

• https://code.google.com/archive/p/beetle-j2ee-application-framework/
• 余浩东HenryYu框架开发博客
• 大型网站技术架构分析(余浩东)