了解JMS

       企业级应用程序通常需要在不同组件之间进行通信，RMI技术允许两个分布在不同物理节点上的组件直接以方法调用的方式进行通信，此外，CORBA、Web Service等也可以实现大致相似的功能。但是，当面对规模和复杂度越来越高的系统时，这些技术也存在不足之处： 
       •  这些技术都是以同步方式来通讯，也就是说客户端调用服务器端对象的方法后，在服务器端方法返回之前，客户端程序无法向下执行。
       •  客户端和服务器端的生命周期耦合，客户端的调用代码和服务器端的被调用方法必须同步执行，而且这两段代码都必须可以正常执行。如果服务器端的被调用方法出现异常或网络通信出现异常，客户端代码都将收到异常。
       •  点对点通信：客户端每次只能调用一个服务器的方法。
        为了解决上面所存在的不足，出现了一种面向消息的应用程序架构。
        消息是不同应用程序之间，或同一个应用程序的不同组件之间的通信方法，当一个应用程序或一个组件将消息发送到指定的消息目的之后，该消息可以被一个或多个组件读取并处理。
        对于面向消息的应用架构来说，消息生产者和消息消费者之间完全隔离，双方无须相互了解，它们只要了解交换的消息格式即可。
        面向消息的通信方式既可以是同步的通信，也可以是异步通信，具有很高的适应性。Java EE为企业应用之间的消息机制提供了JMS规范。
        JMS(Java Message Service) java消息服务，主要用于分布式应用的各组件之间的通信。可以把JMS想象成一个智能交换机，负责路由分布式应用中各组件所发出的消息。JMS提供了一组通用的java应用程序接口，开发者可以通过这种通用的API来创建、发送、接收、读取消息，JMS是一种与具体实现厂商无关的API，不管底层采用何种消息服务器实现，应用程序总是面向通用的JMS API编程。
       JMS：

       1. 使应用组件之间的通信变得更加松耦合 

       2. 可以采用异步处理机制，避免客户机等待 

       3. 可以持久地保存消息，因而提高系统的可靠性。

       4.允许一条消息同时发送给多个接收者。

 

       JMS架构：

 

   

 

    JMS架构的组成部分：

        JMS服务器：通常来说，商业应用服务器都可提供JMS服务器支持，应用服务器通常包括了JMS服务器。

       JMS生产者：负责创建并发送消息的程序组件。

       JMS消费者：负责读取并处理消息的程序组件。

  JMS消息机制模型类型：

        PTP模型

        pub/sub模型

  JMS消息类型：

        StreamMessage：消息内容由序列化的对象流组成，读取消息时必须按写对象时的顺序从流中读取对象。

        MapMessage：消息内容由多个Key-value对组成

        TextMessage：消息内容为普通字符串

        ObjectMessage：消息内容包含序列化对象

        BytesMessage：消息内容是原始的字节流。只有当客户端需要完全控制原始消息格式时才考虑使用这种类型