0
A17: Managing workloads, scaling 
and availability with IBM MQ clusters 
David Ware, IBM 
© 2014 IBM Corporation
© 2014 IBM Corporation 2 
Please Note 
IBM’s statements regarding its plans, directions, and intent are subject to change ...
© 2014 IBM Corporation 3 
Agenda 
 Why a cluster? 
 Starting to scale 
 Service availability 
 Routing around failures...
© 2014 IBM Corporation 6 
Why a Cluster? 
6
© 2014 IBM Corporation 7 
Where it all begins… 
Client 1 QMgr 
Service 1
QQMMggrr QQMMggrr 
Service 2 Service 1 
© 2014 IBM Corporation 9 
Over time… 
Client 1 
Service 1 
Client 2 
Client 2 
Cli...
© 2014 IBM Corporation 10 
Over time… 
App 1 
Service 1 
CAlpiepn 1t 1 
Client 2 
Client 2 
Client 3 
Service 2 
Service 1...
QMgr QMgr 
© 2014 IBM Corporation 11 
Until... 
App 1 
Service 1 
CAlpiepn 1t 1 
Client 2 
Client 2 
Client 3 
Service 2 
...
Zooming in on an application… 
QMgr QMgr 
© 2014 IBM Corporation 13 
Service 1 
ACAplpipep n1 1t 1 
Client 2 
Client 2 
Cl...
Starting to scale horizontally… 
QUEUE 1 
© 2014 IBM Corporation 14 
• Workload Balancing 
• Service Availability 
Service...
© 2014 IBM Corporation 16 
Availability
© 2014 IBM Corporation 17 
• Target queues 
• Transmission queues 
Service 1 
ACAplpipep n1 1t 1 
Service 1 
QMgr 
QMgr 
Q...
Service 1 
The service queue manager/host fails 
© 2014 IBM Corporation 18 
ACAplpipep n1 1t 1 
Service 1 
QMgr 
QMgr 
QMg...
Service application availability 
© 2014 IBM Corporation 20 
20
Unserviced messages 
Half the messages will quickly 
start to build up on the service 
queue 
QMgr 
QMgr 
Service 1 
Servi...
Service 1 
© 2014 IBM Corporation 22 
ACAplpipep n1 1t 1 
Service 1 
QMgr 
QMgr 
QMgr 
Monitoring for service failures
Service 1 
• WebSphere MQ provides a sample monitoring service 
• Regularly checks for attached consuming applications 
• ...
© 2014 IBM Corporation 26 
Client failures
• Multiple locations for a client to connect to 
Service 1 
•Allows new requests when one queue manager is unavailable. 
•...
Service 1 
© 2014 IBM Corporation 28 
ACAplpipep n1 1t 1 
Service 1 
Client host failure with an in flight request/respons...
Name resolution 
Outgoing request resolves the ReplyToQ 
to be ‘REPLYQ’ and ReplyToQMgr to be 
‘DUMMY’ Replying applicatio...
Location Dependency 
© 2014 IBM Corporation 31 
31
Service Service 
© 2014 IBM Corporation 32 
Global applications 
QMgr QMgr 
QMgr QMgr 
Service Service 
QMgr 
AAppCplipe n...
© 2014 IBM Corporation 34 
Setting this up
Service 
A A 
A 
© 2014 IBM Corporation 35 
One cluster 
QMgr 
QMgr 
AAppCplipe n 1t1 
New York 
London 
DEF QALIAS(AppQ) ...
Service Service 
QMgr QMgr 
QMgr QMgr 
Service Service 
The two cluster alternative 
© 2014 IBM Corporation 36 
QMgr 
AApp...
Avoiding interference 
© 2014 IBM Corporation 38 
38
© 2014 IBM Corporation 39 
AAppCplipe n 1t1 
SSeerrvvicicee 
AAppCplipe n 1t1 
SSeerrvvicicee 
AAppCplipe n 1t1 
SSeerrvvi...
© 2014 IBM Corporation 40 
The cluster as a pipe 
AAppCplipe n 1t1 
SSeerrvvicicee 
AAppCplipe n 1t1 
SSeerrvvicicee 
AApp...
Cluster 
Cluster 
© 2014 IBM Corporation 42 
The cluster as a pipe 
AAppCplipe n 1t1 
SSeerrvvicicee 
AAppCplipe n 1t1 
SS...
QQMMggrr 
QMgr 
Workload balancing level interference 
Service 1 
© 2014 IBM Corporation 44 
Client 1 
Service 1 
QMgr 
Se...
© 2014 IBM Corporation 45 
QMgr 
Cluster transmit queue 
 Separation of Message Traffic 
 With a single transmission que...
Multiple cluster transmit queues: Automatic 
 Configured on the sending queue manager, not the owners of the cluster rece...
 Still configured on the sending queue manager, not the owners of the cluster receiver 
Pink.B 
QMgr QMgr 
Pink.B 
Pink.A...
When things go wrong 
Disaster Recovery 
© 2014 IBM Corporation 48
Everything? 
Applications must be able to connect and target the exact same MQ resources. 
Every existing, in-flight, mess...
Datacenter 1 
© 2014 IBM Corporation 51 
Datacenter Replication 
‘in step’ 
Synchronous Replication 
1 
QMgr 
2 
QMgr 
DB ...
Datacenter 1 
1 
QMgr 
2 
QMgr 
1 2 
REFRESH 
REFRESH 
© 2014 IBM Corporation 53 
Datacenter Replication 
‘asynchronous’ 
...
Datacenter 1 
QMgr 
1 
QMgr 
3 
© 2014 IBM Corporation 55 
No Replication 
‘warm standby’ 
QMgr 
2 
Datacenter 2 
QMgr 
QM...
Live disk replication 
Restore nearly live 
backup 
Restore from stale 
backup 
Duplicated queue manager 
configuration 
H...
© 2014 IBM Corporation 58 
Summary 
 My first cluster 
 Service availability 
 Location dependency 
 Avoiding interfer...
© 2014 IBM Corporation 59 
Questions & Answers
IBM MQ Sessions this week 
10:30 - 12:00 13:15 - 14:15 14:30 - 15:30 16:00 - 17:00 17:15 - 18:15 
© 2014 IBM Corporation 6...
For Additional Information 
© 2014 IBM Corporation 61 
 IBM Training 
 http://www.ibm.com/training 
 IBM WebSphere 
 h...
Legal Disclaimer 
• © IBM Corporation 2014. All Rights Reserved. 
• The information contained in this publication is provi...
Upcoming SlideShare
Loading in...5
×

IBM WebSphere MQ: Managing Workloads, Scaling and Availability with MQ Clusters

2,744

Published on

IBM WebSphere MQ Clustering can be used to solve many problems, from simplified administration and workload management in an MQ network, to horizontal scalability and continuous availability of messaging applications. This session will show the full range of uses of MQ Clusters to solve real problems, highlighting the underlying technology being used.

This has been superseded by http://www.slideshare.net/DavidWare1/ame-2273-mq-clustering-pdf

Published in: Software, Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,744
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
270
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Transcript of "IBM WebSphere MQ: Managing Workloads, Scaling and Availability with MQ Clusters"

  1. 1. A17: Managing workloads, scaling and availability with IBM MQ clusters David Ware, IBM © 2014 IBM Corporation
  2. 2. © 2014 IBM Corporation 2 Please Note IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.
  3. 3. © 2014 IBM Corporation 3 Agenda  Why a cluster?  Starting to scale  Service availability  Routing around failures  Location dependency  Active active scenarios with ties to home  Avoiding interference  What are we sharing?  When things go wrong  Levels of DR and clustering implications
  4. 4. © 2014 IBM Corporation 6 Why a Cluster? 6
  5. 5. © 2014 IBM Corporation 7 Where it all begins… Client 1 QMgr Service 1
  6. 6. QQMMggrr QQMMggrr Service 2 Service 1 © 2014 IBM Corporation 9 Over time… Client 1 Service 1 Client 2 Client 2 Client 3 Service 3 CClileienntt 1 1
  7. 7. © 2014 IBM Corporation 10 Over time… App 1 Service 1 CAlpiepn 1t 1 Client 2 Client 2 Client 3 Service 2 Service 1 QMgr QMgr QMgr QMgr Client 3 Client 1 Client 4 ACAplpipep n4 4t 4 Service 4 Service 3 SSeerrvvicicee 1 1 Service 3
  8. 8. QMgr QMgr © 2014 IBM Corporation 11 Until... App 1 Service 1 CAlpiepn 1t 1 Client 2 Client 2 Client 3 Service 2 Service 1 QMgr QMgr QMgr QMgr Client 3 Client 1 Client 4 ACAplpipep n4 4t 4 Service 4 Service 3 SSeerrvvicicee 1 1 Service 3
  9. 9. Zooming in on an application… QMgr QMgr © 2014 IBM Corporation 13 Service 1 ACAplpipep n1 1t 1 Client 2 Client 2 Client 3 Service 2 Service 1 QMgr QMgr QMgr QMgr Client 3 Client 1 Client 4 ACAplpipep n4 4t 4 Service 4 Service 3 SSeerrvvicicee 1 1 Service 3
  10. 10. Starting to scale horizontally… QUEUE 1 © 2014 IBM Corporation 14 • Workload Balancing • Service Availability Service 1 ACAplpipep n1 1t 1 Service 1 QMgr QMgr QMgr QUEUE 1
  11. 11. © 2014 IBM Corporation 16 Availability
  12. 12. © 2014 IBM Corporation 17 • Target queues • Transmission queues Service 1 ACAplpipep n1 1t 1 Service 1 QMgr QMgr QMgr Where can the messages get stuck? Target queue Transmission queue
  13. 13. Service 1 The service queue manager/host fails © 2014 IBM Corporation 18 ACAplpipep n1 1t 1 Service 1 QMgr QMgr QMgr Message reallocation Unbound messages on the transmission queue can be diverted QMgr Locked messages Messages on the failed queue manager are locked until it is restarted Restart the queue manager Use multi-instance queue managers or HA clusters to automatically restart a queue manager Reconnect the service Make sure the service is restarted/reconnects to the restarted queue manager When a queue manager fails: • Ensure messages are not bound to it • Restart it to release queued messages
  14. 14. Service application availability © 2014 IBM Corporation 20 20
  15. 15. Unserviced messages Half the messages will quickly start to build up on the service queue QMgr QMgr Service 1 Service 1 The service application fails © 2014 IBM Corporation 21 QMgr Blissful ignorance This queue manager is unaware of the failure to one of the service instances ACAplpipep n1 1t 1 • Cluster workload balancing does not take into account the availability of receiving applications. • Or a build up of messages.
  16. 16. Service 1 © 2014 IBM Corporation 22 ACAplpipep n1 1t 1 Service 1 QMgr QMgr QMgr Monitoring for service failures
  17. 17. Service 1 • WebSphere MQ provides a sample monitoring service • Regularly checks for attached consuming applications • Updates the cluster workload balancing configuration to reflect this • So, what happens?... • Generally suited to steady state service applications © 2014 IBM Corporation 23 ACAplpipep n1 1t 1 Service 1 QMgr QMgr QMgr Monitoring for service failures QMgr QMgr Moving messages Any messages that slipped through will be transferred to an active instance of the queue Detecting a change When a change to the open handles is detected the cluster workload balancing state is modified Sending queue managers Newly sent messages will be sent to active instances of the queue
  18. 18. © 2014 IBM Corporation 26 Client failures
  19. 19. • Multiple locations for a client to connect to Service 1 •Allows new requests when one queue manager is unavailable. • What happens to replies after a failure? © 2014 IBM Corporation 27 ACAplpipep n1 1t 1 Service 1 Client availability QMgr QMgr QQMMggrr
  20. 20. Service 1 © 2014 IBM Corporation 28 ACAplpipep n1 1t 1 Service 1 Client host failure with an in flight request/response QMgr QMgr QMgr QMgr • Reply messages are bound to the originating queue manager, with no ability to redirect. • This may or may not be what’s required… Reply message bound The reply message will be locked to that outbound queue manager Request message Typically a request message will fill in the reply ReplyToQmgr based on the outbound queue manager
  21. 21. Name resolution Outgoing request resolves the ReplyToQ to be ‘REPLYQ’ and ReplyToQMgr to be ‘DUMMY’ Replying application Application replies to ‘REPLYQ’ on queue manager ‘DUMMY’ Service 1 DEF QREMOTE(DUMMY) RNAME(‘ ’) RQMNAME(‘ ’) Name resolution Target queue manager ‘DUMMY’ is resolved to ‘ ’, allowing cluster resolution to occur © 2014 IBM Corporation 29 DEF QLOCAL(REPLYQ) CLUSTER(CLUSTER1) DEF QREMOTE(REPLYQALIAS) RNAME(REPLYQ) RQMNAME(DUMMY) Requesting application Request message sets ReplyToQ to be ‘REPLYQALIAS’ and ReplyToQMgr to ‘ ’ ACAplpipep n1 1t 1 Service 1 Unlocking a response message QMgr QMgr QMgr QMgr DEF QLOCAL(REPLYQ) CLUSTER(CLUSTER1) DEF QREMOTE(REPLYQALIAS) RNAME(REPLYQ) RQMNAME(DUMMY) • Reply-to queue aliases and reply-to queue manager aliases can be used to blank out the outbound resolution of the ReplyToQMgr field. • But watch out, replies will now go to queue managers where the requestor may not be connected – this only suits some scenarios
  22. 22. Location Dependency © 2014 IBM Corporation 31 31
  23. 23. Service Service © 2014 IBM Corporation 32 Global applications QMgr QMgr QMgr QMgr Service Service QMgr AAppCplipe n 1t1 QMgr QMgr AAppCplipe n 1t1 QMgr New York London but separated by an ocean and 3500 miles • Prefer traffic to stay geographically local • Except when you have to look further afield • How do you do this with clusters that span geographies?…
  24. 24. © 2014 IBM Corporation 34 Setting this up
  25. 25. Service A A A © 2014 IBM Corporation 35 One cluster QMgr QMgr AAppCplipe n 1t1 New York London DEF QALIAS(AppQ) A LonQ • Clients always open AppQ • Local alias determines the preferred region • Cluster workload priority is used to target geographically local cluster aliases • Use of CLWLPRTY enables automatic failover •CLWLRANK can be used for manual failover Service AAppCplipe n 1t1 TARGET(NYQ) DEF QALIAS(NYQ) TARGET(ReqQ) CLUSTER(Global) CLWLPRTY(9) AppQ NYQ ReqQ QMgr AppQ A LonQ QMgr NYQ ReqQ A DEF QALIAS(AppQ) TARGET(LonQ) DEF QALIAS(LonQ) TARGET(ReqQ) CLUSTER(Global) CLWLPRTY(4) DEF QALIAS(LonQ) TARGET(ReqQ) CLUSTER(Global) CLWLPRTY(9) DEF QALIAS(NYQ) TARGET(ReqQ) CLUSTER(Global) CLWLPRTY(4)
  26. 26. Service Service QMgr QMgr QMgr QMgr Service Service The two cluster alternative © 2014 IBM Corporation 36 QMgr AAppCplipe n 1t1 QMgr QMgr AAppCplipe n 1t1 QMgr New York London USA QMgr QMgr QMgr QMgr EUROPE • The service queue managers join both geographical clusters •Each with separate cluster receivers for each cluster, at different cluster priorities. Queues are clustered in both clusters. • The client queue managers are in their local cluster only.
  27. 27. Avoiding interference © 2014 IBM Corporation 38 38
  28. 28. © 2014 IBM Corporation 39 AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 AAppCplipe n 1t1 SSeerrvvicicee Real time queries Big data transfer Audit events The cluster as a pipe • Often a WebSphere MQ backbone will be used for multiple types of traffic
  29. 29. © 2014 IBM Corporation 40 The cluster as a pipe AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 AAppCplipe n 1t1 SSeerrvvicicee QMgr QMgr QMgr QMgr QMgr QMgr Channels • Often a WebSphere MQ backbone will be used for multiple types of traffic • When using a single cluster and the same queue managers, messages all share the same channels • Even multiple cluster receiver channels in the same cluster will not separate out the different traffic types
  30. 30. Cluster Cluster © 2014 IBM Corporation 42 The cluster as a pipe AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 SSeerrvvicicee AAppCplipe n 1t1 AAppCplipe n 1t1 SSeerrvvicicee QMgr QMgr QMgr QMgr QMgr QMgr Cluster Channels Channels Channels • Often a WebSphere MQ backbone will be used for multiple types of traffic • When using a single cluster and the same queue managers, messages all share the same channels • Even multiple cluster receiver channels in the same cluster will not separate out the different traffic types • Multiple overlaid clusters with different channels enable separation
  31. 31. QQMMggrr QMgr Workload balancing level interference Service 1 © 2014 IBM Corporation 44 Client 1 Service 1 QMgr Service 2 Client 2  Cluster workload balancing is at the channel level.  Messages sharing the same channels, but to different target queues will be counted together.  The two channels here have an even 50/50 split of messages…  …but the two instances of Service 1 do not!  Split Service 1 and Service 2 queues out into separate clusters, queue managers or customise workload balancing logic. x75 x100 x50 x75 x25 x50  Multiple applications sharing the same queue managers and the same cluster channels. x75 x150
  32. 32. © 2014 IBM Corporation 45 QMgr Cluster transmit queue  Separation of Message Traffic  With a single transmission queue there is potential for pending messages for cluster ChannelA to interfere with messages pending for cluster ChannelB  Management of messages  Use of queue concepts such as MAXDEPTH not useful when using a single transmission queue for more than one channel.  Monitoring  Tracking the number of messages processed by a cluster channel currently difficult/impossible using queues.  Performance?  In reality a shared transmission queue is not always the bottleneck, often other solutions to improving channel throughput (e.g. multiple cluster receiver channels) are really what’s needed, but sometimes it will help.  A much requested feature…  Multiple cluster transmission queues QMgr QMgr QMgr QMgr V7.5 V8 Distributed z/OS & IBM i
  33. 33. Multiple cluster transmit queues: Automatic  Configured on the sending queue manager, not the owners of the cluster receiver SYSTEM.CLUSTER.TRANSMIT.ChlB SYSTEM.CLUSTER.TRANSMIT.ChlC ChlB © 2014 IBM Corporation 46 channel definitions.  Queue Manager switch to automatically create a dynamic transmission queue per cluster sender channel. ALTER QMGR DEFCLXQ( SCTQ | CHANNEL )  Dynamic queues based upon model queue. SYSTEM.CLUSTER.TRANSMIT.MODEL  Well known queue names. SYSTEM.CLUSTER.TRANSMIT.<CHANNEL-NAME> QMgr ChlB QMgr QMgr ChlA SYSTEM.CLUSTER.TRANSMIT.ChlA ChlA ChlC ChlC
  34. 34.  Still configured on the sending queue manager, not the owners of the cluster receiver Pink.B QMgr QMgr Pink.B Pink.A PINK.XMITQ © 2014 IBM Corporation 47 QMgr channel definitions.  Administratively define a transmission queue and configure which cluster sender channels will use this transmission queue. DEFINE QLOCAL(GREEN.XMITQ) CLCHNAME(GREEN.*) USAGE(XMITQ)  Set a channel name pattern in CLCHNAME  Single/multiple channels (wildcard) E.g. all channels for a specific cluster (assuming a suitable channel naming convention!)  Any cluster sender channel not covered by a manual transmission queue defaults to the DEFCLXQ behaviour Pink.A Green.A GREEN.XMITQ Green.A Multiple cluster transmit queues: Manual
  35. 35. When things go wrong Disaster Recovery © 2014 IBM Corporation 48
  36. 36. Everything? Applications must be able to connect and target the exact same MQ resources. Every existing, in-flight, message must be processed whilst in DR mode. New messages must be processed whilst in DR mode. © 2014 IBM Corporation 49 What do we need to recover? The MQ resources? Applications must be able to connect and target the exact same MQ resources. New messages must be processed whilst in DR mode. Application availability? Applications must be able to connect and target equivalent MQ resources. New messages must be processed whilst in DR mode.
  37. 37. Datacenter 1 © 2014 IBM Corporation 51 Datacenter Replication ‘in step’ Synchronous Replication 1 QMgr 2 QMgr DB DB Datacenter 2 QMgr QMgr QMgr DB DB QMgr QMgr QMgr QMgr  Outside the datacenter, DR queue managers must be locatable in either site  IP switching layer or comma separated channel names QMgr 1 2
  38. 38. Datacenter 1 1 QMgr 2 QMgr 1 2 REFRESH REFRESH © 2014 IBM Corporation 53 Datacenter Replication ‘asynchronous’ Asynchronous Replication/one-time copy Datacenter 2 QMgr QMgr QMgr QMgr QMgr QMgr  Backup queue managers contain historic messages (if any).  Cluster state will also be historic.  Refreshing cluster state on failover and failback is essential. – That’s why we moved the full repository QMgr QMgr
  39. 39. Datacenter 1 QMgr 1 QMgr 3 © 2014 IBM Corporation 55 No Replication ‘warm standby’ QMgr 2 Datacenter 2 QMgr QMgr QMgr QMgr QMgr  Backup queue managers are always running.  Cluster workload balancing used to direct traffic to live queue managers (CLWLPRTY/RANK)  Messages will be trapped on failed queue managers in the event of a failure. QMgr 4  Applications and system must be designed to accommodate this configuration (as we’ve discussed)
  40. 40. Live disk replication Restore nearly live backup Restore from stale backup Duplicated queue manager configuration How much do we need to recover? © 2014 IBM Corporation 57 Everything Live, cross center, WebSphere MQ clustering synchronous replication Asynchronous replication active/active COST MQ resources Application availability REFRESH
  41. 41. © 2014 IBM Corporation 58 Summary  My first cluster  Service availability  Location dependency  Avoiding interference  When things go wrong
  42. 42. © 2014 IBM Corporation 59 Questions & Answers
  43. 43. IBM MQ Sessions this week 10:30 - 12:00 13:15 - 14:15 14:30 - 15:30 16:00 - 17:00 17:15 - 18:15 © 2014 IBM Corporation 60 Tuesday Opening General Session- IBM Digital Experience and WebSphere Technical University Session A31: IBM MQ CHLAUTH rules – with MQ V8 updates Speaker: Morag Hughson Room 02 Session A4: WebSphere MQ for z/OS: Performance and Accounting Speaker: Alexander Ross Room 8 Session I26: DataPower- MQ Connectivity Deep Dive (Theory) Speaker: Robin Wiley Room 27 Session Z1: WebSphere MQ for z/OS V8: Latest Features Deep Dive Speaker: Damon Cross Room 6 9:00 - 10:00 10:30 - 11:30 11:45 - 12:45 14:00 - 15:00 15:15 - 16:15 16:45 - 17:45 Wednesday Session Z5: WebSphere MQ for z/OS: Security Speaker: Damon Cross Room 02 Session A21: What's New in IBM Messaging Speaker: Morag Hughson Room 8 Session C7: Messaging in the Cloud with IBM MQ Light and IBM Bluemix Speaker: Rob Nicholson Room 27 Session A17: Managing work-loads, scaling and availability with IBM MQ clusters Speaker: David Ware Room 6 Lab IL5: DataPower-MQ Connectivity Deep Dive (Hands-On) Speaker: Robin Wiley Room 7b Session A9: WebSphere MQ for z/OS: The Inside Story Speaker: Damon Cross Room 6 Thursday Session A35: How to Develop Responsive Applications with IBM MQ Light Speaker: Rob Nicholson Room 27 Session A22: New IBM MQ V8 Security Features Speaker: Morag Hughson Room 01 Session A3: WebSphere MQ for z/OS: Shared Queues Speaker: Alex Ross Room 6 Session A18: Using Publish /Subscribe with IBM MQ Speaker: David Ware Room 27 Friday Lab AL6: Developing a First Application with IBM WebSphere MQ Light Speakers: Robert Nicholson, Alex Ross Room 7b Session A16: Using IBM MQ Pub/Sub in an MQ network Speaker: David Ware Room 6
  44. 44. For Additional Information © 2014 IBM Corporation 61  IBM Training  http://www.ibm.com/training  IBM WebSphere  http://www.ibm.com/software/websphere/  http://www.ibm.com/software/products/ibm-mq  IBM developerWorks  http://www.ibm.com/developerworks/websphere  https://www.ibm.com/developerworks/community/blogs/messaging  WebSphere forums and community  http://www.ibm.com/developerworks/websphere/community/
  45. 45. Legal Disclaimer • © IBM Corporation 2014. All Rights Reserved. • The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. • References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. • All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. © 2014 IBM Corporation 62
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×