MQ Tech Notes

®
IBM Software Group
GSE Nordic Technical Conference

May 23rd – 25th 2005 – Riga
Session S19.
Introduction to WebSphere MQ Queue Managers
Morten Sætra
morten.satra@no.ibm.com
© 2004 IBM Corporation

IBM Software Group | WebSphere software
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
© IBM Corporation 2004

Messaging Fundamentals
• A single, multi-platform API

• Easy to use Message centric interface
• Network Independent
….faster application development
• Assured message delivery
• Loosely coupled applications
• Asynchronous messaging
B
Y
A

Messaging Fundamentals - notes
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 :-
First it must be totally reliable. A message put to an WebSphere MQ queue is as safe as

a record written to a database. e-mail just isn't reliable enough
Secondly it should be available everywhere

The postal service would be severely restricted if it only covered the local city.

Messaging Fundamentals - Reducing Complexity
• Reliable, distributed computing

• Complex
• Error prone
• WebSphere MQ eases the complexity

• WebSphere MQ is not a substitute for:
• Well written applications
• Robust network
• Good operational procedures
• Well managed system

Messaging Fundamentals - Reducing Complexity notes

The WebSphere MQ base product is available on all major platforms such as
Windows,AIX, HP, Solaris, iSeries, z/OS and many others.
A simple API, known as the MQI, is available with only around a dozen verbs
which allows an application on one platform to communicate with an application on
another platform without either application requiring any explicit knowledge of each
other. The goals of MQ from an application standpoint are to provide :-
• Time Independence
It is not necessary for both applications to be up and running at the same time
• Platform Independence
A sending application need not know what type of platform the receiving
application is running on.
• Location Transparency
A sending application need not know where the receiving application is nor have
any knowledge of the network or communications .
• Data transparency
With the advent of Brokers and message translation it is not even necessary for
the two applications to exchange messages in a shared format.

What's a Message?
Message = Header + User Data
Header
Header User
UserData
Data
•Any sequence of bytes

•Any sequence of bytes
•Private to the sending and
•Private to the sending and
AASeries
SeriesofofMessage
MessageAttributes
Attributes receiving programs
receiving programs
Understood
Understood and augmentedby
and augmented bythe
theQueue
QueueManager
Manager •Not meaningful to the Queue Manager
•Not meaningful to the Queue Manager
•Message Id
•Message Id
•Correlation
•CorrelationIdId
•Reply
•Replyrouting
routinginformation
information •Message Types
•Message
•Messagepriority
priority
•Message
•Messagecodepage/encoding
•Message
codepage/encoding
format
-Persistent ... recoverable
•Message format
....etc.
....etc.
-Non Persistent
•Up to 100MB message length

What's a Message? - notes
A message in WebSphere MQ is merely a sequence of bytes in a buffer of a given

length. The current products support up to 100MB in a single message although the
vast majority of messages are in the order of a few thousand bytes.
Messages have various attributes associated with them such as their identifier, their
priority and their format. Each application is free to define its own format for messages
although there are a number of predefined formats. One common format for messages
is XML for example.
A key attribute of a message is its persistence. A message is either persistent or non-
persistent. This attribute tells the Queue Manager how important the message is.
Persistent
Persistent messages are written to disk and are logged. The Queue Manager will
ensure that the messages are recovered in the case of a system crash or network
failure.
These messages are delivered once and only once to the receiving applications.
Non persistent
The messages are identified by the application as non-critical. The Queue Manager will
make every effort to deliver these messages but since they are not written to disk they
will be lost in the case of a system crash or network failure.
Clearly with no disk IO involved these messages are much faster than persistent ones.

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

What is a Queue ? - notes

A Queue is a named object (up to 48 characters) which is defined with a queue
type.
Local Only queue type which can actually hold messages
Alias A queue name which 'points' to another queue
Remote A queue which 'points' to a queue on a remote machine
Model A template definition which when opened will create a temporary
local queue
Applications open queues, by name, and can either put or get messages to/from
the queue. Messages can be got from the queue either in FIFO order, by priority
or directly using a message identifier or correlation identifier.
As many applications as required can open a queue either for putting or for getting
making it easy to have single server responding to many clients or even n
servers responding to many clients.
A key feature of WebSphere MQ is its transaction support. Messages can be both
put and got from queues in a transaction. The transaction can be just local,
involving just messaging operations or global involving other resource managers
such as a database. A classic example, is an application which gets a
message, updates a database and sends a reply message all within a single
transaction. If there is a failure before the transaction commits, for example a
machine crash, both the database update and the received message will be
rolled back. On machine restart the request message will still be on the queue
allowing the application to reprocess the request.

What is a Queue Manager ?

Utilities
Command Server
Put Get Listener
Channel Initiator
Trigger Monitor
Windows Explorer
MQ API
Kernal
Local
Moving Queuing
Message

What is a Queue Manager - notes

A queue manager may - generally - be thought of as 3 components:
The Kernel is the part of the queue manager that understands how to implement the MQ
APIs. Given that the APIs are common across the queue manager family, it stands to
reason that the Kernel is mostly common code across the set of queue managers. (The
primary exception to this is the z/OS queue manager where the same functions are
implemented differently to support the same APIs).
The Local Queuing component is the part of the queue manager responsible for
interacting with the local operating system. It manages memory, the file system and any
operating system primitives such as timers, signals, etc. This component insulates the
Kernel from any considerations of how the underlying operating system provides
services and so enables the Kernel to be operating system independent.
The Message Moving component is responsible for interacting with other queue
managers and with MQI clients. For environments where all of the message queuing
activity is local to a system then this component is unused - though this is a very rare
case.
The message moving functions are provided by specialised MQ applications, called
Message Channel Agents.

What is a WebSphere MQ Client ?

Messaging Servers
OS/390, z/OS
Linux, zLinux
AIX
Windows XP, 2000
Solaris: Intel & SPARC
HP-UX
OS/400
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 …
…

What's a WebSphere MQ MQI Client? - notes
WebSphere MQ clients provide a low cost, low resource mechanism

to gain access to MQ facilities. The client provides a remote API
facility, allowing an WebSphere MQ application to run on a machine
that does not run a queue manager.
Each MQ API command is passed to a Server queue manager
where a proxy executes the required API command. The connection
between client and server is entirely synchronous providing an 'rpc-
like' mechanism - though NO regular (well-known) rpc mechanism is
used ! Also, the client machine does not own any MQ resources - all
resources are held by the Server machine. Thus, if local queuing
capability is required then a server (rather than a client) must be
used.

The MQ API
Program A
MQCONN MQOPEN MQGET MQBEGIN MQINQ

MQDISC MQCLOSE MQPUT MQBACK
MQSET
MQCONN(X) MQPUT1 MQCMIT
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, ...

Examples of how MQ queues can be used
‘Send and Forget’

Put Invoice-Q Get Invoice-Q
Program A Program B
Invoice-Q
Request / Response Target Queue
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.
'Send and Forget'

This style is one where there is no (direct) response required to a message.
The message/queuing layer will guarantee the arrival of the data without the
application having to solicit a response from the receiver.
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
Program A Program B Program C
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.
These various modes of interaction may be arbitrarily combined to

provide as complex/sophisticated topology as is necessary to support
a particular application. The loosely coupled nature of the message
queuing model makes it ideal for this style of interaction. Furthermore,
it makes it straightforward to develop applications in an iterative style.

Examples …Publish / Subscribe
Data C
Data
A
A
Pub/Sub D
Broker B
Data
B E
A,B
Subscription
B F
(re-) Publication

Examples…Publish/Subscribe - notes
In this environment, the receiving applications notify an intermediate broker

of their interest in particular sets of information. The receiving (or
subscribing) application provides a subject and a queue where messages
matching this subject may be delivered.
The sending (publishing) applications generate information, together with a
subject name, and sends the information to the broker. The broker contains
a matching service which determines the subscribing applications interested
in receiving this information.
Note that the publish/subscribe model provides for the situation where a
message may be published by an application using a subject which has no
subscribers. In this instance the message data is discarded.
There are many publish/subscribe products available in the marketplace
today. MQ publish/subscribe differentiates itself by providing support for the
publish/subscribe model and combining it with the exactly once delivery
model of MQ message/queuing.

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
•Multiple Queues with single image

•Failure isolation
•Scalable throughput
•MQI applications to exploit clusters
QSERVICE
transparently
•Definition through usage (MQOPEN)
•MQGet always local

Goals of Clustering - notes

Here we see a client putting to the 'QSERVICE' queue that is available in the
cluster on three server queue managers. A message is MQPUT by the client
and is delivered to *one* of the servers. It is processed there and a response
message sent to a ReplyToQueue on the client queue manager.
If a server becomes unavailable, then it is not sent any further messages and
all requests are routed to the servers which are still available. In addition, to
handle new workload, additional servers can be added online without
requiring the application take any action at all.
Both these behaviours are achieved by existing MQI applications, i.e. without
change. An applications need not be aware that it is operating in a cluster
environment.
We can see how a cluster can provide a highly available and scalable
message processing system. The administration point in processing is
MQOPEN as this is when a queue or queue manager is identified as being
required by an application.
Note that only one message is sent to a server; it is not replicated three
times, rather a specific server is chosen and the message sent there.
Also note that MQGET processing is still local, we are not extending MQGET
into the network.

Cross System Communication with WebSphere MQ
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
TCP/IP, APPC etc

Cross System Communication with WebSphere MQ - notes
In the diagram we see Program A sending messages to two other programs.
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.

WebSphere MQ Systems Management

Scripting
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 Systems Management - notes

One of the key operational components of any system is management. WebSphere MQ enables
systems management in a number of ways:
There are facilities provided by the MQ base to enable MQ resources to be managed. There are
'internal' utility programmes (for example, MQSC, the TSO interface for z/OS and the command line
interface for AS/400). There are also documented interfaces, most notably Programmable Command
Format messages which are PUT to a well known queue and are processed accordingly by the queue
manager.
WebSphere MQ provides events. These events are themselves MQ messages which are PUT (by the
queue manager) to well known queues and provide information on state changes for various queue
manager resources. The format of the event messages is documented. Text based message logs (and
Windows events) are also provided.
So, WebSphere MQ queue managers provide a set of documented interfaces to allow control and
configuration of resources and to inform external processes of state changes within the queue manager.
These interfaces may be used by any application program. Typically, this occurs in 3 ways:
There are MQ utilities which make use of these interfaces. Most notably, the MQ Explorer (provided for
Windows NT and 2000 environments) enables management and configuration of both local and remote
queue managers using PCF messages.
The majority of the established systems management vendors use the facilities described above to
provide MQ 'personalities' for their products.
Customers may write their own utilities to provide systems management capabilities within their
organisations. This style often makes use of the messaging APIs to utilise PCF and event messages.
Also scripting languages (most notably PERL) are used to provide systems management scripts for
WebSphere MQ and other environments.

WebSphere MQ Transactional Integration

• Message level selection for unit of work
• Single UoW active at any one time
• WebSphere MQ messages in a unit of work

• MQCMIT and MQBACK control the unit of work
• Messages and other resources in a unit of work

• Managed by a Transaction Manager
• WebSphere Application Server, z/OS; CICS, IMS, z/OS RRS
• Microsoft Transaction Server
• Any XA Transaction Manager
• Managed by WebSphere MQ
• WebSphere MQ is an XA Transaction Manager
• MQBEGIN, MQCMIT and MQBACK control the unit of work
WebSphere MQ Transactional Integration - notes
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

WebSphere MQ Security - notes
There are several aspects to WebSphere MQ security:

Control of WebSphere MQ commands
Access to MQ commands, like creating and starting queue managers, can
be controlled through operating system facilities and also by MQ facilities; it
is necessary to be in a particular authorisation group to be allowed to use
these commands.
Access to Queue Manager objects
There is an access control component that is provided by the MQ Queue
Manager, called the Object Authority Manager (OAM), which controls access
to Queue Manager objects, particularly queues. The OAM can control
access to resources at a very granular level, allowing access for different
actions, such as GET, PUT, INQ, SET, etc. This access is (generally) based
upon group memberships.
This security service is a pluggable component of MQ. Thus, if the OAM
does not meet the requirements of the environment it is possible to provide a
different (or additional) component. Note that the OAM is used for all queue
managers except for the z/OS queue manager which uses any SAF
compliant security manager.

WebSphere MQ Security – notes continued
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.

This page intentionally left blank

WebSphere MQ
& the Wider World

WebSphere MQ and the Wider World - notes
For a messaging engine to be really useful it should allow access to

the messages from many different environments. We have already
discussed MQs programming language and API support but what
about the environments.
The complexity of overall business applications is increasing every
year as more and more applications are linked together in some
way. WebSphere MQ dramatically reduces an individual applications
complexity by providing a consistent, reliable and transactional
method of communicating between applications from hundreds of
different environments.
We are now going to look briefly at where WebSphere MQ fits in the
Business Reference Architecture and also at some of the other
WebSphere Business Integration products that make up the portfolio

IBM Business Integration Reference Architecture
Model, design, development, test tools

Common Runtime Infrastructure
Monitoring Services
User Community
Interaction Application Information Process Integration
Services Services Services Services Services
Enterprise Service Bus
Application Access Services Data Access Services
Enterprise applications Enterprise data


WebSphere BI Modeler Model, design, development, test tools WebSphere Studio
Monitoring Services WebSphere BI Monitor
User Interaction Application Information Process Community

Services Services Services Services Integration
WebSphere Services
Process
Choreographer
WebSphere WebSphere DB2 Information WebSphere
WebSphere BI
Portal Server Application Server Integrator Business
Server
Integration
WebSphere BI
Connect
Server
WebSphere MQ Everyplace Foundation
Enterprise Service Bus
WebSphere MQ Web Services Gateway WebSphere BI Event/Message Broker

WebSphere BI Adapters DB2 Information Integrator

WebSphere MQ Everyplace
Customer
Relationship
Management (CRM)
Mobile workers WebSphere MQ

WebSphere
WebSphere MQ Event Broker
MQ Everyplace Supply chain
WebSphere Management (SCM)
MQ Integrator Broker
Retail stores
Enterprise resource
Planning (ERP)
WebSphere MQ Everyplace can extend your IT infrastructure to

Mobile workers and remote machines

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
Server EJB MDB

Foundation JMS
Adapter Repository
EJB
Servlet MDB BODs
Web JText
Service Configuration

WebSphere Business Integration Adapters - notes

There is little value in providing a business integration infrastructure without providing the ‘last mile’ in terms of access
to business applications and data. This is the task of this component. There are 3 separate sets of services that are
provided:
Adapters provide a set of capabilities for accessing business applications. These business applications generally fall
into one of two categories:
Custom Off The Shelf (COTS) applications are well known applications sold by vendors. As such, these applications
have well defined interfaces (usually!!) for accessing the services of each application environment.
Technology based adapters interact with business applications through the use of well known underlying
technologies such as files, databases, queues, etc.
Regardless of the type of adapter, there is a consistent infrastructure provided to enable business applications to be
hooked into the business integration environment with minimal invasion of the applications. One hooked into the
integration infrastructure, all of the components are available to provide integration with other application components.
Many of today’s applications are available only through so-called ‘green screen’ interfaces … 3270 and 5250
interfaces. IBM BI provides a set of services to enable access to these applications within the business integration
environment.
There are very basic facilities for re-purposing green screens to a web based interface and then there are more
programmatic capabilities available to enable programmed access and service based access to green screen based
applications.
Finally, there is a further set of data access components that are provided to enable access to z/OS based data. This
set of components complete the diagram of Information Services that was shown earlier and allow access to a very
wide spectrum of data types.

Adapters to accelerate deployment

WBI Adapters require implementation of WBI Server, WBI Brokers or WebSphere Application Server
Application Adapters Technology Adapters Mainframe Adapters
ƒAriba Buyer ƒACORD XML ƒADABAS
ƒCentricity Gateway ƒCOM ƒCICS
ƒClarify CRM ƒCORBA ƒDB2 Databases
ƒeMatrix ƒe-mail ƒIDMS Database
ƒESRI Spatial Database ƒEnterprise JavaBean (EJB) ƒIMS Transaction Manager
ƒIndusConnect Framework ƒExchange ƒIMS Database Manager
ƒi2 ƒFIX Protocol ƒNatural
ƒi2 Active Data Warehouse ƒHealthcare Data Protocols ƒVSAM
ƒJD Edwards OneWorld ƒHTTP
ƒManugistics Demand & Fulfillment
Management
ƒiSeries e-Business Adapters
ƒMaximo MEA
ƒJMS ƒTrading Partner Interchange
ƒMetaSolv Application ƒJText ƒiSoft Peer-to-Peer Agent
ƒmySAP.com ƒJDBC
ƒNightFire Applications ƒLotus Domino IBM WebSphere BI Adapters
ƒOracle Applications ƒSWIFT
support
ƒPeopleSoft ƒXML
ƒPortal Infranet ƒData Handler for XML ■ Multiple releases of the
ƒQAD MFG/PRO ƒData Handler for EDI application
ƒSAP Exchange Infrastructure ƒWeb Services
■ Multiple application
ƒSiebel eBusiness Applications ƒWebSphere BI Message Broker
ƒSpirent Applications
transactions types
ƒWebSphere MQ
ƒTelcordia Applications ƒWebSphere MQ Workflow ■ Frequent releases for
ƒWebSphere Commerce currency

WebSphere Business Integration Event Broker
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

WebSphere Business Integration Message Broker
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

WebSphere Business Integration Brokers
Event Broker and Message Broker enable disparate applications to be integrated

without wholesale changes.
Both point-to-point and publish subscribe architectures
Extends the messaging model
Acts as an intermediary for any-to-any application integration
Routing based on message content
Application connectivity using a variety of transports:

MQ
RealTime
Multicast
SCADA
MQe
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.

WebSphere Process Choreographer

and WebSphere MQ Workflow
•Multiple applications, systems or services can be

aggregated into a business process
•May involve automatic as well as human
interactive tasks
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

Representing the Choreography/Workflow

People assignments
determined by business rules
invoke
p1
invoke invoke
p2
invoke
Flow determined
by externalized
business rules

WebSphere Process Choreography and WebSphere MQ Workflow - notes
There are a number of services required to support business processes:
• 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.


WebSphere BI Modeler Model, design, development, test tools WebSphere Studio
Monitoring Services WebSphere BI Monitor
User Interaction Application Information Process Community

Services Services Services Services Integration
WebSphere Services
Process
Choreographer
WebSphere WebSphere DB2 Information WebSphere BI WebSphere
Portal Server Application Server Integrator Server Business
WebSphere BI Integration
Server Connect
Foundation
WebSphere MQ Everyplace Enterprise Service Bus
WebSphere MQ Web Services Gateway WebSphere BI Event/Message Broker

WebSphere BI Adapters DB2 Information Integrator

®
IBM Software Group
Thank You
© 2004 IBM Corporation

MQ Tech Notes

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MQ Tech Notes

Uploaded by

Copyright:

Available Formats

®

IBM Software Group

GSE Nordic Technical Conference

© 2004 IBM Corporation

© IBM Corporation 2004

• A single, multi-platform API

© IBM Corporation 2004

Messaging Fundamentals - notes

 First it must be totally reliable. A message put to an WebSphere MQ queue is as safe as

 Secondly it should be available everywhere

© IBM Corporation 2004

Messaging Fundamentals - Reducing Complexity

• Reliable, distributed computing

• WebSphere MQ eases the complexity

© IBM Corporation 2004

Messaging Fundamentals - Reducing Complexity notes

© IBM Corporation 2004

Message = Header + User Data

•Any sequence of bytes

© IBM Corporation 2004

What's a Message? - notes

A message in WebSphere MQ is merely a sequence of bytes in a buffer of a given

© IBM Corporation 2004

© IBM Corporation 2004

What is a Queue ? - notes

© IBM Corporation 2004

What is a Queue Manager ?

© IBM Corporation 2004

What is a Queue Manager - notes

© IBM Corporation 2004

What is a WebSphere MQ Client ?

© IBM Corporation 2004

What's a WebSphere MQ MQI Client? - notes

 WebSphere MQ clients provide a low cost, low resource mechanism

© IBM Corporation 2004

MQCONN MQOPEN MQGET MQBEGIN MQINQ

© IBM Corporation 2004

© IBM Corporation 2004

Examples of how MQ queues can be used

‘Send and Forget’

Request / Response Target Queue

© IBM Corporation 2004

'Send and Forget'

© IBM Corporation 2004

Program A Program B Program C

© IBM Corporation 2004

These various modes of interaction may be arbitrarily combined to

© IBM Corporation 2004

Examples …Publish / Subscribe

© IBM Corporation 2004

 In this environment, the receiving applications notify an intermediate broker

© IBM Corporation 2004

© IBM Corporation 2004

© IBM Corporation 2004

•Multiple Queues with single image

© IBM Corporation 2004

Goals of Clustering - notes

© IBM Corporation 2004

Cross System Communication with WebSphere MQ

TCP/IP, APPC etc

Cross System Communication with WebSphere MQ - notes

In the diagram we see Program A sending messages to two other programs.

First it must be totally reliable. A message put to an WebSphere MQ queue is as safe as

Secondly it should be available everywhere

WebSphere MQ clients provide a low cost, low resource mechanism

In this environment, the receiving applications notify an intermediate broker

There are several aspects to WebSphere MQ security:

For a messaging engine to be really useful it should allow access to

Event Broker and Message Broker enable disparate applications to be integrated

Application connectivity using a variety of transports: