Transcript 1833 - WebSphere User Group UK

M49: Using IBM WebSphere Application Server
and IBM WebSphere MQ together
Matt Leming
[email protected]
© 2009 IBM Corporation
Conference materials may not be reproduced in whole or in part without the prior written permission of IBM.
Agenda
•
•
•
•
Why are we here?
What options are available?
Choosing between them
How to do it
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
2
Why are we here?
• Reasons for being here
“We currently use WebSphere MQ as our messaging backbone, we need
to access that backbone from our WebSphere Application Server system”
“We’re going to be using messaging in WebSphere Application Server,
we’re trying to choose a messaging provider and are thinking that
WebSphere MQ might fit the bill”
…
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
3
The basics
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
4
WAS’ messaging in a slide
• WebSphere Application Server (WAS) is a JEE application server, JEE includes
support for asynchronous messaging using JMS (Java Message Service)
• Allows Java application interactions to be loosely coupled

Temporal and transactional decoupling of applications
• A standardised programming interface


Implemented by a JMS provider
JMS applications can be coded to be ignorant of the underlying JMS provider
 Provider specific configuration, such as how to connect to a messaging provider, is contained
within JMS resources held in JNDI, defined at application deployment time

JMS is not a transport protocol
 No standardised ability to couple different JMS providers
• JMS Supports two messaging models


Point-to-point – using queues
Publish/subscribe – using topics
• WebSphere Application Server provides first class support for two JMS
messaging providers

An embedded messaging provider, the Default Messaging provider (or Service
Integration Bus)
 WebSphere MQ as an external messaging provider
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
5
WebSphere MQ in a slide
• WebSphere MQ (WMQ)




WMQ is IBM’s flagship asynchronous messaging product
Queues are managed by queue managers
Queue Managers can be connected together to form a network, or cluster
Messaging applications connect to queue managers to access queues
 Applications can send messages to any queue in the network from their queue
manager
 Applications can receive messages from queues on their queue manager

WMQ supports the point-to-point and publish/subscribe messaging models
• WMQ as the JMS provider in WAS


WMQ supports the JMS programming interface for Java applications.
Applications in WAS can use JMS to interact with WMQ queues (and topics)
 WAS V6 and V6.1 contains a WMQ JMS client to enable this
 WAS V7 contains the WMQ V7 JCA resource adaptor

WAS applications connect to a queue manager using:
 Bindings – when application and queue manager are on the same server
 Client – when application server and queue manager are on separate, networked,
servers - using a TCP/IP socket
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
6
Service integration bus in a slide
• Service Integration Bus (SIBus)

SIBus is a native component of WAS, forming the asynchronous messaging
platform for application server based products
 Logically:
 A bus is a logical entity that contains destinations (e.g. queues/topic spaces)
 Messaging applications connect to the bus to access the destinations
 A bus is location transparent, all destinations and their messages are available from
anywhere in the bus

Physically:







A WAS cell contains application servers, or clusters of application servers
These can optionally be made a member of a bus
Destinations are assigned to bus members
Bus members run messaging engines within the application server JVMs
Messaging engines manage the runtime and persistent state of messages in the bus
Messaging applications form a connection to a messaging engine
Messages are routed from any messaging engine in the bus to the application
• SIBus as the JMS provider in WAS

SIBus supports the JMS programming interface for Java applications.
 Natively supporting both point-to-point and publish/subscribe messaging models

SIBus is the default JMS provider in WAS – hence the “Default messaging
provider”
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
8
Options
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
9
Options for accessing your WMQ backbone
•
Three key options
1.
Use WMQ as the JMS provider in WAS
2.
Use the service integration bus in WAS and connect that messaging
system with your WMQ backbone
3.
Use SIBus for intra-WAS messaging, use WMQ for inter-system
messaging
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
10
Option 1
WebSphere MQ as the JMS provider in WAS
WAS
Application
Server
Applications connect
directly into the
WMQ backbone
Application
Server
Application
Application
WMQ
QMgr
WMQ
QMgr
Existing WMQ
application
WMQ
QMgr
CICS
application
WMQ
QMgr
WMQ backbone
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
11
Option 2
SIBus for WAS application messaging,
An SIBus interacts with WMQ to access the messaging backbone
WAS
Application
Server
Application
Server
Application
Server
Application
Application
Application
Messaging
Engine
Messaging
Engine
SIBus
Messages flow between
SIBus and WMQ where
interactions with the WMQ
backbone are necessary
WMQ backbone
WMQ
QMgr
Existing WMQ
application
WMQ
QMgr
WMQ
QMgr
CICS
application
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
12
Option 3
SIBus for WAS-WAS application messaging,
WMQ for WAS-‘other’ messaging
WAS
Application
Server
Application
Server
Application
Server
Application
Application
Application
Messaging
Engine
Messaging
Engine
Application
SIBus
WMQ backbone
WMQ
QMgr
Existing WMQ
application
WMQ
QMgr
WMQ
QMgr
CICS
application
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
13
Just a simple matter of choosing…
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
14
‘Side by side’
Service integration bus
WebSphere MQ
Fully Integrated with WAS runtime,
configuration and console
Own runtime, admin domain and explorer
interface
Included with WAS (c. 2005)
Separate product (c. 1993)
growing customer base
limited tooling support
huge install base
widespread tooling support
Underpins WESB, WPS, …
Underpins WMB, FTE, …
Provides point-point & publish-subscribe messaging models
Supports JMS
Supports multiple programming languages,
including JMS
Optimised for WAS-based messaging
performance
Optimised for heterogeneous messaging
performance
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
15
Just a simple matter of choosing…
When accessing messages on WMQ queues in a
WMQ backbone
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
16
Option 1: WMQ as the JMS provider in WAS
When accessing messages on WMQ queues in a WMQ backbone:
• Pros

The most direct route to WMQ queues
 Best performing way to get messages on and off a WMQ queue
 Least moving parts




Least things to configure
Least places where things can go wrong
Simplest problem determination
A single messaging system to maintain rather than two
• Cons

WAS application deployment depends on knowledge of WMQ topology
 E.g. the WMQ queue location is required when connecting applications


WAS applications dependent on two systems being simultaneously available
(application servers and queue managers)
Can be complex to exploit WAS and WMQ
high availability and scalability features
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
17
Option 2: SIBus messaging system
When sending or receiving messages to or from a WMQ backbone:
• Pros

Messaging runtime is embedded into the same runtime as the applications
 Probably better performing way to get messages produced by WAS applications into
WAS applications

Ability to asynchronously queue messages in the WAS system while connectivity
with the WMQ backbone is unavailable
 JMS resource configuration relates to WAS-defined SIBus configuration objects
 WMQ-aware configuration in WAS is minimised

Applications can be unaware of actual queue locations
• Cons


Two messaging systems to configure and maintain
Additional complexity in configuring interactions
between SIBus and WMQ
 Additional problem determination may be required
to resolve issues

Performance overhead when passing from one
messaging system to another
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
18
Just a simple matter of choosing…
When starting with a JMS messaging provider
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
19
Option 1: WMQ as the JMS provider in WAS
When used as the messaging system for WAS alone:
• Pros

‘Industry standard’
 Proven to be robust and scalable in very large messaging deployments
 Extensive knowledge base
• Cons

Added complexity of two different configuration and monitoring systems
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
20
Option 2: SIBus messaging system
When used as the messaging system for WAS alone:
• Pros

Messaging configuration is completely integrated into the WAS configuration
model
 SIBus configuration and runtime concepts are closer aligned with the WAS configuration
and runtime concepts

SIBus exploits many WAS Network Deployment features
• Cons


 A centrally managed, federated, configuration model
 Embedded high availability of the messaging resources using application server
clusters
Smaller customer base
More limited support through external tooling
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
21
Option 2…. options!
When accessing messages on WMQ queues in a WMQ
backbone
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
22
How to achieve Option 2
 Two ways to connect to WMQ through
 Asynchronous connectivity to WMQ
 Synchronous connectivity to WMQ
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
SIBus:
23
Asynchronous connectivity to WMQ
through the SIBus
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
25
Asynchronous connectivity to WMQ
WMQ-to-WMQ
• WMQ queue managers can be networked together, allowing messages to
be asynchronously sent from applications connected to one queue
manager to queues located on other queue managers



Store and forward of routed messages
Network connections using channels
Message routing using remote queue managers and remote queues
WMQ network
app
Queue
Manager
Queue
Manager
app
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
26
Asynchronous connectivity to WMQ
SIBus-to-SIBus
• SIBuses, which may be a network of bus members, can be
networked together, allowing messages to be asynchronously sent
from one SIBus to queues located on other SIBuses


Allows SIBus messaging to span multiple WAS ND cells
Store and forward of routed messages
 Network connections using links
 Message routing using foreign buses and alias destinations
SIBus network
Bus
AppServer
app
AppServer
ME
Bus
AppServer
AppServer
ME
app
ME
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
27
Asynchronous connectivity to WMQ
SIBus-to-WMQ
• So, it’s just a matter of joining the two together…

The WMQ queue manager sees the connected SIBus as another remote queue
manager, connected via a sender and receiver channel, allowing messages to be
routed through to the SIBus as for any other connected queue manager.
 The SIBus sees the connected queue manager as another bus, connected via a
foreign bus connection, allowing messages to be routed through to the queue
manager as for any other connected bus.
• Messaging applications on either side are not aware of the transition.
Bus
AppServer
AppServer
WMQ network
app
ME
Queue
Manager
Queue
Manager
SIBus network
app
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
28
Asynchronous connectivity with WMQ
• What does this add?

Ability to asynchronously queue messages in the WAS system while
connectivity with the WMQ backbone is unavailable
 All JMS resources defined are SIBus resources, referring to SIBus
objects.
 Fine grain authorisation access to those resources can be managed
using SIBus authorisation, within the WAS configuration domain.
 WMQ configuration is restricted to the SIBus configuration domain.
 WMQ topology is hidden from JMS resource configuration
• What does it cost?


Extra latency
Only able to send messages to WMQ queues,
unable to receive from WMQ queues
 WMQ applications must send to queues located
in the SIBus (using remote WMQ queues)


WMQ network
Additional configuration
Additional runtime management
SIBus network
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
30
Synchronous connectivity to WMQ
through the SIBus
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
31
Synchronous connectivity with WMQ
• When WMQ is the JMS provider in WAS, a JMS application will connect
directly to a queue manager

This requires a WMQ JMS ConnectionFactory, defining where the queue
manager is and how to connect to it.
 The embedded WMQ JMS client in WAS is then used to synchronously connect
to the queue manager.
 The application will also require a WMQ JMS Queue which defines the actual
queue located on that queue manager.
 This allows synchronous style messaging with WMQ
WAS config
JNDI
WMQ network
AppServer
ConnectionFactory
<QMgr location>
app
WMQ
JMS
client
WMQ
JMS
Queue
Manager
JMS Queue
<WMQ queue name>
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
32
SIBus synchronous connectivity with WMQ
• It is possible to insert the SIBus runtime between the application and the queue
manager, such that the JMS application actually connects to the SIBus runtime and the
bus manages the synchronous connection to a queue manager when required.




This requires an SIBus JMS ConnectionFactory, defining which bus to connect to, and an
SIBus JMS Queue, defining which SIBus queue to send or receive messages from.
The configuration detailing which queues are available on which queue managers, and how
to connect to those queue managers is contained in the SIBus configuration.
A connection will then be made to a messaging engine in the bus, which will then make a
synchronous connection to the correct queue manager.
This allows synchronous style messaging with WMQ
JNDI
WAS config
ConnectionFactory
<SIBus name>
WMQ network
AppServer
JMS Queue
<SIBus queue name>
app
SIBus JMS
SIBus config
<QMgr location>
ME
WMQ
WMQ bus member
Queue
Manager
SIBus queue
<WMQ queue>
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
33
SIBus synchronous connectivity with WMQ
• What does this add?

All JMS resources defined are SIBus resources, referring to SIBus
objects within the WAS configuration domain.
 WMQ configuration is restricted to the SIBus configuration domain.

WMQ shared queue on z/OS can be fully utilised from WAS
 Supports transaction recovery across multiple members of the queue
sharing group, enabling full shared queue workload balancing and high
availability.
• What does it cost?



Extra code path, slower performance
Additional overall configuration complexity
Additional runtime management
JNDI
WAS config
WMQ network
SIBus config
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
35
WMQ direct vs. SIBus asynchronous vs. SIBus synchronous
• WMQ direct
Solution has the least moving parts when trying to access WMQ
resources
Not a seamless fit with WAS
• SIBus asynchronous
Fits well with the WMQ asynchronous networking principles
Keeps WAS application configuration within their comfort zone
Increases latency between WAS applications and WMQ
• SIBus synchronous
Keeps WAS application configuration within their comfort zone
Increases overall complexity when accessing WMQ resources
Reduces performance between WAS applications and WMQ
Don’t underestimate the importance of your current skill base when choosing your messaging provider
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
36
Putting this into practice….
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
38
Using WebSphere MQ as
the JMS provider
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
39
WMQ Connection Factories
Resources > JMS > Connection factories > [New]
• Specify how an application connects
to a WMQ queue manager
• Typically requires:

Queue manager name

Hostname and port

Channel name

Other parameters such as:
 Transport type (client or bindings)
 Use of SSL
• WAS V7 allows the identification of a
WMQ client channel definition table
(CCDT) URL

This removes the need for most of the above
configuration
 Prior to V7, a CCDT can be specified through
custom properties
• WAS V7 added the option to try
‘bindings, then client’ as a transport
type
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
40
WMQ Destinations
Resources > JMS > Queues / Topics > [New]
• Defines references to the resources in WMQ that a JMS application will use

The WMQ resources must be created using WMQ administration
• Queues

Identifies the actual queue
in WMQ
 Can be used to set properties
such as persistence,
priority, etc.
• Topics

Defines the WMQ
publish/subscribe properties
 Can include details of a
durable subscription
 Requires knowledge of WMQ
pubsub broker configuration
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
41
WMQ Activation Specifications
Resources > JMS > Activation Specifications > [New]
• Message-driven beans (MDBs) are a special
class of EJB, they enable JEE applications to
asynchronously process messages, with WAS
managing the transactionality and concurrency
of the application.
• Activation specs are the standardised way of
defining and activating an MDB
• The WebSphere MQ messaging provider in
WAS V7 adds support for activation specs
• Activation specs combine the configuration of
connectivity, the JMS destination to be
processed and the runtime characteristics of
the MDB itself
• Activation specs can be defined at all WAS
configuration scopes, as can be done for
ConnectionFactories and Destinations.
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
42
Listener Ports
Servers > Server Types > WebSphere application servers > serverName > Message listener service > Listener ports > [New]
• Prior to V7, activation specifications are not available when using WMQ. Instead,
MDBs are enabled by an application server’s message listener service and its
associated listener ports
• Just like an activation spec, a listener port is bound to the JMS destination that an
MDB wishes to receive messages from

It also identifies a ConnectionFactory to use
for connecting to WMQ
• Listener ports can only be defined at
server scope.
• WAS V7 provides a wizard to migrate
listener ports to activation specs
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
44
Using connectivity with
WMQ via the SIBus
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
45
Using asynchronous connectivity with
WMQ via the SIBus
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
46
Asynchronous connectivity to WMQ
• The point where WMQ and SIBus configuration
and runtime come together is within the SIBus’
WebSphere MQ link

Prior to V7, two separate pieces of configuration
are required
 One foreign bus – defined on a bus
 One WebSphere MQ link – defined on a messaging engine

V7 brings these together under the umbrella of a foreign bus connection, and
adds a wizard to take you through its complete configuration

A WebSphere MQ Link can be further subdivided into an WMQ link sender and
an WMQ link receiver (surprisingly similar to WMQ sender and receiver
channels!), which require:
 Channel names
 Queue manager location (TCP/IP address and port)
 Security settings
• The link runs in a single messaging engine
• The link has access to all resources in the bus for incoming messages, and
all members of the bus have access to the link for outgoing messages
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
47
Configuring a foreign bus connection in WAS V7
Service integration > Buses > BusName > Foreign bus connections > [New]
1. Decide which messaging engine
will own the link
2. Provide the WMQ specific details
enter the details including the send/receiver channel details
3. (or 0) Configuring the equivalent sender and receiver
channels on the WMQ queue manager
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
49
Asynchronous connectivity to WMQ
Servers > Server Types > WebSphere application servers > serverName > Transport Chain
• Just as a WMQ receiver channel requires an active channel listener on the
queue manager to enable it, an SIBus WMQ link receiver requires an
enabled inbound transport chain on the application servers that the link may
run on

The InboundBasicMQLink and InboundSecureMQLink transport chains are
automatically enabled on such servers
 Inbound transport chains are
associated with a port, the WMQ
sender channel should point to
that port
• Secure inbound and outbound
transport chains may be used to
secure the channels using SSL
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
50
Asynchronous connectivity to WMQ
System integration > buses > BusName > Foreign bus connection > name > WebSphere MQ Links
• WMQ stores messages on an XMITQ prior to sending them down a sender
channel. Similarly, SIBus stores messages on a Sender channel transmitter

WAS V7 added direct administration of these transmitters, allowing viewing and
management of messages currently awaiting transmission on the transmitter
The overall state of the link
The current number of messages
waiting to be transmitted
Indoubt batches of messages can
be detected and resolved
The link can be started and
stopped
The messages can be
viewed, deleted or moved to
an exception destination
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
53
Asynchronous connectivity to WMQ
Translation guide
Below is an approximate mapping between things that do similar jobs in SIBus and WMQ
when connecting an SIBus to a WMQ queue manager network

There is actually considerable overlap between certain objects, for example a WAS inbound transport
chain and a WMQ channel listener both listen for incoming traffic on a TCP/IP port, but the transport chain
can also contain the SSL configuration for a link, where as that would be configured on a channel in
WMQ.
Role
SIBus
WMQ
Addressing resources in another
messaging system directly
Foreign bus
Remote queue manager
Addressing specific queues in another
messaging system
Alias destination
Remote queue
Configuration and status for sending
messages to another system
WMQ link sender
+ runtime
Sender channel
+ channel status
Configuration and status for receiving
messages from another system
WMQ link receiver
+ runtime
Receiver channel
+ channel status
Place for storing messages prior to
transmission
Sender channel transmitters
XMITQ
Listening on a TCP/IP port for incoming
communication from another system
Inbound transport chain
Channel listener
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
55
Failover of a WMQ Link
• If the messaging engine is made highly available across a WAS cluster the
link will also be made highly available on the WAS side

The ME, along with the link, is able to run on different application servers (with
different TCP/IP addresses)
 WMQ requires an additional support pack, MR01, to enable this function
Cluster
AppServer
Cluster bus member
configured to allow MEs to
failover to alternative servers
WMQ network
Server running the
ME terminates
ME
AppServer
MR01
Cluster
Queue
Manager
AppServer
WMQ network
ME
AppServer
SIBus network
MR01 configured for
multiple ME locations
MR01
ME
Queue
Manager
ME
Link fails over
along with the ME
SIBus network
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
Channels reconnect to
the alternative location
using MR01
56
Using synchronous connectivity with
WMQ via the SIBus
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
58
Synchronous connectivity to WMQ
• Configuring synchronous connectivity with WMQ through SIBus is a
three stage process

First, a WebSphere MQ Server is required
 This defines which queue manager or queue sharing group (QSG) is to be connected to and
how to achieve it


Second, that WebSphere MQ Server is made a member of the SIBus


 E.g. identify the WMQ server connection channel of the queue manager
Servers > Server Types > WebSphere MQ servers > [New]
Service integration > Buses > busName > Bus members > [Add]
Third, An SIBus queue destination is created which identifies a WMQ queue on the
configured queue manager or QSG bus member.
 This does not create a queue in WMQ, it simply references an existing queue from the SIBus
 This enables producing or consuming applications connected to the SIBus to use the queue

Service integration > Buses > busName > Destinations > [New]
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
59
Summary
•
•
•
•
Why were we here
What options are available
Choosing between then
How to do it
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
61
Further Information
•
•
•
•
WAS product information
 http://www-306.ibm.com/software/webservers/appserv/was/
WAS Info Center
 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp
 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
Using WebSphere MQ Java Interfaces in J2EE/JEE Environments
 http://www01.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&dc=DB520&uid=swg21266535&loc=en_US&cs=UTF8&lang=en&rss=ct171websphere
IBM RedBooks
 http://www.redbooks.ibm.com
WebSphere Application Server V7: Messaging Administration Guide SG24-7770-00
WebSphere Application Server V7: Concepts, Planning and Design, SG24-7708-00
WebSphere Application Server V7: Technical Overview, REDP-4482-00
WebSphere Application Server V6.1: JMS Problem Determination, REDP-4330-00
WebSphere Application Server V6.1: System Management & Configuration, SG24-7304-00
WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392-00
WebSphere Application Server V6.1 Security Handbook, SG24-6316-01
WebSphere Application Server V6.1: Technical Overview, REDP-4191-00
WebSphere Application Server V6.1: Planning and Design, SG24-7305-00
WebSphere Application Server V6.1: Installation Problem Determination, REDP-4305-00
•
IBM developerWorks
 http://www.ibm.com/developerworks
 (Searching on “Service Integration Bus” returns a number of interesting articles)
http://www.ibm.com/developerworks/websphere/techjournal/0901_leming/0901_leming.html - WASV7
http://www.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html - Security
http://www.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html - Security
WebSphere Technical Conference and
Transaction & Messaging Technical Conference
© 2009 IBM Corporation
62