WM1011-VM1011INST

(1)

Technical Introduction to IBM

WebSphere MQ

(Course code WM101 / VM101)

Instructor Guide

ERC 1.0

WebSphere Education

cover

Front cover

(2)

November 2011 edition

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

© Copyright International Business Machines Corporation 2011.

This document may not be reproduced in whole or in part without the prior written permission of IBM.

Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Trademarks

IBM® is a registered trademark of International Business Machines Corporation.

The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both:

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®

Domino® Everyplace® IMS™

iSeries® Lotus® Maximo®

MVS™ OS/390® OS/400®

RACF® VTAM® WebSphere®

(3)

TOC

_Contents

Trademarks . . . vii

Instructor course overview. . . ix

Course description . . . xiii

Agenda . . . xv Unit 1. Introduction to WebSphere MQ. . . 1-1

Unit objectives . . . 1-2 The enterprise IT environment of today . . . 1-4 IBM WebSphere reference architecture . . . 1-6 Why are interfaces so expensive to build and maintain? . . . 1-9 Service-oriented architecture (SOA) . . . 1-11 Program-to-program communication . . . 1-13 Synchronous application design model . . . 1-16 Extended asynchronous application design model . . . 1-18 Time independence . . . 1-20 Three styles of communication . . . 1-22 WebSphere MQ eliminates application networking concerns . . . 1-25 Local and remote queues concept . . . 1-27 MQI calls . . . 1-30 Message composition . . . 1-33 Parallel processing application design . . . 1-35 Triggering . . . 1-37 Client/server application model . . . 1-40 WebSphere MQ client . . . 1-42 Data integrity . . . 1-44 Security . . . 1-47 Unit summary . . . 1-50 Checkpoint questions (1 of 2) . . . 1-53 Checkpoint answers (1 of 2) . . . 1-55 Checkpoint questions (2 of 2) . . . 1-57 Checkpoint answers (2 of 2) . . . 1-59

Unit 2. Programming with WebSphere MQ . . . 2-1

Unit objectives . . . 2-2 Programming with the MQI . . . 2-4 MQI actions . . . 2-6 MQI call notation . . . 2-9 MQCONN call . . . 2-11 MQCONNX call . . . 2-14 Remote queue manager . . . 2-17 MQOPEN call . . . 2-19

(4)

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

iv WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Queue definition and independence . . . .2-22 Model queue definition . . . .2-24 MQPUT call . . . .2-26 MQGET call . . . .2-29 MQGET get message options . . . .2-31 MQPUT1 call . . . .2-34 MQINQ call . . . .2-36 MQSET call . . . .2-39 Additional MQI calls . . . .2-41 Connecting to a queue manager with Java . . . .2-43 Accessing queues with Java . . . .2-45 The Java MQMessage object . . . .2-48 Putting messages on the queue with Java . . . .2-50 Getting messages from the queue with Java . . . .2-52 Introducing Java Message Service (JMS) . . . .2-55 JMS concept . . . .2-57 JMS APIs . . . .2-59 JMS components . . . .2-61 Relationship to other Java APIs . . . .2-63 WebSphere MQ APIs . . . .2-65 Unit summary . . . .2-67 Checkpoint questions . . . .2-69 Checkpoint answers . . . .2-71

Unit 3. Messages: additional information . . . .3-1

Unit objectives . . . .3-2 Some fields in the message descriptor . . . .3-3 Message persistence . . . .3-6 Retrieval in priority order . . . .3-8 Report field and report message type . . . .3-10 Expiry . . . .3-13 Message groups . . . .3-16 Message segmentation . . . .3-19 Distribution list . . . .3-21 Unit summary . . . .3-23 Checkpoint questions . . . .3-25 Checkpoint answers . . . .3-27 Unit 4. Intercommunication. . . .4-1 Unit objectives . . . .4-2 The message channel . . . .4-4 Types of channels . . . .4-7 Starting a channel . . . .4-10 Stopping a channel . . . .4-12 Remote queues . . . .4-14 Message concentration . . . .4-17 Message segregation . . . .4-19 Multiple hops . . . .4-21

(5)

TOC Channel exits . . . 4-23

Application data conversion . . . 4-26 Channel attributes example . . . 4-28 Queue manager clusters . . . 4-31 Cluster workload management . . . 4-33 Shared queues Sysplex support . . . 4-35 MQI client channels . . . 4-38 Unit summary . . . 4-40 Checkpoint questions . . . 4-42 Checkpoint answers (1 of 2) . . . 4-45 Checkpoint answers (2 of 2) . . . 4-47

Unit 5. System administration . . . 5-1

Unit objectives . . . 5-2 Introduction . . . 5-4 Installation . . . 5-6 Administrative tasks . . . 5-8 WebSphere MQ administrative interfaces . . . 5-10 WebSphere MQ Explorer . . . 5-15 WebSphere MQ Explorer: Queue Manager view . . . 5-17 WebSphere MQ Explorer: Queues view . . . 5-19 WebSphere MQ Explorer: Queue selected . . . 5-21 WebSphere MQ Explorer: Compare . . . 5-23 WebSphere MQ Explorer: Filtering . . . 5-25 WebSphere MQ Explorer: Filter results . . . 5-27 Queue storage management on z/OS . . . 5-29 Queue sharing on z/OS . . . 5-31 Log and bootstrap data sets on z/OS . . . 5-33 Journaling and recovery (iSeries) . . . 5-36 Logging and recovery: UNIX and Windows . . . 5-39 Unit summary . . . 5-41 Checkpoint questions . . . 5-43 Checkpoint answers (1 of 2) . . . 5-45 Checkpoint answers (2 of 2) . . . 5-47

Unit 6. Transactional support . . . 6-1

Unit objectives . . . 6-2 Unit of work . . . 6-4 Resource manager . . . 6-6 Transaction manager . . . 6-8 MQGET within sync point control . . . 6-11 MQPUT within sync point control . . . 6-13 Coordinating local units of work . . . 6-15 Internal coordination of global units of work . . . 6-17 Database coordination . . . 6-19 WebSphere MQ for z/OS RRS support . . . 6-22 Unit summary . . . 6-24 Checkpoint questions . . . 6-26

(6)

vi WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Checkpoint answers . . . .6-28

Unit 7. Security. . . .7-1

Unit objectives . . . .7-2 IBM security architecture . . . .7-4 Security implementation . . . .7-7 Security in WebSphere MQ . . . .7-9 Resource access security . . . .7-12 Command security . . . .7-14 Message context . . . .7-16 User IDs . . . .7-18 Passing context information . . . .7-20 WebSphere MQ channel security . . . .7-22 Secure Sockets Layer (SSL) . . . .7-24 Management and audit tasks . . . .7-26 Using user ID context and alternate user ID . . . .7-28 Using channel message exit . . . .7-30 Unit summary . . . .7-32 Checkpoint questions . . . .7-34 Checkpoint answers (1 of 2) . . . .7-36 Checkpoint answers (2 of 2) . . . .7-38

Unit 8. Linking, bridging, and the WebSphere MQ family . . . .8-1

Unit objectives . . . .8-2 The IMS bridge . . . .8-4 The CICS DPL bridge . . . .8-6 The CICS 3270 bridge . . . .8-8 The link for SAP R/3 . . . .8-10 WebSphere MQ Everyplace . . . .8-12 Publish/subscribe examples . . . .8-14 WebSphere MQ publish/subscribe . . . .8-16 WebSphere Business Integration Adapters . . . .8-18 WebSphere Message Broker . . . .8-21 Unit summary . . . .8-24 Checkpoint questions . . . .8-26 Checkpoint answers . . . .8-28

Unit 9. Course summary . . . .9-1

Unit objectives . . . .9-2 Course learning objectives . . . .9-4 Class evaluation . . . .9-6 To learn more on this subject . . . .9-8 References . . . .9-10 Unit summary . . . .9-12

(7)

TMK

_Trademarks

The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies:

IBM® is a registered trademark of International Business Machines Corporation.

The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both:

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Other product and service names might be trademarks of IBM or other companies.

AIX® CICS® DB2®

Domino® Everyplace® IMS™

iSeries® Lotus® Maximo®

MVS™ OS/390® OS/400®

RACF® VTAM® WebSphere®

(8)

(9)

TMK

_{Instructor course overview}

This 1-day instructor-led course is a technical overview of IBM

WebSphere MQ. It provides a conceptual understanding of messaging and queuing as implemented by IBM WebSphere MQ.

IBM WebSphere MQ delivers reliable application integration for

applications and web services, allowing users to fully leverage existing software and hardware investments. Through a series of lectures, students learn how IBM WebSphere MQ provides a messaging backbone for deploying an enterprise service bus (ESB) as the

connectivity layer of a service-oriented architecture (SOA). The course also explains how IBM WebSphere MQ responsibilities can include the management of topic-based publish/subscription information.

There are no lab exercises in this course; students confirm their learning through checkpoint questions.

After completing this course, students should be able to: • Compare IBM WebSphere MQ with other forms of

program-to-program communication

• Identify the impact WebSphere MQ can have on application design • Describe the basic components and structure of IBM WebSphere

MQ

• Describe the function of each of the calls in the Message Queue Interface

• Describe the tasks that must be performed to manage a queue manager and its connections with:

- Other queue managers

- WebSphere MQ client applications

• Describe the transactional support within the IBM WebSphere MQ product

• Describe the features of IBM WebSphere MQ that contribute to system security

• Explain how IBM WebSphere MQ can be used as part of the communications infrastructure to:

- Connect application environments, such as the World Wide Web, enterprise transaction systems, and database systems - Manage the dissemination of publisher information to

(10)

x WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Course strategy

Teaching strategy

Each classroom session uses a combination of facilitated lecture, discussions to convey the material.

Introduce the material

Inform the students of the objectives of the unit and topic. Give them a brief scenario that will help them understand how the presented material will assist them in performing their jobs.

Facilitate the learning experience

Involve the students in the learning process. Ask them questions and present classroom scenarios in which students use the available resources to solve situations involving process, procedure, or content on the job.

Review the material

Review objectives at the conclusion of each unit to ensure that the students have a thorough understanding of the material.

Course evaluation

Evaluation measures the quality, effectiveness, and impact of the course. It enables students to answer the question, "Are the requirements and objectives of the course being met?"

For all classes, students will provide feedback on course quality by completing an end-of-course questionnaire.

Measurement plan

There are no formal tests administered in the class. Course materials

• Student Notebook • Instructor Guide

• PowerPoint visuals in PDF form to be displayed

Summary of changes

November 2011 edition — WM101/VM101, ERC 1.0

This course is an update from the previous version course WM100, which was written for V7.0.

(11)

TMK • Updated for WebSphere MQ V7.1

• Updated for current WebSphere Education course standards

April 2008 edition — WM100/VM100, ERC 1.0

This course is an update from the previous version course WM010, which was written for V6.

• Course base content taken from WM010/VM010 • Updated for WebSphere MQ V7

• Additional detail on the IBM WebSphere MQ publish/subscribe • Changed all OS/390 references to zSeries

• Updated course for new IBM WebSphere MQ new publisher/subscribe API • Publication/subscription added to Unit 8

(12)

(13)

TMK

_{Course description}

Technical Introduction to WebSphere MQ

Duration: 1 day

Purpose

This 1-day instructor-led course is a technical overview of IBM

WebSphere MQ. It provides a conceptual understanding of messaging and queuing as implemented by IBM WebSphere MQ.

IBM WebSphere MQ delivers reliable application integration for

applications and web services, allowing users to fully leverage existing software and hardware investments. Through a series of lectures, students learn how IBM WebSphere MQ provides a messaging backbone for deploying an enterprise service bus (ESB) as the

connectivity layer of a service-oriented architecture (SOA). The course also explains how IBM WebSphere MQ responsibilities can include the management of topic-based publish/subscription information.

There are no lab exercises in this course; students confirm their learning through checkpoint questions.

Audience

This basic course is designed for system administrators, application developers, and technical sales and marketing professionals.

Prerequisites

Before taking this course, students should have experience working with software. Skills and experience in one or more of the following specific areas enable students to derive more benefit from the course: • Communications and networking

• System and network management • System design

• Application development • Transaction processing • Database management • Client/server solutions

• Platform knowledge (IBM and non-IBM) • Open systems

(14)

xiv WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Objectives

After completing this course, students should be able to: • Compare IBM WebSphere MQ with other forms of

program-to-program communication

• Identify the impact WebSphere MQ can have on application design • Describe the basic components and structure of IBM WebSphere

MQ

• Describe the function of each of the calls in the Message Queue Interface

• Describe the tasks that must be performed to manage a queue manager and its connections with:

- Other queue managers

- WebSphere MQ client applications

• Describe the transactional support within the IBM WebSphere MQ product

• Describe the features of IBM WebSphere MQ that contribute to system security

• Explain how IBM WebSphere MQ can be used as part of the communications infrastructure to:

- Connect application environments, such as the World Wide Web, enterprise transaction systems, and database systems - Manage the dissemination of publisher information to

(15)

TMK

_Agenda

Day 1

(00:30) Course introduction

(00:30) Unit 1 - Introduction to WebSphere MQ (00:30) Unit 2 - Programming with WebSphere MQ (00:30) Unit 3 - Messages: Additional information (00:30) Unit 4 - Intercommunication

(00:30) Unit 5 - System administration (00:30) Unit 6 - Transactional support (00:30) Unit 7 - Security

(00:30) Unit 8 - Linking, bridging, and the WebSphere MQ family (00:15) Unit 9 - Course summary

(16)

(17)

Uempty

_{Unit 1. Introduction to WebSphere MQ}

Estimated time

00:30

What this unit is about

This unit provides an overview of IBM WebSphere MQ. It introduces the business requirements that led to the development of IBM WebSphere MQ, positions it against other forms of

program-to-program communication, and discusses the function it provides for building business application solutions.

What you should be able to do

After completing this unit, you should be able to:

• Explain the positioning of messaging and queuing in the current business environment

• Provide a high-level view of WebSphere MQ functions

• Describe the breadth of coverage of WebSphere MQ products

How you will check your progress

Accountability:

• Checkpoint questions

References

www.ibm.com/software/integration/wmq

IBM WebSphere MQ home page

www.ibm.com/software/integration/wmq/library

IBM WebSphere MQ Library

www.ibm.com/software/integration/wmq/quicktour

(18)

1-2 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Figure 1-1. Unit objectives WM101 / VM1011.0

Notes:

The intent of this course is to provide an introductory technical overview of IBM WebSphere MQ. The topics covered help you gain a solid foundation so you can begin building

WebSphere MQ skills.

The purpose of this unit is to identify and help you understand the types of business requirements solved by WebSphere MQ, and to introduce how WebSphere MQ meets those requirements.

Unit objectives

After completing this unit, you should be able to:

• Explain the positioning of messaging and queuing in the current

business environment

• Provide a high-level view of WebSphere MQ functions

(19)

Uempty

Instructor notes:

Purpose — Highlight the unit objectives.

Details — This unit introduces WebSphere MQ.

• You look at some examples of the types of environments that can use WebSphere MQ for complete solutions.

• You compare WebSphere MQ V7.1 to other communication models. • You list the major strengths of the WebSphere MQ asynchronous model. • You see the Message Queue Interface (MQI).

• You examine the contents of an WebSphere MQ message, as well as how it is delivered to applications.

Additional information —

Transition statement — Look at a business view of integration: the current IT environment.

(20)

Figure 1-2. The enterprise IT environment of today WM101 / VM1011.0

Notes:

Perhaps the biggest challenge is that current IT environments are becoming increasingly diverse. As the focus on integration increases, it moves horizontally, and extends beyond the boundaries of the individual enterprise to include partners, suppliers, and customers. It is this diversity in IT environments that increases the complexity of the challenges that a company like yours must handle.

Middleware is the infrastructure software that simplifies the problem of horizontal

integration. The infrastructure has to integrate people, data, and applications across and beyond the enterprise to provide benefits throughout the value chain. Infrastructure

middleware provides the operational resilience that is essential for making the technology transitions that allow your business to react quickly to necessary business changes, and to adapt dynamically.

The enterprise IT environment of today

IT environments are increasingly heterogeneous and complex

The role of modern middleware is to integrate and simplify

Transactions

Legacy systems and applications Networks Databases Intranets Value chain extranets Internet Customers

(21)

Uempty

Instructor notes:

Purpose — Describe the role of middleware. Details —

Transition statement — Look at a business view of integration: the IBM WebSphere reference architecture.

(22)

Figure 1-3. IBM WebSphere reference architecture WM101 / VM1011.0

Notes:

The WebSphere platform provides the software foundation for On Demand Business. WebSphere MQ started as a transactional application server, and has grown with customer needs. It provides software products delivering a breadth of business integration. While it emphasizes the value of the entire platform, IBM also allows the customer to start simply, using just the functionality required at the time, and then to progressively add function as needed. The IBM middleware platform is implemented as a service-oriented architecture (SOA), which IBM calls the IBM WebSphere Integration Reference Architecture.

IBM WebSphere reference architecture

Business services WebSphere Business Monitor

Infrastructure services Development services WebSphere Business Integration Modeler, WebSphere Integration Developer Management services Interaction services WebSphere Portal Server Process services WebSphere Process Server Information services WebSphere Information Integrator Partner services WebSphere Partner Gateway Business application services WebSphere Application Server Access services WBI and WebSphere Adapters, HATS Connectivity services, ESB

WebSphere MQ

WebSphere Enterprise Service Bus, WebSphere Message Broker

(23)

Uempty

Instructor notes:

Purpose — Outline WebSphere Business Integration Reference Architecture. Indicate how the layers are complementary. Different solutions may use subsets of the architecture functions; but the most value, that is, what is required for e-business on demand, is

obtained when all the function of the architecture is leveraged and used.

Details — Begin at the bottom of the chart and work your way up the stack. Integration solutions typically begin with the fundamental need to interconnect multiple applications. Integration solutions can include prepackaged applications, like SAP, PeopleSoft, or Siebel. Integration solutions often include applications that were built years ago with no requirement or design considerations for interconnecting and interacting with other

applications or components in a distributed system. There are three basic layers within the architecture.

• Application connectivity provides integration middleware that allows information to flow between the applications in a way that abstracts the details of the information flow from the applications themselves. This layer provides:

- Connectivity management to attach applications to a transport, isolating the details of the connection from the internals of the application. Connectivity management is provided through adapters.

- Information delivery management to determine the appropriate destination for the information flow and ensure that it is in the form required by the destination. It centralizes the logic so that it is not repeated in each of the interconnected applications.

• Process integration provides integration middleware that manages the execution of functions across heterogeneous, connected applications in a way that abstracts the details of the flow of activity from the applications themselves. This layer provides functions that:

- Catch and handle application events that need to be propagated to other applications.

- Control the flow of actions required among the interconnected applications. - Allow the interaction of people and applications.

- Provide control and state management required for long-running processes.

• Modeling and monitoring provide for the creation of runtime assets that implement a business process. Graphical tools are used view, collect, and analyze data from the runtime system to upgrade the processes, effectively providing the necessary tools for continuous process improvement. This layer provides the functions required for:

- Efficient implementation of business processes.

- Analyzing and assessing process efficiency and effectiveness.

(24)

1-8 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011 When appropriate, these layers can be extended to users through the functions and capabilities of WebSphere Portal technologies. The users may be employees or may access the system from outside the enterprise; for example, they may be customers, partners, or suppliers.

Also, when it is necessary to integrate third-party systems, the layers can be extended again, using the capabilities of the WebSphere Business Connect technologies.

Additional information — Transition statement —

(25)

Uempty

Figure 1-4. Why are interfaces so expensive to build and maintain? WM101 / VM1011.0

Notes:

Why are interfaces so expensive to build and maintain?

There are several reasons. Application interface logic is typically intertwined within

application business logic to the nature of the applications themselves. The programming models do not enable the separation of interface logic from the applications themselves. The more tightly integrated the interface, the more difficult the application is to change. The more interfaces within a program, the more complex the application becomes. Over time, and with enough separate connections, the interface logic can, in fact, exceed the business logic. In such circumstances, reuse becomes difficult and impractical.

SOA is the methodology and architecture for solving this problem.

Why are interfaces so expensive to build and maintain?

• Application interface logic is intertwined with business logic

• Tightly integrated interfaces are difficult to change

• The more interfaces, the more complex the application — interface

logic may exceed business logic.

(26)

1-10 WebSphere MQ Technical Introduction © Copyright IBM Corp. 2011

Instructor notes:

Purpose — To show the problems with interfaces. Details —

(27)

Uempty

Figure 1-5. Service-oriented architecture (SOA) WM101 / VM1011.0

Notes:

SOA is not a new concept. It is the next step of a connectivity evolution, and indeed, much of the problem has already been solved with existing technologies that you may be using today.

The objective of SOA is to reduce the service down to the bare business logic.

Service-oriented architecture (SOA)

Message queuing Abstracts connectivity logic from application Traditional message brokering Abstracts connectivity and mediation logic from application Message and service brokering Reduces application to core business functions

(that is, a service) Application Application Connectivity, mediation, and additional logic Direct connectivity Connectivity, mediation, and additional logic buried in application Application Connectivity logic SERVICES Connectivity, mediation, and additional logic Mediation and additional logic Additional logic Connectivity and mediation logic

Degree of flexibility and reuse Lines

of code

(28)

Instructor notes:

Purpose — To introduce SOA.

Details — The concept of message queuing is a powerful one that you may be using if you use IBM products like IBM WebSphere MQ. IBM WebSphere MQ decouples applications by abstracting connections through the use of queues. Instead of the application talking directly to another application, it talks to an intermediate queue that can then be directed to any application. Message queuing also eliminates the need for the application to deal with the intricacies of different platforms or the worry about whether the other application is busy or even online. It also takes care to ensure that message delivery is assured and not duplicated. All of this capability strips out interface code from your application. However, message queuing itself does nothing to help deliver information in the right format. Nor does it help you direct information to different targets based on the message content. You still have to build all of this interface logic directly into your application interfaces. To

eliminate this second level of interface logic, you need a different type of intermediary — a traditional broker. Brokers enable you to remove the transformation and routing logic from the application interfaces. Brokers can also augment content and reroute based on

message content. They can also translate between different protocols and programming models.

(29)

Uempty

Figure 1-6. Program-to-program communication WM101 / VM1011.0

Notes:

WebSphere MQ is a means of program-to-program communication.

The figure depicts the basic mechanism by which this communication takes place. Program A prepares a message and puts it on a queue. Program B then gets the message from a queue and processes it.

Both Program A and Program B use an application programming interface (API) to put messages on a queue and get messages from a queue. The WebSphere MQ API is called the message queue interface (MQI).

When Program A puts a message on the queue, Program B might not be running. The queue stores the message safely until Program B starts and is ready to get the message. Likewise, at the time when Program B gets the message from the queue, Program A might no longer be running. With WebSphere MQ, there is no requirement for two programs communicating with each other to be running at the same time.

Program-to-program communication

B A

Queue

(30)

WebSphere MQ provides several functions that are mandatory for successful message transport:

• Assured delivery • Once-only delivery • Asynchronous delivery

(31)

Uempty

Instructor notes:

Purpose — To explain the way in which program-to-program communication works using IBM WebSphere MQ.

Details — The main point is to make sure that everyone is comfortable with the high-level idea of using messaging and queuing for program-to-program communication. It may help to have them think of the queue pictures as a logical queue. As you go, you are introduced to the physical objects that make up the logical queue. It is also suggested that you may consider the queue as a replacement for an intermediate file, making sure that you point out that queues have certain advantages, which are covered as you progress.

Be sure to explain the three mandatory messaging functions that WebSphere MQ provides, namely:

• Assured delivery: a message is always delivered successfully, if the proper options are used.

• One-time delivery: a message is always delivered exactly one time, with no duplication, if the proper options are used.

• Asynchronous delivery: a message is always delivered even if the sending and receiving applications are not online at the same time.

Transition statement — What happens if Program B needs to send a message to Program A — perhaps a reply?

(32)

Figure 1-7. Synchronous application design model WM101 / VM1011.0

Notes:

The figure shows how Program B can send a message to Program A using the same mechanism. The message might be a reply to a message it received from Program A. Typically, Program B uses a different queue to send messages to Program A. Using a separate queue is not strictly necessary, but doing so leads to a simpler application design and simpler programming logic.

If Program A sends a message to Program B and expects a reply, one option is for

Program A to put a message on Queue 1. It then waits for the reply to appear on Queue 2. This communication model is called the synchronous model for two-way communication between programs.

Using the synchronous model, Program A and Program B would normally be running at the same time. However, if Program B fails, Program A might potentially have to wait a long time for a reply. How long Program A waits before continuing with other processing is a design issue.

Synchronous application design model

B A

Queue 1

(33)

Uempty

Instructor notes:

Purpose — To explain the synchronous model for two-way communication between programs.

Details — Point out that in the synchronous model is the inherent dependency that Program A and Program B must be available at the same time.

(34)

Figure 1-8. Extended asynchronous application design model WM101 / VM1011.0

Notes:

Using the extended asynchronous model, Program A puts messages on Queue 1 for Program B to process, but Program C, acting asynchronously to Program A, receives replies from Queue 2 and processes them. Typically, Program A and Program C would be part of the same application.

The asynchronous model is a natural model for IBM WebSphere MQ. Program A can continue to put messages on Queue 1 and is not blocked by having to wait for a reply to each message. It can continue to put messages on Queue 1 even if Program B fails. In that case, Queue 1 stores the messages safely until Program B is restarted.

In a variation of the asynchronous model, Program A could put a sequence of messages on Queue 1, optionally continue with other processing, and then return to get and process the replies from Queue 2.

Extended asynchronous application design model

B A

C

Queue 1

(35)

Uempty

Instructor notes:

Purpose — To explain the asynchronous model for two-way communication between programs.

Details — Now point out that the dependency shown in the previous visual has been removed.

Transition statement — You saw that Program A can continue to put messages on Queue 1 even if Program B fails.

(36)

Figure 1-9. Time independence WM101 / VM1011.0

Notes:

This figure demonstrates that Program A puts messages on the queue and Program B gets them when it is ready. If Program B is busy or is not available, the messages are stored safely in the queue until it is ready to get them.

If Program A has completed its processing when B becomes ready, or if Program A has failed, it does not matter. Program B can still get the messages and process them. Indeed, there may be times when neither program is available, but any outstanding messages are still stored safely in the queue.

This property of WebSphere MQ, in which communicating applications do not have to be active at the same time, is known as time independence.

Time independence

B A B A B A B A Not available Not available Not available Not available

(37)

Uempty

Instructor notes:

Purpose — To highlight the time-independence property of WebSphere MQ.

Details — A concept to get across here is that everything is conditional. There are no hard requirements for a program to be available to get messages at the same time; another program is sending them.

Transition statement — Now compare WebSphere MQ with the other styles of program-to-program communication.

(38)

Figure 1-10. Three styles of communication WM101 / VM1011.0

Notes:

Conversational or transaction-oriented communication is characterized by two or more programs executing simultaneously in a cooperative manner in order to perform a

transaction. They communicate with each other through a designed interface. While one program is waiting for a reply from another program with which it is cooperating, it can continue with other processing. APPC, CPI-C, and the socket interface to TCP/IP are examples of this style of communication.

The call-and-return style is similar, but when one program calls another program, the first program is blocked and cannot perform any other processing until the second program returns control to it. Remote procedure call (RPC) is an example of this style of

communication.

Three styles of communication

Conversational A _B A B Messaging Call-and-return A Call B B Return to A

(39)

Uempty In the messaging style, communicating programs can run independently of each other. A

running program receives input in the form of messages and also outputs its results as messages. A message that is the output from one program becomes the input to another program, but there is no requirement that the latter must be running when the former outputs the message. Contrast this style with the conversational and call-and-return styles where all cooperating partners must be running at the same time. WebSphere MQ uses this messaging style.

(40)

Instructor notes:

Purpose — To clarify the differences between the two synchronous styles of

program-to-program communication and the asynchronous style that can be used with IBM WebSphere MQ.

Details — Thoroughly explain the three styles to students.

Examples of the conversational style are APPC, CPI-C, and the socket interface to TCP/IP. Using CPI-C, for example, the complexities of the network are fairly well-hidden, but not totally. Some, at least, of the LU6.2 conversation is exposed to the application programmer. When a program sends some data to another program and expects a reply, it may carry on with other processing for a while. However, it eventually must issue a communication receive, which may cause it to wait in a blocked state until the reply arrives. The implication is that the partner program is present and running. It is similar to a telephone conversation; both ends must be there and the line must be working for anything useful to happen. The call-and-return style is similar. However, in implementation, it requires a more

substantial piece of code to be linked to each program. This stub, as it is called, transfers control and parameters across the network, normally over TCP/IP. Both the calling and the called program work in a synchronous manner, and both partners must be executing at the same time.

The messaging style is the one used by WebSphere MQ. A program communicates with another program simply by sending it a message, but there is no requirement for the two programs to be active at the same time.

Transition statement — Next, you look at the networking requirements of WebSphere MQ compared to the requirements of the conversational style of program-to-program communication.

(41)

Uempty

Figure 1-11. WebSphere MQ eliminates application networking concerns WM101 / VM1011.0

Notes:

The conversational style of program-to-program communication relies on a

communications connection existing across a network for each pair of applications. In reality, a communications connection manifests itself as a TCP connection, an SNA LU6.2 (system network architecture logical unit) conversation, a NetBIOS session, and so on. In WebSphere MQ, an application sends a message to another application by using the Message Queue Interface (MQI) functions provided by the queue manager to which it is connected. Therefore, the required communications connection is between a pair of message channel agents (MCAs), each connected to its respective queue manager, not between a pair of applications.

The Message Queue Interface shields applications and their developers from the

complexities of the network. The message channel agents supplied with WebSphere MQ contain all the communications programming that is necessary.

WebSphere MQ eliminates application network concerns

Applications Applications Network Networking interface Applications MQI Queue manager Applications MQI Queue manager Networking interface Networking interface MCA MCA

(42)

Instructor notes:

Purpose — To compare the networking requirements of WebSphere MQ and the conversational style of program-to-program communication.

Details — The conversational style of program-to-program communication requires that a communications connection exist between each pair of communicating applications. In WebSphere MQ, it is the MCAs that are responsible for moving messages from one queue manager to another, so it is only each pair of MCAs that requires a communications connection. In this way, one communications connection can support multiple applications connected to one queue manager, sending messages to multiple applications connected to another queue manager.

Additional information — Keep the discussion at this level for now. Intercommunication has a full unit later on.

Transition statement — So far, it may seem as if everything is happening on one system. Often this requirement is true, but WebSphere MQ is able to connect applications over a network.

(43)

Uempty

Figure 1-12. Local and remote queues concept WM101 / VM1011.0

Notes:

When an application opens a queue, the queue manager determines the ultimate destination queue owner. If the queue is owned by the queue manager to which the application is connected, it is a local queue. If the queue is owned by another queue manager, it is a remote queue.

When the application puts a message on a queue that is local, the queue manager places the message directly on that queue. However, if the queue is remote, the queue manager places the message on a special local queue called a transmission queue.

A message channel agent is a component of WebSphere MQ. It is the task of the MCA to get the message from the transmission queue and send it over the network to the MCA at the receiving end. The receiving MCA then puts the message on the destination queue. Once the message has been safely committed on the destination queue, it is removed from the transmission queue.

Local and remote queues concept

Program B Program A Program C QM2: Local queue, transmit queue Q1: Local queue Queue manager QM1 Queue manager QM2 Q2: Local queue System 1 System 2 MQPUT Q2, QM2

MQPUT Q1 _{MQGET Q1} _{MQGET Q2}

MQI

Dead letter queue

(44)

If the receiving MCA cannot put the message on the destination queue, the message is placed in the dead letter queue associated with that queue manager, or it can also be discarded, depending on the options specified by the sending application in the message descriptor.

(45)

Uempty

Instructor notes:

Purpose — Explain how a message is delivered safely to a remote destination queue. Details — Walk the students through what happens when Program A puts a message on local queue Q1. This process is easy because the queue manager to which Program A is connected owns Q1, and therefore knows where it is.

However, when Program A puts a message on remote queue Q2, the queue manager to which Program A is connected needs to know which queue manager owns Q2. It also needs to know where that queue manager is located in the network. This process is done in various ways, which you discuss later. Do not be tempted to discuss these ways now. Assuming the queue manager knows this information, the message can be forwarded to that queue manager and put on the destination queue.

However, the delivery of a message to a remote queue needs to be done reliably, and once only. The queue manager to which Program A is connected identifies a local queue called a transmission queue, and puts the message on that queue. It is the task of an MCA to get the message from the transmission queue and send it to a partner MCA at the other end of a communications connection. The receiving MCA then puts the message on the

destination queue Q2.

Once the receiving MCA has put the message on the destination queue, the protocol used by the two MCAs ensures that the message is removed from the transmission queue. If there is a communications failure during transmission, the same protocol also ensures that the two ends resynchronize when the communications connection is restored. Any

messages that have been safely received are removed from the transmission queue at the sending end, and any messages that were not safely received are sent again. This protocol is called the Message Channel Protocol (MCP) and is responsible for ensuring that a message is delivered to a remote queue once only.

If a message cannot be delivered, it would normally be put on the dead letter queue at the receiving end. However, the sending application may specify other options.

(46)

Figure 1-13. MQI calls WM101 / VM1011.0

Notes:

The component of WebSphere MQ that owns and manages queues is called a queue manager.

A queue manager also provides the message queue interface (MQI) to enable an application to access its queues and the messages they contain. The MQI is a simple application programming interface that is consistent across all platforms supported by WebSphere MQ. The MQI effectively protects applications from having to know how a queue manager physically manages messages and queues.

An application must first connect to a queue manager before it can access any of its resources. To connect to a queue manager, it issues an MQCONN or MQCONNX call. When the application no longer needs to be connected to the queue manager, it issues an MQDISC call.

To access a queue, an application must first issue an MQOPEN call. When it no longer requires access to the queue, the application issues an MQCLOSE call.

MQI calls

• Major calls – MQCONN – MQCONNX – MQDISC – MQOPEN – MQCLOSE – MQPUT – MQPUT1 – MQGET – MQSUB – MQSUBRQ • Minor calls – MQBEGIN – MQCMIT – MQBACK – MQINQ – MQSET Applications MQI Queue manager Queue manager object Namelist object Process definition object

(47)

Uempty Once a queue is opened, an application uses an MQPUT call to put a message on the

queue and an MQGET call to get a message from the queue. An MQPUT with a Topic String is also used to publish information which can be established for subscribers of the published information. The MQCLOSE call releases access to the queue. The MQPUT1 call enables an application to open a queue, put one message on the queue, and close the queue, all in a single call.

The MQPUT1, MQCMIT, and MQBACK calls enable an application to put and get messages as part of a unit of work.

A queue is an example of a WebSphere MQ object. However, there are other types of WebSphere MQ objects, such as a process definition, a namelist, and queue manager objects.

The following functionality was introduced in WebSphere MQ V7: using MQPUT with

topics, or topic strings, enables the publication of information. WebSphere MQ enables the subscription to publication information via the MQSUB and MQSUBR, which is outlined in Unit 8, “Linking.”

Every WebSphere MQ object has a set of attributes that describe the object. Each attribute has a name and a value. The definition of a WebSphere MQ object specifies the values of its attributes. Every WebSphere MQ object also has a name, which is considered to be one of its attributes. An application can use an MQINQ call to inquire on the values of the attributes of an object. It can use an MQSET call to set the values of certain attributes of a queue.

WebSphere MQ has two additional application programming interfaces: the Java interface for use in Java applications, and the Java Message Service (JMS), which allow

(48)

Instructor notes:

Purpose — To introduce the concepts of a queue manager and a WebSphere MQ object, and to describe the MQI calls.

Details — As shown in the figure, there are 10 major calls and five more specialized ones. It is not necessary to go into the details of the calls here, as they are covered in the

following units. Simply emphasize that this simple set of calls provides all the functionality that an application program needs to interact with WebSphere MQ.

It is sufficient to consider the following types of IBM WebSphere MQ objects: • Queue managers

• Queues

• Process definitions — the attributes of an application that must be known to a queue manager in order for the application to be started without operator intervention (used in triggering)

• Namelist — a WebSphere MQ object that contains a list of other WebSphere MQ objects

There are other types of WebSphere MQ objects as well.

WebSphere MQ V7 introduced the ability to publish using MQPUT with topic information. Subscriptions can be retrieved using the MQSUB and MQSUBR commands. More information is provided in Unit 8, “Linking, bridging, and the WebSphere MQ family.” Additional information —

(49)

Uempty

Figure 1-14. Message composition WM101 / VM1011.0

Notes:

A message is composed of two parts: the various headers used by WebSphere MQ, and the application data.

All WebSphere MQ messages always have a header called the WebSphere MQ message descriptor (MQMD). The message descriptor contains control information about the

message that is used by both the queue manager and the receiving application. It contains a number of fields that you review later in the course.

The application data is meaningful only to the applications that send or receive the message. It is possible to have a message with only a header and no application data. There is no restriction on the content of the application data, but there is a maximum allowable length of 100 MB for a physical message. However, later in the course you see that messages larger than that size can still be processed.

Message composition

• Set by application and queue manager • Header

– MQMD (message descriptor) • Application data

– Any sequence of bytes

– Meaningful only to the sending and receiving applications – Not meaningful to the queue manager

Application data Header

(50)

Instructor notes:

Purpose — To describe the two parts of a message.

Details — The application data (sometimes referred to as the “payload”) in a message has no meaning to the queue manager, and is not checked or processed in any way. Under certain circumstances, however, it may be converted from one character representation to another, and from one numeric representation to another, if wanted. You look more closely at application data conversion later in the course.

The message descriptor is used by the queue manager and the receiving application for the purposes of security, reporting, determining the sequence in which messages are delivered to the receiving application, and so on.

Some of the fields in the message descriptor are set by the application that puts the message on a queue; others are set by the queue manager on behalf of the application. Both the message descriptor and the application data are returned to the application that gets the message from the queue.

Do not get too deep on the contents of the message descriptor or the use of the other headers here. You look at the message descriptor in detail in Unit 3.

Additional information — In general, the default maximum message length is 4 MB, although you can increase it to a maximum length of 100 MB. An application is not limited to sending a maximum of 100 MB at a time; larger messages can be sent by using

segmentation, which is discussed in Unit 3.

Transition statement — Next, you look at some types of application models for which WebSphere MQ is well-suited.

(51)

Uempty

Figure 1-15. Parallel processing application design WM101 / VM1011.0

Notes:

Booking a vacation with a travel agent may require a number of tasks. In the scenario depicted in the figure, an agent needs to reserve a flight and a hotel room, and rent a car. All of these tasks must be performed before the overall business transaction can be considered complete.

Using WebSphere MQ, a request message can be put on each of three queues which serve the car rental application, the flight reservations application, and the hotel

reservations application. Each application can perform its respective task in parallel with the other two, and then put a reply message on the reply-to queue. The agent's application can then get the three replies and produce a consolidated answer.

This model allows several requests to be sent by an application without the application having to wait for a reply to one request before sending the next. All the requests can then be processed in parallel. Designing the system in this way can improve the overall

response time.

Parallel processing application design

Car Flight Hotel MQPUT CAR.RENTAL MQPUT FLIGHT MQPUT HOTEL

MQGET reply-to queue

CAR.RENTAL FLIGHT HOTEL MQPUT MQPUT MQPUT Reply-to queue

(52)

Instructor notes:

Purpose — To explain how WebSphere MQ enables applications to be built in which units of processing can be done in parallel, or possibly even on different systems.

Details — A more complex application may involve sending a number of requests to different servers. For example, a travel agent might use an application to arrange a trip for a customer. The requirements of the customer might mean that the application needs to make a number of requests — to make an airline reservation, to book a hotel room, to run a credit check, and so on.

By using queues, these steps do not have to be performed serially. The requests can be put on different queues, and processed in parallel.

The application might then wait until it has received all the replies before preparing a consolidated response. Alternatively, the business logic may define a time limit to wait for the replies. In that case, the application may present some form of partial response with limited information after that time has elapsed.

As you have seen previously, the application design may involve having a separate process to receive and process the replies.

Transition statement — Next, you look at how an application can be started automatically by the arrival of a message on a queue.

(53)

Uempty

Figure 1-16. Triggering WM101 / VM1011.0

Notes:

In WebSphere MQ, it is possible to arrange for an application to be started automatically when a message is put on a queue and certain conditions are satisfied. This facility is known as triggering.

The figure depicts the sequence of actions involved in triggering.

1. Program A puts a message on an application queue that is enabled for triggering. 2. If the conditions for triggering are met, a trigger event occurs, and the queue manager

examines the process definition object referenced by the application queue. The process definition object identifies the application to be started, namely Program B. 3. The queue manager creates a trigger message whose fields contain information copied

from certain attributes of the process definition object and the application queue, including the name of the application queue. The queue manager puts the trigger message on an initiation queue.

4. A long-running program called a trigger monitor gets the trigger message from the initiation queue, and examines its contents.

Triggering

Process definition object MQPUT A.Q Program A Trigger types: • FIRST • DEPTH • EVERY Application queue (A.Q) Initiation queue (I.Q) Trigger monitor 1 2 3 4 6 5 MQGET I.Q MQGET A.Q Program B Queue manager

(54)

5. The trigger monitor starts Program B, passing it information from the trigger message as a parameter, including the name of the application queue.

6. Program B opens the application queue and gets messages from it. Triggering can occur based on selected conditions:

• The first time a message arrives on a queue

• When the number of messages on the queue reaches a predefined number • Every time a message arrives on a queue

(55)

Uempty

Instructor notes:

Purpose — To explain how triggering works. Details — Cover triggering only at a high level. A trigger event may occur in one of three ways:

• The first message that arrives on the application queue can be the trigger event. In this case, the application would get the first message from the queue and continue to get any more messages that arrive later. It would terminate only if the queue is empty and no message arrives within a predetermined time.

• When the application queue reaches a specified depth, for example, 10 messages. The design of the started application would normally be similar to that of the previous case. • Every message that is put on the application queue. In this case, the started application would normally be designed to get and process just one message before terminating. This option is a difficult option to use, both from the point of view of administration and from the point of view of application design. Its use is not, therefore, generally

recommended. One problem is that it can cause multiple instances of a program or transaction to be scheduled within a short time, thus putting a strain on system resources.

It is possible to specify that messages below a certain priority are ignored by the queue manager when determining whether a trigger event should occur.

A trigger monitor may start the application synchronously within its own unit of execution or asynchronously as a separate unit of execution. It is worth pointing out that trigger monitors are supplied with WebSphere MQ, but users can write their own trigger monitors for the different operating systems and environments.

Transition statement — Next, you look at how WebSphere MQ can be used to implement client/server applications.

(56)

Figure 1-17. Client/server application model WM101 / VM1011.0

Notes:

The server application (insurance quotations) can handle requests from multiple client applications. Each application client is identical, and requests information from the

application server. The message descriptor in each of the incoming messages identifies the appropriate reply-to queue for each request, so that the application server knows where to route the reply message.

Client/server application model

Insurance agent Insurance agent Insurance agent Application clients • Queue = service • Message = request • Reply-to queue name in

message descriptor • Multiple instances of server possible Insurance quotations Application server Insurance data

(57)

Uempty

Instructor notes:

Purpose — To explain how a queue can be viewed as a service, and how multiple clients can request the same service.

Details — The previous example described how a single client application can put messages on one or more queues in order to request the services of the applications serving those queues.

In general, multiple applications may put messages on the same queue in order to request the same service. The application serving the queue gets each message in turn and responds to it.

The message descriptor of each request message plays an important role here. One of the fields in the message descriptor is the name of the reply-to queue whichinforms the server application where to put the reply message. In this way, each client application can receive its replies separately from the replies of the other client applications.

The message descriptor also has a field to hold an identifier for a message. Furthermore, the message descriptor of a reply message can contain the identifier of the request message to which it relates (the correlation ID). In this way, a client application can correlate a reply with a request it sent previously.

If required, multiple instances of the server application may serve the same queue for increased throughput.

Transition statement — If an application wants to issue MQI calls to a queue manager, the application and the queue manager can be running on different systems.

(58)

Figure 1-18. WebSphere MQ client WM101 / VM1011.0

Notes:

A WebSphere MQ client is a component of IBM WebSphere MQ that allows an application running on a system where no queue manager exists to issue MQI calls to a queue

manager running on another system.

The client stub receives the input parameters of an MQI call from the application and sends them over a communications connection to the server connection. The server connection is on the same system as the queue manager. The server connection then issues the MQI call to the queue manager on behalf of the application. After the queue manager has completed the MQI call, the server connection sends the output parameters of the callback to the client stub, which then passes them to the application.

Most MQI calls and options are available to the client application. The application simply issues an MQCONN (or MQCONNX, where supported) call to connect to a queue

manager. Special consideration of WebSphere MQ client and database units of work are discussed later.

Not surprisingly, a reliable communications connection is required.

WebSphere MQ client

WebSphere MQ application Communications stack Client stub WebSphere queue manager Communications stack Server connection

Client system Server system

(no queue manager exists on this system)

Communication link