jms

ENC 的概念： The application component environment is referred to as the ENC, the enterprise naming context. 应用组件的业务逻辑应该是 ENC中取得对象。组件提供者使用标准的部署描述符指定必需的ENC入口。这些ENC入口是运行时组件所依赖的资源等信息。 一个应用组件实例使用 JNDI定位ENC。ENC的标准JNDI CONTEXT是：java;/comp/env // Obtain the application component's ENC Context iniCtx = new InitialContext(); Context compEnv = (Context) iniCtx.lookup("java:comp/env"); env 环 境是一个私有的环境，只能在该组件内部存取。对其它组件是不可见的。比如，EJB1不能存取EJB2的ENV。同样，任何一个客户端代码，不管它是运行在 应用服务器的同一个JVM内或者是远程调用，均不能访问这些JNDI。这样的话，组件之间是相互隔离的，不同组件之间可以定义它自己的环境参数。比如 EJB1可以定义自己的环境变量参数：java:comp/env/red 1 、JBOSS的命名空间： 比如一个命名： java:comp/env

1.面向消息的中间件(MOM) 1.什么是MOM 面向消息的中间件，Message Oriented Middleware，简称MOM，中文简称消息中间件，利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。 一个MOM系统，通常会包括客户端（Clients）、消息（Message）和 MOM，客户端是发送或者接受消息的应用程序，消息封装了要传递的内容，MOM可以存储和转发消息。如下图所示，系统A和系统B之间的消息传递，不是直接通信，而是通过中间件来间接的传递 2.MOM的好处 降低系统间通信复杂度：有了MOM，系统间的通信，不用考虑系统是什么语言开发的，也不用考虑复杂的网络编程，各个系统只需要关心自身和MOM之间如何进行消息的接受和发送即可，这些操作通过简单的API就可以完成。 提高了消息的灵活性：系统A通过MOM向系统B发送消息，消息可以存储在MOM中，并由MOM转发。即使是系统B不在线，MOM会持有这个消息，直到系统B连接并处理消息。这就是说，系统A发完消息后，就可以执行其它操作，而不必阻塞等待，尤其是对那些时间无关或者并行处理的操作，非常适用。 松散耦合：有了MOM的存在，对于系统B而言，只要发送的消息没有变化，就不必考虑系统Ａ的变化。A系统的代码改变，不会影响到B系统，反之亦然。 2.JMS基本概念 1.JMS是什么 Java消息服务

Java 消息服务 (JMS) SOA与异步消息传送模型都适合于系统集成： 异步消息传送模型非常适于完成集成复杂系统的任务；对于此类系统，在执行操作的过程中让一个组件为另一个组件提供支持既不切实际，也不值得这样做。尽管异步消息传送放弃了同步系统所具有的某些控制功能，但大大提高了组件间相互作用的灵活性。它还增强了系统的稳定性，因为一个组件的故障并不会导致整个系统瘫痪。 SOA或者WS是主动请求，消息的接收方必须做好准备，这类系统的集成属于 整体一个组件必须为另一个组件提供支持。并且这样就很难做到高密度吞吐量。 消息的格式：标题 属性 主体 属性可以用来过滤消息。避免在消息接收者的应用程序中再去过滤处理。 消息主体可以是对象，字节流，key-value的map等。 创建连接时，将分配通信资源以及验证客户机。这是一个相当重要的对象，大多数客户机均使用一个连接来进行所有的消息传送。 客户机使用消息生产者对象 (MessageProducer) 向指定的物理目标（在 API 中由目标对象destinaction表示）发送消息。 客户机使用消息消费者对象 (MessageConsumer) 从指定的物理目标（在 API 中表示为目标对象destinaction表示）接收消息。共有两种类型的目标，分别是队列和主题 物理目标是在jms服务器上。destinaction只是在客户机上对应的抽象

JMS 消息传送模型 : 　　 消息传送机制 , 是基于 拉取 (pull) 或者 轮询 (polling) 的方式. JMS 具备两种 " 消息传送模型 ": P2P 和 Pub/sub. (1) P2P： 点对点消息传送模型 , 允许 JMS 客户端通过队列 (queue) 这个虚拟通道来同步或 异步发送消息 ; 消息的生产者为 Sender, 消费者为 receiver . 　　　　 receiver 主动到队列中请求消息 , 而不是 JMS 提供者将消息推送到客户端 ; 　　　　 主要原因是一个队列通道可能有多个 receiver, 每个 receiver 可能对消息的处理速率不同 ( 因处理消息而造成的阻塞时间不同 ), 对于 JMS 提供者而言 , 它无法意识到哪个 receiver 处于 " 空闲 " 状态 , 如果 JMS 提供者主动推送会造成通道的阻塞或者消息在客户端积压等问题 ; 所以基于客户端 pull 的方式 , 当 receiver 空闲时向 JMS 提供者请求消息 , 很好的解决了这个问题 , 而且还能进行良好的 " 负载均衡 ". 　　 Queue 中的消息如果被某个 recervier 成功接收 ( 确认成功 ) 后 , 消息就会被移除 . 　　 P2P 消息传送模式即支持异步 " 即发即失 ", 也支持同步的 " 请求 / 应答 " . (2)

Jms规范里的两种message传输方式Topic和Queue，两者的对比如下表()： 　 Topic Queue 概要 Publish Subscribe messaging 发布订阅消息 Point-to-Point 点对点 有无状态 topic数据默认不落地，是无状态的。 　　Queue数据默认会在mq服务器上以文件形式保存，比如Active MQ一般保存在$AMQ_HOME/data/kr-store/data下面。也可以配置成DB存储。 完整性保障 并不保证publisher发布的每条数据，Subscriber都能接受到。 Queue保证每条数据都能被receiver接收。 消息是否会丢失 一般来说publisher发布消息到某一个topic时，只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了。 Sender发送消息到目标Queue，receiver可以异步接收这个Queue上的消息。Queue上的消息如果暂时没有receiver来取，也不会丢失。 消息发布接收策略 一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器 一对一的消息发布接收策略，一个sender发送的消息，只能有一个receiver接收。receiver接收完后，通知mq服务器已接收

一 .安装运行ActiveMQ： 1.下载activemq wget http://archive.apache.org/dist/activemq/apache-activemq/5.9.0/apache-activemq-5.9.0-bin.tar.gz 2.解压 tar -xf apache-activemq-5.9.0-bin.tar.gz [zcw@g1 ~]$ cd apache-activemq-5.9.0 [zcw@g1 apache-activemq-5.9.0]$ cd bin/ 3.运行： [zcw@g1 bin]$ activemq start 三种运行方式： (1)普通启动 ./activemq start (2)启动并指定日志文件 ./activemq start >tmp/smlog (3)后台启动方式nohup ./activemq start >/tmp/smlog 前两种方式下在命令行窗口关闭时或者ctrl+c时导致进程退出，采用后台启动方式则可以避免这种情况 管理后台为： http://ip:8161/admin/ 4.检查已经启动 ActiveMQ默认采用61616端口提供JMS服务，使用8161端口提供管理控制台服务，执行以下命令以便检验是否已经成功启动ActiveMQ服务。 打开端口：nc -lp 61616 & 查看哪些端口被打开