操作JMS成立动静通报系统
副标题#e#
在开始之前需要说明，为了领略本文，我们但愿读者拥有Java编程的相当坚硬的基本。我们将试图尽大概简朴地表明什么是JMS，可是在你可以或许成立本身的措施并正确地领略它们之前，你需要有一些利用JNDI开拓实际应用措施的履历。
JMS（Java动静处事）是一个动静互换尺度，它答允利用J2EE应用措施组件成立、发送、吸收和读打动静。它假设漫衍式通讯拥有自由（free）的毗连、是靠得住的（reliable）和异步的（asynchronous）。
Exchange（互换）系统
动静互换反应了措施组件或应用措施之间的一种交互浸染。动静互换系统是一种雷同于下的系统：一个相似系统的客户端可以发送和吸收任何其它客户端的动静。每个客户端都并入系统的署理中，它提供了成立、发送、吸收和读打动静的大概。
互换系统使得漫衍式的交互操纵成为大概。组件在目标地（Destination）发送动静，收件人也可以在沟通的目标地中获得这个动静。发送者和收件人不必然是相互熟悉的。换句话说，它并没有强迫发送者知道一些收件人的信息，也没有强迫收件人知道某些发送者的信息。发送者和收件人只需要知道动静的名目以及要达到的目标地。在这种景象下，上述的系统差异于与它细密相连的一些技能，譬喻长途要领挪用（RMI），它只要求开拓人员相识RMI中的一些要领。
动静通报系统
动静通报系统是一种漫衍式的系统，是基于系统组件之间的异步动静互换。面向动静的中间件（Message-Oriented Middleware，MOM）就是这种产物，动静通报系统是在它的道理上成立的。
动静通报系统应用软件不会直接地通讯（这与传统的系统（基于RMI的）形成光鲜的比较），而需要依赖MOM的辅佐。假如系统的某个组件但愿给另一个组件发送动静，它将把给定的动静发送给MOM，接着MOM把该动静发送给收件人。
与传统的基于RMI构建的系统对比，它有以下利益：
·发送动静的应用措施不需要等候回应，可以继承执行。
· 没有强迫发送动静的应用措施和特定动静的收件人在某个特定的时刻是激活的。假如动静的收件人不是激活的，MOM担保收件人一旦激活就当即收到该动静。
· 系统组件没有直接地相相互连。它们被分分开了，这就是在运行时刻能把组件从一个主机传输到另一个、却不会间断系统可用性的原因。
动静互换模子：点对点模子和颁发－预订模子
今朝有两种“根基的”动静互换模子：点对点模子和颁发－预订（pub-sub）模子。点对点模子应用于一个或多个组件（发送者）仅仅给一个组件收件人（吸收者）发送动静的景象。这种模子是基于动静行列观念的：发送者把动静发送到行列中，吸收者从该行列中读打动静。在点对点模子中，沟通的行列上大概存在多个吸收者，可是MOM只给个中一个通报动静。给哪一个通报动静依赖于MOM的实现（implementation）。
颁发－预订模子应用于一个或多个组件（颁发者）给一个或多个组件收件人（预订者）发送动静的景象。这种特定的模子是基于动静主题（message topic）观念的：颁发者把动静发送到某个主题中，而该特定主题的预订者吸收这些动静。
颁发－预订模子看起来越发“优雅”，可是许多颁发－预订模子不能担保动静凭据发送的序次通报（它与点对点模子相反，点对点行列实现了FIFO（先进先出）道理）。因此，动静的序次很重要（可能为了同步需要利用动静的头和属性部门）的时候，就应该制止回收颁发－预订模子。
Java动静处事（JMS）是利用面向动静中间件的一套Java API，它答允你的应用措施成立、发送、吸收和读打动静。这组措施集位于J2EE措施包布局树上的javax.jms措施包中。JMS在许多MOM产物中获得了实现，个中iPlanet Message Queue、 IBM MQSeries、Progress Software SonicMQ、BEA WebLogic Server、Prism Technologies OpenFusion等最有名气，也存在一些免费的实现。
JMS同时支持动静互换的两种“根基的”模子。可是，其说明（specification）并没有要求厂商同时实现两种模子，尽量大大都JMS产物实现了点对点和颁发－预订模子。
#p#副标题#e#
JMS应用措施
JMS应用措施的主要部门是：
· 发生毗连的部门和目标地
· 毗连
· 对话
· 发活跃静的部门
· 利用动静的部门
· 动静
发生毗连的部门（ConnectionFactory）是认真成立JMS毗连的工具。每个ConnectionFactory都是QueueConnectionFactory或TopicConnectionFactory的一个副本（copy）。MOM打点器成立特定的工具，并把它与JNDI树关联起来，这样JMS客户端就可以或许利用尺度的JNDI查找表获得ConnectionFactory的进口。在点对点的模子中，它利用了javax.jms.QueueConnectionFactory；在颁发－预订模子中，它利用的是javax.jms.TopicConnectionFactory。
目标地（Destination）——它是行列或主题，这依赖于我们利用了下面哪种模子：javax.jms.Queue或javax.jms.Topic。
#p#分页标题#e#
毗连（Connection）——它大概是客户端和处事应用之间的开放的TCP/IP。它可以被用于成立一个或少量的对话。在你的应用措施可以或许吸收动静前，你必需挪用start()要领。为了暂停发送动静，你需要挪用stop()。
对话（Session）——在JMS毗连的辅佐下成立的工具，被客户端用作发送和吸收动静。
发活跃静的部门（MessageProducer）——对话成立的工具，被用于在目标地中发送动静。
利用动静的部门（MessageConsumer）——对话成立的工具，用于吸收动静。为了同步吸收动静，需要利用receive()要领。对付异步的景象，利用MessageListener和独一的要领——onMessage()。在该要领中，在界说的动静达到后应该执行必然的操纵。
动静（Message）——动静自己。JMS动静由三个部门构成：
· 动静头
· 属性（不是须要的）
· 动静体（不是须要的）
本文没有表明更多的细节信息，你可以在官方文档中找到详细的细节。
什么时候利用EJB 2.0
请留意下述各项内容：
在新的EJB 2.0类型中，与JMS的集成是通过成立新的EJB范例——动静驱动Bean（MDB）来实现的。MDB的特性是客户端不会利用长途接口（remote interface）与它通讯。其交互操纵的独一途径是通过动静发送。MDB仅仅是动静监听措施，是一个实现了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的类，没有任何其它的成果。个中的第一个接口只有两个要领：setMessageDrivenContext() 和ejbRemove()。第二个接口只有一个要领：onMessage()。这个类型还需要一个不带参数的ejbCreate()成立要领。客户端不会直接与MDB通讯；它不会成立MDB。容器（container）自身抉择什么时候和需要几多个MDB来处理惩罚来自特定目标地的动静。MDB的主要缺陷是它只能从一个目标地吸收到动静。
代码示例
我们假设你已经安装了J2SE（可以在http://java.sun.com/j2se/找到它），而且已经安装并运行了JBoss应用措施处事器（可以在http://www.jboss.org/找到它）。
为了编译下面的示例，你需要输入：
javac -classpath .;C:\jboss-3.2.3\client\jbossall-client.jar SimpleSender.java
为了运行它，你需要输入：
java -classpath .;C:\jboss-3.2.3\client\jbossall-client.jar SimpleSender
（在输入时，请用你本身的JBoss目登科代C:\jboss-3.2.3。同时还要记着，在你可以或许运行这些示例前，JBoss处事器必需处于运行状态。）
好了，此刻我们开始成立示例发送措施和吸收措施了：
// SimpleSender.java
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
public class SimpleSender {
public static void main(String argv[]) {
new SimpleSender();
}
public SimpleSender() {
try {
QueueConnectionFactory myQConnFactory;
Queue myQueue;
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
properties.put(Context.URL_PKG_PREFIXES, "org.jnp.interfaces");
properties.put(Context.PROVIDER_URL, "localhost");
Context ctx = new InitialContext(properties);
myQConnFactory = (QueueConnectionFactory)ctx.lookup
("UIL2ConnectionFactory");
myQueue = (Queue) ctx.lookup("queue/testQueue");
ctx.bind ("SimpleSender", myQueue);
QueueConnection con = myQConnFactory.createQueueConnection();
QueueSession session = con.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
TextMessage textMessage = session.createTextMessage();
QueueSender sender = session.createSender(myQueue);
con.start();
for (int i=0; i<10; i++) {
textMessage.setText("Hello World #" + i);
sender.send(textMessage);
}
con.close();
ctx.close();
} catch(Exception e) {
e.printStackTrace();
}
}
}
#p#分页标题#e#
我们有两种吸收动静的途径。第一种是利用javax.jms.QueueReceiver的receive()要领向行列同步请求动静。这大概阻塞吸收措施，直到它不吸收动静为止，可能如何某个动静没有在特定的时距离断内达到而返回超时操纵。第二种是一旦可以会见动静了就异步吸收动静，利用javax.jms.MessageListener挪用onMessage()要领，它会处理惩罚动静的内容。
成立吸收措施的许多步调与成立发送措施的步调雷同：
// SyncReceiver.java
import java.util.Properties;
import javax.jms.*;
import javax.naming.*;
public class SyncReceiver {
public static void main(String argv[])
{
new SyncReceiver();
}
public SyncReceiver() {
try {
QueueConnectionFactory myQConnFactory;
Queue myQueue;
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory");
properties.put(Context.URL_PKG_PREFIXES, "org.jnp.interfaces");
properties.put(Context.PROVIDER_URL, "localhost");
Context ctx = new InitialContext(properties);
myQConnFactory = (QueueConnectionFactory)ctx.lookup("UIL2ConnectionFactory");
myQueue = (Queue) ctx.lookup("queue/testQueue");
ctx.bind("SyncReceiver", myQueue);
QueueConnection con = myQConnFactory.createQueueConnection();
QueueSession session = con.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
QueueReceiver receiver = session.createReceiver(myQueue);
con.start();
for (int i=0; i<10; i++) {
TextMessage textMessage = (TextMessage) receiver.receive();
System.out.println("Got: " + textMessage.getText());
}
con.close();
ctx.close();
} catch(Exception e) {
e.printStackTrace();
}
}
}
跋文
数据库是长时间数据存储的抱负途径，可是用户改观的姑且数据和用户通知的存储不是它们的强项。尽量被认为是效率低下的，可是数据库查询照旧频繁地用于现实中。所有请求都需要大量特另外“埋没的”事情，假如大量的工具频繁地会见一个数据库，大概会导致数据库处事器和网络的严重的负载。在大大都时候，请求不会返回任何数据，更糟的景象是，将已知的信息返回处处理惩罚进程中。
简朴地说，数据库不是打算用于频繁的查询或事件的。假如一旦数据或任何事件产生了改变就要当即作出回响，那么更简朴和效率更高的途径将是利用异步动静。
技能处理惩罚的应用措施（譬喻公函畅通、认领的处理惩罚等）大大都利用了MQ（动静行列），因为MQ模子与技能处理惩罚模子的统计特征雷同，它认可“办公室”的形式，在个中每小我私家都有本身吸收和发送的邮件箱。
这类应用措施的典范特征是利用了大量的署理（署理大概是人、自动处理惩罚的操纵、甚至于物理设备，譬喻打印机或设备），个中每个署理城市碰着一些小的机能困难，并凭据业务逻辑把它通报到下一个署理。在成立这类应用措施的时候，开拓的主要事务是对快速的机能的掌握，同时要掌握开拓时失败的缺乏。利用数据库的MQ处事器简化了处理惩罚应用措施中的技能处理惩罚的进程；这样做越发机动、容易扩展。
同样，对付聚焦于事务的应用措施，利用MQ技能也长短常利便的。这涉及处处理惩罚财务金融和新处事规模的一些应用措施。在财务金融市场，操纵必需很快地完成；用户对付即时产生的改变感乐趣。
