导引
作为当前业界最成熟的编程语言的 Java ，以其开发的各类应用，可以说是涉及到每个领域，包括而不限于桌面应用、Web应用、移动应用、智能终端、云端应用、IoT应用、大数据应用、AI应用、区块链应用等等，基本是无所不包，而且围绕Java形成的各类生态圈也蔚然繁荣。同时，以JVM为核心的Java语言也在不断的兼蓄并包其它语言的特性与优点，依然在稳健的发展中。
我们知道，为了保持Java的新特的快速验证和应用采纳，其版本的发布周期早已更改，目前Java SE 14已发布，Java 15的到来也为其不远了。
随着Java SE新特的引入，Java企业版也相应的做了很多更新和改进，尤其为了适应现代的企业级开发和微服务架构风格的应用，最新的企业级Java也已经稳定采用在，最新的企业级Java为 Jakarta EE 8（脱胎于Oracel的Java EE 8，由于托管给Eclipse基金会而重新发布的企业级Java规范，与Java EE 8本质上一样）。
为了更好的理解企业级Java ，那么我们就来总体认识一下最新的Jakarta EE 8，了解一下其规范标准的总体结构组成。
Jakarta EE结构总览
企业级Java由一系列标准规范组成，各个规范的最终实现产品，一般根据产品自身的定位而选择性实现不同标准，而并非强制性要求要实现所有规范，比如 Tomcat 实现为 Servlet 容器，OpenJPA实现了JPA应用规范，glassfish则实现了所有企业级标准。也就是说，开发的 应用程序 所依托的 服务器 产品的实现是按照不同的需求而实现相应规范或全部规范的。
对于企业级Java标准体系构成，总体可以参照如下架构模型来加以理解：
Jakarta EE 8规范体系架构
如图上所示,它描述了Java EE平台架构元素之间的关系。注意，该图显示的是组件元素之间的逻辑关系，而并不意味着将元素物理地划分为单独的机器、进程、地址空间或虚拟机等。
容器 (用单独的矩形表示)是Java EE运行时环境，为矩形上半部分中表示的应用程序组件提供所需的服务。所提供的服务由矩形下半部分的方框表示，一些由应用服务器实现的符合规范的组件。例如，应用客户端容器向应用客户端提供Java消息服务(JMS) APIs以及所表示的其他服务。下面将解释所有这些服务。参见 下图“Java EE标准服务组件”。
箭头表示需要访问Java EE平台的其他部分。应用客户端容器通过JDBC API与数据库系统连接，为应用客户端提供了对Java EE所需数据库的直接访问。由Web容器为JSP页面、JSF应用和servlet提供类似的数据库访问，EJB容器为企业bean提供类似的访问。
如前所述，Java平台标准版(Java SE)的APIs由Java SE运行时环境为每种类型的应用组件提供支持。
Java EE标准服务组件
作为完整Java EE 产品规范需求，产品级 中间件 服务器必须实现其中的一些规范。
而且作为 EE 8产品规范，要完整支持Java SE 8以及由公共注释规范定义的资源和组件生命周期注释(Resource , Resources , PostConstruct ,PreDestroy)。同时，所有企业级产品必须支持JNDI “java:” 命名上下文以及Java Transaction API (JTA)。
对于上述的企业标准规范，其相关组件规范的版本情况，罗列如下：
1) EJB 3.2
2) Servlet 4.0
3) JSP 2.3
4) EL 3.0
5) JMS 2.0
6) JTA 1.2
7) JavaMail 1.6
8) Connector 1.7
9) Web Services 1.4
10) JAX-RS 2.1
11) WebSocket 1.1
12) JSON-P 1.1
13) JSON-B 1.0
14) Concurrency Utilities 1.0
15) Batch 1.0
16) Java EE Management 1.1
17) JACC 1.5
18) JASPIC 1.1
19) Java EE Security 1.0
20) JSP Debugging 1.0
21) JSTL 1.2
22) Web Services Metadata 2.1
23) JSF 2.3
24) Common Annotations 1.3
25) Java Persistence 2.2
26) Bean Validation 2.0
27) Managed Beans 1.0
28) Interceptors 1.2
29) Contexts and Dependency Injection for Java EE 2.0
30) Dependency Injection for Java 1.0
可选实现规范：
1) EJB 3.2 and earlier entity beans and associated EJB QL
2) JAX-RPC 1.1
3) JAXR 1.0
4) Java EE Deployment 1.2
企业级Tomcat：TomEE
TomEE，可对等看作企业级Tomcat，肯定是比作为Servlet容器的Tomcat更强大，简单的记住根本的一条：若无前者Tomcat的存在，则后者TomEE无从谈起。若Tomcat不是能满足你开发软件所要求的后端应用服务器，那你即可以考虑TomEE了
下面我们还是来更明确的梳理一下Tomcat和TomEE。
1 TomEE是Tomcat的升级版
将TomEE看作是Tomcat加上一些花哨的东西这样更容易理解一些，因为TomEE是构建在Tomcat之上的。具体来说，TomEE 8是完整的Tomcat 9发行版加上Jakarta EE 8(以前是Java EE 8)特定的 API 而来的，支持Java EE 8规范的企业级的应用服务器，包含更多的开箱即用的功能脚手架，让开发者更关注业务和应用，而不是技术本身。
Tomcat是一个功能强大且非常流行的Java Web服务器。它实现了四个Jakarta EE web规范。
- Jakarta WebSocket 1.1
- Jakarta Servlet 4.0
- Jakarta Expression Language 3.0
- Jakarta Server Pages 2.3
您可以使用Tomcat单独构建完整的动态web站点，但是Tomcat与Jakarta EE不是同义词。Tomcat本身甚至不能满足Jakarta EE 8 Web Profile(EE规范规范中的一个子集)的最低要求，但是TomEE确实以Jakarta EE 8 Web Profile为目标。TomEE 8扩展了Tomcat 9，并专注于Jakarta EE 8的需求实现。
注意: 在2019年底时，TomEE 8已通过了Jakarta EE 8 Web Profile兼容性测试的96%。相信很快它将是100%兼容的。
2 TomEE 8中的Jakarta EE规范
那么TomEE所拥有的什么是Tomcat没有的呢?最新版本TomEE 8增加了很多Jakarta EE 8 Web Profile所需的企业技术，但在Tomcat中却没有，包括:
1) Jakarta EE Web Profile 8 (Targeted)
2) Jakarta JSON Processing 1.1
3) Jakarta JSON Binding Specification 1.0
4) Jakarta Server Faces 2.3
5) Jakarta Standard Tag Library
6) Jakarta Interceptors 1.2
7) Jakarta Batch 1.0
8) Jakarta Concurrency 1.1
9) Jakarta Contexts and Dependency Injection 2.0
10) Jakarta Annotations 1.3
11) Jakarta Bean Validation 2.0
12) Jakarta Enterprise Beans 3.2
13) Jakarta Connectors 1.7
14) Jakarta Persistence 2.2 (警告:基于openjpa的发行版提供了一个JPA 2.0运行时)
15) Jakarta Messaging 2.0 (layer based on ActiveMQ 5 / JMS 1.1 for default distributions- (基于ActiveMQ 5 / JMS 1.1的层，用于默认发行版))
16) Jakarta Transactions 1.3
17) Jakarta Security 1.0
18) Jakarta Authentication 1.1
19) Jakarta Mail 1.6 (NOTE: EE 7 requires 1.5)
20) Jakarta RESTful Web Services 2.1
21) Jakarta Managed Beans 1.0
22) Jakarta Enterprise Web Services 1.4
23) Jakarta Debugging Support for Other Languages 1.0
以上，你可以看作是TomEE8作为应用服务器或所中间件所具有的特性。
3 Jakarta EE:只使用你需要的
所有这些APIs都很重要，这取决于上下文，就像Java SE中的所有APIs都很重要，这取决于您需要什么。在Java SE中，如果您不想使用特定的API(例如Java.rmi)，就不要使用它。没有额外的认知负荷，因为你可以专注于你所需要的，而忽略其他。Jakarta EE也是如此。实现中确实提供了很多，但你可以只专注于你需要的部分。你没必要知道所有的事情，你都可以忽略，直到你确实需要了解时采取研究就行了。
也就是说，如果没有您需要的东西，那么将它集成到项目中是很痛苦的，特别是在所有其他企业级APIs环境中。这就是Jakarta EE的优势所在。Jakarta EE平台的重点不是捆绑一堆不相关的api。Jakarta EE的目的是确保各种有用的企业APIs能和谐地一起发挥作用（可以聚合性的和平共处地工作）。
基于这样的应用服务器的支持，通常我们的企业级Java应用架构类似一下模式：
企业级Java应用架构模式
我们的TomEE就是对应着服务器层。
4 TomEE 版本
TomEE本身有四种风格的产品版本，分别是 TomEE、TomEE JAX-RS、TomEE +（TomEE Plus）和TomEE PluME 。在下一篇文章中，我们将更多地讨论这些风格和Jakarta EE支持的版本，但是现在，你可以假定TomEE的任何版本至少都是针对Jakarta EE 8 Web Profile的要求的，或者说是满足Jakarta EE规范的某一子集要求。
这一部分内容，我们就简要说这些了。下一次，将来谈谈TomEE各个版的异同。
分享出去吧，顺手点个赞或收藏备查。谢谢。
