WebSphere
MQ is an IBM web sphere product which is evolved in 1990’s. MQ does transportation
from one point to other. It is a middleware tool used for connectivity.
Previously it was known with name ‘mqseries’. MQ supports more than 35+ operating
systems. It is platform independent. For every OS we have different MQ
software.
WebSphere
MQ is a solution for application-to-application communication services
regardless of where
your
applications or data reside. Whether on a single server, separate servers of
the same type, or
separate
servers of different architecture types, WebSphere MQ facilitates
communications between
applications
by sending and receiving message data via messaging queues. Applications then
use the
information
in these messages to interact with Web browsers, business logic, and databases.
WebSphere
MQ
provides a secure and reliable transport layer for moving data unchanged in the
form of messages
between
applications but it is not aware of the content of the messages. WebSphere MQ
uses a set of
small and
standard application programming interfaces (APIs) that support a number of
programming
languages,
including Visual Basic, NATURAL, COBOL, Java, and C across all platforms.
VERSIONS:
5.0, 5.1, 5.3, 6.0, 7.x & 8.x (Latest). Currently widely used
version is 7.x
PERSISTENT
AND NON-PERSISTENT MESSAGES:
MQ differentiates between
persistent and non-persistent messages. Delivery of persistent
messages is assured; they are
written to logs to survive system failures. Non-persistent
messages cannot be recovered
after a system restart.
MQ
Objects: objects are used to handle the transactions with the help of
services.
QUEUE
MANAGER maintains all the objects and services.
QUEUE:
it is a database structure which stores messages until the
application or program receives messages.
TYPES
OF QUEUES:
• Local Queue
• Alias Queue
• Model Queue
• Remote Queue
• Repository Queue
Local
Queue:
A queue is local if it is
owned by the queue manager to which the application program is connected. It is
used to store messages for programs that use the same queue manager. For
Example, program A and
program B each has a queue for incoming messages and another
queue for outgoing messages.
Since the queue manager serves both programs, all four queues
are local.
Note: Both programs do not have to run in the same workstation.
Client workstations usually
use a queue manager in a
server machine.
ALIAS
QUEUE:
WebSphere MQ Basics
Alias queues are not real
queues but they are definitions. They are used to assign different
names to the same physical
queue. Advantages of alias queue allow multiple programs to work
with the same queue but with
different attributes or properties.
Example:
Alias for LQ with different parameters
DEFINE QALIAS (PQ) TARGQ (LQ)
GET (DISABLED) PUT (ENABLED)
DEFINE QALIAS (PQ) TARGQ (LQ)
PUT (ENABLED) GET (DISABLED)
DEFINE QLOCAL (LQ)
Model
Queue:
A model queue is not a real
queue. It is a collection of attributes that are used when a dynamic
queue is created.
Repository
Queue:
These are used in conjunction
with clustering and hold either a full or a partial repository of
queue managers and queue
manager objects in a cluster (or group) of queue managers.
Remote
Queue:
The queue which holds the
address of the remote queue manager where the message has to
be sent or delivered. It is a
logical queue where we cannot store the messages and get the
messages.
Note: To send the messages we use only Remote Queue, none other
than this
Message Flow from remote
Queue:
“Remote queue->
Transmission queue-> Channel->Network receiver channel-> Local queue
(Finally the message will
reach here) “
CHANNEL (123.456) channel
name.
CHLTYPE (SDR) sender channel
TRPTYPE (TCP) Transport type
using TCP protocol
CONNAME (127.0.0.1)(1414)?the
channel will connect to the IP address specified in the conn
name and looks for the queue
manager which is having listener, port number(1414) and
connects to the queue
manager.
XMITQ (TQ)?the channel will
receive the messages from transmission queue.
TYPES
OF LOCAL QUEUE:
• Dead letter Queue
• Transmission Queue
• Initiation Queue
• Local Queue.
DEAD-LETTER
QUEUE: The enrooted (or) undelivered messages will be landed in to the
dead
letter queue. We have one
control command called runmqdlq.It is a control command which is used to route
the messages through .rul table. This is called dead letter handler. It is
important
that we need a dead letter
queue defined for every queue manager.
Note: For one Queue manager we can’t have two dead letter
queues.
We have system defined
objects called SYSTEM.DEAD.LETTER.QUEUE. Or we can use our
own dead letter queue. The
messages those are landed in the dead letter header (DLH). By
seeing the dead letter
header, we can find the reason and the destination.
RULE TABLE:
Syntax:- DESTQ(DLQ)
DESTQM(222) REASON(*) WAIT(NO) FWDQ(LQ) FWDQM(222)
HEADER(NO)
Runmqdlq: rule table path
TRANSMISION
QUEUE: TQ will receive messages from Remote queue and hits or sends the
messages to the channel.
CHANNELS:
It is a Networked program to
transmit or pas the messages over the network. Channel will
receive the messages from
XMITQ which is defined in the definition of the channel.
Transmission queue is also a
local queue.
TYPES
OF CHANNELS:
• Message channels.
• MQI Channels.
MESSAGE
CHANNELS: Message channels are one way piping channels. They are
used for
sending or receiving the
messages. Message channels are unidirectional.
TYPES OF MESSAGE CHANNELS:
• Sender Channel(SDR)
• Receiver Channel (RCVR)
• Server Channel (SVR)
• Requester Channel (RQSTR)
• Cluster Sender Channel (CLUSSDR)
• Cluster Receiver Channel (CLUSRCVR)
MQI
CHANNELS: These channels are two way piping channels which can send
and receive the messages in both ways.
TYPES of MQI Channels:
• Server Connection Channel
(SVRCONN)
• Client Connection Channel
(CLNTCONN)
COMBINATION
OF CHANNELS:
• Sender and Receiver
• Server and Requester
• Cluster sender and Cluster
Receiver
• Server Receiver
• Sender Requester
LISTENER:
It is a service of MQ. Every
Queue Manager will have a listener defined with a unique port number. Default
port number is:-1414. Listener acts as a mediator between external application or
queue managers connecting to the queue manager. To contact the queue manager we
should approach through Listener.
Comments