1 . 本地队列 :
一个本地队列是一个物理上位于本地队列管理器中的队列。本地队列实际上存在与本地系统的内存或磁盘存储终。本地队列管理器控制队列的访问。应用程序可以“PUT”消息到本地队列，也可以从本地队列“GET”消息，另外程序还可以查询或修改这些队列的 某些属性。对队列属性的修改需要相应的权限。
2 . 远程对列 :
一个远程队列属于一个不与该应用程序直接相连的队列管理器。对这类队列的访问包含有本地队列管理器和远程队列管理器的通信过程。这种通信涉及到通道。 应用程序可对远程队列进行某些操作，比如程序可以向一个远程队列放一条消息，但程序不能从远程队列中去消息。应用程序只能从本地队列读取消息。
应用程序有两种不同的方法可用来访问远程队列。第一种是当程序打开一个远程队列时同时提供队列管理器名和队列名两个参数。这要求程序知道目的队列属于哪个队列管理器。第二种方法是在本地队列管理器上存在一个远程队列的定义，这个定义包含有足够的信息让本地队列管理器确定该远程队列所在的队列管理器。远程队列定义中的目的队列不一定是远程队列管理器的本地队列，它也可以是一个远程队列定义。(这就话和之后的网关队列管理器的创建有关系)
应用程序放一条消息到Q1，Q1是本地队列管理器QM1上的一个远程队列定义：Q2at QM2。QM2是远程队列管理器。Q2是QM2上的一个远程队列定义Q3 at QM3。Q3是QM3的一个本地队列，经过两次传送，消息最终到达Q3这个QM3的本地队列。
有多种原因使这种多跳（Multihop）传送变得有意义。在一个TCP/IP网络内部，所有机器都有IP地址，IP协议本身处理节点间的路由选择。但假设消息需要穿过不同类型的网络，这就需要中间件参加路由选择。在图中，QM2位于一台连接TCP/IP网和SNA网的机器上，只需在QM2上提供一个远程队列定义Q2：Q3 at QM3，就可以实现消息的跨网络传输。
因为对远程队列的访问总是涉及到队列管理器之间的通信，因而我们需要定义其他一些资源，比如通道、传输队列（Transmission queue）。
3 . 传输队列(Transmission queue)：
传输队列是临时存储目标为远程队列管理器的消息的队列。队列管理器利用传输队列把消息分阶段地发向远程队列。队列管理器和消息移动程序一起负责把数据传送到远程队列。当队列管理器收到把一条消息发往远程队列的要求后，它把消息发送到一个与目的队列管理器相关联的传输队列，传输队列位于本地队列管理器上。目的队列管理器的名称可能由应用程序提供，也可以从远程队列定义中得到。
一个传输队列是两个队列管理器之间的连接的一端。所有直接目的地是同一队列管理器的消息都可放在同一个传输队列上，这些消息的最终目的可能不一样。把消息从一个队列管理器传送到另一个队列管理器只需要一个传输队列，然而也有可能在两个队列管理器之间存在着多个连接以提供不同的传输服务，每个连接都带有一个不同的传输队列。
传输队列是由MCA处理的，MCA负责在队列管理器之间可靠地传送消息。MCA实际上是处理传输队列上消息的MQI应用程序。
4 . 动态队列和模板队列：
除了有固定定义的队列之外，WebSphere MQ还为程序在它们执行时提供了动态地创建队列的能力。例如,一个应用程序作为某种服务的客户，它可能创建一个动态队列，并通知服务器把对服务要求的响应发送到该动态队列。当然，这种情况也可以使用具有永久定义的队列。为了简化在创建动态队列时所必需设置的许多参数，动态队列总是基于模板队列被创建的，模板队列定义了动态队列的所有属性。当应用程序试图打开一个模板队列时，WebSphere MQ就创建一个动态队列。WebSphere MQ为应用提供了系统模板队列。
动态队列也可以分成两种，它们的生存周期和故障恢复特性不同。在创建临时动态队列（Temorary dynamic queue）的应用程序关闭时，这些队列将被删除，队列上的消息将丢失。这类动态队列不支持消息的持久性。如果队列管理器发生故障重新启动，临时动态队列也不会被恢复。另一种动态队列是持久动态队列（Permanent dynamic queue）。只有当一个应用程序关闭持久动态队列时定义删除选项，持久动态队列才会被删除。删除持久动态队列的程序不一定是创建持久动态队列的程序，持久动态队列在队列管理器重启后会被恢复，并且支持具有持久性的消息。
5 . 启动队列
启动队列是在触发中使用的队列。如果队列管理器将使用触发，则必须至少为此队列管理器定义一个启动队列。队列管理器在触发器事件发生时将触发器消息放入启动队列。触发器事件是由队列管理器检测的条件的逻辑组合。例如，当队列上的消息数达到预定义深度时，可能会生成触发器事件。此事件使队列管理器将触发器消息放入指定的启动队列。此触发器消息由触发器监视器（即监视启动队列的特殊应用程序）检索。然后触发器监视器启动在触发器消息中指定的应用程序。
6 . 群集传输队列
每个在群集中的队列管理器有一个称为 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的群集传输队列。当您定义队列管理器时，按缺省情况创建此队列的定义。作为群集一部分的队列管理器可以将群集传输队列上的消息发送到在同一群集中的任何其它队列管理器。 在路由解析期间，群集传输队列优先于缺省传输队列。 当队列管理器是群集的一部分时，缺省操作是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非当目标队列管理器不是此群集的一部分。
7 . 死信队列 （Dead letter queue）
死信（未传递的消息）队列是存储无法发送到其正确目的地的消息的队列。有时候会出现队列管理器不能把消息发送到目的地的情况，此时消息将被发送到某个死信队列中。死信队列中的消息常常暗示了系统可能出现的问题。例如当一条消息到达目的队列管理器之后却发现目的队列并不存在。或者目的队列出现不能接收信消息的情况，比如目的队列已经满了，或者它被设置成不允许再加入新的消息。并不是所有的放消息操作的失败都导致消息被放入死信队列，例如，由于本地队列出现错误造成应用程序不能“放”消息，此时MQI调用直接把错误码返回给应用程序。
有些错误只能由死信队列报告，例如，一条消息穿越网络之后到达目的队列管理器，却发现目的队列已满。发现错误的机器不同于最初“放”消息应用程序所在的机器，甚至可能放消息的应用程序已不在运行状态。此时目的队列管理器把这条消息发往它所拥有的死信队列，而不是简单地扔掉该条消息。这样使得这次错误是可见的，也给应用程序提供了一个改正错误的机会。
死信队列是WebSphere MQ面对远端系统错误时的一种解决方案。应用程序可以利用WebSphere MQ提供的其他一些工具来监视并确保消息的可靠传送和接收。
在队列管理器创建时，系统会缺省创建一个死信队列，队列名是SYSTEM.DEAD.LETTER.QUEUE。建议在生产系统上，需要独立创建一个死信队列，而不使用系统缺省的死信队列。
8 . 命令队列
命令队列 SYSTEM.ADMIN.COMMAND.QUEUE 是用来存放由应用管理程序放的具有PCF（programcommand format）的消息的队列。该队列主要用于编写管理程序时使用。具体的使用将在后续章节介绍。在创建队列管理器时将为每个队列管理器自动创建命令队列。
9 . 回复队列
当应用程序发送请求消息时，接收消息的应用程序可以将回复消息发送给发送应用程序。此回复消息放入一个称为回复队列的队列中，它通常是发送应用程序的本地队列。回复队列的名称由作为消息描述符一部分的发送应用程序指定。
10 . 别名队列
别名队列实际上是本地队列、远程队列定义或队列名表的另外一个名字。它是一种简单的名字到名字的映射，它允许应用程序用另外一个名字来访问队列。WebSphere MQ已经为应用程序屏蔽了许多底层系统细节，特别是网络通信的细节，而别名队列允许在不修改应用程序的条件下访问其他名字的队列。
