消息文件传输解决方案

IBMSoftwareWebSphere技术白皮书IBMMQ:借助集成式消息传递实现企业互联目录1实现企业互联3复杂性问题4加速变革及潜在解决方案7实现业务系统与应用的互联8什么是IBMMQ10IBMMQ-架构与功能17在关键场景中使用IBMMQ的理由19业务价值19下一步行动加速消息在组织内的流动,并将业务价值向外扩展至智能设备和手机.
创建更具响应性的业务,同时支持在应用、系统和服务之间快速、可靠、安全地传输信息.
降低复杂性并减少维护,进而降低成本.
采用新的解决方案和技术(从主机到移动企业技术),推动收入提升.
实现企业互联从小处起步企业的信息技术(IT)历史就是事物互联的历史.
无论IT的作用是连接人员、应用、系统还是连接数据,随着时间的推移,各个方面的业务和基础架构之间的连接数量都会不断增加,而且基础架构也会大幅扩展到无法估量的地步.
连接方面增长的关键因素在于所生成信息的数量及其使用量的不断增加.
这种信息使用量和互联的增长也为企业领导者带来了新的挑战.
IBMSoftwareWebSphere技术白皮书如果只是孤立地看待企业IT基础架构的某个部分或仅仅着眼于单个应用,可能会发现并不存在任何大问题.
任何应用、用户看起来都比较简单.
毕竟,应用互联和数据交换从本质上说并不复杂,至少在一切正常的情况下确实如此.
不过,正如俗话所说的那样,"细节决定成败".
几乎每个企业的详细信息都潜藏在各种应用和系统内,因此会生成大量数据,而且所有这些数据对企业来说都可能极具价值.
此外,还需要在确保没有任何损失、风险或延迟的条件下对这些数据进行存储、跟踪和审核.
随着时间的推移,任何应用的连接都可能会随着业务机会的变化、新的业务合作关系的建立以及客户交互及需求的提升而不断增加、改变和演化.
因此,在日益激烈的全球竞争环境下,这就会给企业带来越来越多的挑战.
您必须满足自身企业、合作伙伴和客户不断变化的需求,而且必须在正确的时间向正确的地点提供正确的信息.
您必须在不影响信息安全且不造成数据丢失或损害数据完整性的前提下实现这一目标.
此外,您还必须确保这种IT基础架构的配备过程不会过于复杂,否则就会增加成本、降低IT组织在全年度对诸多改变的响应性.
应用的复杂性随着所用技术的增加而增加客户网上商店门户合作伙伴、供应商http互联网标准soap/httpJDBCJMS文件soap/http后端图1.
随着业务基础架构从简单到复杂的演变,复杂性也在不断增长.
2IBMSoftwareWebSphere技术白皮书日益增长的复杂性若要改善当今的复杂IT环境,首先就必须了解相应问题,但随着系统互联的增多和发展,做到这一点变得愈发困难.
多年来,这些问题正在变得愈发严重,而且越来越紧迫.
回顾过去,企业计算也只不过是若干个单体应用,这些应用作为处理器、数据存储器发挥作用,而且在大多数情况下,这些应用也仅仅是执行一些简单的重复性例行程序,以便了解数据结构.
偶尔,这些应用会用于分批提供信息,以便在夜间处理存储在数据库内的日常活动.
了解和控制方式都十分直接,系统也是如此.
不过,越多越多的计算用户开始期待能够获得更多的最新信息,同时资源和数据也变得更为分散,计算资源和计算结果任凭用户使用,进而导致批处理开始逐渐消亡.
现在,我们正在迈入这个时代的终结阶段.
企业IT基础架构的用户已不再仅仅局限于部分员工,而是涵盖了几乎所有员工,而且用户范围也开始向外扩展,业务合作伙伴和客户也逐渐被纳入到用户范围.
所有这些个人都希望能够随时随地通过任何设备访问任何信息.
如今,很多企业仍有一些批任务,主要用于在夜间批处理白天所累积的工作,但这种批处理方法正在逐渐边缘化.
这是因为很多企业已经不会再在夜间停机.
如果系统夜以继日地工作,就再也不可能在夜间处理白天累积的工作.
因此说,不仅时间关键型处理很重要,而且计算资源也很重要,因为计算资源必须要时刻待命,时刻准备处理基于批处理的工作负载.
复杂性问题既然单个连接这么直接,那么为何还要连接这么多如此复杂的终端和用户显而易见,一方面是连接的规模问题,另一方面就是故障风险.
如果一切工作正常,便可轻松实现系统和应用的互联.
其复杂性在于发生故障时的情况,或是可能发生故障时的情况,而问题的根源就在于这种可能性.
如果了解了一切问题,而且所有故障模式均得到了明确定义,事情就会相对容易得多.
不过,基础架构内的每个程序和每个连接都必须要为可能出现的任何类型的故障模式做好准备,这意味着编程人员在定义编程功能时,必须发挥想象力,假设出比故障记录更为丰富的故障模式.
导致出现故障的可能原因有很多,而且连接的数量越多,可能的故障模式就越会呈指数级增长.
在部分已部署公有云的企业中,我们可以看到为何需要针对故障而进行设计的绝佳例证.
这些托管式基础架构的使用日益普及,同时也是提高可用的计算资源数量的极佳方式.
不过,需要了解的是这些环境可能会发生故障,而且与完全受现有业务控制的一般内部数据中心相比,其故障率可能会更高.
如果客户已在云端部署了关键业务,但未在其部署环境中构建能够处理故障的弹性应用,那么只要一处出现故障,整个应用生态系统就可能会受到波及.
如此一来,由于需要针对故障进行设计而且还要考虑容错性,就导致应用编程人员面对着巨大压力,进而很少注意到业务逻辑,因此造成效率较低.
3IBMSoftwareWebSphere技术白皮书另一个示例是向实物资产互联的转变.
在数据中心外部运行的实物资产之间的互联,意味着需要考虑到更高的故障率.
故障可能会扩展至任何组件或链路.
因此,在构建用于接收数据的应用时,必须考虑到可能出现的故障,而且应用的设计必须考虑到各种故障的监控、容错及故障恢复.
如果不能解耦应用与数据源之间的链接,将会引发灾难性的后果,尤其是当应用和数据数量较多时,情况会更加严重.
在设计应用时,我们不一定非要考虑数据接收问题(尤其是瞬态数据),但应用和设备必然会涉及到相互通信问题,而且需要能够完全独立地完成通信.
最后一个示例是业务本身的速度越来越快.
多年来,后台系统的设计和构建已经可以确保运行所需的高性能和高吞吐量.
这些后台系统可通过每秒的事务处理量、针对提交的特定工作的响应时间进行衡量.
由于很多团队开始在企业外部访问甚至运行这些解决方案,因此他们仍旧希望在企业内部实现一流的可靠性和响应速度.
若要实现这一目标,则需要对这种连接性的实施方法进行实质性评价,以便平衡这些请求.
对于请求的响应而言,即使一秒的延迟也会导致用户不满,而且这种消极的看法会导致用户对解决方案全盘否定.
加速变革及潜在解决方案如今,很多后台系统可能有着较长的历史.
不过,这些企业应用和数据库背后的驱动系统相对较新.
这不仅仅是因为新技术的转型,而且还因为新的业务机会的数量在不断增加,这一趋势将成为基础架构转型的主要驱动因素.
随着新应用的广泛转型和数量上的不断增加(新的数据源、与新员工和现有员工之间的新互动方式),导致很多系统的工作负载大幅增加.
在这类增加中,有一些是出现在高峰时段,这可能是由于外部事件或社交媒体方面的原因,而其他一些则出现在应用负载峰值增加时.
在过去,有些应用只是在白天的少数时段较为繁忙.
现在,得益于移动互联或互联设备,我们可以更连贯地获取更多数据.
这种持续使用就是批处理方法终结的原因之一,其另一原因在于我们希望对所有事务进行即时处理,而通过批处理是不可能实现这一点的.
在过去,转型需求与业务基础架构(包括应用和系统)的关联性较小,因此我们首先制定长期计划,然后逐步完成修改、迁移和更新.
就当时而言,稳定性就是一切.
不过现在,更具响应性才是关键因素.
业务和基础架构必须能够以新的机会为目标,而且必须能够借此机会快速推向市场.
这意味着没有机会构建全新的应用,而且不能中断现有应用并对其作出颠覆性变更.
若要让企业能够响应新的机会,就必须能够对一切进行无缝修改以应对新的运行方式.
这就要求应用在编写后必须连接在一起,为这一领域的成功提供支持.
4IBMSoftwareWebSphere技术白皮书互联性缩小了智能设备、智能决策者与业务流程之间的差距智能化互联化物联化IBMConnectivity总部MQMQTelemetry物流家庭运营店铺离岸人员传感器仪表控制器rfidscada移动图2.
该图展示了移动环境和"物联网"的发展,同时揭示了将这些设备连接至后端系统的重要性.

利用移动互联加速变革对于企业领导者而言,移动计算的急剧增长就是有待发掘的新机会之一.
当然,我们可以通过很多方式发掘这些机会.
举例来说,我们可以通过与移动客户进行互动来促进现有业务发展,还可通过与移动客户进行互动来创造全新的业务机会.
我们还可以基于浏览器的解决方案或移动应用,定制面向移动消费者的业务访问,这样也能充分利用这些机会.
此外,我们还会越来越多地采用基于位置的传感技术,这也会带来新的业务机会.
在这种技术中,客户端设备能够根据物理位置或其他属性直接与企业互动,这样企业便可及时发布全新的产品来推动业务发展.
所有这些均需要我们能够连接到移动环境和现有后端业务系统.
此外,解决方案也需要不断变化,以便反映客户利用相应功能的具体方式,同时这些客户和移动终端的数量可能高达数百万甚至更多.
因此说,并不是要求您一次性编写完应用,然后维持长达10年的时间.
企业与客户之间的互动方式必须快速演变,但同时后端系统也必须能够在确保企业级安全性、可靠性和效率的情况下保持继续运行.
通过"物联网"加速变革其他的诸多新机会与"物联网"有关.
多年以来,业务基础架构一直专注于业务环境内的互联IT系统,但在很多企业中,可能会在内部部署数千种其他设备,而这些设备会在IT环境外部生成并使用数据.
因此,这些设备所生成的数据很少在企业内部使用,即便是使用,所用的数量也非常小,而且无法确保及时性.
不过,现在企业领导者已经看到了访问这种数据的可能性和机会,而且可基于从这些数据中发掘的洞察力采取行动.
这样一来,他们便可识别可能有用的新业务事件,或者从节省成本的角度来说,识别何时无需运行设备,或设备何时消费的能源超过限额.
此外,很多后端系统还需要继续运行并处理不断生成的数据,不过这样可能会增加工作负载以及连接数量.
毫无疑问,对于处在基础架构前线的设备而言-连接至后端系统的设备-都需要运行"小足迹"代码.
这些设备必须要确保能够通过使用轻量级传输协议,将解决方案广泛部署至设备的部署和使用环境.
5IBMSoftwareWebSphere技术白皮书通过部署至云端加速变革直到最近几年,企业领导者才从真正意义上具有两种IT基础架构选项.
他们可以购买大量IT硬件,并雇佣技能丰富的专家团队构建、部署并维护业务运行所需的硬件和软件.
他们也可以选择将所有IT事务外包给具有相关人员和硬件的大型IT服务提供商;在这种情况下,通常需要签订长期合同,以便确定具体使用方式和服务级别.
内部IT资源的情况可能各有不同,有些企业过度使用内部IT资源,有些企业的内部IT资源处于闲置状态.
根据合同从外部提供的IT服务有时会被视为可能会抑制创新和快速变革的"锚点",因为合同中规定的仅仅是需要满足当今需求,而非未来的需求.
云计算的发展使得这一局面发生了变化.
云并非孤立存在的事物;实际上,云意味着以更灵活的方式分配和使用内部IT资源,或者说云是指采用基于使用量的方式根据需求使用公共可用的IT资源.
或者,可将云作为这些部署类型甚至其他部署类型的任何组合.
无论云对于企业领导者有何意义,他们都可能会考虑哪些IT系统和应用适合于在云端进行部署.
这可能是出于成本节省考虑,也可能是为了应对使用的增加而进行的灵活部署,也可能仅仅是从速度方面来考虑.
无论出于什么原因,应用都需要独立于运行时环境以及与企业其他部门之间的连接.
应用的连接必须松散,但需要确保可靠性、安全性,使得业务团队能够在完全不依赖应用架构的条件下即可作出部署决策.
加速推动基于大数据的转型IT使用的增长源自于数据增长,而数据增长也体现了IT使用的增长.
从定义上来说,业务IT就是在业务环境中消费数据,进而生成业务结果.
企业利用IT运行并开展新业务的程度越大,其与数据之间的关系就越紧密,而且数据量就会增加得越多.
不过,正如上文所述,领导者正在逐渐扩展其企业的覆盖范围.
这种覆盖范围可扩展至移动世界,包括不断创建数据的物理设备、每个连接、每项事务、每次客户互动.
每个数据、每个业务机会都需要进行更多处理,也需要评估更多规则并采取更多行动.
此外,当然不可丢弃任何数据.
总而言之,这种活动可生成大量数据.
这种大数据会超越现有的任何IT基础架构,而且所生成和保存的任何数据必须在特定情况下产生价值而且可供使用,否则就是无意义地资源浪费.
6IBMSoftwareWebSphere技术白皮书应用和业务IT基础架构本身需要足够强大,而且必须能够快速实施,以便及时消费所有数据,并能够就所有数据和事件采取行动.
此外,还应能保存并处理其他数据以提取剩余价值.
事实上,应用和基础架构必须既具备高性能又具备"智能".
应用和基础架构的设计不仅要确保我们能够识别以往非常重要的数据,而且还能够识别余下的部分大数据并据其采取行动,进而创造大数据所带来的新的业务机会,但与此同时,大数据也会对IT基础架构带来新的挑战-系统、应用以及它们相互之间的互联.
实现业务系统与应用的互联每个企业都可能会拥有数十、数百甚至数千种应用.
这些应用会部署在不同的IT环境内-主要部署在数据中心,或分散在多个分公司、仓库或国家/地区.
其中部分系统会进行互联,而其他系统则独立运行,或连接至其他应用的部分子集中.
企业领导者不仅会考虑如何通过新应用的互联应对新的业务机会,而且还会考虑现有应用和系统是能够应对当今的挑战还是能够应对未来的挑战.
应用之间的互联方式非常多样化,因此我们必须对其中部分选项加以审核.
无论是在过去所选的选项,还是现在所用的选项,又或是可能在未来被取代的选项,其背后都有相应的原因.
文件传输在目前所用的业务应用互联方法中,其中有一种方法已经使用了多年甚至数十年之久,它就是文件传输.
人们通常认为文件传输非常直接,因为在文件传输过程中,应用将数据写入至文件系统,然后文件传输程序将文件移动至另一系统,以便让另一应用来使用数据.
通过这种方法,无需以任何方式连接应用即可移动数据.
此外,所有系统都具有通用的文件传输协议(FTP)功能.
借助该功能,可简单、快速地编写数据移动脚本.
不过,尽管这一流程看起来比较简单,但也存在很多故障点.
首先,存储在文件中的数据需要确保格式正确.
此外,文件传输也可能会失败,进而导致接收应用所使用的数据较旧或不正确,而且大部分文件传输解决方案很少甚至完全不会考虑安全性和标准传输管理.
因此说,文件在移动过程中可能会出现不完整或已遭损坏的现象.
尽管文件传输仍在广泛采用,而且其设置也非常方便快捷,但一些企业领导者却希望文件传输能够更可靠、更安全,而且可提供报告功能.
如果没有相关记录或日志,文件传输就很容易出现故障.
尽管这一问题屡见不鲜,但我们仍可以通过很多方式对这一方法进行改进.
HTTP随着基于浏览器的前端系统向基于Web的应用这一方向不断发展,产生了另外一种应用互联方法,即将HTTP作为一种标准化的通用连接解决方案.
目前,该方法仍旧在使用,因为它适于任何平台,而且大部分开发人员也都很熟悉该方法,可快速移动系统之间的数据,进而实现开发项目的目标.
用户和开发人员都非常熟悉HTTP,而且如果通过安全套接字层(SSL)对其加以妥善保护,使用HTTP时也会感到非常安全.
不过,尽管HTTP具有以上诸多优势,但同时也有许多缺点.
HTTP的设计宗旨是提供紧密相关的互联.
它并不适用于与时间无关的流程,在这种流程中,您可以随时"关闭"请求,而无需等待响应,也无需在失败时进行重试.
一旦发生网络故障,HTTP请求就无法继续,也无法在事务控制下移动数据,而只能进行点对点连接.
对于大多数数据移动来说,这些限制的影响很小,但如果是在移动业务关键数据而且需要考虑大量其他因素的情况下,就必须要考虑这些限制.
7IBMSoftwareWebSphere技术白皮书嵌入式JMS假设我们使用Java应用服务器来编写应用,那么若要实现应用互联,则可采用另一方式,即:使用Java消息服务(JMS)应用编程接口(API)并利用已嵌入至很多应用引擎的Java消息服务.
如果所有相关应用均在特定Java引擎上运行,那么对于偏好于使用特定Java应用服务器的编程人员来说,这种方法将会非常简单、直接.
不过,上述限制也表明这一方法可能存在问题.
并非所有应用都会使用Java进行编写,而且应用并不一定会在相同的Java应用服务器中运行,这对于大部分Java实施来说是个问题,因为不同的实施之间无法交换消息.
因此,利用嵌入式JMS提供程序实现应用互联仅对于少数用例来说完全有效.
企业消息传递中间件在不同应用之间移动数据的最后一种方法是使用专用的中间件层实现企业消息传递.
该方法与上述嵌入式JMS消息传递所采用的方法类似,但该方法不存在前面所说的局限性,例如仅适于Java、只可连接至在相同的应用服务器环境中运行的其他实例等等.
这种企业消息传递方法同样也可避免HTTP方面的部分限制,因为您可以使用连接更为松散的请求,包括时间独立性和事务处理完整性等等.
这种方法不同于文件传输解决方案;借助这种方法,我们可以在不中断应用的情况下增强、替换或更新现有或新的文件传输方法.
在这一领域中,IBMMQ中间件就是一款领先的解决方案,近20年以来,IT领导者一直都在采用该中间件来构建解决方案.
在接下来的内容中,本白皮书将会详细阐述这种MQ产品,探讨MQ如何针对不同的客户数据移动需求构建解决方案,以及MQ如何结合其他解决方案方法来实现不同部署.
什么是IBMMQ以消息传递为导向的中间件简单地说,MQ可提供消息传递中间件(MOM)功能,该功能有时也被称作"企业消息传递",支持应用、系统和服务之间的集成.
MOM的原则并不是彼此之间进行连接并直接交换信息,而是由应用通过间接中间件层发送信息.
该层级可对将要作为消息进行交换的信息进行打包,并通过队列系统移动消息,进而将消息发送至接收应用.
借助IBMMQ等消息传递中间件,应用可利用简单的应用编程接口(API)发送消息,并将数据移动至消息传递中间件环境.
然后,接收应用可利用同一API检索MOM环境中的数据.
因此,应用程序员可根据消息传递环境处理各个方面的传输故障和错误,而应用则专注于业务逻辑.
此外,API相对简单易学,而且已在各个平台实现了标准化.
8IBMSoftwareWebSphere技术白皮书消息传递系统的本质也有助于实现编程逻辑异步化.
应用无需等待响应或进行检查即可确定接收应用是否可用或是否已接收消息.
因为这种"传输结果检查"由消息传递中间件管理,因此可释放编程资源,简化应用,同时提高连接的可靠性和可管理性.
如果所有应用、网络和数据均可用,异步编程模型就不存在延迟这一弊端,而且具备真正的优势.
此外,对于存在问题、延迟或故障的很多案例而言,应用可通过这种异步方法处理故障,降低编程的复杂性,而且无需频繁进行轮询即可进行成功检查.
使用通过消息传递层的间接连接,意味着发送应用和接收应用的编码可能完全不同,而且还允许使用非常简单的架构方法.
不同于每个业务功能均局限于入站和出站连接接口的业务逻辑,这种方法允许对每个功能进行干净的编码.
然后,很多应用、系统和服务均可单独调用该功能.
干净的编码可显著提高复用的可能性,进而提升应用的业务价值,提高投资回报并提高企业对变化的响应性.
利用IBMMQ快速获取业务价值.
设备可进行预先配置,而且可在数天内完成部署.
20多年以来,IBMMQ一直是全球数千企业在消息传递架构的首选.
借助该解决方案,任何行业的企业领导者均能够以更简单、更快、更可靠且高度安全的方式集成应用和数据源,进而高效利用其现有软件和硬件资产.
优势:为企业提供稳健、安全且更可靠的消息传递连接一切应用,适用于各种平台和编程环境,帮助您妥善解决应用的复杂性问题可提供全面、安全且可靠的消息传递解决方案以支持传统和新兴的消息传递需求凭借一流的服务质量,可确保仅交付一次信息便可实现消息传递通过各种连接功能降低连接应用的成本多年以来,IBM一直在不断丰富IBMMQ的功能,推动平台的持续改进,以应对新的挑战和机遇.
该解决方案的最新升级版是IBMMQV8和IBMMQAdvancedV8.
其主要的新版本可用于多个平台,包括MicrosoftWindows、IBMz/OS、Linux、IBMAIX、OracleSolaris、HP-UX和IBMi平台.
这种新版本以近几年发布的最近版本为基础,并在此基础上添加了一些新的功能.
这些新的功能包括:增强了可扩展性、提高并简化了可靠性,同时更新了平台和标准.
此外,在IBMSystemz服务器上,这个版本可以更好地利用最近的硬件改进功能.
9IBMSoftwareWebSphere技术白皮书IBMMQAdvanced是一种捆绑式产品,包含有助于提供高效的消息传递基础架构的代码和工具.
该产品可提供单一且完整的消息传递解决方案,并集成业内部署最为广泛的消息传递中间件IBMMQ、ManagedFileTransfer、AdvancedMessageSecurity和MQTelemetry.
这些资产旨在提供数千任务关键应用所信赖的强大、便捷的集成式解决方案.
此外,该解决方案还可为开发人员提供MQAdvanced,进而实现旨在加速生产的所有开发和测试目标.
单一的集成式消息传递解决方案IBMMQAdvancedv8IBMMQ-架构和功能自1993年以来,IBMMQ一直是MOM产品领域的不二之选,借助该产品,各种商业IT平台上的应用和系统之间只需一次消息交付,便可实现消息传递的目的.
这种IBM中间件已经成为各个地区和行业数千家IBM客户为其任务关键环境而部署的基本消息传递架构.
IBMMQ可用于80多种平台配置,可提供标准API和专有方法,以确保最大的编程灵活性.
借助IBMMQ,企业能够利用点到点消息传递方法连接应用.
可专门针对特定应用进行编码,进而将消息从一个位置移动至另一位置.
编码员可利用IBMMQ简化连接接口以及所需的其他支持逻辑.
很多企业领导者已经采用了这种做法,以消除应用互联方面的业务风险.
此外,由于企业领导者大都在其应用内使用IBMMQ,这一特点也决定了IBMMQ更适合于作为服务导向式架构(SOA)或作为云迁移的一部分进行较大组件化和复用.
IBMMQIBMMQManagedFileTransferIBMMQTelemetryIBMMQAdvancedMessageSecurity数据的事务性交换IBMMQ的一项基本功能是充当事务管理器.
如前所述,IBMMQ可用于在应用之间发送和接收数据.
不过这里我们以负责两个账户之间资金转移的银行或负责机票预订的旅行社为例.
在这些用例中,均需要对数据进行事务性交换.
借助MQAdvancedV8,可通过IBMConnect:Direct和IBMConnectControlCenter的其他托管文件传输用例权限进一步扩展托管文件传输功能.
现在,开发人员可借助IBMMQAdvanced免费轻松访问这些功能.
此外,每个用户均可购买完全受支持的版本.
10IBMSoftwareWebSphere技术白皮书关键在于:1)完成信息移动,同时确保数据交换双方处于最新状态;或2)一切维持原状.
作为一名企业领导者,您并不希望将资金从一个账户转移至另一账户,或将同一笔资金计入两个账户.
您也不希望在机票预订失败后仍在票务系统上看到该座位已预订的信息.
如要避免这种情况,就需要采用事务管理器.
IBMMQ建立在事务管理器之上,因此可将消息作为事务的一部分进行移动,而且可将受资源管理器事务控制之下的资源作为事务工作单元的一部分进行更新.
籍此,企业仅需移动一次即可确保可靠性,而且在验证应用中也不需要进行复制或设置额外逻辑.
尽管很多形式的信息交换都适合于或需要进行高级事务管理,但其他很多消息类型是瞬态的,而且不需要进行事务控制.
对于此类消息,我们可以对IBMMQ进行相应的配置,进而轻松确保交付并实现消息持久性.
举例来说,在请求账户余额或查询可用机票时,我们完全不需要锁定任何事务,而且在需要时,可重复发送相同的消息.
总而言之,IBMMQ提供了一种更简单的消息交换方法,有助于快速发送消息,降低开销并减少数据移动对整体系统性能的影响.
持久性如果某个事务对于您的企业或客户来说非常重要,那么您就需要确保:即使发生系统故障,也不会对客户数据的处理产生影响.
作为由IBMMQ提供的事务支持的一部分,每个消息都可以永久保存或写入至磁盘(如需要),进而在消息移动阶段维持信息的完整性.
这样,可保存消息并完成事务,而且如果任何一端在事务处理期间发生故障,不会产生数据损失.
对于IBMMQ来说,若要确保一次且仅一次交付消息,同时不会对应用带来复杂的错误处理代码压力,持久性就非常关键.
如果正在移动的数据非常重要,如果移动数据所通过的系统可能会发生故障,或者如果重新构建或提交数据比较复杂,那么持久性也非常重要.
在很多环境下,即使故障很少出现,但总是会发生故障,那么恢复的成本和投入就可以决定是否能够有效利用持久性以轻松完成恢复.
发布/订阅和多播由于企业希望在IBMMQ提供连接层时提升其应用简洁性和灵活性,因此有些企业希望通过"发布/订阅"方法而非"请求/响应"机制进一步提高灵活性.
这种发布/订阅功能完全断开了发送和接收应用之间的联系.
如果采用这一方法,发送消息的应用不会将消息发送至特定接收应用,而是使用主题描述来发布该消息,之后相关应用便可订阅该消息主题.
位于企业内任何位置的任何数量的应用均可接收并使用数据,而且不会对原始应用产生影响.
借助发布/订阅功能,可显著减少支持新的应用所需的维护更新,而且可进一步降低复用可能性.
发布/订阅网络的规模可能很大,如有数千或更多订阅者,那么必须确保所有订阅者均可同步接收信息,而不是产生部分网络延迟和订阅列表延迟.
如果减少大量订阅者的延迟很重要,那么多播就是发布/订阅的一种形式,通过这种形式,可以同时将信息交付至大量订阅者.
IBMMQ团队增加了多播功能,并以此作为2011年第四季度IBMMQV7.
1版的一部分.
11IBMSoftwareWebSphere技术白皮书在IBMMQV8中,如发布/订阅了集群,则已对IBMMQV8进行了增强.
借助这个版本,您可以将角色分配至集群中的队列管理器.
在这些队列管理器中,部分可进行配置,进而实现高效消息路由.
借助这种增强功能,您可以传输有助于让发布-订阅配置进行高效扩展的出版物.
通过IBMMQ网络实现托管文件传输正如上文所述,很多文件均包含关键业务数据.
应用可将数据写入至文件,然后利用文件传输协议(FTP)将该文件复制至另一系统,以便由另一个应用在其他系统中使用此类数据.
不过,正如本白皮书之前所述,即使写入其他层以支持FTP脚本,该方法也可能并不可靠、不安全,而且不受管理.
借助IBMMQ,可通过IBMMQ基础架构将文件作为消息进行发送.
通过利用IBMMQ的本质鲁棒性,不仅可以提高交付可靠性,而且还可提供其他所有IBMMQ功能并利用安全性以及所有管理、跟踪和记录功能.
借助该功能,可将文件传输转变为一种能够移动大量数据的方法,无需改变可对文件进行写入和读取的现有业务应用.
在IBMMQV7.
5发布后,ManagedFileTransfer功能作为IBMMQ软件包的一部分进行提供,即IBMMQManagedFileTransfer,但需要经过单独的授权.
我们还通过其他IBMSterlingConnect权限对该功能进行了增强,可直接进行对等节点文件传输.
此外,借助IBMSterlingControlCenter权限,您可以针对支持IBMMQManagedFileTransfer和IBMSterlingConnect:Direct的文件传输提供基于事件的监控和管理.
如果您需要以高度安全的方式更为可靠地移动文件或文件内容,则可以利用这种增强功能来加以改善.
现在,IBMMQManagedFileTransferAgent作为WebSphereManagedFileTransferManagedEndpoint授权的一部分予以提供,而且按照安装数量(而非客户端设备数量)授予许可.
采用IBMMQ的全面MFT解决方案IBMMQ网络z/OSAS400贸易伙伴MFT代理UNIX边缘组件供应商Windows现有MQ应用Eclipse工具命令行开放源码脚本编程J2EE应用外部业务单位图3.
如何使用IBMMQ移动整个企业内部和外部的文件.
12IBMSoftwareWebSphere技术白皮书十多年以来,IBM一直是AIM市场的领导者,同时也是业务流程管理套件(BPMS)、企业服务总线(ESB)(包括AIM设备)、独立B2B网关软件、面向消息的中间件(MOM)和事务处理监视器(TPM)领域的市场领导者.
1通过提供在IBMMQ上运行的ManagedFileTransfer功能,无论应用消息或文件是否被打包为消息,均可利用作为IBMMQ的一部分的单一控制仪表盘对您的消息流量进行跟踪,直至完成.
该方法可以为用户(尤其是管理员)带来实际的好处.
这些用户可直观地查看哪些消息正在其企业内移动,其内容是文件还是应用消息.
此外,他们还可以使用同样的方式处理和管理所有类型的文件和消息.
保护IBMMQ和信息内容无论是完全在企业内运行还是连接至广阔的互联网,如今所有系统都需要予以保护.
企业消息传递系统的很多方面都需要予以保护.
鉴于IBMMQ可移动不同系统内的大量关键业务数据,IBMMQ本身必须确保安全,而且经验证可连接至系统,确保非授权用户无法访问或改变配置.
此外,必须确保IBMMQ上的消息流的安全性.
IBMMQ具有很多安全特征.
利用IBMMQ的系统之间的连接更为安全,因为您可以利用SSL和其他连接安全性.
这有助于确保在网络上流动的IBMMQ消息是安全的.
不过,借助消息队列方法,可在消息流经网络时将消息写入至队列管理器中的队列,进而实现持久性.
如果消息内容未加密,那么可将消息写入至MQ队列管理器中的磁盘,这意味着该消息不再由SSL加密.
很明显,若要发送加密的消息内容,可通过改写应用的方式来实现,但在某些情况下,应用是无法更改的.
IBMMQ还具有一个额外的组件,该组件通过IBMMQAdvanced软件包系统,而且受权限的限制,能够在整个流程中对消息内容进行加密,即使该消息始终在队列内,也可进行加密.
无需改变任何一端的应用,否则将对每个应用上的消息内容进行加密.
借助IBMMQV8,您可以利用为运行IBMMQ的OS实例定义的身份进行认证.
这种新的认证功能有助于减少定义和删除用户的管理任务,尤其是对于多个系统而言更是如此.
现在,渠道认证记录(CHLAUTH)定义可用于域名系统(DNS)主机名而非IP地址.
借助这种增强功能,如果您以往已经使用了用户出口来支持该功能,则可以删除此类实例中的用户出口.
然而,IBMMQV8中的另一安全增强功能有助于对队列管理器进行更为灵活的安全配置.
现在,队列管理器具有多个证书,而且每个证书均由不同的证书认证机构签署.
借助这种增强功能,您可以利用单一队列管理器与不同合作伙伴沟通,而且每个合作伙伴仅需控制渠道定义即可使用不同的证书认证机构.
此外,几乎所有平台(包括IBMz/OS平台)现在均可支持SHA-2密码哈希功能.
这些功能有助于确保保护您的资产并符合监管要求.
此外,您还可利用更高的安全标准.
13IBMSoftwareWebSphere技术白皮书向客户传递消息,以便扩展整个基础架构内的访问和事务部署IBMMQ的企业领导者通常可利用IBMMQ安装并维护需要与采用客户端/服务器架构的IBMMQ连接在一起的系统代码.
服务器可作为队列管理器运行,而且所有队列均在服务器上.
IBMMQ客户端可能距离服务器较远,也可能与服务器位于同一位置.
将消息写入至服务器上的队列时即可实现消息持久性,因此根据所移动数据的性质,可通过基础架构部署客户端或服务器.
从客户端移动的部分数据可能需要成为事务工作单元的一部分.
因此,可通过IBMMQTransactionManager将客户端数据从客户端数据库等托管资源移动.
对于这种解决方案而言,可部署ExtendedTransactionalClient替代标准客户端.
该方法有助于与外部资源管理器进行协调,进而实现客户端连接,移动数据并以此作为事务工作单元的一部分,进而提供一流的数据移动和驱动业务保护.
将IBMMQ作为JMS提供程序如前所述,很多企业领导者可使用在应用服务器上运行Java编码的应用.
JMS是Java标准的一部分,可提供消息传递服务并以此作为编程模型的一部分.
因此,使用JMS是此类应用将数据移入/移出应用的一种自然的方式,而且很多应用服务器均利用JMS提供程序"聆听"JMS请求并执行该请求.
不过,这种方式只有在发送应用和接收应用在相同的JMS提供程序上运行的情况下才起作用.
尽管JMS是一种标准API,但有线格式并非标准格式,因此不同的JMS提供程序之间无法交换消息.
与其他消息传递提供程序相比,IBMMQ可以在更多环境下作为JMS提供程序,因此能够让Java编程人员在更多地方使用JMS.
编程人员可利用任何其他IBMMQ应用发送并接收消息,无论该使用是否使用JMS,也无论Java程序是否在相同的应用服务器上运行.
这将有助于确保编程人员获得消息传递方法的优势,而不会产生复杂的互操作性问题.
利用IBMMQ实现高可用性的自动故障转移保持生产环境的运行和互联对于很多企业而言都非常关键.
如果连接故障影响了正在进行的工作,那么连接故障与应用故障一样重要.
大部分硬件平台可提供某种形式的高可用性解决方案,但这种高可用性可能很难设置,而且其成本可能较高.
IBMMQ可支持这些硬件解决方案,而且还可提供对IBMMQ队列管理器进行自动故障转移的软件解决方案,并具备不依赖于硬件的高可用性.
如发生队列管理器故障,另一队列管理器实例无需人工干预即可接手故障系统的工作和事务.
连接实物资产和移动设备多年以来,很多企业一直专注于其内部IT基础架构,并以服务器和紧密相关的客户端为基础.
现在,他们对于将业务IT基础架构扩展至各种移动互联设备(通常为智能手机和平板电脑)的兴趣呈爆炸式增长.
此外,这些企业对于实物资产发送和接收的各种数据方面的机会的认识也在不断发展,这些实物资产可能是传感器、GPS定位器、电表、医疗设备或能够生成或使用数据的任何其他设备.
移动设备和实物资产往往在安装支持方面具有一定限制,而移动设备和实物资产还可在电力供应和网络连接带宽有限的环境下运营.
14IBMSoftwareWebSphere技术白皮书IBMMQ可支持能够连接至这些设备的解决方案:一种名为IBMMQTelemetryTransport的传输协议.
借助这种开放标准协议,可以编写出在占用资源极少的移动设备或远程物理设备上运行的轻量级客户端.
IBMMQTelemetryTransport协议旨在极低的带宽连接上运营,因此该协议非常简洁,并确保运行客户端或发送消息的设备的耗电量极小.
此外,该协议还有助于确保消息仅占用极少的传输字节,而且仅在需要时,才会变为活跃状态.
然后,可将使用IBMMQTelemetryTransport的应用连接至使用IBMMQTelemetry组件的IBMMQ队列管理器,该管理器包含在IBMMQAdvanced包中,但在使用时需要单独的授权.
通过使用该协议,企业可扩展应用,进而更好地了解企业数据中心外部正在发生的事情,并且更快地对已通过这些物理设备识别出的事件作出响应.
此外,新用户可通过移动设备互联在新的时间和地点发掘新业务机会、拓展现有业务机会,而且可通过移动业务访问创造新的机会,进而获取收入.
借助IBMMQTelemetry,您可以在Windows、Linux和IBMAIX平台上将IBMMQ连接至MQTelemetryTransport(MQTT)客户端.
在IBMMQV8发布之前,该功能可用于两种许可:标准许可和高级许可.
借助标准许可,您可以将IBMMQ服务器连接至MQTT客户端.
借助高级许可,您可以针对帮助MQTT消息缓冲并作为客户端集中器的设备,将IBMMQ服务器部署并连接至MQTelemetry后台程序.
借助IBMMQV8,这些功能适用于常规IBMMQTelemetry许可,提高部署选项的灵活性,同时不会增加许可成本.
无论您所购买的IBMMQAdvanced许可的数量为何,IBMMQAdvanced都包含在所有受支持的IBMMQ企业服务器上部署IBMMQTelemetry的部署许可.
利用IBMMQonIBMz/OS如今,对于很多企业而言,IT基础架构在整个企业范围内运用广泛,但关键业务应用仍旧会继续在主机上运行,尤其是运行IBMz/OS操作系统的IBMSystemz硬件更是如此.
毫无疑问,这些应用需要连接至业务的其他部分,而且无论是z/OS还是其他平台,IBMMQ均可提供此类功能.
不过,z/OS平台上的IBMMQ产品与其他平台上的IBMMQ产品之间存在较大差异.
问题的关键点在于,IBMMQonz/OS是专为z/OS而构建的产品.
这种设计一方面可确保IBMMQ能够高效运行,另一方面还可确保IBMMQ能够充分利用z/OS平台的很多关键原生功能.
近期发布的IBMMQonz/OS表明,中间件可在使用大型消息时高效利用耦合设施,而且在使用耦合设施时改善恢复性能.
此外,最新版IBMMQonz/OS可在30路IBMzEnterprisez196服务器上的单一队列管理器上扩展至一百万条消息/秒(2KB非共享).
315IBMSoftwareWebSphere技术白皮书借助IBMMQV8forz/OS,您可以利用队列管理器开发更大的存储,进而减少限于页面设置的私有队列访问.
可利用页面设置存储大部分消息和对象定义.
对于倾向于在批处理等队列中构建大量消息的配置和用例来说,该功能非常重要.
您可以定义64位存储中的缓冲池和其他缓冲池(最多100个缓冲池).
此外,还可对这些缓冲池进行定义,以便支持所存储的大量消息缓存(若需要).
如果使用这些具有固定页面的64位缓冲池,可提高IBMMQV8forz/OS的性能.
此外,还可改变IBMMQV8forz/OS以拓宽日志相关字节地址(RBA).
作出了这一改变之后,如果您具有较大持久消息工作量,则无需关闭队列管理器即可重新设置日志.
此外,您还可以延长正常运行时间并提高系统整体效率.