我是一个上个世纪末开发的企业应用，年纪一大把了，不像那些年轻的系统，用着很多又酷又炫的新技术，什么前后端分离了，什么React了，响应式设计了， 我这里都没有， 不怕你笑话，我这里只有老掉牙的JSP。
但是我也有一些年轻的系统所没有的东西， 比如EJB 。
这个被大家抛弃的家伙还在我这里勤勤勉勉、任劳任怨地工作， 它住在应用服务器中， 用Session Bean来处理我们的业务逻辑， 用Entity Bean 来实现我们的O/R Mapping。
提到应用服务器，Websphere, Weblogic 可是鼎鼎大名，当年很多公司为了展示自己使用了***最热门的技术(也可能是为了政绩)，纷纷掏腰包花大价钱购买。
我挺羡慕隔壁公司的Weblogic， 每天生活极其悠闲，整天就是处理一下Servlet和JSP， 和他那超级强悍的硬件和软件完全不匹配，我常常带着羡慕的口吻酸酸地评价： 你干的可都是Tomcat的活啊。
对比之下，我们公司还算是比较良心的， 至少把EJB这个应用服务器的核心功能给使用起来了， 我们还把4台机器组成了一个集群做负载均衡， 每个EJB都会部署4份， 完全不用担心一个机器挂掉了怎么办。
各位看官， 那可真是分布式计算啊! 这些EJB对象分布在不同的机器上，时不时地被激活，被调用。
你可以想象一下， HTTP请求到达一个机器， 经过简单的处理以后发现需要执行业务逻辑，于是这个机器就发起对EJB的调用 ， 这个EJB可能在本机， 也可能在另外一个机器上， 跨越网络的访问此起彼伏，序列化和反序列化源源不断，场面蔚为壮观 。
有人可能要问了：这些EJB对象是分布式的， 你都不知道他们在哪个机器上， 你怎么去调用他们呢?
这是个好问题， 当时我也很发愁，想了很久，终于找到了一个办法： 把锅甩给Websphere, Weblogic这样的应用服务器 ， 谁让他们这么贵呢!
具体的方法其实很简单：我会给每个EJB都起个名，比如"order/OrderBean", Websphere/Weblogic需要把这个名字和实际的EJB对象给绑定起来 -- 很明显这个工作很困难但是极为重要-- 这样当我需要使用EJB的时候， 我就可以简单地通过这个名字去查找一下，获得EJB对象了。
- OrderBean orderBean = (OrderBean) context.lookup("order/OrderBean");
至于这个OrderBean是从哪个机器来的，作为应用层的我根本不关心，只要我能找到一个这样的EJB对象， 我就可以工作了。
你可能还会问： 难道真的要把OrderBean对象从另外一个机器Copy的你的机器上吗?
No No， 根本不是， 这背后的魔法其实是远程方法调用(RMI),当我去查找对象的时候，看起来应用服务器给我返回了一个OrderBean， 实际上这只是一个存根(Stub)，一个假对象而已!但是通过“假对象”，方法调用的参数可以被发送给远程机器上的真正对象，去执行业务逻辑。 对了，这不就是你们常说的远程代理模式吗?
通过名称来查找对象这种方法让我的日常工作变得极为便利，应用服务器则怨声载道，毕竟这是一件费心费力的事情， 但是为了占领市场，他们也不得不这么做。 我暗地里把这种工作方式叫Java Naming Service (Java 命名服务)
后来我发现，JDBC访问数据库也可以这么办啊。 我为什么要在代码中写下数据库的IP，端口，数据库名，用户名、密码 ? 使用命名服务， 也可以把这个锅扔给应用服务器： 我只知道数据源的名称jdbc/OrderDB，至于它在什么地方，就不要来烦我了：
看看，通过名称拿到一个叫做DataSource的对象，直接就可以获得数据库连接了。
再接再厉，把消息队列相关的也给改了， 通过名称(jms/OrderConnFactory)来获取一个消息队列的对象， 然后发送消息：
给大家画个图看看这个命名服务吧，客户端可以通过lookup 的方式查找， 查找出的可能是直接的对象，也有可能是一个引用，指向了数据源，消息队列，EJB等。
仔细想一想， 我这个命名服务和文件系统还有几分相像， 都是给定一个名称(如 C:\Users\admin\Documents\Test.java) , 然后获得一个对象的引用(如File对象) ， 看来这个世界在底层思想上都是相通的啊。
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
