JMS结构模型
1.ConnectionFactory
A ConnectionFactory
object encapsulates a set of connection configuration parameters that has been defined by an administrator. A client uses it to create a connection with a JMS provider.
A ConnectionFactory
object is a JMS administered object and supports concurrent use.
JMS administered objects are objects containing configuration information that are created by an administrator and later used by JMS clients. They make it practical to administer the JMS API in the enterprise.
Although the interfaces for administered objects do not explicitly depend on the Java Naming and Directory Interface (JNDI) API, the JMS API establishes the convention that JMS clients find administered objects by looking them up in a JNDI namespace.
An administrator can place an administered object anywhere in a namespace. The JMS API does not define a naming policy.
It is expected that JMS providers will provide the tools an administrator needs to create and configure administered objects in a JNDI namespace. JMS provider implementations of administered objects should be both javax.jndi.Referenceable
and java.io.Serializable
so that they can be stored in all JNDI naming contexts. In addition, it is recommended that these implementations follow the JavaBeansTM design patterns.
This strategy provides several benefits:
- It hides provider-specific details from JMS clients.
- It abstracts administrative information into objects in the Java programming language ("Java objects") that are easily organized and administered from a common management console.
- Since there will be JNDI providers for all popular naming services, this means that JMS providers can deliver one implementation of administered objects that will run everywhere.
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by the JNDI API itself.
Clients should think of administered objects as local Java objects. Looking them up should not have any hidden side effects or use surprising amounts of local resources.
2.Connection
A Connection
object is a client's active connection to its JMS provider. It typically allocates provider resources outside the Java virtual machine (JVM).
Connections support concurrent use.
A connection serves several purposes:
- It encapsulates an open connection with a JMS provider. It typically represents an open TCP/IP socket between a client and the service provider software.
- Its creation is where client authentication takes place.
- It can specify a unique client identifier.
- It provides a
ConnectionMetaData
object. - It supports an optional
ExceptionListener
object.
Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections. The JMS API does not architect a reason for using multiple connections; however, there may be operational reasons for doing so.
A JMS client typically creates a connection, one or more sessions, and a number of message producers and consumers. When a connection is created, it is in stopped mode. That means that no messages are being delivered.
It is typical to leave the connection in stopped mode until setup is complete (that is, until all message consumers have been created). At that point, the client calls the connection's start
method, and messages begin arriving at the connection's consumers. This setup convention minimizes any client confusion that may result from asynchronous message delivery while the client is still in the process of setting itself up.
A connection can be started immediately, and the setup can be done afterwards. Clients that do this must be prepared to handle asynchronous message delivery while they are still in the process of setting up.
A message producer can send messages while a connection is stopped.
From :java api
3.Session
public interface Sessionextends java.lang.Runnable
A Session
object is a single-threaded (单线程)context for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine (JVM), it is considered a lightweight JMS object.
A session serves several purposes:
- It is a factory for its message producers and consumers.
- It supplies provider-optimized message factories.
- It is a factory for
TemporaryTopics
andTemporaryQueues
. - It provides a way to create
Queue
orTopic
objects for those clients that need to dynamically manipulate provider-specific destination names. - It supports a single series of transactions that combine work spanning its producers and consumers into atomic units.
- It defines a serial order for the messages it consumes and the messages it produces.
- It retains messages it consumes until they have been acknowledged.
- It serializes execution of message listeners registered with its message consumers.
- It is a factory for
QueueBrowsers
.
A session can create and service multiple message producers and consumers.
One typical use is to have a thread block on a synchronous MessageConsumer
until a message arrives. The thread may then use one or more of the Session
's MessageProducer
s.
If a client desires to have one thread produce messages while others consume them, the client should use a separate session for its producing thread.
Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection close
method.
It should be easy for most clients to partition their work naturally into sessions. This model allows clients to start simply and incrementally add message processing complexity as their need for concurrency grows.
The close
method is the only session method that can be called while some other session method is being executed in another thread.
A session may be specified as transacted. Each transacted session supports a single series of transactions. Each transaction groups a set of message sends and a set of message receives into an atomic unit of work. In effect, transactions organize a session's input message stream and output message stream into series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent. If a transaction rollback is done, the transaction's sent messages are destroyed and the session's input is automatically recovered.
The content of a transaction's input and output units is simply those messages that have been produced and consumed within the session's current transaction.
A transaction is completed using either its session's commit
method or its session's rollback
method. The completion of a session's current transaction automatically begins the next. The result is that a transacted session always has a current transaction within which its work is done.
The Java Transaction Service (JTS) or some other transaction monitor may be used to combine a session's transaction with transactions on other resources (databases, other JMS sessions, etc.). Since Java distributed transactions are controlled via the Java Transaction API (JTA), use of the session's commit
and rollback
methods in this context is prohibited.
The JMS API does not require support for JTA; however, it does define how a provider supplies this support.
Although it is also possible for a JMS client to handle distributed transactions directly, it is unlikely that many JMS clients will do this. Support for JTA in the JMS API is targeted at systems vendors who will be integrating the JMS API into their application server products.
表示一个单线程的上下文,用于发送和接收消息。由于会话是单线程的,所以消息是连续的,就是说消息是按照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持,会话上下文将保存一组消息,直到事务被提交才发送这些消息。在提交事务之前,用户可以使用回滚操作取消这些消息。一个会话允许用户创建消息生产者来发送消息,创建消息消费者来接收消息。
4.MessageConsumer
A client uses a MessageConsumer
object to receive messages from a destination. A MessageConsumer
object is created by passing a Destination
object to a message-consumer creation method supplied by a session.
MessageConsumer
is the parent interface for all message consumers.
A message consumer can be created with a message selector. A message selector allows the client to restrict the messages delivered to the message consumer to those that match the selector.
A client may either synchronously receive a message consumer's messages or have the consumer asynchronously deliver them as they arrive.
For synchronous receipt, a client can request the next message from a message consumer using one of its receive
methods. There are several variations of receive
that allow a client to poll or wait for the next message.
For asynchronous delivery, a client can register a MessageListener
object with a message consumer. As messages arrive at the message consumer, it delivers them by calling the MessageListener
's onMessage
method.
It is a client programming error for a MessageListener
to throw an exception.
5.MessageProducer
A client uses a MessageProducer
object to send messages to a destination. A MessageProducer
object is created by passing a Destination
object to a message-producer creation method supplied by a session.
MessageProducer
is the parent interface for all message producers.
A client also has the option of creating a message producer without supplying a destination. In this case, a destination must be provided with every send operation. A typical use for this kind of message producer is to send replies to requests using the request's JMSReplyTo
destination.
A client can specify a default delivery mode, priority, and time to live for messages sent by a message producer. It can also specify the delivery mode, priority, and time to live for an individual message.
A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT when it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed).
A JMS provider should do its best to expire messages accurately; however, the JMS API does not define the accuracy provided.
Including:QueueSender,TopicPublisher
6.Destination
A Destination
object encapsulates a provider-specific address. The JMS API does not define a standard address syntax. Although a standard address syntax was considered, it was decided that the differences in address semantics between existing message-oriented middleware (MOM) products were too wide to bridge with a single syntax.
Since Destination
is an administered object, it may contain provider-specific configuration information in addition to its address.
The JMS API also supports a client's use of provider-specific address names.
Destination
objects support concurrent use.
A Destination
object is a JMS administered object.
JMS administered objects are objects containing configuration information that are created by an administrator and later used by JMS clients. They make it practical to administer the JMS API in the enterprise.
Although the interfaces for administered objects do not explicitly depend on the Java Naming and Directory Interface (JNDI) API, the JMS API establishes the convention that JMS clients find administered objects by looking them up in a JNDI namespace.
An administrator can place an administered object anywhere in a namespace. The JMS API does not define a naming policy.
It is expected that JMS providers will provide the tools an administrator needs to create and configure administered objects in a JNDI namespace. JMS provider implementations of administered objects should implement the javax.naming.Referenceable
and java.io.Serializable
interfaces so that they can be stored in all JNDI naming contexts. In addition, it is recommended that these implementations follow the JavaBeansTM design patterns.
This strategy provides several benefits:
- It hides provider-specific details from JMS clients.
- It abstracts JMS administrative information into objects in the Java programming language ("Java objects") that are easily organized and administered from a common management console.
- Since there will be JNDI providers for all popular naming services, JMS providers can deliver one implementation of administered objects that will run everywhere.
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by the JNDI API itself.
Clients should think of administered objects as local Java objects. Looking them up should not have any hidden side effects or use surprising amounts of local resources.
I will continue to learn about the detail about the difference between TOPIC and QUEUE, and the defination of the Message.
相关推荐
jms Javamessageservice结构图
体系结构………………………………………………………………………………………..4 JMS消息模型…………………………………………………………………………………..7 JMS消息工具…………………………………………...
根据企业应用程序间进行消息服务的实际需要,深入研究Java消息服务(Java Message Service,JMS)技术,结合其中的"发布/订阅式"和"点对点式"两种消息收发模式,提出了一个基于JMS体系结构的全新的消息服务模型,并针对股票...
JMS基本结构说明 说明了基本架构, 是一个内部演示的ppt文档
赠送jar包:spring-jms-4.3.20.RELEASE.jar; 赠送原API文档:spring-jms-4.3.20.RELEASE-javadoc.jar; 赠送源代码:spring-jms-...人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。
详细介绍了JMS的基本结构,开发实例,从入门到精通。
赠送jar包:spring-jms-4.3.12.RELEASE.jar; 赠送原API文档:spring-jms-4.3.12.RELEASE-javadoc.jar;...人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。 双语对照,边学技术、边学英语。
赠送jar包:spring-jms-4.3.20.RELEASE.jar 赠送原API文档:spring-jms-4.3.20.RELEASE-javadoc.jar ...人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。 双语对照,边学技术、边学英语。
本教程描述了消息服务的概念和一些应用事例,说明了 JMS 的基本概念和结构,并就消息服务的发布/订阅、点对点模式编写了简单代码,最后讨论的JMS的一些高级问题,如食物、可靠性、可恢复性等。
赠送jar包:geronimo-jms_1.1_spec-1.1.1.jar; 赠送原API文档:geronimo-jms_1.1_spec-1.1.1-javadoc.jar; 赠送源代码:geronimo-jms...人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。
赠送jar包:spring-jms-4.3.12.RELEASE.jar; 赠送原API文档:spring-jms-4.3.12.RELEASE-javadoc.jar; 赠送源代码:spring-jms-4.3.12....人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。
● 说明:RMI-IIOP是Java远程方法调用(RMI,Remote Method Invocation)的一个兼容CORBA的版本,CORBA是Common Object Request Broker Architecture的缩写,即公用对象请求代理(调度)体系结构。RMI-IIOP通过...
赠送jar包:geronimo-jms_1.1_spec-1.1.1.jar; 赠送原API文档:geronimo-jms_1.1_spec-1.1.1-javadoc....人性化翻译,文档中的代码和结构保持不变,注释和说明精准翻译,请放心使用。 双语对照,边学技术、边学英语。
spring-framework.zip,弹簧结构弹簧框架
网络支付系统涉及的DES运算 MQ转发存储 JMS消息队列 MD5算法以及 支付系统的数据结构
我自己用Eclipse写的JMS例子。完全是用来理解JMS的基础用法,没有太大的生产... 代码结构简单,只有三个java代码页,只演示基本功能。安装好jboss之后,不需要进行任何配置,在本机运行和编译代码。仅供学习JMS使用
提出并设计一个基于消息驱动的用户状态实时监控系统,以JMS作为基础结构,以XML作为消息载体,从而实现平台和数据的独立,并对系统实现过程中涉及到的关键技术进行了研究分析。
JMS提供程序可以集成在应用程序服务器中,从而允许使用Java EE连接器体系结构。 JMS应用程序由以下部分组成: JMS提供者:实现JMS接口并提供管理控制的消息系统。 JMS客户端:产生和使用消息的组件。 Java EE或...
前提条件是,此演示需要JMS基础结构才能运行。 您可以选择您喜欢在本示例中使用的任何JMS代理。 我们将展示3个使用Apache ActiveMQ , Apache ActiveMQ Artemis和TIBCO EMS的示例: Apache ActiveMQ 无需创建主题或...
该应用程序将具有一个基于REST的接口,该接口将接受JSON请求(通过HTTP),然后将它们传递到队列系统(JMS)上,以持久存储到非结构化数据库中。 然后,写入成功/失败的响应将传递到AMQP代理,最终还将写入一条记录...