Introduction To Websphere MQ

You might also like

Download as pps, pdf, or txt
Download as pps, pdf, or txt
You are on page 1of 31

Introduction to WebSphere MQ

What is Websphere MQ?

• IBM WebSphere MQ is a family of network communication


software products launched by IBM. It allows independent and
potentially non-concurrent applications on a distributed systems to
communicate with each other.

• A middleware product that implements a messaging and queuing


framework.

• Middleware - an intermediate software component that bridges


dissimilar computing environments.
¨ Unix, MVS, OS/400 Tandem, VMS, NT, etc.
¨ SNA, NetBios, TCP/IP
¨ Cobol, C, JAVA
Messaging and Queueing
• Messaging - programs communicate by sending data in
messages rather than by calling each other directly.
• Queuing - messages are put on queues in storage,
eliminating the need for programs to be logically connected.
• A messaging and queuing framework is inherently
ASYNCHRONOUS!

•Messaging means that programs communicate by sending


each other messages (data), rather than by calling each
other directly.
•Queuing means that the messages are placed on queues in
storage, so that programs can run independently of each
other, at different speeds and times, in different locations,
and without having a logical connection between them.
Asynchronous vs. Synchronous Communications

• Synchronous: App sends request, then blocks until request is


processed.
¨Requires service available at EXACTLY same time as client
needs service.

• Asynchronous: App sends request and checks at some future time if


complete.
¨Service need not be available when client sends request
Synchronous: Adv/DisAdv
Asynchronous: Adv/DisAdv
Messaging Advantages
Messaging vs. Procedure Calls

• As programmers, many of us think procedurally, so using procedures


is “natural” extension of how we think.
• Messages are an abstract concept: harder for us to conceptualize
relationship between actions and messages!

•We are free to concentrate on the design of the application itself.

•We are no longer concerned with details of the environment.

•Our application is suddenly portable and to some degree, extensible.


How Messaging &Queuing Works
Messaging and Queuing Characteristics
Three key facts about Messaging and Queuing differentiate it from other
communication styles:

1) Communicating programs can run at different times.

2) There are no constraints on application structure.

3) Programs are insulated from environmental differences.


Applications Shielded from Environmental Differences
• Don’t care what OS is used.
• Don’t care what language they’re written in
• Don’t care what the underlying communication protocol is used.
WebSphere MQ
Objects
Queue Manager
Queue Manager
• Controls access to queues:
administration (create, delete, etc)
usage (Put, Get)

• serves as transaction (syncpoint) coordinator for all queue operations.

• Accessed through the Message Queue Interface (MQI)

• Queue Managers have names (identities) that are UNIQUE in a


network (like host names).
Queues
MQSeries defines four types of queues. A queue instance is fully qualified by its queue
manager and queue name.

• Local Queue - an actual queue for which storage is allocated.

• Remote Queue - a definition of a queue on a different queue manager (acts


somewhat like a pointer)

• Alias Queue - another name for a local or remote queue. Typically used to switch
queue destinations without modifying program code.

• Model Queue - a template whose properties are copied when creating a new dynamic
local queue (“ create queue xxx “like” queue yyy).

MQSeries Queues: Some Properties


Maximum Message Size
Maximum Queue Depth
High/Low Factors
Enable/Disable Put or Get
Persistent/Not Persistent
Events, Triggers, Process
• Local queues can generate events (messages) under certain
conditions (like queue full).
• These “event” messages can be used to “trigger” the execution of a
program.
• These events are called trigger messages. The queue on which
they are put is called an Initiation Queue.

• Process defines an application to an websphere MQ queue manager.


A process definition object is used for defining applications to be
started by a trigger monitor.

• A trigger monitor is a program that listens on an initiation queue


and executes commands named in Process definitions.

• Triggering is useful when you don’t want to deploy long-running


programs.
Channels
• provide a communication path between two queue managers on the same, or
different, platforms.
• A message channel can transmit messages in one direction only. If two-way
communication is required between two queue managers, two message
channels are required.
• Message Channels are implemented by programs called Message Channel
Agents (MCA)

Types of message channels:


• Sender - initiates connection to Receiver
• Server - Accepts request to start from requester, then becomes Sender
• Receiver - Passive; waits for initiation sequence form Sender
• Requester - Active at start, then becomes Receiver
• Cluster-sender (used amongst Cluster Queue Managers)
• Cluster-receiver (ditto)
How messages move across channels ?
WebSphere MQ: Assured Delivery

• If queues are persistent, and message is persistent, then MCAs will


eventually deliver the message to the target queue, and target
application will get it!

• MCAs have recoverable state - they’re STATEFUL - and a connection-


oriented protocol.

• Message is not removed from xmit queue until partner MCA confirms
placement on target queue
Messages
Messages consist of:
• Header (MQMD)
Used by Queue Manager and application to handling properties of the message
• User Data
The application-to-application data (“payload”)
transparent to MQSeries

Messages: Some Properties


• Destination Queue
• Reply Queue name
• Time to live (expiry)
• Format
• Correlation ID
• Persistence
• “Report” options

• Messages can be individually designated persistent or non-persistent (persistent


messages are logged to enable recovery)
• Correlation ID - select which message to get from queue
• Segmented Messages - allows ending of VERY LARGE messages (> 100 MB)
Message types
• Request - used by one program to ask another program for
something (usually data). A request message needs a reply.
• Reply - used in response to a request message.
• A one-way message, as you would expect, doesn’t need a reply,
though it can carry data.
• A report message is used when something unexpected occurs, or to
give extra information like:
• message delivered to target queue
• message taken by application
• message not deliverable
• message exceeded time-to-live
• Request/Reply
An application places a message on a queue and expects a reply in
return

• Publish & Subscribe


messages are “broadcast” to interested participating applications in the
MQ network
Transaction Support
• Unit of recovery - a piece of work that changes data from one point
of consistency to another.
• Syncpoint - A point of consistency (also called a or commit point). It
is a moment at which all the recoverable data that an application
program accesses is consistent.

• Applications are responsible for delimiting the beginning and end of a


transaction. How can messaging be coordinated with a data base
update?
• MQ is XA compliant and can operate with other XA compliant systems
as either a transaction manager (coordinator) or resource manager
(particpant).
Some examples: Sybase, DB2, Oracle.
Logging and Recovery
All operations that affect the “state” of the Queue Manager and its objects are
logged to a log file.
• What is “state”?
• Object definitions (queue manager, queues, processes, channels, etc)
• Queue content (messages)
• Message channel states are logged separately by each channel

• Two forms of Logging


• Circular – log records are written sequentially across several files, then “wrap”
back to the first file.
• Linear - log records are written sequentially across files. New files are
allocated as current files fill. No automatic reuse of file space!
• Observations:
• Circular logging is easy to manage, but is fatal if log is damaged (hard to
backup circular logs!).
• Linear logging is hard to maintain but provides for archiving of previous logs
(still a problem if “current” log is damaged).
Queue Manager Operations

• crtmqm -q host1/qm1
creates a queue manager name qm1 on host1

• Strmqm
Starts queue manager

• Dspmq
Lists all the queue managers

• rummqsc
Starts queue manager scripting interface
Queue Operations
Define/Modify Queue
• DEFINE QLOCAL('queue1') DESCR(Test Queue)
Creates a local queue named queue1
• DEFINE QLOCAL('queue1') REPLACE DESCR(Modifieddescription)
Modifies the queue1 description

Displaying Queues
DISPLAY QLOCAL(*)
DISPLAY QLOCAL('queue1')
DISPLAY QLOCAL('queue1') ALL
DISPLAY QLOCAL('queue1') DEFPSIST DESCR CURDEPTH

Altering Queue Definition


ALTER QLOCAL('queue1') property
DISPLAY QLOCAL('queue1')
• Put messages onto queue
amqsput queue1
Sample AMQSPUT0 start
target queue is queue1

• Read message from Queue


amqsbcg queue1 > queue1.txt
Reads messages from queue and messages will not be
removed from queue

Gets messages from queue and messages will be removed


amqsget queue1
Alias queue

Creating alias Queue


runmqsc
DEFINE QALIAS('queue1. alias') TARGQ('queue1') DEFPSIST(YES) + DESCR(alias
to queue1: For persistent messages)
AMQ8006: WebSphere MQ queue created.
end
2 : end
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Displaying Alias queue


runmqsc
DISPLAY QALIAS('queue1.persistent') TARGQ DEFPSIST DESCR
AMQ8409: Display Queue details.
QUEUE(queue1.persistent) TYPE(QALIAS)
TARGQ(queue1) DEFPSIST(YES)
DESCR(alias to queue1: For persistent messages)
Remote queue

• DEFINE QREMOTE('host1/qm1.alias') RNAME('')


RQMNAME('host1/qm1') +DESCR(queue manager alias to
host1/qm1')
AMQ8006: WebSphere MQ queue created.

• DISPLAY QREMOTE('host1/qm1.alias') RNAME RQMNAME DESCR


AMQ8409: Display Queue details.
QUEUE(host1/qm1.alias) TYPE(QREMOTE) DESCR(queue manager
alias to host1/qm1) RQMNAME(host1/qm1) RNAME( )
end
Channel and Listener

• Creating sender channel (from SRC_QM to TGT_QM)


DEFINE CHL ('SRC_QM.TO.TGT_QM') CHLTYPE(SDR) TRPTYPE(TCP)
+ CONNAME ('IP_address(port)') XMITQ('TGT_QM') DISCINT(0)

• Creating receiver channel (on TGT_MQ)


DEFINE CHL ('TGT_QM.TO.SRC_QM') CHLTYPE(RCVR) TRPTYPE(TCP)

• Creating listener on SRC_QM


DEFINE LISTENER(SRC_QM.listener) TRPTYPE (TCP) PORT(1414)

You might also like