一 : ERP入门经典学习教程
二 : 易经学习教材（一）
易经学习教程（一）
（作者：劝学网小雅）
前言
一、什么是易经
易经是我国春秋以前解释“易”的经典书籍，是华夏智慧和文化的结晶。人们所知道的《易经》有三部《连山易》、《归藏易》、《周易》，前2部已经失传，真正完整保存下来的只有周易。社会上不断有人声称已经发掘出了连山易和归藏易，并整理出版了相关书籍，但这些书籍被许多人认为是1种抄作，并没有得到专家的认可和社会的承认。不过，人们通过古代易学文献的描述，已经确定了连山易是以“艮”卦为首，归藏易以“坤”卦为首，而周易是以“乾”卦为首。诸如南怀瑾这样的专家认为，堪舆、医药等方面有关易的运用，这与连山易、归藏易是分不开的。
几千年来，易经一直被人们誉为“群经之首”，这是因为易经包罗了宇宙万物产生、变化的的根本规律，其原理被无数的智者所证实并广泛得到应用，甚至所有的哲学思想，在易经里面都能找到踪迹，然而人们却无法用所谓“科学”的方法来全面地证明。这样，易经便被蒙上了一层神秘的色彩，吸引着无数的人来学习研究，也无可避免地染上了迷信的内容。
易经有如此的魅力，那么易经是如何产生的呢？因年代的久远，再加上远古的人们缺乏文字，今天的人们已经很难准确考证，但通过有限的资料，以及一些远古的传说，我们大致理清了易经产生的脉络。孔子所写的《易传》告诉我们，远古人们仰则观象于天，俯则观法于地，取鸟兽之纹与地之宜，近取诸身，远取诸物，作八卦以通神明之德、类万物之情。
从这儿我们可以看出，易经并非天外之物，它是人们效法天地而来，用1种简单易懂的符号来揭示自然的一些法则，从而指导人们更好地生活。因此，易经是非常健康的思想，其本源并不神秘，而是极其简单，所以称之为“易”。小雅甚至认为，八卦虽然是伏羲所作，但却并非他所创。这是由以往诸如有巢氏、燧人氏等长期观察所总结传承而来，伏羲将这些思想进行分析，用通俗易懂的八卦符号，使许多人们看明白了其中的意思，从而得以传播，因此后人便有此误传。
二、早期易经的发展
《左传》中记载，楚文王的左史倚相“能读《三坟》、《五典》、《八索》、《九丘》”。孔安国在《尚书·序》里说：“伏羲、神农、黄帝之书，谓之《三坟》，言大道也。少昊、颛顼、高辛、唐、虞之书，谓之《五典》，言常道也。”三皇五帝之书”即三坟、五典，八索就是八卦，九丘就是九畴，是《河图》、《洛书》的理数，由此可见，易经并非上天所赐，而是和万物一样逐渐发展而来。
伏羲用八卦符号来演示易的原理，使易文化得到了飞跃发展，到了神农时代，易的应用进1步得到了很大发展。当时人们不象现在一样交通发达，人们最大的麻烦是困于大山甚至猛兽，因此，代表大山的“艮”便成了首卦。到了黄帝时代，物质生活得到了极大的补充，人们有了相对温暖的家，也开始有了积蓄，所以有了“归藏”的思想雏形。以后各个朝代，都有相应的变更和补充，其中最有代表性的就是前面所说的《连山易》和《归藏易》，这本经典以及后来的周易被后人并称为“三易”，至今仍以这三易为主导。
由于古代没有印刷技术，春秋战国又是兵荒马乱，人们为生存而疲于奔命，再加上秦始皇焚书，诸多原因导致《连山易》和《归藏易》的正本已经失传，但其思想及应用仍然被广泛流传。秦前的易经大多本着法天象地的原则，广泛用于祭祀、决策等国家大事。因此当时的儒者比较精通易经，这是理所当然的事。我们所下的围棋，也是易经应用的工具之一。
由于上述原因，《周易》便成了秦朝以后大多数人学习研究易经的唯一宝典。周易是文王研究易经的应用体系，所谓“文王演易、周公祖述”，也就是说，周易是由周公记录整理并形成文字传承下来的。周易中的卦辞和爻辞便是文王和周公对“卦”和“爻”的解释。由于周易原文深奥难懂，孔子晚年作《十翼》系统地对周易作了解释和说明，有人说《十翼》的一部分也可能是孔子的学生所作。
孔子所作《十翼》对后世学习研究易经起到了无可比拟的作用，至今仍是解释易经的最高权威，其内容已经被加到了周易原文中去，一起成为经文的一部分。《十翼》便是：①上经的彖辞、②下经的彖辞、③上经的象辞、④下经的象辞、⑤《系辞上传》、⑥《系辞下传》、⑦《文言》、⑧《说卦传》、⑨《序卦传》、⑩《杂卦传》。因此，孔子被后世称为继伏羲、文王之后的“易更三圣”之一。
孔子将《易》列为六艺之一并以此教育学生，而孔子的学生中，专门传授易经的主要有两人即卜子夏和商瞿(qú)，他们的二人为易经的传承起到了很大作用，世上留传子夏水平没有商瞿高等传言概不可信。除了孔门弟子外，世上还有许多易经研究传播者，并非只有卜商两宗。
三、后期易经的演变
自汉朝以后，易经在“理”和“术”方面都得到了很大发展和完善，融合了阴阳理论、补充了五行生克、配备了天干地支、简化了占卜程序，使易经不尽用于人事、堪舆的预测，而且广泛用于政治、军事等各大领域。为了使人容易理解，在天文地理方面，配上了许多神化，这样便使易经蒙上了一层迷信的色彩。
首先值得一说的是西汉的焦赣(Gòng)和京房二位易学大师，都是商瞿一脉的传人，目前应用最广的“纳甲筮法”，也称为“六爻法”或“火珠琳”、“周易预测法”等，便是由焦赣将天干地支与周易相结合而发明的，著有《易林》一书。京房曾师从于杨何、焦赣等多位易学大师，博学广记多才多艺，对政治、音律、天文等多方学科都有所建树。他将老师的“纳甲筮法”加以完善补充，并发明了“八卦宫变”的方法来解释事情的本源及发展过程，让人在占卜时很容易找到世爻和应爻。
唐朝李虚中和北宋徐子平对后世影响甚大，李虚中用人的出生年月日来预测人事，无有不中，留有《李虚中命书》。徐子平在李虚中的三柱基础之上发展为年月日时四柱，一直延用至今，而四柱经典《渊海子平》则是由宋代徐大升根据李虚中、徐子平的理论整理而成。明朝万民英所著《三命通会》及清朝任铁樵所著《滴天髓》也都是根据李徐的理论整理出来的四柱方面的名著。
在易经的理学方面，当数北宋五子作出了杰出的贡献，这就是周敦颐结合《周易》解释《太极》，并著有《太极图说》一书；邵雍(五子之首)重新安排了《周易》的64卦，试图揭示宇宙规律，进而解释人类命运，并著有《皇极经世》、《伊川击壤集》、《观物内外篇》、《渔樵问对》等易学大作，自创“梅花易数”，是继孔子之后的又一易学杰出人物；张载开创了理学中“气学”一派，著有《崇文集》十卷（已佚），《正蒙》、《横渠易说》、《经学理窟》、《张子语录》等书；程颢与程颐（二程）创立了“天理”学说，以“致知、格物、穷理”而立说。
术数方面古已有之，但到了明清以后，一些不传之秘才得以出版发行，使许多人了解到三式（太乙、奇门、六壬）、星象（紫微斗数）、堪舆等方面内容，另外还有面相手相等方面内容，不过其中不负责任的言论太多，与易经的结合大多牵强附会，而当今的书简单可以说是泛滥，他们出书并非有所心得，而是为了1个“名”或“利”，实在是无可奈何。
研究的人多了，所出的书也多了，偏离易道的距离也越来越远了。许多原本和易经没有太大联系的学术或思想，也纷纷向易经靠拢，也不管是真理还是歪理，都到易经中来寻找根据。这样导致了后世对易经越来越陌生，越陌生也就越容易对易经产生误解，终于出现了“五四”、“文化革命”等事件，使得不仅是易经文化，而且是整个传统文化遭受了灭顶之灾。
四、文艺复兴的再思考
易经是华夏乃至世界最珍贵的文化遗产，是至德圣人所创并演绎教化众人，经无数出类拔萃的英杰不断完善、不断发展而成，是1种揭示万物产生和灭亡规律的理论体系，是1种可以用来辅助人们解决疑难问题的神奇工具。二千多年前，虽然没有焚烧周易，却也损失了很多术数之类的书籍，因为焚书的起因正是始皇受了一些术士的欺骗所致，二千多年以来，易经一直是读书人必修课程之一，可是到了近代，由于政府的腐败，同时受帝国主义的侵略和掠夺，国家濒临崩溃的边缘，国民生活水深火热，于是爆发了新文化运动和五四运动，一些国外留学回来的人，对国学本就一知半解，却错误地认为造成国家腐败落后的根本原因就是儒家文化根深蒂固，不能接受西方蓝色文明，于是采用革命的手段，砸烂一切旧思想，将符合自然规律的道理说成腐朽，将西方并不成熟的民主思想引入，这就导致了中国文化上的一场大地震，这场地震历数近百年，至今尚未拨乱反正过来。
这不能不引起人们深刻地思考，为什么西方的文艺复兴引起了西方的3种复兴，一是文艺复兴，二是宗教复兴，三是工业革命所带来的复兴。为什么西方能够如此成功，而中国却是失败，而且还是1个巨大的失败。基中的原因是什么呢？小雅认为，原因有三。
(一)打破了传统的伦理。
那些在国外读了几年书的“精英”认为，中国之所以落后，是因为封建君主社会的长期统治造成的，而这种腐朽落后的制度为什么能长期存在，这是因为儒家思想所导致，儒家提倡“父父子子、君君臣臣”，这使得愚昧的人民盲目忠于皇帝而不起来反抗压迫，所以五四运动最响亮的口号就是“打倒孔家店，反对封建统治”。这些“精英”所要反对的正是中华文化最宝贵、也是对人类进步最有价值的思想财富。
精英们年纪轻轻出去海外留学，其国学底子是很差的，完全可以说，他们根本就不了解国学，有许多所谓的大师是回国后，为了找出儒家思想的弊端才去学习研究儒家思想的。“父父子子、君君臣臣”是两方面的，一方面是要做爸爸的人担负起爸爸的责任，做国君的也要担负起国君的责任，然后才会有子女的孝和臣民的忠，这才是父慈子孝、明君忠臣之道，而这一儒家思想也同样符合易经的原理。统治阶级为了稳定国家，当然片面地宣传了“忠”的方面，这并不是儒家思想的过错，这就正如计算机同样会被孩子用来打游戏，家长不能因为这个理由而打倒计算机吧。所以五四运动是一场可笑的愚昧的运动，而直到如今，起来反对的人还很少。
正是因为大家没有认识到这一点，所以共和国成立以后，在文化大革命期间，又一次将国学称为“四旧”，发起了“砸烂一切，破除迷信”的运动。这一次遭殃的可不止是儒家，连同道家佛家及所有宗教都受到了毁灭性的打击。如今人们仍然没有认识到，几千年来，社会稳定正是宗教起到了无可替代的作用。西方如果没有宗教的复兴，就不可能有文艺的复兴。当今的中国人，为什么成了世界上毫无诚信之人，这是传统思想遭受灭顶之灾所带来的必然结果。
(二)没有建立新的伦理体系
文艺复兴之所以成功是因为它将原有有宗教伦理捡起来，有保留地加以发展，使其完善，所以才命之为“复兴”。而五四运动则是打破了封建封建伦理体系，却没有建立新的伦理体系。人们几千年来的思想体系一下子被打破，这必然导致1种迷茫、1种失落。因为对于人类来说，知识是汪洋大海，而人类的认识只是水滴，失去了信仰或伦理，也就失去了对事物的判断标准，人的思想返回到1种原始的愚昧和所谓先进科学思想的漩涡之中。
任何1种漩涡必须有正反2种力量的对冲才能形成，一方面是激进的西方思想，一方面是要深蒂固的传统文化，直到如今仍然在旋而未定之中，一直所谓的“院士”居然会说出“中医是伪科学”的言论，由此可以看出，我们国内的院士已经无知到什么程度了。而这样无知的话，偏偏还有无数的信众跟在后面摇旗呐喊，完全不顾几千年来中医为人类所作的贡献。
这事情本来并不可怕，完全可以当作1个外国人，对中国历史的无知，但这儿所引发出对“迷信”一词的再思考却不能忽视。有人一提到“迷信”就立刻想到求神拜佛之类的事，这当然是迷信的1种，小雅本人也并不赞成，但这并不是我所想说的“迷信”。我们有必要分析一下迷信的定义，也就是“迷而后信”，通俗地说就是：不知其对还是不对的情况下而想信。这样一来，对于那些自称“不迷信”，不信一切菩萨神仙的人来说，这也是1种迷信，因为这些人想信了神学的对立面。对于神的存在和不存在，科学技术是证明不了的。
(三)失去了人类的基本诚信
无论是西方宗教还是中国的宗教，都是在劝人为善，对人的行为有1种无形的约束，虽然是依靠了神的力量，但其作用却比任何一部法律还要有效。西方正是有这样的约束，才保持了人类的基本诚信，因为他们相信人如果不讲信用，上帝是知道的。中国的伦理道德也是同样的作用，有了这样的1种对神或宗教的信仰，上帝或神但真正地存在于人们的心中。
中国的道教、佛教既然属于宗教，也将自然发展的动力源泉归之于本无物质存在的神、佛，而儒家虽然也被部分人员称为宗教，其思想却是实实在在的“科学”体系，以道德为基础，以仁义为做人的根本，以礼仪为人们的行为规范，这并不是孔子坐而论道的空想，而是效法天地的原则，经过历代圣贤的实践出来的一套方法论。
如今人们认为治国必须依靠法律，这是很低级的想法，法律的作用很有限，而现在的人们受西方影响夸大了作用。这个道理很简单，就如同交通一样，交通规则只能是事后的1种补救处理，要解决交通还必须通过道路的规划建设、安全的思想意识等方面抓起，这才是解决的根本之道。管仲说过：“国之四维，礼仪廉耻，一维绝则倾，二维绝则危，三维绝则覆，四维绝则灭。”治国决不是只靠法律就行，这也是大禹治水时总结的经验，即不能只用“堵”，而要用“疏”的办法对能从根本上来解决。
司马迁说得好，“人道经纬万端，规矩无所不贯，诱进以仁义，束缚以刑罚，故德厚者位尊，禄重者宠荣，所以总一海内而整齐万民也。”翻译成白话就是：人类社会的万千世界，规矩则无所不在、无时不在，事前就要从事仁义道德的教育，事后要用刑罚实施得失的奖励和制裁。所以德高望重者因其能服人所以要授予较高的权位，能力强的因其做事成绩而给予高薪厚禄，这是统一海内而使万民信服的总则。
五、学习易经的态度
大多数人学习易经都是因为奔着神奇的算［www.61k.com）命功能而来，这就如同学佛之人追求法力无边、学道之人追求长生不老腾云驾雾之法术一样，其结果必然是水中失之水捞月竹篮打水，不仅浪费学习者宝贵时间，也必将得到一些毫无益处的文化垃圾。所以端正学习态度是本教材的首要任务。
易经是中国文化思想的源泉，这其中有许多内容至今人们尚未正确理解，所以，学习易经是为了保存中国文化宝库不至于流失，同时从易经中学习其中“道理”即“道”的原理。即使学习一些算命的方法，也要以研究为其原理为目的，不可一知半解地出去骗财骗钱。总而言之，心正者可学易，不正者则不可学，学则有害而无益。
学习易经必须1步1个脚印地打好基础，这是学习易经的人方法上的1个重要盲点。许多人学习易经为什么半途而废，究其原因，很大程度是由于没有掌握这样的方法，将五行八卦一看就以为懂了，而不去背一些基础知识，一味地往后加速前进，其结果必然是因其不明白之处过多而疲惫不堪，最终得出一结论：易经太难了！
小雅认为，1个正常的学习者，只要愿意按照我们的教材步骤，1步1个脚印地去学、去背，结果一定能事半功倍。开始时背诵一些基础知识，并牢固地掌握，不仅对学习易经有好处，而且对自己以后一生都有好处。不肯花时间背，实际上是犯了1个常见的错误，这个错误就是“看懂了就以为是自己掌握了”。其实不然，这正如我们看电影，电影内容没有什么不明白的地方，但如果让你讲述出来却不行，充其量只能讲一些大概的情节，更不用说让你去演这个电影中的角色。
我们学习易经，就是要达到自己会演这部“电影”，所以一开始就需要花时间去背一些基本概念，当然，并不是死记硬背。易经知识是很有规律的，也很好记，只要我们注意方法，多联系实际，并且将难懂的文字简单化，这样学习既轻松又快速。我们相应地也开发了一些辅助程序，帮助大家学习。总之，易经的学习并没有大家想象得那样难学。
更多易经内容，请参考劝学网：http://www.quanxue.cn
三 : 外汇交易入门教程,个人学习专用
网站设计/推广、网店设计/推广、封面/名片设计、Logo/Banner设计、软文/论文写作、商标/人名设计、短信/邮件发送、论坛/软件注册、广告语设计??? 你会做这些？你要找人做这些？还不来看看？ 闲暇时间，别再浪费时间，开始赚零花钱啦！
按下ctrl键并把鼠标移动到手势文字上面，出现手形鼠标后单击打开对应网站。
个人外汇交易技巧入门教程
第一课
什么是外汇交易？
外汇交易就是一国货币与另一国货币进行兑换。外汇是世界上最大交易，每天成交额逾15000亿美元。与其它金融市场不同，外汇市场没有具体地点，也没有中央交易所，而是通过银行、企业和个人间的电子网络进行交易。由于缺少具体的交易所，因此外汇市场能够 24 小时运作。在交易过程中的讨价及还价，则经由各大信息公司传递出来，各投资者实时得知外汇交易的行情。
什么是外汇保证金？
在各样投资项目中，最公平而最吸引的人的可算是外汇保证金交易。外汇保证金交易就是投资者以银行或经纪商提供之信托进行外汇交易。银行或经纪商一般可以提供90%以上之信托，换言之投资者只要持有10%左右的资金(保证金)就可进行外汇交易。例fxsol保证金的最低要求是1%，投资者可以以最低100美元的保证金来进行最高10000美元的外汇交易，可谓小财大用！
如何获利？
货币的价值因应外汇交易的气氛而不停高低波动，如日圆一天的波动大概是0.7%至1.5%。投资者不但可以在低价买入，高价卖出中获利；也可以从高价先卖出(空投/沽空)，在低价买入而获利；因为外汇保证金交易有预购和预售特色，容许相向投资。而且外汇保证金交易
并没有指定的结算日期，交易一瞬间即可完成，全日24小时可以进出市场，也可以随时改变投资方向策略，是最灵活可靠的投资。
外汇保证金的具体情况
汇率显示在国际市场，汇率是以位五数字来显示的，如：
欧元EUR 0.9003
日圆JPY 111.80
澳元AUD 0.5280
汇率的最小变化为最后的一个数字(一点)即：
欧元0.0001
日圆JPY 0.01
澳元AUD 0.0001
货币的汇率的高低，不一定相等于货币价值高低。以汇率分类，货币分：
直接货币─欧元EUR、英磅GPD、澳元AUD、纽西兰元NZD?
间接货币─日元JPY111.80、瑞士法郎CHF、加拿大元CAD?
直接货币汇率是1直接货币兑换多少美元；如澳元AUD 0.5280，即一澳元兑0.5280美元。欧元EUR 0.9003，即一欧元兑 0.9003美元。
间接货币则1美元兑换多少间接货币；如日元JPY111.80，即1美元兑111.80日元。瑞士法郎CHF1.6006，即1美元兑1.6006瑞士法郎。
报价
外汇保证金以采购价(Dealing Rate)来进行交易，由银行或经纪商自行同时定出买入和卖出的价位，客户自行决定买卖方向。以fxsol欧元兑美元为例，买入和卖出的价位(差价)相差3点。对于投资者来说差价越小，成本越小，获利的机会也较大。
合约单位
外汇保证金交易的合约单位，跟股票交易相若都是以某数目作为一个单位(手/口)来进行交易。在fxsol一般以十万元为一手，来进行交易和计算盈亏。
计算盈亏
计算盈亏就是要计算买入和卖出的点差的价值，如买入欧元是0.8946卖出时0.8956，点差就是10点。要计算每一点的价值，可以先分别直接货币和间接货币。直接货币的特性在于汇率怎样高低波动，都不会影响每一点的价值。如一手十万元的EUR欧元，汇率怎样波动每一点的价值都是10美元。程序如下：
〈最少的变化单位／汇率〉＊合约单位＊手数＝每一点的价值〈0.0001／0.8942〉＊100,000＊1＝11.183 EUR
我们把11.183 EUR＊汇率〈0.8942〉就知道每一点的价值等于10美元。如果欧元汇率涨至0.9000每一点的价值又怎样呢？
〈0.0001／0.9000〉＊100,000＊1＝11.11EUR
我们把11.183EUR＊汇率〈0.9000〉就知道也是等于10美元。总言之，只是十万元一手，所有直接货币，每一点的价值都是10美元。
间接货币每一点的价值，会因应汇率波动而变化。计算程序跟直接货币相约，不同的在于合约单位是以美元为基础的。以日圆JPY130.46为例计算程序如下：
〈最少的变化单位／汇率〉＊合约单位＊手数＝每一点的美元价值〈0.01／130.46〉＊100,000＊1＝7.7美元
如果日圆的汇率涨至132.60，每一点的价格又会不会是7.7美元呢?
〈0.01／132.60〉＊100,000＊1＝7.54美元
答案是不会的，日圆和所有间接货币每一点的价格会因应汇率波动而变化。
补充一下，有些银行或经纪商，计算间接货币的合约单位不一定以美元为单位的。例如日圆可能以12,500,000日圆为一手。
fxsol的交易系统中，客户持有每手货币的盈亏状况是随市场变动而实时显示出来，客户无须自行计算盈亏，详情可以参与模拟账户得知。
符号
在外汇行情中，每种货币都有代表自己符号：
货币 美元 日圆 英镑 欧元 瑞士法郎 加元 澳元 新西兰元
符号 USD JPY GBP EUR CHF CAD AUD NZD
当我们明白符号后，基本上对外汇保证金交易的概念已经可以掌握。而现时外汇保证金交易的操作一般有两种，电话交易和网上交易。fxsol就具备了以上两种操作，要了解外汇保证金交易的操作，最好的方法就是参与模拟账户。
总结外汇保证金的优点
1．投资成本低，少于实际投资10%！
2．双向交易投资，涨跌都有获利机会！
3．获利高，一天有一倍以上获利的可能！
4．风险可控性，可预设限价和停止损点！
5．资金灵活，随时可抽取资金！
6．全球24小时交易，选取获利的机会多！
7．低廉手续费，低于千分之一！
8．全球每日交易量超过一兆美元，不易受人为操纵！
9．透明度高，所有行情、数据和新闻都是公开！
10．交易快，在绝大多数情况下外汇是实时成交！
第二课 外汇与外汇市场
1、外汇
外汇，就是外国货币或以外国货币表示的能用于国际结算的支付手段。我国1996年颁布的《外汇管理条例》第三条对外汇的具体内容作出如下规定：外汇是指：①外国货币。包
括纸币、铸币。②外币支付凭证。包括票据、银行的付款凭证、邮政储蓄凭证等。③外币有价证券。包括政府债券、公司债券、股票等。④特别提款权、欧洲货币单位。⑤其他外币计值的资产。
2、汇率及标价方式
汇率，又称汇价，指一国货币以另一国货币表示的价格，或者说是两国货币间的比价。 在外汇市场上，汇率是以五位数字来显示的，如：
欧元EUR 0.9705
日元JPY 119.95
英镑GBP 1.5237
瑞郎CHF 1.5003
汇率的最小变化单位为一点，即最后一位数的一个数字变化，如：
欧元EUR 0.0001
日元JPY 0.01
英镑GBP 0.0001
瑞郎CHF 0.0001
按国际惯例，通常用三个英文字母来表示货币的名称，以上中文名称后的英文即为该货币的英文代码。
汇率的标价方式分为两种：直接标价法和间接标价法。
(1)直接标价法
直接标价法，又叫应付标价法，是以一定单位(1、100、1000、10000)的外国货币为标准来计算应付出多少单位本国货币。就相当于计算购买一定单位外币所应付多少本币，所以叫应付标价法。包括中国在内的世界上绝大多数国家目前都采用直接标价法。在国际外汇市场上，日元、瑞士法郎、加元等均为直接标价法，如日元119.05即一美元兑119.05日元。
在直接标价法下，若一定单位的外币折合的本币数额多于前期，则说明外币币值上升或本币币值下跌，叫做外汇汇率上升；反之，如果要用比原来较少的本币即能兑换到同一数额的外币，这说明外币币值下跌或本币币值上升，叫做外汇汇率下跌，即外币的价值与汇率的涨跌成正比。
(2)间接标价法
间接标价法又称应收标价法。它是以一定单位(如1个单位)的本国货币为标准，来计算应收若干单位的外国货币。在国际外汇市场上，欧元、英镑、澳元等均为间接标价法。如欧元0.9705即一欧元兑0.9705美元。
在间接标价法中，本国货币的数额保持不变，外国货币的数额随着本国货币币值的对比变化而变动。如果一定数额的本币能兑换的外币数额比前期少，这表比前期明外币币值上升，本币币值下降，即外汇汇率上升；反之，如果一定数额的本币能兑换的外币数额多，则说明外币币值下降、本币币值上升，即外汇汇率下跌，即外币的价值和汇率的升跌成反比。
外汇市场上的报价一般为双向报价，即由报价方同时报出自己的买入价和卖出价，由客户自行决定买卖方向。买入价和卖出价的价差越小，对于投资者来说意味着成本越小。银行间交易的报价点差正常为2-3点，银行(或交易商)向客户的报价点差依各家情况差别较大， 目前国外保证金交易的报价点差基本在3-5点，香港在6-8点，国内银行实盘交易在10-40点不等。
3、外汇市场
目前世界上的金融商品市场有许多种，但概括起来可分为：股票市场、利息市场(包括债券、商业票据等)、黄金市场(包括黄金、白金、银)、期货市场(包括粮食、棉、油等)、期权市场和外汇市场等。
外汇市场，是指从事外汇买卖的交易场所，或者说是各种不同货币相互之间进行交换的场所。外汇市场之所以存在，是因为：
ü 贸易和投资
进出口商在进口商品时支付一种货币，而在出口商品时收取另一种货币。这意味着，它们在结清账目时，收付不同的货币。因此，他们需要将自己收到的部分货币兑换成可以用于购买商品的货币。与此相类似，一家买进外国资产的公司必须用当事国的货币支付，因此，它需要将本国货币兑换成当事国的货币。
ü 投机
两种货币之间的汇率会随着这两种货币之间的供需的变化而变化。交易员在一个汇率上买进一种货币，而在另一个更有利的汇率上抛出该货币，他就可以盈利。投机大约占了外汇市场交易的绝大部分。
ü 对冲
由于两种相关货币之间汇率的波动，那些拥有国外资产(如工厂)的公司将这些资产折算成本国货币时，就可能遭受一些风险。当以外币计值的国外资产在一段时间内价值不变时，如果汇率发生变化，以国内货币折算这项资产的价值时，就会产生损益。公司可以通过对冲消除这种潜在的损益。这就是执行一项外汇交易，其交易结果刚好抵消由汇率变动而产生的外币资产的损益。
外汇市场作为一个国际性的资本投机市场的历史要比股票、黄金、期货、利息市场短得多，然而，它却以惊人的速度迅速发展。今天，外汇市场每天的交易额已达1.5万亿美元，其规模已远远超过股票、期货等其他金融商品市场，已成为当今全球最大的单一金融市场和投机市场。
自从外汇市场诞生以来，外汇市场的汇率波幅越来越大。1985年9月，1美元兑换220日元，而1986年5月，1美元只能兑换160日元，在8个月里，日元升值了27%。近几年，外汇市场的波幅就更大了，1992年9月8日，1英镑兑换2.0100美元，11月10日，1英镑兑换1.5080美元，在短短的两个月里，英镑兑美元的汇价就下跌了5000多点，贬值25%。不仅如此，目前，外汇市场上每天的汇率波幅也不断加大，一日涨跌2%至3%已是司空见惯。1992年9月16日，英镑兑美元从1.8755下跌至1.7850，英镑一日下挫5%。
第三课 外汇市场的特点
近年来，外汇市场之所以能为越来越多的人所青睐，成为国际上投资者的新宠儿，这与外汇市场本身的特点密切相关。外汇市场的主要特点是：
1、有市无场
西方工业国家的金融业基本上有两套系统，即集中买卖的中央操作和没有统一固定场所的行商网络。股票买卖是通过交易所买卖的。像纽约证券交易所、伦敦证券交易所、东京证券交易所，分别是美国、英国、日本股票主要交易的场所，集中买卖的金融商品，其报价、交易时间和交收程序都有统一的规定，并成立了同业协会，制定了同业守则。投资者则通过经纪公司买卖所需的商品，这就是“有市有场”。而外汇买卖则是通过没有统一操作市场的
行商网络进行的，它不像股票交易有集中统一的地点。但是，外汇交易的网络却是全球性的，并且形成了没有组织的组织，市场是由大家认同的方式和先进的信息系统所联系，交易商也不具有任何组织的会员资格，但必须获得同行业的信任和认可。这种没有统一场地的外汇交易市场被称之为“有市无场”。全球外汇市场每天平均上万亿美元的交易。如此庞大的巨额资金，就是在这种既无集中的场所又无中央清算系统的管制，以及没有政府的监督下完成清算和转移。
2、循环作业
由于全球各金融中心的地理位置不同，亚洲市场、欧洲市场、美洲市场因时间差的关系，连成了一个全天24小时连续作业的全球外汇市场。早上8时半(以纽约时间为准)纽约市场开市，9时半芝加哥市场开市，10时半旧金山开市，18时半悉尼开市，19时半东京开市，20时半香港、新加坡开市，凌晨2时半法兰克福开市，3时半伦敦市场开市。如此24小时不间断运行，外汇市场成为一个不分昼夜的市场，只有星期六、星期日以及各国的重大节日，外汇市场才会关闭。这种连续作业，为投资者提供了没有时间和空间障碍的理想投资场所，投资者可以寻找最佳时机进行交易。比如，投资者若在上午纽约市场上买进日元，晚间香港市场开市后日元上扬，投资者在香港市场卖出，不管投资者本人在哪里，他都可以参与任何市场，任何时间的买卖。因此，外汇市场可以说是一个没有时间和空间障碍的市场。
3、零和游戏
在股票市场上，某种股票或者整个股市上升或者下降，那么，某种股票的价值或者整个股票市场的股票价值也会上升或下降，例如日本新日铁的股票价格从800日元下跌到400日元，这样新日铁全部股票的价值也随之减少了一半。然而，在外汇市场上，汇价的波动所表示的价值量的变化和股票价值量的变化完全不一样，这是由于汇率是指两国货币的交换比率，汇率的变化也就是一种货币价值的减少与另一种货币价值的增加。比如在22年前，1美元兑换360日元，目前，1美元兑换120暂元，这说明日元币值上升，而美元币值下降，从总的价值量来说，变来变去，不会增加价值，也不会减少价值。因此，有人形容外汇交易是“零和游戏”，更确切地说是财富的转移。近年来，投入外汇市场的资金越来越多，汇价波幅日益扩大，促使财富转移的规模也愈来愈大，速度也愈来愈快，以全球外汇每天1.5万亿美元的交易额来计算，上升或下跌1%，就是1500亿的资金要换新的主人。尽管外汇汇价变化很大，但是，任何一种货币都不会变为废纸，即使某种货币不断下跌，然而，它总会代表一定的价值，除非宣布废除该种货币。
第四课 外汇交易简介
外汇是伴随着国际贸易而产生的，外汇交易是国际间结算债权债务关系的工具。但是，近十几年，外汇交易不仅在数量上成倍增长，而且在实质上也发生了重大的变化。外汇交易不仅是国际贸易的一种工具，而且已经成为国际上最重要的金融商品。外汇交易的种类也随着外汇交易的性质变化而日趋多样化。
外汇交易主要可分为现钞、现货、合约现货、期货、期权、远期交易等。具体来说，现钞交易是旅游者以及由于其他各种目的需要外汇现钞者之间进行的买卖，包括现金、外汇旅行支票等；现货交易是大银行之间，以及大银行代理大客户的交易，买卖约定成交后，最迟在两个营业日之内完成资金收付交割；合约现货交易是投资人与金融公司签定合同来买卖外汇的方式，适合于大众的投资；期货交易是按约定的时间，并按已确定汇率进行交易，每个 合同的金额是固定的；期权交易是将来是否购买或者出售某种货币的选择权而预先进行的交易；远期交易是根据合同规定在约定日期办理交割，合同可大可小，交割期也较灵活。 从外汇交易的数量来看，由国际贸易而产生的外汇交易占整个外汇交易的比重不断减少，据统计，目前这一比重只有1%左右。那么，可以说现在外汇交易的主流是投资性的，
是以在外汇汇价波动中赢利为目的的。因此，现货、合约现货以及期货交易在外汇交易中所占的比重较大。
1、现货外汇交易(实盘交易)
现货交易是大银行之间，以及大银行代理大客户的交易，买卖约定成交后，最迟在两个营业日之内完成资金收付交割。
本文主要介绍国内银行面向个人推出的、适于大众投资者参与的个人外汇交易。
个人外汇交易，又称外汇宝，是指个人委托银行，参照国际外汇市场实时汇率，把一种外币买卖成另一种外币的交易行为。由于投资者必须持有足额的要卖出外币，才能进行交易，较国际上流行的外汇保证金交易缺少保证金交易的卖空机制和融资杠杆机制，因此也被成为实盘交易。
自从1993年12月上海工商银行开始代理个人外汇买卖业务以来，随着我国居民个人外汇存款的大幅增长，新交易方式的引进和投资环境的变化，个人外汇买卖业务迅速发展，目前已成为我国除股票以外最大的投资市场。
截止目前，工、农、中、建、交、招等六家银行都开展了个人外汇买卖业务，光大银行和浦发银行也正在积极筹备中。预计银行关于个人外汇买卖业务的竞争会更加激烈，服务也会更加完善，外汇投资者将享受到更优质的服务。
国内的投资者，凭手中的外汇，到上述任何一家银行办理开户手续，存入资金，即可透过互联网、电话或柜台方式进行外汇买卖。要了解更详细的情况，请参考本网站实盘交易栏目。
2、合约现货外汇交易(按金交易)
合约现货外汇交易，又称外汇保证金交易、按金交易、虚盘交易，指投资者和专业从事外汇买卖的金融公司(银行、交易商或经纪商)，签定委托买卖外汇的合同，缴付一定比率(一般不超过10%)的交易保证金，便可按一定融资倍数买卖10万、几十万甚至上百万美元的外汇。因此，这种合约形式的买卖只是对某种外汇的某个价格作出书面或口头的承诺，然后等待价格出现上升或下跌时，再作买卖的结算，从变化的价差中获取利润，当然也承担了 亏损的风险。由于这种投资所需的资金可多可少，所以，近年来吸引了许多投资者的参与。
外汇投资以合约形式出现，主要的优点在于节省投资金额。以合约形式买卖外汇，投资额一般不高于合约金额的5%，而得到的利润或付出的亏损却是按整个合约的金额计算的。外汇合约的金额是根据外币的种类来确定的，具体来说，每一个合约的金额分别是
12,500,000日元、62,500英镑、125,000欧元、125,000瑞士法郎，每张合约的价值约为10万美元。每种货币的每个合约的金额是不能根据投资者的要求改变的。投资者可以根据自己定金或保证金的多少，买卖几个或几十个合约。一般情况下，投资者利用1千美元的保证金就可以买卖一个合约，当外币上升或下降，投资者的盈利与亏损是按合约的金额即10万美元来计算的。有人认为以合约形式买卖外汇比实买实卖的风险要大，但我们仔细地把两者加以比较就不难看出差别所在，请详见下表。
假设：在1美元兑换135.00日元时买日元
实买实卖 保证金形式
购入12,500,00日元需要 US,592.59 US,000.00
若日元汇率上升100点
盈利 US0.00 US0.00
盈利率 680/92,592.59=7.34%0 680/1000=68%
若日元汇率下跌100点
亏损 US0.00 US0.00
亏损率 680/92,592.59=7.34%0 680/1000=68%
从上表中可以发现，实买实卖的与保证金形式的买卖在盈利和亏损的金额上是完全相同的，所不同的是投资者投入的资金在数量上的差距，实买实卖的要投入9万多美元，才能买卖12,500,000日元，而采用保证金的形式只需1千美元，两者投入的金额相差90多倍。因此，采取合约形式对投资者来说投入小、产出多，比较适合大众的投资，可以用较小的资金赢得较多的利润。
但是，采取保证金形式买卖外汇特别要注意的问题是，由于保证金的金额虽小，但实际撬动的资金却十分庞大，而外汇汇价每日的波幅又很大，如果投资者在判断外汇走势方面失误，就很容易造成保证金的全军覆没。以上表为例，同样是100点的亏损幅度，投资者的1千美元就亏掉了680美元，如果日元继续贬值，投资者又没有及时采取措施，就要造成不仅保证金全部赔掉，而且还可能要追加投资。因此，高收益和高风险是对等的，但如果投资者方法得当，风险是可以管理和控制的。
在合约现货外汇交易中，投资者还可能获得可观的利息收入。合约现货外汇的计息方法，不是以投资者实际的投资金额，而是以合约的金额计算。例如，投资者投入1万美元作保证金，共买了5个合约的英镑，那么，利息的计算不是按投资人投入的1万美元计算，而是按5个合约的英镑的总值计算，即英镑的合约价值乘合约数量(62,500英镑*5)，这样一来，利息的收入就很可观了。当然，如果汇价不升反跌，那么，投资者虽然拿了利息，怎么也抵不了亏掉的价格变化的损失。
财息兼收也不意味着买卖任何一种外币都有利息可收，只有买高息外币才有利息的收入，卖高息外币不仅没有利息收入，投资者还必须支付利息。由于各国的利息会经常调整，因此，不同时期不同货币的利息的支付或收取是不一样的，投资者要以从事外币交易的交易商公布的利息收取标准为依据。
利息的计算公式有两种，一种是用于直接标价的外币，像日元、瑞士法郎等，另一种用于间接标价的外币，如欧元、英镑、澳元等。
日元、瑞士法郎的利息计算公式为：
合约金额*1/入市价*利率*天数/360*合约数
欧元、英镑的利息计算公式为：
合约金额*入市价*利率*天数/360*合约数
合约现货外汇买卖的方法，既可以在低价先买，待价格升高后再卖出，也可以在高价位先卖，等价格跌落后再买入。外汇的价格总是在波浪中攀升或下跌的。这种既可先买又可先卖的方法，不仅在上升的行情中获利，也可以在下跌的形势下赚钱。投资者若能灵活运用这一方法，无论升市还是跌市都可以左右逢源。那么，投资者如何来计算合约现货外汇买卖的盈亏呢？主要有3个因素要考虑。
首先，要考虑外汇汇率的变化。投资者从汇率的波动赚钱可以说是合约现货外汇投资获取利润的主要途径。盈利或亏损的多少是按点数来计算的，所谓点数实际上就是汇率，比如说1美元兑换130.25日元，130.25日元可以说成13025点，当日元跌到131.25时，即下跌100点，日元在这个价位上，每一点代表了6.8美元。日元、英镑、瑞士法郎等每种货币的每一点所代表的价值也不一样。在合约现货外汇买卖中，赚的点数越多盈利也就越多，赔的点数越少亏损也就越少。例如，投资者在1.6000价位时买入1个合约的英镑，当英镑上升到1.7000时，投资者把这个合约卖掉，即赚1000点的英镑，盈利高达6,250美元。而另一个投资者在1.7000时买英镑，英镑下滑至1.6900时，他马上抛掉手中的合约，那么，他只赔了100点，即赔掉625美元。当然，赚和赔的点数与盈利和亏损的多少是成正比的。 其次，要考虑利息的支出与收益。本文曾叙述过先买高息外币会得到一定的利息，但先卖高息外币就要支付一定的利息。如果是短线的投资，例如当天买卖结束，或者在一二天内
结束，就不必考虑利息的支出与收益，因为一二天的利息支出与收益很少，对盈利或者亏损影响很小。对中、长线投资者来说，利息问题却是一个不可忽视的生要环节。例如，投资者在1.7000价位时先卖英镑，一个月以后，英镑的价格还在这一位置，如果按卖英镑要支付8%的利息计算，每月的利息支付高达750美元。这也是一个不少的支出。从目前一般居民投资的情况来看，有很多投资者对利息的收入看得比较多，而同时忽视了外币的走势，从而都喜欢买高息外币，结果造成了以少失多，例如，当英镑下跌时，投资者买了英镑，即使一个合约每月收息450美元，但一个月英镑下跌了500点，在点数上赔掉3,125美元，利息的收入弥补不了英镑下跌带来的损失。所以，投资者要把外汇汇率的走势放在第一位，而把利息的收入或支出放在第二位。
最后，要考虑手续费的支出。投资者买卖合约外汇要通过金融公司进行，因此，投资者要把这一部分支出计算到成本中去。金融公司收取的手续费是按投资者买卖合约的数量，而不是按盈利或亏损的多少，因此，这是一个固定的量。
以上的三个方面，构成了计算合约现货外汇盈利及亏损的计算方法。
日元、瑞士法郎的损益计算公式为：
合约金额*(1/卖出价-1/买入价)*合约数-手续费+/-利息
而欧元、英镑的损益计算公式为：
合约金额*(卖出价-买入价)*合约数-手续费+/-利息
外汇保证金交易，作为一种投资工具，在欧美、日本、香港、台湾等国家和地区是合法的，交易商和交易行为受到政府的监管。
3．期货外汇交易
期货外汇交易是指在约定的日期，按照已经确定的汇率，用美元买卖一定数量的另一种货币。期货外汇买卖与合约现货买卖有共同点亦有不同点。合约现货外汇的买卖是通过银行或外汇交易公司来进行的，期货外汇的买卖是在专门的期货市场进行的。目前，全世界的期货市场主要有：芝加哥期货市场、纽约商品交易所、悉尼期货市场、新加坡期货市场、伦敦期货市场。期货市场至少要包括两个部分：一是交易市场，另一个是清算中心。期货的买方或卖方在交易所成交后，清算中心就成为其交易对方，直至期货合同实际交割为止。期货外汇和合约外汇交易既有一定的联系，也有一定的区别，以下从两者对比的角度，介绍一下期货外汇的具体运作方式。
期货外汇的交易数量和合约现货外汇交易是完全一样的。期货外汇买卖最少是一个合同，每一个合同的金额，不同的货币有不同的规定，如一个英镑的合同也为62,500英镑、日元为12,500,00日元，欧元为125,000欧元。
期货外汇合同的交割日期有严格的规定，这一点合约现货外汇的交易是没有的。期货合同的交割日期规定为一年中的3月份、6月份、9月份、12月份的第3个星期的星期三。这一样，一年之中只有4个合同交割日，但其他时间可以进行买卖，不能交割，如果交割日银行不营业则顺延一天。
期货外汇合同的价格全是用一个外币等于多少美元来表示的，因此，除英镑之外，期货外汇价格和合约外汇汇价正好互为倒数，例如，12月份瑞郎期货价格为0.6200，倒数正好为1.6126。
期货外汇的买卖并没有利息的支出与收入的问题，无论买还是卖任何一种外币，投资者都得不到利息，当然也不必支付利息。
期货外汇的买卖方法和合约现货外汇完全一样，既可以先买后卖，也可以先卖后买，即可双向选择。
4．在线外汇交易的发展
1997年以来，随着互联网的发展，在线外汇保证金交易已经风靡世界，成为外汇交易的流行方式，不仅银行间交易已开始采用在线方式，个人也越来越多的通过互联网参与外汇交易市场。
在线外汇交易的发展，打破了地域的局限，使得原来必须依赖本地经纪商才能参与外汇交易的个人和小型机构投资者，可以更加方便的进行外汇投资。
2000年12月，美国通过了《期货现代化法案》，这一法案要求所有外汇交易商必须在美国期货协会(NFA)和美国商品期货交易委员会(CFTC)注册为期货佣金商(FCM)，并接受上述机构的日常监管，在期限内不符合资格或没有被核准的外汇业者将被勒令停止营业。这一法案的出台，使得在线外汇保证金交易走上了规范发展的轨道。
目前，已经通过美国CFTC(商品期货交易委员会)注册的外汇交易商有(按通过时间先后) FXCM、MGFG、GAINCAPITAL、fxsol CMS—FOREX等。
5．中国大陆外汇交易市场的历史与现状
在1992年—1993年期货市场盲目发展的过程中，多家香港外汇经纪商未经批准即到大陆开展外汇期货交易业务，并吸引了大量国内企业、个人的参与。
由于国内绝大多数参与者并不了解外汇市场和外汇交易，盲目的参与导致了大面积和大量的亏损，其中包括大量国有企业。
1994年8月，中国证监会等四部委联合发文，全面取缔外汇期货交易(保证金)。此后，管理部门对境内外汇保证金交易一直持否定和严厉打击态度。
1993年底，中国人民银行开始允许国内银行开展面向个人的实盘外汇买卖业务。至1999年，随着股票市场的规范，买卖股票的盈利空间大幅缩小，部分投资者开始进入外汇市场，国内外汇实盘买卖逐渐成为一种新兴的投资方式，进入快速发展阶段。据中央电视台报道，外汇买卖已经成为除股票之外最大的投资市场。
与国内股票市场相比，外汇市场要规范和成熟得多，外汇市场每天的交易量大约是国内股票市场交易量的1000倍，所以尽管在交易规则上不完全符合国际惯例，国内银行开办的个人实盘外汇买卖业务还是吸引了越来越多的参与者。
总体来看，国内绝大多数的外汇投资者参与的是国内银行的实盘交易，而保证金交易，由于国内尚未开放，以及国家的外汇管制政策，国内投资者尚需待以时日。
第五课 汇率的分析方法
1、基础分析
购买力平价 (PPP) | 利率平价 (IRP) | 国际收支模式 | 资产市场模式
货币市场的两种主要分析方法为基础分析和技术分析。基础分析注重金融、经济理论和政局发展，从而判断供给和需求要素。技术分析观察价格和交易量数据，从而判断这些数据在未来的走势。技术分析还可进一步分为两个主要类型：量化分析：使用各种类型的数据属性来帮助估计买超 / 卖超货币的限度；图表分析：使用线条和图形来辨别货币汇率构成中的显著趋势和模式。 基础分析与技术分析最明显的一点区别就是：基础分析研究市场运动的原因，而技术分析研究市场运动的效果。
当以另一国货币估价一国货币时，基础分析包括对宏观经济指标、资产市场以及政治因素的研究。宏观经济指标包括经济增长率等数字，由国内生产总值、利息率、通货膨胀率、失业率、货币供应量、外汇储备以及生产率等要素计算而得。资产市场包括股票、债券及房地产。政治因素会影响对一国政府的信任度、社会稳定气候和信心度。
有时，政府会干预货币市场，以防止货币显著偏离不理想的水平。货币市场的干预由中央银行执行，通常对外汇市场产生显著却又暂时的影响。中央银行可以采取以另一国货币单
方面购入 / 卖出本国货币，或者联合其它中央银行进行共同干预，以期取得更为显著的效果。或者，有些国家能够设法仅仅通过发出干预暗示或威胁来达到影响币值变化的目的。 基础分析的基本理论
购买力平价 (PPP)
购买力平价理论规定，汇率由同一组商品的相对价格决定。通货膨胀率的变动应会被等量但相反方向的汇率变动所抵销。举一个汉堡包的经典案例，如果汉堡包在美国值 2.00 美元一个，而在英国值 1.00 英磅一个，那么根据购买力平价理论，汇率一定是 2 美元每 1 英磅。如果盛行市场汇率是 1.7 美元每英磅，那么英磅就被称为低估通货， 而美元则被称为高估通货。此理论假设这两种货币将最终向 2:1 的关系变化。
购买力平价理论的主要不足在于其假设商品能被自由交易，并且不计关税、配额和赋税等交易成本。另一个不足是它只适用于商品，却忽视了服务，而服务恰恰可以有非常显著的价值差距的空间。另外，除了通货膨胀率和利息率差异之外，还有其它若干个因素影响着汇率，比如:经济数字发布/报告、资产市场以及政局发展。在 20 世纪 90 年代之前，购买力平价理论缺少事实依据来证明其有效性。90 年代之后， 此理论似乎只适用于长周期(3－5 年)。在如此跨度的周期中，价格最终向平价靠拢。
利率平价 (IRP)
利率平价规定，一种货币对另一种货币的升值(贬值)必将被利率差异的变动所抵销。如果美国利率高于日本利率，那么美元将对日元贬值，贬值幅度据防止无风险套汇而定。未来汇率会在当日规定的远期汇率中被反映。在我们的例子中，美元的远期汇率被看作贴水，因为以远期汇率购得的日元少于以即期汇率购得的日元。日元则被视为升水。
20 世纪90年代之后，无证据表明利率平价说仍然有效。与此理论截然相反，具有高利率的货币通常不但没有贬值，反而因对通货膨胀的远期抑制和身为高效益货币而增值。 国际收支模式
此模式认为外汇汇率必须处于其平衡水平－－即能产生稳定经常帐户余额的汇率。出现贸易赤字的国家，其外汇储备将会减少，并最终使其本国货币币值降低(贬值)。便宜的货币使该国的商品在国际市场上更具价格优势，同时也使进口产品变得更加昂贵。在一段调整期后，进口量被迫下降，出口量上升，从而使贸易余额和货币向平衡状态稳定。
与购买力平价理论一样，国际收支模式主要侧重于贸易商品和服务，而忽视了全球资本流动日趋重要的作用。换而言之，金钱不仅追逐商品和服务，而且从更广义而言，追逐股票和债券等金融资产。此类资本流进入国际收支的资本帐户项目，从而可平衡经常帐户中的赤字。资本流动的增加产生了资产市场模式。
资产市场模式
目前为止的最佳模式。
金融资产(股票和债券)贸易的迅速膨胀使分析家和交易商以新的视角来审视货币。诸如增长率、通胀率和生产率等经济变量已不再是货币变动仅有的驱动因素。源于跨国金融资产交易的外汇交易份额，已使由商品和服务贸易产生的货币交易相形见绌。
资产市场方法将货币视为在高效金融市场中交易的资产价格。因此，货币越来越显示出其与资产市场，特别是股票间的密切关联。
美元和美国资产市场 - 1999 年
1999 年夏，许多权威人士认定美元将对欧元贬值，理由是持续增长的美国经常帐户赤字和华尔街的经济过热。此观点的理论基础是：非美国投资者将会从美国股票和债券市场抽取资金，投入到经济状况更为健康的市场中去，从而大幅压低美元币值。而这样的恐惧自 80 年代早期以来一直没有消散。当时，美国经常帐户迅速增长至历史最高记录，占国内总产值(GDP)的 3.5%。
正如80年代那样，外国投资者对美国资产的胃口依旧如此贪婪。但与 80 年代不同的是，财政赤字在 90 年代消失了。虽然外国持有美国债券的增长速度可能已经放缓，但源源不断注入美国股市的大量资金却足以抵销这种缓势。在美国泡沫破裂的情况下，非美国投资者最有可能做出的选择是更安全的美国国库券，而不是欧元区或英国股票，因为欧元区或英国股票很有可能在上述事件中受到重创。在 1998 年 11 月危机，以及 1996 年 12月由美联储主席格林斯潘的某些言论而引发的股慌中，此类情况已经发生。在前一事例中，外国国库券净购买量几乎增长了两倍，达到 440 亿美元；而在后一事例中，此项指标狂增十倍有余，达到 250 亿美元。
过去二十年中，在估计美元行为方面，国际收支法已为资产市场法所取代。尽管欧元区经济基本面要素的改善必将帮助这一年轻的货币收复失地，但是单靠基本面要素很难支撑这一复苏。而今仍旧存在欧洲央行的信用问题；截止目前，欧洲央行的信用度与欧元受到的频繁的口头支持成反比关系。欧元区三巨头(德国、法国和意大利)的政府稳定性，以及欧洲货币联盟扩展等敏感问题若隐若现的风险也被看作是单一货币的潜在障碍。
目前，美元得以保持稳定应归因于下列因素：零通胀增长，美国资产市场的安全避风港性质，以及上文提及的欧元风险。
2、技术分析
技术分析研究以往价格和交易量数据，进而预测未来的价格走向。此类型分析侧重于图表与公式的构成，以捕获主要和次要的趋势，并通过估测市场周期长短，识别买入 / 卖出机会。根据您选择的时间跨度，您可以使用日内(每 5 分钟、每 15 分钟、每小时)技术分析，也可使用每周或每月技术分析。
技术分析基本理论
道琼斯理论
这一技术分析中最古老的理论认为，价格能够全面反映所有现存信息，可供参与者(交易商、分析家、组合资产管理者、市场策略家及投资者)掌握的知识已在标价行为中被折算。由不可预知事件引起的货币波动，比如神的旨意，都将被包含在整体趋势中。技术分析旨在研究价格行为，从而做出关于未来走向的结论。
主要围绕股票市场平均线发展而来的道琼斯理论认为，价格可演释为包括三种幅度类型的波状－－主导、辅助和次要。相关时间周期从小于 3 周至大于 1 年不等。此理论还可说明反驰模式。反驰模式是趋势减缓移动速度所经历的正常阶段，这样的反驰模式等级是33%、 50% 和 66%。
斐波纳契反驰现象
这是一种广为使用，基于自然和人为现象所产生的数字比率的反驰现象组。此现象被用于判断价格与其潜在趋势间的反弹或回溯幅度大小。最重要的反驰现象等级是 38.2%、 50% 和 61.8%。
埃利奥特氏波
埃利奥特派学者以固定波状模式将价格走向分类。这些模式能够表示未来的指标与逆转。与趋势同向移动的波被称为推动波，而与趋势反向移动的波被称为修正波。埃利奥特氏波理论分别将推动波和修正波分为 5 种和 3 种主要走向。这 8 种走向组成一个完整的波周期。时间跨度可从 15 分钟至数十年不等。 埃利奥特氏波理论具有挑战性的部分在于，1个波周期可用 8 个子波周期组成，而这些波又可被进一步分成推动和修正波。因此，埃利奥特氏波的关键是能够识别特定波所处的环境。埃利奥特派也使用斐波纳契反驰现象来预测未来波周期的峰顶与谷底。
技术分析的内容有哪些？
发现趋势
关于技术分析，您首先听说的可能会是下面这句箴言：“趋势是您的朋友”。找到主导趋势将帮助您统观市场全局导向，并且能赋予您更加敏锐的洞察力－－特别是当更短期的市场波动搅乱市场全局时。每周和每月的图表分析最适合用于识别较长期的趋势。一旦发现整体趋势，您就能在希望交易的时间跨度中选择走势。这样，您能够在涨势中买跌，并且在跌势中卖涨。
支撑和阻力
支撑和阻力水准是图表中经受持续向上或向下压力的点。支撑水准通常是所有图表模式(每小时、每周或者每年)中的最低点，而阻力水准是图表中的最高点(峰点)。当这些点显示出再现的趋势时，它们即被识别为支撑和阻力。买入 / 卖出的最佳时机就是在不易被打破的支撑 / 阻力水准附近。
一旦这些水准被打破，它们就会趋向于成为反向障碍。因此，在涨势市场中，被打破的阻力水准可能成为对向上趋势的支撑；然而在跌势市场中，一旦支撑水准被打破，它就会转变成阻力。
线条和通道
趋势线在识别市场趋势方向方面是简单而实用的工具。向上直线由至少两个连继低点相连接而成。很自然，第二点必须高于第一点。直线的延伸帮助判断市场将沿以运动的路径。向上趋势是一种用于识别支持线 / 水准的具体方法。反而言之，向下线条是通过连接两点或更多点绘成。交易线条的易变性在一定程度上与连接点的
数量有关。然而值得一提的是，各个点不必靠得过近。
通道被定义为与相应向下趋势线平行的向上趋势线。两条线可表示价格向上、向下或者水平的走廊。支持趋势线连接点的通道的常见属性应位于其反向线条的两连接点之间。 平均线
如果您相信技术分析中“趋势是您的朋友”的信条，那么移动平均线将使您获益匪浅。移动平均线显示了在特定周期内某一特定时间的平均价格。它们被称作“移动”，因为它们依照同一时间度量，且反映了最新平均线。
移动平均线的不足之一在于它们滞后于市场，因此并不一定能作为趋势转变的标志。为解决这一问题，使用 5 或 10 天的较短周期移动平均线将比 40 或 200 天的移动平均线更能反映出近期价格动向。或者，移动平均线也可以通过组合两种不同时间跨度的平均线加以使用。无论使用 5 和 20 天的移动平均线，还是 40 和 200 天的移动平均线，买入信号通常在较短期平均线向上穿过较长期平均线时被查觉。与此相反，卖出信号会在较短期平均线向下穿过较长周期平均线时被提示。
有三种在数学上不同的移动平均线：简单算术移动平均线；线型加权移动平均线；以及平方系数加权平均线。其中，最后一种是首选方法，因为它赋予最近的数据更多权重，并且在金融工具的整个周期中考虑数据。
第六课 汇市与股市的比较
从选择投资工具的角度来看，汇市与股市各有特点。以下做一个简单的比较，以供投资者参考。
总体来看，外汇市场更加规范和成熟，交易方式更加灵活和方便，获利空间较大而风险则可
控制在一定的限度内。对于专业的投资者，以及持有外汇的机构和个人来讲，是一种稳健而
成熟的投资方式。
第七课 外汇市场的短期波动
国际外汇市场上外汇价格的每天波动幅度大致在0.8%至1.5%之间(即一至两分钱，用
外汇市场的术语来说就是100点至200点)，波动幅度大时可达到5%以上(即700点到1000
点)。外汇市场上汇率经常性的大起大落说明了外汇市场的两大特征：第一，风险很大；第
二，在外汇市场投资 获得巨额利润的可能性存在。对于外汇市场经常出现的短期剧烈波动，
经济学上称之为对信息的过分反应(overshooting)。对于什么是外汇市场的过分反应，经济
学界始终有争论，目前大致有以下三种解释。
第一，外汇的现货价格与外汇汇率的长期均衡价格发生偏离。人们经常在报
纸上谈到，某种货币的“汇率目前是被高估的”，或者是某种货币“目前的汇率已远远低于
它的合理价格”。这些话所指的就是这种现象。
外汇的现货价格过分地偏离外汇的长期均衡价格也可以由多种原因来解释，可能是现货价格太低或太高，也可能是长期的均衡价格被估计得太低或太高。从市场运行本身来看，在投机性资本不充足时(市场上交易量很少)，或在外汇市场上投机性资本过分多的时候(市场交易过热)，现货价格的波动超过它的长期均衡价就不是一种难以理解的现象了。
第二，外汇的短期均衡价格波动幅度总是会超过它长期的均衡价格波动幅度。这种解释假设所有会影响外汇市场的因素都会对外汇的价格波动产生作用，但这种作用的生效在时间和渠道上有差别，造成短期均衡价偏离长期均衡价。
对于外汇的短期均衡价格偏离长期均衡价格的现象，目前经济学界流行的解释是，当政府扩大货币供应量或降低利率时，市场上物价并不会马上上升，导致实际的货币供应量增加，外汇市场则迅速反应，本国货币的汇价大幅度下跌，使外汇的短期均衡价过分地低于长期均衡价。而当物价在完全消化货币供应量增长因素时会上升，实际的货币供应量会有所下降，外汇的短期均衡价也会逐渐恢复到与长期均衡价趋于一致。
第三，外汇市场不是一个有效率的市场，即外汇价格的波动不能充分反映市场在一定时期内出现的全部信息，导致外汇的实际价格经常过分地偏离均衡价格。
外汇市场的短期剧烈波动可能是由于市场参与者主观地排斥某些信息，片面地接受或过分地接受某些信息，使外汇价格过分扭曲；也可能是某些影响外汇波动的信息掩盖了其他一些同样重要的信息，造成外汇价格大起大落。
其次，如果外汇市场不是一个有效益的市场，就会导致一些纠偏的行为在市场出现，如以牟利为动机的投机者介入市场、需要准确地发布影响市场的信息、政府干预等。这些纠偏的行为有时会使实际价格与均衡价格趋于一致，有时却会进一步扭曲市场的价格波动。 从现在外汇市场的实际波动来看，外汇市场在长期可能是一个信息有效率的市场，但在短期却还远远没办法证明。目前对外汇市场每天波动影响最大的是新闻，它包括经济和政治两大类。此外，市场投资者的意愿和心理因素，又常常使这些新闻对外汇市场的影响进一步扩大了。
第八课 经济新闻对外汇市场短期波动的影响
在影响外汇市场波动的经济新闻中，美国政府公布的关于每月或每季度美国经济统计数据的作用最大，其主要原因是美元是外汇市场交易的最重要的货币。从经济统计数据的内容来看，按作用大小排列可分为利率变化、就业人数的增减、国民生产总值、工业生产、对外贸易、通货膨胀情况等。这种排列并不是绝对的，例如，美国对外贸易的每季度统计数曾是最重要的影响美元走势的数据之一。80年代中期以前，每当美国贸易数字公布前几天，外汇市场就会出现种种猜测和预测，引起外汇市场的剧烈波动。但是在80年代中后期以后，其作用越来越小，原因是市场已真正意识到，目前外汇市场的交易额中，国际贸易额所占的比重仅仅为1%左右。所以，现在美国对外贸易统计数据公布时，外汇市场经常不会对它作出大的反应。
1、利率政策
在各种经济数据中，各国关于利率的调整以及政府的货币政策动向无疑是最重要的。对外汇汇率和利率的相互关系，本文不做详细介绍，但这里要强调的是，有时政府虽然没有任何表示要改变货币政策，但只要市场有这种期待，或者说其他国家都采取了类似的行动，那么，外汇市场会继续存在这一政府会改变政策的期待，使这一国家的货币汇率出现大幅度波动。例如，1992年下半年，德国奉行反通货膨胀的紧缩性货币政策，德国中央银行一而再、再而三地声明要坚持这一政策，但外汇市场经常流传德国要减息的谣言和猜测，理由是德国的利息已经加到顶了。虽然德国没有任何减息动向，但在英国、法国、丹麦、瑞典等相
继减息后，外汇市场又顽固地认为德国会减息，即使年底不减，第二年初也会减。这使马克对美元的汇价在美国与德国的利率差仍然很大的情况下，节节下跌。
2、非农就业人口
美国关于非农业人口就业人数的增减数和失业率是近几年影响外汇市场短期波动的重要数据。这组数字由美国劳工部在每月的第一个星期五公布。在外汇市场看来，它是美国宏观经济的晴雨表，数字本身的好坏预示着美国经济前景的好坏。因此，在这组数字公布前的
一、两天，只要市场上有任何关于这一数字可能不错的风言风语时，美元抛售风就会嘎然而止。较典型的例子是1992年1月上旬的美元对其他外汇的走势。从1991年下半年开始，外汇市场由于对美国经济可能陷入衰退的担忧，开始不断抛美元，使外汇对美元的汇价节节高攀，英镑对美元的汇率从1991年7月的1.60涨到1992年1月初的1.89。1992年1月9日，也就是美国劳工部公布美国前一年12月份非农业就业人口数可能增长10万，致使这一天外汇市场一开市，就有人开始抛外汇买美元，英镑对美元的汇价从1.88跌至1.86，跌幅近200点。经过几个小时后，外汇市场便开始恐慌性地买美元，马克、英镑、瑞士法郎等对美元的汇价出现狂泻，英镑又掉了近600点，跌至1.8050。第二天公布的非农业就业人口数虽仅增长了3万，但这次恐慌改变了以后4个月美元对其他外汇的走势。美元在对美国经济前景看好的前提下，一路上扬，一直到4月份，美国经济情况并不如预期中那么好的事实才被外汇市场所接受，美元从此又开始走下坡路。
3、其他经济数据
其他一些美国经济统计数据对外汇市场也有影响，这些数据包括工业生产、个人收入、国民生产总值、开工率、库存率、美国经济综合指标的先行指数、新住房开工率、汽车销售数等，但它们与非农业就业人口数相比，对外汇市场的影响要小得多。这些经济指标对外汇市场的影响也有其独特的规律。一般来说，当美元呈一路上扬的“牛”势时，其中任何指标在公布时只要稍好一些，都会被外汇市场用来作为抛外汇买美元的理由，使美元进一步上扬，而指标为负数时，外汇市场有时就对其采取视而不见的态度。同样，当美元呈一路下泻的“熊”势时，任何公布的经济指标为负数时，都会成为外汇市场进一步抛美元的理由。
美国、德国等每月公布的批发价、零售价指数的变化情况对外汇市场也有影响，但影响的大小要看特定的条件。一般来说，当市场对某国中央银行存在着减息或加息的期待时，其每月公布的物价指数对外汇市场的敏感性就很强。例如，1992年11月，澳大利亚的澳元对美元的汇率已创近几年的最低点，外汇市场许多人认为澳元已接近谷底，有可能开始反弹了。但市场上也有人根据澳大利亚经济前景暗淡的预测，传言澳大利亚中央银行可能会采取减息的刺激经济措施。这时，澳大利亚政府公布的10月份批发物价上涨率仅为0.1%，为近10多年来的最低水平，外汇市场仿佛找到了其减息期待的依据，当天就出现抛澳元风，使澳元在低谷徘徊。
除了经济统计数据之外，其他关于经济活动的报道也会对外汇市场产生很大的影响。外汇价格的变动在很大程度上是外汇市场上的人对外汇波动的期待的反映，换言之，如果人们期待外汇有某一个长期的均衡价格，那么，现货价格的波动就会朝这个价格的方向移动。而这种期待是主观性的东西，它必然会受到客观经济环境的影响。因此，在连续几天没有关于经济活动数据分布的情况下，有关国家货币当局官员的讲话、《华尔街日报》关于外汇市场的有影响力的一篇文章、某研究机构或大企业关于外汇走势的研究报告等，都可能会在某一天造成外汇市场的剧烈波动。这种现象对那些身处外汇市场以外的人来说，似乎很难理解，为什么一个官员的讲话会使美元猛跌或猛涨2至3美分(即200至300点)？如果把人们主观期待的因素考虑在内，这种现象就不难解释了。一个官员的讲话中一篇关于外汇的重要文章仅仅是提供了某种信号，给人们的合理预期起了催化剂的作用，最后导致外汇市场的波动而波动幅度的大小，就由这些信号在合理预期中的催化剂作用大小来决定。
如果市场不认为它是信号，则这种讲话再多，外汇市场的人也会充耳不闻。较典型的例子是英镑在1992年年底的跌势。自1992年9月欧洲货币体系危机以后，外汇市场出现了猛抛英镑风，其原因在于英国经济前景暗淡、英国经济政策不明朗、英国减息期待等多种因素，为了稳定英镑的汇率，英国财政大臣拉蒙特多次发表讲话，表示要稳定英镑汇率，甚至可能以加息来提高英镑的汇价。但每次都只能给英镑的汇率以微弱而短暂的支持，在英镑稍有回弹后，外汇市场就有更多的人抛英镑。
三、影响外汇市场短期波动的政治因素
与股票、债券等市场相比，外汇市场受政治因素的影响要大得多。当某一件重大国际事件发生时，外汇市场的涨落幅度会经常性地超过股市和债券市场的变化。其主要原因是外汇作为国际性流动的资产，在动荡的政治格局下所面临的风险会比其他资产大；而外汇市场的流动速度快，又进一步使外汇市场在政治局面动荡时更加剧烈地波动。
外汇市场的政治风险主要有政局不稳引起经济政策变化、国有化措施等。从具体形式来看，有大选、战争、政变、边界冲突等。从资本安全角度出发，由于美国是当今世界最大的军事强国，其经济也仍处于领先地位，所以，一般政治动荡产生后，美元就会起到“避风港”(safe haven)的作用，会立刻走强。政治事件经常是突发性事件，出乎外汇市场的意料，这又使外汇市场的现货价格异常剧烈地波动，其波动幅度大大超过外汇价格的长期波动幅度。下面选择苏联8.19事件、英国1992年大选和美国攻打伊拉克的“沙漠风暴”计划为例子，说明政治事件对外汇市场短期走势影响的一些规律。
1、苏联1991年8.19事件对外汇市场的影响
从1991年下半年开始，美元对几乎所有的主要外汇都呈弱势。但是，苏联8.19事件使这走势完全打乱，而事件失败后，又使走势恢复到原来的状态，美元又一路走弱，到第二年1月才止跌回升。
外汇市场在苏联8.19事件前后的波动完全说明了美元作为“避风港”货币的作用。在8.19事件发生以前，外汇市场已在流传苏联政局不稳的消息，美元连续7天小涨，但谁也没有预料到会有突发事件发生。到8月19日，当外汇市场所有交易者的计算机屏幕上打出“苏联发生政变”的字样时，便立刻出现一片恐慌性地买美元风。以英镑为例，英镑对美元的汇率在短短的几分钟内从1英镑兑1.6633美元猛跌至1.6130，跌幅达3.1%。第二天，外汇市场又随着弋尔巴乔夫失去联系、发动事件者似乎难以控制局势等消息的不断出现而涨涨落落。到第三天，8.19事件宣告失败，外汇市场立刻抛出美元。同样以英镑为例，英镑对美元的汇率从1.6363美元涨到1.6915，猛涨3.4%，使英镑又同其他外汇一起，开始了对美元的汇价一路上扬的走势。
苏联8.19事件期间外汇市场的走势表明，外汇价格的变动有其内在的规律。短期的突发性事件会引起外汇的现货价格明显地背离其长期的均衡价。但是，在事件过后，外汇走势又按照其长期均衡价格的方向移动。一般来说，短期的价格变动至多会修正长期外汇均衡价格的方向，却很难改变或彻底扭转它的长期波动趋势。
至于在政治性突发事件发生时，外汇市场的波动幅度的极限有多大，始终是一个有争论的问题。一般认为，在突发性事件发生时，外汇价格的波动完全由市场参与者的心理因素决定，取决于人们对这一事件的承受能力。这种解释在实际运用中说服力不强。但是，技术分析专家却认为，外汇对美元的汇率在突发事件时能跌多少，完全是有规律可循的。以苏联
8.19事件为例，英镑对美元的汇价之所以跌至1.6130时止跌回升，完全是因为这一点是近5年来英镑对美元汇率移动平均线的底部，英镑对美元的汇率不太可能一次就穿过这条线，以后苏联8.19事件失败，更说明这一点的支撑作用。
2、1992年4月英国大选对外汇市场的影响
在英国大选前的一个多月，外汇市场就开始受到这次大选的影响。在大选以前，保守党候选人即现任首相梅杰在民意测验中一直落后于工党候选人尼尔·金诺克。英国的工党在80年代以前执政时曾坚持实行国有化政策，导致资本外流的局面。保守党撒切尔夫人在1979年上任当首相后，花了近10年的时间推行私有化政策，而梅杰上任后也继续执行这一政策。因此，如果金诺克在大选中获胜，就可能意味着英国政府政策的改变。虽然工人出身的金诺克在工党内属保守派，但人们还是担心英国有可能回到国有化政策推行的年代。由于金诺克在民意测验中领先于梅杰，英国的金融界从3月就出现了两种现象，一是资本开始逐渐外流，另一是英镑的汇价逐步下跌。以英镑对马克的汇率为例，英镑的汇价从2月中旬就开始下跌，从2月底的1英镑兑2.96马克逐步跌至4月6日的2.83。
英镑是欧洲货币体系的成员货币，它对马克的汇率是由固定但可调节的汇率制决定的，上限在3.1320马克，下限在2.7780马克，中心汇率为2.95。但自从英镑在1990年加入欧洲货币体系后，外汇市场一直认为英镑的汇价是高估的，所以经常在英镑走强时抛英镑。在英国大选到来时，梅杰在民意测验中落后，自然使外汇市场认为英国的政策前景不稳，进一步煽起了市场的抛英镑风，使英镑对马克的汇率向欧洲货币体系规定的底限逼近。
大选这一天，英镑在外汇市场出现了剧烈的波动。从英镑对马克的汇率来看，波幅为2%，达600点，即6个芬尼，而且整个一天的波动是很有戏剧性的。在大选前两天，外汇市场由于听到梅杰在民意测验中已接近金诺克的传闻，就已经开始买英镑抛马克等外汇。在大选这一天，金诺克的选票和民意测验结果在一开始仍然领先于梅杰，使外汇市场又大幅度地抛英镑。但没过多久，梅杰的选票就开始节节上升，立刻在外汇市场刮起了抛外汇买英镑的旋风，使英镑对马克的汇价迅速攀升，从2.8477马克猛涨到2.9053。
大选结束以后，英镑似乎从此扭转了弱势，成了坚挺的货币。外汇市场总是谈论英国的经济前景看好，流到海外的资本会返回英国，梅杰的胜利表明英国政局的稳定等等。其实，这时的梅杰还是原来当首相的梅杰，而以后一段时期内经常出现英国经济不景气的统计数据。但英镑在以后的近两个月内还是一路上涨。许多预测专家和技术分析专家都预言，英镑对马克的汇价将上升到3.10，去试探欧洲货币体系规定的3.13上限。从图形上来看，英镑对马克的汇价在大选后一直居高不下，但每次冲高时都在2.9500处被弹回，经过近两个月的高处徘徊，英镑对马克的汇价终于在6月份开始下跌。
英镑在英国大选前后的走势表明，外汇价格在短期内的过度波动可能会由于市场预期的支持而维持较长时期。在这种预期被打破以前，市场有时会认为短期的均衡价格是一种合理的价格，而预测中的长期均衡价格反而被认为是有偏差的。但是，如果外汇市场的预期始终得不到证实，因意外事件而扭曲的外汇价格走势就会恢复到原来的趋势上去，甚至走得更远。从6月份开始，英镑对马克的汇价一路下跌。在外汇市场证实英国经济前景并不十分乐观时，英镑的弱势就成为大势所趋了。以至在9月份的欧洲货币体系危机后，英镑对马克的汇价直线下降，仿佛如自由落体，迫使英国退出欧洲货币体系，英镑对马克的汇率在10月跌至2.40马克。
3、美国攻打伊拉克解放科威特的“沙漠风暴”计划对外汇市场的影响 “沙漠风暴”计划也很典型地反映出美元和黄金作为资金的“避风港”作用。世界局势的动荡不安会使美金和黄金大涨，以前人们所说的“大炮一响，黄金万两”应该就是这个意思。
外汇市场的许多投资者认为，外汇价格的走势有其一定的规律。但是在“沙漠风暴”计划前后，外汇市场的价格走势忽上忽下，显得非常凌乱。美国进攻伊拉克是1991年1月17日，在这以前的一个月内，外汇市场围绕美国究竟会不会打的猜测，大起大落，很明显地说明了上述特点。每当美国政府要员发表态度强硬的讲话，表示要采取军事行动，美元就会在一天内大涨一波；而外汇市场听到有西欧国家出面调解的传闻，似乎和平解决可望实现时，
美元就会下跌一次。在1月17日战争爆发这一天，美元一开始也是猛涨。从图4—4英镑对美元的走势来看，英镑跌到过1.8990。但没隔多久，新闻界传来美国已很快控制局势，稳操胜券时，美元的“避风港”作用立刻消失，市场便开始抛售美元，英镑对美元的价格猛涨到1.9353，以后的一个月内便一路上涨。
其实，根据对美国和伊拉克两国的军事实力分析，以及国际上舆论的倾向，任何理智的结论都会认为美国会达到把伊拉克赶出科威特的军事目的。然而，外汇市场并不接受这种逻辑判断，而是根据人们第一产生的心理和期待去寻找价格。只有在事实被人们接受之后，市场价格才会猛然回到原来趋势上去。黄金的美元价格更能说明这一点，在美国向伊拉克进攻后，黄金价格出奇地涨到410美元1盎司，但在美军取绝对优势的消息传出后，黄金又猛泻到373.70美元，期间的跌幅高达9.7%，大大出乎人们的预料，许多市场的小投资者顿时全部被“套”在里面，而且又由于黄金以后又持续下跌，使这部分投资者的损失十分惨重。从任何一种主要外汇对美元的汇率走势10年图中，人们都可以发现这10年国际政治、经济格局的变化情况。由于每次突发事件，每项重要的经济统计数据都会在每天的外汇市场上引起剧烈的波动，使汇率涨跌史成为国际政治经济发展史的缩影这一结论更具有说服力。在外汇市场投资，在把握住外汇走势的长期趋势时，更要十分注意它在短期的波动，只有认清它的短期波动规律，才能在外汇市场立于不败之地。
第九课 政府对外汇市场的直接干预（1）
1973年以后国际货币体系中实行的浮动汇率制并不是一种彻底浮动汇率制，而是一种所谓肮脏的浮动汇率制，其原因是工业国家中央银行对外汇市场的经常性干预。政府制定的货币政策和财政政策每天都影响着外汇市场的价格波动。工业国家的中央银行对外汇市场不但会透过制定货币政策和财政政策进行间接性的干预，还经常在外汇市场异常剧烈的波动时，直接干预外汇市场。这种政府对外汇市场的直接干预也是影响外汇市场短期走势的重要因素。
1、中央银行干预外汇市场的目标
自从浮动汇率制推行以来，工业国家的中央银行从来没有对外汇市场采取彻底的放任自流的态度，相反，这些中央银行始终保留相当一部分的外汇储备，其主要目的就是对外汇市场进行直接干预。
一般来说，中央银行在外汇市场的价格出现异常大的、或是朝同一方向连续几天剧烈波动时，往往会直接介入市场，通过商业银行进行外汇买卖，以试图缓解外汇市场的剧烈波动。对于中央银行干预外汇市场的原因，理论上可以有很多解释，为大多数人所接受的原因大致有三个。
第一，汇率的异常波动常常与国际资本流动有着必然联系，它会导致工业生产和宏观经济发展出现不必要的波动，因此，稳定汇率有助于稳定国民经济和物价。现在国际资本跨国界的流动不但规模很大，而且渠道很多，所受到的人为障碍很小。工业国家从70年代末开始放宽金融方面的规章条例，进一步为国际资本流动提供了方便。在浮动汇率制的条件下，国际资本大规模流动的最直接的结果就是外汇市场的价格浮动。如果大批资本流入德国，则德国马克在外汇市场的汇价就会上升，而如果大批资本流出美国，外汇市场上的美元汇价必然下降。从另一方面来看，如果人们都期待某一国货币的汇率会上升，资本就势必会流向该国。
资本流动与外汇市场变化的相关性对一个国家的国民经济产业配置和物价有着重要的影响。例如，当一个国家的资本大量外流，导致本国货币汇价下跌时，或者当人们预计本国货币的汇价会下跌，导致资本外流时，这个国家的产业配置和物价必然出现有利于那些与对外贸易有联系的产业的变动。任何一个国家的产业从对外贸易角度来看，可分为能进行对外
贸易的产业和无法进行对外贸易的产业两种。前者如制造业，生产的产品可出口和进口，后者如某些服务业，生产和消费必须在当地进行。当资本流出货币贬值时，能进行对外贸易的产业部门的物价就会上升，如果这一部门工资的上涨速度不是同步的话，追加这一部门的生产就会变得有利可图，出口因此也会增加，但是从国内的产业结构来看，资本就会从非贸易产业流向贸易产业。如果这是一种长期现象，该国的国民经济比例就可能失调。因此，工业国家和中央银行是不希望看到本国货币的汇价长期偏离它认为的均衡价格的。这是中央银行本国货币持续疲软或过分坚挺时直接干预市场的原因之一。
资本流动与外汇市场变化的相关性对国民经济的另外一个重要影响在于，大量资本流出会造成本国生产资本形成的成本上升，而大量资本流入又可能造成不必要的通货膨胀压力，影响长期资本投资。美国从80年代初实行紧缩性货币政策与扩张性财政政策，导致大量资本流入，美元汇价逐步上涨，而美国的联邦储备银行(联储会)在1981年和1982年间对外汇市场又彻底采取自由放任的态度。西欧国家为了防止资本外流，在欧洲货币的汇率不断下跌时，被迫经常直接干预外汇市场，并一再要求美国的联储会协助干预。
第二，中央银行直接干预外汇市场是为了国内外贸政策的需要。一个国家的货币在外汇市场的价格较低，必然有利于这个国家的出口。而出口问题在许多工业国家已是一个政治问题，它涉及到许多出口行业的就业水平、贸易保护主义情绪、选民对政府态度等许多方面。任何一个中央银行都不希望看到本国外贸顺差是由于本国货币的汇率太低而被其他国家抓住把柄。因此，中央银行为这一目的而干预外汇市场，主要表现在两个方面。
中央银行为了保护出口，会在本国货币持续坚挺时直接干预外汇市场。对那些出口在国民经济中占重要比重的国家来说，这样做就更有理由。1992年4月以前，澳元一路看涨，而且涨势平缓。但是，在3月30日澳元对美元的汇率涨到0.77美元时，澳大利亚中央银行立刻在市场上抛澳元买美元。又如，德国是世界制造业出口大国，70年代实行浮动汇率制以后，马克的汇价随着德国经济的强大而一路上扬，为了维持其出口工业在国际上的竞争地位，德国政府极力主张实行欧洲货币体系，以便把马克与欧洲共同体其他成员国的货币固定在一个范围内。
从日本中央银行经常干预外汇市场，可以充分看出贸易问题的重要性。80年代以来，日本对美国的贸易顺差每年保持在一个天文数字的水平，1991年为500亿美元，已成为美日关系之间的一个政治问题。1992年是美国大选年，美国国内针对日本的贸易保护主义情绪十分强烈，国会议员仍然在国会里抨击日本对美国的市场封闭。日本中银行为了缓和美国国内的反日情绪，经常发表讲话，要求日元走强，还不时地查询汇率情况，以表明自己的态度。
1992年1月17日，日本中央银行在美元走强的趋势形成时，突然在市场抛日元买美元，使美元对日元的汇率一下子从128.35日元涨到124.05日元。当时日本利率较高，日本政府并无减息意图。对于干预的理由，中央银行只是说希望日元走强。在以后3个星期内，日本中央银行又以同样的方式几次干预外汇市场，抛日元买美元，除了2月7日这一次在图形上较明显外，其余的几次都不十分有效。
从国际外汇市场发展史来看，利用本国货币贬值来扩大出口是许多国家在早期经常采取的政策，它被称为“乞邻政策”，在经济不景气时，常引起两国的贸易战。由于现在非关税贸易壁垒名目繁多，这一人为干预外汇市场的政策已很少采用，而且也会明显地引起其他国家的指责。
第三，中央银行干预外汇市场是出于抑制国内通货膨胀的考虑。宏观经济模型证明，在浮动汇率制的情况下，如果一个国家的货币汇价长期性地低于均衡价格，在一定时期内会刺激出口，导致外贸顺差，最终却会造成本国物价上涨，工资上涨，形成通货膨胀的压力。在通货膨胀已经较高的时候，这种工资—物价可能出现的循环上涨局面，又会造成人们出现未
来的通货膨胀必然也很高的期待，使货币当局的反通货膨胀政策变得很难执行。此外，在一些工业国家，选民往往把本国货币贬值引起的通货膨胀压力作为政府当局宏观经济管理不当的象征。所以，在实行浮动汇率制以后，许多工业国家在控制通货膨胀时，都把本国货币的汇率作为一项严密监视的内容。
英镑自80年代以来的波动，很清楚地说明货币贬值与通货膨胀的关系。70年代，几乎所有工业国都陷入两位数的通货膨胀，英镑也在劫难逃。在整个80年代，美国和西欧国家的中央银行都取得明显效果，而英国则效果较差。欧洲货币体系在1979年成立后，英国在撒切尔夫人执政时期出于政治等因素的考虑始终不愿加入，在抑制本国通货膨胀方面也做了很大的努力。在顶了10多年后的1990年，英国终于在梅杰任首相后宣布加入欧洲货币体系。其首要原因就是希望通过欧洲货币体系，把英镑的汇价维持在一个较高的水平，使英国的通货膨胀得到进一步的控制。但是好景不长，1992年欧洲货币体系出现危机，外汇市场猛抛英镑、里拉等，终于导致意大利里拉正式贬值。同样是基于反通货膨胀的考虑，英国政府花了60多亿美元在市场干预，德国中央银行为了维持英镑和里拉的币值，也花了120多亿美元在外汇市场干预。在英镑继续大跌，英镑在欧洲货币体系内贬值的呼声很高的情况下，英国宣布退出欧洲货币体系，而绝不正式将英镑贬值，同时宣布仍要继续执行反通货膨胀的货币政策。
2、中央银行干预外汇市场的手段与效益
关于什么是中央银行对外汇市场的干预，有一个较为正式的定义。80年代初，美元对所有欧洲国家的货币汇率都呈升势，围绕着工业国家要不要对外汇市场进行干预，1982年6月的凡尔赛工业国家高峰会议决定成立一个由官方经济学家组成的“外汇干预工作小组”，专门研究外汇市场干预问题。1983年，该小组发表了“工作组报告”(又称“杰根森报告”)，其中对干预外汇市场的狭义定义是：“货币当局在外汇市场上的任何外汇买卖，以影响本国货币的汇率”，其途径可以是用外汇储备、中央银行之间调拨，或官方借贷等。其实，要真正认清中央银行干预外汇市场的实质和效果，还必须认清这种干预对该国货币供应及政策的影响。因此，在中央银行干预外汇市场的手段上，可以分为不改变现有货币政策的干预
(sterilized intervention，又称“消毒干预”)和改变现有货币政策的干预(no sterilized intervention，又称“不消毒干预”)。所谓不改变政策的干预是指中央银行认为外汇价格的剧烈波动或偏离长期均衡是一种短期现象，希望在不改变现有货币供应量的条件下，改变现有的外汇价格。换言之，一般认为利率变化是汇率变化的关键，而中央银行试图不改变国内的利率而改变本国货币的汇率。
中央银行在进行这种干预时可采取双管齐下的手段：
(1)中央银行在外汇市场上买进或卖出外汇时，同时在国内债券市场上卖出或买进债券，从而使汇率变而利率不变化。例如，外汇市场上美元对日元的汇价大幅度下跌，日本中央银行想采取支持美元抛出日元，美元成为它的储备货币，而市场上日元流量增加，使日本货币供应量上升，而利率呈下降趋势。为了抵消外汇买卖对国内利率的影响，日本中央银行可在国内债券市场上抛债券，使市场上的日元流通量减少，利率下降的趋势因此而抵消。需要指出的是，国内债券和国际债券的相互替代性越差，中央银行不改变政策的干预就越有效果，否则就没有效果。
(2)中央银行在外汇市场上通过查询汇率变化情况、发表声明等，影响汇率的变化，达到干预的效果，它被称为干预外汇市场的“信号反应”。中央银行这样做是希望外汇市场能得到这样的信号：中央银行的货币政策将要发生变化，或者说预期中的汇率将有变化等等。一般来说，外汇市场在初次接受这些信号后总会作出反应。但是，如果中央银行经常靠“信号效应”来干预市场，而这些信号又不全是真的，就会在市场上起到“狼来了”的效果。
1978年至1979年卡特政府支持美元的干预，经常被认为是“狼来了”信号效果的例子。而1985年西方五国财政部长和中央银行行长的“广场饭店声明”立刻使美元大跌，就经常被认为是“信号效应”成功的例子。
所谓改变政策的外汇市场干预实际上是中央银行货币政策的一种转变，它是指中央银行直接在外汇市场买卖外汇，而听任国内货币供应量和利率朝有利于达到干预目标的方向变化。例如，如果马克在外汇市场上不断贬值，德国中央银行为了支持马克的汇价，它可在市场上抛外汇买马克，由于马克流通减少，德国货币供应下降，利率呈上升趋势，人们就愿意在外汇市场多保留马克，使马克的汇价上升。这种干预方式一般来说非常有效，代价是国内既的货币政策会受到影响，是中央银行看到本国货币的汇率长期偏离均衡价格时才愿意采取的。
判断中央银行的干预是否有效，并不是看中央银行干预的次数多少和所用的金额大小。从中央银行干预外汇的历史至少可以得出以下两个结论。
第一，如果外汇市场异常剧烈的波动是因为信息效益差、突发事件、人为投机等因素引起的，而由于这些因素对外汇市场的扭曲经常是短期的，那么，中央银行的干预会十分有效，或者说，中央银行的直接干预至少可能使这种短期的扭曲提前结束。
第二，如果一国货币的汇率长期偏高偏低是该国的宏观经济水平、利率和政府货币政策决定的，那么，中央银行的干预从长期来看是无效的。而中央银行之所以坚持进行干预，主要是可能达到以下两个目的：首先，中央银行的干预可缓和本国货币在外汇市场上的跌势或升势，这样可避免外汇市场的剧烈波动对国内宏观经济发展的过分冲击；其次，中央银行的干预在短期内常会有明显的效果，其原因是外汇市场需要一定的时间来消化这种突然出现的政府干预。这给予中央银行一定的时间来重新考虑其货币政策或外汇政策，从而作出适当的调整。
3、中央银行干预外汇市场的历史发展
从1973年到现在，工业国家的中央银行经常在外汇市场上进行直接干预，其中较大的联合干预约有5次，成功和失败的兼而有之。
对1976年—1979年美元弱势的干预
在经过1974年至1975年的世界性经济衰退以后，美国的经济仍处于高通货膨胀，高失业率和低经济增长率的处境。卡特政府为了刺激经济，决定采取扩张性的财政政策和货币政策，虽然利率在上涨，但美国的通货膨胀率涨得更快，外汇市场因此开始不断地抛美元，使美元的汇价一路下跌。
面对美元的跌势，卡特政府决定干预外汇市场。1978年10月底，卡特政府宣布了一项反通货膨胀的计划，但由于对美国未来的货币政府并没有明确的表示，美元反而在外汇市场上狂泻。面临马克和日元升值的巨大压力，德国和日本两国的中央银行被迫进行不改变自己政策为前提的大规模干预，买美元抛本国货币，但收效甚微。
1978年11月1日，卡特总统宣布美元汇价太低，美国财政部和中央银行将直接进行干预。由于前一星期的反通货膨胀计划使外汇市场大失所望，卡特这次宣布的干预包含两项重要的政策转变。第一，货币政策将紧缩。联邦储备银行将把贴现率提高一个百分点，使贴现率达到当时历史高点的9.5%，从而使这次干预包含政策内容。第二，美国中央银行将调用300亿美元干预外汇市场，平稳美元的汇价。其中150亿将从其他中央银行借调，50亿从国际货币
基金组织提取和特别提款权的销售，50亿为所谓“卡特债券”(Carter bonds)，即财政部在国外销售的以马克和瑞士法郎记帐的债券。卡特计划宣布后，外汇市场果然受到震动，对其第一项紧缩政策更加警觉。在11月1日上午9:13，美元对马克的汇价立刻比前一天的最低点上升3.25%，达到1.83马克；几分钟后，随着中央银行抛出6,900万马克、1,900
万瑞士法郎后，美元继续上升，对马克的汇价又上升1%，对瑞士法郎的汇价也上升到1.567。在针对日元的干预动用了500万美元之后，美元对日元的汇价也跌至187.5日元。在这一天外汇市场收市时，美元对主要外汇的汇价平均上升了7%—10%。
在以后的两个星期内，外汇市场仍有抛美元风，以试探美国等中央银行干预市场的决心，但美国联邦储备委员会联合德国、瑞士和日本中央银行，一次又一次地在市场干预。到11月底，美国干预市场的总额达350亿美元，使美元明显回升。但是，到12月初，外汇市场开始怀疑美国是否会真正采取货币紧缩政策，又开始抛美元，使美元再度下跌。美国等中央银行继续大规模干预外汇市场，光是美国就花了310亿美元，但干预的效果已明显下降，到12月底，美元汇价已低于11月的水平。美元的真正走强是1979年10月新的联储会主席保罗·沃尔克上台宣布货币供应控制以后的事。
1985年9月工业五国对外汇市场的干预
如果说70年代末美国等中央银行干预外汇市场是一场失败的持久战，1985年9月工业5国对外汇市场的干预则是一场成功的速决战。里根上台后，美元就开始一路走强，到1985年2月25日达到最高点，对马克的汇率高达1美元兑3.4794马克。经过春季和夏季的调整后，美元在该年9月又开始上涨。美国、英国、法国、德国和日本等五国的财政部长与中央银行行长在纽约广场饭店开会讨论外汇干预问题。9月22日星期天，五国发表声明。声明说，五国财长和中央银行行长一致同意，“非美元货币对美元的汇价应该进一步走强”，他们“在有必要时将进一步合作，进行干预”。第二天早上，外汇市场美元便立刻大跌，对马克的汇率从2.7352跌到2.6524马克，跌幅达3%以上。美元从此一路下跌，以至到1986年底，日本和德国的中央银行又被迫采取支持美元的干预措施，收效仍然甚微，美元的跌势到1987年初美元中央银行也参加市场干预时才止住。
1985年9月的干预是否有效，外汇市场存在着争论。有人认为，美元在干预前已经开始走弱，即使中央银行银行不干预，它也会在9月份反弹后继续走弱。但更多的意见认为，这次干预还是有效的。
这次干预如果说是成功的话，那就是“信号反应”起的作用。在干预的前后两个星期，汇率大变，而工业国家之间的利率差根本没有变化，一直到10月底，日本在信贷市场上实行紧缩政策，才使利率差开始有真正的变化。但是，这次五国联合至少使外汇市场得到两个强烈信号。首先，这次声明使外汇市场意识到，五个工业国家将会充分协调，竭尽全力地进行更大规模的外汇市场干预。而以后的事实证明，中央银行在干预外汇市场时，确实是那样做的。其次，这次声明意味着美国外汇政策的重大转变。里根政府一开始就奉行让市场自由竞争的自由放任政策，一直听任美元的一路走强，而且对其他国家中央银行干预外汇市场的要求置之不理。这次美国与其他工业国一起参与干预，使外汇市场有理由相信，美国为了与其他工业国家协调，有可能调整货币和宏观经济政策，使美元开始走弱。
1992年夏季美国等中央银行对外汇市场的干预1992年3月中旬开始，外汇市场对期待已久的美国经济复苏再次失望，在德国高利率和美国坚持宽松的货币政策影响下，开始不断抛售美元，致使美元对几乎所有欧洲货币的汇价都一路下跌。美国与欧洲国家的中央银行分别在7月20日和8月11日两次大规模干预外汇市场。这两次干预从性质上来说，都是属不改变各自经济政策的干预，虽然有短时的效果，从中、长期来看却完全是失败的。
第一次干预是7月20日马克与美元的汇价冲击1991年2月以后的新高点1.4430时进行的，美国等15个工业国家的中央银行联手在市场抛马克买美元，经过3次干预后，美元对马克的汇价一下子从1.4470上升到1.5000，美元在两天内反弹了500多点。但是这次干预并没有止住美元的跌势。在经过半个多月的徘徊后，美元又继续下跌。美国等13个工业国家的中央银行于8月11日再次联手干预，但效果比第一次还要差。第一轮干预使美元对马克的汇率从1.4620马克反弹到1.4780，仅上升150点，而且时效仅维持了半个多小时。
以后美元重新下跌。美国联邦储备委员会在3个多小时内分别在美元兑马克的汇率1.4715、
1.4730和1.4770等处4次干预市场，抛马克买美元，但仅仅使美元略有反弹。在这次干预中，美国等工业国家共动用了10至15亿美元。然而，两天以后，美元又跌过干预前的最低点。
这次干预之所以失败，除了上面所说的属于不改变政策的干预外，外汇市场对这些干预早有期待也是个重要原因。对外汇市场来说，最以推动市场的是突发性事件，而预料之中的事件往往会提前反映到外汇市场中去。这是第一次干预比第二次干预有效一些的原因。而这两次干预最终不能改变美元的弱势，原因是中央银行不能使外汇市场相信，美元的汇价应该市场价高一些。
1992年9月欧洲货币体系成员国对外汇市场的干预1992年9月欧洲货币体系出现危机，外汇市场猛烈地抛售成员国中几乎所有的疲软的货币，英镑、意大利里拉、爱尔兰镑等无不出现大幅度币值下跌的情况。受其株连的是非成员国芬兰等国货币，在外汇市场上也出现大跌，迫使这些国家宣布脱离与欧洲货币体系的自愿挂钩。
这次干预中，欧洲共同体的成员国几乎都花了很大的代价。德国中央银行花了120多亿美元，英国花了近60亿，而法国向德国中央银行借调外汇进行干预的钱，到11月初才还清。这次干预使欧洲货币体系的矛盾有所缓和，但远远没有解决问题。
由于外汇市场的短期波动非常频繁且幅度较大，创造了非常多的短期获利机会。因此，把握上述主要因素和外汇市场之间的关系，对于提高分析能力和盈利能力是很有帮助的。
卖图稿、写文章、下软件还能赚钱？今天不是愚人节！ 有创意？有新意？有能力？别浪费自己的天赋力！
四 : 外汇交易入门教程,个人学习专用
按下ctrl键并把鼠标移动到手势文字上面，出现手形鼠标后单击打开对应网站。[www.61k.com)
外汇交易入门 外汇交易入门教程,个人学习专用
并没有指定的结算日期，交易一瞬间即可完成，全日24小时可以进出市场，也可以随时改变投资方向策略，是最灵活可靠的投资。［www.61k.com）
我们把11.183EUR＊汇率〈0.9000〉就知道也是等于10美元。（www.61k.com)总言之，只是十万元一手，所有直接货币，每一点的价值都是10美元。
括纸币、铸币。(www.61k.com）②外币支付凭证。包括票据、银行的付款凭证、邮政储蓄凭证等。③外币有价证券。包括政府债券、公司债券、股票等。④特别提款权、欧洲货币单位。⑤其他外币计值的资产。
目前世界上的金融商品市场有许多种，但概括起来可分为：股票市场、利息市场(包括债券、商业票据等)、黄金市场(包括黄金、白金、银)、期货市场(包括粮食、棉、油等)、期权市场和外汇市场等。(www.61k.com）
行商网络进行的，它不像股票交易有集中统一的地点。(www.61k.com)但是，外汇交易的网络却是全球性的，并且形成了没有组织的组织，市场是由大家认同的方式和先进的信息系统所联系，交易商也不具有任何组织的会员资格，但必须获得同行业的信任和认可。这种没有统一场地的外汇交易市场被称之为“有市无场”。全球外汇市场每天平均上万亿美元的交易。如此庞大的巨额资金，就是在这种既无集中的场所又无中央清算系统的管制，以及没有政府的监督下完成清算和转移。
是以在外汇汇价波动中赢利为目的的。（www.61k.com］因此，现货、合约现货以及期货交易在外汇交易中所占的比重较大。
从上表中可以发现，实买实卖的与保证金形式的买卖在盈利和亏损的金额上是完全相同的，所不同的是投资者投入的资金在数量上的差距，实买实卖的要投入9万多美元，才能买卖12,500,000日元，而采用保证金的形式只需1千美元，两者投入的金额相差90多倍。（www.61k.com)因此，采取合约形式对投资者来说投入小、产出多，比较适合大众的投资，可以用较小的资金赢得较多的利润。
结束，就不必考虑利息的支出与收益，因为一二天的利息支出与收益很少，对盈利或者亏损影响很小。（www.61k.com)对中、长线投资者来说，利息问题却是一个不可忽视的生要环节。例如，投资者在1.7000价位时先卖英镑，一个月以后，英镑的价格还在这一位置，如果按卖英镑要支付8%的利息计算，每月的利息支付高达750美元。这也是一个不少的支出。从目前一般居民投资的情况来看，有很多投资者对利息的收入看得比较多，而同时忽视了外币的走势，从而都喜欢买高息外币，结果造成了以少失多，例如，当英镑下跌时，投资者买了英镑，即使一个合约每月收息450美元，但一个月英镑下跌了500点，在点数上赔掉3,125美元，利息的收入弥补不了英镑下跌带来的损失。所以，投资者要把外汇汇率的走势放在第一位，而把利息的收入或支出放在第二位。
1997年以来，随着互联网的发展，在线外汇保证金交易已经风靡世界，成为外汇交易的流行方式，不仅银行间交易已开始采用在线方式，个人也越来越多的通过互联网参与外汇交易市场。[www.61k.com］
方面购入 / 卖出本国货币，或者联合其它中央银行进行共同干预，以期取得更为显著的效果。[www.61k.com）或者，有些国家能够设法仅仅通过发出干预暗示或威胁来达到影响币值变化的目的。 基础分析的基本理论
正如80年代那样，外国投资者对美国资产的胃口依旧如此贪婪。［www.61k.com)但与 80 年代不同的是，财政赤字在 90 年代消失了。虽然外国持有美国债券的增长速度可能已经放缓，但源源不断注入美国股市的大量资金却足以抵销这种缓势。在美国泡沫破裂的情况下，非美国投资者最有可能做出的选择是更安全的美国国库券，而不是欧元区或英国股票，因为欧元区或英国股票很有可能在上述事件中受到重创。在 1998 年 11 月危机，以及 1996 年 12月由美联储主席格林斯潘的某些言论而引发的股慌中，此类情况已经发生。在前一事例中，外国国库券净购买量几乎增长了两倍，达到 440 亿美元；而在后一事例中，此项指标狂增十倍有余，达到 250 亿美元。
关于技术分析，您首先听说的可能会是下面这句箴言：“趋势是您的朋友”。［www.61k.com)找到主导趋势将帮助您统观市场全局导向，并且能赋予您更加敏锐的洞察力－－特别是当更短期的市场波动搅乱市场全局时。每周和每月的图表分析最适合用于识别较长期的趋势。一旦发现整体趋势，您就能在希望交易的时间跨度中选择走势。这样，您能够在涨势中买跌，并且在跌势中卖涨。
控制在一定的限度内。（www.61k.com）对于专业的投资者，以及持有外汇的机构和个人来讲，是一种稳健而
外汇的现货价格过分地偏离外汇的长期均衡价格也可以由多种原因来解释，可能是现货价格太低或太高，也可能是长期的均衡价格被估计得太低或太高。［www.61k.com］从市场运行本身来看，在投机性资本不充足时(市场上交易量很少)，或在外汇市场上投机性资本过分多的时候(市场交易过热)，现货价格的波动超过它的长期均衡价就不是一种难以理解的现象了。
继减息后，外汇市场又顽固地认为德国会减息，即使年底不减，第二年初也会减。（www.61k.com]这使马克对美元的汇价在美国与德国的利率差仍然很大的情况下，节节下跌。
如果市场不认为它是信号，则这种讲话再多，外汇市场的人也会充耳不闻。(www.61k.com]较典型的例子是英镑在1992年年底的跌势。自1992年9月欧洲货币体系危机以后，外汇市场出现了猛抛英镑风，其原因在于英国经济前景暗淡、英国经济政策不明朗、英国减息期待等多种因素，为了稳定英镑的汇率，英国财政大臣拉蒙特多次发表讲话，表示要稳定英镑汇率，甚至可能以加息来提高英镑的汇价。但每次都只能给英镑的汇率以微弱而短暂的支持，在英镑稍有回弹后，外汇市场就有更多的人抛英镑。
在英国大选前的一个多月，外汇市场就开始受到这次大选的影响。（www.61k.com]在大选以前，保守党候选人即现任首相梅杰在民意测验中一直落后于工党候选人尼尔·金诺克。英国的工党在80年代以前执政时曾坚持实行国有化政策，导致资本外流的局面。保守党撒切尔夫人在1979年上任当首相后，花了近10年的时间推行私有化政策，而梅杰上任后也继续执行这一政策。因此，如果金诺克在大选中获胜，就可能意味着英国政府政策的改变。虽然工人出身的金诺克在工党内属保守派，但人们还是担心英国有可能回到国有化政策推行的年代。由于金诺克在民意测验中领先于梅杰，英国的金融界从3月就出现了两种现象，一是资本开始逐渐外流，另一是英镑的汇价逐步下跌。以英镑对马克的汇率为例，英镑的汇价从2月中旬就开始下跌，从2月底的1英镑兑2.96马克逐步跌至4月6日的2.83。
美元就会下跌一次。［www.61k.com）在1月17日战争爆发这一天，美元一开始也是猛涨。从图4—4英镑对美元的走势来看，英镑跌到过1.8990。但没隔多久，新闻界传来美国已很快控制局势，稳操胜券时，美元的“避风港”作用立刻消失，市场便开始抛售美元，英镑对美元的价格猛涨到1.9353，以后的一个月内便一路上涨。
贸易的产业和无法进行对外贸易的产业两种。(www.61k.com]前者如制造业，生产的产品可出口和进口，后者如某些服务业，生产和消费必须在当地进行。当资本流出货币贬值时，能进行对外贸易的产业部门的物价就会上升，如果这一部门工资的上涨速度不是同步的话，追加这一部门的生产就会变得有利可图，出口因此也会增加，但是从国内的产业结构来看，资本就会从非贸易产业流向贸易产业。如果这是一种长期现象，该国的国民经济比例就可能失调。因此，工业国家和中央银行是不希望看到本国货币的汇价长期偏离它认为的均衡价格的。这是中央银行本国货币持续疲软或过分坚挺时直接干预市场的原因之一。
来的通货膨胀必然也很高的期待，使货币当局的反通货膨胀政策变得很难执行。［www.61k.com）此外，在一些工业国家，选民往往把本国货币贬值引起的通货膨胀压力作为政府当局宏观经济管理不当的象征。所以，在实行浮动汇率制以后，许多工业国家在控制通货膨胀时，都把本国货币的汇率作为一项严密监视的内容。
1978年至1979年卡特政府支持美元的干预，经常被认为是“狼来了”信号效果的例子。（www.61k.com]而1985年西方五国财政部长和中央银行行长的“广场饭店声明”立刻使美元大跌，就经常被认为是“信号效应”成功的例子。
万瑞士法郎后，美元继续上升，对马克的汇价又上升1%，对瑞士法郎的汇价也上升到1.567。（www.61k.com)在针对日元的干预动用了500万美元之后，美元对日元的汇价也跌至187.5日元。在这一天外汇市场收市时，美元对主要外汇的汇价平均上升了7%—10%。
以后美元重新下跌。(www.61k.com]美国联邦储备委员会在3个多小时内分别在美元兑马克的汇率1.4715、
五 : 50Websphere MQ入门经典教程---经典
还Websphere MQ入门经典教程---经典
使用IBM Websphere MQ
提纲
目录
目录................................................................................................................................. 2
前言................................................................................................................................. 9
本书范围................................................................................................................... 9
本书读者................................................................................................................... 9
进一步参考资料 ...................................................................................................... 10
第一部分 Websphere MQ原理和体系结构 .......................................................................11
第一章Websphere MQ原理 .............................................................................................11
目标.........................................................................................................................11
1.1中间件 ................................................................................................................11
1.1.1中间件的优点............................................................................................11
1.1.2中间件的分类........................................................................................... 12
1.2三种通信技术的比较 .......................................................................................... 13
1.3 WebSphere MQ的原理 ....................................................................................... 15
1.4 WebSphere MQ的重要特点 ................................................................................ 16
1.4.1统一接口.................................................................................................. 16
1.4.2处理不依赖时间的限制............................................................................. 16
1.4.3给分布式处理提供的强健的中间件 ........................................................... 16
1.5本章小节 ........................................................................................................... 17
1.6本章练习 ........................................................................................................... 17
第二章Websphere MQ体系结构 ..................................................................................... 18
目标........................................................................................................................ 18
2.1基本概念 ........................................................................................................... 18
2.1.1 WebSphere MQ对象(objects) ..................................................................... 18
2.1.2 消息 ........................................................................................................ 19
2.1.3 队列 ........................................................................................................ 20
2.1.4队列管理器 .............................................................................................. 24
2.1.4通道......................................................................................................... 25
2.1.5进程......................................................................................................... 29
2.1.6群集......................................................................................................... 29
2.1.7名称列表.................................................................................................. 30
2.1.8认证信息对象........................................................................................... 30
2.1.9系统缺省对象........................................................................................... 30
2.1.10 MQI（message queue interface） .............................................................. 30
2.2体系结构 ........................................................................................................... 30
2.2.1 WebSphere MQ和消息排队 ....................................................................... 31
2.2.2 队列管理器的进程 ................................................................................... 32
2.3客户机和服务器 ................................................................................................. 33
客户机－服务器环境中的 WebSphere MQ 应用程序 ......................................... 33
2.4触发机制 ........................................................................................................... 33
2.4.1触发的概念 .............................................................................................. 33
2.4.2触发类型.................................................................................................. 34
2.4.3触发的工作原理 ....................................................................................... 35
2.5 队列管理器群集 ................................................................................................ 36
2.5.1 群集的概念 ............................................................................................. 36
2.5.2 群集的优点 ............................................................................................. 37
2.5.3 群集的组件 ............................................................................................. 38
2.5.4 创建群集 ................................................................................................. 38
2.5.5 实现负载均衡 .......................................................................................... 39
2.5.6 群集管理 ................................................................................................. 40
2.6本章小结 ........................................................................................................... 41
2.7本章练习 ........................................................................................................... 41
第二部分 Websphere MQ系统管理 ................................................................................. 43
第三章WebSphere MQ系统安装 ..................................................................................... 43
目标........................................................................................................................ 43
3.1 规划安装 .......................................................................................................... 43
3.1.1 硬件要求 ................................................................................................. 43
3.1.2 软件要求 ................................................................................................. 44
3.2 安装 WebSphere MQ ......................................................................................... 46
3.2.1 WebSphere MQ 文档 ................................................................................ 46
3.2.2 WebSphere MQ安装 ................................................................................. 47
3.3 验证安装 .......................................................................................................... 49
3.3.1安装验证.................................................................................................. 49
3.3.2测试对象.................................................................................................. 49
3.4 本章小结 .......................................................................................................... 50
3.5本章练习 ........................................................................................................... 50
第四章WebSphere MQ 的管理 ....................................................................................... 51
目标........................................................................................................................ 51
4.1 本地和远程管理 ................................................................................................ 51
4.2 使用命令管理 WebSphere MQ ........................................................................... 51
4.2.1控制命令.................................................................................................. 52
4.2.2WebSphere MQ 脚本（MQSC）命令 ......................................................... 52
4.2.3PCF 命令.................................................................................................. 54
4.3 WebSphere MQ 配置 .......................................................................................... 56
4.3.1在 Windows 系统上更改配置信息 ............................................................ 56
4.3.2 在 UNIX 系统上更改配置信息................................................................ 57
4.4 WebSphere MQ 安全性....................................................................................... 60
管理 WebSphere MQ 的权限 ............................................................................ 60
使用WebSphere MQ 对象的权限 ...................................................................... 61
4.5 WebSphere MQ 事务性支持................................................................................ 61
4.6 WebSphere MQ 死信队列处理程序 ..................................................................... 62
4.7本章小结 ........................................................................................................... 62
4.8本章练习 ........................................................................................................... 63
第五章WebSphere MQ 控制命令 .................................................................................... 64
目标........................................................................................................................ 64
5.1 如何使用控制命令 ............................................................................................ 64
WebSphere MQ 对象的名称 .............................................................................. 64
5.2 控制命令 .......................................................................................................... 65
控制命令集 ...................................................................................................... 65
控制命令举例................................................................................................... 66
5.3 本章小结 .......................................................................................................... 66
5.4本章练习 ........................................................................................................... 66
第六章WebSphere MQ 互连通信 .................................................................................... 68
目标........................................................................................................................ 68
6.1基本概念 ........................................................................................................... 68
6.1.1 什么是互连通信 ...................................................................................... 68
6.1.2 分布式队列组件 ...................................................................................... 72
6.1.3 死信队列 ................................................................................................. 75
6.1.4怎样到达远程队列管理器 ......................................................................... 75
6.2 实现应用程序通信 ............................................................................................ 77
6.2.1发送消息到远程队列管理器...................................................................... 77
6.2.2触发通道.................................................................................................. 79
6.2.3消息的安全性........................................................................................... 80
6.2.4 WebSphere MQ对象配置实例 ................................................................... 81
6.3通道的维护 ........................................................................................................ 83
6.3.1通道的状态 .............................................................................................. 83
6.3.2通道维护命令........................................................................................... 84
6.3.3设置MaxChannels和MaxActiveChannels属性........................................... 88
6.4配置侦听程序 .................................................................................................... 88
6.4.1 Windows 平台 .......................................................................................... 88
6.4.2 unix 平台 ................................................................................................. 88
6.5本章小结 ........................................................................................................... 89
6.6本章练习 ........................................................................................................... 89
第七章 WebSphere MQ 恢复和重新启动......................................................................... 90
目标........................................................................................................................ 90
7.1 WebSphere MQ的数据日志 ................................................................................ 91
7.1.1日志的概念 .............................................................................................. 91
7.1.2日志控制文件........................................................................................... 91
7.1.3日志类型.................................................................................................. 92
7.1.4计算日志的大小 ....................................................................................... 92
7.2 使用数据日志进行恢复 ..................................................................................... 93
7.2.1从掉电或通信故障中恢复 ......................................................................... 94
7.2.2恢复受损对象........................................................................................... 94
7.3保护 WebSphere MQ 日志文件 .......................................................................... 96
7.4备份和恢复 WebSphere MQ................................................................................ 96
7.4.1备份 WebSphere MQ ................................................................................ 96
7.4.2恢复 WebSphere MQ ................................................................................ 96
7.5恢复方案 ........................................................................................................... 97
7.5.1磁盘故障.................................................................................................. 97
7.5.2受损的队列管理器对象............................................................................. 98
7.5.3受损的单个对象 ....................................................................................... 98
7.5.4自动媒体恢复故障.................................................................................... 98
7.6使用 dmpmqlog 命令转储日志........................................................................... 98
7.7本章小结 ..........................................................................................................101
7.8本章练习 ..........................................................................................................102
第八章 WebSphere MQ 问题诊断 ..................................................................................102
目标.......................................................................................................................102
8.1错误日志 ..........................................................................................................102
8.1.1日志文件.................................................................................................103
8.1.2忽略WebSphere MQ for Windows的错误代码 ...........................................104
8.1.3操作信息.................................................................................................104
8.2死信队列 ..........................................................................................................104
8.3配置文件和问题确定 .........................................................................................104
8.4跟踪 .................................................................................................................104
8.4.1WebSphere MQ Windows的跟踪................................................................104
8.4.2WebSphere MQ AIX的跟踪 .......................................................................106
8.5首次故障支持技术（FFST） .............................................................................109
8.5.1FFST: WebSphere MQ Windows 版 ............................................................109
8.5.2FFST: WebSphere MQ UNIX 系统版.......................................................... 110
8.6本章小结 .......................................................................................................... 112
8.7本章练习 .......................................................................................................... 112 第三部分 Websphere MQ 应用开发 ............................................................................... 113
第九章 设计Websphere MQ应用程序............................................................................ 113
目标....................................................................................................................... 113
9.1介绍应用设计 ................................................................................................... 113
9.1.1 规划设计 ................................................................................................ 113
9.1.2 WebSphere MQ 对象 ............................................................................... 113
9.1.3 设计消息 ................................................................................................ 114
9.1.4 WebSphere MQ 技术 ............................................................................... 114
9.1.5应用编程................................................................................................. 115
9.1.6 测试应用程序 ......................................................................................... 116
9.2 WebSphere MQ消息 .......................................................................................... 116
9.2.1消息描述符 ............................................................................................. 116
9.2.2消息种类................................................................................................. 116
9.2.3消息控制信息和消息数据的格式.............................................................. 117
9.2.4消息优先级 ............................................................................................. 117
9.2.5消息组 .................................................................................................... 118
9.2.6消息持久性 ............................................................................................. 118
9.2.7检索消息................................................................................................. 119
9.2.8交付失败的消息 ...................................................................................... 119
9.3本章小结 .......................................................................................................... 119
9.4本章练习 .......................................................................................................... 119
第十章 用MQI编程 ..................................................................................................... 119
50Websphere MQ入门经典教程---经典_websphere 教程
目标....................................................................................................................... 119 10.1概述................................................................................................................ 119 10.2 平台和语言 ....................................................................................................120 10.3 库和存根模块程序..........................................................................................121 10.4 体系结构模型.................................................................................................122 10.5 用MQI编程 ....................................................................................................124
10.5.1 基本API概念.......................................................................................125 10.5.2 连接到队列管理器 ................................................................................126 10.5.3 打开WebSphere MQ对象 ......................................................................127 10.5.4 关闭WebSphere MQ对象 ......................................................................130 10.5.5 断开与队列管理器的连接......................................................................130 10.5.6 将消息放入队列....................................................................................131 10.5.7 从队列获取消息....................................................................................133 10.5.8 从队列浏览消息....................................................................................135 10.5.9查询对象属性 ........................................................................................136 10.5.10设置对象属性 ......................................................................................138 10.5.11 MQI中的事务处理...............................................................................139 10.5.12 MQI中的消息分组...............................................................................140 10.6本章小结.........................................................................................................142 10.7本章练习.........................................................................................................142 第十一章 用 C++ API编程 ...........................................................................................143
目标.......................................................................................................................143 11.1 概述...............................................................................................................143 11.2 平台和语言 ....................................................................................................144 11.3库 ...................................................................................................................144 11.4体系结构模型..................................................................................................145 11.5用C++ API编程..............................................................................................146
11.5.1连接到队列管理器 .................................................................................147 11.5.2打开WebSphere MQ对象 .......................................................................147 11.5.3 关闭WebSphere MQ对象 ......................................................................148 11.5.4 断开与队列管理器的连接......................................................................148 11.5.5 消息放入队列 .......................................................................................148 11.5.6从队列获取消息.....................................................................................150 11.5.7浏览队列上的消息 .................................................................................153 11.5.8查询并设置对象属性..............................................................................153 11.5.9事务处理管理 ........................................................................................155 11.5.10消息分组 .............................................................................................155 11.6本章小结.........................................................................................................157 11.7本章练习.........................................................................................................157 第十二章 用Java编程 ..................................................................................................158
目标.......................................................................................................................158 12.1 概述...............................................................................................................158 12.2 平台...............................................................................................................158
12.2.1 获得软件包...........................................................................................158
12.2.2 WebSphere MQ for Java的运行环境 ........................................................159 12.3 使用WebSphere MQ for Java ...........................................................................161
12.3.1客户机连接模式 ....................................................................................161 12.3.2绑定模式 ...............................................................................................162 12.3.3 类库 .....................................................................................................162 12.4用WebSphere MQ Java API开展工作 ..............................................................164
12.4.1 设置连接 ..............................................................................................164 12.4.2 打开队列 ..............................................................................................165 12.4.3 处理WebSphere MQ消息 ......................................................................166 12.5应用程序开发..................................................................................................167
12.5.1简单的消息发送器应用程序 ...................................................................168 12.5.2简单的消息接收应用程序 ......................................................................170 12.5.3请求/回复 ..............................................................................................172 12.5.4回复应用程序 ........................................................................................175 12.5.5消息分组 ...............................................................................................177 12.5.6简单的组接收应用程序 ..........................................................................180 12.6本章小结.........................................................................................................183 12.7本章练习.........................................................................................................183 第十三章 用ActiveX编程.............................................................................................183
目标.......................................................................................................................183 13.1 概述...............................................................................................................183 13.2 平台和语言 ....................................................................................................184 13.3 库 ..................................................................................................................185 13.4 架构模型........................................................................................................185 13.5 用WebSphere MQ automatin classes for ActiveX编程 .......................................186
13.5.1 连接到队列管理器 ................................................................................186 13.5.2 打开WebSphere MQ对象......................................................................187 13.5.3 基本操作 ..............................................................................................189 13.5.4 关闭对象 ..............................................................................................191 13.5.5 关闭连接 ..............................................................................................192 13.6 事务处理管理.................................................................................................192 13.7 分组...............................................................................................................195 13.8 本章小结........................................................................................................195 13.9本章练习.........................................................................................................195 第十四章 用AMI编程 ..................................................................................................195
目标.......................................................................................................................195 14.1 概述...............................................................................................................196 14.2 平台和语言 ....................................................................................................198 14.3 库和包 ...........................................................................................................199 14.4 体系结构模型.................................................................................................201 14.5 用AMI编程...................................................................................................202
14.5.1 连接到队列管理器 ................................................................................202 14.5.2 打开WebSphere MQ对象......................................................................204 14.5.3 基本操作 ..............................................................................................208
14.5.4 删除会话并关闭连接.............................................................................212 14.6 AMI和MQI的比较 ........................................................................................213 14.7 事务处理管理.................................................................................................213 14.8 分组...............................................................................................................215 14.9本章小结.........................................................................................................215 14.10本章练习 .......................................................................................................215 附录一 WebSphere MQ的缺省系统对象 ........................................................................215
今天，大多数企业都希望他们的硬件和软件提供者不只受限于一家厂商，相反，大家普遍认为应当面向多家厂商能够运行多种软件的多种硬件平台，这些硬件平台既可以是大型机，也可以是笔记本计算机。其中包括传统的中央集中式系统，通常指大型企业所采用的大型机，部门级小型计算机和个人用个人计算机或工作站。通常这些平台是在“混乱”中发展起来的，当时它们的成长既有独立性又有偶然性。
混乱造成的结果是由企业“玻璃房子”控制的清静、秩序井然的世界退化成了一个个独立而分散的部门，并要求任务能够满足其独立而分散的需求。有些公司一直在寻求一种成熟的策略，以便在企业范围内扩展应用和数据，使其距最终用户最近。这种需求在设计时，存在许多限制，因为目前的交互式主要是同步形式，它要求对方一直处于通讯状态，这必然会大大增加网络代价。
目前，许多企业都是由一些相对于整体业务问题而孤立的解决方案所组成的自动化孤岛。在信息共享的大环境下，如果能在这些孤岛之间架起桥梁，那么效率和利润都将得到提高。从我们与不同行业客户与服务提供者广泛接触的经验来看，这种沟通非常必要，而且正变得越来越重要。
有些公司已经找到了连接网络若干个部分的解决方案，它们或者是自行开发的或者只有较窄的应用领域。如IBM用户事务处理的CICS就有这样的连接功能，但数据处理软件的设计、维护和开发通常都非常昂贵。因此需要一种通用软件，它能够集成多个运行于供应商所提供的系统上的应用程序。这种软件不仅成本不高，而且可以可靠地处理很高的吞吐量，消息中间件正是解决这种互连问题的解决方案。
商业消息中间件的出现保证了消息传输的可靠性，高效率和安全性，同时也减少了系统的开发周期。目前应用最多的消息中间件产品为IBM Websphere MQ。本文就针对Websphere MQ的体系结构、管理和开发进行详细的阐述，希望对读者有所帮助。 本书范围
全书共分为3部分共14章，第一部分 WebSphere MQ原理和体系结构，分为两章；第二部分 WebSphere MQ系统管理，分为六章，分别介绍安装、配置、管理、控制命令和问题确定；第三部分 WebSphere MQ应用开发，由五章组成，介绍程序设计、编写和例子程序。
本书读者
本书是WebSphere MQ产品的实用指南，所以至少对两种读者有益，一种是WebSphere MQ产品的初学者，本书能成为指导性资料；另一种是WebSphere MQ的系统管理员和开发者。
进一步参考资料
《WebSphere MQ System Administration Guide》 《Application Messaging Interface》
《Application Programming Guide》
《Application Programming Reference》
《WebSphere MQ Clients》
《Event Monitoring》
《Intercommunication》
《Programmable Command Formats and Administration Interface》 《Queue Manager Clusters》
《Script (MQSC) Command Reference》
《Using C++》
《Using Java》
上述书籍均可到以下网址下载：
http://www-3.ibm.com/software/ts/WebSphere MQ/library/manuals/
第一部分 Websphere MQ原理和体系结构
第一章Websphere MQ原理
目标
1， 了解什么是中间件，以及中间件的特点。
2， 介绍WebSphere MQ的原理。
3， 介绍WebSphere MQ的特性和优点。
1.1中间件
中间件处于应用软件和系统软件之间，是一种以自己的复杂换取企业应用简单化的可复用的基础软件。在中间件产生以前，应用软件直接使用操作系统、网络协议和数据库等开发，开发者不得不面临许多很棘手的问题，如操作系统的多样性，繁杂的网络程序设计和管理，复杂多变的网络环境，数据分散处理带来的不一致性，性能和效率、安全问题等等。这些问题与用户的业务没有直接关系，但又必须解决，耗费了大量有限的时间和精力。于是，有人提出将应用软件所要面临的共性问题进行提炼、抽象，在操作系统之上再形成一个可复用的部分，供成千上万的应用软件重复使用。这一技术思想最终形成为了中间件产品。
从技术上讲，中间件是介于应用系统和系统软件之间的一类软件，它使用系统软件所提供的基础服务（功能），衔接网络上应用系统的各个部分或不同的应用，能够达到资源共享、功能共享的目的。
1.1.1中间件的优点
1?应用开发：The Standish Group分析了一百个关键应用系统中的业务逻辑程序、应用逻辑程序及基础程序所占的比例，发现了一个有趣的平均百分比，其中，业务逻辑程序、应用逻辑程序仅占总程序量的30%，而基础程序却占了70%!若是以新一代的中间件系列产品来组合应用，同时配合以可复用的商务对象构件，则应用开发费用可节省至80%。
2?系统运行：没有使用中间件的应用系统，其初期投入的资金及运行费用要比同规模的使用中间件的应用系统多一倍。
3?开发周期：时间限制是所有应用系统开发项目的天敌，而基础软件的开发又是一件极耗时的工作，若使用标准商业中间件则可缩短开发周期50-75%。
4?减少项目开发风险：The Standish Group对项目失败的定义是：项目中途夭折、费用远远超过预算、无法准时完成项目和偏离既定的目标。研究表明，没有使用标准商业中间件的关键应用系统开发项目的失败率高于90%。而且，企业自己开发内置的基础(中间件)软件是得不偿失的，项目总的开支至少要翻一倍，甚至会十几倍。
5?合理运用资金：借助标准的商业中间件，企业可以很容易地在现有或遗留系统之上或之外增加新的功能模块，并将它们与原有系统无缝集合。
6?应用集合：依靠标准的中间件可以将现有的应用、新的应用和购买的商务构件融合在一起。
7?系统维护：每年维护自我开发的基础(中间件)软件的开支是当初开发费用的15%至25%，每年应用程序的维护开支也还需要当初项目总费用的10%至20%。
8?质量：基于企业自我建造的基础(中间件)软件平台上的应用系统，每增加一个新的模块，就要相应地在基础(中间件)软件之上进行改进。The Standish Group在调研过程中，曾在某个企业中的一个应用系统里，发现了有多达1万7千多个模块接口，而标准的中间件在接口方面都是清晰和规范的，可以有效地保证应用系统质量及减少新旧系统维护开支。
9?技术革新：企业对自我建造的基础(中间件)软件平台的频繁革新是不容易实现的，也是不实际的，而购买标准的商业中间件，则对技术的发展与变化可以极大地增强其适应性。
10?增加产品吸引力：不同的商业中间件提供有不同的功能模型，合理地使用，可以让用户的应用更容易增添新的表现形式与新的服务项目，从而使得企业的应用系统更完善、更出众。
1.1.2中间件的分类
1.2三种通信技术的比较
(1) CPI-C
CPI-C是一个同步的对话通信模式。参加通信的某一程序发起一次对话，并控制信息的流动，如图，1.2。发起者可随后向对方发送数据，而对方可接收数据，数据也可反向流动。
图1.2 使用CPI-C基于连接的同步通信
参加通信的程序必须跟踪对话的状态，以备故障发生时作恢复连接用。在对话过程中两个程序都必须同时参加对话。如果由于某种原因造成连接断开，由连接建立者重建并恢复这次对话。这给应用程序增加了连接的负担。通信双方也可处于对等地位，在程序开始时确定了谁是对话的发起者，并保存下去，也可改变这种关系，但必须在该对话完成之后。这意味着CPI-C既支持客户——服务器环境也支持对等通信方式。
前面提到，CPI-C是一种同步通信模型，但在某些事务处理环境的支持下，CPI-C
可以实现一定程度的异步，在CICS环境中这种支持是通过“临时数据队列”这种技术实现的。
在这以前，只有SNA协议支持CPI-C，现在TCP/IP和SNA都支持CPI-C。
由于应用程序必须参与对错误的处理和恢复，所以CPI-C的编程接口相当复杂。
（2）RPC
（RPC）远程过程调用也是一种同步的、对话方式的模型，如图1.3。一个调用程序向服务器提出申请，该调用被一个负责通信的转接器发向远端系统。调用者和被调用者关系是固定的，很难实现对等通信。和CPI-C一样，由应用程序处理错误，并且在申请的服务得到响应之前，服务申请者被阻塞。
如图1.3 使用RPC，基于连接的同步通信
（3）MQI(Message Queue Interface)
如图1.4消息队列接口为程序提供了一种异步通信方式。一个程序以一个队列作为中转与另一个程序相互通信，这个队列相对于该程序而言既可是本地的也可以是远程的。当程序A需要和程序B通信时，A只需PUT一条消息到一个和B相联系的队列上，程序A然后可以干别的事。它似乎感觉不到通信的发生，通信以及对通信错误的恢复是由队列管理完成的。
图1.4 使用MQI，基于队列的异步通信 通信的方式和使用的传送协议无关。因为应用程序感觉不到通信的发生，因而可以使用各种标准协议，比如TCP/IP,SNA或者其他局域网协议。
当程序A通过向某一队列PUT一条消息来申请程序B的服务时，程序B不一定必需在运行。而且一个程序可以通过向不同的队列PUT消息来实现与多个程序的通信。
最后，应该把MQI看作是其它通信方式所缺乏的功能的一个必要补充。每种通信
方式都有其优点、缺点和适用范围。
1.3 WebSphere MQ的原理
Websphere MQ是IBM的商业通讯中间件(Commercial Messaging Middleware)。Websphere MQ提供一个具有工业标准、安全、可靠的消息传输系统。它的功能是控制和管理一个集成的商业应用，使得组成这个商业应用的多个分支程序(模块)之间通过传递消息完成整个工作流程。Websphere MQ基本由一个消息传输系统和一个应用程序接口组成，其资源是消息和队列(Messaging and Queuing)。
消息：消息就是一个信息单元，这个信息单元可以是一个请求（Request message），也可以是一个应答(Reply message)，或者是一个报告(Report message)或一份报文(Datagram messge)。一个消息包含两个因素——消息描述(用于定义诸如消息传输目标等)和数据消息(如应用程序数据或数据库查询等)。程序之间的通信消息而非直接调用程序。
队列:一个安全的存储消息的地方，消息的存储一般是顺序的，队列是消息分阶段地传送和接收。因为消息存放在队列中，所以应用程序可以相互独立的运行，以不同的速度，在不同的时间，在不同的地点。
消息传输系统：用于确保队列之间的消息提供，包括网络中不同系统上的远程队列之间的消息提供。并保证网络故障或关闭后的恢复。
应用程序接口：应用程序和消息系统之间通过Websphere MQ API实现的接口Websphere MQ API在所有Websphere MQ平台上是一致的。API只有14个调用，2个关键动词：发送(PUT)和接收(GET)。
如图所示：虽然应用程序A和应用程序B运行于同一系统A，它们不需要直接的通讯。应用程序A向队列1发送一条消息，而当应用程序B需要时就可以得到该消息。
如果消息传输的目标改为在系统B上的应用程序C，这种变化不会对应用程序A产生影响，应用程序A向队列Q2发送一条消息，系统A的Websphere MQ发现Q2实际上在系
统B，它将消息放到本地的一个特殊队列－传输队列(Transmission Queue)。系统A的Websphere MQ然后建立一条到系统B通讯联接，传递这条消息到系统B，并等待确认。只有Websphere MQ接到系统B成功地收到消息的确认后，才从传输队列中移走消息。如果通讯线路不通，或系统B不在运行，消息会留在传输队列中，直到被成功地传送到目的地。这是Websphere MQ最基本而最重要的技术—可靠消息传输。
事实上，Websphere MQ具有特殊的技术防止消息重复传送，确保消息一次且仅一次(once-and-only-once)传递。
1.4 WebSphere MQ的重要特点
WebSphere MQ提供给用户许多难得的价值。
1.4.1统一接口
跨越IBM和非IBM平台。简单的?PUT?和?GET?动词在WebSphere MQ支持35种IBM和非IBM平台上完全相同。使得WebSphere MQ提供了这样的特性：目标应用程序位置的透明性(targetapplicationlocationtransparency)。对于一个应用程序的开发者，他需要知道的全部只是队列的名字，这个队列与一个特定的服务有关，而与系统的平台或系统在什么地方无关。
使开发人员避开网络的复杂性。因为WebSphere MQ负责处理所有的通讯，开发人员不必编写任何通讯方面的程序。并且编程和调试非常简单和直接，不需要具体的系统和通讯方面的知识。尤其在开发客户机/服务器模式的应用时，开发人员可以集中精力在与业务有关的客户端和服务器端的应用，而不必考虑操作系统和通讯，特别是底层的网络通讯，节省大约50%到75%of通讯编程工作。
1.4.2处理不依赖时间的限制
意思是说在信息创建和发送时，信息的接收方或到接收方的通道不需要激活.不受时间的限制增加了处理的灵活性，允许事务处理在它们想做或有时间做时。彼此通讯程序可以运行在不同的时间。这样程序的运行是独立的，如果逻辑允许，它们不必等待其它程序的应答而继续工作,利用这种异步处理功能，可以更有效的使用资源，更灵活的处理模式，应用处理可以是独立的，并行的，重叠的，从而改进用户服务。
1.4.3给分布式处理提供的强健的中间件
包括逻辑工作单元支持(logicalunitofwork),备份和恢复机制，大信息传递和高性能等特点。其中最重要的是确保信息传输，意思是一旦WebSphere MQ接受一个信息传输的任务,会确保信息被传送到目标平台。信息的传输是一次且仅一次.另外，强健的中间件机制保证业务数据一致性，并可在系统发生故障时，及时恢复，业务不会受到影响。
1.5本章小节
WebSphere MQ是基于消息队列（Message Queuing）或消息传送（Message passing）的中间件，主要功能是在应用程序之间传送消息，这些消息可以在不同的网络协议、不同的计算机系统和不同的应用软件之间传递。通过使用WebSphere MQ用户可以简单方便的开发出可靠、高效的分布式应用系统。
总之，WebSphere MQ的技术可实施在广泛的IBM和非IBM平台上，WebSphere MQ提供了一个面向业务的信息技术架构:基于WebSphere MQ的应用程序可以更接近的模拟商业问题，更容易设计，开发和维护。这种技术使得基于WebSphere MQ的应用无结构限制，应用程序之间可以是一对一的关系，也可以是一对多的关系，多对多的关系。应用程序之间的信息传递可以是单向，也可以是双向的。灵活的结构支持平衡工作负荷，并行处理，多路广播以及其它应用程序之间的关系。总之是应用程序可以充分接近业务需求，并且当应用需求改变时，WebSphere MQ的结构可以很容易的跟着改变。
1.6本章练习
1.什么叫中间件？
2.请比较三种通信技术。
3.介绍IBM WebSphere MQ的原理。
4.下列那些是IBM WebSphere MQ的特性？
(1) 不需要TCP/IP。
(2) 要求发送和接收程序同时运行。
(3) 当一个消息到达队列时，可以启动应用程序。
(4) 支持不同平台之间的异步处理。
(5) 是与时间相关的分布式处理。
答案：（3）（4）
5.当一个消息到达队列时自动启动了处理程序，这个特征是：
（1） 触发(triggering)
（2） 激发(firing)
（3） 信号(signaling)
（4） 自动启动(auto-start)
答案：（1）
第二章Websphere MQ体系结构
4， 了解WebSphere MQ的对象。
5， 描述WebSphere MQ的体系结构。
6， 学习WebSphere MQ的客户机和服务器。
7， 理解WebSphere MQ的触发机制。
8， 学习使用WebSphere MQ的队列管理器群集。
2.1基本概念
2.1.1 WebSphere MQ对象(objects)
?
? WebSphere MQ对象是一种由WebSphere MQ管理的具有可恢复能力的资源。在本书中队列管理器（Queue managers） 队列（Queues） 名字列表（Namelists） 分发列表（Distribution lists） 进程定义（Process definitions） 通道（Channels） 存储类（Storage classes） 描述的许多任务都和下列对象相关：
这些对象在异种平台上都是统一的。对于系统管理员来说，操纵对象的命令都是可用的。这些命令格式，对于不同平台是有区别的。当你创建队列管理器时，会自动地创建缺省对象。这些缺省对象可以帮助您来定义所需的对象。
每一个对象都有一个名字，以便通过命令和MQI调用可以引用它。通常在这些对象类型中的每一种对象的名字必须唯一。例如，一个队列和一个进程的名字可以相同，但是不可以有两个相同名字的队列。这意味着一个本地队列名不能和模板队列、远程队列或别名队列相同。但是也会有些特殊情况。另外在互连的队列管理器网络中，队列管理器名必须唯一。 WebSphere MQ的对象名是大小写敏感的，因此在定义对象时，需要仔细选择好大小写字母。在 WebSphere MQ 中，除最多有 20 个字符的通道之外，名称最多可以有 48 个字符。
2.1.2 消息
消息是对使用它的应用程序有意义的以字节为单位的字符串。消息可以用来实现在相同或不同平台上应用程序间的通信。
WebSphere MQ 消息由两个部分：
应用程序数据。
应用程序数据的内容和结构由使用它的应用程序定义。
消息描述符。
消息描述符标识消息，并包含其它控制信息，如消息类型和消息的优先级，如图所示：
图，消息结构
消息描述符的格式由 WebSphere MQ 定义。有关消息描述符的完整描述，参看《WebSphere MQApplication Programming Reference》。
2.1.2.1消息的类型
WebSphere MQ定义了四种基本类型的消息。应用程序可以定义其他类型的消息。四种基本类型是：
? 请求消息 Request message
请求消息需要应答。从客户端发往服务器的查询和更新信息往往是一条请求消息。请求消息中应该包含回复消息的路由信息，即回复消息发往什么地方。
? 回复消息 Reply message
回复消息是对请求消息的回应。请求消息中的信息决定了回应消息的目的地。处理请求和回应的应用程序控制着消息间的关联，这种关联和队列管理器没有关系。消息自身带有足够的信息供应用程序实现这种关联。
? 报文消息 Datagram message 数据报消息是不需要回复的消息，报文消息只是一次单向的信息传送。 报告消息 Report message。
报告消息用于对一些系统故障的响应。有些报告消息是由应用程序创建的，有些报告消息是由队列管理器创建的。后一种情况是由于远程队列已经满或者远程队列不存在引起消息不能正确发送。最初发送者条消息的应用程序不能检测到这种错误，只有等远程队列管理器创建了这样一条报告消息并发往本地队列管理器之后，应用程序才能作相应的处理。
队列管理器把报告消息也用于其他目的，比如报告一些事件。消息可能有一个失效时间限制。如果一条消息在失效时间过后还没有被某个应用程序处理，该条消息将被队列管理器从系统中清除。当队列管理器清除一条失效消息之后，它将创建一条报告消息，
这条报告消息的目的地址由失效消息提供。
报告消息的另一个用途是确保消息的到达。应用程序可以要求它们所发送的消息到达目的地后，他们收到一条报告消息，这叫做接收确认（Confirmation of arrival）。与此相类似，应用程序也可以要求当另外一个程序取走这条消息时它们收到一条报告消息，这被叫做交付确认（Confirmation of delivery）。这两种情况，都是由队列管理器创建报告消息，并把报告消息发送到适当地目的地。
另外还一类特殊的消息叫触发消息。触发消息是由队列管理器创建的一类特殊消息。WebSphere MQ的队列管理器提供了一种当满足某一条件时，自动触发应用程序的机制，而触发消息是触发机制的重要组成部分。
应用程序也可以定义新的消息类型。队列管理器不能解释这些类型，应用程序设置的消息类型由一个范围。这些类型值可用来区分不同类型的应用程序在同一个输入队列 中放入的消息。
2.1.2.2消息长度
最大消息长度为 100 MB（其中 1 MB 等于 1 048 576 字节），缺省最大消息长度是 4 MB。实际上，消息长度受以下方面的影响：
? 接收队列定义的最大消息长度 队列管理器定义的最大消息长度 传输队列定义的最大消息长度 发送或接收应用程序定义的最大消息长度 存储消息的可用空间
所以有时可能需要由多个消息组成的信息才能满足应用程序的要求。
2.1.2.3应用程序如何发送和接收消息？
应用程序使用 MQI 调用来实现发送和接收消息。
例如，要将消息放入队列，应用程序：
1. 通过发出 MQI MQOPEN 调用打开所需的队列
2. 发出 MQI MQPUT 调用以将消息放入队列
另一个应用程序可以通过发出 MQI MQGET 调用，从同一队列取出消息
2.1.3 队列
队列是用于存储消息的数据结构,目前WebSphere MQ 版本 5.3 支持超过 2 GB 大小的队列。
2.1.3.1队列的类型
按创建方法分类
? 预定义队列由管理员使用相应的 MQSC 或 PCF 命令创建。 预定义队列是永久的；它们的存在与应用程序是否实用它们无关，并且 WebSphere MQ 重新启动后继续存在。
? 动态队列在应用程序发出设定模型队列名的MQOPEN调用时创建的。被创建的队列是基于一个模板队列。 您可以使用 MQSC 命令 DEFINE QMODEL 创建模板队列。动态队列继承了模板队列的属性。模板队列有一个属性可以说明动态队列是永久的还是临时的。永久队列在应用程序和队列管理器重新启动后继续存在；临时队列在重新启动后消失。
按功能分类
1. 本地队列（local queue）：
一个本地队列是一个物理上位于本地队列管理器中的队列。本地队列实际上存在与本地系统的内存或磁盘存储终。本地队列管理器控制队列的访问。
应用程序可以“PUT”消息到本地队列，也可以从本地队列“GET”消息，另外程序还可以查询或修改这些队列的某些属性。对队列属性的修改需要相应的权限。
2. 远程队列（remote queue）：
一个远程队列属于一个不与该应用程序直接相连的队列管理器。对这类队列的访问包含有本地队列管理器和远程队列管理器的通信过程。这种通信涉及到通道。
应用程序可对远程队列进行某些操作，比如程序可以向一个远程队列放一条消息，但程序不能从远程队列中去消息。应用程序只能从本地队列读取消息。
应用程序有两种不同的方法可用来访问远程队列。第一种是当程序打开一个远程队列时同时提供队列管理器名和队列名两个参数。这要求程序知道目的队列属于哪个队列管理器。第二种方法是在本地队列管理器上存在一个远程队列的定义，这个定义包含有足够的信息让本地队列管理器确定该远程队列所在的队列管理器。
远程队列定义中的目的队列不一定是远程队列管理器的本地队列，它也可以是一个远程队列定义，如图所示。
应用程序放一条消息到Q1，Q1是本地队列管理器QM1上的一个远程队列定义：Q2 at 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（program command format）的消息的队列。该队列主要用于编写管理程序时使用。具体的使用将在后续章节介绍。在创建队列管理器时将为每个队列管理器自动创建命令队列。
9. 回复队列
当应用程序发送请求消息时，接收消息的应用程序可以将回复消息发送给发送应用程序。此回复消息放入一个称为回复队列的队列中，它通常是发送应用程序的本地队列。回复队列的名称由作为消息描述符一部分的发送应用程序指定。
10. 别名队列
别名队列实际上是本地队列、远程队列定义或队列名表的另外一个名字。它是一种简单的名字到名字的映射，它允许应用程序用另外一个名字来访问队列。WebSphere MQ已经为
应用程序屏蔽了许多底层系统细节，特别是网络通信的细节，而别名队列允许在不修改应用程序的条件下访问其他名字的队列。
2.1.3.2定义队列
在WebSphere MQ中可以使用以下方法定义队列：
? 在MQSC命令行中使用DEFINE 在程序中使用PCF创建队列命令
在定义队列时需要指定队列的类型和属性。例如，可以设置队列可存放的消息最大长度，以及队列的最大深度等属性。有关定义队列对象的进一步详细信息，请参阅《WebSphere MQ 脚本（MQSC）命令参考》或《WebSphere MQ Programmable Command Formats and Administration Interface》。
2.1.3.3从队列检索消息
适当授权的应用程序可以根据以下检索算法从队列检索消息：
? 先进先出（FIFO）。 在消息描述符中定义的消息优先级。以 FIFO 为基础检索具有相同优先级的消息。 特定消息的程序请求。
来自应用程序的 MQGET 请求确定所使用的方法。
2.1.4队列管理器
在WebSphere MQ中队列管理器是基本的软件系统，队列管理器可看成是队列和其他对象的容器。WebSphere MQ中的每一个队列都属于一个队列管理器，队列管理器是为应用程序和WebSphere MQ部件（一些管理工具）提供对队列管理中对象的访问。
一个队列管理器是WebSphere MQ中的一个基本的独立的执行单元。一台机器上可以运行一个或多个队列管理器。
任何需要访问WebSphere MQ提供的服务的应用程序都必须先和队列管理器相连，和应用程序相连的队列管理器对该应用程序而言就叫“本地队列管理器”（Local Queue Manager）,本地队列管理器为程序提供MQI调用的支持。应用程序可以操作、管理本地队列管理器所拥有的各种资源，也可以向其他的队列管理器发送消息。
应用程序通过一种叫做MQI的编程接口向队列管理器申请服务。这些服务包括“放”一条消息到队列或从队列“取”一条消息等一些基本操作。队列管理器还使队列成为可靠的存储消息的地方，它也控制安全性管理，并提供一些特殊的队列功能，比如触发队列。
为了减少应用程序对于它所运行环境的依赖性，WebSphere MQ的应用程序可以和一个它不知道名字的队列管理器相连，这个队列管理器就是一台机器上的缺省队列管理器。如果程序在调用MQCONN时，把队列管理器名参数设置为空，MQCONN将返回与缺省的队列
管理器连接的句柄。
队列管理器拥有每个队列。队列管理器负责维护它所拥有的队列，以及将它接收到的所有消息存储到相应的队列。可以由应用程序或队列管理器将消息放入队列，这些是它的正常操作的一部分。
2.1.4通道
2.1.4.1消息通道（Message channels）
消息通道是一种提供从一个队列管理器到另一个队列管理器的通信路径。消息通道用在分布式的队列把消息从一个队列管理器发送到另一个队列管理器。它们使应用程序屏蔽了底层的通信协议。队列管理器可能存在同种或异种平台之间。为了实现队列管理器之间的通信，您必需在一个队列管理器中定义一个发送消息的通道对象，在另一个队列管理器中定义一个接收消息的通道对象。消息通道是一个单向链接。它通过消息通道代理（message channel agents
）把两个队列管理器连接起来。如图所示：
不要和MQI通道（MQI channel）通道混淆。MQI通道有两种类型，分别是服务器连接（server-connection）和客户器连接（client-connection）。
消息通道分类
消息通道的定义可以分为以下6种类型：
发送通道（Sender） 接收通道（Receiver） 服务器通道（Server） 请求器通道（Requester） 群集发送通道（Cluster sender） 群集接收通道（Cluster receiver）
消息通道的组合形式
如果要在队列管理之间实现消息传输，必须要在两个队列管理器上都要定义相应的通道。发送方和接收方通道的组合形式如下：
发送通道-接收通道（Sender-receiver ） 请求器通道-服务器通道（Requester-server） 请求器通道-发送通道（Requester-sender (callback) ） 服务器通道-接收通道（Server-receiver ） 群集发送通道-群集接收通道（Cluster sender –cluster receiver）
注意：通道的组合形式有5种形式，每种组合方式是固定的，用户不能随意组合。每对通道的名称必需相同例如：在发送通道-接收通道组合中，发送通道名和接收通道名必须一致，否则通道将无法启动。
消息通道用法
发送通道-接收通道（Sender-receiver）
图5 发送通道-接收通道
用法：由一个系统的发送通道来启动通道，以便它可以发送消息到另一个系统。发送通道向接收通道发送启动请求。发送通道从传输队列发送消息到接收通道。接收通道把消息放到目标队列。
请求器通道-服务器通道（Requester-server）
用法：
(1)由一个系统中的请求器通道来启动通道，以便它能从另一个系统接收到消息。 请求器通道向通道另一端的服务器通道发送请求来启动。服务器通道从传输队列把消息发送到请求器通道。
(2) 服务器通道也能启动通道，并发送消息到请求器, 但这仅应用于完全意义的服务器通道, 也即服务器通道定义中应含有对方的连接名。一个完全意义的服务器通道可以由请求器通道启动, 也可以发起和服务器通道的通讯。
(3) 最好不要手工去停止Server和Request通道，而是依靠Server通道的Discint的属性来停止通道。
请求器通道-发送通道（Requester-sender (callback)）
用法：请求器通道启动通道，发送通道终止这个会话。 发送通道然后依据它的通道定义中的信息(称为 callback)来重新启动会话。它把消息从传输队列发送给请求器通道。最好不要手工去停止Sender和Request通道，而是依靠Sender 通道的Discint属性来停止通道。
服务器通道-接收通道（Server-receiver）
用法：类似于发送通道-接收通道，但仅应用在完全意义的服务器通道。也即服务器通道定义应含有对方的连接名，通道的启动方是服务器通道。
群集发送通道（Cluster sender）
用法：在一个群集中，每个队列管理器都有一个群集发送通道，通过它可以把送群集信息发送到其中一个队列管理器资源管理器。 队列管理器通过这个通道也可以把消息发送到其他的队列管理器。
群集接收通道（cluster receiver）
功能：在一个群集中，每一个队列管理器都有一个群集接收通道。通过这个通道可以接收数据消息和关于群集的消息。
2.1.4.2 MQI通道
MQI通道是WebSphere MQ 客户端和服务器上的队列管理器的通信的通道。当客户端应用程序发出MQCONN或MQCONNX调用时，才开始建立连接。它是一个双向的通道，可以负责发送和接收，被用作MQI调用的传送和响应。如图所示：
图，MQI通道
一个MQI通道可以把一个客户端连接到单个队列管理器，MQI通道有两种类型，它们定义了双向的MQI通道。
客户端连接通道（Client-connection channel）
这种类型为WebSphere MQ 的客户端所使用。
服务器连接通道（Server-connection channel）
这种类型为运行队列管理器的服务器端所使用，运行在WebSphere MQ 客户端的应用程序将使用这种通道进行通信。
2.1.4.3比较消息通道和MQI通道
消息通道与MQI通道之间的区别可以从两方面进行比较：
? MQI通道是双向的：一个MQI通道可以被用来发送请求，也可用来接收响应。而消息
通道则只能单向数据通信。如果要在两个队列管理器之间实现双向通信，那么需要定义两个消息通道，一个用来实现数据的发送，另一个用来实现数据的接收。
? MQI通道的通信是同步的：当一个MQI请求从客户端发送服务器端时，WebSphere MQ
的客户端在发送下一个请求之间必须要等待来自服务器端的响应。而消息通道，在通道中传输的消息是与时间无关的。大量的消息可以从一个队列管理器发送到另一个队列管理器，发送队列管理器不必等待来自接收队列管理器的任何响应。
2.1.5进程
进程定义对象定义响应 WebSphere MQ 队列管理器上的触发器事件启动的应用程序。进程定义属性包含应用程序标识、应用程序类型和特定于应用程序的数据。
2.1.6群集
在使用分布式排队的传统 WebSphere MQ 网络中，每个队列管理器是独立的。如果队列管理器需要将消息发送到另一个队列管理器，则它必须定义一个传输队列、一个到远程队列管理器的通道，以及它要将消息发送到的每个队列的远程队列定义。
群集是一组以队列管理器可以在不需要传输队列、通道和远程队列定义的情况下在单个网络上彼此直接通信的方法设置的队列管理器。
2.1.7名称列表
名称列表是包含其它 WebSphere MQ 对象列表的 WebSphere MQ 对象。通常，应用程序（如触发器监视器）使用名称列表，它们用于标识一组队列。使用名称列表的优点是它独立于应用程序维护；可以在不停止任何使用它的应用程序的情况下更新它。并且，如果一个应用程序失败，则名称列表不受影响，其它应用程序可以继续使用它。
名称列表还与队列管理器群集一起使用，以维护多个 WebSphere MQ 对象引用的群集列表。
2.1.8认证信息对象
队列管理器认证信息对象（AUTHINFO）组成安全套接字层（SSL）安全性的 WebSphere MQ 支持的部件。它提供使用 LDAP 服务器检查证书撤销列表（CRL）所需的定义。CRL 允许认证中心取消不再可信的证书。
本书描述对认证信息对象使用 setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有关 SSL 概述以及 AUTHINFO 的使用，请参阅 WebSphere MQ Security。
2.1.9系统缺省对象
系统缺省对象是一组每次创建队列管理器时自动创建的对象定义。您可以复制和修改这些对象定义中的任何一个，以在安装时用于应用程序。
缺省对象名具有项 SYSTEM.DEFAULT；例如，缺省本地队列是 SYSTEM.DEFAULT.LOCAL.QUEUE，并且缺省接收方通道是 SYSTEM.DEFAULT.RECEIVER。您无法重命名这些对象；这些名称的缺省对象是必需的。 当您定义对象时，从相应的缺省对象复制您不明确指定的任何属性。例如，如果您定义本地队列，则从缺省队列 SYSTEM.DEFAULT.LOCAL.QUEUE 获取您未指定的那些属性。
请参阅附录1, "系统和缺省对象"以获取有关系统缺省的更多信息。
2.1.10 MQI（message queue interface）
MQI(消息队列接口)有下列组成部分：
? 函数接口：应用程序通过函数可以访问队列管理器和它的部件。
数据结构：应用程序使用提供的数据接口来是实现把数据传递给队列管理器，或从队列管理器中获得数据。 基本数据类型：也是用来实现从队列管理器传递数据，或从队列管理器中获得数据。
2.2体系结构
WebSphere MQ的体系结构如图所示，它是由许多对象所组成的，主要包括队列管理器、
队列、通道、进程定义等对象。队列管理器和DB2数据库中的实例相似，它是有一组MQ进程和一些内存空间所组成的。它实现了应用程序通过MQI调用可以访问MQ的对象。 队列管理器为应用程序提供了排队服务，并管理属于它的队列。它确保：
? 根据接收到的命令更改对象属性。
? 当满足相应条件时，生成特殊事件（如触发器事件或检测事件）。
? 按照发送 MQPUT 调用的应用程序的请求，将消息放入正确的队列。如果不能完成，
则将通知应用程序并给出适当的原因码。
所以在使用WebSphere MQ时，首先需要创建一个队列管理器，然后再队列管理器中在创建队列和通道等其他对象。
图，WebSphere MQ的结构
2.2.1 WebSphere MQ和消息排队
2.2.1.1 WebSphere MQ 和消息排队
WebSphere MQ 使应用程序通过使用消息排队来实现消息驱动处理，使用对应的消息排队软件产品实现在不同平台之间进行通信。从而使应用程序屏蔽了底层的通讯结构。
WebSphere MQ 产品提供了消息队列接口（或 MQI）的公共应用程序编程接口，如果应用程序使用了MQI，将非常容易将应用程序从一个平台移植至另一个平台。
WebSphere MQ 还提供高级别消息句柄 API，它使程序员更容易在企业内或企业间部
署商业流程集成的智能网络。这称为应用程序消息传递接口（AMI）。AMI 将许多通常由消息传递应用程序执行的消息处理功能移动到中间件层，在此将代表应用程序应用企业定义的一组策略。
如需更详细地了解 MQI 和 AMI，请参看《WebSphere MQApplication Programming Reference 》。
2.1.2与时间无关的应用程序
程序不在网络上直接相互通信，而是间接地将消息放入消息队列。因为程序没有直接的联系，所以它们不必同时运行。消息放入适当的队列时目标程序可以是忙的。消息的到达并不影响程序的当前处理，也不意味程序需要立即处理该消息。消息放入队列时接收程序甚至根本不需要正在运行。接收程序可以在需要的时候开始执行。
2.1.3消息驱动处理
当消息到达队列时满足了触发条件，它们可以使用自动触发应用程序。
2.2.2 队列管理器的进程
图，队列管理器进程
启动了队列管理器之后，将会启动一组进程（如上图所示），现以unix平台为例，简单介绍一些进程的功能：
? 以amqc开头的进程是和通道相关的进程。
amqhasmx进程是负责记录日志的进程(Logger)。 amqharmx进程是负责日志格式化。(仅在线性日志中使用)。 amqzllp0进程是检查点处理器(Checkpoint processor)。 amazlaa0进程本地队列管理器的代理（Local queue manager agents）。 amqzxma0进程是执行控制器（ Execution controller）。
2.3客户机和服务器
WebSphere MQ 支持其应用程序的客户机－服务器配置。 WebSphere MQ客户端通过MQI通道与WebSphere MQ服务器进行通讯。
WebSphere MQ 客户机是允许在系统上运行的应用程序对在另一个系统上运行的队列管理器发出 MQI 调用的组件。此调用的输出发送回客户机，此客户机将其输出传送回应用程序。
WebSphere MQ 服务器是为一个或多个客户机提供排队服务的队列管理器。所有 WebSphere MQ 对象，例如，仅存在于队列管理器机器（WebSphere MQ 服务器机器）而不存在于客户机的队列。WebSphere MQ 服务器还可以支持本地 WebSphere MQ 应用程序。 WebSphere MQ 服务器和普通队列管理器之间的差异是服务器与每个客户机有专用通信链路。要获取有关创建客户机和服务器的通道的更多信息，请参阅《WebSphere MQ Intercommunication》。
要获取有关客户机支持的信息，请参阅 《WebSphere MQ 客户机》。
客户机－服务器环境中的 WebSphere MQ 应用程序
当连接到服务器时，客户机 WebSphere MQ 应用程序可以与本地应用程序相同的方法发出大多数 MQI 调用。客户机应用程序发出 MQCONN 调用，以连接到指定的队列管理器。然后此队列管理器处理指定从连接请求返回的连接句柄的任何其它 MQI 调用。 您必须将您的应用程序链接到相应的客户机库。请参阅 《WebSphere MQ 客户机》 一书，以获取进一步信息。
2.4触发机制
2.4.1触发的概念
队列管理器把某种条件叫做触发事件，如果队列被设置为触发类型并且触发事件发生了，队列管理器发送触发消息到一个叫做启动队列的队列中，触发消息被放置到启动队列过程意味着产生了触发事件。
由队列管理器产生的触发消息不是永久性消息，这将减少日志工作量（因此提高性能），并最小化系统重启时间。
处理启动队列中的消息叫做触发监控程序（trigger-monitor application）,他的工作是读
取触发消息并根据触发消息的信息作出相应的处理。通常将启动别的应用程序来处理产生触发消息的队列。从队列管理器来看，触发监控程序没有什么特殊的，它只是一个从启动队列读取消息的应用程序。
如果队列被设置成触发形式，你可以选择创建一个进程定义（process-definition）的对象，这个对象包含了一个应用程序名，这个应用程序用来处理引起触发事件的消息。如果创建了进程对象，队列管理器将把应用程序名包含在触发消息中，以便触发监控程序可以使用。进程对象名需要在本地队列的ProcessName的属性中设置。每个队列可以配置一个进程对象，或几个队列可以共享同一个进程对象。
对于所有WebSphere MQ 或WebSphere MQ V5的产品，如果你想触发启动通道，可以不必定义进程对象。
有些平台的WebSphere MQ客户端也支持触发机制，例如：UNIX，Windows,OS/2。
运行在客户端的应用程序和运行在完全WebSphere MQ 环境的应用程序是一样的，只是应用程序链接的库有区别。同时触发监控程序和应用程序必需要都在同一系统中运行。
触发所涉及的对象：
? 应用队列：是一个本地队列，并设置为可触发的。当触发条件满足时，将会产生触发消息。 进程定义：一个应用队列可能由一个进程定义对象和它关联。进程定义中包含应用程序的信息。该应用程序负责从应用队列中取出消息。 传输队列：如果用触发方式来启动通道，则需一个传输队列。传输队列的TriggerData属性中设置成将被启动的通道名。这将可省略进程的定义。 触发事件：它是一种引起队列管理器产生触发消息的事件。 触发消息：当触发事件发生时，队列管理器将产生触发消息。触发信息来自于应用队列和与应用队列关联的进程定义，它包含了将要被启动的程序名。 启动队列：也是一个本地队列，它是被用来存放触发消息的队列。一个队列管理器可以拥有多个启动队列。一个启动队列可以为多个应用队列服务。 触发监控器：是一个持续运行的程序，当一个触发消息到达启动队列时，触发监控器获
取触发消息，并利用触发消息中的信息，启动应用程序来处理应用队列中的消息，并把触发消息头发送传递给应用程序，消息头中包括应用队列名。
在所有平台上，有一个特殊的触发监控器叫做通道启动器（channel initator），它的作用是启动通道。
2.4.2触发类型
? EVERY:当应用队列中每接收到一个消息时，都将产生触发消息。如果应用程序仅处理一个消息就结束时，可采用这种触发类型。 FIRST：当应用队列中的消息从0变为1才会发生触发事件。如果当队列中的一个
消息到达时启动应用程序，直到处理完所有消息就结束，则采用这种触发类型。
? DEPTH：当应用队列中的消息数目和TriggerDepth的属性值相同时，才会产生触
发事件。当一系列请求的恢复都收到时，才启动应用程序，则采用这种触发类型。 当采用depth触发时，产生触发消息后，队列将被修改成非触发方式，如果需要再次触发，将要重新设置成允许触发。
队列的TriggerDepth属性表示引起depth触发事件发生时，队列中的消息数目。
2.4.3触发的工作原理
为了更好地能理解触发机制，我们举一个触发类型为FIRST的例子。
1. 只有一个本地或远程的应用程序A，往应用队列(Application Queue)中PUT了一条
消息。
2. 当队列原来的深度为0时，也即队列为空，这时PUT一条消息到队列中，将会形
成触发事件，同时会产生一条触发消息，触发消息中将包含进程定义（Process）中的信息。
3. 队列管理器创建触发消息，并把它PUT到与应用队列相关的启动队列（Initiation
Queue）。
4. 触发监控器从启动队列中GET出触发消息。
5. 触发监控器处理触发消息，发出启动应用程序B的命令。
6. 应用程序B打开应用队列，并处理队列中的消息。
注意：
1. 如果队列的触发类型为FIRST或DEPTH，同时有多个应用程序往应用队列发送消
息，这种情况下将不会形成触发事件。
2. 如果启动队列设置成不允许PUT消息，那么队列管理器将不产生任何触发消息，
直到把启动队列的属性修改成允许PUT消息。
3. 如果通道设置成触发方式，建议触发类型为FIRST或DEPTH。
图 2.1触发消息和应用流程
一般情况下，特别是工作负载不均匀分布时，人们总希望有消息需要处理时，才启动相应的应用程序。
这种自动启动应用程序的机制被称作“触发”（Triggering）。基本原理是：当队列管理器发现有一条消息到达被触发的队列之后，他将产生一条
2.5 队列管理器群集
2.5.1 群集的概念
如果您熟悉WebSphere MQ和分布式队列，则可以把群集认为是一个队列管理器的网络，或是一个队列管理器的集合，群集中的队列管理器可以是不同的操作系统平台。每当您在群集中创建一个接收通道或定义一个队列时，则系统将自动在其它队列管理器中创建相应的发送通道和远程队列定义。
在群集中您不需要创建传输队列定义，因为WebSphere MQ在每个队列管理器中已经定义了一个传输队列。这个传输队列可以把消息发送到任何队列管理器中。
群集的信息是存放在资源库中。大多数队列管理器只保留它们自己所需要的信息，这些信息包括与它们通信的队列管理器和队列的信息。一些队列管理器包含了群集中所有队列管理器的所有信息。
下图显示了一个叫CLUSTER的群集：
? 在这个群集中有三个队列管理器，QM1,QM2和QM3。 QM1和QM2存放了群集中队列管理器的信息。它们被叫作完全资源队列管理器。 QM2和QM3中有几个队列，这些队列能被群集中任何其它队列管理器。这些队列被叫作群集队列。 每一个队列管理器有一个接收通道的定义，它被叫作群集接收通道。用来接收消息。 每一个队列管理器也有一个发送通道的定义，它将和完全资源管理器的群集接收通道相
连。这个通道叫做群集发送通道。在下图中,QM1和QM3有群集发送通道连接到TO.QM2，QM2有群集发送通道连接到TO.QM1。
一旦群集接收通道和群集发送通道已经定义好了，通道将自动启动。
图，队列管理器群集
2.5.2 群集的优点
使用群集有两个优点：
1. 减少系统管理
即使您创建了一个很小的群集，都将减少系统管理的工作。在群集中建立队列管理网络比在分布式队列建立网络将使用更少的定义。由于使用更少的定义，您将能够更快和更容易地建立和改变网络。并且降低了定义错误的风险。
2. 增强可用性和实现负载均衡
简单的群集将更容易管理。对于复杂的群集，将提高了扩展性和可用性。因为您可以定义在不同的队列管理器定义相同的队列，因此工作负载可以在群集的队列管理器实现均衡。
2.5.3 群集的组件
? 群集资源库（队列）
资源库中存放了群集中队列管理器的信息，包括队列管理器名，以及它们的通道和队列等。这些资源库信息通过一个叫SYSTEM.CLUSTER.COMMAND.QUEUE的队列进行交换，并存放到一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的固定队列中。
资源库可能是完全或部分的。每个队列管理器至少要连接到一个拥有完全资源库的队列管理器。
每一个群集队列管理器必须有一个叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的本地队列，在群集中至少一个群集队列管理器含有完全资源库。对于每个群集队列管理器，必须要预定义一个群集-发送通道连接到资源库队列管理器中。资源库队列管理器之间必须要互连，网络状况要比较好，和具有高可用性。普通队列管理器只包含有部分资源库信息。
? 群集-发送通道
群集-发送通道的类型为TYPE(CLUSSDR)，群集队列管理器使用群集-发送通道可以把消息发送到完全资源库队列管理器中。这个通道被用来通知队列管理器状态的改变，例如，队列的删除和创建。它仅和第一个完全资源库队列管理器联系。
? 群集-接收通道
群集-接收通道的类型为TYPE(CLUSRCVR)，群集队列管理器可以使用它接收群集内的消息。每一个群集队列管理器至少需要一个群集-接收通道。
? 群集传输队列
从一个队列管理器发送到其它队列管理器的消息都将被放到SYSTEM.CLUSTER.TRANSMIT.QUEUE队列中，在每个队列管理器中必须要存在群集传输队列。
2.5.4 创建群集
下表是一个创建群集的脚本示例，群集名为NPC。
其中群集传输队列和命令队列不用显示定义，队列管理器QM0000是NPC群集中一个完全资源库队列管理器。一个队列管理器可以同时属于多个群集。
在MQSeries v5.2以后版本，在群集中能够支持DHCP：
? 在定义群集-接收通道时，不用说明队列管理器的网络地址。
2.5.5 实现负载均衡
当在群集中含有同一队列的多个实例时，WebSphere MQ通过使用负载管理算法把消息发送到最方便的队列管理器中。负载管理算法尽可能地选择本地队列管理器作为目的地。如果在本地队列管理器中没有队列，这个算法将选择最合适的目标。合适的原则是取决于通道状态、队列管理器和队列的可用性。在满足条件的队列管理器之间，这个算法使用了轮循的方法进行选择。从而可以实现负载均衡的功能。
使用群集可以减少系统管理，也可以在群集中的几个队列管理器中创建同名的队列。只有拥有队列的队列管理器才能处理队列中的消息，但应用程序发送消息时不用显示说明队列管理器名。负载管理算法决定了那个队列管理器应该处理消息。
下图中显示了一个群集中定义了多个Q3队列的定义。当在QM1的应用程序放一个消息到Q3时，它不必知道是那个Q3队列将处理消息。
当消息正在传输时，群集中的一个本地队列变得不可用，那么消息将被转发到另一个队列中（但需要以BIND_NOT_FIXED的选项打开队列）。如果其它队列也不可用，这个消息将被放到死信队列中。
如果目标队列管理器不能工作，那么消息将仍然被放在传输队列中，系统将尝试更换消息的路由。这样做并不会影响消息的完整性，但如果出现队列管理器失败并消息处在可疑（in doubt）状态，这个消息将不能更换路由。
图，在群集中一个队列有多个实例
2. 在群集中创建同一队列的多个实例时，需要确保您的消息互相之间没有依赖，例如，
消息需要按照特定顺序处理或被同一队列管理器处理。
3. 使同一队列的不同实例的定义相同，否则执行MQINQ调用将产生不同的结果。
在大多数情况下负载管理算法将满足系统的需求，然而您也可以编写用户出口(user-exit)程序来定制负载管理算法，WebSphere MQ中包含用户出口和群集负载出口（cluster workload exit），可以使用ALTER QMGR命令来激活群集负载出口。例如，ALTER QMGR CLWLEXIT(myexit) 欲了解更详细的有关信息，请参考《Queue Manager Clusters》。
2.5.6 群集管理
您有时需要对群集中的队列管理器进行维护，例如，您可能需要备份队列中的数据，或把补丁应用到系统中。如果队列管理器包含队列，则必须暂停队列管理器。当维护结束后，将继续队列管理器的工作。
? 为暂停队列管理器，可以使用命令SUSPEND QMGR，例如：
SUSPEND QMGR CLUSTER(SALES)
它将临时从群集中移走一个队列管理器，这样将不会有任何消息发送到这个队列管理器。暂停的队列管理器和对象的信息都被保留在资源库中，但是队列管理器被标记为暂停。
? 当维护队列管理器的工作完成后，需要让队列管理器继续工作。通过执行RESUME
QMGR则可以实现，例如：
RESUME QMGR CLUSTER(SALES)
RESUME QMGR命令将通知完全资源库，这个队列管理器将又重新可用。完全资源队? 列管理器散布这个信息到其它队列管理器。 在群集中的队列管理器可以执行刷新启动命令。在正常环境下不需要执行刷新命令，
例如：
REFRESH CLUSTER(SALES)
执行刷新命令，将丢弃所有本地的关于群集的信息。
? 如果要从群集中强制除去一个队列管理器，则可以通过RESET CLUSTER命令实现。
或一个队列管理器已经被删除，但是定义到群集的群集-接收通道仍然存在，那么您也可以使用RESET CLUSTER命令来快速地清理这些定义信息。
使用RESET CLUSTER命令是删除自定义群集-发送通道的唯一方法。在正常的环境中，您不必运行这个命令。这个命令只能在资源管理器中执行，例如：
RESET CLUSTER(SALES) QMNAME(QM0000) ACTION(FORCEREMOVE)
QUEUES(NO)
? 查看群集中队列管理器信息，可以使用命令DISPLAY CLUSQMGR，例如： ? DISPLAY CLUSQMGR(*) CLUSTER(SALES) 您可以定义群集队列，例如：
DEFINE QLOCAL(0000_1) CLUSTER(SALES)
欲了解更详细的有关群集管理的信息，请参考《Queue Manager Clusters》。
2.6本章小结
本章主要介绍WebSphere MQ的基本概念和体系结构，WebSphere MQ核心是由队列管理器、队列和通道组成。队列和通道分别有多种类型。在实际应用中，根据系统的实际需要选择合适的对象类型进行配置。描述了WebSphere MQ队列管理器的触发机制和群集的概念并介绍了它的优点以及实现方法。
2.7本章练习
1， IBM WebSphere MQ中包含了那些对象？
2， 练习安装和连接WebSphere MQ客户端到服务器端的过程。
3， 在系统中创建的第一个队列管理器是缺省队列管理器？
(1) 是 （2） 否
答案：（2）
4， WebSphere MQ 使用一种什么接口，实现通过程序可以访问队列管理器的资
源：
（1） 程序到程序的API(the program to program API)
（2） 消息队列接口（Message Queue Interface）
（3） 同步模式(the synchronous model)
（4） 触发机制(triggering)
5， WebSphere MQ仅异步环境的消息队列。
（1）对 （2）错
6， 一个消息可以由下列那些部分组成：
（1） 应用数据（application data）
（2） 死信头 (a dead-letter header)
（3） 安全头 (security header)
（4） 消息描述块 (a message descriptor)
（5） 以上所有的 (all the above)
答案：（1）（2）（4）
7， 所有的消息至少有一个头，它是：
（1） MQXQH（transmission header）
（2） MQDLH (dead letter header)
（3） MQMD (message descriptor)
（4） MQTH (trigger header)
答案：（3）
8， 在WebSphere MQ触发机制，队列管理器启动被触发的程序：
9.临时动态队列中可以包含下列那些消息类型：
（1） 仅回复消息
（2） 仅报告消息
（3） 仅非永久性消息
（4） 永久性和非永久性消息
第二部分 Websphere MQ系统管理
第三章WebSphere MQ系统安装
1． 由于WebSphere MQ支持35种以上系统平台，本章仅以WebSphere
MQ Windows版为例。
2． 介绍WebSphere MQ系统安装规划。
3． 学习WebSphere MQ系统安装步骤。
4． 描述了WebSphere MQ的安装验证过程。
3.1 规划安装
本节概述了运行WebSphere MQ所需的硬件和软件环境，所支持的网络协议和编译器、传递媒体以及产品的各种功能部件（以前称为组件）。
内容包括安装、验证和通信设置（假设您使用 TCP/IP 作为通信协议）。可以使用其它协议（例如，SNA、SPX 和 NetBIOS）。本书中没有涉及关于这些协议的特定过程，却有对 WebSphere MQ 库中包含相关信息的其它书籍的引用。但请注意，WebSphere MQ 的以下功能仅在 TCP/IP 下才可使用：
WebSphere MQ MQI 明信片
WebSphere MQ JMS 明信片
WebSphere MQ 资源管理器
注:
尽管在―动态主机配置（DHCP）‖的机器上运行的队列管理器可以是群集的成员，但建议群集资源库的队列管理器应该位于具有静态 IP 地址的机器上。
3.1.1 硬件要求
以下是 WebSphere MQ 服务器的硬件要求：
? 任何基于 32 位 Intel 处理器 IBM PC 机（或兼容机）。 支持 SNA LU 6.2、TCP/IP、NetBIOS 或 SPX 的通信硬件。
对于典型安装，WebSphere MQ至少需要大约 85 兆字节（MB）的磁盘空间用于产品代码和数据（如果使用 NTFS）。至少需要20 MB 作为运行空间。而且，安装进程需要在系统
盘上需要30M的临时空间。
3.1.2 软件要求
以下是运行 WebSphere MQ Windows 版的先决条件；列出了最低的支持级别。 操作系统
WebSphere MQ的安装需要以下操作系统软件之一：
? Microsoft Windows NT 版本 4.0（包括 TCP/IP、NetBIOS 和 SPX）和 Microsoft Windows NT Service Pack 6a。 Microsoft Windows 2000。可以是Microsoft Windows 2000 专业版或Microsoft
Windows 2000 服务器版。
连通性
WebSphere MQ如果需要实现SNA连接，则需要安装下列软件之一：
? IBM 通信服务器 Windows NT 版，版本 5.0 和版本 6.1.1。 Attachmate Extra! Personal Client，版本 6.7。 Attachmate Extra! Enterprise 2000. Microsoft SNA 服务器，版本 4.0。 Microsoft Host Integrated Server 2000。 TCP/IP、NetBIOS 和 SPX。它们被包含在操作系统中。
Windows NT的安装需求
以下是 Windows NT 的安装需求：
? Microsoft Internet Explorer 4.0.1，带有 Service Pack 1 或更高版本。 Microsoft HTML Help 1.2。
在 WebSphere MQ 服务器 CD-ROM 中提供。
? Microsoft Management Console（MMC）1.1。
? Microsoft Installer（MSI）1.1 或更高版本。
? Microsoft Active Directory Client Extensions（ADCE） Windows NT 版。
? 支持 Java Runtime Environment 版本 1.3 或更高版本。（仅 Java 消息传递需要）。 Microsoft Windows NT 的 Option Pack 4。（如果需要支持Microsoft Transaction Server
（MTS））。
Windows 2000的安装需求
? 支持 Java Runtime Environment 版本 1.3 或更高版本。（仅 Java 消息传递需要）。 安装必备软件
要安装 WebSphere MQ 服务器 CD-ROM 中提供的必备软件（不包含服务包或 Web 浏览器），可以执行以下操作：
? 使用 WebSphere MQ 安装程序。
当使用 WebSphere MQ 服务器 CD-ROM 进行安装时，在 WebSphere MQ 安装启动面板中有一个必备软件选项。可以使用该选项检查已安装了哪些必备软件和缺少哪些，然后安装缺少的软件。
? 使用 Windows 资源管理器：
1. 使用 Windows 资源管理器选择 WebSphere MQ 服务器 CD-ROM 上的文
件夹 \MSI。
2. 选择要安装的软件项的文件夹。
3. 如果适合，可以选择所需安装语言的文件夹。它们是：
de_de
德语
en_us
英语
es_es
西班牙语
fr_fr
法语
it_it
意大利语
ja_jp
日语
ko_kr
韩国语
pt_br
巴西葡萄牙语
zh_cn
简体中文
zh_tw
繁体中文
4. 启动安装程序。
WebSphere MQ 功能部件
当安装 WebSphere MQ 时，可选择需要的功能部件。下面显示的功能部件在从服务器 CD 安装 WebSphere MQ 时可用。
服务器
服务器功能部件允许您运行计算机上的队列管理器并与网络上的其它计算机连接。包含 Java 支持。
Windows客户机
WebSphere MQ 客户机是 MQ 的一个小子集（不包含队列管理器），它使用队列管理器和其它（服务器）计算机上的队列。只有当它所在的计算机和一台正在运行完整 WebSphere MQ 服务器版本的计算机相连接时，它才能使用。根据需要，客户机和服务器可以在同一台机器上。
Java 消息传递
使用 Java（包含 Java Message Service 支持）进行消息传递所需的文件。
开发工具箱
这个功能部件中包含了开发将在 WebSphere MQ 上运行的应用程序时所需的一些源文件样本和各种绑定（.H、.LIB、.DLL 等文件）。绑定和样本是使用以下语言提供的：C、C++、Visual Basic、ActiveX、Cobol、DCE、PL/1。它包括 Java 和 Java Message Service 支持，提供的样本有：MTS、MQSC 和 Lotus Notes。
3.2 安装 WebSphere MQ
3.2.1 WebSphere MQ 文档
WebSphere MQ 文档不再是 WebSphere MQ 产品的部件，现在它作为此产品的单独 CD 软件包而提供。您可以从光盘直接查看文档，或者可以把它们独立安装到计算机上。 安装 WebSphere MQ 文档步骤如下：
1. 把 WebSphere MQ 文档 CD 插入 CD-ROM 驱动器。
如果启用自动启动，则会启动安装进程。如果不启用，则双击 CD-ROM 上的根文件夹
中的安装图标以启动安装程序。
2. 依照安装提示进行操作，即可安装完成。
3.2.2 WebSphere MQ安装
介绍关于如何安装 WebSphere MQ Windows 版的步骤。安装过程大约要需要30 分钟。 以下步骤演示了如何进行典型安装。
1. 将 WebSphere MQ Windows 版服务器 CD-ROM 插入 CD-ROM 驱动器。
2. 如果安装了自动运行，那么会启动安装进程。如果不启用，则双击 CD-ROM 上的
根目录中的 Setup 图标以启动安装程序。
3. 请等待，直到出现―WebSphere MQ 安装启动板‖窗口为止。
4. 可选地，要更改安装的本地语言，单击选择语言图标，然后从列表中选择所需的语
言。
5. 选择必备软件选项。
如图所示列出典型安装的必备软件，请参阅图，每个安装项的右边，有一个勾号（表示已安装）否则一个叉号（表示没有安装）。
如果出现了叉号：
a. 单击项目左边的 + 符号以显示安装链接。
b. 选择要使用的安装源的选项。从以下各项选择：
WebSphere MQ CD
? 因特网
? 网络
c. 安装完成时，单击项目左边的 - 符号。 ?
注: 对于定制安装，可能不需要所有的必备软件。
6. 当安装了所有的必备软件时，选择网络先决条件选项。
7. 选择 WebSphere MQ 安装选项。
8. 请选择启动 WebSphere MQ 安装程序，然后等待，直到显示了带有欢迎消息的
―WebSphere MQ 安装‖窗口为止。
9. 单击下一步继续。
10. 请阅读面板上的信息和许可证条款。
要更改显示许可证协议的语言，单击更改语言，然后从提供的列表中选择您需要的语言。 选择此选项接受许可证条款，然后单击下一步。
11. 如果机器上未安装过此产品的前一个版本，则显示―安装类型‖面板。
选择希望的安装类型，然后单击下一步。显示了安装类型以及每种选项所安装的功能部件。 选择―典型‖安装。
12. 如果机器上已安装了 WebSphere MQ 的前一版本，则显示―安装进程的类型‖面板。
选择以下一个选项，然后单击下一步：
o 更新。安装与前面版本相同的功能部件。转至下一步。
o 定制。可以选择要安装哪些功能部件。
13. ―WebSphere MQ 安装‖窗口显示以下消息：
安装 WebSphere MQ 就绪，该窗口还显示您选中的安装摘要。要继续，单击安装。
14. 会询问您在您的计算机上是否已为处理程序数购买了足够的容量单元。
如果您有足够的容量单元，单击是。 如果没有足够的容量单元，单击否。会通知您必须获取足够的容量单元，以在计算机上运行此软件。单击是继续，或单击否取消安装。 显示―安装 WebSphere MQ‖面板。 等待，直到进展栏结束。
成功安装 WebSphere MQ 后，―WebSphere MQ 安装‖窗口显示以下消息： 安装向导成功完成
15. 单击完成启动―准备 WebSphere MQ‖向导。
3.3 验证安装
3.3.1安装验证
安装验证的方法有许多种，可以用明信片应用程序，或可以使用一个队列管理器和一个队列的简单配置来验证本地安装。使用样本应用程序将消息放置到队列并从队列读取该消息。 下面介绍手工创建对象验证安装的方法。
使用以下步骤来安装队列管理器和队列：
1. 创建名为 venus.queue.manager 的缺省队列管理器。在窗口的命令提示符下，输入以下命令：
crtmqm -q venus.queue.manager
2. 启动队列管理器。输入以下命令：
strmqm venus.queue.manager
3. 启用 MQSC 命令。输入以下命令：
runmqsc venus.queue.manager
4. 定义名为 ORANGE.QUEUE 的本地队列。输入以下命令：
define qlocal (orange.queue)
MQSC 中的任何小写字母都将自动转换成大写，除非用单引号将它们括起来。这意味着如果用名称 orange.queue 创建了队列，则记住在 MQSC 以外的其它命令中必须使用 ORANGE.QUEUE。
5. 停止 MQSC。输入以下命令：
end
现在已经定义了以下对象：
? 名为 venus.queue.manager 的缺省队列管理器 名为 ORANGE.QUEUE 的队列
3.3.2测试对象
要测试队列和队列管理器，请使用样本程序 amqsput （将消息放入队列）和 amqsget（从队列获取消息）：
1. 启动MS-DOS窗口，进入到c:\Program Files\IBM\WebSphere MQ\bin目录下。
2. 将消息放入队列，输入以下命令：
amqsput ORANGE.QUEUE
显示以下消息：
Sample amqsput0 start
target queue is ORANGE.QUEUE
3. 输入一些字符数据，然后按 Enter 键两次。显示以下消息：
Sample amqsput0 end
现在消息已经被放在队列。
4. 要从队列获取消息，请输入以下命令：
amqsget ORANGE.QUEUE
在屏幕上将显示您刚才输入的字符数据消息。暂停后，例子程序结束。
如果以上步骤都能完成，则完成了本地安装的验证。
如果在任何阶段中断整个安装过程，则应该从头开始重新运行安装。
3.4 本章小结
本章主要介绍在Windows平台WebSphere MQ的安装需求和安装过程，并介绍了安装后的安装验证过程。
3.5本章练习
1. 列出安装WebSphere MQ产品的任务列表。
练习安装WebSphere MQ for Windows 产品。
2. 产品安装完毕后，然后验证安装是否正确？
3. 在Windows 2000系统中安装WebSphere MQ产品前，必须工作有：
（1） 安装MQS.INI配置文件。
（2） 用管理组的成员登录系统。
（3） 创建通道。
（4） 为每个队列管理器创建通讯链路。
第四章WebSphere MQ 的管理
5． 学习和掌握WebSphere MQ的管理，管理任务包括创建、启动、修改、
查看、停止和删除WebSphere MQ对象（队列管理器，队列，群集，
进程，名字列表，和通道）。
6． 掌握WebSphere MQSC和PCF命令 。
7． 学习WebSphere MQ配置。
8． 了解WebSphere MQ安全性。
9． 了解WebSphere MQ事务性。
10．
学习WebSphere MQ死信队列处理程序。
4.1 本地和远程管理
WebSphere MQ可以从本地或者远程管理对象。
本地管理是对在本地系统上定义的任何队列管理器执行管理任务。也可以访问其它系统，例如通过 TCP/IP 终端仿真程序 telnet，对其他系统进行管理。在 WebSphere MQ 中，认为是本地管理，因为没有通道定义，它们之间的通信是由操作系统提供的。
WebSphere MQ 也支持远程管理，可以从本地系统上发出一条命令到远程系统上运行。例如，您可以发出一条命令修改远程队列管理器上的队列定义。如果需要进行远程管理，则需要有相应的通道定义，远程系统上的队列管理器和命令服务器必须正在运行，但您不必登录到远程系统。 在非 Windows 系统的平台上，有些命令不能用这种方式发出，特别是创建或启动队列管理器和启动命令服务器。要执行这种任务，您必须登录到远程系统并从那里发出命令或创建一个进程来处理您的命令。但在 Windows 系统上，您可使用 WebSphere MQ 服务管理单元来实现这个功能。
4.2 使用命令管理 WebSphere MQ
有三种命令集合，可用于管理 WebSphere MQ，分别是控制命令、MQSC 命令和 PCF 命令。
4.2.1控制命令
控制命令是用来维护队列管理器本身的管理命令。 关于控制命令将在‖第六章 WebSphere 控制命令‖作详细地介绍。
4.2.2WebSphere MQ 脚本（MQSC）命令
MQSC命令是用来管理队列管理器对象，包括队列管理器本身、通道、队列和进程定义。 可以使用 runmqsc 向队列管理器发出 MQSC 命令。命令的输入有两种方式，一种是交互式命令，另一种是从ASCII 文本文件中重定向输入命令。在这两种方式中，命令的格式是相同的。
runmqsc 命令有三种运行模式：
验证模式，用这种方式在本地队列管理器上验证 MQSC 命令，但实际上并不运行 。 ? 直接模式，用这种方式在本地队列管理器上运行 MQSC 命令 。
? 间接模式，用这种方式在远程队列管理器上运行 MQSC 命令 。 ?
使用MQSC命令
使用MQSC命令的规则
当使用 MQSC 命令时，应该遵循以下规则：
? 每个命令的第一参数是动词，第二个参数是名词。第三个参数可能是对象名或对象
统配符。随后的参数没有次序关系。如果参数有一个相应的值，则值必须紧跟在和它相关的参数之后。
可以用空格和逗号分隔关键字、括号和值。
在命令的开始或结束和参数、标点符号和值之间可以有任意多个空格。例如，以下命令是有效的： ? ?
ALTER QLOCAL ('Account' ) TRIGDPTH ( 1)
? 不允许重复参数。 字符串中可以包含空格、小写字母或特殊字母，但必须包含在单引号中，而且不能
包含下列特殊字符：
o 句话（.）
o 前斜杠（/）
o 下划线（_）
o 百分号（%）
如果字符串本身包含引号，则引号用两个单引号替代。如果小写字母没有用单引号包含，则将被自动转换成大写。
? 不包含字符的字符串（即，在两个引号之间没有空格）被认为是('') 或(' ')。 左圆括号后跟着右圆括号，它们之间没有重要的信息，例如 NAME ( )，这被认为是无效。 关键字不区分大小写 － AltER、alter 或 ALTER 都是同样的含义。 一些参数定义同义词。 例如，DEF 总是 DEFINE 的同义词，因此 DEF QLOCAL 是
有效的。但是，同义词不仅仅是最小字符串；DEFI 不是 DEFINE 有效的同义词。 注:
DELETE 参数没有同义词。
有特殊意义的字符
创建MQSC 命令时，以下字符有特殊意义：
当您需要在一个字段中使用这些特殊字符时，您必须将整个字符串包含在单引号中。
创建命令脚本
命令脚本的规则如下：
? 每个命令都必须以新行开始。 在不同平台上，关于命令行的长度和记录格式的可能会有区别。如果希望脚本能适用于不同平台，则每行的实际长度应该限定为 72 个字符。 每一行不必以键盘控制字符结束（例如，tab）。 如果行上的最后非空格字符是：
o 减号（-），表明命令将从下一行的开始继续。
o 加号（+），表明命令将从下一行的第一个非空格字符继续。如果您使用 + 继
续一个命令，则记住要在下个参数前保留至少一个空格（z/OS 除外）。
? 当命令重新组合成单个字符串时，行末使用的 + 和 – 被忽略。 忽略第一个位置中以星号（*）开始的行，这代表文件中的注释行。空白行将被忽略。 MQSC 命令属性名称限制为 8 个字符。
MQSC 命令在其它平台上都可用，包括 OS/400(R) 和 z/OS。《WebSphere MQ 脚本（MQSC）命令参考》 包含每个 MQSC 命令和它的语法的描述。
WebSphere MQ 对象的命名规则
WebSphere MQ 队列、进程、名称列表、通道和存储类对象存在于各自独立的对象名字空间中，因此不同类型的对象可以有相同的名称。但是，同一类型中的对象不能同名。（例如，本地队列不能和模型队列有相同的名称。）WebSphere MQ 中的名称都区分大小写；住不包含在引号中的小写字符都将转换为大写。
用于命名WebSphere MQ 对象的字符集如下所示：
? 大写 A-Z 小写 a-z 数字 0-9 句号（.） 前斜杠（/） 下划线（_） 百分号（%）。
1. 不允许首字符为空格或嵌入空格。
2. 首字母或尾字母不能为下划线。
3. 少于完整字段长度的任何名称都可在其右边添加空格以达到规定长度。被队
列管理器返回的短名称总是在其右边填满空格。
4. 任何名称结构（例如，使用句号或下划线）对队列管理器而言都是无意义的。
5. 队列名称可长达 48 个字符。
6. 系统缺省的对象名称请参看附录。
4.2.3PCF 命令
WebSphere MQ 可编程命令格式（PCF）命令使得管理任务能编写到应用程序中。在程序中可以创建队列和进程定义和更改队列管理器。PCF 命令和MQSC 命令具有相同的命令集。 可使用 WebSphere MQ 管理接口（MQAI）可以更容易访问PCF 消息。
PCF的原理
PCF定义了命令和回复消息，应用程序通过这些命令和回复消息实现和队列管理器之间的信息交换，通过WebSphere MQ的应用程序可以实现对MQ对象的管理包括：队列管理器，进程定义，队列和通道。应用程序可以通过一个本地队列管理器集中管理网络中的任何本地和远程管理器。
每一个队列管理器有一个管理队列，应用程序可以发送PCF命令消息到管理队列中，每一个队列管理器也有一个命令服务器，它是为管理队列中的消息而服务。因此在网络中的任何队列管理器可以处理PCF消息，通过使用定义的回复队列，回复消息可以被返回给应用程序。PCF命令和回复消息是使用MQI进行发送和接收的。
WebSphere MQ 管理接口(MQAI)
在WebSphere MQ for Windows, AIX, iSeries, Linux, HP-UX, and Solaris and WebSphere MQ for OS/2 Warp版本，都支持 WebSphere MQ Administration Interface(MQAI)。
MQAI是WebSphere MQ 提供的一种实现发送和接收PCF的接口。MQAI通过使用数据报（data bags）来处理对象的属性，这样比直接使用PCF更简单。
MQAI通过传递参数到数据包的方法，从而提供了更简单的访问PCF消息的编程接口。这样只要一条语句就可以实现一个结构。编程人员不需要处理数组和分配空间，也不需要了解PCF的消息结构。
MQAI通过发送PCF消息到命令服务器并等待回复消息来管理WebSphere MQ，如图所示。
图：MQAI的原理图
4.3 WebSphere MQ 配置
本节主要描述在 Windows 系统上和在 UNIX 系统上更改配置信息。
4.3.1在 Windows 系统上更改配置信息
WebSphere MQ所有配置信息都存储在 Windows 注册表中。您可使用 WebSphere MQ 服务管理单元或使用 amqmdain 命令编辑配置信息。
建议使用 WebSphere MQ 服务管理单元修改配置信息。不要直接编辑注册表系统文件，因为这如果对编辑注册表失败，可能会严重影响 WebSphere MQ 系统或Windows 操作系统第 56 页 共 217 页
的运行。
4.3.2 在 UNIX 系统上更改配置信息
在 UNIX 平台上，可以更改以配置文件中的 WebSphere MQ 属性：
? WebSphere MQ 配置文件（mqs.ini），它的属性将影响整个WebSphere MQ节点系统，每个节点有一个mqs.ini文件。 队列管理器配置文件（qm.ini），它的属性仅影响某个队列管理器，在节点中的每个
队列管理器都有一个qm.ini文件。
配置文件中包含一个或多个节，每节都是为一个专门功能服务，如日志功能、通道功能和可安装服务。
因为 WebSphere MQ 配置文件用于维护和队列管理器相关的数据，不合法的或不正确的配置文件可能导致一些或全部 MQSC 命令失败。同样，应用程序不能与在 WebSphere MQ 配置文件中没有定义的队列管理器连接。
对配置文件所做的任何修改都不会立即生效，只有重新启动队列管理器才生效。
编辑配置文件前，最好先备份它。 编辑的方式有两种：一种是自动的，在节点上使用更改队列管理器配置的命令 ；另一种是手工的，使用标准文本编辑器 。
如果您在配置文件属性上设置了非法值，则系统忽略此值并会提示错误信息。
当创建新队列管理器时，最好先备份 WebSphere MQ 配置文件和新队列管理器配置文件。
如果出现以下情况时，可能需要编辑配置文件，例如：
? 丢失配置文件。（如果可以，从备份中恢复。） 需要移动一个或多个队列管理器到新目录中。 需要更改缺省队列管理器。
根据以下优先级设置配置文件属性值：
? 在命令行上输入的参数优先于在配置文件中定义的值。 qm.ini 文件中定义的值优先于 mqs.ini 文件中定义的值
WebSphere MQ 配置文件（mqs.ini）
WebSphere MQ 配置文件 mqs.ini 包含和节点上所有队列管理器都相关的信息。它在安装期间自动创建。 WebSphere MQ UNIX 系统版的 mqs.ini 文件在 /var/mqm 目录中。它包含：
? 队列管理器的名称 缺省队列管理器的名称 和每个文件关联的文件位置
如图显示 WebSphere MQ 配置文件的示例：
第 57 页 共 217 页
队列管理器配置文件 (qm.ini)
队列管理器配置文件 qm.ini, 包含和特定队列管理器相关的信息。每个队列管理器都有一个队列管理器配置文件。创建队列管理器时，将自动创建此文件。
qm.ini 文件保存在队列管理器的目录树的根中。例如，队列管理器 QMNAME 的配置文件的路径和名称是： /var/mqm/qmgrs/QMNAME/qm.ini
队列管理器名称最大长达 48 个字符。
如图显示了在 WebSphere MQ UNIX 系统版中队列管理器配置文件的配置属性。 第 58 页 共 217 页
第 59 页 共 217 页
4.4 WebSphere MQ 安全性
WebSphere MQ 队列管理器传递的信息可能都是有价值的数据，因此您需要使用授权系统来保证未授权的用户无法访问您的队列管理器。所以需要考虑以下安全性控制：
谁可以管理 WebSphere MQ
你可以定义一些用户通过命令来管理WebSphere MQ。
谁可以使用 WebSphere MQ 对象
您可以定义哪些用户（通常是应用程序）可以使用 MQI 调用和 PCF 命令执行以下操作：
? 连接到队列管理器。
? 访问类似队列、名字列表和进程的对象，访问这些对象的方式。
? 访问 WebSphere MQ 消息。
? 访问与消息相关联的上下文信息。
通道安全性
您需要确保用于将消息发送到远程系统的通道可以访问必需的资源。您还需要确保该通道被已授权的用户操纵。
管理 WebSphere MQ 的权限
WebSphere MQ 管理员有执行以下任务的权限：
? 使用命令（包含为其它用户授权 WebSphere MQ 授权的命令） 访问 WebSphere MQ Windows 版上的管理单元
要成为 WebSphere MQ 管理员，您必须是 mqm 组的成员（或是 Windows 系统上的管理员组的成员）。mqm 组是在安装 WebSphere MQ 时自动创建的；可以把其他用户加入到mqm组中，也可以把用户从mqm组中删除。
在 UNIX 平台上，还创建了 mqm 的用户。所有 WebSphere MQ 对象都属于mqm用户。
在 Windows 系统上，Administrator组的成员也可以管理任何队列管理器。您还可以在域控制器上创建 mqm 组，并将其添加到本地 mqm 组。有些命令必需只有属于mqm组的第 60 页 共 217 页
成员才可以操作，例如,创建队列管器crtmqm。但要执行以下操作，您不需要成为 mqm 组的成员：
? 使用PCF 命令或 MQSC 命令。 从应用程序发出 MQI 调用（除非您要在 MQCONNX 调用上使用快速路径绑定）。 使用 crtmqcvx 命令。 使用 dspmqtrc 命令。
使用WebSphere MQ 对象的权限
队列管理器、队列、进程、名称列表和认证信息（authinfo）对象都是从使用 MQI 调用或 PCF 命令的应用程序访问的。这些资源是被WebSphere MQ保护，所以应用程序需要有许可权来访问它们。
不同的主体组可以将不同类型的访问权限授权相同的对象。例如，对于特定队列，可能允许一个组执行放入和获取操作；可能仅允许另一个组浏览队列（带有浏览选项的 MQGET）。类似地，一些组可能已经放入和获取了队列权限，但未被允许改变队列的属性或删除队列。
一些操作是特别敏感的，应该限制为特权用户使用。例如：
? 访问一些特殊的队列，例如传输队列或命令队列 SYSTEM.ADMIN.COMMAND.QUEUE 运行使用全部 MQI 上下文选项的程序 创建和删除应用程序队列
所有对象的完全控制许可权是自动给予创建对象的用户标识和 mqm 组的成员的（以及给予 Windows 系统上的本地管理员组的成员的）。
4.5 WebSphere MQ 事务性支持
应用程序可以把一些列更新组合成一个工作单元。这些更新通常是逻辑相关的，为了保持数据完整性，所有的更新必须成功，如果一部分更新成功，一部分更新失败，将失去数据完整性。
工作单元成功完成后就提交。此时，所有在工作单元内所做的更新都将变成永久的并且是不可逆的。如果工作单元失败了，所有的更新都将被回滚。同步点协调是工作单元用来实现提交或回滚保证数据完整的进程。
本地工作单元上唯一更新的那些资源是 WebSphere MQ 队列管理器的资源。这里同步点协调是由队列管理器自身使用单阶段提交进程提供的。
全局工作单元上属于其它资源管理器的资源，例如符合 XA 的数据库，也同时被更新。必须使用两阶段提交过程，并且工作单元可由队列管理器自身协调，或由其它符合 XA 的事务管理器（例如 IBM TXSeries 或 BEA Tuxedo）。
总之，队列管理器资源可作为本地或全局工作单元的一部分进行更新：
本地工作单元
当要更新的资源仅为 WebSphere MQ 队列管理器的那些资源时，使用本地工作单元。使用 MQCMIT 动词提交更新，或使用 MQBACK 复原。
全局工作单元
当您还需要将 XA 相应的数据库管理器的更新包含到使用全局工作单元。此处对队列管理器的协调可以是内部或外部的。
队列管理器协调
全局工作单元可以使用 MQBEGIN 动词启动，然后使用 MQCMIT 提交或使用 MQBACK 复原。两阶段提交进程是在 XA 相应的资源管理器（例如，DB2(R)、Oracle 和 Sybase）在首次要求准备提交时使用的。仅当所有准备都成功时，然后要求将它们提交。如果任何资源管理器发出其无法准备提交的信号，则要求将它们复原。 外部的协调
此处，协调由 XA 相应的事务管理器（例如，IBM CICS、Transarc Encina、或 BEA Tuxedo）执行。工作单元是在事务管理器的控制下提交的。MQBEGIN、MQCMIT 和 MQBACK 动词都是不可用的。
(R)
4.6 WebSphere MQ 死信队列处理程序
死信队列（DLQ），有时指未送达消息队列，是一个保存不能发送到它们目标队列的消息的队列。网络中的每个队列管理器应该有一个关联的 DLQ。
消息可用队列管理器、消息通道代理程序（MCA）和应用程序放在 DLQ 上。DLQ 上的所有消息的前缀必须是用死信头结构 MQDLH 的结构。
队列管理器或消息通道代理程序放在 DLQ 上的消息总是有 MQDLH；将消息放在 DLQ 上的应用程序必须提供 MQDLH。MQDLH 结构的原因字段包含标识为什么消息在 DLQ 上的一个原因码。
所有 WebSphere MQ 环境需要一个在 DLQ 上有规律地处理消息的例程。WebSphere MQ 提供一个缺省例程死信队列处理程序（DLQ 处理程序），您可使用 runmqdlq 命令来调用它。
用用户写入规则表方式将 DLQ 上的处理消息的说明提供给 DLQ 处理程序。即，DLQ 处理程序匹配和规则表中条目相对的 DLQ 上的消息；DLQ 消息匹配规则表中的一个条目时，DLQ 处理程序执行和条目关联的操作。
4.7本章小结
本章主要介绍了WebSphere MQ的管理命令，共有三种命令，第一种是控制命令，主要是用在维护队列管理器本身的管理命令；第二种是MQSC命令，是用来管理队列管理器对象和队列管理器本身；第三种是PCF命令，它具有和MQSC命令相同的命令集，它主要用于在应用程序实现对队列管理器的维护。还介绍了WebSphere MQ配置信息和队列管理配置信息的存放位置，并举例介绍了unix和Window平台的配置文件。对WebSphere MQ的安全性、事务性和死信队列处理程序作了简单的介绍。
4.8本章练习
1. WebSphere MQ关心下列那个安全服务：
（1） 认证（authentication）
（2） 授权（authorization）
（3） 访问控制（access control）
2. WebSphere MQ管理员需要为WebSphere MQ对象设置所有的安全性。
3. 在WebSphere MQ中可以被保护的是：
（1） 队列
（2） 通道
（3） 定义
答案：（1）（2）
4．在一个工作单元中，changes是atomic。
（1）对 (2)错
5．在同步点控制的MQPUT意味着：
（1） 直到提交之后，消息才被放到队列中。
（2） 消息被放到队列，“getting”程序需要检查同步标记。
（3） 消息被放到队列，但直到提交后“getting”程序才能处理这些消息。 答案：（3）
6．WebSphere MQ 客户端可以使用全局工作单元处理。
7.下列那些选项可以保证WebSphere MQ for Windows NT的应用数据的提交和回滚？
（1） WebSphere Application Server
（2） MQCMIT和MQBACK调用
（3） Windows NT平台支持的XA-compliant Syncpoint coordinator
（4） Microsoft Transaction Server
（5） 以上都是
答案：（5）
第五章WebSphere MQ 控制命令 目标
11．
12． 了解WebSphere MQ控制命令 熟悉WebSphere MQ控制命令集
5.1 如何使用控制命令
如果需要使用控制命令，则用户必须属于mqm组。控制命令在不同平台上的使用会有些注意事项，如下所示：
WebSphere MQ Windows 版
所有控制命令都可以从命令行发出。使用 WebSphere MQ 资源管理器管理单元可以发出子集。命令名和它们的标志是不区分大小写的：您可以用大写、小写或大小写组合进行输入。但是，控制命令的自变量（如队列名）是区分大小写的。
在语法描述中，连字号（-）用作标志指示符。您可以使用正斜杠（/）来代替连字号。 WebSphere MQ UNIX 版
所有 WebSphere MQ 控制命令都可以从 shell 发出。所有命令都是区分大小写的。
WebSphere MQ 对象的名称
通常，WebSphere MQ 对象名可以有多达 48 个字符。此规则适用于所有以下对象： ?
? 队列管理器 队列 进程定义 名称列表 群集 认证信息（authinfo）对象
通道名的最大长度是 20 个字符。
可用于所有 WebSphere MQ 名称的字符是：
? 大写 A-Z 小写 a-z 数字 0-9 句点（.） 下划线（_） 正斜杠（/）（请查看注 1）
? 百分号（%）（请查看注 1）
1. 正斜杠和百分号是特殊字符。如果在名称中使用这些字符中的任意一个，则
使用此名称时必须加上双引号。
2. 不允许以空格开头或嵌入空格。
3. 不允许使用本地语言字符。
4. 名称可以加双引号，但是仅当名称中包含特殊字符时才需要。
5.2 控制命令
控制命令集
以下是每个 WebSphere MQ 控制命令的参考信息：
控制命令举例
1. 此命令创建一个称为 Paint.queue.manager 的缺省队列管理器，创建系统和缺省对
象，并请求两个主日志文件和三个次日志文件：
crtmqm -c "Paint shop" -ll -lp 2 -ls 3 -q Paint.queue.manager
2. 下列命令删除队列管理器 travel 并且也抑制任何由该命令发出的消息。
dltmqm -z travel
3. 此命令立即结束名为 saturn.queue.manager 的队列管理器。完成所有当前 MQI 调用，但不允许新的调用。
endmqm -i saturn.queue.manager
5.3 本章小结
本章介绍主要介绍如何使用WebSphere MQ控制命令和熟悉WebSphere MQ的控制命令集。
5.4本章练习
1. 使用CRTMQM控制命令创建缺省队列管理器的选项是哪一个？
（5） -d
（6） -q
（7） -x
（8） -u
2. 一个WebSphere MQ应用使用如下定义创建了一个队列：
DEFINE QLOCAL(TEST)
DEFPRTY(0)
MSGDLVSQ(FIFO)
TRIGMPRI(5)
TRIGTYPE(DEPTH)
TRIGDPTH(10)
TRIGGER
当什么条件发生时，将产生触发消息？
（1） 没有触发消息产生。
（2） 当队列中有5个消息时。
（3） 当队列中有10个消息时。
（4） 当队列中有5个优先级消息时。
（5） 当队列中有10个优先级为5的消息时。
答案（1）
3. 在WebSphere MQ for Windows平台上执行如下控制命令：
crtmqm /t 5000 /u MY.DEAD.LETTER.QUEUE travel
这个命令将能完成如下什么功能？
（1）
（2）
（3）
（4） 它定义了触发间隔。 它定义了队列MY.DEAD.LETTER.QUEUE。 创建了一个名为travel的队列管理器。 设置了队列的最大消息数5000。
答案：（1）（3）
4. 执行“runmqchl /c CHAN1”命令将产生什么结果？
（1） 通道CHAN1将被启动。
（2） 通道CHAN1将和队列管理器CHAN1相关。
（3） 缺省队列管理器中的CHAN1通道被启动。
（4） 由于sender/requester参数没有说明，所以将返回错误消息。
5. 使用下列那个命令，可以实现当前所有MQI调用完成之后，停止队列管理器？
（1） endmqm /c
（2） endmqm /i
（3） endmqm /p
（4） endmqm /z
第六章WebSphere MQ 互连通信 目标
1. 描述WebSphere MQ 产品之间的互连。
2. 学习掌握WebSphere MQ互连的概念；传输队列，消息通道代理程序和通信链路一起组合形成了消息通道。
3. 学习怎样通过消息通道把地理位置分开的队列管理器构成一个队列管理器网络。
4. 学习判断WebSphere MQ出口（exits）的需要，对于指定的需求给出推荐使用的出口（exits）。
5. 学习使用通道的维护和配置侦听程序。
6.1基本概念
6.1.1 什么是互连通信
对于WebSphere MQ，互连通信意味着把消息从一个队列管理器发送到另一个队列管理器，接收队列管理器可能是在本地机器或远程机器。发送队列管理器和接收队列管理器可以运行在相同的平台，也可以是WebSphere MQ所支持的任何平台，这种环境叫做分布式环境。WebSphere MQ使用DQM(Distributed Queue Management)来实现分布式环境间的通信。 本地队列管理器有时被叫做源队列管理器（source queue manager），而远程队列管理器有时被叫做目标队列管理器（target queue manager），或叫伙伴队列管理器(partner queue manager)。
分布式队列的工作原理
下图概括描述了分布队列的组件。
图，分布式队列组件
1. 应用程序使用MQCONN 调用连接到队列管理器。
2. 然后应用程序使用MQOPEN调用打开一个队列，以便可以把消息放到队列中。
3. 队列管理器拥有每个队列的定义。
4. 如果消息的目的地是远程系统的队列，那么本地队列管理器将保存消息直到消息被发送到远程队列管理器。这些对于应用程序来说是透明的。
5. 每个队列管理器都有叫做moving service通信软件;通过这个服务,一个队列管理器可以和另一个队列管理器通信。
6. transport service 不依赖于队列管理器，它可以是下列其中的一种，这和平台有关。
? SNA APPC （Systems Network Architecture Advanced Program-to Program Communication） TCP/IP (Transmission Control Protocol/Internet Protocol) NetBIOS (Network Basic Input/Output System) SPX (Sequenced Packet Exchange) UDP (User-Datagram Protocol)
分布式组件的定义：
1. WebSphere MQ应用程序可以把消息放到已连接的队列管理器的队列中。
2. 队列管理器可以定义属于自己的队列，也可以定义属于其他队列管理器的队列。这些队列叫做远程队列定义。WebSphere MQ应用程序也可以把消息放置到远程队列中。
3. 如果消息要发送到远程队列管理器中， 本地队列管理器把消息存放到传输队列（transmission queue）中直到它消息发送到远程队列管理器。传输队列是一个特殊的本地队列，在传输队列中的消息一直被保存到被成功地发送到远程队列管理器。
4. 负责消息发送和接收的软件叫消息通道代理（Message Channel Agent (MCA)）。
5. 消息是通过通道（channel）来实现队列管理器之间传输，通道是一条两个队列管理器之
间的通信链路，它可以把队列中的所有消息发送到远程队列管理器。
发送消息所需要的组件：
如果要把消息发送到远程队列管理器中，那么本地队列管理器需要定义一个传输队列和一个通道。通道的两端都需要分别定义，例如，发送端或接收端。一个简单通道是由本地队列管理器一个发送通道和远程队列管理器一个接收通道所组成的。这两个定义必须是相同的名字，并共同构成一个通道。
在通道的每一端也被叫做消息通道代理（Message Channel Agent (MCA)）。 每一队列管理器都应该有一个死信队列（dead-letter queue），也叫做不能交付的消息下图显示了队列管理器、传输队列、通道和MCA之间的关系。
队列（undelivered message queue）。如果消息不能到达目的队列，则将被放置到死信队列。
图，发送消息
实现接收消息所需的组件：
如果您的应用程序序要从远程队列管理器返回到本地队列管理器，则需要定义另一个通道，它的传输方向与发送的相反。
图，消息的双向传输
群集组件：
与传统的WebSphere MQ 网络相比的另一种网络是群集。支持群集的版本有 WebSphere MQ for AIX, iSeries, HP-UX, Solaris, z/OS,and Windows, WebSphere MQ V5.1 for Compaq Tru64 UNIX, 和 OS/2 Warp ，群集是由具有逻辑关系的队列管理器所组成的网络。集群中的任何队列管理器可以发送消息到同一集群其他队列管理器，而不需要显示地定义通道、远程队列和与目标相对应的传输队列。在群集中的每个队列管理器只有一个传输队列来负责把消息发送到群集中的其他队列管理器。每个队列管理器只需要一个cluster-receiver通道和一个 cluster-sender通道。下图显示了名叫“CLUSTER”的集群的组件：
图，队列管理器的群集
? “CLUSTER”集群中有三个队列管理器，分别是 QM1, QM2和QM3。 QM1和QM2存放了关于集群中的队列管理器和队列的完全资源信息。 QM2 and QM3 有一些群集队列。这些队列可以被群集中的其他队列管理器访问。 每个队列管理器有一个名叫“TO.qmgr”的cluster-receiver通道，该通道负责接收消息。 每个队列管理器也有一个cluster-sender通道，该通道可以发送消息到其中一个资源队列管理器中。 QM1和QM3发送资源信息到QM2，并且QM2发送资源信息到QM1中。 您可以使用MQPUT调用把消息发送到任何其他队列管理器，但是只可以使用MQGET
调用从本地队列中检索消息。
为了解更详细的关于群集的情况，请参看《WebSphere MQ Queue Manager Clusters》。
6.1.2 分布式队列组件
本节描述分布式队列组件，它们分别是：
? 消息通道 消息通道代理 传输队列 通道启动器和侦听程序 通道出口程序
6.1.2.1 消息通道
关于消息通道的内容，前面的章节已经详细介绍了，不再赘述。
6.1.2.2 消息通道代理（MCA）
MCA是一个控制消息发送和接收的程序。在通道的每一端都有一个MCA。一个MCA是把消息从传输队列取出来，然后放到通讯链路上。另一个MCA接收消息，并把消息放到远程队列管理器的队列中。
初始化通信链路的MCA叫做呼叫MCA，则另一个MCA叫响应MCA。呼叫MCA可以是发送通道，群集发送通道，服务器通道（完全意义的）或请求器通道。响应MCA可以是关联除群集发送通道之外的任何通道。
6.1.2.3 传输队列
传输队列是一个特殊的本地队列，它是用来存放将被发送到远程队列管理器的消息的队列。在分布式队列环境中，您需要位每一个发送MCA定义一个传输队列，除非使用了WebSphere MQ 的队列管理器群集。
您在远程队列定义中说明了传输队列名，如果没有说明传输队列名，那么队列管理器将会寻找一个和远程队列管理器相同名字的传输队列。
您可以为队列管理器说明一个缺省传输队列。如果您没有说明传输队列名，并且没有定义和远程队列管理器同名的传输队列，那么将会使用这个缺省传输队列。
6.1.2.4 通道启动器和侦听程序
通道启动器为发送通道充当了触发监控器，因为传输队列可以被定义为一个触发队列。当一个消息到达传输队列中，并满足了队列的触发条件，一个触发消息将被放到启动队列中，通道启动器将取出触发消息来启动相应的发送通道。如果在服务器通道中定义了对方的连接名，则也能触发服务器通道。这意味着基于消息到达传输队列中，使得通道能够被自动启动。 您需要一个通道侦听程序来启动接收（响应）MCA。为了响应呼叫MCA的启动请求
接收MCA被启动；通道侦听程序探测接入网络请求，并启动相应的通道。
图，通道启动器和侦听程序
通道启动器的使用依赖于平台，在z/OS平台，每个队列管理器只能有一个通道启动器；在其他平台，您可以启动多个通道启动器，并对每一个通道启动器指定一个启动队列。通常您只需要一个通道启动器。在WebSphere MQ for AIX, iSeries, HP-UX, Solaris 和 Windows systems, 和 WebSphere MQ for Compaq Tru64 UNIX, 和 OS/2 Warp平台上可以启动三个通道启动器(缺省值)，但是您可以修改这个值。对于支持群集的平台，当启动队列管理器时，通道启动器也会被自动启动。
通道侦听程序的使用也是和平台相关的。在OS/2和Windows系统中, 您可以使用WebSphere MQ 提供的通道侦听程序，也可以使用操作系统提供的程序。MQ的侦听程序有两种配置和启动方式，一种是通过配置/etc/inetd.conf文件选择使用inetd方式, 也可以使用MQ自身提供的runmqlsr程序，所不同的是：runmqlsr 是一个线程应用，所以比inetd需要更少的内存消耗。因此，采用runmqlsr方式可以提高通道相关的性能。与MQ应用程序类似，MQ的通道侦听程序也有trusted(fastpath)和non trusted(standard)两种运行方式，采用trusted运行方式可以降低CPU和内存消耗。将通道和侦听程序设置为trusted方式运行的方法是通过修改qm.ini配置文件中的MQIBindType参数来实现，即创建或修改qm.ini文件中与Channels相关的小节，例如：
Channels:
MQIBindType=FASTPATH 或者
MQIBindType=STANDARD
其中，FASTPATH表示trusted运行方式，而STANDARD表示非trusted运行方式。
6.1.2.5 通道出口程序
如有您想做一些额外的处理（例如，加密或数据压缩），则可以编写通道出口程序或使用 SupportPacs。使用网址：http://www.software.ibm.com/WebSphere MQ/txppacs/txpsumm.html 找到WebSphere MQ的事务处理SupportPacs。
WebSphere MQ的通道出口程序是在MCA执行过程中被调用的。通道出口程序有六种类型： ? 安全出口（Security exit）
用作安全性检查，例如，接收方认证。
? 消息出口（Message exit）
对消息的操作，例如，传输前进行加密。
? 发送和接收出口（Send and receive exits）
对消息切割的操作，例如，数据压缩和解压。
? 消息重试出口（Message-retry exit）
用于处理消息不能到达目的地的问题。
? 通道自动定义出口（Channel auto-definition exit）
用于自动定义接收通道和服务器连接通道。
? 传输重试出口（Transport-retry exit）
当通讯失败时，用来暂停把数据发送到通道。
通道出口程序的处理顺序如下：
1. 通道双方数据初始化成功后，调用通道安全出口。在通道启动阶段.这些必须要成功完成，才能把消息发送出去。
2. 通道消息出口程序被发送MCA调用，被发送到接收MCA的每个消息部分都将调用发送出口程序。
3.接收MCA当接收到消息的每部分就会调用接收出口程序，然后当整个消息接收完成后调用消息出口程序。
图，通道出口程序被调用的次序
消息重试出口程序被用来决定接收MCA在采取其他策略之前试图放消息到目标队列的次数。这个出口程序在WebSphere MQ for z/OS上不支持。
6.1.3 死信队列
如果消息不能被发送到正确的目的地，那么消息将被发送到死信队列，例如由于目标队列不存在，或队列已满。死信队列也能在通道的发送方使用，例如，数据转换失败。我们建议针对每个队列管理器定义一个死信队列。如果没有定义死信队列，MCA将不能放消息，消息就会被滞留在传输队列中，那么通道将被停止。
如果快速、非永久的消息不能被交付，并且目标系统没有定义死信队列，那么这些非永久消息就会被丢弃。然而使用死信队列将会影响消息的交付次序。
6.1.4怎样到达远程队列管理器
在源和目标队列管理器不一定总是有一个通道，可以考虑使用下列方案。
多跳（Multi-hopping）
如果源队列管理器和目标队列管理器之间没有直接的通讯链路，从源队列管理器到目标队列管理器之间可能会存在多个中间队列管理器，这种连接方式叫做多跳。在所有的队列管理器之间需要定义通道，在中间的队列管理器需要定义传输队列，如下图所示：
图，通过中间队列管理器到达目标队列管理器
共享通道（Sharing channels）
作为应用程序设计者，为了要把消息发送到目标队列管理器，您可以在应用程序中说明远程队列管理器名和队列名，或为每个远程队列创建一个远程队列定义，这个远程队列定义包含了远程队列管理器名，队列名和传输队列名。这两种方法都是通过相同的传输队列把消息发送到同一目的地，如图所示：
图，共享传输队列
上图描述了多个应用程序的消息可以使用同一个通道到达不同的远程队列。 使用不同的通道
如果您有不同类型的消息需要发送，那么可以在两个队列管理器之间定义多个通道。使用多个通道一般是考虑安全性或传输的负载均衡。
为了又创建另一条通道，则需要定义另一个通道和另一个传输队列，或创建一个远程队列。应用程序可以使用任何一条通道把消息发送到同一目标队列管理器。
图，使用多个通道
当您使用了远程队列定义，那么在应用程序中不用说明目标队列管理器和目标队列。通过使用远程队列定义，应用程序则不用关心目标队列的位置和传输队列。
使用群集
在群集中的每个队列管理器定义了一个群集接收通道。当一个队列管理器要发送消息到另一个队列管理器时，它将自动定义相应的群集发送通道。例如，如果在群集中一个队列有多个实例，那么群集发送通道将被定义到拥有队列的所有队列管理器。WebSphere MQ使用了一种负载均衡管理算法（轮循机制）来选择一个可用的队列管理器。如果想了解更详细的情况，请参考《WebSphere MQ Queue Manager Clusters》。
6.2 实现应用程序通信
本节主要更详细地介绍WebSphere MQ产品之间的互连通信，阅读本节之前需要理解通道、队列等概念。
6.2.1发送消息到远程队列管理器
这部分描述了把消息从一个队列管理器发送到另一个队列管理器的最简单的方法，发送消息前需要做如下的准备工作：
1. 检查通讯链路，确保可用。
2. 启动队列管理器。
3. 启动通道启动器。
4. 启动侦听程序。
您也需要有合适的WebSphere MQ权限来创建对象。
在源队列管理器上需要定义如下对象：
– 发送通道
– 远程队列定义
– 启动队列 (在z/OS平台上是必须的，其它平台是可选的。)
– 传输队列
– 死信队列 (推荐)
在目标队列管理器上需要定义如下对象：
– 接收通道
– 目标队列
– 死信队列(推荐)
针对不同的平台，您可以使用不同的方法来定义对象：
例如，在OS/2, Windows systems, UNIX systems, and Compaq OpenVMS Alpha 平台，您可以使用《WebSphere MQ Script (MQSC) Command Reference》书中的WebSphere MQ 命令或《WebSphere MQ Programmable Command Formats and dministration Interface》书中PCF 命令。仅在Windows系统中,您可以使用图形界面，WebSphere MQ explorer和WebSphere MQ Web Administration。
定义通道
为了把消息从一个队列管理器发送到另一个队列管理器，您需要定义两个通道；一个是在源队列管理器，另一个是在目标队列管理器。
? 在源队列管理器
定义一个通道类型为SENDER的通道，您需要说明如下属性：
1，使用的传输队列名( XMITQ属性)。
2，目标系统的连接名(CONNAME属性)。
3，正使用的通讯协议 ( TRPTYPE属性)。在 AIX, iSeries, Compaq Tru64 UNIX, HP-UX, OS/2 Warp, Solaris, 和 Windows, 可以不设置这个属性，而使用通道的缺省值。
? 在目标队列管理器
定义一个通道类型为RECEIVER的通道，并且和发送通道同名。设置正使用的通讯协议(TRPTYPE属性)。在 AIX, iSeries, Compaq Tru64 UNIX, HP-UX, OS/2 Warp, Solaris, 和 Windows, 可以不设置这个属性，而使用通道的缺省值。
接收通道的定义都普遍相同，如果您有几个队列管理器同时往同一个队列管理器发送消息，那么发送通道和接收通道都是相同的名字，这样在接收方只要定义一个接收通道就可以负责接收所有的消息。
当已经定义了通道，您可以使用“PING CHANNEL”来测试通道。这个命令从发送通道发送了一个特殊的消息到接收通道，并且检测它的返回情况。
定义队列
为把消息从一个队列管理器发送到另一个队列管理器，您需要定义六个队列；在源队列管理器需要定义四个，目标队列管理器要定义两个。
1，远程队列定义
在这个定义中需要说明下列属性： 远程队列管理器名
目标队列管理器名 远程队列名
在目标队列管理器上的目标队列名。 传输队列名
传输队列的名称，您可以不说明它。如果没有说明这个属性，将会使用一个和目标队列管理器同名的传输队列，或者这个传输队列不存在，将会使用缺省传输队列。建议传输队列名和目标队列管理器同名，以便这个队列在缺省情况下能找到它。
2，启动队列定义
在z/OS平台上，这是必须定义的；其他平台上使可选的。在z/OS平台上您必须定义队列名为“SYSTEM.CHANNEL.INITQ”的启动队列，在其它平台您也可以使用它。
3，传输队列定义
一个本地队列的“USAGE”属性被设置成“XMITQ”。如果您使用了 WebSphere MQ for iSeries ，那么“USAGE”属性是“*TMQ”。
4，死信队列定义—推荐
定义一个死信队列是为了存放不能交付的消息。
1，本地队列定义
目标队列。这个队列名必须和在源队列管理器中的远程队列定义中远程队列名的属性值相同。
2，死信队列—推荐
发送消息
当您把消息放在源队列管理器的远程队列定义中时,这消息将被存放在传输队列中，直到通道被启动。当通道被启动，消息被交付到远程队列管理器的目标队列中。
启动通道
在发送队列管理器上使用“START CHANNEL”命令启动通道。当您启动发送通道时，接收通道将被自动地启动（由侦听程序启动），消息然后被发送到目标队列。消息通道的两端都必须处在“running”状态，消息才能被发送。由于通道的两端是处在不同的队列管理器中，它们使用了不同的属性。
发送消息之前，发送MCA把大消息分割成小消息，然后通过通道发送出去，在目标队列管理器再把这些小消息组装成大消息，这些步骤对用户来说是透明的。一个MCA在传输消息时可以启动多个线程，这种叫“pipelining”的过程能更有效地提高消息传输的效率，从而提高通道的性能。
6.2.2触发通道
下面主要介绍触发的概念，您可以在《WebSphere MQ Application Programming Guide》文档中找到关于触发机制更详细的描述。
图，触发的概念
上图描述了触发所需的对象和事件发生的顺序：
1. 本地队列管理器从应用程序或MCA放一个消息到传输队列。
2. 当触发条件满足时，本地队列管理器产生一条触发消息并放到启动队列。
3. 长期运行的通道启动器监控着启动队列，并检索队列中的触发消息。
4. 通道启动器按照消息中的内容处理触发消息。触发消息中可能包括需要被启动的通道名。
5. 被触发的本地应用程序或MCA将从传输队列中检索消息。
为了配置触发环境，您需要做如下准备工作:
1，创建传输队列，设置启动队列属性为“SYSTEM.CHANNEL.INITQ”。
2，确保启动队列“SYSTEM.CHANNEL.INITQ”存在。
3，确保通道启动程序是可用的并在运行。启动通道启动器时需要提供启动队列名。
4，创建进程定义，如果没有创建，那么确保进程定义的“UserData”属性值包含了通道名，对于 WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris 和 Windows systems, 和
WebSphere MQ for Compaq Tru64 UNIX, 和 OS/2 Warp平台, 可以不创建进程定义，如果不创建进程定义，您可以在传输队列的“TriggerData”属性中设置为通道名。
5，如果使用了进程定义，请确保传输队列定义中包含了进程定义名，和启动队列名，并设置合适的触发条件。
注意:
1. 通道启动器程序充当了“触发监控器”，监控着启动队列，用来启动通道。
3. 可以定义多个启动队列和触发进程。
4. 推荐的触发类型为“FIRST”。
6.2.3消息的安全性
分布式队列管理通过通道两端的同步点协调来确保消息被正确地传输。如果协调过程发现了错误，将关闭通道，把消息安全地存放在传输队列中，直到通道被重新启动。当通道启动时，同步过程可以恢复可疑（in-doubt）状态。处理通道的可疑状态可疑用下列方法：
1. 用提交或回滚的方法Resolve通道。
2. 复位通道的消息序号。
只有意外的情况，才会出现通道可疑的情况，一般情况通道能自动解决可疑状态。
快速, 非永久消息
在 WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, 和 OS/2 Warp平台，通道的NPMSPEED (nonpersistent message speed) 属性可以用来说明任何非永久性消息将更快地传输。当快速、非永久消息在传输中，通道出现了中断，消息可能被丢失。如果接收通道不能把消息放到目的队列时，则将被放到死信队列中；如果死信队列没有定义，那么消息将被丢弃。
6.2.4 WebSphere MQ对象配置实例
6.3通道的维护
6.3.1通道的状态
下图显示了所有可能的通道状态层次结构，在 WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, 和Windows systems, 和 WebSphere MQ V5.1 for OS/2 Warp平台，这些状态对服务器连接通道也适用。
图，通道状态
如果通道的状态分为inactive和current两大类；“current”可以是Stopped,Starting,Retrying和Active的情况。通道Acitve的情况又可分为Initializing,Binding,Requesting,Running,Paused或Stopping的状态。
下图显示通道状态之间的变化关系。
1. 当通道处于INITIALIZING, BINDING, REQUESTING, RUNNING, PAUSED, or或
STOPPING状态时,这将消耗系统资源，并且通道的进程或线程正在运行；因为通道是Active状态。
2. 当通道是STOPPED状态时, 会话可能是active，因为下一个状态时未知的。
6.3.2通道维护命令
下面将详细地介绍通道有关的维护命令。
创建通道
为创建一个新通道，您需要创建两个通道定义，在通信的双方各定义一个。这两个通道的名字必须时相同的，而且两端的通道类型必须匹配，例如：发送和接收。可以使用MQSC命令“DEFINE CHANNEL”来创建通道，在命令中需要指定通道名，通道类型，连接名，通道描述（可选），传输队列名（可选）和传输协议，等还有许多可选的属性可以设置。
建议在WebSphere MQ的网络中所有的通道名唯一，并且通道名中最好包含了源队列管理器名和目标队列管理器名。
创建通道的例子
I
修改通道
可以使用 MQSC命令“ALTER CHANNEL”来修改现有通道定义，但是通道名和通道类型不能修改。
删除通道
可以使用 MQSC命令“DELETE CHANNEL”来删除现有通道定义。
查看通道定义
可以使用 MQSC命令“DISPLAY CHANNEL”来查看现有通道定义。可以说明通道名，通道类型（可选），和其它属性，或查看所有的属性。
查看通道状态
可以使用 MQSC命令“DISPLAY CHSTATUS”来查看现有通道状态。
显示的通道信息包括：
通道名 通信连接名 通道的In-doubt状态 上一个消息序号 传输队列名 in-doubt 标识 上一个提交消息序号 逻辑工作单元标识 进程ID 线程 ID (仅OS/2 和 Windows 支持)
查看通道状态的例子
Ping 通道
使用MQSC 命令“PING CHANNEL”用固定的数据消息来测试和远端的连接.ping通道并没有使用传输队列和目标队列。它只是使用了通道定义、通讯链路和网络设置。只用通道当前状态不是active的情况下才使用它。这个命令只能在发送通道和服务器通道方使用。 命令返回的结果是“Ping complete”或错误消息。
使用MQSC命令“START CHANNEL”启动发送通道、服务器通道和请求器通道。如果通道是采用触发方式启动，那么不用手工执行启动命令。当接收通道处在disabled的状态时，也可以使用“START CHANNEL”命令启动它。在WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, 和Windows systems, 和 WebSphere MQ V5.1 for Compaq Tru64 UNIX, 和 OS/2 Warp,如果服务器连接通道处在disabled状态，也可以使用“START CHANNEL”命令启动它。启动处在disabled状态的接收通道或服务器连接通道，即是复位通道和允许通道被远程启动。当通道被启动时，发送MCA读通道定义文件并打开传输队列，并远程启动相应的接收或服务器通道。
通道启动成功的条件：
1，本地和远端的通道定义必须存在。
2，传输队列必须存在，并且没有其它通道使用它。
3，本地和远程的MCA必须存在。
4，通讯链路必须可用。
5，本地和远程队列管理器必须是处在运行状态。
6，消息通道一定不在运行。
停止通道
使用MQSC命令“STOP CHANNEL”停止通道。停止通道的命令只能对除客户连接之外的通道进行操作。
停止通道的方式：
静态停止（Stop quiesce）
STOP CHANNEL(QM1.TO.QM2) MODE(QUIESCE)
这种方式将顺序地停止通道，必须完成当前的消息处理并确保事务的一致性。
如果通道是空闲的，将不终止接收通道。
强制停止（Stop force）
STOP CHANNEL(QM1.TO.QM2) MODE(FORCE)
这种方式立即停止通道，但不终止通道的线程或进程。通道并没有完成当前的消息处理，因此可能使通道处在可疑的状态。通常，推荐系统管理员使用静态停止通道。
终止停止（Stop terminate）
STOP CHANNEL(QM1.TO.QM2) MODE(TERMINATE)
这种方式立即停止通道，并终止通道的线程或进程。
复位通道
可以使用MQSC命令“RESET CHANNEL”改变消息序号。这个命令可以适用于任何消息通道，但不能用在MQI通道(客户连接或服务器连接)。通道被启动后，将使用新的消息序号。如果是对发送通道或服务器通道进行复位，当下次通道重新启动时将通知通道的另一方。 Resolve通道
从发送通道或服务器通道使用MQSC命令“RESOLVE CHANNEL”来处理可疑的消息。“RESOLVE CHANNEL”命令可以接受 BACKOUT 或 COMMIT参数，Backout将把可疑消息恢复到传输队列，而Commit将丢弃可疑消息。
6.3.3设置MaxChannels和MaxActiveChannels属性
MaxChannels和MaxActiveChannels分别代表队列管理器允许配置的通道的最大个数和允许同时运行的通道的个数，MaxChannels的缺省值是100，MaxActiveChannels的缺省值与MaxChannels相同。如果您的并发通道连接个数超过了100，您需要修改这两个参数。这对于大并发的Client/Server间通讯尤为重要。
例如，在unix平台，修改qm.ini文件如下所示：
6.4配置侦听程序
对于不同的平台或不同的通讯协议，侦听程序的配置也会存在着差别，下面将举例介绍在Windows和unix平台上针对TCP/IP协议的侦听程序的配置过程。
6.4.1 Windows 平台
为了运行WebSphere MQ提供的侦听程序，并把通道作为一个线程运行，则使用RUNMQLSR 命令，例如：
RUNMQLSR -t tcp [-m QMNAME] [-p 1822]
方括号中的参数是可选的。如果使用缺省队列管理器，则不用说明QMNAME；如果使用缺省端口号1414，，则也不用设置端口号的参数。
您可以停止非活动的队列管理器的所有侦听程序，使用如下命令：
ENDMQLSR [-m QMNAME]
如果命令中没有队列管理器名，则是指缺省队列管理器。通道能成功启动之前，必须要启动侦听程序。WebSphere MQ for Windows可以自动地启动队列管理器、通道启动器、通道、侦听程序和命令服务器。可以使用IBM WebSphere MQ Services snap-in工具定义队列管理器的服务。
6.4.2 unix 平台
您可以使用TCP/IP 侦听程序 (INETD) 或WebSphere MQ侦听程序。unix平台的WebSphere MQ侦听程序和Windows平台的一致。
1，使用TCP/IP侦听程序
为了启动unix系统上的通道，需要编辑/etc/services文件和inetd.conf文件。
只有超级用户或root用户才能编辑/etc/services文件。
在文件中增加如下一行：
WebSphere MQ 1414/tcp
其中1414表示侦听端口号，可以选择其它未使用的端口号。
? 编辑/etc/inetd.conf 文件:
WebSphere MQ stream tcp nowait mqm /mqmtop/bin/amqcrsta amqcrsta [-m Queue_Man_Name]
为了使修改的配置生效，需要用root用户执行如下命令：
On AIX:
refresh -s inetd
On other UNIX systems:
kill -1 <process number> 编辑/etc/services 文件:
6.5本章小结
本章主要介绍了WebSphere MQ互连通信的基本概念，例如，分布式组件，死信队列，和远程队列管理器通信。描述了怎样实现应用程序间的通信，把消息从本地队列管理器发送到远程队列管理器。为了确保WebSphere MQ互连通信的可靠性，需要能熟练维护消息通道，并掌握侦听程序的配置步骤。
6.6本章练习
1.实现两个队列管理之间的数据通讯，下列哪一个可以没有？
(1)通信链路。
(2)MCA之间的通讯协议。
(3)远程队列定义。
(4)传输队列。
2.WebSphere MQ的通道总是成对的。
3.传输队列是一种需要定义的特殊队列类型。
4.哪一个是合法的MCA通道类型，并实现从传输队列中发送消息？
(1)发送器通道（Sender）
(2)接收器通道（Receiver）
(3)请求器通道（Requester）
(4)服务器通道（Server）
答案：（1）（4）
5. 修改MQSeries for AIX V5.3的qm.ini文件中的CHANNELS节的属性，从
PipeLineLength=2修改成PipeLineLength=4,将会产生什么效果？
（1） 任何新定义的通道将会启动4个执行线程。
（2） MQSeries Version 5.2系统中的所有通道将有4个执行线程。
（3） 非永久性消息的吞吐量将提高2倍。
（4） 没有影响。
答案：（4）
6. 以下哪一个通道出口可以在WebSphere MQ网络中用来加密消息？
（1） 安全出口（a security exit）
（2） 消息出口（a message exit）
（3） 消息重试出口（a message retry exit）
（4） 消息加密出口（a message encryption exit）
7. 如果SENDER通道的SEQWRAP的属性值和RECEIVER通道值不相同，那
么将会发生什么？
（1） 在通道启动时，以两个通道的SEQWRAP最小值启动。
（2） 通道将不启动。
（3） 在通道启动时，以两个通道的SEQWRAP最大值启动。
（4） 优先考虑SENDER通道的定义值。
（5） 没有任何变化，由SENDER通道进行控制，RECEIVER通道不
能说明SEQWRAP值。
8. 练习实现两个队列管理器之间的双向通信。
第七章 WebSphere MQ 恢复和重新启动 目标
1. 了解WebSphere MQ的数据日志。
2. 学习在出现失败故障后，怎样恢复消息和WebSphere MQ对象。
7.1 WebSphere MQ的数据日志
消息传递系统确保输入到系统的消息被发送到它们的目的地。这意味着它必须提供跟踪系统中消息和恢复消息的方法（如果系统发生故障）。
WebSphere MQ 通过记录队列管理器（处理消息的接收、传输和传递）的活动日志来确保消息不丢失。并提供了三种恢复方式：
1. 重启恢复。
2. 崩溃恢复。
3. 媒体恢复。
在所有情况下，恢复是把队列管理恢复到它停止时的状态，（除了回滚所有执行中的事务）队列管理器停止时未提交的任何消息将被删除。恢复所有永久消息；非持久性消息将被丢失。
WebSphere MQ 把所有由队列管理器控制的数据的重要更改都记录到日志中。 这包括创建和删除对象（除了通道）、永久消息更新、事务状态、更改对象属性以及通道活动。
7.1.1日志的概念
WebSphere MQ 日志包含两个组件：
1. 一个或多个日志文件
2. 日志控制文件
可以在队列管理器的配置文件中配置日志文件的大小和个数。在 WebSphere MQ Windows 版中，三个文件都缺省为 1 MB。在 WebSphere MQ UNIX 系统版中，三个文件都缺省为 4 MB。
创建队列管理器时，您可以指定主日志文件数和从日志文件数以及日志文件的大小。如果不指定数，则使用缺省值。
在 WebSphere MQ Windows 版中，如果未更改日志路径，则日志文件将存放在 C:\Program Files\IBM\WebSphere MQ\log\<QMgrName>目录下；在 WebSphere MQ UNIX 系统版中，如果未更改日志路径，则日志文件将存放在/var/mqm/log/QmName目录下。 WebSphere MQ 在创建队列管理器时会自动创建所有的主日志文件，如果主日志用完了，则会动态地创建次日志文件。当WebSphere MQ不需要从日志空间时，也会动态地删除它们。
7.1.2日志控制文件
日志控制文件包含监控日志文件使用状况的信息，如它们的大小和位置、下一个可用日志文件的名称等等。
确保队列管理器启动时创建的日志足够大，使它能够满足应用程序处理的需要。
7.1.3日志类型
在 WebSphere MQ中，系统所需的日志文件数取决于日志文件大小以及接收到的消息数和消息长度。
日志记录的形式有两种：循环日志和线性日志。
循环日志记录
如果您的WebSphere MQ系统恢复使用“重启恢复”就可以满足要求，则可使用循环日志，当系统停止时，正在处理的事务通过日志进行回滚操作。
循环日志是把所有重启数据都记录在日志文件环中。首先使用第一个日志文件，然后下一个，依次类推，直到所有文件都满为止。然后它回到环中的第一个文件又重新开始。只要产品在使用中，就会一直循环下去，并且具有永远不会用完日志文件的优点。
线性日志记录
如果您的WebSphere MQ系统恢复需要使用“重启恢复”和“媒体恢复” （通过重播日志内容重新创建已丢失或已损坏的数据）才能满足要求，则使用线性日志。
线性日志记录在连续文件中保留日志数据。它不重用空间。由于磁盘空间是有限的，您可能需要考虑归档方式，来管理日志的磁盘空间，必要时重用或扩展现有的空间。
使用线性日志，则日志文件数可能非常大，这取决于您的消息流和您的队列管理器寿命。但是，有许多文件是活动的。活动文件包含重新启动队列管理器所需的日志信息。活动日志文件数通常与配置文件中定义的主日志文件数相同。
WebSphere MQ 检查点是一组日志记录，包含重新启动队列管理器成功的信息。重新启动队列管理器不需要的以前的任何记录信息，称为非活动的。
您必须确定何时不再需要非活动的日志文件。则可以压缩或者删除它们。
7.1.4计算日志的大小
确定队列管理器应该使用循环还是线性日志后，您需要估计队列管理器需要的日志大小。日志大小是由以下日志配置参数确定的：
LogFilePages
每个主和次日志文件的大小是以4K为单位。
LogPrimaryFiles
预分配的主日志文件数
LogSecondaryFiles
主日志用完后，可创建的次日志文件数。
下表显示了队列管理器各种操作所消耗的日志数据量。大多数队列管理器操作只需要最少量的日志空间。 但是，当永久消息放入队列时，所有消息数据必须写入日志，以便它能够恢复此消息。通常，日志大小取决于队列管理器需要处理的永久消息的数量和大小。 表 日志开销大小（参考值）
1. 每次启动队列管理器时，您可以修改主和从日志文件数。
2. 日志文件大小只能在创建队列管理器前确定，以后不能修改。
3. 主日志文件的数量和日志文件大小决定了队列管理器创建时预分配的日志空间，这些空
间应该是由少量的大文件组成，而不是由大量的小文件组成的。
4. 主日志文件和次日志文件的总数不能超过63个文件，这是针对循环日志而言， 线性日
志则不受限制。
5. 当使用循环日志记录时，队列管理器重用主日志空间。主日志文件已满时，队列管理器
将分配一个次日志文件（最多到限定值）。
7.2 使用数据日志进行恢复
下列几种情况可能会损坏您的数据：
? 数据对象被损坏 系统掉电 通信故障
但WebSphere MQ可以帮助您恢复被破坏的数据。本节将描述如何使用日志进行数据恢复。
7.2.1从掉电或通信故障中恢复
WebSphere MQ 可以从通信故障和掉电中进行恢复。另外，它有时还可以从其它类型的问题中进行恢复，例如，文件被意外删除。 在通信故障情况下，消息一直保留在队列中直到被接收应用程序取出。如果消息正在传输中，则消息将一直被保留在传输队列中直到被成功传输。要从通信故障中恢复，通常您可以重新启动使用失败的链接的通道。
如果您掉电了，则重新启动队列管理器时，WebSphere MQ 把队列恢复到失败时的已提交的状态。确保不丢失持久消息。但非持久性消息被丢弃；当WebSphere MQ 停止时会丢弃它们。
7.2.2恢复受损对象
有些情况可以使 WebSphere MQ 对象成为不可用的，例如，由于无意中的损坏。您不得不恢复整个系统或部分系统。恢复操作与发现损坏的时间、日志是否支持媒体恢复和被损坏的对象有关。
7.2.2.3媒体恢复
媒体恢复是从线性日志中的记录信息重新创建对象。例如，如果无意中删除了一个对象文件，则媒体恢复可以重新创建它。用于对象媒体恢复的日志信息被叫做媒体映象。媒体映象可以通过使用rcdmqimg 命令手工记录或自动记录。 媒体映象中包含对象映象的日志记录序列。
重新创建对象所必需的第一个日志记录叫作媒体恢复记录；它是对象的最后一个媒体映象的开始。每个对象的媒体恢复记录是检查点期间记录的信息之一。
从媒体映象重新创建对象时，有必要重播任何描述自采用最后一个映象以来对对象执行更新的日志记录。
例如，考虑在持久消息放入到队列前，采用具有队列对象映象的本地队列。为了重新创建最新的对象映象，有必要重播记录消息放入队列的日志条目，并重播该映象本身。
创建对象时，已编写的日志记录包含完全重新创建此对象所需的足够的信息。这些记录组成对象的第一个媒体映象。接着，每次关机时，队列管理器记录媒体映象自动执行如下操作：
? 所有进程对象和队列的映象不是本地的。 空的本地队列的映象
还可以使用 rcdmqimg 命令手工记录媒体映象，在rcdmqimg（记录媒体映象）中对它进行了描述。此命令编写 WebSphere MQ 对象的媒体映象。一旦这样做了，仅保持媒体映象的日志和此时后创建的所有日志需要重新创建受损的对象。这样做的好处取决于某些因素，如可用的空闲存储器量和创建日志文件时的速度。
7.2.2.4恢复媒体映象
如果发现某些对象被损坏，则 WebSphere MQ 自动从它们的媒体映象中进行恢复。特别地，这适用于正常队列管理器启动期间所找到的受损对象。如果队列管理器最后一次关机时有任何未完成的事务，则也会自动恢复任何受影响的队列，以便完成启动操作。
您必须使用 rcrmqobj 命令手工恢复其它对象，它会重播日志中的记录以重新创建 WebSphere MQ 对象。从日志中找到的最新映象中重新创建此对象，并带有保存此映象和发出重新创建命令期间所有可用的日志事件。如果 WebSphere MQ 对象受损，则仅可执行的有效操作是使用此方法删除或重新创建它。 不能用此方法恢复非持久性消息。 请参阅rcrmqobj（重新创建对象）以获得 rcrmqobj 命令的进一步详细信息。
包含媒体恢复记录的日志文件和所有后继的日志文件，在尝试对象的媒体恢复时必须在日志文件中可用。如果找不到必需的文件，发出操作程序消息 AMQ6767，并且媒体恢复操作失败。如果您不采用要重新创建的对象的常规媒体映象，则可能没有足够的磁盘空间来保持重新创建对象所必需的所有日志文件。
7.2.2.5启动期间恢复受损的对象
如果队列管理器启动期间发现受损的对象，则所使用的操作取决于对象类型和队列管理器是否配置成支持媒体恢复。
如果队列管理器对象受损，则该队列管理器无法启动，除非它可以恢复该对象。如果队列管理器配置成使用线性日志，并支持媒体恢复，则 WebSphere MQ 自动尝试从其媒体映象中重新创建此队列管理器对象。如果所选的日志方法不支持媒体恢复，则可以恢复队列管理器的备份或删除该队列管理器。
如果队列管理器停止时任何事务都是活动的，则包含持久的、未提交的消息（在这些事务中放入或取出）的本地队列还需要成功启动该队列管理器。如果发现这些本地队列中的任何一个受损，并且队列管理器支持媒体支持，它自动尝试从其媒体映象中重新创建它们。如果无法恢复任何队列，则 WebSphere MQ 无法启动。
如果启动不支持媒体恢复的队列管理器的处理期间，发现任何包含未提交的消息的受损本地队列，则这些队列标记为受损对象，并且忽略它们上面的未提交的消息。这是因为不可能执行这样的队列管理器上的受损对象的媒体恢复，并且仅留下的操作是删除它们。发出 AMQ7472 消息报告任何损坏。
7.2.2.6在其它时间恢复受损的对象
仅在启动期间对象的媒体恢复是自动的。在其它时间，检测到受损对象时，发出操作程序消息 AMQ7472，并且使用此对象的大多数操作失败。如果启动队列管理器后的任何时间该队列管理器对象受损，则该队列管理器执行抢先关机。队列管理器受损后您可以删除它，或者如果该队列管理器使用线性日志，则尝试使用 rcrmqobj 命令（请参阅rcrmqobj（重新创建对象）以获得进一步的详细信息）从其媒体映象中恢复它。
7.3保护 WebSphere MQ 日志文件
WebSphere MQ 队列管理器运行时不要手工除去这些日志文件。如果用户无意删除了队列管理器需要重新启动的那些日志文件，则 WebSphere MQ 不发出任何出错消息，并且继续处理包含持久消息的数据。队列管理器正常关机，但是无法重新启动。则消息的媒体恢复就不可能了。
具有除去活动队列管理器使用的日志权限的用户也具有删除其它重要队列管理器资源（如队列文件、对象目录和 WebSphere MQ 可执行文件）的权限。因此，他们能够以针对 WebSphere MQ 无法保护其本身的途径损坏正在运行的或处于睡眠状态的队列管理器（可能是由于缺乏经验所致）。 所以授予超级用户或 mqm 权限时要谨慎。
7.4备份和恢复 WebSphere MQ
您可能要定期备份您的队列管理器数据以保护由硬件故障导致的可能的破坏。但是，由于消息数据通常是短期的，您可以选择不进行备份。
7.4.1备份 WebSphere MQ
要备份队列管理器的数据：
1. 确保队列管理器不在运行。如果您尝试备份正在运行的队列管理器，备份可能会不一致，因为文件复制时正在进行更新。
如果可能，以正常方法停止您的队列管理器。尝试执行 endmqm -w（等待关机）；仅当其失败时，使用 endmqm -i（立即关机）。
2. 使用配置文件中的信息，查找队列管理器放置其数据和日志文件的目录。
3. 备份所有队列管理器的数据和日志文件目录，包括所有子目录。
确保没有丢失任何文件，特别是日志控制文件和配置文件。某些目录可以为空，但是以后恢复备份时全部需要，因此也要保存它们。
4. 保留文件的权限。对于 WebSphere MQ UNIX 系统版，可以用 tar 命令完成。
7.4.2恢复 WebSphere MQ
要恢复队列管理器的数据备份：
1. 确保队列管理器不在运行。
2. 查找队列管理器放置其数据和日志文件的目录。此信息保持在配置文件中。
3. 清除您要放置备份数据的目录。
4. 把备份的队列管理器数据和日志文件复制到正确的位置。
检查结果目录结构，确保您有所有必需的目录。
确保您有日志控制文件和日志文件。还请检查 WebSphere MQ 和队列管理器配置文件是是否一致，以便 WebSphere MQ 可以在正确的位置查看恢复的数据。
如果正确备份和恢复了数据，则将启动队列管理器。
即使队列管理器数据和日志文件保持在不同的目录，但必须是在相同时间备份的。如果队列管理器数据和日志文件的备份时间不同，则队列管理器无效，并且可能会不启动。如果启动，您的数据很可能被损坏。
7.5恢复方案
本节针对许多可能出现的问题并讲解如何进行恢复。
7.5.1磁盘故障
您可能会遇到存放队列管理器数据或/和日志的磁盘出故障、数据被丢失或数据被破坏的情况。
在所有情况下，首先检查任何受损的目录结构，若有必要，修复它。如果您丢失队列管理器数据，则队列管理器目录结构可能已受损。如果这样，重新启动该队列管理器前手工重新创建该目录树。
检查受损的结构后，您可以做许多事，这取决于您所使用的日志类型。
? 目录结构的主要受损处或日志的任何受损处在哪里，全部除去旧文件返回到 QMgrName ? 级别，包括配置文件、日志和队列管理器目录，恢复最近的备份并重新启动队列管理器。 对于具有媒体恢复的线性日志记录，确保该目录结构是完整的，并且重新启动该队列
管理器。如果队列管理器不重新启动，则恢复备份。如果队列管理器重新启动，则使用 MQSC 命令（如 DISPLAY QUEUE）检查是否已损坏了任何其它对象。使用 rcrmqobj 命令恢复您找到的损坏。例如：
rcrmqobj -m QMgrName -t all *
其中 QMgrName 是要恢复的队列管理器。-t all * 表明要恢复任何类型的所有对象（除了通道外）。如果只有一个或两个对象报告受损了，则您可以在此处按名称和类型指定那些对象。
? 对于具有媒体恢复和未受损的日志的线性日志记录，您可以恢复队列管理器数据的备
份，保留现有日志文件和未更改的日志控制文件。启动队列管理器会应用日志的更改，把队列管理器置回故障发生时的状态。
该方法基于两个因素：
1. 您必须把检查点文件恢复为队列管理器数据部分。此文件包含一些信息，这些信息
确定必须应用日志中的多少数据才能给出一致的队列管理器。
2. 备份时，您必须具有启动队列管理器所必需的最旧的日志文件和此日志文件目录中
所有的后继日志文件。
如果没有，则恢复队列管理器和日志的备份，它们是在同一时间备份的。
? 对于循环日志记录，从您具有的最近备份中恢复队列管理器。一旦您恢复了备份，重新
启动队列管理器并如上所述检查受损的对象。但是，由于您没有媒体恢复，因此，必须找到重新创建受损对象的其它方法。
7.5.2受损的队列管理器对象
如果正常操作期间报告了队列管理器对象受损，则该队列管理器执行抢先关机。根据您使用的日志记录类型，这些情况下有两种恢复方法：
? 仅对于线性日志记录，手工删除包含受损对象的文件，并重新启动该队列管理器。（您
可以使用 dspmqfls 命令确定受损对象的真实的文件系统名。受损对象的媒体恢复是自动的。
对于循环或线性日志记录，恢复队列管理器数据和日志的最近备份，并重新启动此队列管理器。 ?
7.5.3受损的单个对象
如果正常操作期间报告单个对象受损：
? 对于线性记录日志，从其媒体映象中重新创建此对象。 对于循环日志记录，不支持重新创建单个对象。
7.5.4自动媒体恢复故障
如果带有线性日志的队列管理器启动所必需的本地队列受损了，并且自动媒体恢复失败，则恢复该队列管理器数据和日志的最近备份并重新启动该队列管理器。
7.6使用 dmpmqlog 命令转储日志
使用 dmpmqlog 命令转储队列管理器日志的内容。缺省情况下，转储所有活动的日志记录，即，该命令从日志头开始转储（通常从最近完成的检查点开始）。
通常仅当队列管理器不运行时才能转储日志。由于队列管理器在停止时会采用检查点，因此日志的活动部分通常包含少量的日志记录。然而，您可以设置以下选项之一使用 dmpmqlog 命令转储更多日志记录：
? 从日志基开始转储。这些日志基是日志文件中包含日志头的第一个日志记录。该情
况中的其它转储数据量取决于日志头在日志文件中的位置。如果它靠近日志文件的开头，则仅转储小量的其它数据量。如果头在日志文件的结束部分，则转储更多重要的数据。
? 指定转储的开始位置作为个别的日志记录。每个日志记录是由日志序列号（LSN）
标识的。在循环日志记录情况中，开始的日志记录不能在日志基之前；此限制不适用于线性日志。您可能需要在运行命令之前恢复非活动的日志文件。必须指定一个有效的 LSN，从前一个 dmpmqlog 输出中获取它以作为开始位置。
例如，使用线性日志记录时，您可以从最近的 dmpmqlog 输出指定 nextlsn。nextlsn 在日志文件头中出现，并表明要编写的下一个日志记录的 LSN。使用它作为开始位置，对所有自最近一次转储日志以来所编写的所有日志记录进行格式化。
? 仅对于线性日志，您可以说明 dmpmqlog 从任何给定日志文件范围开始格式化日
志记录。在这种情况下，dmpmqlog 期望在与活动日志相同的目录中查找此日志文件和每个后继的日志文件。此选项不适用于循环日志，其中 dmpmqlog 无法访问日志基之前的日志记录。
dmpmqlog 命令的输出是日志文件头和一系列已格式化的日志记录。队列管理器使用几个日志记录记录对其数据的更改。
某些已格式化的信息仅用于内部使用。以下表包括最有用的日志记录：
日志文件头
每个日志有单个日志文件头，它总是由 dmpmqlog 命令格式化的第一项。它包含以下字段：
日志中的每个日志记录有一个包含以下信息的固定头：
启动队列管理器
队列管理器已启动的日志。
停止队列管理器
队列管理器已停止的日志。
这表示队列管理器检查点的启动。
结束检查点
这表示队列管理器检查点的结束。
持久消息放入队列的日志。如果消息放到同步点下，则日志记录头包含非空的 XTranid。其余记录包含：
对于单个日志记录来说太大的持久消息记录为单个放入消息记录，后跟多个放入部
仅记录取出的持久消息。如果在同步点下取出消息，则日志记录头包含非空的 XTranid。其余记录包含：
表明新事务的启动。MQI 的 TranType 表明仅 WebSphere MQ 事务。XA 的 TranType 表明涉及其它资源管理器的事务类型。由该事务所做的所有更新将具有相同的 XTranid。
准备事务
表明队列管理器已准备好提交与指定的 XTranid 相关联的更新。此日志记录作为涉及其它资源管理器的两阶段提交部分而编写。
提交事务
表明队列管理器已由事务提交了所有更新。
回滚事务
这表示队列管理器的目的是回滚事务。
结束事务
这表示已回滚的事务结束。
事务表
此记录是在同步期间编写的。它记录已进行持久更新的每个事务的状态。对于每个事务，记录以下信息：
此日志记录由队列管理器的 XA 事务管理器组件编写。它记录参与事务的外部资源管理器。对于每个参与者，记录以下信息：
此日志记录由队列管理器的 XA 事务管理器组件编写。它表明已成功准备好指定的全局事务。将说明每个参与资源管理器的事务进行提交。日志记录中记录每个已准备的资源管理器的 RMID。如果队列管理器本身参与到事务中，则将显示带有 O 的 RMID 的
参与者条目。
事务忘记
此日志记录由队列管理器的 XA 事务管理器组件编写。当提交决定已发送到每个参与者时，它跟在已准备的事务日志记录后面。
清除队列
它记录已清除队列上的所有消息这一事实，例如，使用 MQSC 命令 CLEAR QUEUE
。
队列属性
它记录队列属性的初始化或更改。
创建对象
它记录 WebSphere MQ 对象的创建。
它记录 WebSphere MQ 对象的删除。
7.7本章小结
记录数据日志是队列管理器的一个重要部分。数据日志是顺序地记录在日志文件中，队列管理器的配置文件中说明了日志参数，缺省的日志参数则是在WebSphere MQ配置文件中说明的。数据日志参数包括主日志和从日志数、日志类型和日志目录的路径。确保有足够的日志空间，否则如果磁盘空间不足，将导致对队列管理器的操作失败。
主日志文件是在队列管理器创建时分配的，并且随后它的个数保持不变。从日志仅在主日志用完以后才开始分配。
7.8本章练习
1.下列那些队列管理器有记录数据日志的功能？
（1） WebSphere MQ for MVS/ESA
（2） WebSphere MQ for OS/2 Warp
（3） WebSphere MQ for HP-UX
（4） WebSphere MQ for AS/400
（5） WebSphere MQ for AIX
答案：（1）（2）（3）（4）（5）
2， 在AIX平台上，WebSphere MQ支持的两种类型是：
（1） journaling
（2） linear
（3） circular
（4） checkpointing
答案：（2）（3）
第八章 WebSphere MQ 问题诊断
1． 描述在那儿能找到能确定问题的消息日志。
2． 学习启动和停止WebSphere MQ的跟踪功能。
8.1错误日志
WebSphere MQ 使用许多错误日志来捕捉WebSphere MQ自身的操作、任何队列管理器的启动和正在使用的通道的错误信息。
错误日志的位置取决于队列管理器名，以及错误是否与客户机相关。
在 WebSphere MQ Windows 版中，假设 WebSphere MQ 已经安装在缺省位置中： ? 如果队列管理器名称是已知的，则错误日志位于：
c:\Program Files\IBM\WebSphere MQ\qmgrs\qmname\errors
? 如果队列管理器不是已知的，则错误日志位于：
c:\Program Files\IBM\WebSphere MQ\qmgrs\@SYSTEM\errors
? 如果错误发生在客户机应用程序，则错误日志位于客户机的根目录中：
c:\Program Files\IBM\WebSphere MQ Client\errors
在 WebSphere MQ Windows 版中，错误信息也被添加到应用程序日志中，所以可以通过查看Windows系统的事件查看器来检查WebSphere MQ的错误日志。
在 WebSphere MQ UNIX 系统版中：
? 如果队列管理器名称是已知的并且队列管理器是可用的，则错误日志位于： /var/mqm/qmgrs/qmname/errors
? 如果队列管理器不是可用的，则错误日志位于：
/var/mqm/qmgrs/@SYSTEM/errors
? 如果错误发生于客户机应用程序，则错误日志位于客户机的根目录中：
/var/mqm/errors
8.1.1日志文件
在产品安装时，在qmgrs 目录下将创建@SYSTEM errors子目录。errors子目录最多可以包含 3 个错误日志文件，分别是：
? AMQERR01.LOG AMQERR02.LOG AMQERR03.LOG
在创建队列管理器后，在需要时将创建了 3 个错误日志文件。这些文件名是，AMQERR01、AMQERR02 和 AMQERR03 并且每一个文件的大小都为256 KB。这些文件被放置在您创建的队列管理器的errors子目录中。
当产生错误消息时，它们被放置在 AMQERR01 中。当 AMQERR01文件比 256 KB 大时，将其复制成AMQERR02。在复制前，将 AMQERR02 复制到 AMQERR03.LOG。这样将删除了AMQERR03的以前内容。
因此最新的错误消息总是放在 AMQERR01 中的，其它文件用来保存错误消息的历史记录。
所有与通道相关的信息也被放在相应的队列管理器的错误文件中，除非队列管理起步可用或队列管理器的名称未知，则通道相关的消息是放在 @SYSTEM 错误子目录。
使用通常的系统编辑器就可以查看错误日志文件的内容。
有些错误是在错误日志还没有创建时发生的，WebSphere MQ 也会尝试记录这样的错误日志。日志的位置取决于创建队列管理器的过程进展情况。
如果配置文件被损坏，WebSphere MQ不能读取目录信息，则将错误记录到在安装时创建的根（/var/mqm 或 C:\Program Files\IBM\WebSphere MQ）的errors目录中。
如果 WebSphere MQ 可以读取配置信息，并且可以访问 Default Prefix 的值，则错误记录在由 Default Prefix 属性标识的目录的errors子目录中。例如，如果缺省前缀为 C:\Program Files\IBM\WebSphere MQ，则错误在 C:\Program Files\IBM\WebSphere MQ\errors 中记录。
8.1.2忽略WebSphere MQ for Windows的错误代码
如果您要忽略WebSphere MQ Windows的错误代码，则编辑 Windows 注册表。
注册表键是：
HKEY_LOCAL_MACHINE\Software\IBM\MQSeries\CurrentVersion\IgnoredErrorCodes
它的值是由 NULL 字符分隔的字符串数组，例如，如果您要 WebSphere MQ 忽略错误代码 AMQ3045、AMQ6055 和 AMQ8079，则将值设置为：AMQ3045\0AMQ6055\0AMQ8079\0\0
您对配置文件所做的任何修改，只有在下一次启动队列管理器时才能生效。
8.1.3操作信息
操作信息是指一般的错误信息，通常由用户在命令上使用无效的参数等类似操作时直接引起。这些信息被写到相关的窗口中。另外，一些操作信息被写到队列管理器目录中的 AMQERR01.LOG 文件的，而其它是写到错误日志的 @SYSTEM 目录副本中。
8.2死信队列
出于某种原因无法发送的消息都被放置在死信队列。您可以通过 MQSC 命令 DISPLAY QUEUE 来检查队列是否包含消息。如果队列包含消息，则使用所提供的浏览样本应用程序（amqsbcg）来浏览队列上的消息。样本应用程序将显示每个消息的消息描述符和消息上下文字段。您应该通过分析消息的死信头来确定消息被放在死信队列的原因。
8.3配置文件和问题确定
配置文件错误通常找不到队列管理器，和导致队列管理器不可用。确保配置文件存在，并且 WebSphere MQ 配置文件必须和队列管理器和日志目录对应。 在 Windows 注册表中的错误是在启动队列管理器时，通过消息通知的。
8.4跟踪
本节描述了如何产生WebSphere MQ跟踪信息。
8.4.1WebSphere MQ Windows的跟踪
在 WebSphere MQ Windows 版中，您可以使用 strmqtrc 控制命令启用或修改跟踪；使用 endmqtrc 控制命令停止跟踪。您还可以使用 WebSphere MQ 服务管理单元启动和停止跟
踪。
8.4.1.1跟踪的选项
使用 -t 和 -x 选项控制跟踪信息量的详细程度。缺省情况下，启用所有跟踪信息。-x 选项指定不需要跟踪的信息。
例如，如果您仅跟踪队列管理器 QM1在通信网络上流动的数据，则使用：
strmqtrc -m QM1 -x all -t comms
8.4.1.2跟踪文件
在安装过程期间，您可以选择跟踪文件的存放路径。跟踪文件一般放置在目录 \<mqmwork>\errors 中，其中 <mqmwork> 是WebSphere MQ 数据文件的安装目录。
跟踪文件名的格式如下：
AMQppppp.TRC
其中 ppppp 是产生跟踪的进程的进程标识（PID）。
1. 进程标识号的数字位数不是固定的。
2. 每个被跟踪的进程都有一个跟踪文件。
8.4.1.3跟踪数据的示例
下图显示了WebSphere MQ Windows版的跟踪数据：
8.4.2WebSphere MQ AIX的跟踪
WebSphere MQ AIX 使用AIX系统标准跟踪。跟踪分为两步：
1. 采集数据 。
2. 格式化结果数据。
WebSphere MQ 使用两个跟踪 hook 标识：X'30D' 和X'30E' 。
跟踪提供了执行跟踪的详细信息来帮助您分析问题。跟踪产生的文件可能非常大，所以合理地设置跟踪。例如，您可以通过时间和组件来限定跟踪。
有两种运行跟踪的方法：
1. 交互地。
以下命令是对程序 myprog 运行了交互式跟踪并结束跟踪。
trace -j30D,30E -o trace.file
->!myprog
->q
2. 异步地。
以下命令对程序 myprog运行了异步跟踪和结束跟踪。
trace -a -j30D,30E -o trace.file
myprog
trcstop
您可以用以下命令格式化跟踪文件：
trcrpt -t /usr/mqm/lib/amqtrc.fmt trace.file > report.file
report.file 是存放格式化的跟踪输出的文件名。
当跟踪是活动的，将跟踪所有的WebSphere MQ 活动。
8.4.2.1跟踪选项
可使用环境变量 MQS_TRACE_OPTIONS来分别激活高级详细信息和参数跟踪的功能。下表定义了MQS_TRACE_OPTIONS的各种配置的跟踪行为。
表，MQS_TRACE_OPTIONS 设置
1. 最好需要在技术支持人员的指导下，设置MQS_TRACE_OPTIONS环境变量。
2. 通常在启动队列管理器之前设置MQS_TRACE_OPTIONS。
3. 在跟踪开始前设置 MQS_TRACE_OPTIONS。 8.4.2.2 SSL 跟踪
如果您请求 SSL 跟踪，请注意以下内容：
? SSL 跟踪是写到目录 /var/mqm/trace 的。 SSL 跟踪文件是 AMQ.SSL.TRC 和 AMQ.SSL.TRC.1。
? 您无法格式化 SSL 跟踪文件；将它们原封不动地发给IBM 技术支持中心。
8.4.2.3跟踪数据的示例
下图显示了WebSphere MQ AIX跟踪的数据：
8.5首次故障支持技术（FFST）
本节描述了 WebSphere MQ 的首次故障支持技术（FFST）的角色。
8.5.1FFST: WebSphere MQ Windows 版
在 WebSphere MQ Windows 版中，FFST 信息是存放在 c:\Program Files\IBM\WebSphere MQ\errors 目录下的文件中。这些错误通常都是严重的、不可恢复的错误，要么是系统的配置问题或 WebSphere MQ 内部错误。
FFST 文件命名为 AMQnnnnn.mm.FDC，
其中：nnnnn 是报告错误进程的标识
mm 是顺序号，通常为 0
当进程创建了 FFST 记录时，它还将记录发送到事件日志（应用程序级别）中。记录包含 FFST 文件的名称来辅助自动问题跟踪。下图显示了典型的 FFST 日志。
IBM使用函数堆栈和跟踪历史来辅助定位问题。在大多数情况下，当生成 FFST 记录时，系统管理员基本上不能自己解决问题，而需要寻求IBM 支持中心的帮助。
8.5.2FFST: WebSphere MQ UNIX 系统版
对于 WebSphere MQ UNIX 系统版，FFST 信息是存放在 /var/mqm/errors 目录的文件中。 这些错误通常都是严重的、不可恢复的错误。要么时系统的配置问题或 WebSphere MQ 内部错误。
文件命名为 AMQnnnnn.mm.FDC，其中：
nnnnn 是报告错误进程的标识
当进程创建了FFST 记录时，它也将一条记录发送到系统日志（用户级）中。记录包含 FFST 文件名用来辅助自动问题跟踪，下图显示一些典型的 FFST 数据。
然而，有些问题是系统管理员可以解决的。如果FFST 显示当调用 IPC函数（例如，semop或 shmget）时资源用尽或空间用尽，则可能是已经超出了相关的内核参数极限。
如果 FFST报告显示问题 setitimer，则可能需要修改内核定时器参数。 要解决这些问题，增加 IPC 限制、重新建立内核并重新启动机器。
8.6本章小结
8.7本章练习
1. 如果队列管理器出现了故障，那么错误信息将记录在下列那个文件中？
（1） QMGRERR
（2） ERRORS
（3） amqerr01.log
（4） AMQERR.001
2. 当队列管理器出现故障重新启动后，非永久性消息能够得到恢复。
（1） 对
（2） 错
第三部分 Websphere MQ 应用开发
第九章 设计Websphere MQ应用程序 目标
1． 介绍消息和队列的概念。
2． 描述使用WebSphere MQ提供的服务怎样设计和编写应用程序。
9.1介绍应用设计
9.1.1 规划设计
首先需要明确操作系统的平台和环境，针对WebSphere MQ，需要考虑以下因素：
1．队列类型
是使用永久队列、动态队列还是别名队列。
2．消息类型
是使用数据报消息还是请求消息，在一些消息中是否设置不同的优先级。
3．应用程序是否在WebSphere MQ Client运行？
在WebSphere MQ Server 和WebSphere MQ Client运行程序所链接的库是不一样的，运行在WebSphere MQ Client的程序需要链接MQIC库；而运行在WebSphere MQ Server的程序需要链接MQI库。
注意：运行在WebSphere MQ Client的应用程序可以同时连接多个队列管理器。但是运行在WebSphere MQ Server的应用程序不能同时连接多个队列管理器
4．数据的安全性和完整性
可以使用上下文信息来验证数据的安全性，使用同步点机制来确保数据的一致性。也可以使用消息的永久性特征来确保重要数据的传递。
5．怎样处理意外和错误
需要考虑怎样处理不能交付的消息，以及怎样处理队列管理器产生的报告消息。
9.1.2 WebSphere MQ 对象
MQI可以使用以下对象：
? 队列管理器 队列 名字列表 进程定义
? 通道 存储类（仅WebSphere MQ for Z/OS支持） 授权信息对象 （AUTHINFO objects）
除动态队列之外，其他对象都需要在定义之后使用。定义的方法有PCF，MQSC，这些对象被定义之后可以被查看，修改和删除。
9.1.3 设计消息
当使用MQI接口PUT消息到队列中时，将产生一个消息。该消息有控制信息（Message Description）和应用数据组成，在应用程序中使用消息时，需要考虑以下因素：
? 消息类型
在应用程序中的消息是一个简单消息，还是一个请求消息。如果是请求消息，请求-回复的处理方式是异步还是同步。还有就是所有的消息是否在同一个工作单元。 ? 消息优先级
在发送应用程序中可以为每个消息设置优先级再放到队列中。如果队列的消息交付方式也设置为优先级方式，则接收程序将总是先取出优先级最高的消息。如果队列的消息交付方式也设置为先进先出方式，则接收程序将按先进先出方式取出队列中的消息。
? 消息的永久性
当队列管理器重新启动，是否希望保留队列中的消息，如果需要保留，则把消息设置成永久性的，如果不需要保留，则把消息设置成非永久性的。
9.1.4 WebSphere MQ 技术
如果仅编写一个简单的WebSphere MQ应用程序，只需要确定在应用程序中使用的WebSphere MQ对象和消息类型，对于编写更高级的应用程序，可能会使用如下技术：
? 等待消息
可以采用轮循机制从队列中取出消息或设置等待消息时间，如果消息到达则取出，否则超时则返回。
? 关联回复
把请求消息中的消息标识（MsgId）复制到回复消息的关联标识（CorrelID）中。
? 上下文信息（Context information）
上下文信息对于安全，审计和问题确定是很有用。
? 自动启动WebSphere MQ应用程序
WebSphere MQ触发机制，当消息到达队列时，自动启动应用程序处理消息。
? 产生消息报告
在应用程序可以请求产生多种报告消息，例如，意外报告（Exception reports）、失效报告(Expiry reports)、到达确认报告(Confirm-on-arrival reports)、交付确认报告(Confirm-on-delivery reports)、PAN报告（Positive action notification reports）和NAN报告(Negative action notification reports)等。
? 群集和消息的紧密联系
在WebSphere MQ群集里，消息可以被放到群集中任何队列管理器的相应队列，因此消
息间的紧密联系可能被变得松散。
9.1.5应用编程
WebSphere MQ支持IBM MQI(Message Queue Interface)和AMI（Application Messaging Interface）。MQI包括一些发送和接收消息以及操作WebSphere MQ对象的API调用。AMI是一个比MQI更简单的调用接口。
调用接口
MQI接口可以实现以下功能：
? 连接和断开队列管理器。
? 打开和关闭对象（例如，队列、队列管理器和名字列表和进程） 放消息到队列中。 从队列中接收消息或浏览消息。 查询WebSphere MQ对象的属性，并可以设置队列的某些属性。 提交和回滚事务。 协调队列管理器与别的资源管理器的更新。
MQI接口提供了放消息和取消息的结构。也提供了许多常量。
应用程序的性能
? 使应用程序的处理尽量并行操作。 MQCONN/MQDISC是最耗CPU的两个函数，其次是MQOPEN和MQCLOSE这两个
函数，因此要尽量避免必要地重复使用这几个函数。比如，当您需要从队列中读取多条消息时，正确的编程方法应该如下：
MQCONN
MQOPEN
MQGET
.
MQCLOSE
MQDISC
即：连接/断开队列管理器一次，打开/关闭队列一次，读取消息多次。而不应该反复建立与队列管理器的连接和反复进行队列打开/关闭操作。
? 如果应用程序放一条消息到队列中，则应该使用MQPUT1函数。
? 当处理一批消息时，可以采用MQCMIT函数，将若干消息作为一个完整的交易来处理，
消息将作为一个batch统一提交，而不是一个个地分别提交，因此，可以提高性能。尤其对于永久性的消息效果更加明显。
尽量减小消息的大小，小消息的读取效率要高。对于mqget, mqput这两个函数而言，8k以下的消息的耗时差别不大，8k到128k的消息的耗时随着消息大小的增加而增加。大于128k的消息耗时较大，因为当与队列相关的内存满了的时候，会有硬盘交换。 同时要注意，从传输效率而言，如果在广域网上进行消息传输，消息太小会影响传输效率，因为对于每一消息，MQ都会有一个消息头，它会占有一定的字节数，如果把消息拆分太小，每个消息的传输头都会占据一定的开销。 ? ?
? 如果消息不必可恢复，则在应用程序中可使用非永久性消息。 使用Distribution List 方式来把相同的消息发往不同的目的地。 用match correlation ID的方法取消息比不匹配性能要差。 通常，我们使用MQCONN这个函数建立与队列管理器的连接，除此之外，MQ支持
trusted application binding，即fastpath binding，用MQCONNX来实现。当从性能方面考虑时，我们可以使用MQCONNX来提高性能。
9.1.6 测试应用程序
WebSphere MQ应用程序的开发环境和其他应用程序的一样。因此您可以使用和WebSphere MQ trace工具一样的开发工具。
9.2 WebSphere MQ消息
9.2.1消息描述符
通过使用MQMD结构，可以访问消息中的控制信息。关于MQMD结构的更详细的描述，请参看《WebSphere MQ Application Programming Reference》。
9.2.2消息种类
WebSphere MQ定义了四种类型的消息：
? 数据报消息
? 请求消息
应用程序可以使用前三种消息来实现它们之间的信息交换。第四种，报告消息是应用程序和队列管理器用来报告关于例如错误发生的事件。
每种消息类型都是使用MQMT_*来定义的。您也可以自定义消息类型。 回复消息 报告消息
9.2.3消息控制信息和消息数据的格式
队列管理器仅关心消息控制信息格式，而处理消息的程序则既关心消息的控制信息，也关心消息数据格式。
9.2.3.1消息控制信息格式
在消息描述的character-string字段中的控制信息必须是在队列管理器的CodedCharSetId属性值定义的字符集。因为当应用程序把消息从一个队列管理器发送到另一个队列管理器时，传输消息的消息通道代理需要使用这个属性值来确定是否需要对消息进行数据转换。
9.2.3.2消息数据格式
在应用程序中可以定义应用数据格式、字符数据的字符集和数字数据的格式。为设置这些格式需要使用下列字段：
? Format
这个字段向消息的接收者说明了消息中应用数据的格式。
CodedCharSetId
这个字段表示了消息中的字符数据的字符集。
Encoding
这个字段描述了数字消息数据的格式。 ? ?
9.2.4消息优先级
当应用程序放消息到队列中时，您可以设置消息的优先级（在MQMD结构的Priority字段设置）。
队列的MsgDeliverySequence属性决定了队列中的消息是以先进先出方式存放，还是以优先级内先进先出方式存放。如果队列的这个属性设置成MQMDS_PRIORITY,队列中的消息将以消息描述符的Priority字段的优先级进行排队。但如果队列的这个属性设置成MQMDS_FIFO,队列中的消息将以消队列的缺省优先级进行排队，相同优先级消息的存放次序是取决于到达的次序。
当消息放到队列中时，如果没有设置消息优先级，那么将会自动使用队列的DefPriority属性定义的缺省优先级。在WebSphere MQ系统中，可以对消息设置0（最低）至9（最高）的10类优先级。
9.2.5消息组
? 一个消息组是由一个或多个逻辑消息组成的。一个逻辑消息是由一个或多个物理消息组组
每个组是通过GroupId来标识的。它是由一个或多个包含同样GroupId的消息组成。这些消息可以存放在队列中的任何位置。
成。
图，一组逻辑消息
? 逻辑消息
在组里的逻辑消息是通过GroupId和MsgSeqNumber来标识的。在一个组里的第一个消息的MsgSeqNumber值是从1开始。如果组里的逻辑消息没有被分成段，则组里的逻辑消息是由一个物理消息组成。
? 段（Segment）
段是用来处理对于应用程序或队列管理器来说太大消息。消息中的段是由GroupId，MsgSeqNumber和Offset来标识的。每个段是由一个物理消息组成。
图，分段消息
9.2.6消息持久性
永久消息需要写到日志和队列文件中。当队列管理器失败后重新启动时，它将会从日志数据中恢复所需要的永久消息，如果队列管理器停止，非永久性消息将被丢弃。
当您创建消息时，如果使用缺省值初始化消息描述符（MQMD）。消息的永久性是由MQOPEN的队列的DefPersistence所决定的。您也可以使用MQMD中的Persistence字段来设置消息的永久性。
如果使用永久性消息将会影响应用程序的性能。影响的程度由系统I/O子系统的特性和
使用的同步点选项所决定的。
9.2.7检索消息
为从队列中获得一个特殊消息，您需要使用消息描述符中的MsgId和CorrelId字段。如
果使用了版本2的MQMD结构，还需要使用GroupId字段。
当消息被放到队列中时，队列管理器将产生消息描述符。队列管理器试图确保消息描述符是唯一的，然而WebSphere MQ应用程序也能设置消息描述符中的值。
9.2.8交付失败的消息
当队列管理器不能把消息放到队列时，可以使用下列处理办法：
? 再次把消息放到队列中。
? 把消息返回到发送方。 把消息放到死信队列中。
9.3本章小结
介绍WebSphere MQ应用程序设计的要点和怎样编写以及测试应用程序。在设计应用程序过程中的一个重要环节就是设计合适的WebSphere MQ消息。
9.4本章练习
1． 列出WebSphere MQ应用程序的设计步骤。
2． 列出WebSphere MQ消息的设计种类。
第十章 用MQI编程
1.学习使用C语言环境下的WebSphere MQ编程。
2.掌握MQI API的调用和参数的使用。
10.1概述
消息队列接口或MQI 是一种编程接口，它向程序员提供WebSphere MQ 消息发布平台
的所有便利，并使程序员可对消息和消息流动方式进行全面的、细节上的控制。通过MQI 调用，您可以：
? 把程序连接至队列管理器，或断开程序与队列管理器的连接
? 打开和关闭对象（如队列、队列管理器、名单和线程）
? 将消息放入队列
? 从队列接收消息并浏览消息（仍将消息保存在队列上） 查询WebSphere MQ 对象的属性，并设置队列的某些属性 在不具备自然同步点支持的环境中（如OS/2 和UNIX 系统），提交和取消在一个工作单元中所做的改变 协调队列管理器和其它资源管理器所做的更新
MQI 提供一系列调用或函数来进行这些操作，还可提供各种数据结构和类型用作调用的输入和输出。同时，MQI 提供大量的指定常量，可用来修改这些数据结构中的选择项。数据结构初始化时，可以使用API 以指定常量形式提供的默认值。MQI 在所有的支持平台上具有一致性，因此应用程序毋需修改代码即可移植到不同的平台上使用，尽管这可能要求程序员添加一些逻辑以保证其可移植性，例如：
#ifdef _OS2
OS/2 specific code
#else
generic code
#endif
MQI 程序在服务器或客户端环境中都能够运行。由于在客户端环境中到队列管理器的不能以绑定方式连接，因此程序在客户端环境中运行有着一定的限制。另外，在客户端配置中，我们还需要某些环境变量，帮助应用程序找到WebSphere MQ 服务器。
10.2 平台和语言
以下列出了MQI 支持的平台和语言：
? ??WebSphere MQ for MVS/ESA：
- COBOL
- 汇编语言
- C
- PL/I
? ??WebSphere MQ for AS/400：
- RPG
- C＋＋
? ??WebSphere MQ for AT&T GIS UNIX，WebSphere MQ for Digital OpenVMS，
WebSphere MQ for SINIX 和 DC/OSx 以及WebSphere MQ for SunOS：
? ??WebSphere MQ for HP－UX 和WebSphere MQ for Sun Solaris：
? ??WebSphere MQ for AIX，WebSphere MQ for OS/2 Warp 以及WebSphere MQ for
Windows NT：
? ??WebSphere MQ for Tandem NonStop Kernel：
- TAL
? ??WebSphere MQ for Windows：
- Visual Basic
10.3 库和存根模块程序
以下列出了MQI 支持的库和存根模块程序。
? WebSphere MQ for Windows
在WebSphere MQ for Windows 中，您必须将您的程序链接到应用程序所运行的环境所提供的MQI 库文件，此外还要链接到那些由操作系统提供的库文件：
??MQM16.LIB 使用16 位C 的服务器
??MQM.LIB 使用32 位C 的服务器
??MQM16.LIB 使用16 位Visual Basic 的服务器
??MQMSTD.LIB 使用32 位Visual Basic 的服务器
? WebSphere MQ for Windows NT
在WebSphere MQ for Windows NT 中，您必须将您的程序链接到应用程序所运行的环境所提供的MQI 库文件，此外还要链接到那些由操作系统提供的库文件：
??MQIC.LIB 使用16 位C 的客户机
??MQIC32.LIB 使用32 位C 的客户机
??MQMXA.LIB C 的静态XA 接口
??MQMCICS.LIB C 的CICS for Windows NT 版本2
??MQMCICS4.LIB CICS Transaction Server for Windows NT 版本4 出口
??MQMZF.LIB C 的可安装服务出口
??MQMCBB.LIB 使用32 位IBM COBOL 的服务器
??MQMCB32 使用32 位Micro Focus COBOL 的服务器
??MQICCBB.LIB 使用32 位IBM COBOL 的客户机
??MQICCB32 使用32 位Micro Focus COBOL 的客户机
??MQMENC.LIB 在C 中用于Encina 的动态XA 接口
??MQMTUX.LIB 在C 中用于Tuxedo 的动态XA 接口
? WebSphere MQ for AIX
在WebSphere MQ for AIX 中，您必须将您的程序链接到应用程序所运行的环境所提供的
MQI库文件，此外还要链接到那些由操作系统提供的库文件：
在非线程的应用程序中：
??libmqm.a 使用C 的服务器
??libmqic.a 使用C 的客户机
??libmqmzf.a C 的可安装服务出口
??libmqmxa.a C 的XA 接口
??libmqmcbrt.o 用于Micro Focus COBOL 支持的WebSphere MQ 运行时间库
??libmqmcb.a 使用COBOL 的服务器
??libmqicb.a 使用COBOL 的客户机
在线程的应用程序中：
??libmqm_r.a 使用C 的服务器
的可安装服务出口 ??libmqmzf_r.a C
??libmqmxa_r.a C 的XA 接口
??libmqmxa_r.a 用于Encina
? WebSphere MQ for HP－UX
在WebSphere MQ for HP－UX 中，您必须将您的程序链接到应用程序所运行的环境所提供的MQI 库文件，此外还要链接到那些由操作系统提供的库文件：
??libmqm.sl 使用C 的服务器
??libmqic.sl 使用C 的客户机
??libmqmzf.sl C 的可安装服务出口
??libmqmxa.sl C 的XA 接口
??libmqmcb.sl 使用COBOL 的服务器
??libmqicb.sl 使用COBOL 的客户
??libmqm_r.sl 使用C 的服务器
??libmqmzf_r.sl C 的可安装服务出口
??libmqmxa_r.sl C 的XA 接口
? WebSphere MQ for Sun Solaris
在WebSphere MQ for Sun Solaris 中，您必须将您的程序链接到应用程序所运行的环境所提供的MQI 库文件，此外还要链接到那些由操作系统提供的库文件。列举如下： ??libmqm.so 使用C 的服务器
??libmqmzse.so 用于C
??libmqic.so 使用C 的客户机
??libmqmcs.so 使用C 的客户机
??libmqmzf.so C
??libmqmxa.a C 的可安装服务出口 的XA 接口
10.4 体系结构模型
MQI 体系结构是WebSphere MQ 不同特点的简单而直接的实施。不同的调用直接访问某一基本的WebSphere MQ 操作，例如从队列中获取消息或将消息放入队列。我们可以根据这些调用的不同作用进行分组：
? 连接和断开连接一个队列管理器：
MQCONN，MQCONNX 和MQDISC
? 打开和关闭WebSphere MQ 对象（例如队列）：
MQOPEN 和MQCLOSE
? 将一个或多个消息放入队列：
MQPUT 和MQPUT1
? 从队列中浏览消息或删除消息：
? 查询对象属性：
MQINQ
? 运行时间内设定某些队列属性：
MQSET
? 管理局部或分布式的事务处理：
MQBEGIN，MQCMIT 和MQBACK
我们利用API 所提供的数据结构和基本数据类型，可以提供操作所需的不同选择项和基本信息。以下就是MQI 的数据结构：
? MQBO （开始选项）
为MQBEGIN 调用确定选择项（仅适用于WebSphere MQ 版本5 产品）。
? MQCNO （连接选项）
为MQCONNX 调用确定选择项（仅适用于WebSphere MQ 版本5 产品）。
? MQDH （分配标题）
如果传输队列中的一条消息是分布列表消息，则描述该消息所包含的数据（仅适用于WebSphere MQ 版本5 产品和WebSphere MQ for AS/400）。
? MQGMO（获取消息选项）
为MQGET 调用确定选择项。
? MQMD（消息描述器）
为放入队列的（使用MQPUT 或MQPUT1）或从队列中获取的（使用MQGET）消息提供控制信息。
? MQMDE （消息描述器扩展）
与MQMD 版本1 结合，它包含MQMD 版本2 通常采用的分组消息和分段信息（仅适用于WebSphere MQ 版本5 产品和WebSphere MQ for AS/400）。
? MQOD（对象描述器）
确定采用MQOPEN 时要处理的对象。
? ?MQOR（对象记录）
确定您在分布列表中要处理的目标（仅适用于WebSphere MQ 版本5 产品和WebSphere MQ for AS/400 V4R2）。
? MQPMO（放置消息选项）
确定MQPUT 和MQPUT1 调用的选择项。
? ?MQPMR（放置消息记录）
包含相关分布列表中个别目标的特定信息（仅适用于WebSphere MQ 版本5 产品和 WebSphere MQ for AS/400 V4R2）。
下述结构用于特殊目的：
? ?MQDLH（死信标题）
定义放入死信（未送达的消息）队列中消息标题的格式（WebSphere MQ for Windows V2.0不支持）。
? MQRMH （引用消息标题）
定义引用消息的格式（仅适用于WebSphere MQ 版本5 产品和WebSphere MQ for AS/400）。 ? MQTM（触发器消息）
定义触发器消息格式。
? MQTMC （触发器消息）
定义作为一组字符字段的触发器消息的格式（仅适用于WebSphere MQ for AS/400） ? MQTMC2 （触发器消息）
定义包括队列管理器名的触发器消息的格式（仅适用于WebSphere MQ for MVS/ESA，WebSphere MQ on UNIX systems，WebSphere MQ for OS/2 Warp 和WebSphere MQ for Windows NT）
? MQXP（出口参数块）结构
用来与API 交叉出口进行通讯（仅适用于WebSphere MQ for MVS/ESA）。
? MQXQH（传输队列标题）
定义放入传输队列中的添加至消息的标题格式。
对C 和Visual Basic，MQI 提供以下基本数据类型：
? MQBYTE 单字节数据 MQBYTEn 16、24、32 或64 字节的字符串 MQCHAR 单字节字符 MQCHARn 包含4，8，12，16，20，28，32，48，64，128 或256 个单字节字符的字符串 MQHCONN 连接句柄（此数据为32 位） MQHOBJ 对象句柄（此数据为32 位） MQLONG 32 位带符号二进制整数 PMQLONG 指向MQLONG 类型数据的指针
10.5 用MQI编程
MQI 是一组使得程序员可以发送和接收消息的函数和数据类型。一般而言，MQI 程序采用如下简单的操作流程。
1. 程序首先调用MQCONN 连接到队列管理器。
2. 一旦连接成功建立，就可以调用MQOPEN 打开一个或多个对象。
3. 可对每个对象进行任何次数的操作(如GET或PUT操作)，直到不需要该对象为止。
4. 然后调用MQCLOSE 关闭该对象。
5. 调用MQDISC 断开与队列管理器的连接。
我们首先来看看所有调用的一些相同元素，然后我们将讨论连接或断开队列管理器所需的调用，并探讨如何打开并关闭WebSphere MQ 对象。
我们完成上述工作之后，还将讨论一下MQI 所能完成的四项基本操作：
? ??将消息放入队列中
? ??从队列中获取消息
? ??在队列上浏览消息 ??查询和设定对象属性
10.5.1 基本API概念
下面我们将讨论MQI API 的基本概念。
1，所有调用的公共参数
所有的调用都具有两种类型的参数：
? ?句柄
句柄由队列管理器连接返回，打开队列调用，用作后续调用的输入参数。
? ??返回码
所有调用都具有两种返回码：完成代码和原因代码。
- 完成码确定调用是成功（MQCC_OK）还是失败（MQCC_FAILED）。它也可以返回一个警告（MQCC_WARNING）。
- 如果完成码是MQCC_OK，那么原因代码就是MQCC_NONE。如果完成码不是MQCC_OK，那么就会返回某个其它的值，说明完成码报告警告或失败。
2，按顺序GET消息
我们可以根据物理顺序或逻辑顺序对队列中的消息进行扫描。如果对消息所在的队列发出GET或BROWSE请求的话，就会使用这种排序。
物理排序与队列接收消息的方式有关。首先到达队列的消息就是获取或浏览操作时的第一个消息。对队列上的消息，物理排序给我们提供了一个FIFO（先进先出）或优先级序列先进先出的顺序。
如果采用优先级内先进先出的排序方法的话，那么即使优先级较高的消息在优先级较低的消息之后到达，它也会在队列内先出现。
这样，在获取或浏览队列上的消息时，就会产生一些被忽略的消息。这是因为：一旦一个优先级较低的消息已经到达而另一个优先级较高的消息又出现在队列中，那么该消息就会被置于当前消息（指针）之前，因此只有关闭并重新打开队列，才能看到该消息，或者调用一个MQOGET 并选中MQOO_BROWSE_FIRST 选项。
让我们以下面发送到优先级顺序队列的消息为例来说明：
1. 消息一，优先级一
2. 消息二，优先级二
3. 消息三，优先级一
我们假设应用程序正在浏览该队列上的消息。程序首先以下面的顺序见到消息：
1. 消息二，优先级二
2. 消息一，优先级一（浏览光标位于此处）
如果程序的浏览光标指向消息一的时候，又出现了优先级为二的消息四，那么队列的顺序将会是：
2. 消息四，优先级二
3. 消息一，优先级一（浏览光标位于此处）
4. 消息三，优先级一
在这种情况下，程序只有重新打开队列，或者利用MQOO_BROWSE_FIRST 选项将浏览光标移动到队列顶端之后，才能看到消息四。
另一方面，逻辑顺序主要与消息的分组和分段有关。在这种情况下，消息根据GroupID的划分，在队列中分组出现，各组的顺序取决于该组第一条消息的物理位置。消息分段的过程与此类似。
我们以按照下列顺序PUT消息到队列中为例来作说明：
1. 组123 的逻辑消息一（非最后）
2. 组456 的逻辑消息一（非最后）
3. 组456 的逻辑消息二（最后）
4. 组123 的逻辑消息二（非最后）
5. 组123 的逻辑消息三（最后）
那么在应用程序中，这些消息以下列顺序出现：
2. 组123 的逻辑消息二（非最后）
3. 组123 的逻辑消息三（最后）
4. 组456 的逻辑消息一（非最后）
5. 组456 的逻辑消息二（最后）
10.5.2 连接到队列管理器
利用MQI进行WebSphere MQ应用编程时，您首先应当使用MQCONN 或MQCONNX函数来连接到队列管理器。函数语法如下：
MQCONN （QMgrName，Hconn，CompCode，Reason）
MQCONNX （QMgrName，ConnectOpts，Hconn，CompCode，Reason）
入口参数：
QMgrName (队列管理器名，如果为空串，则表示连接到缺省队列管理器。); ConnectOpts (控制MQCONNX行为的选项)；
出口参数：
CompCode (完成码)；
??Reason (原因码)；
??Hconn (队列管理器的连接句柄)；
ConnectOpts
下面这段代码显示了如何利用C语言MQI 连接到队列管理器：
10.5.3 打开WebSphere MQ对象
在开发平台上可以打开以下三种WebSphere MQ对象类型：
? ??队列
? ??过程定义 ??队列管理器
我们调用MQOPEN 可以打开任何上述对象：
MQOPEN （ Hconn，ObjDesc，Options，Hobj，CompCode，Reason）
?? Hconn （MQCONN 调用返回的连接句柄）；
?? ObjDesc （打开对象的描述，它以对象描述（MQOD）结构的形式出现）；
?? Options （控制调用行为的一个或多个选项）。
??CompCode (完成码)；
??Reason (原因码)；?
??Hobj （访问对象的对象句柄）；
??ObjDesc （调用后返回的对象描述结构）。
10.5.3.1 打开队列
从程序员的角度来看，共有三种类型的队列：
? ??局部队列 ??远程队列 ??动态队列
局部和远程队列代表着队列管理器从管理角度定义的实际队列。它们之间的主要区别是：在MQOD 数据结构的ObjectName 字段中确定队列名称的方法不同。
局部队列名是局部队列管理器所确定的。远程队列名可以通过局部队列管理器所知的远程队列名获得，或者通过远程队列管理器中的名称获得。如果采用远程队列管理器中的名称，那么ObjectQMgrName 字段必须在下面二者中确定其一：
? ??与远程队列管理器名称相同的传输队列名称
? ??别名队列对象名称（分解为与远程队列管理器名称相同的传输队列）
下面这段代码显示了如何利用局部队列管理器名称打开局部或远程队列：
动态队列是根据需要而建立的，一旦不再被使用就会被删除。在WebSphere MQ中，动态队列不是在管理员层次上建立的。举例来说，在请求器指定一个“回复到”队列的请求/回复环境中，就可以采用动态队列。
建立动态队列时，我们应采用被称为模型队列的模版，这个模版是在管理员层次上建立的，同时还调用了MQOPEN。动态队列名可通过MQOD 结构的DynamicQName 来确定。我们可以通过三种方法确定动态队列名：
? ??赋予一个全名，但不超过33 个字符
? ??赋予一个局部名，在这种情况下，您可以为队列名指定前缀，后跟一个星号（*）。
队列管理器随后会用您指定的前缀生成一个唯一的名称。
? ??在首个字符处给一个星号（*），允许队列管理器生成一个全名。
如果动态队列成功创建，那么对象描述器结构就会返回ObjectName 字段中动态队列的实际名称。下面这段代码可以打开动态队列，并输出动态队列名：
10.5.3.2打开分布列表
通过使用分布列表可以将一条消息放入多个队列中。为实现这个目的，我们必须调用MQOPEN 打开分布列表，同时需要下列输入参数：
??连接句柄
??对象描述器结构（MQOD）中的一般信息
??对象描述器结构(MQOD)必须在版本字段中指定MQOD_VERSION_2，也必须在RecsPresent 字段中指定对象记录结构的数量(与您希望打开的队列数量相同)。??利用对象记录结构（MQOR），确定您希望打开的每个队列的队列名。
上述调用的输出为：
???对分布列表访问的对象句柄;
???完成码;
?? 原因码;
???响应记录（MQRR 结构），包括每个目的地的结果代码（完成代码和原因代码）必须向每个目的地都提供一个MQOR 记录，作为队列名和队列管理器名的结合。我们可以通过两种方法确定目的地队列数组的地址：
??利用指针字段ObjectRecPtr，给出MQOR 记录数组的地址。这是C 语言中通常采用的方法，请看下面的例子：
MQRR 结构在分布列表中包含特定目的地的完成和原因代码。如果任何目的地打开失 败，MQRR 数组将允许我们发现有问题的队列并采取某种纠正行动。
例如，打开分布列表
如欲了解如何利用这些结构的更多细节，请参阅《Application Programming Reference》。
10.5.4 关闭WebSphere MQ对象
我们调用MQCLOSE函数可以关闭WebSphere MQ对象。
MQCLOSE （Hconn，Hobj，Options，CompCode，Reason）
?? Hconn （连接句柄）；
?? Hobj（被关闭对象的句柄）；
?? Options（关闭选项）
??结果代码（完成代码和原因代码）
?? Hobj （对象句柄，重置为MQHO_UNUSABLE_HOBJ）
如果您关闭的不是永久动态队列的话，那么关闭选项将为MQCO_NONE。通常说来，一旦建立动态队列的程序对该队列调用MQCLOSE，该队列就会被删除。但是，就永久动态队列而言，队列管理器可以保存它们，或者也可以根据MQCLOSE 调用的选项删除它们。
我们建议您在应用程序结束之前关闭所有WebSphere MQ 对象。
10.5.5 断开与队列管理器的连接
WebSphere MQ程序的最后一步就是断开与队列管理器的连接。我们可以调用MQDISC 来实现。
MQDISC （Hconn，CompCode，Reason）
Hconn （提供到队列管理器的连接句柄）
结果代码（完成代码和原因代码） Hconn （连接句柄设置为MQHC_UNUSABLE_HCONN）。
10.5.6 将消息放入队列
MQI API 为将消息放入队列向程序员提供了两个选项：
??将多个消息放入一个已经打开的队列。
??将单一消息放入一个队列，而不显式打开队列。
我们可以调用MQPUT 将多个消息放入一个队列：
MQPUT （ Hconn ，Hobj ，MsgDesc ，PutMsgOpts ，BufferLength ，Buffer ，CompCode ，Reason ）
?? Hconn （连接句柄，由MQCONN 调用返回）
?? Hobj （队列句柄，由MQOPEN 调用返回）
?? MsgDesc （消息的描述）
?? PutMsgOpts （控制信息，其形式为一个放置消息选项（MQPMO）结构）
?? BufferLength （消息所包含数据的长度）
?? Buffer （消息本身）
?? MsgDesc （已经更新的消息描述器和选项）
对此函数进行调用之前，队列必须先用MQOO_OUTPUT 选项打开。
下列代码显示了如何向SampleQueue 队列中PUT一条消息。
第 131 页 共 217 页
如果仅将单一消息PUT到队列中我们可以调用MQPUT1，不需要MQOPEN打开队列即可将单个消息放入队列。
MQPUT1 （Hconn，ObjDesc，MsgDesc，PutMsgOpts，BufferLength，Buffer，CompCode，Reason）
除了队列句柄之外，MQPUT1参数接口与MQPUT 参数接口相同，但MQPUT1中必须指定一个对象描述块，就像MQOPEN 调用所指定的那样。例如，
提示：重要的是，如果实际上要利用此函数的操作数量很少，而不必考虑MQOPEN 和MQPUT 函数的话，这种方法就是有用的，因为与这个单放置函数相关的总开销要高得多。
第 132 页 共 217 页
同时将消息放入多个队列您也可以将消息放入分布列表。利用单一的MQPUT 或MQPUT1 调用，消息被发送到分布列表中的所有队列中。在这种情况下，MQPUT 调用的输入参数如下：
??对象句柄，到利用MQOPEN 调用打开的分布列表，和本章前面所显示的一样 ??消息描述器结构（MQOD）
??总体控制信息
??控制信息，以放置消息记录的形式（MQPMR）
??消息所包含数据的长度
??消息本身
此调用的输出如下：
??响应记录
MQPMR 结构为某些字段（可能和已经存在于MQMD 结构中的字段不同）给出特定的目的地信息。
10.5.7 从队列获取消息
我们调用MQGET从队列中获取消息。
MQGET （ Hconn，Hobj，MsgDesc，GetMsgOpts，BufferLength，Buffer，DataLength，CompCode，Reason）
此调用的入口参数如下：
?? GetMsgOpts （控制信息，以获取信息选项（MQGMO）结构的形式）
此调用的出口参数如下：
??结果代码（原因代码和完成代码）
?? DataLength （消息的实际长度）
为了执行MQGET调用，必须用MQOO_INPUT_SHARED 或MQOO_INPUT_EXCLUSIVE 选项打开队列，才能使用这个调用。从队列获得的消息可能是以物理顺序，也可能是以逻辑顺序排列，这取决于MQOPEN调用和MQGET 调用所采用的选项。
例如， MQGET 调用
第 133 页 共 217 页
从队列中获取指定消息我们也可以根据消息描述获取消息，正如MQMD 结构所提供的那样。可利用MsgId 和CorrelId 字段来查询某一特定消息，但由于这两个字段是由应用程序设定的，因此它们可能不是唯一的。在这种情况下，我们获取的第一个符合所有标准的消 息可以重新调用，以获取其余的消息。如果采用MQMD 结构第二版的话，那么也可以利用GroupId、MsgSeqNumber 和Offset字段。我们可以为上述任何字段指定一个“不匹配”的第 134 页 共 217 页
值，这样在查找匹配时就不会考虑该字段。利用MQMD 结构第二版时，也可以在队列扫描中声明采用哪些字段。下面这段代码显示了如何在调用MQGET 前设定correlID 作为消息
队列具备一些索引功能，从而提高了这些操作的性能。索引字段可以是MsgId 或CorrelId，具体取决于队列indexType 属性的值。
10.5.8 从队列浏览消息
下面讨论在队列上怎样浏览消息。
为了在队列上浏览消息，我们应当：
? ??调用MQOPEN 来打开要浏览的队列，选中MQOO_BROWSE 选项。
? ??调用MQGET，并选中MQGMO_BROWSE_FIRST 选项，以获得队列上的第一个消息。 ??重复调用MQGET，并选中MQGMO_BROWSE_NEXT 选项，以便逐步浏览随后的许多消息，在任何新的MQGET 调用之前将MsgId 和CorrelId 设为空。 ??调用MQCLOSE 关闭队列。
在浏览消息时，正如我们从队列中获取消息一样，消息排列的顺序可能是物理的，
也可能是逻辑的。下例显示了如何浏览物理顺序队列的消息。
第 135 页 共 217 页
如果您不知道队列中消息的大小，那么您可以在调用MQGET 时设置下列选项，从而获得消息的大小，再浏览消息或从队列中获取消息：
???MQGMO_BROWSE_FIRST 或MQGMO_BROWSE_NEXT 选项。
???MQGMO_ACCEPT_TRUCATED_MSG 选项。
????0 缓存区长度
消息大小以DataLength 参数返回。
10.5.9查询对象属性
查询对象属性时，我们可以调用MQINQ。
MQINQ （Hconn，Hobj，SelectorCount，Selectors，IntAttrCount，IntAttrs，CharAttrLength，CharAttrs，CompCode，Reason）
该调用的入口参数如下：
SelectorCount（选择器数量）
第 136 页 共 217 页
?? Selectors （属性选择器数组）
?? IntAttrCount （被查询的整型数量）
?? IntAttrs （整型变量数组，调用向其返回指定的整型）
???CharAttrLength （字符属性缓存区的长度）
?? CharAttrs （字符缓存区，调用把被查询字符属性的值放入其中）
该调用的出口参数如下：
?? IntAttrs （一系列拷贝到数组中的整型值）
?? CharAttrs （字符属性返回其中的缓存区）
就字符属性而言，所得的缓存区由长度固定的属性值一个接一个地填充。如果这些属性中的任何一个实际值小于属性的固定长度，那么其余的空间由空白区填充。如果任何对象（在这种情况下，对象就是队列）请求的属性不适用于该类型的队列，那么空间由星号（*）填充。 例如，查询对象属性：
第 137 页 共 217 页
10.5.10设置对象属性
只有队列对象才可以设置属性。我们调用MQSET 来设定队列属性。
MQSET （Hconn，Hobj，SelectorCount，Selectors，IntAttrCount，IntAttrs，CharAttrLength，CharAttrs
，CompCode，Reason）
该调用的参数与MQINQ 调用的参数相同。除了完成代码和原因代码之外，所有的参数都是输入参数。下面列出了调用MQSET 时可以设定的属性：
??InhibitGet（远程队列不适用）
??DistList
??InhibitPut
??TriggerControl
??TriggerType
??TriggerDepth
??TriggerMsgPriority
??TriggerData
下例显示了如何禁止对队列进行放置操作：
第 138 页 共 217 页
10.5.11 MQI中的事务处理
局部或全局工作单元都可以用MQI API 启动。一旦启动，任何工作单元都可调用MQCMIT 或MQBACK 来完成。
MQCMIT （ Hconn，CompCode，Reason）
MQBACK （ Hconn，CompCode，Reason）
第 139 页 共 217 页
我们在MQPUT 或MQGET 调用中加入MQPMO_SYNCPOINT 或MQGMO_SYNCPOINT 代码，不调用MQBEGIN，这样就启动了局部工作单元，请看下面的例子：
工作单元中的每个操作都必须设定MQPMO 或MQGMO 选项，正如我们前面代码中所显示的那样。
我们调用MQBEGIN 来启动全局工作单元。如果局部工作单元已经启动，那么MQBEGIN调用会失败，返回MQRC_UOW_IN_RPOGRESS 原因。
MQBEGIN （ Hconn，BeginOptions，CompCode，Reason）
下面这段伪代码显示的是一个分布式的事务处理，包括基本的获取、放置操作，和一些关系数据库的操作：
10.5.12 MQI中的消息分组
消息分组使得我们可以向消息添加某些分组逻辑，而不必为所有逻辑都编写应用程序代码。分组是由队列管理器来管理的，提供排序和组完成控制等基本特点。调用MQPUT 或MQPUT1 时，随消息发出的消息描述器结构（MQMD）引入组标识符。组中的每个消息都必须有MQMF_MSG_IN_GROUP 标志，但是最后一条消息则应具有MQMF_LAST_MSG_IN_GROUP 标志。组中消息的顺序储存在MQMD 结构的MsgSeqNumber 字段中，它是由队列管理器自动生成的。下面这段代码显示了如何将三条消息作为消息组的一部分发出：
第 140 页 共 217 页
第 141 页 共 217 页
10.6本章小结
本章主要介绍了MQI的体系结构，并对MQI API的使用进行举例说明。
10.7本章练习
1. MQCONNX调用中的补充参数是：
（1） 队列管理器名（queue manager name）
（2） 连接句柄 (connection handle)
（3） 连接选项 (connection option)
（4） 原因码 (reason code)
2. MQSET调用可以改变队列的所有属性。
3. 使用下列那些调用之前，需要执行MQOPEN调用：
（1） MQGET
（2） MQINQ
（3） MQPUT1
（4） MQCLOSE
（5） ALL of the above
4. 下列那种情况，当队列管理器重新启动时，消息可以恢复：
（4） 被操作员保存的消息 永久性消息 高优先级消息 使用MsgID和CorrelID检索消息
5. 队列管理器决不能设置消息的CorrelID 属性。
第 142 页 共 217 页
6. 消息组（message group）由什么组成：
（1） 一个或更多的物理消息
（2） 一个或更多的逻辑消息
（3） 仅有一个逻辑消息和多个物理消息
（4） 以上所有的
7. 使用MQI编写文件的发送程序。
8. 使用MQI编写文件的接收程序。
第十一章 用 C++ API编程
1． 了解WebSphere MQ C++ API。该API 是MQI API 的面向对象的延伸。
2． 学习这种API 的基本概念、体系结构模型，以及API 可用性。
3． 介绍利用这种API 所能进行的一些基本操作。
4．最后，我们将探讨如何利用该API 的编程模式。
11.1 概述
WebSphere MQ C++接口是MQI API的延伸。就WebSphere MQ 消息发布接口而言，为程序员提供了一种面向对象的方法。由于该API 是以面向对象的模型为基础的，属性和方法都继承到子类中。在下面各节中，我们将确定作为父类的方法。
关键特性：
C++ MQI 可提供MQI API 的所有特性，如获取、放置及浏览消息等，其还允许用户查询并设置对象选项。此外，还可提供以下特性：
? ??WebSphere MQ 数据结构的自动初始化；
? ??及时的队列管理器连接和队列打开；
? ??隐式队列关闭和队列管理器断开；
? ??死信标题发送和接收； ??IMS 桥标题发送和接收； ??参照消息标题发送和接收； ??触发器消息接收； ??CICS 桥标题发送和接收； ??工作标题发送和接收； ??客户机渠道定义。
第 143 页 共 217 页
11.2 平台和语言
WebSphere MQ C++允许您使用C++语言编写WebSphere MQ应用程序，WebSphere MQ C++可以在下列服务器平台使用：
? WebSphere MQ for AIX, Version 5.3 WebSphere MQ for HP-UX, Version 5.3 WebSphere MQ for iSeries, Version 5.3 WebSphere MQ for Linux for Intel, Version 5.3 WebSphere MQ for Linux for zSeries, Version 5.3 WebSphere MQ for Solaris, Version 5.3 WebSphere MQ for Windows, Version 5.3 WebSphere MQ for z/OS, Version 5.3 WebSphere MQ for Compaq Tru64 UNIX, Version 5.1 WebSphere MQ for OS/2 Warp, Version 5.1 WebSphere MQ for Sun Solaris, Intel Platform Edition, Version 5.1
同时也适用于以下客户机环境：
? AIX Compaq Tru64 UNIX HP-UX Linux for Intel Linux for zSeries OS/2 Solaris (SPARC and Intel Platform Editions) Windows 3.1 Windows 95 Windows NT(R) Windows 2000
11.3库
下表显示了在各个可用平台上使用该API 开发的C++程序进行编译时所需的库。
第 144 页 共 217 页
imqi.hpp
标题包含所有利用此API 所需的声明。
11.4体系结构模型
此API 中所有的类均继承于ImqError 类，其允许错误条件下（error condition）与每个对象相关。如下图（ 队列管理类）。
图，队列管理类
上图显示了与项目有关的类（item-related classes），这些类包含MQI提供的消息标题结构（如IMS 桥标题和死信标题）。
第 145 页 共 217 页
图，项目处理类
队列管理类和项目处理类都利用以下类和数据类型：
??ImqBinary 类，包括字节数组（如MQBYTE24）；
??ImqBoolean 数据类型，可定义为typedef unsigned char ImqBoolean；
??ImqString 类，包含字符数组（如MQCHAR64）。
我们将就其与MQI API 特性的关系来阐述该API 体系结构的特性。可将所有的MQI 数据结构实体归入合适的对象类中，从而使我们可就不同的数据结构字段采用不同的方法。有句柄的实体（继承于ImqObject 类或其派生物之一）可向我们提供MQI 的抽象界面。此外，这些对象具有智能行为，与过程MQI 实施相比，能减少方法调用量。举例来说，到队列管理器的连接根据需要被创建或删除。ImqMessage 类包括MQMD 数据结构，提供缓冲功能，可以作为用户数据和项目的保存点。缓冲区可以由应用程序提供，也可以由系统自动创建。ImqItem 类代表着消息主题中的项目。项目是指需要连续且分别进行处理的消息的各个部分。除了常规用户信息外，项目还可能是死信标题或触发器消息。每个项目都有对象类，与一种可辨认的WebSphere MQ 消息格式相对应。用户数据没有对象类，但是可以特别指明ImqItem，从而将其写入。如果不写入的话，那么用户数据处理则交由应用程序来完成。ImqChannel 类包括渠道定义（MQCD）结构，使得我们可以确定在客户机环境中执行ImqQueueManager::connect（）时要用到的连接选项。欲了解有关WebSphere MQ 自动通道定义选项的更多信息，请参见《WebSphere MQ Intercommunication》。
11.5用C++ API编程
现在，我们将阐述如何利用上述API 来实现基本的WebSphere MQ 操作，如连接到队列管理器、打开一个队列或发送/接收消息。
11.5.1连接到队列管理器
为了连接到队列管理器，我们将使用ImqQueueManager 类（它包括WebSphere MQ 队列管理器对象）。队列管理器名可以由构造器调用提供，也可以用ImqQueueManager 类的setName 方法来提供。
ImqQueueManager qmanager；
qmanager.setName（name）；
或者
ImqQueueManager *pmanager = new ImqQueueManager（name）；
提示：我们在本章其余部分中都将用到qmanager 对象。而后，我们可以利用ImqQueueManager 的连接方法来建立连接。
qmanager.connect（）；
队列管理器的信息可以利用ImqQueueManager类来访问。
11.5.2打开WebSphere MQ对象
我们可以根据对象是队列还是其他类型的对象，然后利用ImqObject 或ImqQueue 类来打开WebSphere MQ 对象。一般来说，我们都会使用ImqQueue 类，除非必须要查询或设定某些对象属性。
? 打开队列
ImqQueue 类包括WebSphere MQ 队列对象，并向队列对象行为添加了某些信息。在可以对队列进行任何放置或获取操作前， 必须利用ImqQueue 类的setConnectionReference 方法将包含队列的队列管理器分配给ImqQueue 对象。
ImqQueue pqueue；
pqueue.setConnectionReference（pmanager）；
可在对象构建过程中提供队列名，也可以利用ImqObject 类的setName 方法提供队列名。 pqueue.setName（queuename）；
当发出放置或获取调用时，将自动采用要求的选项打开队列，也就是说，不需要进行显式打开操作。如果实际的打开选项不符合在队列上进行操作的要求的话，那么ImqQueue对象就会关闭并重新打开队列。
在某些情况下，根据被打开队列的类型，将会导致一些额外的开销或某些问题。为了避免自动关闭和重新打开队列，我们必须利用ImqObject 类的openFor 方法或setOpenOptions 直接设置打开选项。我们也可以利用ImqObject 类的打开方法显式打开队列，但是如果打开选项已经指定的话，那么较之于这种接口提供的隐式打开，它并不能提供什么重大优势。 pqueue.setOpenOptions（MQOO_OUTPUT | MQOO_INPUT_SHARED）；
pqueue.openFor（MQOO_OUTPUT | MQOO_INPUT_SHARED）；
openFor 方法不断添加指定的打开选项到实际分配给对象的选项。ImqQueue 对象的默认打开选项是MQOO_INQUIRE。
? 打开动态队列
动态队列不能通过重新打开方式自动关闭，因为对动态队列进行关闭操作会删除该队列。因此，打开动态队列时，我们必须指定打开选项。
队列模型的名由ImqObject 类的setName 方法指定，动态队列名或其前缀可以用ImqQueue 类的setDynamicQueueName 方法确定。动态队列的实际名可以在队列打开后用dynamicQueueName 方法获得。
pqueue.setDynamicQueueName（dynamicqueuename）；
? 打开分布列表
分布列表由ImqDistributionList 类进行管理，它继承自ImqQueue 类。可以利用ImqQueue 类的setDistributionReference 方法将任意数量的ImqQueue 对象和一个ImqDistributionList 对象关联起来。
在打开分布列表之前，相关联的队列必须分配到队列名和包含队列的队列管理器，下面提供了一个打开分布列表的例子：
一旦设置好分布列表的队列，就可以向其他任何ImqQueue 对象一样来打开分布列表并对其进行操作。
11.5.3 关闭WebSphere MQ对象
WebSphere MQ 对象在删除与其相应的ImqObject 后即会自动关闭。
11.5.4 断开与队列管理器的连接
当删除ImqQueueManager 对象后，将隐式执行断开连接操作。
11.5.5 消息放入队列
我们可以利用ImqQueue 类的放置方法将消息放入ImqQueue 或ImqDistributionList。放置方法提供两种接口：
ImqBoolean put（ImqMessage & msg）；
ImqBoolean put（ImqMessage & msg, ImqPutMessageOptions & pmo）；
消息数据由ImqMessage 类管理。ImqMessage 类继承自ImqMessageTracker 类（它包括MQMD 数据结构）和ImqCache 类（它处理消息数据缓冲区）。
我们可以利用ImqMessageTracker 类的setMessageId 方法来设置消息身份。
ImqMessage msg；
msg.setMessageId（msgId）；
同样，我们也可以利用某些方法来访问关联性ID 和组ID。我们必须用ImqBinary 类来创建messageId、correlationId 和groupId。该类包括用于MQI的BYTExx 数据类型，它提供某些进行基本操作的方法。下例显示了如何利用ImqBinary 来创建二进制对象。
准备消息数据
该API 与MQI API 的不同之处在于准备和处理消息数据的方法不同。在MQI 中，从分配正确的缓冲区到储存数据，再到读取消息时处理消息中不同的可能标题，消息完全由应用程序管理。
在C++ API 中，添加了一些缓冲功能，而且缓冲区由ImqCache 对象管理。缓冲区通过继承与每个消息（ImqMessage 对象）相关联。默认情况下，缓冲区由ImqCache 自动提供，或者也可以由应用程序利用以下任何一种ImqCache 对象方法来提供：
??useEmptyBuffer：这种方法允许应用程序分配一个固定长度的空白缓冲区给ImqMesage 对象。如果没有分配实际消息长度的话，那么会将消息长度自动设置为零，而且缓冲区也将是空的。
useFullBuffer：这种方法允许应用程序分配一个已经准备好的消息缓冲
区给消息缓冲区可以重复使用，我们也可以利用ImqCache 类的setMessegeLength 方法来设置消息长度，因此发送字节的数量也各不相同。由应用程序提供消息缓冲区的优势在于无需
进行数据拷贝，因为数据可以直接在缓冲区中准备。
为了将ImqCache 再设为自动的缓冲区，应用程序可以用空缓冲区指针和零（0）长度调用useEmptyBuffer。当自动提供缓冲区时，缓冲区随着消息的增长而增长。这为准备消息前却不知道消息长度提供了更多的灵活性。可以利用ImqCache 写入方法将消息（数据）拷贝到缓冲区中。
msg.write（12, “Hello world”）；
我们可以利用ImqMessage 的writeItem 方法将项目拷贝到缓冲区中。比方说，您可能希望向消息添加一个死信标题，并将其放入死信队列中。
下例显示了如何创建一个ImqDeadLetterHeader 并将其插入现有消息的开始部分。
消息放到队列上时，必须经常指定更多的选项。我们可以用以ImqPutMessageOptions对象为形式的第二个参数调用放置方法来指定这些选项。ImqPutMessageOptions 类包括MQPMO 数据结构，它允许应用程序指定更多的选项，如同步点控制或消息上下文。
下例显示了如何启动并设置同步点选项。这将启动本地队列管理器事务处理，我们可以利用ImqQueueManager 类的提交或回滚方法来结束它。
如欲了解ImqQueue 类可用选项的更多信息，请参见《Using C++》手册。
11.5.6从队列获取消息
我们可以利用该类提供的获取方法从ImqQueue 对象上获取消息。ImqQueue 获取方法提供四种接口：
ImqBoolean get（ImqMessage & msg, ImqGetMessageOptions & options）；
ImqBoolean get（ImqMessage & msg）；
ImqBoolean get（ImqMessage & msg, ImqGetMessageOptions & options,
const size_t buffer-size）；
ImqBoolean get（ImqMessage & msg, const size_t buffer-size）；
在方法调用之后，消息信息会包含在ImqMessage 对象中。缺省情况下，消息缓冲区由系统
提供，可以利用dataPointer 或bufferPointer 方法获得。消息数据长度可以利用ImqCache 类的dataLength 方法获得。
在每次获取方法调用之后，数据缓冲区的物理位置可能发生改变，因此我们建议不要使用实际的缓冲区指针来访问数据。我们应当利用dataPointer 或bufferPointer 方法来重新分配数据指针。
如果应用程序希望提供固定长度的缓冲区来接收消息数据的话，那么我们可以在利用ImqQueue 的获取方法前使用ImqCache 的useEmptyBuffer 方法。给定缓冲区的长度将限制消息长度，因此在应用程序设计中必须考虑到长消息的情况。
在这种情况下，我们可以一直使用实际的缓冲区指针pszBuffer，但是我们还是建议采用dataPointer 方法以保证可移植性。
读取消息数据
一旦接收到消息，那么根据消息格式，消息数据可能是项目形式的，也可能是原始的用户数据形式。但项目必须是分别连续处理的数据的各个部分。我们可以利用ImqMessage 的formatIs 来确保消息格式的有效性。如果消息格式代表着任何已知消息标题数据结构，那么我们可以利用ImqMessage 的readItem 方法从消息中获得结构。该API 具有三个实现定义的消息标题：
??死信标题（ImqDeadLetterHeader class）；
??IMS 桥标题（ImqIMSBridgeHeader）；
??参照标题（ImqReferenceHeader）。
每个标题都对应于一个WebSphere MQ定义的消息格式。用户可以指定ImqItem 类来定义其他类型的格式。
如果消息格式未知的话，那么正如前面所讲解过的那样，我们可以利用dataPointer 方法来
直接访问消息数据。
更多的获取方法选项
ImqGetMessageOptions 类为消息接收过程提供了更多信息，如：
??获取操作的等待间隔；
??匹配选项；
??消息选项；
??同步点参加；
??组状态；
??细分状态。
我们可以利用ImqGetMessageOptions 的setOptions 方法来指定任何MQI 中可用的消息获取选项。其中MQGMO_WAIT 选项应用较多，它为要完成的获取操作提供了一个等待间隔。这样，如果期待的消息还未到达队列的话，那么获取方法在返回错误前会等待一定的时间，时间长度是用ImqGetMessageOptions 类的setWaitInterval 方法来指定。
下例显示了如何用无限等待选项从队列获取消息。
从队列获取特定消息
通过ImqMessageTracker 类中的消息属性的任意结合，我们可以确认特定的消息。 ??MessageId
??CorrelationId
??GroupId
这些选项必须在获取方法调用中传递的ImqMessage 对象中指定。ImqGetMessageOptions 类
为应用程序提供了一种在指定消息查找过程中将使用什么选项的方法。
如果一个以上的消息与给定标准相匹配，那么将返回这些消息中的第一个，并且获取方法的后续调用将提供所有消息的访问。如果找到了匹配的消息，消息对象信息在获取方法调用后将发生改变，否则函数会返回假。
11.5.7浏览队列上的消息
我们可以利用ImqQueue 获取方法浏览队列上的消息。必须用MQOO_BROWSE 选项来打开ImqQueue 对象。我们可以用setOpenOptions 或openFor 方法来实现这一目的。
pqueue.setOpenOptions（MQOO_BROWSE）；
pqueue.openFor（MQOO_BROWSE）；
在队列对象已被打开并用于浏览后，我们必须用以下选项调用ImqQueue 获取方法：MQGMO_BROWSE_FIRST 消息选项，如果您希望浏览光标位于符合ImqMessage 对象指定的标准的第一个消息处的话；MQGMO_BROWSE_NEXT 消息选项，如果您希望浏览光标移动到符合ImqMessage 对象指定的标准的下一个消息的话。
获取方法将返回ImqMessage 对象的更新版本，浏览光标也将指向当前消息的信息，并且当前消息不会从队列中删除。队列对象一旦打开， 浏览光标就会指向队列中的第一个消息， 因此MQGMO_BROWSE_NEXT 选项与MQGMO_BROWSE_FIRST 具有相同的行为。
可以按照物理顺序或逻辑顺序来浏览消息。
根据队列的消息到达顺序（MsgDeliverySequence），物理排序可以是FIFO（先进/先出）排序或优先级内FIFO 排序。逻辑顺序就是说，即便另一个组中的任何消息在本组最后一条消息接收前出现，属于同一个组的消息仍将按照其在队列中的正确位置顺序排列。为了浏览逻辑顺序的消息，我们在调用方法时必须指定MQGMO_LOGICAL_ORDER 选项。
gmo.setOptions（MQGMO_BROWSE_NEXT | MQGMO_WAIT |
MQGMO_LOGICAL_ORDER）；
11.5.8查询并设置对象属性
? 查询属性
利用此种API，较之于采用MQI API 时的情况，查询并设定对象属性实在是相当直接的操作。这里，ImqObject 类提供了两种查询方法，可查询任何显示的整数或字符属性。
ImqBoolean inquire（const MQLONG int-attr, MQLONG & value ）；
ImqBoolean inquire（const MQLONG char-attr, char * & buffer, const size_t length）；
int-attr 和char-attr 参数将MQIA_*和MQCA_*指数赋予属性。整数对象属性值在值参数中返回，正如下面这段代码所显示的那样：
字符对象属性值在缓冲区参数中返回，正如下面这段代码所显示的那样：
缓冲区必须足够大，以致于可以容纳属性值。缓冲区的长度必须在长度参数中指定。设置对象属性为了设置队列属性，ImqObject 提供了两种查询属性的方法。
ImqBoolean set（const MQLONG int-attr, MQLONG & value
）；
ImqBoolean set（const MQLONG char-attr, char * buffer, const size_t length）；
下面这段代码显示了这些函数可能的用法：
只有下面这些队列属性值可以利用上述函数进行调整：
- MQIA_INHIBIT_PUT
- MQCA_TRIGGER_DATA
- MQIA_DIST_LISTS
- MQIA_INHIBIT_GET
- MQIA_TRIGGER_CONTROL
- MQIA_TRIGGER_DEPTH
- MQIA_TRIGGER_MSG_PRIORITY
- MQIA_TRIGGER_TYPE
11.5.9事务处理管理
本地资源管理器事务处理可以通过在ImqPutMessage 或ImqGetMessage 选项类中设置同步点参加来启动。
ImqQueueManager 对象提供了用此API 开始、提交或取消分布式事务处理所需的事务处理管理接口。分布式事务处理由ImqQueueManager 开始方法调用来启动。一个事务处理开始和结束调用中的任何操作都是事务处理的一部分。
只有在不存在其他本地或分布式事务处理管理的情况下，才能启动分布式事务处理管理。如果事务处理成功的话，本地和分布式事务处理管理都可以由ImqQueueManager 提交方法调用来终止。它们也可以由ImqQueueManager 取消方法调用来终止。
pmanager.commit（）；
pmanager.backout（）；
11.5.10消息分组
我们可以利用ImqMessageTracker 的setGroupId 方法将消息分组。我们也必须利用ImqMessage 的setMessageFlags 方法给出MQMF_MSG_IN_GROUP 或MQMF_LAST_MSG_IN_GROUP 标记，从而确认组中的消息。
MQI API的例子显示了如何将三条消息作为一个组进行发送。前两条消息将用MQMF_MSG_IN_GROUP 标记发送， 而第三条消息
则将利用MQMF_LAST_MSG_IN_GROUP 发送。下例显示了消息分组。
而后， 我们可以利用ImqGetMessageOptions 类setOptions 方法中的MQGMO_LOGICAL_ORDER 选项，并以这些消息在队列中的逻辑循序接收它们。
另外，队列管理器可以控制是否完全接收消息组。如果我们仅希望队列中出现完整的消息组的话， 那么我们可以在ImqGetMessageOptions 的setOptions 方法中设置MQGMO_ALL_MSGS_AVAILABLE 等选项。
11.6本章小结
本章已经讨论WebSphere MQ C++ API。该API 是MQI API 的面向对象的延伸。此外我们还讨论这种API 的基本概念、体系结构模型，以及API 可用性。而后，我们介绍了利用这种API 所能进行的一些基本操作，如：
? ??连接到队列管理器并断开与队列管理器的连接；
? ??打开及关闭WebSphere MQ 对象（如队列对象）；
? ??向队列发送消息并从队列获取消息； ??事务处理管理；
? ??消息分组。
最后，我们探讨了如何利用该API 的编程模式。
11.7本章练习
1. 使用WebSphere MQ C++ API 编写文件的发送程序。
2. 使用WebSphere MQ C++ API编写文件的接收程序。
第十二章 用Java编程
学习使用WebSphere MQ for Java编程。
12.1 概述
WebSphere MQ for Java允许用Java 编程语言写成的程序直接访问WebSphere MQ Server，或作为一个WebSphere MQ Client连接到WebSphere MQ。
12.2 平台
WebSphere MQ for Java 产品可用于以下平台：
??AIX
??iSeries 和OS/400
??HP-UX
??Linux
??Sun Solaris
??z/OS 和OS/390 V2R9 或更高版本
??Windows 平台
12.2.1 获得软件包
WebSphere MQ base Java的最新版本的安装可以和WebSphere MQ同时安装。关于WebSphere MQ的安装可以参考下列资料：
? AIX 平台的《WebSphere MQ for AIX, V5.3 Quick Beginnings 》 HP-UX平台的《WebSphere MQ for HP-UX, V5.3 Quick Beginnings》 OS/400平台的《WebSphere MQ for iSeries V5.3 Quick Beginnings 》 Linux 平台的《WebSphere MQ for Linux for Intel and Linux for zSeries, V5.3 Quick Beginnings 》 Solaris 平台的《WebSphere MQ for Solaris, V5.3 Quick Beginnings 》 Windows 平台的《WebSphere MQ for Windows, V5.3 Quick Beginnings 》 z/OS 平台的《WebSphere MQ for z/OS System Setup Guide 》
WebSphere MQ base Java 被包含在下列Java的.jar文件中:
? com.ibm.mq.jar 这个jar文件支持所有的连接选项。 com.ibm.mqbind.jar
这个jar文件仅支持bindings连接，并不是在所有的平台都提供或支持，所以我们推荐在新应用程序中不要使用它。
12.2.2 WebSphere MQ for Java的运行环境
为了运行WebSphere MQ for Java，需要以下的软件：
服务器端平台的WebSphere MQ ； 服务器端平台的Java Development Kit（JDK）； 客户端平台的Java Development Kit 或Java Runtime Environment（JRE）或支持Java 的网络浏览器。
12.2.2.1安装目录
WebSphere MQ Java V5.3文件的安装目录如下表所示：
还提供了一些例子程序，例如安装验证程序(IVP)
。下表中列出了不同平台的例子程序的目录结构。
12.2.2.2环境变量
产品安装完成后，您必须更新CLASSPATH环境变量，CLASSPATH中需要包含WebSphere MQ base Java和例子程序的目录，如下表所示：
如果现有的应用程序依赖于com.ibm.mqbind，您必须要把com.ibm.mqbind.jar文件加到 classpath中。
在某些平台还必须要更新下列附加的环境变量，如下表所示：
确保您追加的WebSphere MQ的变量不要覆盖现有的系统环境变量。如果覆盖了系统的环境变量，那么应用程序在编译或运行时将可能会失败。
12.3 使用WebSphere MQ for Java
应用程序连接到队列管理器后，就可以与访问WebSphere MQ对象（例如,队列）。队列管理器为其拥有的WebSphere MQ对象提供消息发送服务。使用WebSphere MQ classes for Java编程的方法依赖于使用的连接模式。连接的模式有两种，分别是客户连接模式和绑定模式。
12.3.1客户机连接模式
当WebSphere MQ classes for Java作为客户端时，与WebSphere MQ C客户端类似，但仍然存在如下区别：
1， 仅支持TCP/IP。
2， 不支持连接表。
3， 在启动时，不读取任何WebSphere MQ环境变量。
4， 通道的定义和环境变量信息都被存放在一个叫做Environment的类中，当连接时这
些信息也可以被作为入口参数。
5， 错误和意外信息被写到MQException类说明的日志中。缺省错误信息被写到Java
控制台。
WebSphere MQ classes for Java 客户端不支持MQBEGIN和快速绑定。
当利用客户机连接时，您必须指定其他一些环境属性，以便建立与队列管理器的连接。这些属性是： 主机名，即作为队列管理器主机的WebSphere MQ服务器的名字；以及通道名，即客户 机连接通道的名字。另外，您也可以指定WebSphere MQ服务器监听的端口号。如果还没有指定端口号的话，那么将使用默认的端口号1414。
12.3.2绑定模式
在绑定模式（也称作服务器连接模式）中，与队列管理器的通讯利用的是进程间通讯。关键因素之一就是，要记住绑定模式只适用于那些运行在作为队列管理器主机的WebSphere MQ 服务器上的程序。利用绑定模式的程序不会从WebSphere MQ客户机机器上运行。换言之，应用程序被绑定在队列管理器所在的同一台机器上。绑定模式是访问WebSphere MQ 的一种快速而高效的方法。某些功能（如队列管理器的扩展架构事务处理协同）只在绑定模式下才可用。
WebSphere MQ classes for Java的绑定模式与客户连接模式存在下列区别： 1， 忽略了MQEnvironmnet类所提供的大多数参数。
2， 绑定模式支持MQBEGIN和快速绑定。
12.3.3 类库
WebSphere MQ classes for Java 提供了一系列可以使Java applet和应用程序访问WebSphere MQ的类。WebSphere MQ for Java 包括以下类和接口：
12.3.3.1类
? MQChannelDefinition
该类用来传递有关连接队列管理器的信息至发送、接收和安全退出。当以绑定模式直接连接到WebSphere MQ时，此类不适用。
? MQChannelExit
当调用发送、接收和安全退出时，该类定义传递到这些调用的上下文信息。该类的exitResponse 属性应当通过退出设置，以显示WebSphere MQ Client for Java 下一步应当采取何
种行动。
? MQDistributionList
该类代表开放式队列集，我们可以利用put（）方法的单一调用发送消息至这些队列中。我们利用MQDistributionList 构造器或MQQueueManager 类的accessDistributionList（）方法来做出该类的实例。
? MQDistributionListItem 该类代表分配表中的单一项目（单一队列）。该类继承MQMessageTracker 类。 MQEnvironment
该类包含控制构建MQQueueManager 对象（及其相对应的到WebSphere MQ 的连接）环境的静态元素变量。由于调用MQQueueManager 构造器使该类值的集生效， 因此MQEnvironment 类的值应当在MQQueueManager 实例构建前设置。
? MQException
该类包含WebSphere MQ 完成代码和错误代码常量的定义。以MQCC_开始的常量是
WebSphere MQ 完成代码，而以MQRC_开始的常量则是WebSphere MQ 原因代码。只要出现WebSphere MQ
错误，就会给出MQException。
? MQGetMessageOptions 该类包含控制MQQueue.get（）方法行为的选项。 MQManagedObject
该类是MQQueueManager、MQQueue 和MQProcess 类的超类。它提供查询并设置这些资源属性的能力。
? MQMessage
该类代表WebSphere MQ 消息的消息描述器和数据。
? MQMessageTracker 该类用来处理分配表中某个给定目的地的消息参数。MQDistributionListItem 继承它。 MQPoolServices
用作WebSphere MQ 连接默认ConnectionManager 的ConnectionManager，其实现可以使用该类。
? MQPoolServicesEvent
只要添加或删除MQPoolToken 到MQEnvironment 控制的权标集，那么就可用该类来生成一个事件。当默认的ConnectionManager 改变时， 即会生成MQPoolServicesEvent。 ?
? MQQueue
该类为WebSphere MQ 队列提供查询、设置、放置和获取操作。查询和设置能力继承MQQueueManager
该类代表WebSphere MQ 的队列管理器。
MQSimpleConnectionManager
该类提供基本的连接集合功能。
MQPoolToken 该类可被用来提供默认的连接集合。 MQProcess 该类为WebSphere MQ 进程提供查询操作。 MQPutMessageOptions 该类包含控制MQQueue.put（）方法行为的选项。 自MQManagedObject。 ? ?
12.3.3.2接口
WebSphere MQ for Jave 具有以下接口：
? MQReceiveExit
该接口使得我们可以用WebSphere MQ for Java 检查并有可能修改从队列管理器接收MQSecurityExit
该接口使得我们可以尝试定制连接到队列管理器时出现的安全流。当以绑定模式直接连的数据。当以绑定模式直接连接到WebSphere MQ 时，该接口不适用。 ?
接到WebSphere MQ 时，这一接口不适用。
? MQSendExit
该接口使得我们可以检查并有可能修改用WebSphere MQ Client for Java 发送到队列管理器的数据。当以绑定模式直接连接到WebSphere MQ 时，这一接口不适用。
12.4用WebSphere MQ Java API开展工作
我们在本节中将探讨利用WebSphere MQ Java API 进行编程的方法。
12.4.1 设置连接
在本节中，我们将看看绑定模式和客户机连接模式是如何实现的。我们假定从设计的观点出发，您已经决定用绑定模式或客户机连接模式实现，下面我们就来讲解一下应当如何来实现的方法。
我们通过MQQueueManager 类的构造器调用获得到队列管理器的连接。在这个时候，我们所获得连接的类型是由MQEnvironment 类的某些静态字段决定的。区别不同连接模式的静态字段设置分别是主机、通道、userId 和口令。在这些用以连接到队列管理器的MQEnvironment 字段中，最能区别出绑定模式和客户机连接模式的两个字段设置就是主机和通道。在绑定模式中，除了userId 和口令字段外，您不必为这些字段中的任何一个设置值。您也可以选择在绑定模式中设置它们。
? ?MQEnvironment.hostName
对客户机连接而言，我们应当将此设为队列管理器所在主机的主机名。由于该主机名用于到队列管理器运行机器的TCP/IP 连接，因此其值不区分大小写，请看下面的例子： MQEnvironment.host = “machinename.dmain.com” ；
? ?MQEnvironment.channel
这是客户机连接通道的名。该字段的值是区分大小写的。一般说来，它就是队列管理器下面服务器连接通道的名。是一个双向链接，它使在客户机和队列管理器之间的MQI 调用和回复成为可能。对客户机连接而言，我们应当将其设为应用程序尝试连接的队列管理器下面服务器连接通道的名，请看下面的例子：
MQEnvironment.channel = “JAVA.CLIENT.CHNL”；
? MQEnvironment.port
端口号是一个可选字段。在默认情况下，客户机会尝试在主机的1414 号端口上连接到队列管理器。1414 号端口是WebSphere MQ监听器默认使用的端口。如果该端口号与默认的不同，那么您可以用MQEnvironment.port 字段来指定端口号，请看下面的例子：
MQEnvironment.port = nnnn；
? MQEnvironment.userId 和MQEnvironment.password
userId 和口令字段在默认情况下是空的。您可以通过设置userId 和口令字段的值来指定userId 和口令，请看下面的例子：
MQEnvironment.userId = “userXYZ” ；
MQEnvironment.password = “password” ；
? MQEnvironment.properties
这是定义WebSphere MQ 环境的关键值对的散列表。如果您不是使用VisiBroker 连接的话，那么就应当将该字段在绑定和客户机连接情况下都做如下设置：
MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_WEBSPHERE MQ
MQEnvironment 类中的变量控制着到队列管理器的连接调用。设置连接到队列管理器的第一步就是根据连接模式的类型来设置MQEnvironment 字段， 我们通过创建MQQueueManager 类的新的实例、发出MQQueueManager 类的构造器调用来获得到队列管理器的连接。MQQueueManager 类有过载的构造器。我们要根据创建MQQueueManager 类新实例时提供的参数来调用合适的构造器建立连接。在最简单的情况中，您可以提供队列管理器名作为字符串，从而创建QueueManager 类的新实例，请看下面的例子：
MQQueueManager qmgr = new MQQueueManager（“ITSOG.QMGR1”） ；
在这里，ITSOG.QMGR1是队列管理器名。上面的方法在绑定模式和客户机连接模式中都有效。
在第二种方法中，您可以提供队列管理器名以及具有设置环境选项关键值对的散列表，从而创建MQQueueManager 类的新实例。利用这种方法时，提供的属性会覆盖MQEnvironment 类中设置的值。如果您希望在队列管理器到队列管理器的情况下设置环境值，那么您就可以使用此方法。请看下面的例子：
MQQueueManager qmgr = new MQQueueManager（queueManagerName ,propertiesHashTable）；
第三种方法就是通过提供队列管理器名和队列管理器打开选项，从而创建MQQueueManager 类的新实例（它是一个整数字段）。只有在绑定模式中才能使用该方法。选项字段使您可以在快速绑定或正常绑定间作出选择。请看下面的例子：
MQQueueManager qmgr = new MQQueueMager（queueManagerName ,
MQC.MQCNO_FASTPATH_BINDING ） ；
12.4.2 打开队列
为了对队列进行操作，我们首先应当通过打开队列以获得队列句柄或队列对象。打开队列有两种方法。我们可以利用MQQueueManager 对象的accessQueue 方法，也可以通过调用MQQueue 类的构造器。
这两种不同调用的形式如下：
MQQueue queue = qmgr.accessQueue（“qName’, openOption, “qMgrName” ,
“dynamicQname”, “alternateUserId”）；
使用MQQueue 类构造器的第二种方法，需要添加一个队列管理器参数，
MQQueue queue = new MQQueue（qmgr, “qName’, openOption, “qMgrName” , “dynamicQname”, “alternateUserId”）；
WebSphere MQ 将在打开队列过程中根据用户认证保证openOption 的有效性。
MQQueue 类的对象代表着队列。它既拥有有助于消息发送（即放置、获取、设置、查询）的方法，也有对应于队列属性的属性。
12.4.3 处理WebSphere MQ消息
MQMessage 类的对象代表着将被放置到队列上或将从队列获取的消息。它既包括应用程序数据，又包括MQMD。既具有对应于MQMD 字段的属性，又具有向消息写入或从消息读取不同数据类型的应用程序数据的方法。在应用程序中，MQMessage 代表着一个缓冲区。应用程序不必声明缓冲区的大小，因为它会随着写入的数据而不断改变。但是，如果消息大小超过了队列的MaximumMessageLength 属性的话，您就不能将消息放到队列中。
为了创建消息，您应当创建MQMessage 类的新实例。我们利用writeXXX 方法根据特定应用程序数据类型将应用程序数据写入消息。数字和字符串等数据类型格式可以通过characterSet 和编码等MQMD 属性来控制。我们可以在放置消息到队列上之前设置MQMD 字段，也可以在从队列获取消息时读取MQMD 字段。应用程序通过设置合适的放置或获取操作选项，从而控制着消息放置到队列或从队列获取消息的方式。我们通过设置合适的放置消息选项值来控制消息放置到队列的方式。同样，我们也可以通过设置合适的获取消息选项来控制从队列接收消息的方式。
? 放置消息选项
消息放置到队列上的方式是由MQPutMessageOptions 类实例的选项字段的值来决定的。我们可以利用WebSphere MQ 常量接口 MQC 的MQPMO 结构来设置选项的值。请看下面的例子：
MQPutMessageOptions pmo = new MQPutMessageOption（）；
MQPutMessageOptions 类的实例，其选项属性的值设置为默认值。这在大多数简单消息发送情境中都已经足够了。您可以利用WebSphere MQ 常量接口MQC 的MQPMO 结构来设置任意特定的选项，例如：
pmo.options = pmo.options + MQC.MQPMO_NEW_MSG_ID
上面的例子设置了选项字段的值，指令队列管理器为消息生成新的消息ID 并将其设为MQMD 的MsgId 字段。
? 获取消息选项
从队列接收消息的方式是由MQGetMessageOptions 类实例的选项字段的值决定的。我们可以利用WebSphere MQ Constants MQC 的MQOO 结构来设置选项的值。请看下面的例子：
MQGetMessageOptions gmo = new MQGetMessageOption（）；
MQGetMessageOptions 类的新实例将选项属性的值设为默认值。您可以利用MQPOO 结构来设置合适的获取消息选项。请看下面的例子：
gmo.options = gmo.options + MQC.MQGMO_NO_WAIT；
以上选项指定了如果队列上没有消息的话，那么获取消息调用将立即返回。发送消息我们利
用MQQueue 类的put（MQMessage message）或put（MQMessage message,
MQPutMessageOptions pmo）方法来发送消息。放置方法调用控制着消息放置到队列上的方式。
? 获取消息
我们利用MQQueue 类的get （ MQMessage message ） 或get （ MQMessage, MQGetMessageOptions gmo）、get（MQMessage, MQGetMessageOptions gmo, int max
MessageSize）方法来从WebSphere MQ 队列接收消息。所有从给定MQQueueManager 到WebSphere MQ的调用都是同步的。
如果您进行带有等待的获取调用的话，那么直到获取调用完成之前，所有其他利
用相同MQQueueManager 的线程都将被封锁，不能发出进一步的WebSphere MQ调用。如果
您需要多线程同时来访问WebSphere MQ的话，那么每个线程都必须创建其自己的MQQueueManager 对象。
如果没有指定MaxMessageSize 的话，那么将自动调整消息缓冲区长度为将要到达的消息的大小。如果您以获取方法调用使用MaxMessageSize 的话，那么该调用将能接收最大的消息。如果队列上的消息比它还要大的话，那么就会出现下面两种情况之一：
1. 如果MQC.MQGMO_ACCEPT_TRUNCATED_MSG 标记在MQGetMessageOptions
对象的选项元素变量中得到设置的话，那么将根据指定缓冲区的大小向消息填充最多的数据，并且会返回完成代码为MQException.MQCC_WARNING 和原因代码为
MQException.MQRC_TRUNCATED_MSG_ACCEPTED的结果。
2. 如果没有设置MQC.MQGMO_ACCEPT_TRUNCATED_MSG 标记的话，那么消息将被留在队列上，并且会返回完成代码是MQException.MQCC_WARNING 和原因代码是 MQeception.MQRC_TRUNCATED_MSG_FAILED 的结果。
12.5应用程序开发
在本节中，我们将探讨发送-遗忘、请求/回复和消息分组点到点消息发送模式的实现。在点到点模式中，应用程序成对活动。我们称作发送器的发送应用程序将消息放置在发送方的WebSphere MQ 应用程序队列上。在目的地系统或接收方上，我们称作接收器的应用程序从WebSphere MQ 应用程序队列接收消息。因此，发送器和接收器应用程序是成对活动的，实现了在来源和目的地系统之间的数据移动或消息发送。
在我们所举的这些例子中，用到了到队列管理器的客户机连接。在这些例子中用到的WebSphere MQ 对象是在主机ITSOG 上称作ITSOG.QMGR1 的队列管理器。用于客户机连接的通道是JAVA.CLIENT.CHNL，端口就是默认端口1414。我们所用的应用程序队列是SAMPLE.QUEUE。
12.5.1简单的消息发送器应用程序
我们的第一个点到点客户机程序将创建一个简单的消息并发送它到WebSphere MQ 队列。我们还将讲解处理发送器发送消息的接收器程序。
有关步骤如下：
??调入WebSphere MQ Java API package；
??为客户机连接设置环境属性；
??连接到队列管理器；
??为打开WebSphere MQ 队列设置选项；
??为发送消息打开应用程序队列；
??设置选项，放置消息到应用程序队列上；
??创建消息缓冲区；
??使用用户数据和任何消息描述器字段准备消息；
??放置消息到队列上。
以下程序PtpSender.java 就是将在应用程序队列上发送消息的发送器应用程序：
12.5.2简单的消息接收应用程序
我们的下一个点到点客户机程序是消息接收器应用程序，它获取PtpSender 应用程序所发送的消息并在控制台上将消息打印出来。
??为获取消息打开应用程序；
??设置选项，从应用程序队列获取消息；
??从队列获取消息到消息缓冲区；
??从消息缓冲区读取用户数据并在控制台上显示。
以下程序PtpReceiver.java 就是将从应用程序队列上获取消息的接收应用程序：
第 171 页 共 217 页
12.5.3请求/回复
在请求/回复消息发送模式中，一个应用程序发送一条消息（请求消息）到另一个回复应用程序（回复生成器）再到请求消息。生成回复的应用程序获取请求消息、处理请求， 并向请求应用程序发出回复。回复发送到由请求消息的消息标题属性replyToQueueManager 指定的队列。请求应用程序在放置消息到队列上之前会在请求消息上设置这些消息标题属性。
请求应用程序让队列管理器生成唯一的messageId，以及回复应用程序拷贝请求消息的 messageId 到回复消息的correlationId 上。请求应用程序使用回复消息的correlationId 值， 将回复映射回原始的请求。
我们将利用一对简单的应用程序来讲解请求回复模式。第一个应用程序（我们称作请求器）放置一条简单的消息到队列（请求队列）上。请求器在放置请求消息到队列上之前会在请求消息上设置replyToQueue 和replyToQueueManager 消息标题属性。而后，它将打开回复队列并等待correlationId 匹配已发出请求消息的messageId 值的消息。服务于请求消息的回复应用程序获取消息，准备回复消息，并将它发送到请求消息指定的队列管理器下的回复队列上。它还将从请求消息拷贝messageId 到回复消息的correlationId消息标题字段。
应用程序Requester.java 即发送请求消息并且等待从回复应用程序获得回复的应用程序。 有关步骤如下：
??调入必要的包；
??为客户机连接设置MQEnvironment 属性；
??打开请求队列以获得输出；
??设置放置消息选项；
- 准备请求消息；
- 设置到队列名的回复；
??设置到队列管理器名的回复；
??放置请求消息到请求队列上；
??关闭请求队列；
??打开回复队列以获得输入；
??设置获取消息选项；
- 设置选项，匹配回复消息上的correlationID；
- 用等待（等待匹配correlationId 的回复消息）在回复队列上发出获取。
我们建议您为回复消息在获取调用上使用确定的等待时间。等待间隔可以设为系统所允许的等待回复的最大时间。
第 172 页 共 217 页
第 173 页 共 217 页
第 174 页 共 217 页
12.5.4回复应用程序
回复器应用程序Responder.java 处理来自请求队列的请求消息并发送回复到请求应用程序指定的请求队列上。
第 175 页 共 217 页
第 176 页 共 217 页
12.5.5消息分组
应用程序可能需要将一系列更新分组归入一个工作单位中。这样的更新通常都是逻辑上相互关联的，为了保持数据的完整性，更新必须全部成功。如果一个更新成功而另一个更新失败的话，那么就会丢失数据完整性。WebSphere MQ 支持事务处理消息发送。当一个工作单位成功完成时就会被提交。在这时，所有在这个工作单位中所做的更新都将成为永久性的和不可逆的。如果工作单位失败的话，那么所有更新将都被取消。同步点协同就是工作单位在保持其完整性的情况下被提交或取消的过程。逻辑消息组中的逻辑消息是由GroupId 和MsgSeqNumber 字段确认的。MsgSeqNumber 从组中第一条消息由1 开始，如果消息不在组中，那么该字段的值就是1。
组中的逻辑消息用途如下：
???保证排序（如果这在消息传输环境中不能得到保证的话）。
???允许应用程序将相似的消息分在一组（例如，那些必须全部由相同服务器实例来处理的消息）。
组中的每条消息如果不是分为段的话，那么就是由一个物理消息构成的。每条消息在逻辑上都是分开的，只有MQMD 中的GroupId 和MsgSeqNumber 字段需要与组中的其他消息关联。MQMD 中的其他字段都是独立的；一些字段可能对组中所有消息都是相同的，而其他字段可能会不同。举例来说，组中的消息可能有着不同的格式名、CCSIDs、编码等。
简单的组发送器应用程序
第 177 页 共 217 页
我们的下一个程序范例GroupSender.java 将讲解如何发送在组中的消息。该应用程序将 把10 条简单的消息作为工作单位中的一个组放置到队列上。
??调入必需的包；
??设置队列打开选项以获得输出；
??打开队列以获得输出；
- 设置选项，维护消息的逻辑顺序；
- 设置选项，请求队列管理器生成GroupId；
??设置消息标题属性；
- 设置messageFlags 属性，从而显示出消息位于组中；
- 给String 设置格式属性；
??创建个体消息并将其放置到队列上；
??在组中的最后一条消息上设置messageFlags 属性，从而显示出消息是组中的最后一条； ??提交事务处理。
第 178 页 共 217 页
第 179 页 共 217 页
12.5.6简单的组接收应用程序
我们的下一个程序范例GroupReceiver.java 将讲解如何在组中获取消息。该应用程序将 在组里（通过GroupSender 应用程序放置）获取消息，该组是以工作单位中作为组的队 列。
??设置队列打开选项以获得输入；
??打开队列以获得输入；
- 设置选项以便在同步点控制下获得消息；
- 设置选项，当在组里提供所有消息时，以便只处理消息；
- 设置选项以便以逻辑顺序处理信息；
??从队列上获取消息直到处理完最后消息；
??在控制台上显示消息内容；
??提交事务处理。
GroupReceiver.java例子应用程序
第 180 页 共 217 页
您如欲进行更深入的探讨，可参考《WebSphere MQ 发布/预订应用程序》，您可以从以下网址下载：http://www.ibm.com/redbooks。
12.6本章小结
本章介绍了如何利用WebSphere MQ for Java 编程。并且为那些希望编写与WebSphere MQ相连接的Java 应用程序或小程序的程序员提供所需的信息。WebSphere MQ Base Java可以使用Java applets、应用程序或servlets来调用和查询WebSphere MQ。在客户端机器上不用安装任何WebSphere MQ程序，直接通过WebSphere MQ for Java作为一个Internet终端用户就可以参与交易的执行。
12.7本章练习
1.使用WebSphere MQ Java API 编写文件的发送程序。
2.使用WebSphere MQ Java API编写文件的接收程序。
第十三章 用ActiveX编程
学习使用WebSphere MQ automatin classes for ActiveX编程。
13.1 概述
WebSphere MQ Automation Classes for ActiveX 是又一组允许程序员处理队列管理器对象的API。WebSphere MQ Automation Classes for ActiveX 的组成部分为希望开发可在Windows 平台上运行的WebSphere MQ 应用程序的设计人员和程序员们提供了可用的类。因为我们可以利用实现语言的本身语法来编写WebSphere MQ 对象的代码，因此这些类可以很容易地被整合到任意应用程序中。应用程序的整体设计与任何WebSphere MQ 应用程序的设计都是一样的。
我们在这里要重点指出的是那些与ActiveX 相关的概念。ActiveX 组件是以组件对象模型（Component Object Model，缩写为COM）为基础的，它是由Microsoft 定义的基于对象的编程模型。该模型确定了如何使软件组件可以确定彼此的位置并进行相互通讯，而不必在乎使用的是何种计算机语言或其物理位置如何。
COM 是形成更高级软件服务（如OLE 提供的服务）基础的底层架构。COM 简化了
强大的基于组件的应用程序的开发工作。从其原始的单一机器应用，COM 已经扩展到允许访问其他系统的组件。这一新的模型被称作分布式COM（Distributed COM），也被简称为DCOM。
DCOM 使得我们可以利用组件来创建网络式应用程序。它扩展了COM，可以在局域网、广域网甚至因特网上支持不同电脑间的通讯。利用DCOM，应用程序的分布位置可以做到对客户和应用程序本身最有意义。COM+是COM 的另一个延伸。它提供可从任何编程语言或工具使用的运行时间环境和服务，并且使得组件之间的大范围相互操作性成为可能，而不管实现的方式如何。COM+为从互动的对象创建软件系统提供了一种简单、强大的模型。与对象进行的所有通讯必须通过界面发生，并且所有通讯都必须看起来像简单的方法调用，即便目的地对象位于另一进程之中或在另一台机器上。
在利用WebSphere MQ Automation Classes for ActiveX 设计ActiveX 应用程序时，最重要的信息项目就是发送的消息或从远程WebSphere MQ 系统中接收的消息。为了让WebSphere MQ Automation Classes 脚本工作，发送方和接收应用程序都必须知道消息结构。而且，在考虑如何构建设计中的应用程序的实现时，我们应当记住，WebSphere MQ Automation Classes for ActiveX 脚本运行的机器与WebSphere MQ 队列管理器或WebSphere MQ 客户安装的机器相同。
WebSphere MQ Automation Classes for ActiveX 的主要特性如下：
??提供对WebSphere MQ API 所有函数和特性的访问。这就使得可与其他非Windows 的WebSphere MQ 平台建立完全的相互关联；
??兼容ActiveX 惯例；
??兼容WebSphere MQ 对象模型；
??使得使用它的ActiveX 应用程序能够在任何通过WebSphere MQ 可以访问的企业系统上运行事务处理和访问数据。
WebSphere MQ Automation Classes for ActiveX 采用的是自由线程模型，在这种模型中，对象可在线程间使用。类允许使用MQQueue 和MQQueueManager 对象，但WebSphere MQ 一般不允许在不同线程间分享句柄（the sharing of handles）。
尽管使用这些类有一定的好处，但同时也有一些限制。下面就是一些限制的例子： ??如果打算用网络浏览器来访问应用程序的话，浏览器必须支持ActiveX 控件（如Microsoft Internet Explorer 3 或更高版本）。如果用WebSphere MQ 向其执行的机器外发送数据的话，那么恶意脚本可能会钻这个空子并制造安全问题；
??Automation Classes 常量对VBScript 和JavaScript 程序不可用，因此程序员必须对其进行硬编码（这些常量可在随WebSphere MQ 产品提供的cmqc.h 标题文件中找到）。 13.2 平台和语言
WebSphere MQ Automation Classes for ActiveX 只能用于32 位ActiveX 脚本客户机。因此，这些类只能用于以下平台：
??Windows 98/95
??Windows NT
??Windows 2000
我们可以利用支持COM 对象创建和使用的语言来编写使用WebSphere MQ Classes for ActiveX 的应用程序，例如Visual Basic、Java 和其他ActiveX 脚本客户机。这些类可以 简单地整合到应用程序中，因为我们可以用实现语言的本身语法来编写WebSphere MQ 对象的代码。为了在WebSphere MQ 服务器环境中运行ActiveX 组件，您必须拥有Windows
NT 4.0 （如果打算使用MTS 作为事务处理协同器的话，还应具备Service Pack 6 和Option Pack4）或Windows 2000 和WebSphere MQ 版本5.1 或更高。
13.3 库
如果应用程序在使用WebSphere MQ Automation Classes for ActiveX 的话，它将需要MQAX200.dll 链接库。这个库可以在WebSphere MQ Base Directory\bin 下找到。当编写应用程序时，其中应包括该库。在Visual Basic 中，我们可以通过向程序引用添加mqax200.dll来实现此目的。欲了解更多信息，请参见Visual Basic 产品文档。
13.4 架构模型
WebSphere MQ Automation Classes for ActiveX 提供以下对象：
MQSession：这是WebSphere MQ Automation Classes for ActiveX 的主类。它包含对任何其他类进行的上一次动作的状态。每个ActiveX 进程只有一个MQSession 对象。如果尝试创建第二个此类对象的话，将创建原始对象的第二个引用；
MQQueueManager：此类提供到队列管理器的访问。调用该对象的方法和属性将发出通过MQI 的调用。在此类的对象毁坏后，它将自动从队列管理器断开连接。可以通过此调用访问的某些属性是预备用户ID、完成代码、连接状态和原因代码。这些属性大多数只有在对象连接到队列时才能进行访问。
MQQueue：此类提供到队列及其属性的访问，如当前深度、深度高度限制等。
MQMessage：此类代表着一条WebSphere MQ 消息。该类不仅包括访问消息描述器的属性，还提供储存消息数据的缓冲区。它包括写入方法，可以从ActiveX 应用程序中拷贝数据到MQMessage 对象，还提供读取方法，可以从MQMessage 对象中拷贝数据到ActiveX 应用程序。这个类自动管理向缓冲区分配内存和取消其内存分配。在创建MQMessage 对象时，应用程序不必声明缓冲区的大小，因为缓冲区会随着写入其中的数据大小而变化；
MQPutMessageOptions：此类包括所有控制放置消息行为的不同的选项；
MQGetMessageOptions：此类包括所有控制获取消息行为的不同的选项；
MQDistributionList：此类包括获得输出的本地、远程或假名队列的集合；
MQDistributionListItem：此类包括MQOR、MQRR 和MQMR 结构，并将其与拥有分配表（owning distribution list）相关联。
13.5 用WebSphere MQ automatin classes for ActiveX编程
在下面这节中，我们将看看如何利用WebSphere MQ Automation Classes for ActiveX 连接和操作队列管理器对象。这节中的例子都以Visual Basic 编写。
13.5.1 连接到队列管理器
WebSphere MQ Automation Classes for ActiveX 遵循与AMI 相同的结构。您必须先创建会话对象，以便连接到队列管理器。为了创建MQSession 类的实例，我们如下将采用New 关键词：
Set SessionObject = New MQSession
一旦创建了会话对象，就必须建立到队列管理器的连接。我们利用MQSession 类的AccessQueueManager（）方法来实现这一目的。该方法实际上将连接队列管理器、打开队列管理器并设置初始属性值。
Set QueueManagerObject =SessionObject.AccessQueueManager（QmgrName as string） 该方法所需的唯一参数就是队列管理器名。如果需要访问默认队列管理器名的话，那么就使用空串，而不使用队列管理器名。我们可以利用WebSphere MQ 客户来建立连接，也可以直接连接到WebSphere MQ 服务器来建立连接。如果连接对象失败的话，那么将举出错误事件并设置对象的原因代码和完成代码以及MQSession 对象的原因代码和完成代码。
下例显示了如何连接到默认队列管理器。
例，连接到默认队列管理器
另一种可以用来连接到队列管理器的方法就是采用MQQueueManager 类的Connect（）方法。在调用此方法前，必须设置队列管理器名。我们利用MQQueueManager 类的Name属性来实现这一目的。
例6-2 显示了如何利用上述调用来连接到名为SAMPLE.OMGR1 的队列管理器。 例6-2 连接到队列管理器
13.5.2 打开WebSphere MQ对象
一旦我们已经成功建立了到队列管理器的连接，接下来我们就可以打开WebSphere MQ 对象了。这些对象可以是：
??队列（远程队列、本地队列、动态队列）；
??分配表；
??消息。
为了打开队列，我们要使用MQQueueManager（）类的AccessQueue（）方法：
Set QueueObject = QueueManagerObject.AccessQueue（QueueName asstring,
OpenOption as Long,
QueueManagerName as string,
DynamicQueueName as string,
AlternateUserId as string）
QueueName 就是队列名。在尝试连接到队列管理器之前，队列必须被创建。OpenOption 参数是用来确定控制打开队列行为的选项的。最常用的打开选项如下：
??MQOO_INPUT_SHARED：当应用程序需要从队列获取消息时使用。它在分享访 问模式中打开队列，因此多个应用程序可以同时从队列接收消息。该选项只能用 于本地队列、别名队列和模型队列。
??MQOO_INPUT_EXCLUSIVE：当应用程序需要从队列获取消息时使用。它在独占 模式中打开队列。该选项仅对本地队列、别名队列和模型队列有效。
??MQOO_OUTPUT：如果应用程序将在队列中放置消息的话，则应使用该选项。它 对所有类型的队列有效，包括远程队列和分配表。
QueueManagerName 也用来指定拥有队列的队列管理器名。该参数通常被省略，因为我 们已经创建了引用队列管理器的MQQueueManager 对象。如果QueueName 是模型队列 的话，那么将使用DynamicQueueName 来向将创建的动态队列分配一个名。
例6-3 显示了如何打开一个命名为PTP.QUEUE.LOCAL 的队列，它定义在默认队列管理器中。
例6-3 打开队列
提示：如果要打开的队列是本地队列的话，那么请不要设置QueueManagerName 或将其 设为。如果将其设为拥有队列的远程队列管理器的名的话，那么将尝试打开远程队列的 本地定义。
当需要发送消息到多个目的地时，我们可以利用MQDistributionlist 对象。与MQQueue 对象相似，我们需要创建一个此类型的对象。如下所示，我们可以利用New 关键词来 实现这一目的：
Set DistributionListObject = New MQDistributionList
创建MQDistributionList 对象的引用后，我们应当指定引用到队列管理器（在此定义分 配表）的MQQueueManager 对象。此目的可以通过利用MQDistributionList 对象的 ConnectionReference 属性来实现。
DistributionListObject.ConnectionReference = QueueManagerObject
一旦指定到队列管理器的引用后，那么最后要做的一件事就是将队列添加到分配表中。 每个队列必须与MQDistributionListItem 对象相关联。我们可以利用MQDistributionList 类的AddDistributionListItem（）方法来实现此目的。
Set DistributionListItemObject =
DistributionListObject.AddDistributionListItem（QueueName as string,
QueueMgrName as string）
QueueName 就是需要成为分配表一部分的队列的名，QueueMgrName 指的是拥有队列的 队列管理器。
例6-4 显示了如何发送一条消息到两个队列PTP.QUEUE.LOCAL 和
PTP.QUEUE2.LOCAL，它们定义在队列管理器SAMPLE.QMGR1 中：
另一个需要在发送或接收消息之前被创建的对象就是消息对象。正如我们在前面提到的那
样，消息对象类包含消息数据和访问消息描述器的属性。此类型的对象可以利用MQSession 类的AccessMessage（）来创建：
Set MessageObject = SessionObject.AccessMessage（）
消息数据由MessageData 属性分配。举例来说，如果您需要发送消息“Sample Message”的话，那么该字符串必须被引用到消息对象上，见例6-5。
例6-5 分配
MessageObject.Message = “Sample Message”
我们可以简单地设置CharacterSet 属性为队列管理器的编码字符集标识符（MQCCSI_Q_MGR）并将它作为字符串传递，从而把二进制数据传递到WebSphere MQ 消息中。
13.5.3 基本操作
在第6.5.2 节《打开WebSphere MQ 对象》（见本书第186 页）中，我们看到了如何创建并打开不同的队列管理器对象。现在，对象已经创建了，那么接下来我们将谈谈可以对这些对象进行哪些基本操作。基本操作包括获取消息和发送消息。
在发送消息之前，必须用MQOO_OUTPUT 选项打开队列。为了发送消息，必须使用MQQueue 对象的Get（）方法。
QueueObject.Put（MessageObject, PutMsgOptionsObject）
MessageObject 代表将要发送消息的对象。因此，这种类型的对象必须创建在调用之前。另外，我们可以指定PutMsgOptions 对象，它包含控制放置操作的选项。如果没有指定PutMsgOptions 对象的话，那么将使用默认的PMOs。如果要使用该选项的话，那么就应当利用MQSession 类的AccessPutMessageOptions （ ） 对象来创建MQPutMessageOptions。
下例显示了如何用PMO 选项MQPMO_NO_SYNCPOINT（放置消息时无同步点控制） 将消息放入一个称作PTP.QUEUE.LOCAL 的队列。
例， 放置消息
请记住，MQPutMessageOptions 对象包含控制放置消息到WebSphere MQ 队列上这一行为的各种选项。
为了同时发送多条消息，我们要用到MQDistributionListObject 类的put（）方法。正如发送一条消息到单一队列一样，在开始发送多条消息之前，我们需要用MQDistribution类的OpenOptions 属性以MQOO_OUTPUT 选项打开分配表。然后，我们将用MQDistributionList 类的open（）方法打开分配表中定义的对象。
下例显示了如何发送一条消息到两个队列PTP.QUEUE.LOCAL 和PTP.QUEUE2.LOCAL，它们定义在队列管理器SAMPLE.QMGR1 中。
例， 发送消息
接收消息
为了接收消息，我们要利用MQQueue 类的get（）方法。请记住，在我们可以接收消息前，必须用MQOO_INPUT_EXCLUSIVE 或MQOO_INPUT_SHARE 打开队列。
QueueObject.Get（MessageObject, GetMsgOptionsObject, MsgLength）
MessageObject 即代表将被接收消息的对象。因此，在调用前必须创建这种类型的对象。另外，我们可以指定GetMsgOptionsObject，它包含控制获取操作的选项。但是，如果没有指定它的话，那么将使用默认的GMOs。如果将使用该选项的话，那么我们应当用MQSession 类的AccessGetMessageOptions（）方法来创建MQGetMessageOptions 对象。从WebSphere MQ 接收消息有两种方法：
??用Visual Basic 计时器函数发出get（）后等待，这是轮询（polling）的方法；
??用Wait 选项发出get（）。设置WaitInterval 属性以指定等待时间。如果正在运行的软件
是单线程的，而系统却是多线程的话，那么我们推荐采用此种方法。这将避免使您的系统无限期死锁。
如果WebSphere MQ 应用程序是消息的发信方并且WebSphere MQ 生成AccountToken 、 CorrelationId、GroupId 和MessageId 的话，那么我们建议您利用AccountTokenHex、 CorrelationIdHex、GroupIdHex 和MessageIdHex 属性，如果您希望查看它们的值或想对 其进行任何操作（包括在消息中将其传递回WebSphere MQ）。这样做的原因在于，WebSphere MQ生成的值是0 到255 之间任意值（包括0 和255）的字节串。它们不是可打印的字符串。如果上方法成功的话，那么到来的消息的MQMD 和消息数据会完全代替MQMessage对象的MQMD 和消息数据。如果不成功的话，MQMessage 对象不会改变。如果消息缓冲区的内容没有定义的话，那么整个消息长度就设为应当接收到的消息的完全长度。如果未指定消息长度参数的话，那么消息缓冲区长度则自动调整为至少是将到达的消息的大小。
下例显示了如何从一个命名为PTP.QUEUE.LOCAL 的队列获取消息，然后如何在命名为txtMessageData 的文本框中显示消息。
例，获取消息
13.5.4 关闭对象
一旦已经发送或接收消息并且已经处理数据，我们就可以关闭对象了。我们可以利用需 要关闭对象（队列管理器、队列或分配表）的close（）方法来实现此目的。
如果要关闭动态队列而且我们就是创建动态队列者的话，那么我们在用MQQueue 类的 CloseOptions 属性时，应当在关闭选项中指定下面选项中的任意一个：
第 191 页 共 217 页
13.5.5 关闭连接
为了断开与队列管理器的连接，我们可以利用MQQueueManager 类的Disconnect（）方
法：
QueueManagerObject.Disconnect
所有与MQQueueManager 对象相关联的队列对象都将不可用，且不能重新打开。任何未
提交的改变（消息放置和获取）都被提交。
13.6 事务处理管理
用来控制事务处理的API 调用取决于使用中的事务处理的类型。有以下三种情境：
当WebSphere MQ 消息（本地工作单位）是唯一的资源时。在此种情况下，根据MQPutMessageOptions 或MQGetMessageOptions 对象的MQPMO_SYNCPOINT 或MQGMO_SYNCPOINT 选项的指定，事务处理由同步点控制下的第一个被发送或接收的消息启动。同一个工作单位可以包括多个消息。事务处理可以利用Commit()方法提交，也可以利用MQQueueManager 对象的Backout（）方法取消。
下例显示了如何在同步点控制下放置消息。
例，在同步点下放置消息
下例显示了如何在同步点控制下获取消息。
例，在同步点下获取消息
第 192 页 共 217 页
??当WebSphere MQ 作为扩展架构事务处理协同器（全局工作单位）时。事务处理必须在 第一个可恢复资源（如关系数据库）改变前用MQQueueManager 类的begin（）方 法显式启动。而后，工作单位可以利用commit（）方法提交，或者利用
MQQueueManager 对象的backout（）方法取消。
下例显示了在WebSphere MQ 作为扩展架构事务处理协同器时我们可以如何利用 第 193 页 共 217 页
??当使用外部事务处理协同器（如Microsoft 事务处理服务器）时。在这种情况下，事务处理由外部事务处理协同器的API 调用控制。简单说就是，Microsoft 事务处理服务器从本质上是本地和远程计算机上COM/ActiveX 组件的一个管理工具。
Microsoft 事务处理服务器一般与前端处理机代码（它是Microsoft 事务处理服务器中对象的COM 客户）一起使用，也同后端处理机服务（如数据库）一起使用。前端处理机代码可能是巨大的独立程序，也可能是基于因特网信息服务器的活动服务器页。前端处理机代码可能位于Microsoft 事务处理服务器及其商业对象所处的同一台机器上，并通过COM 相互连接。
前端处理器代码也可能位于另外一台机器上，通过DCOM 相连接。在不同的情况下，我们可以利用不同的客户机来访问相同的Microsoft 事务处理服务器商业对象。使用哪台客户机或者客户机如何连接到Microsoft 事务处理服务器不会对Microsoft事务处理服务器及其商业对象造成任何影响。客户机对象可能由任何语言在任何支持COM 客户机代码编写的第 194 页 共 217 页
环境中写成。最常见的是用于巨大客户机的Visual Basic和用于小客户机的VBScript 或JavaScript。商业对象可以由任何支持COM 服务器代码编写的语言写成。最常见的是Visual Basuc、C++和Java（Microsoft 的）。Microsoft 事务处理服务器被设计用来帮助用户在典型的中间层服务器上运行商业逻辑应用程序。它将工作分为活动，这些活动通常都是比较短的、独立的商业逻辑块。Microsoft 事务处理服务器推出了许多特性，能够简化可升级分布式应用程序的编写。在Windows2000 中又推出了称作COM+的新产品。该产品也是Microsoft 事务处理服务器的一个发展。
13.7 分组
WebSphere MQ Automation Classes for ActiveX 允许在一个消息组中包含一系列相关的消息，并作为一个消息组被发送。组环境信息与每个消息一起发送，使得消息系列可以被保存，对接收应用程序可用。组身份定义在消息描述器结构中，我们可以通过MQMessage 类来访问它.
除了最后一条消息具有MQMF_LAST_MSG_IN_GROUP 选项外，组中的每条消息都必须具备MQMF_MSG_IN_GROUP 选项。组中消息的顺序储存在MQMD 结构的MsgSeqNumber 字段中，它由队列管理器自动生成。
另外，队列管理器可以控制是否已完全接收消息组。如果只须显示完成的消息组的话，那么我们可以在获取消息选项结构中设置MQGMO_ALL_MSGS_AVAILABLE 选项。 13.8 本章小结
本章概括介绍MQSereis Automation Classes for ActiveX，讲解其定义，介绍我们能够如何利用其来处理WebSphere MQ 队列管理器对象。
13.9本章练习
1.使用WebSphere MQ automatin classes for ActiveX编写文件的发送程序。
2.使用WebSphere MQ automatin classes for ActiveX编写文件的接收程序。
第十四章 用AMI编程
学习使用WebSphere MQ AMI 编程。
第 195 页 共 217 页
14.1 概述
应用程序消息接口（AMI）是对现有WebSphere MQ API 的最新补充。其可向程序员提供一种可以用于处理队列管理器对象非常简单的接口。利用AMI，程序员不必深入了解所有MQI 调用，他们只要专注于应用程序的商业逻辑即可。这就意味着在编程时出现的错误更少，具有更高的处理业务及技术改变的灵活性。AMI 减少了编写新应用程序所需的代码数量。
每种编程模式都有不同的调用。举例说来，如果程序员希望编写发布/预订应用程序代码，那么他将必须采用不同于编写请求/回复应用程序的程序员所采用的调用。单个函数之中的结构更少，但是动词会更多。许多函数现在都是中间件层的一部分，在中间件层，企业确立的一系列策略代表应用程序得以应用。AMI包括了Java、C 和C++等在内的标准编程语言的接口。
AMI允许中央集中式控制和灵活的改变管理，为点到点模型提供高级接口，可以进行发布/预订工作。AMI 的重要特点是，其是独立于运输和消息发送基础设施的。 可采用以下方式发送和接收消息AMI： ? ??发送-遗忘，不需要回复。
? ??分配表，将消息发送到多个目的地。 ? ?
??请求/回复，发送消息的应用程序需要请求消息的回复。 ??发布/预订，由代理管理消息的分配。
利用AMI，程序员通常需要处理三个概念： ? ??消息，或者说交换的是“什么”。消息包括： - 标题信息，确定消息及其属性。
- 消息主体，包含应用程序数据。应用程序数据可以由应用程序生成，也可以由消息服务API 生成。
在采用MQI 的WebSphere MQ 应用程序中，消息属性是用MQI 显示设定的，因此应用程序设计人员必须理解其目的是什么。利用AMI 工作时，消息属性包括在消息对象中，或由系统管理员设定的策略所定义，因此程序员就不必再关心这些细节。 ?
??策略，或者说将要“如何”处理消息。其包含优先级或交付确认等信息。任何数量的
应用程序都可以利用相同的策略，而且任何应用程序都可以利用超过一个的策略。IBM 提供了一套通用或默认策略，此外，其也提供了开放式策略处理器框架，该框架允许第三方软件销售商创建更多策略。如果必须修改策略的话，那么通常来说，我们不必修改应用该策略的应用程序。 ?
??服务，或者说消息将被发送到“何处”或应从“何处”接收消息。就
WebSphere MQ 而言，这是指队列、分配表等。服务可以是指由单个应用程序提供服务的单个目的地，也可以是指目的地列表或消息代理。服务通常定义在储存库（REPOSITORY）中，其可指定到消息发送网络中真实资源的映射。储存库可以定义不同类型的服务。服务由AMI
暗示打开和关闭。
储存库可为服务及策略提供定义。如果服务名或策略名在储存库中找不到，或者AMI应用程序没有储存库，那么就可采用集成在AMI 中的定义。将储存库定义保存在XML格式的储存库文件中。这些定义可以通过管理工具进行更改，但只能在Windows 平台上才可获得
该管理工具。
利用标准文件共享工具或者简单的文件发送，我们可以在不同的平台上共享储存库文件。重要的是要明确AMI 应用程序不管具备或不具备储存库时都可以运行。如果没有储存库，那么就将使用默认值。
在管理工具中，被称为“服务点”（service point）的单个定义可代表储存库中发送者和接收者的定义。利用管理工具，我们可以界定义如下对象： ? ??服务点 ? ? ? ?
??分配表 ??发布者 ??预订者 ??策略
不管有无相对应的储存库定义，我们都可以创建策略以及除分配表之外的服务。只有在创建服务点之后才可创建分配表。利用储存库创建服务或策略时，必须包含专用类型的定义，其命名应与应用程序所指定的名称相对应。
举例来说，创建名为“ORDERS”的发送者对象时，储存库必须有一个名为“ORDERS”的服务点定义。利用储存库创建的策略和服务，其内容由称为命名储存库定义进行初始化。无储存库的策略和服务，其内容由在默认系统定义中定义的值进行初始化。管理工具只是WebSphere MQ AMI SupportPac （MA0F）for Windows NT 的一部分，并只能安装在运行Windows NT 4.0 或Windows 2000 的机器上。启动管理工具时，应选择IBM WebSphere MQ AMI－>IBM WebSphere MQ AMI Administration Tool，或者从Windows 资源管理器中双击文件\amt\AMITool\amitool.bat。下图显示了AMI 管理工具。
图，AMI 管理工具
AMI 具有两个不同的角色：管理角色和开发角色。
在开发作用中，开发者专注于利用管理员提供的资源发送信息。这一作用不需要深入了解WebSphere MQ。管理作用则负责创建和定义储存库中的服务和策略。换言之，管理员定义信息将被发送到“哪里”以及“如何”发送信息。这一作用要求深入了解WebSphere MQ。利用AMI，简化连接代码以便在发送或接收消息时确定服务或策略。利用管理工具在储存库中定义策略和服务，因此管理员可以修改它们而不会对应用程序造成任何影响。利用AMI，我们可以在下面一种或更多种情况中交换消息： 1，与另一个使用AMI 的应用程序交换。
2，与使用任何不同WebSphere MQ API （MQI、WebSphere MQ Classes for Java、ActiveX 等）的应用程序交换。
3，与消息代理交换（WebSphere MQ 发布/预订或WebSphere MQ Integrator）。
AMI 简化了发布/预订应用程序的创建。发布/预订环境中的许多配置都存在储存库中，应用程序从中获取参照。如果程序员希望寻找简单的、毋需深入了解WebSphere MQ 的API，那么我们就会推荐AMI。AMI 可以通过SupportPac （MA0F）获得，也可以从下面的 IBM 网站地址中下载：http://www.ibm.com/software/ts/WebSphere MQ/txppacs/；
提示：在尝试采用AMI 的发布/预订功能前，必须先安装WebSphere MQ Publish/Subscribe SupportPac （MA0C）。
14.2 平台和语言
AMI 适用于C、C++和Java 语言。其可应用于以下平台上： ? ? ? ? ? ?
?Windows NT
和Windows 2000
?AIX 版本4.3 或更高版本
?Sun Solaris 2.6
或2.7
?HP－UX 版本11.0
?AS/400
版本4R4 或更高版本
AMI 也适用于COBOL，但仅限于OS/390 版本2R6 或更高，以及CICS 版本4.1 和IMS版本5.1。
AMI 的过程应用程序编程有两个级别：
??高级：程序C 和COBOL（在OS/390 接口上）。由于操作是隐式的，因此AMI 函数数量减少。
??对象级：Java 和C++类接口/对象风格C 接口。
提示：C 高级接口包括适应大多数应用程序要求的功能。但是，如果我们需要更多的功能的话，那么可以采用C 对象接口和高级接口的组合。
AMI 除了可提供简单的接口来处理队列管理器对象外，其对每种编程语言都有一个自然的风格。下例显示了采用C API 的发送-遗忘应用程序。
下例中出现的应用程序与上例中的发送-遗忘应用程序相同，不过这回它是用Java API 编写的。请注意，这两种编程语言的每一种都具有自然的风格。 例，用
Java 编写的简单发送- 遗忘应用程序 14.3 库和包
现在，我们已经了解了可以用来编写AMI 应用程序的不同编程语言，接下来，我们就必须
了解用于编写AMI 应用程序的不同的库。如果利用C 语言来编写应用程序的话，那么AMI 会提供头文件，称为amtc.h。该文件包括AMI 所用的所有函数、结构和常量。该头文件必须包含在应用程序中，我们可以用下面的语句来做到这一点： #include <amtc.h>
下图显示了在支持AMI 的不同平台上amtc.h 文件所处的位置。 表， AMI C 头文件的位置
提示：在编译时间内，程序必须能够访问amtc.h 文件。
就C++而言，AMI 还可提供另一个头文件，称为amtcpp.hpp。该头文件包括C++的函数、 结构和常量，与C 语言的头文件完全一样。同样，amtcpp.hpp 也必须包含在应用程序中。 我们同样也可以用下面的语句来实现这一目的： #include<amtcpp.hpp>
下表显示了amtcpp.hpp 文件在支持AMI 的不同平台上的位置。
提示：在编译时间内，即便amtcpp.hpp 是唯一在使用中的头文件，程序也必须可以访问 amtc.h 和amtcpp.hpp 这两个文件。
如果开发人员希望使用Java API 的话，那么AMI 可提供包括构成AMI package for Java所有类的JAR 文件。
??Java
包：com.ibm.mq.amt
??Java JAR 文件：com.ibm.mq.amt.jar
为了使用AMI package for Java，我们必须利用导入语句将其导入Java 应用程序： import com.ibm.mq.amt.*；
提示：JAR 文件必须是CLASSPATH 环境变量的一部分（这必须在编译和运行Java 应用程序的环境中完成）。
下表显示了AMI JAR 文件在支持AMI 不同平台上所处的位置。 表， AMI Java JAR 文件的位置
表，语言编译器
如欲了解如何在所有支持的语言中准备并运行AMI 应用程序的更多信息，请参见WebSphere MQ 应用程序消息发送接口文档。
14.4 体系结构模型
AMI 可提供以下对象：
? ??会话：用以创建新的AMI 会话，并用以控制事务处理支持。这是在创建和管理所有? ? ? ? ? ?
其他对象（消息、策略、接收者等）前第一个需要初始化的对象。
??消息：该对象包含消息数据以及发送或接受消息时用到的消息描述符结构。 ??发送者：代表消息发送目的地的一项服务。MQOD 结构包含在该对象中。
??接收者：代表消息接收来源的一项服务。MQOD
结构也包含在该类中。
??分配表：包含发送者服务列表，提供目的地列表。
??发布者：包含发送者服务，其中目的地是一个发布/预订代理。
??预订者：包含发送者服务，将预订和取消预订消息发送至发布/预订代理，也包括一个
接收者服务，接收来自代理的发布内容。
? ??策略：定义应当如何处理消息，包括优先级、持久性，以及其是否应包括在工作单元
中等项目。
发送者、接收者、分配表、发布者和预订者都是服务。直接连接到消息传输层的唯一对象是发送者和接收者。因此，分配表和发布者对象包含发送者，而预订者对象包含发送者和接收者。下图显示了AMI 体系结构模型，并反映了每个对象如何与其他各个对象进行互动。
图， AMI 体系结构模型
消息、服务和策略对象是由会话对象创建和管理的。会话对象也提供工作单元的范围。连接、发送者和接收者对象的组合可提供消息的传输。
程序员可以利用系统默认提供的消息属性、服务和策略对象，也可以利用管理员定义的、储存在储存库中的属性。除了以上提到的对象之外，AMI 还为C++和Java 提供了更多的对象定义。
这些对像包括：
??会话库：该对象用以创建会话对象。没有会话库，就不能创建会话对象。
??协助对象和异常对象（Helper and Exception objects）。
14.5 用AMI编程
本节所用的实例是采用Java接口编写的。如欲了解如何采用其他支持AMI 的编程语言发出调用，请参考应用程序消息发送接口文档。
14.5.1 连接到队列管理器
正如在其他WebSphere MQ API 中一样，在尝试访问任何队列服务器对象之前，我们都必须
连接到队列服务器。我们可以利用两个AMI Java 调用实现这一目的。首先，需要创建新的会话库对象。在此应记住，为了创建会话对象，必须至少有一个会话库对象（这只适用于C++和Java）。用来创建会话库的命令是：
SessionFactoryObject ＝ new AmSessionFactory（String factoryName）
FactoryName 是一个可选参数。该字符串实际上就是储存库和主文件所在的目录，其也可以是完全指定的目录，包括文件所在的路径，例如：C:\Program Files\WebSphere MQ\amt。如果该参数没有指定，那么我们将使用AMT_DATA_PATH 环境变量所指定的值。该环境变量通常是在WebSphere MQ AMI SupportPac（MA0F）安装时设定的。创建会话库对象之后，我们可以定义新的会话对象。通过利用AmSessionFactory 类的createSession（）方法来进行这一工作。
mySessionFactory.createSession（String sessionName）
sessionName 参数是我们可以用来确定会话对象的名。一旦会话库初始化且创建了会话对象，应用程序就可以处理WebSphere MQ 对象了。在AMI 中，队列管理器名是从位于{WebSphere MQ 基目录}/amt 的主文件（默认情况下是amthost.xml）中读取的。下面显示了用来连接到称为ITSOH 队列管理器的主文件样例。如果defaultConnection 标签没有指定队列管理器的话，那么将采用默认的队列管理器。
例， 主文件样例
下例显示了如何创建AmSessionFactory 对象，以及名为ITSO 的AmSession 对象。 例，
创建新对象
一旦创建了会话，我们在创建其他AMI对象时所采用的顺序就并不重要了。但是，我们建议您以如下顺序对对象进行初始化： 1. 会话
2. 策略
3. 发送者/接收者/发布者/预订者/分配表 4. 消息
14.5.2 打开WebSphere MQ对象
创建会话库和会话对象之后，下一步应创建/初始化其他AMI 对象。
14.5.2.1创建策略
首先，我们需要创建策略对象。我们可以利用AmSession 类的createPolicy（）方法来达到这一目的。
sessionObject.createPolicy（String policyName）
如果我们所指定的policyName 与储存库中已经存在的策略名相匹配，那么将会采用储存库定义来创建策略。如果储存库中不存在这种策略名，则将采用默认值创建策略。在下例中，我们可以看到如何创建AMT.SAMPLE.POLICY。由于储存库已经定义了AMT.SAMPLE.POLICY，因此该策略将用储存库已定义的值进行创建。 例，创建策略对象
创建策略之后，下一步就是根据应用程序要采用的设计模式来创建对象模式。对象类型可以是：
??发送者和/或接收者（也称服务点） ??发布者 ??预订者 ??分配表
14.5.2.2创建发送者
为了创建发送者对象，我们要用到会话对象的createSender（）方法。
sessionObject.createSender（String senderName）；
如果指定的senderName 与储存器中已存在的相匹配，那么将采用储存器中的定义来创建发
送者对象。如果不存在的话，那么将采用默认值来创建发送者。下例显示了如何创建一个称为AMT.SENDER.NAME 的发送者。
例，创建发送者
14.5.2.3创建接收者
为了创建接收者对象，我们要用到会话对象的createReceiver（）方法。
sessionObject.createReceiver（String receiverName）；
如果我们指定的receiverName 与储存器中已经存在的相匹配，那么将采用储存器中的定义来创建接收者对象。如果不存在的话，将采用默认值来创建接收者。下例显示了如何创建一个称为MT.RECEIVER.NAME 的接收者。
14.5.2.4创建发布者
为了创建发布者对象，我们要用到会话对象的createPublisher（）方法。
sessionObject.createPublisher（String publisherName）；
如果我们指定的publisherName 与储存器中已经存在的相匹配，那么将采用储存器中的定义来创建发布者对象。如果不存在的话，那么将采用默认值来创建发送者。发布者和预订者所用的发送者和接收者点的服务类型必须在储存库中定义为MQRFH。这就会产生MQRFH 标题，包含发送/预订名/值等因素，这些将在消息发送时被加到消息中。如欲了解更多信息，请参见应用程序消息发送接口文档。下例显示了如何创建称为AMT.PUBLISHER.NAME 的发布者。
例，创建发布者
14.5.2.5创建预订者
为了创建预订者，我们要用到会话对象的createSubscriber（）方法。
sessionObject.createSubscriber（String subscriberName）；
如果我们指定的subscriberName 与储存器中已经存在的名称相匹配，那么将采用储存器中的定义来创建预订者对象。如果不存在，将采用默认值进行创建。下例显示了如何创建一个称为AMT.SAMPLE.SUBSCRIBER 的预订者。
例， 创建预订者
14.5.2.6创建分配表
为了创建分配表对象，我们要用到会话对象的createDistributionList（）方法。
sessionObject.createDistributionList（String distributionlistName）；
如果我们指定的分配表名与储存器中已经存在的相同，那么将采用储存器中的定义创建对象。如果不存在，将采用默认值创建分配表。在我们能使用分配表之前，管理员必须首先定义发送者服务，再将这些服务定义为分配表的一部分。下例显示了应当如何创建分配表。
14.5.2.7创建消息
为了创建消息对象，我们要用到以下AmSession 类的createMessage（）方法。
AmSession.createMessage（String messageName）
对应用程序而言，MessageName 是具有意义的名称。下例显示了一段代码样例，告诉我们如何创建称为ITSO.SAMPLE.MESSAGE.NAME 的消息。
例， 创建消息对象
现在我们已经创建了对象，那么下一步就要打开这些已被定义的对象。利用open（）方法来进行这一工作。举例来说，如果需要打开发送者对象，那么就要用到该发送者对象的open（）方法。所有的打开调用都分享一个共同的参数，这就是策略对象，open()方法的语法如下：
下例显示了如何打开会话、发布者和接收者对象。
例，打开不同类型的对象
14.5.3 基本操作
下面讨论可对这些WebSphere MQ 对象进行哪些基本操作。这些基本操作包括获取消息、发送消息、发布和预订消息。
可以在MQI 中发送或接收消息之前，我们必须先打开队列，以获得输入或输出。在MQI中，这被称为打开选项（MQOO_INPUT_SHARED, MQOO_OUTPUT）。在AMI 中，由管理员给出这些定义，并将其保存在储存库中，因此在队列管理器对象打开或作为一部分调用的时候，程序员不必对其做明确的定义。
为了发送消息，我们要用到发送者类的send（）方法。请记住，在尝试发送消息之前，必须创建至少四个对象（会话、策略、消息和发送者）。如果我们需要获得回复的话，那么还必须创建接收者对象和另外的消息对象。
消息内容总是以字节形式发送的（Java 的本身形式），因此我们建议您在发送消息前用getBytes（）方法（Java 的本身方法）将消息转化成字节数组。一旦转化消息，接下来就应当利用发送者类的writeBytes（）方法将其写入消息对象中。
senderObject.send（AmMessage messageObject, AmReceiver receiverObject/AmMessage
receivedMessage, AmPolicy policyObject）
另外，我们可以指定策略对象和/或接收者或另一消息对象。请记住，策略是指“如何”处理消息。换言之，我们利用策略可以指定优先级，或者说如果送达消息时出现错误的话，那么应当采取哪些行动，等等。
如果我们要求某种类型的回复，比如送达报告确认或远程应用程序的确认，那么我们就必须根据希望如何处理回复而指定接收者对象或消息对象。下例显示了发送消息样例方法。 例，发送消息样例
我们也可以同时将消息发送到多个目的地。我们可以利用distributionList 对象的send（） 方法做到这一点。下例显示了将消息样例发送到多个目的地的实例的方法。
例， 将一条消息发送到多个目的地
获取消息
为了获取消息，我们要用到接收者类的receive（）方法。
amReceiver.receive（AmMessage messageObject, AmSender senderObject, AmMessage
selectionmessageObject, AmPolicy policyObject）；
要该调用中有4 个参数，但其中只有messageObject 是始终需要的。接收的消息将被储存在此参数中。如果发送应用程序请求回复的话，那么就必须指定senderObject。PolicyObject 用来指定等待时间间隔，或是否要求数据转换等。如果我们需要根据关联性ID（correlation ID）获得某个特定消息的话，那么就必须指定selectionmessageObject。下例显示了如何接收消息。 例，接收消息
发布消息
发布消息时，应当遵从以下几个步骤。一旦打开消息和发布者对象，就需要为消息创建新主题。该主题就是描述将要发布数据的词。我们用消息类的addTopic（）方法创建主题。
messageObject.addTopic（String topicName）
唯一所需的参数就是topicName，正如我们前面谈到的那样，其为描述将要发布数据的词。
添加主题之后，我们就可以发布消息了。为了发布消息，要用到发布者类的publish（）方法。
publisherObject.publish（AmMessage messageObject, AmReceiver
receiverObject, AmPolicy policyObject）
messageObject 是包含将发布消息的对象。只有在策略不指定发布者的隐式注册（implicit registration）的情况下，才可以省略receiverObject。总是应当指定MessageObject。如果没有指定policyObject，将采用默认定义。
下例显示了如何发布消息的样例代码。在该例中，没有指定policyObject；因此我们将采用默认定义。默认定义不要求发布者的隐式注册，因此不要求receiverObject。
例， 发布一条消息
预订消息
为了预订消息，应用程序应当就感兴趣的信息发送请求。我们通过在请求中包含主题来实现这一目的。一旦请求完成，预订者就可以接收来自许多不同发布者的信息，而且也可以将接收到信息发送给其他的预订者。为了在请求中包括主题，我们可以使用消息类的addTopic（）方法。
topicName 是确认数据的一个名，该数据对预订者应用程序有用。对应用程序希望预订的每个主题，都必须使用该调用。一旦应用程序定义了所有主题，就用预订者类的subscribe（）方法发送预订请求。
subscriberObject.subscribe（AmMessage messageObject, AmReceiver
messageObject 是我们利用addTopic（）方法向其添加主题的对象。该参数是可选的。将匹配预订请求的发布内容发送到receiverObject。但是，该参数并不总是需要的。另一种接收匹配请求的发布信息的方法就是发出预订类的receive（）方法。
可以确定，也可以不指确定PolicyObject。如确定，那么策略就包含匿名注册、仅接收新发布内容等选项。如果未确定的话，那么将采用默认策略。如果receiverObject 在预订请求中未确定的话，那么可以利用receive（）方法接收发布内容。
subscriberObject.receive（AmMessage messageObject, AmMessage
selectionmessageObject, AmPolicy policyObject
messageObject 将包含所有已发布的消息，并在消息接收前进行隐式重置。只有在我们希望根据关联性ID 选择某个特定消息时才采用selectionMessageObject。如果未确定的话，那么就接收第一个可用的信息。可以确定PolicyObject，也可以不确定。
一旦我们接收了符合预订请求所确定标准的所有消息，或者说我们不需要更多的消息了，那么应用程序就可以取消预订，换言之，应用程序此时可以发出请求，这样就不会再发送更多的消息了。
应用程序可以发送一个请求，取消预订其最初请求的所有主题，也可仅取消预订某个特定主题。通过发出预订类的unsubscribe（）方法，我们可实现这一目的。
subscribeObject.unsubscribe（AmMessage messageObject, AmReceiver
messageObject 包含取消预订请求所应用的主题。如需要获得取消预订请求的确认，那么必须发出receiverObject。正如前面的调用一样，可以确定策略，也可以不确定。下例显示了如何应用我们在本节所讨论的这些调用。
例，预订消息
14.5.4 删除会话并关闭连接
我们对队列管理器应用程序的工作完成之后，接下来就可关闭对象了。我们利用每个被用对象的close（）方法来实现这一目的。另一种方法就是仅关闭会话对象。一旦关闭该对象，其他对象也将关闭。但是，我们强烈建议您隐式关闭所有已打开的对象。
所有这些close（）方法需要的唯一一个参数就是policyObject。请记住，policyObject也包含关闭选项，如关闭时删除动态队列等。如欲了解更多信息，请参见WebSphere MQ 应用程序消息发送接口文档。
提示：最后一个必须关闭的对象是sessionObject。一旦关闭sessionObject，其他参照都会无
效。
14.6 AMI和MQI的比较
我们已经讨论了WebSphere MQ 所提供的不同API，现在，我们可以谈谈它们彼此之间的比较。在这一节中，我们将对AMI 和MQI 进行比较。利用MQI，消息目的地和消息的发送/接收选项均由应用程序管理，而利用AMI，则由策略管理。MQI 提供全部WebSphere MQ 函数支持，只考虑消息传输。AMI 提供较少的WebSphere MQ 函数，但提供更多的功能性。 MQI 的编程接口属低级的（动词较少，但有很多结构），对不同语言（C、C++、Java和COBOL）来说，其API 都是相似的。AMI 具有高级编程接口，这意味着其动词更多，而结构更少，而且其API 对每种不同的编程语言都有各自自然的风格。MQI 根据传输而不同，AMI 则独立于传输。MQI 是IBM 的所有，而AMI 的子集符合开放应用程序组/开放应用程序中间件API 标准（C++和Java）。
14.7 事务处理管理
为了使AMI 发送和接收的消息成为事务处理工作单元的一部分，管理员必须利用AMI管理工具指定策略的同步点属性。在默认情况下，将同步点属性设为关闭。我们可以在策略定义的General 标签中找到该属性。控制事务处理的API 调用取决于正被使用的事务处理类型。此处有两种不同的情况：
??当唯一的资源是WebSphere MQ 消息时：
在这种情况中，根据策略中就发送或接收对象所确定的那样，事务处理由同步点控制下第一个发送或接收的消息来启动。多个消息可以包括在同一工作单元中。可以用会话对象的commit（）方法提交事务处理，或者也可以用会话对象的rollback（）
方法取消事务处理。
下例显示了WebSphere MQ 消息作为唯一资源的同步点控制实例。
例，同步点控制
??WebSphere MQ 作为XA 事务处理协调器（XA transaction coordinator）在可恢复资源（如关系数据库）发生改变之前，须用AmSession 类的begin（）方法显式启动事务处理。而后，可以用AmSession 类的commit（）方法提交工作单元，或者用AmSession 类的rollback（）方法予以取消。下例显示了WebSphere MQ作为XA 事务处理协调器的实例。
例，WebSphere MQ 作为XA 事务处理协调器
提示：如果使用外部事务处理协调器（如Tuxedo），就可能出现另一种情况。在这种情况下，我们利用外部事务处理协调器的API 调用来控制事务处理。尽管没有使用AMI调用，但同步点属性仍必须在调用使用的策略中确定。
14.8 分组
AMI 允许将一系列相关消息包含在消息组中或作为消息组发送。组上下文信息（group context information）随每个消息发送，以使消息系列得以保存，并可由接收程序获得。为了将消息包含在消息组中，组中第一个和后续消息的组状态信息（group status information）必须进行如下设定：
??第一条消息设为AMGRP_FIRST_MSG_IN_GROUP
??除第一和最后一条消息外，所有消息均设为AMGRP_MIDDLEMSG_IN_GROUP ??最后一条消息设为AMGRP_LAST_MSG_IN_GRP
我们可以利用消息类的setGroupStatus（）实现上述目的。
messageObject.setGroupStatus（int groupStatus）
groupStatus 可以为下面任何值：
??AMGRP_MSG_NOT_IN_GROUP
??AMGRP_FIRST_MSG_IN_GRP
??AMGRP_MIDDLE_MSG_IN_GRP
??AMGRP_LAST_MSG_IN_GROUP
??AMGRP_ONLY_MSG_IN_GROUP
如果AMGRP_FIRST_MSG_IN_GROUP 在序列外， 那么该消息的行为与AMGRP_MIDDLE_MSG_IN_GRP 相同。
提示：一旦应用程序开始发送在组中的消息，那么在尝试发送不在该组内的任何其他消息之前，必须先发送完该组的消息。
14.9本章小结
本章概括介绍了应用程序消息接口，讲解什么是AMI 以及如何应用AMI。 14.10本章练习
1.使用WebSphere MQ AMI 编写文件的发送程序。
2.使用WebSphere MQ AMI编写文件的接收程序。
附录一 WebSphere MQ的缺省系统对象 保留的队列名称
以“SYSTEM.”开始的名称保留为队列管理器定义的队列名。您可使用 ALTER 或 DEFINE REPLACE 命令来更改这些队列定义以适合您的安装。为 WebSphere MQ 定义以下名称：
第 216 页 共 217 页
其它对象名
进程、名称列表、群集和认证信息对象对象名称可以长达 48 个字符。通道名称可长达 20 个字符。存储类名称可长达 8 个字符。
保留的对象名
保存以“SYSTEM.”开始的名称为队列管理器定义的对象。您可使用 ALTER 或 DEFINE REPLACE 命令奈更改这些对象定义以适合你的安装。为 WebSphere MQ 定义以下名称：
第 217 页 共 217 页
61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1
