来点“硬菜”-----谈谈EJB和Web服务

导读:

最近两天看到的新闻就是Oracle将JavaEE卖给了Eclipse基金会，这边卖完之后就让Eclipse基金会改名字改LOGO，这和当年对Android的做法一样狠（Android官方语言改为Kotlin），作为互联网的大哥大，不得不说Oracle公司是霸气外泄，“盛气凌人”。今天要和大家分享的知识点同样是JakartaEE（也就是我们的JavaEE）中的经典概念：EJB组件化开发以及SOA面向服务架构的典例Web服务开发，接下来就让我们一起来深入了解下当年EJB的盛世概况以及Web服务开发作为新兴明星的崛起历程。

EJB和JNDI

一、EJB和JNDI的关系：
1. EJB分类：SessionBean、EntityBean以及MessageDriverBean（MDB）。每一种组件类完成各自不同的功能其中SessionBean又分为有状态会话Bean和无状态会话Bean，有状态会话Bean对应的是单一客户端不支持异步访问会记录访问的状态（账单的操作），而无状态的会话Bean对应的则可以是多个客户端支持异步访问。另外在EJB3.0之后EntityBean改为JPA支持的持久层Bean。
2. JNDI的认识：JNDI指的是Java命名目录接口，在规范中所有的EJB容器必须支持JNDI。JNDI就好比JDBC一样通过预先设计好的一套API可以实现对容器中各种EJB逻辑方法的调用，区别是一个操作对象是底层数据库数据一个是EJB的组件方法。在使用JNDI的过程中我们只需要将特定的资源、EJB通过配置文件和起对应的命名关联起来就可以在其他的EJB组件中通过应用编程接口的相关方法实现调用，他不是命名服务而是目录服务，是对命名服务的一种扩展（目录服务可以带属性）。
二、JNDI的设计思想

1. 两个部分：JNDI主要是由API应用编程接口和SPI服务提供者接口两部分组成，他通过定义一组共有的接口方法可以实现对不同资源（数据库资源DataSource、EJB）进行调用，对于应用程序的开发者来说我们只需要关注其API的使用就可以了。
2. 通过该种目录服务的设计，使得各个组件在跨服务器调用的时候多了一个中间媒介层，这样设计的好处就是通过中间层使得各个组件解耦，解耦的好处就是提高了系统的复用性以及扩展性。

两个侧重点

一、面向组件的开发：在聊到软件架构的时候，我想说的一点就是对分包分层的理解。分包分层其实无需用多高大尚的词藻来解释他的优势，最为简单的就是利于不同的开发人员分工协作，用HeadFirst里边的例子就是一个是穿卫衣的码农，一个是着装时尚的前端界面设计人员，如果你的系统前台呈现和后台代码耦合严重那么就需要码农去学习页面设计，同时还得前端设计人员学习Java，不过他们现在都在旅游度假，显然这样是不合适的。假如我们的系统在分包分层方面做的很好，那么你就会成为一个被所有开发人员称赞的好老板，很显然我们想当好老板。在了解EJB之前首先要明确的就是他的使用范围和基本定义，EJB全称Enterprise JavaBean是J2EE的一部分，他是一种J2EE进行分布式系统组件开发的规范，特点是跨平台但不跨语言。EJB既可以用来开发桌面应用，也可以用来开发Web应用，他最大的优势就是组件化开发，复用性高并且易于扩展，当然还有就是实现系统的分布式部署以及基于RMI-IIOP实现各个服务器对象的远程调用实现功能类的共享共用。EJB是实现大型分布式系统的标准，是JAVAEE的行业规范之一，在开发基于EJB的系统时，技术人员面对的就是拥有不同功能的一个个组件（面向组件），我们主要的任务就是开发拥有特定功能的组件，张三开发拥有功能A的组件一，李四开发拥有功能B的组件二，最后将不同的组件分门别类的部署到拥有EJB容器的各个服务器上，经过运维工程师的测试检验完成分布式系统的开发部署。
二、面向服务的开发：如果你理解了第一点面向组件的开发，那么面向服务顾名思义就是我们要创建若干个拥有不同业务逻辑方法的“服务”（封装操作组合，抽象逻辑表现）。最为典型的就是Web服务，不过和组件不同，各个服务器上的服务是通过HTTP协议进行通信的，RMI-IIOP会受防火墙影响，而HTTP协议则不在乎这些。另外就是面向Web服务的开发不光跨平台而且跨语言，服务这一概念本身就比组件更抽象更具有广义包容特点（站得高看得远），组件更加具体化。正是这些优点才有了后续SOA的崛起，可以说Web服务开发从一开始就已经领先了EJB组件开发。

EJB实现分布式的思想

EJB实现的分布式主要就是将不同的EJB组件部署到各个不同的服务器上，这些个组件可以在一台服务器上运行，分布式就是将系统的整个组件进行分门别类的拆分。不同于Web服务分布式，EJB分布式好像来的更直接，在EJB分布式系统中虽然组件分开了但是系统运行的底层原理实质还是业务逻辑方法的直接调用，只不过是是远程调用。而Web服务则是基于HTTP协议进行请求-响应对话，经过URL请求识别以及响应的数据来实现逻辑方法调用。

EJB的优势和不足

一、EJB适用的场景：部署实现EJB系统基本上都是比较大型的分布式系统，EJB经过多年的发展本身技术是很成熟的，他首先具备可扩展 (Scalable)、分布式 (Distributed)、事务处理(Transactional)
、数据存储(Persistent)、安全性 (Secure)等优势，另外该系统对系统硬件的要求不是很高从成本上来考虑的话很合算，同时也支持Web服务开发（无状态会话Bean），是企业开发大型系统的备用方案之一。
二、EJB不足的地方：EJB不足的地方也很多，在2.+++以及之前版本中EJB过于繁琐，笨重，学习成本大。而且在之前的版本中没有local接口的实现，不够灵活轻便。另外由于组件之间是基于RMI-IIOP进行远端调用的，需要相关的类实现序列化，这就使得该规范不适用于要求高并发的系统设计。

Web面向服务开发的崛起

一、赢在起跑线：为什么说面向服务开发赢在起跑线了呢，前边我就说过，首先Web服务不光实现了跨平台还可以跨语言，EJB只能说是JavaEE的规范，他是在Java这一语言的范畴内进行开发部署的，而Web服务则不一样之所以可以实现跨语言就是因为服务分布式设计通信是基于HTTP协议的，你的服务端可以是Java开发的也可以是PHP开发的，你的客户端可以是Android移动端也可以是Web前端网页甚至可以是桌面程序，这是他的主要优势。
二、微服务的诞生 ：传统的Web服务分布式设计一般都是将整个项目部署到不同的服务器中，然后经由负载均衡实现高效访问。很明显这样的设计有太多的浪费，这就好比一家超市想在不同的地区开分店，有的地区对生活日用品需求多，有的地区对服装类产品需求多，各个地区在商品的需求上有不同，传统的分布式设计就是直接在各个地区开设一模一样的分店，忽略了商品需求受地区影响这一因素，搞的是一刀切标准，这样的缺点显而易见。而假如我们将超市不同类别的商品进行分类，设置日用平分店、服装类分店这样的微型分店。那么就可以因地制宜部署没有资源浪费的聚合程度高的微分店集合（微服务集合），这就是微服务。
三、站的更高模块集成程度更强：这一点主要是从服务的角度来说的，相对于组件，服务范畴更广更加抽象，用我的那句话来说就是“封装操作组合，抽象逻辑表现”。很显然服务高度抽象底层更加复杂，一个服务的底层逻辑如果由组件来实现的话可能需要多个组件配合才能实现，这种底层操作高度集成的抽象逻辑表现模块会使得分布式服务器之间的通信次数更少逻辑实现更加高效，原来需要多个服务器多次交互实现的逻辑功能现在可能只需要更少的服务器交互一次就实现了，所以面向服务的开发更实用可靠。

总结：

在理解EJB的时候，最为关键的是要知道他的功能以及特点，当然有比这更为重要的那就是通过实际动手来玩一玩，“纸上得来终觉浅，绝知此事要躬行”，理论总归是理论，知道了不代表你真正理解了。理论结合实践，在实践中品理论的味道，在理论中反思框架的底层原理，如此反复就能彻底掌握框架。编程有一个特点只要你保持好奇心，只要你有一探究竟的勇气，并不断反复的思考尝试就一定能学到别人学不到的东西。