Spring 5 高级教程读书笔记——第2章

1、EJB: Enterprise JavaBeans

EJB是JavaEE中面向服务的体系架构的解决方案，可以将功能封装在服务器端，以服务的形式对外发布，客户端在无需知道方法细节的情况下来远程调用方法，大大降低了模块间的耦合性，提高了系统的安全性和可维护性。

为什么需要EJB?

要想知道为什么要使用EJB，就需要知道"面向服务"的概念。"面向服务"，是软件开发过程中，异构环境下模块调用的一个比较重要的思想。同样，面向服务也只是一种设计思想，不是一种编程技术。由"面向服务"的思想，业界提出了"面向服务的体系结构(Service Oriented Architecture, SOA)"的概念。

用一个实际案例来引入"面向服务"的概念。在某些大型应用场合，我们要在不同的运行环境之间传递数据，比如：A公司需要从B公司的数据库中查询一些内容之后返回，进行处理，如何实现？

最简单的结构，如图2-1所示：

图2-1 最简单的两公司之间互相调用的结构

但是，以上程序在实际操作中，是不能实现的。因为JDBC代码写在A公司部分，那就必须让A公司的程序知道B公司数据库的详细结构。在一般情况下，这是不合理的。比如，一个公司通过自己的平台向银行转账，不可能知道银行数据库的结构。于是，程序可以变为如图2-2所示结构：

图2-2 改进的结构

 

该结构详述如下：B公司编写自己的程序，访问数据库，对外发布一个接口，并发布一个服务的名称。我们知道，接口里面并没有核心代码。该接口也被A公司获取，A公司网上寻找相应的B公司发布的服务名称，然后通过接口调用B公司程序里面的方法。

但是，该技术不是简单就可以实现的，因为A公司和B公司的程序，可能运行在不同的虚拟机内，甚至可能是不同的语言。EJB可以解决A公司和B公司使用的都是Java语言，但是处于不同的Java虚拟机的情况。

该问题的原型是：一个Java虚拟机内的对象能否远程调用另外一个Java虚拟机里面的对象内的方法？实际上，在Java内，该技术可以用RMI(远程方法调用)实现。而EJB的底层，就是用RMI实现的。

实际上，即使是在同一个Java虚拟机内，将某个功能以服务的形式对外发布，被该虚拟机中的另一个模块调用，也是可以大大降低耦合性的。因为模块之间打交道的，只是一个接口和一个服务名称。

不过，顺便需要提到的是，如果两个程序使用的是不同语言平台，如一个是C，一个是Java，业界中也提出了一些方法来解决数据交换问题，如WebService、CORBA等。读者可以参考相关文献。

 

2、JNDI: Java Naming and Directory Interface

JNDI是 Java 命名与目录接口（Java Naming and Directory Interface），在J2EE规范中是重要的规范之一，不少专家认为，没有透彻理解JNDI的意义和作用，就没有真正掌握J2EE特别是EJB的知识。

那么，JNDI到底起什么作用？

要了解JNDI的作用，我们可以从“如果不用JNDI我们怎样做？用了JNDI后我们又将怎样做？”这个问题来探讨。

没有JNDI的做法：

程序员开发时，知道要开发访问MySQL数据库的应用，于是将一个对 MySQL JDBC 驱动程序类的引用进行了编码，并通过使用适当的 JDBC URL 连接到数据库。

就像以下代码这样：

Connection conn=null; 
try { 
	Class.forName("com.mysql.jdbc.Driver", true, Thread.currentThread().getContextClassLoader()); 
	conn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=xxx&password=xxx"); 
	...... 
	conn.close(); 
} catch(Exception e) { 
	e.printStackTrace(); 
} finally { 
	if(conn!=null) { 
		try { 
			conn.close(); 
		} catch(SQLException e) {} 
	}
}

这是传统的做法，也是以前非Java程序员（如Delphi、VB等）常见的做法。这种做法一般在小规模的开发过程中不会产生问题，只要程序员熟悉Java语言、了解JDBC技术和MySQL，可以很快开发出相应的应用程序。

没有JNDI的做法存在的问题：
1、数据库服务器名称MyDBServer 、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；
2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；
3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；
4、......

解决办法：

程序员应该不需要关心“具体的数据库后台是什么？JDBC驱动程序是什么？JDBC URL格式是什么？访问数据库的用户名和口令是什么？”等等这些问题，程序员编写的程序应该没有对 JDBC 驱动程序的引用，没有服务器名称，没有用户名称或口令 —— 甚至没有数据库池或连接管理。而是把这些问题交给J2EE容器来配置和管理，程序员只需要对这些配置和管理进行引用即可。

由此，就有了JNDI。

用了JNDI之后的做法：
首先，在在J2EE容器中配置JNDI参数，定义一个数据源，也就是JDBC引用参数，给这个数据源设置一个名称；然后，在程序中，通过数据源名称引用数据源从而访问后台数据库。
具体操作如下（以JBoss为例）：
1、配置数据源
在JBoss 的 D:/jboss420GA/docs/examples/jca 文件夹下面，有很多不同数据库引用的数据源定义模板。将其中的 mysql-ds.xml 文件Copy到你使用的服务器下，如 D:/jboss420GA/server/default/deploy。
修改 mysql-ds.xml 文件的内容，使之能通过JDBC正确访问你的MySQL数据库，如下：

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
  <jndi-name>MySqlDS</jndi-name>
  <connection-url>jdbc:mysql://localhost:3306/lw</connection-url>
  <driver-class>com.mysql.jdbc.Driver</driver-class>
  <user-name>root</user-name>
  <password>rootpassword</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
  <metadata>
  <type-mapping>mySQL</type-mapping>
  </metadata>
</local-tx-datasource>
</datasources>

这里，定义了一个名为MySqlDS的数据源，其参数包括JDBC的URL，驱动类名，用户名及密码等。

2、在程序中引用数据源：

Connection conn=null; 
try { 
	Context ctx = new InitialContext(); 
	Object datasourceRef = ctx.lookup("java:MySqlDS"); 
	//引用数据源 
	DataSource ds = (Datasource) datasourceRef; 
	conn = ds.getConnection(); 
	...... 
	c.close(); 
} catch(Exception e) { 
	e.printStackTrace(); 
} finally { 
	if(conn!=null) { 
		try { 
			conn.close(); 
		} catch(SQLException e) {} 
	} 

直接使用JDBC或者通过JNDI引用数据源的编程代码量相差无几，但是现在的程序可以不用关心具体JDBC参数了。
在系统部署后，如果数据库的相关参数变更，只需要重新配置 mysql-ds.xml 修改其中的JDBC参数，只要保证数据源的名称不变，那么程序源代码就无需修改。

由此可见，JNDI避免了程序与数据库之间的紧耦合，使应用更加易于配置、易于部署。

总结：
J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下，提供 JNDI 供应者的容器可以充当有限的数据存储，这样管理员就可以设置应用程序的执行属性，并让其他应用程序引用这些属性（Java 管理扩展（Java Management Extensions，JMX）也可以用作这个目的）。JNDI 在 J2EE 应用程序中的主要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了解这些间接性。

在 J2EE 中，JNDI 是把 J2EE 应用程序合在一起的粘合剂，JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺，而且经过一些计划和预先考虑，这个承诺是完全可以实现的。

说白了就是把资源取个名字，再根据名字来找资源。

转载自https://blog.csdn.net/wn084/article/details/80729230

3、JMX: Java Management Extensions

JMX(Java管理扩展)是一种JAVA的正式规范，它主要目的是让程序有被管理的功能，用户可以在任何Java应用程序中使用这些代理和服务实现管理，那么怎么理解所谓的“被管理”呢？试想你开发了一个软件（如WEB网站），它是在24小时不间断运行的，那么你可能会想要“监控”这个软件的运行情况，比如收到了多少数据，有多少人登录等等。或者你又想“配置”这个软件，比如现在访问人数比较多，你想把数据连接池设置得大一些。

当然，你也许会专门为这些管理来开发软件，但如果你借助JMX，则会发现创建这样的管理程序是如此简单。因为你无需为管理程序来开发界面，已经有通用的JMX管理软件，如MC4J，或者是用一般都附带提供的HTML网页来管理，你要做的仅仅是将自己要被管理和监控类的按照JMX规范修改一下即可。

中间件软件WebLogic的管理页面就是基于JMX开发的，而JBoss则整个系统都基于JMX构架。

举一个应用实例：在一个系统中常常会有一些配置信息，比如服务的IP地址，端口号什么的，那么如何来写这些代码呢？

   1. 程序初哥一般是写死在程序里，到要改变时就去改程序，然后再编译发布；
   2. 程序熟手则一般把这些信息写在一个配置文件里（JAVA一般都是*.properties文件），到要改变时只要改配置文件，但还是重新启动系统，以便读取配置文件里的新值；
   3. 程序好手则会写一个段代码，把配置值缓存起来，系统在读值的时候，先看看配置文件有没有更动。如有更改则重读一遍，否则从缓存里读取值
   4. 程序高手则懂得取物为我所用，用JMX！把配置属性集中在一个类，然后写一个叫MBean的东东，再配置一下就轻松搞定了。而且JMX自动提供了一个WEB页面来给你来改变这些配置信息。

下图是使用Jconsle通过JMX查看Java程序的运行信息

图2-3 Jconsle通过JMX查看Java程序

为Java程序开启JMX很简单，只要在运行Java程序的命令后面指定如下命令即可

-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.port=1000
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

我们从Jconsole的视图标签中见到，JConsole通过JMX展示的信息都是Java程序的通用信息，如内存情况、线程情况、类加载情况等，换言之，只要是Java程序就都具备这些信息。这些信息为我们优化程序性能、排查BUG非常有用，而JMX就是获取这些信息的基础，因此它是一种非常有用的技术。

然而JMX的强大远不止此，它出了能提供一些通用的信息以外，还能通过特定的编程接口提供一些针对具体程序的专有信息并在JConsole等JMX客户端工具中展示，具体点说就是程序员可以把需要展示的信息放在一种叫做MBean的Java对象内，然后JConsole之类的客户端工具可以连接到JMX服务，识别MBean并在图形界面中显示。从纯抽象的角度触发，这其实有点像浏览器发送一个请求给http服务器，然后http服务器执行浏览器的请求并返回相应的数据，从某种角度来说JConsole和JMX也是以这种方式工作的，只是它们使用的协议不是http，交换数据协议格式不是http数据包，但是他们的确是以客户端/服务器这种模式工作的，而且完成的事情也差不多。

那么既然有了http，JMX又有何存在意义呢。 事实上，JMX能完成的任务通过http的确都能完成，只不过某些情况下用JMX来做会更加方便。

比如说你需要知道服务器上个运行中程序的相关信息， 如执行了多少次数据库操作、任务队列中有多少个任务在等待处理

最常用的解决方案，我们会在程序中启动一个http服务，当接收到来自客户端的请求这些信息的请求时，我们的http处理程序会获得这些信息，并转换成特定格式的数据如JSON返回给客户端，客户端会以某种方式展现这些信息。

如以JMX作为解决方案，核心流程也是如此，但在数据的交换方式上会略有不同。

下面我们展示JMX是如何完成此任务的。

• 定义一个展示所需信息的MBean接口

public interface ServerInfoMBean {
    int getExecutedSqlCmdCount();
}

在使用 Standard Mbean 作为数据传输对象的情况下这个接口的定义是必须的， 并且接口名称必须以“MBean”这个单词结尾。

• 实现具体的MBean

public class ServerInfo implements ServerInfoMBean {
    public int getExecutedSqlCmdCount() {
        return Dbutil.getExecutedSqlCmdCount();
    }
}

• 在程序的某个地方启动JMX服务并注册ServerInfoMBean

public static void main(String[] args)  throws JMException, Exception{
        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        ObjectName name = new ObjectName("serverInfoMBean:name=serverInfo");
        server.registerMBean(new ServerInfo(), name);
    }

• 运行程序，并通过JConsole查看

如果程序运行在本地，Jconsole会自动检测到程序的进程，鼠标双击进入即可

图2-4 通过Jconsole查看1

在JConsole下面即会展示我们定义的MBean中的内容

图2-4 通过Jconsole查看2

那么假如Java程序并非运行在本地而是运行在远端服务器上我们应该如何通过客户端去连接呢， 很简单，只要使用JDK提供的JMX类库监听端口提供服务即可

ublic class Main {
    public static void main(String[] args)  throws JMException, Exception{
        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        ObjectName name = new ObjectName("serverInfoMBean:name=serverInfo");
        server.registerMBean(new ServerInfo(), name);


        LocateRegistry.createRegistry(8081);
        JMXServiceURL url = new JMXServiceURL
                ("service:jmx:rmi:///jndi/rmi://localhost:8081/jmxrmi");
        JMXConnectorServer jcs = JMXConnectorServerFactory.newJMXConnectorServer(url, null, server);
        jcs.start();
    }
}

或者在启动Java程序指定命令行参数

-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.port=10086
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

然后使用JConsole的连接远端进程功能即可

图2-5 通过Jconsole查看3

其余的操作和本地无差。

这相对于提供一个http服务来完成任务是不是要简单了不少，http是一个更加抽象、应用面更广泛、功能更强大的服务，因此所作的工作也要更多一些。JMX则是一个更加具体、应用面不那么广、功能也没有http强大的服务，不过呢它胜在解决特定问题更加轻松方便，上面的示例已经很好的说明了。

此外，JMX和Jconsole并不仅仅只能展示数据，它还能执行Java方法。以上面的示例为基础我们再进行一系列改进。

• 扩展ServerInfoMBean接口和实现的类

public interface ServerInfoMBean {
    int getExecutedSqlCmdCount();
    void printString(String fromJConsole);
}

public class ServerInfo implements ServerInfoMBean {
    public int getExecutedSqlCmdCount() {
        return 100;
    }

    public void printString(String fromJConsole) {
        System.out.println(fromJConsole);
    }
}

• 运行程序并使用JConsole连接

图2-6 通过Jconsole查看4

mbean页签中出现了我们新添加的方法

• 点击printString按钮调用方法

图2-7 通过Jconsole查看5

方法被调用，同时控制台也打印了通过Jconsole传递的参数

图2-8 查看控制台结果

 

这里只是讲解了JMX的用处和最基础的使用方法，显然JMX真正提供的功能远不及此，比如它可以不用JConsole而是客户端编程的方式访问等等， 有兴趣的同学可以深入研究。

总而言之， 我觉得JMX是一种小巧精悍的工具，在不需要大张旗鼓的通过http或者其他server\client方式提供服务时，就是他发挥用处的时机了。

转载自https://www.jianshu.com/p/fa4e88f95631