论文部分内容阅读
在这一段关于网络与应用的分析中，我所提到的信息队列（ Messaging Queuing ，MQ）可能对很多人来说并不熟悉。
MQ没有像HTTP应用协议一样得到大众的关注，也很少有人会写关于它的文章。
对MQ最好的描述也许是“发送与队列之间的信息与平台的应用中间件”。它是目前IBM大型机与基于Linux和Windows平台运营的软件应用或应用服务器，包括IBM的WebSphere之间沟通的因素。
使用MQ API的程序发送和接受特定的数据应用是从队列中完成的，而非从应用本身。具体的应用程序通过队列命名完成与其的联系。它发送的信息具有弹性，可以同步或异步操作。
MQ具有一些很吸引人的特性。
其一，目标应用并不需要是并行运行或很繁忙的信息队列。这些信息可以请求数据或更新数据。大多数情况下，异步应用程序可以只是“发送并忘记”。
另外，在网络临时断开或是需要启动远程应用等情况下，MQ可以确保信息被交付给目标应用程序。因此，它不仅能被不同的平台很容易地接受，同时还较传统应用层协议具有更强大的可交付性和可用性机制。
当我第一次开始分析MQ协议时，让我惊讶的是，没有一个大牌商业分析商曾经对它进行解读。也没有针对它的开源的Wireshark解码。
我得指出，学习这一协议对我来说是非常有趣并且非常有意义的。很多时候，一个交互式应用程序中，利用MQ会非常有效。运行在TCP 1414端口的MQ可以识别信息的队列名称、管理器等信息并将其交付给目标应用程序。实际的信息数据可以是只有目标应用能够理解的XML专用交换数据。
我嘗试利用MQ应对程序的申请，完成打开一个队列、将数据加入队列、打开一个结果队列、检索数据等命令。在这一过程中，所有队列行动都完成得非常迅速，最长不超过38毫秒。
我还发现，MQ可以处理优先次序、信息有效期、为特定应用程序提供多个输入或输出队列、数据转换、提供即时信息传递确认、信息分组发送等更多的功能。看来，只有充满想象力的程序员才能用好MQ。
MQ没有像HTTP应用协议一样得到大众的关注，也很少有人会写关于它的文章。
对MQ最好的描述也许是“发送与队列之间的信息与平台的应用中间件”。它是目前IBM大型机与基于Linux和Windows平台运营的软件应用或应用服务器，包括IBM的WebSphere之间沟通的因素。
使用MQ API的程序发送和接受特定的数据应用是从队列中完成的，而非从应用本身。具体的应用程序通过队列命名完成与其的联系。它发送的信息具有弹性，可以同步或异步操作。
MQ具有一些很吸引人的特性。
其一，目标应用并不需要是并行运行或很繁忙的信息队列。这些信息可以请求数据或更新数据。大多数情况下，异步应用程序可以只是“发送并忘记”。
另外，在网络临时断开或是需要启动远程应用等情况下，MQ可以确保信息被交付给目标应用程序。因此，它不仅能被不同的平台很容易地接受，同时还较传统应用层协议具有更强大的可交付性和可用性机制。
当我第一次开始分析MQ协议时，让我惊讶的是，没有一个大牌商业分析商曾经对它进行解读。也没有针对它的开源的Wireshark解码。
我得指出，学习这一协议对我来说是非常有趣并且非常有意义的。很多时候，一个交互式应用程序中，利用MQ会非常有效。运行在TCP 1414端口的MQ可以识别信息的队列名称、管理器等信息并将其交付给目标应用程序。实际的信息数据可以是只有目标应用能够理解的XML专用交换数据。
我嘗试利用MQ应对程序的申请，完成打开一个队列、将数据加入队列、打开一个结果队列、检索数据等命令。在这一过程中，所有队列行动都完成得非常迅速，最长不超过38毫秒。
我还发现，MQ可以处理优先次序、信息有效期、为特定应用程序提供多个输入或输出队列、数据转换、提供即时信息传递确认、信息分组发送等更多的功能。看来，只有充满想象力的程序员才能用好MQ。