Académique Documents
Professionnel Documents
Culture Documents
Session S19.
Introduction to WebSphere MQ Queue Managers
Morten Sætra
morten.satra@no.ibm.com
Agenda
• Messaging Fundamentals
• What is a message
• Introduction to Queue Manager
• The MQ API
• Application connection topologies
• Remote messaging
• Administration
• Security
• WebSphere MQ and the Wider World
Messaging Fundamentals
Y
A
The physical world is frequently organised in queues. Consider for a moment just how
many queues you have been involved in today alone. We queue at the Post Office,
Supermarket checkout, at traffic lights. We write shopping lists and to do lists. We use
the postal service, voice mail, and of course, the ever present e-mail.
The truth is that queuing is a natural model that allows us to function efficiently.
Perhaps not surprisingly therefore it turns out that it is also a very useful model in which
to organise our applications.
Instead of application A talking synchronously to Application B have Application A 'send
a message' to a queue which Application B will read.
What WebSphere MQ (aka MQSeries) did was to recognise that for the queuing model
to be successful and applicable to a wide range of applications that it must achieve two
major goals :-
What's a Message?
Header
Header User
UserData
Data
What's a Queue ?
• Place to hold messages
•Various Queue Types
•Local,Alias,Remote,Model
• Queue creation
•Predefined
•Dynamic definition
• Message Access
•FIFO
•Priority
•Direct
•Destructive & non-destructive access
•In transactions
• Parallel access by applications
•Managed by the queue manager
Kernal
Local
Moving Queuing
Message
LAN
OS/2
Compaq OpenVMS
Compaq NSK / NSS
Compaq Tru64 UNIX
VSE/ESA
Digital UNIX
Messaging Clients
SCO: Openserver,
DG/UX
UnixWare
HP3000 MPE/iX
IRIX
Java
Dynix/ptx
Windows: 3.1,95,98
NCR
.NET
DOS
VM
WAN TPF
DC/OSx
Sinix
Apple MacOS
Unisys 2200
Stratus VOS
Hitachi
4690
Unisys A …
…
The MQ API
Program A
MQI
Queue Manager
Process Queue
Object Manager
Object
Queues
MQ API - notes
There are 13 verbs in the WebSphere MQ API, four of which are most heavily used and the
rest have less frequent use. The most common verbs will be MQOPEN, MQCLOSE,
MQPUT and MQGET which are concerned with the processing of messages on queues.
The other verbs have important uses but will not be used as commonly as these four.
There are many, many options associated with these verbs - approximately 250! However,
in general, most of these options may be left to take their default values - and MQ provides
a set of default structures to allow for easy assignment of these default values.
The MQ API has both a procedural implementation and an object oriented implementation.
This allows for straightforward usage in both of these programming environments.
All of the popular languages and programming environments are supported, for example:
Assembler (z/OS)
C, C++, COBOL, PL/1
RPG (AS/400)
Java, JMS
LotusScript,SmallTalk,Visual Basic,COM
Plus application environments, e.g.
CICS, IMS,Encina, Tuxedo, TXSeries, WebSphere Application Server, MTS, ...
Program B
Program A
Reply-to-Queue
Examples
These examples show some of the ways in which MQ queues can be used
and, thereby, shows some of the styles of applications that may benefit from
the use of a message/queuing model.
Request/Response
This style is typical of many existing synchronous applications where some
response is required to the data sent. This style of operation works just as well
in an asynchronous environment as in a synchronous one. One difference is
that - in this case - the sender does not have to wait for a response
immediately. It could pick up the response at some later time in its processing.
Although this is also possible with the synchronous style, it is less common.
Examples…
Chain
Workflow
Program A Program B
Program D
Program C
Examples…
Chain
Data does not have to be returned to the originating application. It may
be appropriate to pass a response to some other application for
processing, as illustrated in a chain of applications.
Workflow
There may be multiple applications involved in the processing before a
response comes back to the originating application.
Data C
Data
A
A
Pub/Sub D
Broker B
Data
B E
A,B
Subscription
B F
(re-) Publication
Examples…Publish/Subscribe - notes
Examples … Clustering
Q Mgr 1
B
Queue 1
Q Mgr 2
B
Queue 1
Q Mgr 3
Q Mgr A B
A ? Queue 1
Q Mgr 4
B
Queue 1
Examples …. Clustering
The final example given here (though not the last possibility by any
means) is MQ Clustering.
In order to enable highly scalable applications, MQ queue managers
provide support for MQ Clusters. In this environment, there are several
copies (or clones) of a particular target queue and each message is
sent to exactly one of the possible choices.
WebSphere MQ Cluster support also defines and manages all MQ
resources, such as channels, automatically and provides automatic
notification of failed or new queue managers in the environment.
Goals of Clustering
QSERVICE
MQPUT QSERVICE
QM 1 QM 2
Program A Program B Program C
Put Q2
Put Q1 Get Q1 Get Q2
MQI MQI
Messaging
Messaging and
and Queuing
Queuing
Q2
Transmission Q Q1
to Program B
In this case the actual physical queue that both applications access are the
same. This therefore does not require any network communication.
to Program C
In this case Program A wants to put a message to queue Q2 on Queue
Manager QM2. It can't do this directly without requiring that the network and
QM2 Queue Managers are available so instead the message is put to a
'holding' queue called a transmission queue. Asynchronously another part of
WebSphere MQ called a channel will read this transmission queue and deliver
any messages to the queues on QM2.
Any number of applications running on QM1 can send messages to QM2 via
the same transmission queue and channel.
MQ
Application
MQ Explorer
Programmable
Command
Format
System Management
Applications
E.g.
BMC
Kernal ComputerAssociates
Local WebSphere Landmark
Moving MQ Events Nastel
Message Queuing RYO
Tivoli/Candle
WebSphere MQ supports logical units of work (UoW) where a set of resource updates
may be considered as an atomic unit - either all of the changes are made or none of the
changes are made. This support is particularly important when using WebSphere MQ in
a commercial environment (it's primary focus) as transactions play a major part in this
arena.
WebSphere MQ allows messages to be included/excluded from a UoW at the message
level. This differs from some other environments where a UoW starts and all subsequent
actions are included in the UoW. Thus, a set of messages may be considered to be a
UoW. Often, it is necessary to include both MQ messages and some other recoverable
resources (typically database updates) in a UoW. Typically, this has required the use of
some Transaction Monitor and WebSphere MQ works well with CICS and IMS on z/OS
and with any XA compliant Transaction Manager. In situations where a Transaction
Manager product is not available/suitable, WebSphere MQ itself may be used as the
Transaction Manager. This does not mean that WebSphere MQ is transforming itself
into a Transaction Monitor, it is just providing the Transaction Manager aspect of a
Transaction Monitor product.
The API used in handling transactions differs according to the environment. WebSphere
MQ provides some verbs to handle UoWs. If a Transaction Monitor is used, however, its
UoW verbs are used in place of the MQI.
WebSphere MQ Security
Application
Security
Commands
Context
Access
A Control
Xmit Q 2 Queue 4
Transmission
Queue 1
Queue3 Queue 5
QMgr 1 QMgr 2
Channel Security
WebSphere MQ 5.3 provides built-in SSL link level security
MQ provides a set of exit points, available in the intercommunication
component. These exit points allow a set of functions to be provided:
The security exit allows for (mutual) authentication of partner
systems when they connect to one another.
The message exits allow for customisation at the message level,
allowing individual messages to be protected, in terms of message
integrity, message privacy and non-repudiation
Application Security
This level of security is not implemented directly by the Queue
Manager but such facilities may be implemented at the application
level, outside of the direct control of WebSphere MQ.
WebSphere MQ
& the Wider World
Monitoring Services
User Community
Interaction Application Information Process Integration
Services Services Services Services Services
WebSphere MQ Everyplace
Customer
Relationship
Management (CRM)
Retail stores
Enterprise resource
Planning (ERP)
WebSphere MQ Everyplace
• Allows you to extend your infrastructure to the
mobile environment with robust and dependable
access to business critical applications anytime
anywhere
• Helps you gather transactions from the
marketplace to enable realtime analysis
• Supports publish and subscribe messaging when
used with WebSphere MQ Integrator Broker and
WebSphere MQ Event Broker
• Supports fragile networks with messaging over
satellite, phone lines and radio links.
Adapter Architecture
Integration Brokers
WebSphere
InterChange A
Server B
C D
JMS
E
WBI
Message WBI Adapter MQ
Broker FAIL MQOutput1
JMS
Framework
Connector
MQInput1 Compute1
Adapter
Compute2
MQOutput2
WBI JDBC
Internet reach
in a security-rich Enterprise
Enterprise environment Applications
Applications
Mobile
Mobile devices
devices Enterprise
Integration bus,
Inbound Event Web Services, Outbound Web
Information Monitoring WebSphere Java Information And Portals
And
Web Business Integration Messaging
Control Services
And Portals Event Broker Telemetry
Sensors
Telemetry Routing
Sensors Multicast
Subscribers
WebSphere Business Integration Event Broker routes targeted messages in realtime from multiple
devices and locations to people and applications throughout your enterprise – and beyond
Internet reach
in a security-rich Enterprise
Enterprise environment Applications
Applications
Mobile
Mobile devices
devices Enterprise
Integration bus,
Inbound Event Web Services, Outbound Web
Information Monitoring WebSphere Java Information And Portals
And
Web Business Integration Messaging
Control Services
And Portals Message Broker Telemetry
Sensors
Telemetry Routing
Sensors Enrichment
Multicast
Transformation
Subscribers
WebSphere Business Integration Message Broker routes targeted messages in realtime from multiple
devices and locations to people and applications throughout your enterprise – and beyond
Message Broker
Includes all the functions of Event broker (and is a seamless upgrade)
Plus provides the function that enables complex message routing and transformation
functions to be encapsulated outside of applications, in a (logically) central component.
Choreography/Workflow management
Separates the business logic (flow logic) from the
implementation of the business functions
Activity sequence can be easily updated/changed to
represent changing business processes
Generic interface to the process, interacting with the
activities and their data rather than with applications
directly
Concurrency:-If a process contains parallel branches,
the middleware guarantees that the branches are
executed concurrently in parallel threads
Recoverability:- If the system fails while executing a
process based application, the execution of the
application carries on where it left off – steps that have
already been performed are not repeated
invoke
p1
invoke invoke
p2
invoke
Flow determined
by externalized
business rules
• Specification of a set of activities that make up the business process. These process activities may be
automated or may involve some end user (supported by user interaction services). A process that is
composed entirely of automated activities is referred to as an automated process or as a straight-through
process.
• The activities are linked together or choreographed by use of a set of connectors. These are the black
lines shown connecting together the activities.
• It is possible to traverse any combination of activities (via the connectors) and so there needs to be a set
of transition conditions controlling which activities are traversed. These are the predicates, labeled P1 and
P2 in the picture. It is possible to traverse any combination of activities and so, for the process shown, it is
possible to visit either or both of the activities in the middle of the picture.
• Where there are staff activities, there needs to be some process for determining which users will be
assigned which activities. This is known as staff resolution.
• The business process has state – associated with all of the activities within the process. This state is
maintained across the entire business process and is available to the various activities and the transition
predicates. It is also available to the monitoring component of the BI architecture if required.
• Business processes may be long running – especially if there are people involved in the process. Long
running business process need to preserve their state so that they are recoverable in the case of failures
within the environment. For this reason the state (and other data) of the process is regularly recorded in a
recoverable store.
Thank You