Sun Java System Message Queue 是一种功能全面的消息服务,提供符合 Java Messaging Specification (JMS) 1.1 的可靠、异步的消息传送功能。此外,Message Queue 还提供 JMS 规范之外的许多功能,以满足大型企业部署的需要。
Message Queue 3.7 UR1 是 Message Queue 3.6 的维护版本,它包含错误修复和少量较小的增强功能。本部分包含以下信息:
Message Queue 3.7 UR1 包括以下新功能:
这些功能将在以下各部分中进行描述。
为了简化产品交付过程,我们将 Sun Java Message Queue 的 Platform Edition 和 Enterprise Edition 进行了合并。从 Message Queue 3.7 UR1 开始只提供一个版本,这样可有效排除独立发行版中的功能限制。希望此举能简化您对本产品的体验。
合并版本还可以使 Message Queue 与 Solaris Enterprise System 更好地配合使用,并提供一种持久而广泛的权限,使您可以在无需支持、维护或功能补充的情况下使用 Enterprise Edition 功能。与以前版本相同,我们将继续提供用于支持和维护服务的多种授权选项。Message Queue 仍将与 Java Enterprise System 和 Application Platform Suite 打包在一起。请查看在线商店(网址为 http://www.sun.com)或与销售代表联系,以找到最适合您的选项。下表描述了新单一版本的 Message Queue 的升级途径。
表 1–2 Message Queue 3.7 UR1 的升级途径
以前版本 |
升级途径 |
注释 |
---|---|---|
Platform Edition |
Sun Java System Message Queue 3.7 UR1 |
现在 3.7 UR1 用户可使用所有功能(Platform 和 Enterprise)。购买许可证后就会提供支持选项。 |
Enterprise Edition |
Sun Java System Message Queue 3.7 UR1 |
未更改任何功能。提供一定范围的授权和支持选项。 |
Platform Edition 支持合同 |
升级到 Enterprise Edition 支持合同 |
将继续续订先前发行的 Platform Edition 的现有支持合同。不会为先前发行的 Platform Edition 发布新的 Platform Edition 合同。 |
Enterprise Edition 支持合同 |
无更改 |
继续续订现有合同。将会发布新的合同。 |
下表描述了各种 Message Queue 产品交付来源的更改。
表 1–3 Message Queue 产品交付来源的更改
产品 |
以前的交付来源 |
新的交付来源 |
注释 |
Open Message Queue |
不适用 |
Sun 下载中心产品页面 |
独立下载。仅支持社区。不提供支持合同。 |
Message Queue Platform Edition |
Sun 下载中心(通过 Message Queue 产品页面) |
不再可用 |
现在仅提供结合了 Platform 和 Enterprise 功能的单一 Message Queue 版本。 |
Message Queue Enterprise Edition 试用版(通过 Platform Edition) |
Sun 下载中心(通过 Message Queue 产品页面) |
不再需要试用版许可证 |
不再需要 |
Message Queue Enterprise Edition 90 天试用版(通过 Java Enterprise System 下载或 CD) |
Java Enterprise System 下载中心,早于版本 3 GA(2006 年 3 月) |
Solaris Enterprise System 下载中心 |
Solaris Enterprise System 许可证。具有产品许可证就会提供支持选项。(不再需要 90 天试用许可证。) |
Message Queue Enterprise Edition(通过 SunStore、CD、单个许可证、Java Enterprise System 许可证、Suite 许可证以及通过 Java Enterprise System 提供) |
Java Enterprise System 或 Suite 下载中心、介质 |
Solaris Enterprise System 或 Suite 下载中心、介质提供 |
无更改。 |
新函数:MQGetDestinationName()
MQGetDestinationName (const MQDestinationHandle destinationHandle, MQString * destinationName); |
使用此函数可以获取目的地的名称。返回的 destinationName 是一个副本,调用方通过调用 MQFreeString() 函数来负责释放该副本。
参数
要获取其名称的目的地的句柄。
名称的输出参数。
使用回复模式时,此函数会非常有用。可以使用 MQGetMessageReplyTo 函数获取要将消息发送到的目的地的句柄。然后可以使用 MQGetDestinationName 获取该目的地的名称。获取目的地名称之后,可以根据此名称处理消息。
新枚举值:MQ_MESSAGE
新的 MQMessageType MQ_MESSAGE 允许 C 客户端与其他 Message Queue 客户端(C 和 Java)交换 Message 类型的 JMS 消息:
typedef enum _MQMessageType {MQ_TEXT_MESSAGE = 0, MQ_BYTES_MESSAGE = 1, MQ_MESSAGE = 3, MQ_UNSUPPORTED_MESSAGE = 2} MQMessageType; |
MQ_MESSAGE 类型用于标识具有标题和属性但没有消息主体的消息。使用 MQCreateMessage() 函数可创建此类型的消息。
新连接属性 MQ_UPDATE_RELEASE_PROPERTY,用于指定已安装的 Message Queue 的更新发行版本。使用 MQGetMetaData() 函数可获取版本信息。
为了提高性能,已对 Message Queue 的持久性存储库格式进行了两处更改。一处是对文件存储库的更改,另一处是对 JDBC 存储库的更改。
文件存储库中的事务信息
已经对事务状态信息(存储在 Message Queue 的基于文件的持久性存储库中)的格式进行了更改,以减少磁盘 I/O 和提高 JMS 事务性能。
Oracle JDBC 存储库
在 Message Queue 的以前版本中,适用于 Oracle 的存储库结构使用 LONG RAW 数据类型来存储消息数据。在 Oracle 8 中,Oracle 引入了 BLOB 数据类型,而不再使用 LONG RAW 类型。Message Queue 3.7 UR1 已转为使用 BLOB 数据类型,以提高性能和提供更多支持。
由于这些更改会影响存储库兼容性,因此存储库版本已由 350 更改为 370。Message Queue 3.7 UR1 支持将持久性存储库从旧的 200 和 350 版本自动转换为 370 版本(同时适用于 JDBC 存储库和基于文件的存储库)。imqbrokerd 首次启动时,如果实用程序检测到早期版本的存储库,则会将存储库迁移到新格式,并留下早期的存储库。
如果需要回滚此升级,可以先卸载 Message Queue 3.7 UR1,然后重新安装以前运行的版本。由于未对存储库的早期副本进行任何更改,因此代理可以运行存储库的早期副本。
Sun Java Enterprise System 安装指南中提供了 Message Queue 的硬件和软件要求。
区域是一种 Solaris Container 技术,该技术可以在计算机上提供独立的环境,并在逻辑上使应用程序之间彼此分隔。区域允许您在 Solaris 操作系统实例中创建虚拟的操作系统环境。在不同区域中运行应用程序时,您可以在相同的计算机上运行同一应用程序的不同实例或不同版本,同时对资源进行集中管理和有效共享。
本部分对区域进行了简要描述,并说明了它们在 Message Queue 3.7 UR1 中的使用情况。
区域环境包括一个全局区域以及一个或多个非全局区域。首次在系统上安装 Solaris 10 时,只有一个全局区域。管理员可以创建其他非全局区域作为全局区域的子区域。每个区域都显示为运行 Solaris 的独立系统。每个区域都有其各自的 IP 地址、系统配置、运行应用程序的实例,以及文件系统上的位置。
全局区域包含可以在非全局区域之间共享的资源,从而可以将某些管理功能集中起来。例如,在全局区域中安装的软件包可用于(传播到)所有现有的非全局区域。这样可以集中执行生命周期管理(如安装、升级和卸载)。同时,非全局区域所提供的分隔功能也带来了更高的安全性,并允许您在相同的计算机上运行同一应用程序的不同配置的实例或不同版本。
非全局区域可以是完全根区域,也可以是稀疏根区域:选择哪种区域作为应用程序的环境取决于如何平衡管理控制和资源优化。
完全根区域包含全局区域上文件系统的读/写副本。在全局区域中安装的软件包(及其注册信息)将被自动复制到完全根区域。这样可以获得最佳的管理控制,但却会消耗资源。
稀疏根区域包含全局区域上部分文件系统的读/写副本;其他文件系统将作为只读文件系统进行挂载。通过只读文件系统以及注册信息的自动同步,稀疏根区域也可以使用全局区域中安装的软件包。稀疏根区域可以优化资源共享,而集中管理功能却会相对变弱。
组成 Java Enterprise System 的组件依赖于某些共享组件;这在使用区域方面造成了一些限制。在区域环境中,共享组件必须遵循以下规则。
区域中的所有共享组件必须为同一 JES 版本。此要求会导致三种结果。
如果要安装共享组件的不同版本,则每个版本都必须驻留在单独的区域中。
在区域中,如果对某个共享组件进行了升级或安装了较新版本,则必须升级所有共享组件。
在全局区域中安装共享组件时,必须根据需要对非全局区域中的共享组件进行升级。
由于稀疏根区域中使用只读文件系统,因此无法在稀疏根区域中安装共享组件。必须在全局区域中安装共享组件。依赖于共享组件的产品组件必须先安装在全局区域中,然后再传播到非全局区域。
由于 Message Queue 是 Java Enterprise System 的组件产品,因此上述要求会影响其安装,进而会限制其区域使用。
Message Queue 产品将被安装到 /usr 目录中,因此必须先在全局区域中进行安装或升级。
在全局区域中安装 Message Queue 时,它将被设置为传播到所有非全局区域。在全局区域中安装 Message Queue 之后,即在所有区域中安装了同一版本的 Message Queue:如果您登录到任意区域并运行命令 pkginfo -l SUNWiqu,您会看到 Message Queue 已被安装,并且与全局区域中安装的版本相同。接下来可以在每个区域中运行独立的 Message Queue 代理实例,因为这些实例进程并不共用 /var 和 /etc 目录中保存的实例和配置数据。(如果其他大多数 Java Enterprise System 组件都安装在全局区域,则不会传播这些组件。)
由于 Message Queue 将被传播到非全局区域,因此全局实例将始终链接到非全局区域中的安装。这样,无论您何时在全局区域中卸载或升级 Message Queue,它都会对非全局区域中运行的实例造成影响。以下示例说明这样做如何导致可能的意外结果。
在全局区域中安装 Message Queue 3.7 UR1。这会导致同时将 Message Queue 3.7 UR1 软件包安装到所有非全局区域中。
在完全根区域中卸载 Message Queue 3.7 UR1。然后在完全根区域中安装 Message Queue 3.6。
现在,不同区域中将运行不同版本的 Message Queue,您可能会发现这种设置非常有用。
在全局区域中卸载 Message Queue 3.7 UR1。这将从所有其他区域中卸载 Message Queue,包括完全根区域中的 Message Queue 3.6 实例。
请注意在全局区域中安装和卸载 Message Queue 的级联效应。
以下两个使用案例说明了如何在不同区域中安装 Message Queue 的不同实例和不同版本。
如果要在 Solaris 10、Solaris 10U1 或 Solaris 10U2 上的完全根区域中安装 Message Queue,则必须先在全局区域中升级 Lockhart。请查看错误 645030 的解决方法,以获取其他信息。
在全局区域中安装所需版本的 Message Queue。
这些版本将传播到任何现有的非全局区域中。如果创建了其他的非全局区域,则 Message Queue 也将传播到这些区域中。(您既可以在完全根区域中安装不同实例,也可以在稀疏根区域中安装不同实例,但使用稀疏根区域可以更有效地利用磁盘空间和其他资源)。
如果您希望 Message Queue 传播到任何其他非全局区域中,请立即创建这些区域。
在每个非全局区域中运行 Message Queue 的实例。