本博客 猫叔的博客 ,转载请申明出处
先来看看官网对它的定义。
Java平台企业版(Java EE)是社区驱动的企业软件的标准。Java EE是使用Java Community Process开发的,其中包括来自行业专家,商业和开源组织,Java用户组以及无数个人的贡献。每个版本都集成了符合行业需求的新功能,提高了应用程序的可移植性并提高了开发人员的工作效率
Java EE 8,你值得了解,起码官网还提示了你它还在 更新
新的功能。
说到JEE,做web项目的朋友其实都有所了解,它将企业级软件架构分为 三个层级,web层、业务逻辑层和数据存储层
。
先看看图,旧时代的辉煌!
先介绍一下:
WEB容器:给处于其中的应用程序组件(JSP,SERVLET)提供一个 环境
,使JSP,SERVLET直接跟容器中的环境变量接口交互,不必关注其它系统问题。主要由 WEB服务器
来实现。例如:TOMCAT,WEBLOGIC,WEBSPHERE等。该容器提供的接口严格遵守J2EE规范中的WEB APPLICATION 标准。我们把遵守以上标准的WEB服务器就叫做J2EE中的WEB容器。同时,JEE 平台将 不同的模块化组件聚合后运行在通用的应用服务器
上,例WebLogi,WebSphere , JBoss 等,这也包含 Tomcat Tomcat 仅仅是实现了 JEE Web 规范的 Web 容器。
EJB容器:Enterprise java bean 容器。更具有行业领域特色。他提供给运行在其中的组件EJB各种管理功能。只要满足J2EE规范的EJB放入该容器,马上就会被容器进行高效率的管理。并且可以通过现成的接口来获得系统级别的服务。例如邮件服务、事务管理。WEB容器和EJB容器在原理上是大体相同的,更多的区别是 被隔离的外界环境
。WEB容器更多的是跟基于HTTP的请求打交道。而EJB容器不是。它是更多的跟数据库、其它服务打交道。但他们都是把与外界的交互实现从而减轻应用程序的负担。例如SERVLET不用关心HTTP的细节,直接引用环境变量session,request,response就行、EJB不用关心数据库连接速度、各种事务控制,直接由容器来完成。
可以看到每个层次的职责如下:
值得一提的是, JEE平台是典型的二八原则的应用场景
,它将 80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件里,通过配置的模式提供给应用程序访问, 应用程序实现 20%专用逻辑
,并通过 配置
的形式来访问应用服务器提供的模块化组件。事实上,应用服务器提供的对象关系映射服务、数据持久服务、事务服务、安全服务、消息服务等通过简单的配置即可在应用程序中使用。
JEE 时代的架构已经对企业级应用的整体架构进行了 逻辑分层
,包括上面提到的 Web 层、业务逻 和数据存取层,分别对应上图中的 Web 容器、 JB 容器和数据存取 ORM 组件与数据持久层 (数据库) 不同的层级有自己的职责,并从功能类型上划分层级,每个层级的职责单一。
在分层架构下需要对项目管理过程中的团队进行职责划分,井建立团队交流机制。根据康威定律,设计系统的组织时, 最终产生的设计等价于组织的沟通结构
,通俗来讲,团队的交流机制应该与架构分层交互机制相对应。由于在架构上把整体的单体系统分成具有不同职责的层级,对应的项目管理倾向于把大的团队分成不同的职能团队,主要包括:用户 交互 UI 团队、后台业务逻辑处理团队、 数据存取 ORM 团队与 DBA 团队等, 每个团队只对自己的职责负责
,并对使用方提供组件服务质量保证。
让我们在看看另一个经典,职能团队划分。
JEE通过对单体架构的分层,结合职能划分,开始通过架构在一定程度上进行逻辑拆分,让各个专业的人能更加高效的做他们应该做的事情。
但是,每个层次的多个业务逻辑的实现会被放在同一应用项目中,并且运行在同一个服务器上。尽管大多数公司会使用规范来约束不同业务逻辑的 隔离性
来解祸,但是久而久之,随着复杂业务逻辑的选代增加及开发人员的不断流动,新的程序员为了节省时间和赶进度,非法使用了其他组件的服务,业务组件之间、 组件之间、数据存取之间的稿合性必然增加,最后导致 组件与组件之间难以划清界限
,完全祸合在一起,将来的新功能迭代、增加和维护将难上加难。(反正你如果是入职接手一个老项目,那你一般都会很头疼)
就当时而言,尽管 JEE 支持 Web容器和 EJB 容器的分离部署,大多数项目仍然部署在同 个应用服务器上井跑在一JVM 进程中。
说说你和JEE的那些事吧!
现架构设计(码农)兼创业技术顾问,不羁平庸,热爱开源,杂谈程序人生与不定期干货。