1.JMS消息的异步与同步接收
消息的异步接收:
异步接收是指当消息到达时,主动通知客户端,即当消息到达时转发到客户端。JMS客户端可以通过注册一个实现MessageListener接口的对象到MessageConsumer,这样,每当消息到达时,JMS Provider 会调用MessageListener中的onMessage 方法。所以需要创建一个消息监听器,然后注册一个或多个使用MessageConsumer的JMS MessageListener接口。会话(主题或队列)负责产生某些消息,这些消息被传送到使用onMessage方法的监听者那里;
客户可以为消费者注册一个消息监听器,以定义在消息到达时所采取的动作
消息的同步接收
jms同步接受消息的功能(客户端必须请求每个消息),通过调用消费者的receive方法从目的地中显式提取消息,receive方法可以一直阻塞到消息到达,同步接收是指客户端主动去接收消息,JMS 客户端可以采用MessageConsumer的receive方法去接收下一个消息。
2. JMS消息域
点对点(PTP)
发布和订阅(Pub/Sub)
消息中间件大致分为两类:Point-to-Point(PTP)和Publish-Subscribe(Pub/Sub)
PTP是点对点传输消息,建立在消息队列的基础上,每个客户端对应一个消息队列,客户端发送消息到对方的消息队列中,从自己的消息队列读取消息。
Queue 由JMS Provider 管理,队列由队列名识别,客户端可以通过JNDI接口用队列名得到一个队列对象。
Pub/Sub是将消息定位到某个层次结构栏目的节点上,Pub/Sub通常是匿名的并能够动态发布消息,Pub/Sub必须保证某个节点的所有发布者(Publisher)发布的信息准确无误地发送到这个节点的所有消息订阅者(Subscriber)。
消息订阅分为非持久订阅(non-durable subscription)和持久订阅(durablesubscrip-tion),非持久订阅只有当客户端处于激活状态,
也就是和JMS Provider保持连接状态才能收到发送到某个主题的消息,而当客户端处于离线状态,这个时间段发到主题的消息将会丢失,
永远不会收到。持久订阅时,客户端向JMS注册一个识别自己身份的ID,当这个客户端处于离线时,JMS Provider 会为这个ID 保存所有发送到主题的消息,
当客户再次连接到JMS Provider时,会根据自己的ID得到所有当自己处于离线时发送到主题的消息。
Topic 主题由JMS Provider 管理,主题由主题名识别,客户端可以通过JNDI接口用主题名得到一个主题对象。
3. JMS常用接口说明
ConnectionFactory :连接工厂,JMS 用它创建连接
Connection :JMS 客户端到JMS Provider 的连接
Destination :消息的目的地
Session: 一个发送或接收消息的线程
MessageProducer: 由Session 对象创建的用来发送消息的对象
MessageConsumer: 由Session 对象创建的用来接收消息的对象
4.Spring与JMS
JmsTemplate
JmsTemplate类有两个实现方式。JmsTemplate类使用JMS 1.1的API,而子类JmsTemplate102使用了JMS 1.0.2的API
ConnectionFactory
JmsTemplate需要一个对ConnectionFactory的引用
<bean
>
<property >
<!-- lets wrap in a pool to avoid creating a connection per send -->
<bean
>
<property
ref="jmsConnectionFactory" />
</bean>
</property>
<!-- custom MessageConverter
<property ref="defaultMessageConverter" />
</bean>
Spring提供了一个ConnectionFactory接口的实现,SingleConnectionFactory,它将在所有的createConnection调用中返回一个相同的Connection,
并忽略所有对close的调用。这在测试和独立环境中相当有用,因为多个JmsTemplate调用可以使用同一个连接以跨越多个事务。
SingleConnectionFactory通常引用一个来自JNDI的标准ConnectionFactory。
消息侦听容器
AbstractMessageListenerContainer负责消息接收的多线程处理并分发到各MDP中。一个消息侦听容器是MDP和消息提供者之间的一个中介,
用来处理消息接收的注册,事务管理的参与,资源获取和释放,异常转换等等。这使得应用开发人员可以专注于开发和接收消息(可能的响应)
相关的(复杂)业务逻辑,把和JMS基础框架有关的样板化的部分委托给框架处理。
<!-- this is the Message Driven POJO (MDP) -->
<!-- define MessageListenerAdapter -->
<bean >
<constructor -arg>
<property ref="mailService"></property>
</bean>
</constructor>
<!-- mey be other method -->
<property value="sendEmail"/>
<!-- custom MessageConverter define -->
<property ref="orderMessageConverter"/>
</bean>
<!-- and this is the attendant message listener container -->
<bean >
<property ref="jmsConnectionFactory"/>
<property ref="destination"/>
<property ref="messageListener"/>
</bean>
Spring提供了三种AbstractMessageListenerContainer的子类:
SimpleMessageListenerContainer
DefaultMessageListenerContainer
ServerSessionMessageListenerContainer
5.JMS的可靠性机制
(1) 确认
JMS消息只有在被确认之后,才认为已经被成功地消费了。消息的成功消费通常包含三个阶段:客户接收消息、客户处理消息和消息被确认。
在事务性会话中,当一个事务被提交的时候,确认自动发生。在非事务性会话中,消息何时被确认取决于创建会话时的应答模式(acknowledgement mode)。该参数有以下三个可选值:
Session.AUTO_ACKNOWLEDGE。当客户成功的从receive方法返回的时候,或者从MessageListener.onMessage方法成功返回的时候,会话自动确认客户收到的消息。
Session.CLIENT_ACKNOWLEDGE。客户通过消息的acknowledge方法确认消息。需要注意的是,在这种模式中,确认是在会话层上进行:确认一个被消费的消息将自动确认所有已被会话消费的消息。例如,如果一个消息消费者消费了10个消息,然后确认第5个消息,那么所有10个消息都被确认。
Session.DUPS_ACKNOWLEDGE。该选择只是会话迟钝第确认消息的提交。如果JMS provider失败,那么可能会导致一些重复的消息。如果是重复的消息,那么JMS provider必须把消息头的JMSRedelivered字段设置为true。
(2)持久性
JMS 支持以下两种消息提交模式:
PERSISTENT。指示JMS provider持久保存消息,以保证消息不会因为JMS provider的失败而丢失。
NON_PERSISTENT。不要求JMS provider持久保存消息。
(3)优先级
可以使用消息优先级来指示JMS provider首先提交紧急的消息。优先级分10个级别,从0(最低)到9(最高)。如果不指定优先级,默认级别是4。需要注意的是,JMS provider并不一定保证按照优先级的顺序提交消息。
(4)消息过期
可以设置消息在一定时间后过期,默认是永不过期。
(5)临时目的地
可以通过会话上的createTemporaryQueue方法和createTemporaryTopic方法来创建临时目的地。它们的存在时间只限于创建它们的连接所保持的时间。只有创建该临时目的地的连接上的消息消费者才能够从临时目的地中提取消息。
(6)持久订阅
首先消息生产者必须使用PERSISTENT提交消息。客户可以通过会话上的createDurableSubscriber方法来创建一个持久订阅,该方法的第一个参数必须是一个topic。第二个参数是订阅的名称。
JMS provider会存储发布到持久订阅对应的topic上的消息。如果最初创建持久订阅的客户或者任何其它客户使用相同的连接工厂和连接的客户ID、相同的主题和相同的订阅名再次调用会话上的createDurableSubscriber方法,那么该持久订阅就会被激活。JMS provider会象客户发送客户处于非激活状态时所发布的消息。
持久订阅在某个时刻只能有一个激活的订阅者。持久订阅在创建之后会一直保留,直到应用程序调用会话上的unsubscribe方法。
(7)本地事务
在一个JMS客户端,可以使用本地事务来组合消息的发送和接收。JMS Session接口提供了commit和rollback方法。事务提交意味着生产的所有消息被发送,消费的所有消息被确认;事务回滚意味着生产的所有消息被销毁,消费的所有消息被恢复并重新提交,除非它们已经过期。
事务性的会话总是牵涉到事务处理中,commit或rollback方法一旦被调用,一个事务就结束了,而另一个事务被开始。关闭事务性会话将回滚其中的事务。
需要注意的是,如果使用请求/回复机制,即发送一个消息,同时希望在同一个事务中等待接收该消息的回复,那么程序将被挂起,因为知道事务提交,发送操作才会真正执行。
需要注意的还有一个,消息的生产和消费不能包含在同一个事务中。
6. JMS消息类型:
TextMessage、MapMessage、BytesMessage、StreamMessage和ObjectMessage
ActiveMQ端口:1099(JMX),61616(默认的TransportConnector)
7.JMS 消息组成
JMS 消息由以下几部分组成:消息头,属性,消息体。
消息头:
包含客户端及 JSM 提供程序所需的标识、路由消息的信息
各种类型的消息都具有相同的消息头结构
消息头包含以下属性:
JMSDestination --消息发送的目的地。
JMSDeliveryMode --传递模式,有两种模式:PERSISTENT和NON_PERSISTENT,PERSISTENT表示该消息一定要被送到目的地,否则会导致应用错误。NON_PERSISTENT表示偶然丢失该消息是被允许的,这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。
JMSMessageID 唯一识别每个消息的标识,由JMS Provider 产生。
JMSTimestamp 一个消息被提交给JMS Provider 到消息被发出的时间。
JMSCorrelationID 用来连接到另外一个消息,典型的应用是在回复消息中连接到原消息。
JMSReplyTo 提供本消息回复消息的目的地址。
JMSRedelivered如果一个客户端收到一个设置了JMSRedelivered属性的消息,则表示可能该客户端曾经在早些时候收到过该消息,但并没有签收(acknowledged)。
JMSType 消息类型的识别符。
JMSExpiration 消息过期时间,等于QueueSender 的send方法中的timeToLive值或TopicPublisher 的publish 方法中的timeToLive值加上发送时刻的GMT时间值。如果timeToLive值等于零,则JMSExpiration被设为零,表示该消息永不过期。如果发送后,在消息过期时间之后消息还没有被发送到目的地,则该消息被清除。
JMSPriority 消息优先级,从0-9 十个级别,0-4 是普通消息,5-9 是加急消息。JMS 不要求JMS Provider严格按照这十个优先级发送消息,但必须保证加急消息要先于普通消息到达。
属性(Properties) -除了消息头中定义好的标准属性外,JMS提供一种机制增加新属性到消息头中,这种新属性包含以下几种:
属性的值可以是int,boolean,byte,short,long,float,double,String等;
可以通过getPropertyNames来取得所有的属性名;通过clearProperties来删除消息的属性;
Jms定义的属性主要是一些发送消息的用户(应用)标识,转发消息的重试次数等,如:JMSXDeliveryCount.....
应用需要用到的属性;
消息头中原有的一些可选属性;
JMS Provider 需要用到的属性。
消息体(Body) - JMS API定义了5种消息体格式
TextMessage、MapMessage(key是String,value是java原始类型)、BytesMessage、StreamMessage和ObjectMessage
8. AbstractMessageListenerContainer
Spring提供了三种AbstractMessageListenerContainer的子类,每种各有其特点。
SimpleMessageListenerContainer
这个消息侦听容器是三种中最简单的。它在启动时创建固定数量的JMS session并在容器的整个生命周期中使用它们。这个类不能动态的适应运行时的要求或参与消息接收的事务处理。然而它对JMS提供者的要求也最低。它只需要简单的JMS API。
DefaultMessageListenerContainer
这个消息侦听器使用的最多。和SimpleMessageListenerContainer一样,这个子类不能动态适应运行时侯的要求。然而,它可以参与事务管理。每个收到的消息都注册到一个XA事务中(如果配置过),这样就可以利用XA事务语义的优势了。这个类在对JMS提供者的低要求和提供包括事务参于等的强大功能上取得了很好的平衡。
ServerSessionMessageListenerContainer
这个子类是三者中最强大的。它利用JMS ServerSessionPool SPI允许对JMS session进行动态管理。它也支持事务。使用这种消息侦听器可以获得强大的运行时调优功能,但是对使用到的JMS提供者有很高的要求(ServerSessionPool SPI)。如果不需要运行时的性能调整,请使用DefaultMessageListenerContainer或SimpleMessageListenerContainer。
9. 事务管理
Spring提供了一个JmsTransactionManager为单个JMSConnectionFactory管理事务,JmsTransactionManager从指定的ConnectionFactory绑定了一个Connection/Session对到线程上。然而,在Java EE环境中,SingleConnectionFactory将把连接和session放到缓冲池中,所以绑定到线程的实例将依赖越缓冲池的行为。在标准环境下,使用Spring的SingleConnectionFactory将使得和每个事务相关的JMS连接有自己的session。JmsTemplate也可以和JtaTransactionManager以及具有XA能力的JMS ConnectionFactory一起使用来提供分布式交易。
当使用JMS API从一个连接中创建session时,在受管理的和非受管理的事务环境下重用代码会可能会让人迷惑。这是因为JMS API只有一个工厂方法来创建session并且它需要用于事务和模式确认的值。在受管理的环境下,由事务结构环境负责设置这些值,这样在供应商包装的JMS连接中可以忽略这些值。当在一个非管理性的环境中使用JmsTemplate时,你可以通过使用属性SessionTransacted和SessionAcknowledgeMode来指定这些值。当配合 JmsTemplate中使用PlatformTransactionManager时,模板将一直被赋予一个事务性JMS的 Session。
10.Webservice:cxf
<beans xmlns="http://www.springframework.org/schema/beans"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
<import resource="classpath:META-INF/cxf/cxf-servlet.xml" />
<jaxws:endpoint
implementor="demo.order.OrderProcessImpl" address="/OrderProcess" />
<jaxws:endpoint
implementor="#orgService" address="/OrgService">
</jaxws:endpoint>
</beans>
在jaxws.xsd中,你将看到有关 jaxws:endpoint, jaxws:server, jaxws:client的定义。
这里需要说明的内容有三点:
jaxws的target namespace是 http://cxf.apache.org/jaxws,由于目前CXF还处于incubating 的状态,没有cxf.apache.org这个域名。为了能让Spring来进行xml文档校验的时候能够获得jaxws.xsd,Spring提供了一种通过ClassPath中获得jaxws.xsd方法。具体步骤如下就是在META-INF中添加spring.schema的方式将jaxws.xsd与对应的URI进行绑定,同时也需要将NamespaceHandler注册进Spring中。
jaxws:endpoint 与 jaxws:server是对等的,他们都是对Web Services 服务端的描述。只是在JAXWS RI在最初的实现过程中,对于Server端的配置是通过Endpoint来进行描述的,而且JAXWS API也定义了Endpoint,因此为了保持与JAXWS API的一致性,在这里设置了jaxws:endpoint。
jaxws front end 与 simple front end之间的关系。 CXF除了提供JAXWS 的实现,也延续Xfire的风格提供了简单POJO Web Services的实现前端 simple front end。Jaxws front end 继承了simple front end的绝大部分方法,它与simple front end 的最大不同就是提供了Web Services Meta data (JSR 181)的支持,提供从Annotation中获取Web Services的能力。对于 jaxws:server 以及 jaxws:client 你可以在 simple front end中找到对应的 simple:server , simple:client