© 2009 ibm corporation conference materials may not be reproduced in whole or in part without the...

© 2009 IBM CorporationConference materials may not be reproduced in whole or in part without the prior written permission of IBM.

M49: M49: Using IBM WebSphere Application ServerUsing IBM WebSphere Application Serverand IBM WebSphere MQ togetherand IBM WebSphere MQ together

Matt LemingMatt [email protected]@uk.ibm.com

WebSphere Technical Conference and Transaction & Messaging Technical Conference

© 2009 IBM Corporation2

AgendaAgenda

• Why are we here?• What options are available?• Choosing between them• How to do it



Why are we here?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”

…



The basics



WAS’ messaging WAS’ messaging in a slidein 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 MQ WebSphere MQ in a slidein 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



Service integration bus Service integration bus in a slidein 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”



Options



Options for accessing your WMQ backboneOptions 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



Option 1Option 1

WMQQMgr

ApplicationServer

Application Server

WMQQMgr

WMQQMgr

Application Application

WebSphere MQ as the JMS provider in WAS

WMQQMgr

Existing WMQapplication CICS

application

WAS

WMQ backbone

Applications connect directly into the WMQ backbone



WMQQMgr

Application Server

ApplicationServer

WMQQMgr

WMQQMgr

Application Application

MessagingEngine

SIBus for WAS application messaging,An SIBus interacts with WMQ to access the messaging backbone

SIBus

WMQ backbone

WAS


application

Messages flow between SIBus and WMQ where interactions with the WMQ backbone are necessary

ApplicationServer

MessagingEngine

Application

Option 2Option 2



WMQQMgr

Application Server

ApplicationServer

WMQQMgr

Application

SIBus for WAS-WAS application messaging,WMQ for WAS-‘other’ messaging

SIBus

WMQ backbone

WAS


application

WMQQMgr

Application Server

Application

MessagingEngine Application

MessagingEngine

Application

Option 3 Option 3



Just a simple matter of choosing…



‘‘Side by side’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) growing customer base limited tooling support

Separate product (c. 1993) 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



Just a simple matter of choosing…When accessing messages on WMQ queues in aWMQ backbone



Option 1: Option 1: WMQ as the JMS provider in WASWMQ 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



Option 2: Option 2: SIBus messaging systemSIBus 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



Just a simple matter of choosing…When starting with a JMS messaging provider



Option 1: Option 1: WMQ as the JMS provider in WASWMQ 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



Option 2: Option 2: SIBus messaging systemSIBus 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

A centrally managed, federated, configuration model Embedded high availability of the messaging resources using application server

clusters• Cons

Smaller customer base More limited support through external tooling



Option 2…. options!When accessing messages on WMQ queues in a WMQ backbone



How to achieve Option 2How to achieve Option 2

Two ways to connect to WMQ through SIBus: Asynchronous connectivity to WMQ Synchronous connectivity to WMQ



Asynchronous connectivity to WMQthrough the SIBus



Asynchronous connectivity to WMQAsynchronous connectivity to WMQWMQ-to-WMQWMQ-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

QueueManager

app

app

WMQ network

QueueManager



Asynchronous connectivity to WMQAsynchronous connectivity to WMQSIBus-to-SIBusSIBus-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

AppServer AppServer

ME

AppServer

ME

AppServer

ME

app

app

Bus

Bus

SIBus network



Asynchronous connectivity to WMQAsynchronous connectivity to WMQSIBus-to-WMQSIBus-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.

AppServer AppServer

MEapp

Bus

SIBus network

app

WMQ network

QueueManager

QueueManager



Asynchronous connectivity with WMQAsynchronous 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) Additional configuration Additional runtime management

SIBus network

WMQ network



Synchronous connectivity to WMQthrough the SIBus



Synchronous connectivity with WMQSynchronous 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

WMQ JMS client

AppServer

app

WMQ network

QueueManager

WAS config

JNDI

ConnectionFactory<QMgr location>

JMS Queue<WMQ queue name>

WMQ JMS



SIBus synchronous connectivity with WMQSIBus 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

AppServer

WMQ network

QueueManager

WAS config

SIBus config

WMQ bus member<QMgr location>

JNDI

SIBus queue<WMQ queue>

app

ME

ConnectionFactory<SIBus name>

JMS Queue<SIBus queue name>

SIBus JMS

WM

Q



SIBus synchronous connectivity with WMQSIBus 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

WMQ network

WAS config

SIBus config

JNDI



WMQ direct vs. SIBus asynchronous vs. SIBus synchronousWMQ direct vs. SIBus asynchronous vs. SIBus synchronous

• WMQ directSolution has the least moving parts when trying to access WMQ resourcesNot a seamless fit with WAS

• SIBus asynchronousFits well with the WMQ asynchronous networking principlesKeeps WAS application configuration within their comfort zoneIncreases latency between WAS applications and WMQ

• SIBus synchronousKeeps WAS application configuration within their comfort zone

Increases overall complexity when accessing WMQ resourcesReduces performance between WAS applications and WMQ

Don’t underestimate the importance of your current skill base when choosing your messaging provider



Putting this into practice….



Using WebSphere MQ asUsing WebSphere MQ asthe the JMS providerJMS provider



WMQ Connection FactoriesWMQ Connection Factories

• 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

Resources > JMS > Connection factories > [New]



WMQ DestinationsWMQ Destinations

• 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

Resources > JMS > Queues / Topics > [New]



WMQ Activation SpecificationsWMQ Activation Specifications

• 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.

Resources > JMS > Activation Specifications > [New]



ListenerListener PortsPorts

• 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 usefor connecting to WMQ

• Listener ports can only be defined at server scope.

• WAS V7 provides a wizard to migrate listener ports to activation specs

Servers > Server Types > WebSphere application servers > serverName > Message listener service > Listener ports > [New]



Using connectivity withUsing connectivity withWMQ via the SIBus WMQ via the SIBus



Using Using asynchronousasynchronous connectivity with connectivity withWMQ via the SIBus WMQ via the SIBus



Asynchronous connectivity to WMQAsynchronous connectivity to WMQ

• The point where WMQ and SIBus configurationand 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



Configuring a foreign bus connection in WAS V7Configuring a foreign bus connection in WAS V7

1. Decide which messaging enginewill own the link

2. Provide the WMQ specific details enter the details including the send/receiver channel details

Service integration > Buses > BusName > Foreign bus connections > [New]

3. (or 0) Configuring the equivalent sender and receiver channels on the WMQ queue manager




• 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 areassociated with a port, the WMQsender channel should point tothat port

• Secure inbound and outbound transport chains may be used tosecure the channels using SSL

Servers > Server Types > WebSphere application servers > serverName > Transport Chain




• 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

System integration > buses > BusName > Foreign bus connection > name > WebSphere MQ Links

The current number of messages waiting to be transmitted

The overall state of the link

The messages can be viewed, deleted or moved to an exception destination

Indoubt batches of messages can be detected and resolved

The link can be started and stopped



Asynchronous connectivity to WMQAsynchronous connectivity to WMQTranslation guideTranslation 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



Failover of a WMQ LinkFailover 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

AppServer

ME

SIBus network

WMQ network

AppServer

ME

Cluster

QueueManager AppServer

ME

SIBus network

WMQ network

AppServer

ME

Cluster

QueueManager

Link fails over along with the ME

Server running the ME terminates

Channels reconnect to the alternative location using MR01

MR

01

MR

01

MR01 configured for multiple ME locations

Cluster bus member configured to allow MEs to failover to alternative servers



Using Using synchronoussynchronous connectivity with connectivity withWMQ via the SIBus WMQ via the SIBus



• 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 E.g. identify the WMQ server connection channel of the queue manager

Servers > Server Types > WebSphere MQ servers > [New]

Second, that WebSphere MQ Server is made a member of the SIBus 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]

Synchronous connectivity to WMQSynchronous connectivity to WMQ



SummarySummary

• Why were we here• What options are available• Choosing between then• How to do it



Further InformationFurther 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://www-01.ibm.com/support/docview.wss?

rs=171&context=SSFKSJ&dc=DB520&uid=swg21266535&loc=en_US&cs=UTF-8&lang=en&rss=ct171websphere• IBM RedBooks

http://www.redbooks.ibm.comWebSphere Application Server V7: Messaging Administration Guide SG24-7770-00WebSphere Application Server V7: Concepts, Planning and Design, SG24-7708-00WebSphere 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-00WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392-00WebSphere Application Server V6.1 Security Handbook, SG24-6316-01 WebSphere Application Server V6.1: Technical Overview, REDP-4191-00WebSphere Application Server V6.1: Planning and Design, SG24-7305-00WebSphere 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 - WASV7http://www.ibm.com/developerworks/websphere/techjournal/0601_ratnasinghe/0601_ratnasinghe.html - Securityhttp://www.ibm.com/developerworks/websphere/techjournal/0601_smithson/0601_smithson.html - Security

© 2009 ibm corporation conference materials may not be reproduced in whole or in part without the...

Documents

websphere technical

jms messaging providers

jms provider jms applications

messaging backbone

ibm websphere mq

default messaging provider

embedded messaging provider

cluster messaging applications