Introduction to WebSphere Message Broker V6.1 on z/Linux

IBM® WebSphere® Message Broker (hereafter called Message Broker) helps you connect the pieces of your enterprise architecture, for both application integration and for creating an Enterprise Service Bus (ESB) to support a Service Oriented Architecture (SOA). This article discusses the benefits of Message Broker V6.1 on z/Linux, and describes common configurations for z/Linux.

Message Broker V6.1 on z/Linux is a 64-bit offering that can only run on 64-bit z/Linux images. As on all supported platforms, all Message Broker run-time components are available, with one exception -- the Toolkit. Therefore you need an Intel® Linux® or Microsoft® Windows® platform on which to install the Toolkit in order to do administration tasks. For more information, see WebSphere Message Broker system requirements.

Message Broker on z/Linux provides all of the features available on the other supported platforms. You can develop message flows and message sets on either Intel Linux or Microsoft Windows, and deploy the generated Message Broker artifacts to the z/Linux run time without any changes.

Introduction to z/Linux

z/Linux is simply the Linux operating system running on IBM System z™. The two most popular enterprise distributions are provided by SuSE and Red Hat, and Message Broker V6.1 is fully supported on both. z/Linux is available in both 31-bit and 64-bit versions.

To determine whether your z/Linux image is 31-bit or 64-bit, run the following command from a shell prompt: uname –m. If your image is 31-bit, the response will be s390. If your image is 64-bit, the response will be s390x. You must ensure that the response is the latter if you wish to use Message Broker V6.1.

Why run Message Broker on z/Linux?

This section describes the advantages of running Message Broker on z/Linux. Integrated Facilities for Linux (IFL) and HiperSockets™ mean that z/Linux provides a cost effective, flexible, and high-performance communications platform for Message Broker.

Integrated Facility for Linux (IFL)

IFLs are z/Series processors dedicated to running z/Linux. They cost less than standard general-purpose processors and thus provide a cost-effective expansion of System z to exploit spare hardware capacity. IFLs can run z/VM or can be partitioned into LPARs, depending on your needs, as shown below in Figure 1. This flexibility lets you easily create and IPL additional z/Linux images as your business requirements change. To further enhance the value of this approach, System z architecture lets you reassign resources as needed, enabling you to consolidate and centrally manage Linux resources on proven hardware.

HiperSockets

HiperSockets provide high-speed TCP/IP connectivity within a central processor complex, eliminating the need for any physical cabling or external networking connection between servers running in different LPARs. Communication is through the system memory of the processor, with servers connected to form a "internal LAN," providing enhanced communications performance within the processor complex.

z/Linux can take advantage of HiperSocket TCP/IP connections. Therefore, you can configure Message Broker nodes that use TCP/IP-based technologies such as MQ or HTTP to use high speed communications to other TCP/IP-enabled technologies within the processor complex, including z/OS subsystems and other z/Linux images. For example, you can have the Message Broker queue manager running on z/Linux, and connect to another queue manager running on z/OS using MQ channels, which use HiperSockets.

Performance

If you currently use an earlier version of Message Broker, such as V6, you should review the performance report for V6.1. Improving the performance of the Message Broker runtime has been a focus for V6.1, with significant improvements for XML processing, XSLT transformations, XMLNSC opaque parsing and XMLNSC validation. For details, see WebSphere MQ Family - Performance Reports.

Configuring Message Broker V6.1 on z/Linux

Prerequisites

Message Broker can run only on 64-bit z/Linux images. Supported 64-bit z/Linux operating systems include:

• Red Hat Enterprise Linux AS 4.0
• Red Hat Enterprise Linux AS 5.0
• SUSE Linux Enterprise Server (SLES) 9
• SUSE Linux Enterprise Server (SLES) 10

In addition, Message Broker has a dependency on both WebSphere MQ and a database. When installing WebSphere MQ, ensure that you install the 64-bit version. Message Broker V6 required that a DB2® database, but Message Broker V6.1 supports both DB2 and Oracle. The following database versions are supported for this purpose:

• DB2 V8.2
• DB2 V9.1
• Oracle Database 9i R2
• Oracle Database 10g R1 and R2

Support for databases may change, so you should check the official product system requirements before deciding upon a specific setup.

If you use SUSE Linux Enterprise Server (SLES) 10, you will require WebSphere MQ V6.0.2.0 or later.

Configuring Message Broker V6.1 for use with DB2

If you wish to configure Message Broker to use DB2 for its database, you can host DB2 on the same image or on a different image from Message Broker.

The configuration in Figure 2 is a standard, single image Message Broker setup that requires a DB2 database and a queue manager to be created, as described in the Message Broker documentation. Those familiar with Message Broker V6 may be aware that such a setup on a single 64-bit z/Linux installation was not possible because of the interaction between the 31-bit Message Broker and the 64-bit DB2. Now that Message Broker is 64-bit this is no longer an issue.

You may want to host the broker database on a different image for manageability reasons or because you are migrating from a similar setup used with Message Broker V6. An example of how to do this is shown in Figure 3, where RTCL refers to the DB2 runtime client:

In such a setup you must define to the runtime client a remote database definition. For information on how to do this, see the DB2 documentation.

Now that Message Broker supports databases other than just DB2, it primarily uses ODBC to connect to databases (a couple of the available nodes use JDBC). Therefore you need to set up the ODBC definitions before Message Broker can interact with DB2. This step was not previously required on z/Linux.

Configuring Message Broker V6.1 for use with Oracle

The Oracle database is accessed over TCP/IP and as such can be installed on the same, or a different, image. Unlike with DB2, you do not require a client to be installed on the same image as Message Broker if you choose to host the database elsewhere.

As with DB2, you need to set up the ODBC definitions before Message Broker can interact with Oracle.

Configuring your ODBC definitions

Message Broker uses ODBC to connect to its databases, so you need to configure ODBC definitions before accessing your databases. On z/Linux, this step was not required for Message Broker V6. ODBC definitions are specified in the file odbc64.ini. A sample template for this file is at <install dir>/ODBC64/V5.2/odbc64.ini. Copy this file to the location of your choice, such as /var/mqsi/odbc/odbc64.ini, and tailor it as necessary. First, tailor the mandatory information stanza. For example:

[ODBC]
# To turn on ODBC trace set Trace=1
Trace=0
TraceFile/tmp/odbctrace64.out
TraceDll=/opt/ibm/mqsi/6.1/ODBC64/V5.2/lib/odbctrac.so
InstallDir=/opt/ibm/mqsi/6.1/ODBC64/V5.2
UseCursorLib=0
IANAAppCodePage=4
UNICODE=UTF-8

If you wish to add a definition for a DB2 database, use the DB2DB stanza as a template. For example:

[MQSIBKDB]
DRIVER=libdb2Wrapper.so
Description=MQSIBKDB DB2 ODBC Database
Database=MQSIBKDB

You should also add an entry in the ODBC Data Sources stanza, such as:

MQSIBKDB=IBM DB2 ODBC Driver

Similarly if you wish to add a definition for a Oracle database you can use the ORACLEDB stanza as a template. For example:

[MQSIBKDB]
Driver=/opt/ibm/mqsi/6.1/ODBC64/V5.2/lib/UKora22.so
Description=DataDirect 5.2 64bit Oracle Wire Protocol
HostName=myoraclehost
PortNumber=1521
SID=mysid
CatalogOptions=0
EnableStaticCursorsForLongData=0
ApplicationUsingThreads=1
EnableDescribeParam=1
OptimizePrepare=1
WorkArounds=536870912
ProcedureRetResults=1
ColumnSizeAsCharacter=1

You should also add an entry in the ODBC Data Sources stanza, such as:

MQSIBKDB=DataDirect 5.2 64bit Oracle Wire Protocol

When editing this file, ensure that no two stanzas have the same name. For DB2 databases, the name of the ODBC data source (stanza) is the name of the DB2 database alias, but for Oracle data source definitions, it does not have to be the name of the Oracle SID (or Oracle TCP/IP listener service name).

When identifying a data source to Message Broker, for example via the –n flag to mqsicreatebroker, you should specify the name of the ODBC stanza.

Once you have created this file, you need to tell Message Broker to read this file for the definitions, by setting the ODBCINI environment variable in your shell. For example:

export ODBCINI=/var/mqsi/odbc/odbc64.ini

If you do not set this environment variable you will encounter errors when attempting to run a command that requires access to a data source. To avoid these errors, either add it to your profile, or create a user profile for use with Message Broker that will be run automatically when you source the mqsiprofile script. You can do this by creating a user profile containing this command under /var/mqsi/common/profiles.

Configuring Message Broker for coordinated transactions (XA)

Message Broker can be configured to use coordinated transactions (XA) by means of coordinated message flows. A coordinated message flow ensures that all updates to protected resources, such as MQ messages and data in a database, are all committed or all rolled back together within a single transaction.

Transaction coordination of message flows on z/Linux is provided by WebSphere MQ. As a result, you need to configure the broker’s queue manager to act as a coordinator for the databases that you wish to participate. To do this, define a XAResourceManager stanza for each database in the WebSphere MQ queue manager qm.ini file. If your message flow references message dictionaries or contains publication nodes, you must ensure that the broker’s internal database also has a XAResourceManager stanza in the WebSphere MQ queue manager qm.ini file.

The stanza that you add in to this file is different depending on the type database that you are using. You will need a stanza for each data source that is to be transaction coordinated.

An example stanza for DB2 is shown below, where:

• MyDataSource -- name of the DB2 database alias to which you want to connect
• MyUserId -- user name with which you want to connect to the data source
• MyPassword -- password associated with the user name

XAResourceManager:
  Name=MyDataSource
  SwitchFile=db2swit
  XAOpenString=db=MyDataSource,uid=MyUserId,pwd=MyPassword,toc=t
  XACloseString=
  ThreadOfControl=THREAD

Similarly, an example stanza for Oracle is shown below, where:

• MyDataSource -- name of the ODBC data source name to which you want to connect
• MyHostName -- name of the TCP/IP host on which the Oracle database resides
• MyPortNumber -- TCP/IP port on which the Oracle database is listening
• MyServerName -- TCP/IP name of the Oracle server
• MySID -- Oracle System Identifier of the database (or Oracle TCP/IP listener service name)

XAResourceManager:
  Name=MyDataSource
  SwitchFile=oraswit
  XAOpenString=ORACLE_XA+SQLNET=MyServerName+HostName=MyHostName+PortNumber=MyPortNumber+
    Sid=MySID+ACC=P/MyUserId/MyPassword+SesTM=100+Threads=True+DataSource=MyDataSource+
    DB=MyDataSource+K=2+
  XACloseString=
  ThreadOfControl=THREAD

(The XAOpenString is actually all one line; it has been wrapped here for readability.) In addition to configuring the qm.ini file, you also need to configure some symbolic links in the /var/mqm/exits64 directory. The simplest way to create these links is to run the mqsimanagexalinks script provided with Message Broker.

For DB2, you can use a command such as:

mqsimanagexalinks create DB29 <broker install dir> <db2 install dir>

which should result in symbolic links such as:

db2swit     -> <broker install dir>/sample/xatm/db2swit
libdb2.so.1 -> <db2 install dir>/lib64/libdb2.so.1

For Oracle, you can use a command such as:

mqsimanagexalinks create DD52 <broker install dir>

which should result in symbolic links such as:

libUKicu22.so -> <broker install dir>/ODBC64/V5.2/lib/libUKicu22.so
oraswit       -> <broker install dir>/ODBC64/V5.2/lib/UKoradtc22.so
UKora22.so    -> <broker install dir>/ODBC64/V5.2/lib/UKora22.so

In addition to configuring WebSphere MQ, the following additional steps are required for Oracle:

1. Ensure that the user ID Message Broker uses to access Oracle has select authority on the dba_pending_transactions table.
2. Ensure that the JAVA_XA package is available in your Oracle database. You can check for this via sqlplus using desc JAVA_XA. If the package is not found, get your Oracle DBA to configure it, which can typically be done by running the $ORACLE_HOME/javavm/install/initxa.sql script.

Configuring DB2 to let Message Broker access DB2 UDB for z/OS

Message Broker can be configured to access DB2 databases on z/OS (or i/Series). Message Broker does not need to know that the database resides on a host system; the resolution of the database location is handled by DB2. Figure 5 below shows the two most likely ways in which a database located on a z/OS system can be accessed.

The following configuration steps are required to define the communication channels illustrated by the numbered arrows in Figure 5. When defining the communication channels, the associated commands should be run against the DB2 installation on the image to the left of the arrow, because communications will be instantiated from left to right.

Defining Communication Channel 1 in Figure 5

The first step is to configure DB2 to allow it to connect to other DB2 instances using TCP/IP:

Set the TCP/IP service name in your database manager configuration via: db2 update dbm cfg using svcename service_name, where service_name is a valid service name in /etc/services, for example, DB2_db2inst1

You can verify this update by issuing: db2 get dbm cfg.

Ensure DB2 is configured to use TCP/IP communication via: db2set DB2COMM=TCPIP

Restart DB2 and check that db2start does not give any warnings.

The next step is to catalog the database. To define the remote z/OS or iSeries server, run the command below, where myhost is the name of the host on which the z/OS or iSeries database is running. You can specify a service name instead of a port number (for more information, see the DB2 information center).

db2 catalog tcpip node mynode remote myhost server myport
db2 terminate

You then need to catalog the database connection server (DCS) database as follows, where local_dcsname represents your local name for the z/OS or iSeries database, and target_dbname represents the name of the z/OS or iSeries database (for example, location name):

db2 catalog dcs database local_dcsname as target_dbname
db2 terminate

You can then catalog the local database via the following command, substituting local_dcsname, MYDB and mynode appropriately:

db2 catalog database local_dcsname as MYDB at node mynode authentication dcs
db2 terminate

Once you have catalogued the databases you need to bind the utilities and applications to the remote server. You can do this as follows, where the user bob has BINDADD authority:

db2 connect to MYDB user bob using mypwd
db2 bind db2_path_dir@ddcsmvs.lst blocking all sqlerror continue grant public
db2 connect reset

where db2_path_dir represents the directory where the DB2 .lst files reside -- normally <instance home directory>/sqllib/bnd.

The next step is to configure DB2 to use the connection concentrator, which lets applications, such as Message Broker, stay connected without any resources being consumed on the DB2 host server. You can have thousands of users active in applications and only have a few threads active on the DB2 host server. Enabling the connection concentrator is required if you wish the database to participate in coordinated (XA) transactions. This can be achieved by updating your database manager configuration such that the number for MAX_CONNECTIONS (maximum number of client connections) is greater than that for MAX_COORDAGENTS (maximum number of coordinating agents). This can be done via:

db2 update dbm cfg using MAX_CONNECTIONS max_number_of_connections

For more information on the DB2 connection concentrator see Resources below.

If you wish to use coordinated transactions, you also need to configure the DB2 sync point manager. To do this, update the database manager configuration so that the SPM_NAME is set to be a unique identifier within your network. It is common to set this to your local hostname:

db2 update dbm cfg using SPM_NAME your_spm_name

Defining Communication Channel 2 in Figure 5

So far the z/OS database is only defined to the DB2 ESE instance. You now need to define it to the DB2 RTCL to complete the chain from left to right. Similarly to how you catalogued the broker database, you must catalogue the database alias that you have just defined to your DB2 ESE installation to the DB2 runtime client (RTCL) installed on the same image as Message Broker. Perform the following step, substituting the values appropriately:

• MYNODE is the name you gave to the DB2 RTCL node entry for your remote z/Linux image
• MYDB is the name you gave to your z/OS (or iSeries) database on your remote z/Linux image in your db2 catalog database local_dcsname as MYDB ... statement above.

db2 catalog database MYDB at node MYNODE
db2 terminate

Verifying that DB2 is configured correctly

To verify that DB2 has been configured correctly, use the db2 command line interpreter to see if you can access the tables that the Message Broker instance will use using the appropriate username and password. When you have created your broker, use the command mqsisetdbparms to configure message broker to use the appropriate credentials for each database.

Migration considerations

If you have an existing Message Broker V6 installation and wish to migrate to V6.1, your migration path will depend on the architecture of the z/Linux images that you are using. You cannot migrate brokers running on a 31-bit z/Linux operating system to V6.1. In this scenario, you must create a broker in a 64-bit z/Linux installation and deploy your resources to the new broker. If you have any C user-defined extensions, you will need to recompile them in 64-bit before they can be used by a V6.1 broker. For more information on migration, see the migration topics in the Message Broker information center.

Conclusion

This article described the different ways in which you can run WebSphere Message Broker V6.1 on z/Linux. The version on z/Linux is functionally complete and consistent with the version offered on other platforms. Dependent on your requirements, there is significant flexibility in the way you can configure your environment. Message Broker can use either DB2 or Oracle for its own data repository, and can access user data stored in DB2, Oracle, and Informix. You can also use DB2 Connect to access DB2 data in a z/OS or iSeries system.

IFL processors enable you to lower the cost of ownership for WebSphere Message Broker. You can obtain a Linux implementation of WebSphere Message Broker whilst at the same time benefiting from the well-established reliability of the System z hardware. The use of HiperSockets provides a fast method of communication for TCP/IP based protocols and is unique to System z.

The benefits outlined above contribute to making the implementation of WebSphere Message Broker on z/Linux a strong and effective one.

Resources

• Participate in the discussion forum.
  
  
• WebSphere Message Broker developer resources page
  Technical resources to help you use WebSphere Message Broker for connectivity, universal data transformation, and enterprise-level integration of disparate services, applications, and platforms to power your SOA.
  
  
• WebSphere Message Broker product page
  Product descriptions, product news, training information, support information, and more.
  
  
• WebSphere Message Broker information center
  A single Eclipse-based Web portal to all WebSphere Message Broker V6 documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Message Broker environment.
  
  
• WebSphere Message Broker documentation library
  WebSphere Message Broker specifications and manuals.
  
  
• WebSphere Message Broker forum
  Get answers to your technical questions and share your expertise with other WebSphere Message Broker users.
  
  
• WebSphere Message Broker support page
  A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
  
  
• WebSphere Message Broker system requirements
  A list of software and hardware required for WebSphere Message Broker and its components.
  
  
• DB2 V8.2 supported environments
  Details of DB2 support for a variety of Linux environments.
  
  
• DB2 V9.1 supported environments
  Details of DB2 support for a variety of Linux environments.
  
  
• DB2 Connection Concentrator
  This feature reduces DB2 for z/OS resources required on to support large numbers of workstation and Web users, and can dramatically increase the scalability of your DB2 for z/OS and DB2 Connect solutions while also providing for fail-safe operation and transaction level load balancing in data sharing environments.
  
  
• HiperSockets
  HiperSockets provide high-speed TCP/IP connectivity within a central processor complex, eliminating the need for any physical cabling or external networking connection between servers running in different LPARs. Communication is through the system memory of the processor, with servers connected to form a "internal LAN."
  
  
• Speed-start your Linux app Web site
  Access to the latest no-charge trial downloads for Linux as well as how-to articles and tech support.
  
  
• developerWorks WebSphere Business Integration zone
  For developers, access to WebSphere Business Integration how-to articles, downloads, tutorials, education, product info, and more.
  
  
• WebSphere Business Integration products page
  For both business and technical users, a handy overview of all WebSphere Business Integration products
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• Trial downloads for IBM software products
  No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
  
  
• Safari Bookshelf: e-library designed for developers
  Complete search and download access to thousands of technical books for a one-time subscription fee. Free trial for new subscribers.
  
  
• developerWorks technical events and Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts to half-day and full-day live sessions in cities worldwide.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction to WebSphere Message Broker V6.1 on z/Linux
• Introduction to z/Linux
• Why run Message Broker on z/Linux?
• Configuring Message Broker V6.1 on z/Linux
• Migration considerations
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: DB2 Enterprise
• Demo: DB2 serving ATOM feed
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: Information on Demand
• Buy: DB2 Enterprise

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers