本文为金蝶天燕Apusic20周年书籍的中关于Java EE技术内容，我进行梳理写出来分享给大家。如果对其中的部分阶段演进有疑问，可以在评论区提问。
开端
Java EE发展和现状
Java EE的全称是Java Platform, Enterprise Edition，Java平台企业版。刚推出时用的名称是J2EE（Java 2 Platform Enterprise Edition），这个2表示Java第二版本，即 Java 1.2。
Sun公司在推出Java第二版本时，定位是新一代的编程语言，并设计了三个不同用途的大版本：J2SE(Standard Edition)为标准版，面向桌面应用软件；J2EE为企业版，面向企业级分布式网络编程；J2ME(Micro Edition)为微缩版，用来做消费类电子产品的软件开发。
可以说Java成为当今应用开发最广泛的编程语言，Java EE（J2EE）起到非常大的作用。2000年时互联网快速发展，各种服务器技术涌现出来，开发者需要一种可以跨平台，适合网络编程的语言和应用运行平台，J2EE生逢其时。当时业界的标准是Corba技术，支持C/C++等多种语言，可以跨平台但没有办法做到“编写一次，到处运行”。
J2EE受Corba的设计的影响较大，早期EJB的Home，接口和实现就是仿照Corba在C语言的实现的，并移植到Java语言之中。J2EE中的Servlet规范获得了极大的成功，配合模板技术如JSP等很快成为主流的网络应用开发方式。
J2EE 1.3规范推出时，包括了如Servlet, JSP, EJB, JNDI, JMS, SOAP等技术，具备了完整的企业开发平台能力。利用这个平台，可以设计出绝大多数企业级应用架构。国际性的大型软件公司纷纷在J2EE上进行投资，一些公司获得了丰厚的回报，同时这些公司又进一步投资Java技术，从而奠定Java语言成为软件开发主流的位置。
2006年5月， Java EE 5发布，版本号演进方式从1.X 改成 X 的大版本，J2EE也改名为Java EE。这个版本最主要是EJB3.0的版本升级，在此之前，EJB2.X版本被广泛质疑，Spring Framework创建者Rod Johnson在经典书籍“J2EE Development without EJB“中，对EJB2代表的分布式对象的设计方法予以批驳。EJB3经过改造，使用注解方式，应用服务器对POJO对象进行增强来实现分布式服务能力。某种程度来说，EJB3挽救了Java EE的过早消亡。
2009年12月，Java EE 6发布，这个版本应该说是Java EE改进最大，影响最深远的一个版本。因为在Java EE 5中只有EJB3适应了Java注解语法的加入，而EE6全面接纳了注解。CDI和BeanValidation规范的加入，使得在POJO对象之上可以定义完备的语义，进行加载或者运行时处理，由容器来决定如何实现业务功能和非业务的操作。同时Servlet也升级到3.0版本，在接口上加入异步支持，使得系统整体效率可以大幅提高。Java EE划分为Full Platform和Web Profile，用户可以根据自己的需要选择不同的功能集。
2016年初，Oracle对于Java EE的技术热情持续下降，Reza Rahman针对提出Java EE Guardians (Java EE守护者)计划，来向Oracle谏言应投入更多的力量在Java EE之上，这个行动是成功的，很快Oracle高层做出表态，并且推动了Java EE 8的进展。
2016年7月，IBM，Redhat，Tomitribe(TomEE), Payara(PayaraFish)宣布成立Microprofile的组织，提供一个小范围的，面向微服务的规范子集。初期只有JaxRS/CDI/JsonP少数规范，并在2017年2月，加入到Eclispe组织。MicroProfile目前已经发展到3.3版本，有多个开源实现，提供完整的微服务方案。
Java EE 8 在2016年10月的JavaOne大会上正式发布，Java EE 8是在大公司控制下的最后一个版本，接下来Java EE技术体系走向开放之路。经过全球约7000开发者的公开投票，Java EE的下一代名称确定为 "Jakarta EE"。Oracle将这项庞大的技术规范集移交给开源社区 Eclipse。
Jakarta EE于2019年9月发布，完全开源开放。目前社区已经确定了Jakarta EE 9的内容和发布周期，并开始讨论Jakarta EE 10的技术内容。
Java EE规范的本质，是企业级应用软件设计经验的精华凝结，每一个API都经过众多丰富经验的专家反复商议并确定。各个版本之间可以做到向后兼容，也就是说，即使是10年前写的Servlet程序，当前开发者也可以通畅的阅读源码，不需要或者少量代码进行调整，修改部分配置后就可以部署在最新的应用服务器上。另外，现在用Servlet4写的程序，浏览器和服务器通信是使用全新的HTTP/2协议，但开发者在理解上不会有障碍，就是因为Servlet规范的API非常稳定，基本没有大的变动。
Java EE提供了一套稳定的API接口，满足很多大中型企业实际的需求。我在和一些企业信息化负责人交流时，经常能得到这样的反馈，就是希望企业甚至行业中的应用在一个可控、有序的框架下来开发，不用太多采用新的技术，而是成熟稳定，更容易治理。如今企业应用开发用的最多的是Spring框架。但从多个角度去看，有一套API去定界会更好，也就是说Java EE更符合企业主管的真实需求。
我和很多Java开发者交流，包括面试时问到对企业应用开发的深层次问题时，多数开发者只是会用Spring框架，但并没有能够深入了解设计的原理。这个问题的部分原因是因为Spring框架，加上SpringBoot/SpringCloud，即所谓的Spring全家桶实在太庞大了。一般的开发者没有能力去抽丝剥茧的去找到深入学习的方法，也和没有明确接口层定界有关。相对来说，Java EE有较为清晰的规范文档，API，TCK测试用例，就容易学习和理解的多。有了Java EE规范的学习基础，再去学习使用Spring，就容易更深入理解了。
国内Java EE的发展
国内企业和开发者对于Java EE的开发是及时跟进的。
在J2EE热度的时期，中国大陆就是国际软件厂商重点布局的市场，在很多行业都设计、开发、部署了大量J2EE应用系统，软件商，集成商都赚了钱。
国内也有很多开发J2EE应用服务器的厂商和团队，其中金蝶中间件Apusic和Huihoo社区的 JFox是两个做的不错的。
Apusic当时汇聚了国内最用心去做J2EE应用服务器的开发者，核心团队成员报有极大热情去参与国际技术社区，在学习交流，高效而紧张的研发之后，独立开发出了Apusic应用服务器产品。我还记得当时听说金蝶中间件研发出国产应用服务器软件时的惊喜和为止高兴，若干年我加入金蝶天燕（金蝶中间件）公司后首先做的技术方面的工作，就是研读Apusic应用服务器源码：了解微内核体系，组件依赖处理，多路复用IO设计，线程池策略选择等一直好奇的方面。从软件角度来说，这个产品设计在当时无疑是处于国内领先，国际一流位置。
另外一个国内团队开发的JFox，采用了开源协作方式，通过Huihoo社区被Java爱好者所了解。后来其主力成员进入红帽成为我的同事。
国内的软件市场有很大的空间，同时也有一些科研机构也关注这个领域。在Java EE的发展过程中，国内的中间件公司如金蝶，东方通，中创等也陆续加入Sun（后来是Oracle）的JCP组织，参与Java EE规范的设计。
现在市场上各家中间件软件公司都推出了符合规范认证的应用服务器产品：金蝶天燕和普元已经通过最新的Jakarta EE 8认证，中创中间件、东方通、宝兰德则是通过Java EE 8或者7版本的认证。在应用服务器市场，中国公司可以说是非常上心的。我们需要做的是更加推广普及Java EE（Jakarta EE）规范知识，让中国的开发者更加了解这项技术的整体能力。
主题：为何要做中间件产品？
问：您从什么时候开始深度研究学习Java EE技术，您的技术生涯是怎样的？
回答：
我从2000年左右开始接触J2EE相关技术，以学习为主，开发一些网页应用。深度研究这方面的技术是从2002年开始的，当时所在的公司研发J2EE应用服务器，我所在的团队没有直接参与，但会涉及到一些相关的模块。2005年左右，公司开始理解和适应开源技术文化，研究并且成为JBoss合作服务商，负责中华区的服务提供。我从那时起深入研发中间件产品一直到今天。
我的工作是从开发网络软件为开端，用C++语言编写桌面应用程序。后来在工作中涉及到网络管理和企业应用，就开始学习分布式网络，Java语言，数据关系映射等技术。在开发企业应用软件时，面对系统架构设计，项目整体管理等困难问题时，又逐步了解到中间件，软件工程等领域，逐步的深入大范围学习技术知识。
中间件技术即可以深入系统低层，又能通达到实际应用层面，技术含量高，又有一定的趣味性，我选择中间件技术作为我的重点专业领域。后来的工作基本是围绕中间件技术来开展，先后参与开发了多个知名的中间件产品和项目。加入红帽公司之后，又全面理解并接受了开源文化的熏陶：开源中间件成为我的技术能力的主体承载。
问：既然Java EE已经是一个发展迅速且相对成熟的领域，那么为什么还是存在很多“现实的难题”的？
回答：
前面我们说过，中间件是承载应用系统的软件，因为软件的多样性，中间件也有不同的适用范围。基础软件在一定时期，也和当时的计算能力，应用层次有关联。比如说，SOA在2005年时在IBM公司推动下进行市场推广，后来回首看SOA不是很成功，因为当时的webservice，SOAP等技术都太重量级，和实际用户的需求有偏差，技术和工具都不是特别好用。后来的微服务取得巨大的成功，微服务的很多理论都是来源于SOA，但直到今日，微服务在策略定义等方面还没有达到当时SOA实现的技术共识。
另外，不同的应用需求所需要的中间件也是不同的，Java EE适合企业级应用开发，但面对互联网海量用户高并发、大量数据的处理时就显得力不从心，在这些时候就需要如响应式编程技术，批式流式数据处理框架等新兴技术，Java EE设计时间早，没有办法能够完全改进并适应。所以在当前很多互联网应用，Java EE架构并不完全适用，也会遇到很多技术难点，需要综合运用不同的技术。
主题：定义Java EE深度能力技术
问：请从五个方面，功能，性能，安全性，扩展性，易用性讲一下作用及基本原理？
回答：
应用服务器是一个功能丰富而全面的产品，为了兼容性，所有通过认证的应用服务器产品都需要通过Java EE TCK的用例测试，如今Java EE 8 Full Platform子规范有33个，全部完整测试用例有4万多个。即符合规范的功能点就有几万个，各家厂商还会加入很多独有特性，高级功能如负载均衡，容错，安全等，所以应用服务器有众多功能。但基本上来说，很少有软件公司或者应用软件能用上其中的大多数软件功能。
应用服务器功能上比较接近，区别优劣性的一种判定方式就是对比测量性能，几乎每一个规模较大的用户都会要求应用服务器厂商做性能PK。一般是给定几种应用场景，实现功能后部署在应用服务器中做性能压力测试，再进行数值对比。常见的数据有web网络访问，失败率，数据库访问事务时长，消息发送和接收，CPU和内存占用对比等等。性能好，出错率低的产品会赢得客户的青睐，所以应用服务器厂商也会重点关注产品性能的优化。
安全性是非常重要的，应用服务器承载了关键应用，如果非授权用户能否访问敏感数据，或者黑客能拿到用户信息，都是极度危险而不能被接受的。业界有安全漏洞组织和白帽成员来不断的探测，发布并促进厂商修改漏洞，用这种方式来逐步提升产品的安全性。今年内著名的Tomcat产品先后被爆出几个高级别安全漏洞，都及时给出了修正方案。
应用服务器的扩展能力是厂商在产品中定义的，设计优良的产品，可以通过接口扩展的方式来加入新的功能，比如Apusic的应用服务器可以实现服务接口，并向服务器注册来实现扩展。
易用性体现在有方便易用的Web控制台，清晰简洁的命令行工具，描写完整清楚的用户手册等。有了这个工具和文档，用户可以更方便的使用应用服务器产品。
问：之前提到了多路复用IO，其技术原理是怎样的？
回答：
操作系统来分配网络端口，是用一个整数来编号的。对于独立的服务器来说，几万个甚至更多的数字是足够的，但如果服务器作为宿主机来支撑虚拟化或者容器的话，端口号资源就成为宝贵资源。
我们知道不同的网络应用，一般需要监听并接收不同网络端口请求。对于应用服务器来说，往往需要很多网络端口，比如对于JBoss AS 5，在默认全功能情况下，会打开20多个端口，不但浪费端口资源，也容易造成端口冲突使得服务不可用。很多应用服务器产品会采用IO多路复用的方法来重用网络端口，比如JBoss AS 7最少只需要两个端口，分别用作应用和管理功能。
Apusic应用服务器从很早就运用了这项技术，通过定义复用端口，客户应用只需向多路复用端口发出请求，服务器通过分析客户请求，将其转发给相关的服务或是拒绝此请求。这样，在管理应用服务器时，对于在多路复用端口上提供的多种服务，只指定一个多路复用端口即可进行管理。目前，Apusic 应用服务器的 Web 服务、JMS 服务、JNDI 服务，是在一个端口上进行复用。对于安全端口也可以进行这样的配置。
