The value of WebSphere Message Broker V6 on z/OS

The Enterprise Service Bus

WebSphere Message Broker features and functions

IBM® WebSphere® Message Broker for z/OS®, V6 (hereafter called Message Broker V6) enables you to connect a wide range of applications using different interaction patterns, protocols, and message formats.

Supported interaction patterns include:

One-way messaging

Request/response

Aggregation

Publish/subscribe (pub/sub)

Message Broker V6 supports the following protocols:

WebSphere MQ

HTTP

Java™ Messaging Service(JMS)

Real-time and multicast

File

User-defined

Message Broker V6 enables you to model and transform a comprehensive set of message formats:

Record-based (COBOL, C)

Industry standard string-based (SWIFT, TLOG, EDIFACT)

XML, including all schema artifacts

User-defined

Messages that pass through Message Broker V6 are potentially routed and transformed between different formats on the way to their destination. Message Broker V6 provides a range of technologies for transforming messages, which can be used in accordance with the skill set of the integration developer:

ESQL for users with relational database skills who prefer declarative rather than algorithmic forms to specify message transformation

Java for programmers skilled in Java

Graphical mapping for straightforward transformations that do not require programming

XSLT for XML-based transformations based on an open standard

Using these features, Message Broker V6 can take messages from a wide variety of sources in a wide range of formats and route and transform them as needed, so that they can be sent to destinations to be consumed by applications in the formats and protocols that the applications expect. This multi-step process is what message brokering is all about – end-to-end connections between all parts of an enterprise.

Message Broker V6 development artifacts

Message Broker V6 functions are made available through three objects specific to the broker:

Message flows

Message flows represent the processing required to connect applications to each other. An input message from a source application serves as input to the flow, which generates zero or more messages, some of which are transformed and routed to target applications. A message flow consists of one or more processing nodes.

Processing nodes

Processing nodes are the specialized building blocks from which message flows are constructed. Nodes represent the individual operations that occur on a message as it passes through a message flow. Nodes are customized to perform actions, such as getting a message from a specified queue, storing a message in a database, or transforming the message from, for example, an XML to a COBOL form. If the nodes available with the broker are not sufficient, you can write your own and integrate them easily.

Parsers

Parsers are provided by Message Broker V6 to read and write messages in a broad range of message formats. For message formats that can't be interpreted by the built-in Message Broker V6 message parsers, you can write your own parsers, but you rarely need to to so because of the flexibility of the built-in parsers.

Message Broker V6 components

There are four components of Message Broker V6:

Toolkit

In the Development Perspective, Message Broker V6 provides user-friendly, Eclipse-based tools that help you develop broker artifacts such as message flows and message sets. Message Flows, message definitions, and any other associated files are packaged into deployment containers called broker archive (BAR) files ready for deployment to the broker runtime.

An Administration Perspective lets operations staff deploy BAR files to any broker within the administrative domain. In addition, the full operational state of each broker is visible and can be controlled from this perspective. The Administrative Perspective uses the Configuration Manager (described below) to effect changes and report status. The Eclipse toolkit runs on Linux® and Windows®. Each developer requires a broker toolkit with a Development Perspective, and each administrator may use a broker toolkit for graphical administration as required. A full suite of command-line tools and programming interfaces is also available for operations management.

The Eclipse toolkit runs on Linux and Windows. Each developer requires a broker toolkit with a Development Perspective, and each administrator may use a broker toolkit for graphical administration as required. A full suite of command-line tools and programming interfaces is also available for operations management.

Broker

The Broker is the run time where deployed flows execute within containers called execution groups, which appear as z/OS address spaces. Execution groups provide an excellent opportunity for vertical scaling and isolation.

Operational personnel have a full range of commands, both JCL and console-based, that let them view and control the operational state of a broker.

Configuration Manager

The Configuration Manager is the single management and administration component for a collection of brokers in a domain. The configuration manager controls all operational actions via access control lists. It also monitors broker state and holds topology information related to deployments and inter-broker connectivity.

All users’ toolkits are connected to a configuration manager.

User Name Server

The User Name Server component is used in pub/sub networks to determine the set of user and groups used for pub/sub security checking. This set can be either the users

defined to the z/OS operating system, or those defined with a user-created program or file. These values are sent to both the configuration manager and the broker for subsequent administrative and run-time processing.

A typical configuration is shown below in Figure 1. The diagram represents a broker domain containing three brokers under the administrative control of the Configuration Manager. You can perform development and administrative tasks using the Message Brokers toolkit (in this configuration, a user name server is not shown.) The Message Broker run-time component is responsible for routing and transforming messages between applications using message flows, nodes, and parsers.

Figure 1. WebSphere Message Broker domain

Platform choice for components

The toolkit component runs on Linux and Windows under the Eclipse environment using Rational Application Developer. The other components such as Broker, Configuration Manager, and User Name Server may be placed on your chosen platform. For z/OS, you can deploy brokers, the Configuration Manager, and the User Name Server components to this platform.

A broker domain should contain the appropriate mix of platforms to meet the message processing needs of connected applications. If transformed messages need to be sent to applications that reside on z/OS, or information needed to route and transform messages requires data on z/OS, then it usually makes sense to place a broker on z/OS. As explained

below, operational characteristics of the z/OS broker components mean that users who need a highly available and scalable technology close to their enterprise data and applications will select z/OS as a natural platform for these components.

Moving from development to production

In most enterprises, the needs of developers are different to those of production staff. Developers tend to prefer their own systems under their own control with the ability to share resources with their co-workers as appropriate, so that they can minimize the time required for the compile-test-fix cycle. Production environments have different criteria for success: operational personnel tend to require characteristics such as stability and control.

In development environments, developers usually have their own Toolkit, Configuration Manager, and Broker running on Windows or Linux workstations. Developers have full control over creating, deploying, and managing broker domains in this environment. In many cases, teams of developers will share development resources such as transformation logic or message definitions using one of the library systems supported by Eclipse, such as CVS or Rational ClearCase.

When a project has finished its development phase, artifacts required for the production rollout are packaged into BAR files (see above), so you can send then through quality assurance procedures and prepare them for deployment to live systems.

Moving towards production rollout, project focus turns to proving that functional, performance, and stability criteria are met. The platforms for test and quality assurance tend to be close to those used for production environment, and for many large enterprises this means z/OS. Since all broker capabilities are available on all platforms, projects developed on Windows or Linux can be seamlessly transitioned to z/OS knowing that behaviour is maintained. You can move from project development through test and quality assurance to production by deploying the same project BAR files successively into these environments and verifying that project goals continue to be met. Support for deployment descriptors within BAR files lets you change configuration parameters such as queue names and database table and schema names without changing transformation or message modelling logic.

Once a project is ready for production deployment, operational staff can deploy using the a graphical tool, but are more likely to use JCL or z/OS console commands to deploy BAR file artifacts into the broker run time, and similar commands to verify and report deployment status. Deployment, monitoring, report, and control can be handled completely by z/OS production personnel.

In summary, Message Broker's strong platform support, uniformity of behaviour, flexible deployment capabilities, and range of tools support (graphical, command-line, and programmable) support the demanding needs of z/OS development and operational staff.

Message Broker V6 topologies

Message Brokers can either be deployed individually as standalone processing engines or in connected topologies to create highly available and scalable architectures. Whether a hub, bus, or arbitrary graph topology is employed is a decision based on the architectural or business needs of a project rather than functional characteristics. Message flows and their associated artifacts can be deployed to one, many, or all of the brokers within a domain topology. Applications connected to a message broker node can interoperate with other applications connected to any other broker node within the topology, using any protocol or message format combination. Figure 2 below shows how brokers may be arbitrarily connected

together to create a topology that meets the scalability and availability needs required. For example, applications can communicate with other applications connected to the same or to different brokers within a domain.

Figure 2. WebSphere Message Broker topologies

An initial deployment on z/OS will probably involve a single Message Broker, because a relatively simple pilot will help you gain familiarity with Message Broker V6 concepts and technology. As you roll out more deployments, you may want to scale horizontally onto multiple zSeries machines to increase both capacity and availability.

On z/OS, you can use SYSPLEX technology to scale horizontally and still maintain a single system view from an operational perspective. Because broker domains are designed to support multiple brokers, the single operational SYSPLEX view is consistent with the architectural construct of a broker domain. Therefore you can easily deploy highly available and scalable broker architectures using SYSPLEX technology.

It’s also natural to create combinations of brokers on different operating systems. Your enterprise may have applications running on a variety of platforms in order to meet business needs, including AIX®, HP-UX, Linux, Solaris, and Windows. Message Broker V6 lets you connect the applications throughout your enterprise, regardless of the platform they run on.

Message Broker V6 capability comparison

All Message Broker V6 capabilities are available on z/OS in a consistent and complete fashion compared to WebSphere Message Broker on other platforms. Therefore, you can develop and test solutions on your platform of choice, put them through your quality assurance procedures, and deploy packaged solutions (BAR files) on z/OS. Deployment

descriptors let you reconfigure the parameters that control detailed behaviour of a message flow, such as queue names or database schemas, without changing the message flow.

Message Broker V6 also has platform-specific capabilities and advantages. While some capabilities are available only on z/OS (see below), most are built-in to the broker, so that your applications benefit from the increased performance, manageability, and resilience without design changes.

High availability

Parallel SYSPLEX

Message flows deployed to brokers on z/OS can benefit from using resource managers such as WebSphere MQ and DB2 that are Parallel SYSPLEX aware. Objects including WebSphere MQ queues and DB2 databases are available as shared resources within a SYSPLEX, making them simultaneously available to all applications within the SYSPLEX. As long as one z/OS image is available, these resources are available. What’s really powerful is that this is a truly shared resource. In the event of failure, the remaining images will make the failed work available immediately, without a restart -- availability in its highest sense.

For example, a message flow deployed to brokers in a WebSphere MQ Queue Sharing Group and transforming XML messages from a shared input queue may perform that processing anywhere in the SYSPLEX. As long as one queue manager in the group remains available, messages can continue to be transformed. What differentiates this arrangement from "shared nothing" solutions is that after a failure, rolled back messages are immediately available within the SYSPLEX, and can be processed by other flow instances servicing the shared input queue.

Message flows also exploit a special mode of operations with shared queues that preserves message order in the event of a failure. Messages rolled back after a failure are delivered to another message flow in the SYSPLEX in the same message order. This capability is vital when in-order delivery of messages is critical, as with financial deposits and withdrawals. This capability goes beyond message replication to true resource sharing.

Similar capabilities exist for DB2 resources when using DB2 Data Sharing Groups.

Automatic Restart Manager (ARM)

ARM is a z/OS subsystem that ensures that you can restart appropriately registered applications and subsystems after a failure. Applications and subsystems can either be restarted on the image on which they failed, or in the case of image failure, on another available image in the SYSPLEX. ARM also covers application restart dependencies where applications require other applications or subsystems to be present before they restart. Message Broker V6 is fully ARM-enabled, and it is simple for an operator to assign an ARM classification and name to the broker. When the broker is started or stopped, it performs the necessary registration with ARM, enabling it to be restarted as defined in the ARM policy by the z/OS systems programmer.

The Configuration Manager and User Name Server components are also ARM enabled.

WebSphere MQ clustering

For z/OS users not using Parallel SYSPLEX, MQ clustering provides an excellent way to exploit high availability for new messages in the event of failure. In this mode of operation, brokers in a domain have a partitioned copy of the input queue, and clustering ensures that in

the event of a failure, new messages are sent only to queues that are still available. Although MQ clustering is a "shared nothing "solution, in many scenarios it can be good enough to enable the availability of new work, especially when combined with ARM.

Workload management

Goal-oriented resource allocation

When a Message Broker V6 execution group address space starts, you can assign to it a Workload Manager (WLM) service class. Systems programmers can assign different goals (typically response time) to this service class through WLM configuration choices.

The ability to assign WLM service classes to message processing workload has two significant benefits:

As work passes through subsystems that are WLM enabled, the service class can be maintained. Resources such as CPU and IO "follow" users’ work requests to make sure these requests meet, if possible, the goals set by WLM.

WLM classification means that in the event of resource constraint (at peak time for example), high priority workloads can receive appropriate resource to ensure that critical workloads are completed at the expense of less important work.

It is possible to assign different Execution Group address spaces to different WLM classes so that CPU and IO resource allocation can be prioritized appropriately for different classes of work performed with a single message broker.

Workload scaling

z/OS z/OS SYSPLEX brings vast potential processing capacity to Message Broker V6. Not only are z9 processors extremely powerful on their own, but up to 32 can be configured in a single z/OS image. Moreover, up to 32 z/OS images can participate in a SYSPLEX configuration. Message Broker V6 is designed to exploit all of these capabilities without any design changes to message flows.

Message flows have a built-in multiprocessing capability. Each instance of a message flow can execute on a separate thread (z/OS TCB), letting the broker easily exploit multiple CPUs. If a flow is not able to process enough messages due to a CPU constraint, it is simple to assign more instances to the message flow to dynamically increase the number of eligible CPUs for processing. No outages or changes in flow design are needed.

When you need to deploy flows across multiple execution groups, for example, to overcome the 2 GB virtual storage limit on z/OS address spaces, it is easy to assign a message flow (including its additional instances, if necessary) to these new address spaces. Again, no design changes are needed -- the flow is just assigned and becomes active automatically and without broker restart.

As described above, it’s simple to scale message flows across the SYSPLEX by deploying to multiple brokers within the SYSPLEX broker domain. Again, this reconfiguration process is dynamic and does not require restart. Similarly, you can remove brokers, execution groups, and message flow instances as needed.

Workload isolation

In some scenarios, message processing workloads must be separate from each other. For example, regulatory requirements may mandate that infrastructure groups that are processing workloads from third parties must keep those workloads separate. While you can assign a new broker to each party, it is simpler and just as effective to assign separate execution group address spaces to different types of work. From a storage isolation perspective, these execution groups are completely separate, and storage in one address space is not visible to another execution group. In the event of a failure, an execution group is restarted without affecting any execution groups owned by the broker -- failures are isolated to execution groups.

Reporting and chargeback

System Management Facilities (SMF)

SMF collects and records performance and accounting information generated by z/OS subsystems. This information is generally used for two purposes:

Enable efficient and effective tuning of message flows.

Enable infrastructure departments to charge users for their use of broker facilities, in accordance with agreed metrics, to help recover the cost of the infrastructure.

Message Broker V6 lets operational staff gather SMF data per message flow. Message flow developers do not need to instrument their designs in any way. Once the operator enables statistics for a message flow, the broker measures a broad range of flow- and node-related metrics, including CPU, IO, and user-relevant metrics such as number of messages processed, maximum message size, and average elapsed time. Common usage scenarios include using the number of messages processed by a flow to chargeback, and measuring the CPU, IO, and elapsed time averages for a node within a flow for hotspot analysis.

In some situations, message flow designers may wish to influence data by determining the source of messages processed by the broker, when a single message flow is processing requests on behalf of many disparate users. The flow designer might, for example, extract an application identifier from an MQ Message Descriptor field, or they might extract a department code from a message body. Once the flow designer determines the accounting origin, Message Broker V6 will partition performance and accounting information for this origin and record it separately to SMF, which lets you detail exact usage by a particular user or department.

Coordinated reporting

SMF also lets subsystems report performance and accounting information at the same time for a given processing interval, which lets you correlate statistics between Message Broker V6, WebSphere MQ, and DB2 subsystems and artifacts. This capability provides a powerful performance analysis tool for understanding relationships between subsystems.

Event Notification Flag 37 (ENF37) is signaled by SMF when it wishes subsystems to write performance and accounting information. Message Broker V6 is enabled for coordinated SMF reporting using ENF 37.

Reduced cost of ownership

These improvements mean that existing users will see significant benefit from moving to Message Broker V6. Similarly, new users can be confident that z/OS broker-based solutions deliver a high-performance solution with excellent value for the money.

Using zSeries Application Assist Processor (zAAP)

You can now offload machine instructions generated by the Java Virtual Machine to dedicated processors called zAAPs. A zAAP costs significantly less than a regular central processor, and zAAP capacity is not included in MSU capacity. Therefore you can offload Java-based applications without any increase in software costs. zAAP is available with z/OS V1.6 or later.

Message Broker V6 has several features that directly exploit zAAP technology, namely the Java Compute node, XLST node, and JMS Real-time and Multicast nodes. Therefore message transformations in Java and XSLT may be able to offload a significant percentage of their workload. Message distribution using JMS real-time and Multicast transports will similarly benefit.

The Java Compute node has been designed to cater for the needs of integration developers who wish to use Java as a transformation and routing language. All transformation logic written in these nodes is eligible for offload to zAAP. (However, parsing operations are still performed by non-Java components and are not eligible for offload). The exact offload amount depends on the amount of transformation logic compared to the amount of parsing. For simple messages that don't require too much parsing, or relatively complex message transformations, the zAAP offload should be significant.

XSLT processing, while requiring an XML input message, is increasingly significant. Because processing is entirely in Java, offload ratios as high as 80% have been observed in lab tests using this node. JMS Real-Time and Multicast components can be fully offloaded to zAAP, which means that non-queue-based pub/sub messaging involving a z/OS broker can benefit significantly. Also, the Configuration Manager is implemented in Java, so on z/OS, all of its CPU processing can be offloaded to zAAP.

50% Performance Improvement with V6

Message Broker V6 is an industry leader in high-performance transformation and routing. But the CPU cost associated with these functions is significantly higher than with traditional data processing. For example, parsing large XML documents requires lots of processor cycles. To dramatically reduce cost of ownership, IBM has made significant performance improvements in Message Broker V6 compared to previous versions.

Message Broker V5 and V6 were compared using a comprehensive range of tests involving different messaging styles, protocols, and message formats. In customer-oriented end-to-end messaging scenarios, messaging throughput increased by 50% with Message Broker V6. These reductions in processing costs are in addition to benefits from zAAP offloading when using broker Java components. The improvements were achieved without external product interface changes, so if you migrate from a previous release, you should see these performance improvements for existing message flows without changes to integration logic.

These improvements have been achieved without external product interface changes, meaning that users migrating from previous releases will see an improvement for existing message flows without having to change their integration logic. These performance improvements result from work in the following areas:

Parser improvements: Industry based (e.g. SWIFT) and record based (COBOL/C) parsers have seen improvements by up to a factor of four

ESQL improvements: Implementation has been thoroughly analysed and their implementation improved by an average factor of two

Locking and scalability: A significant reduction in CPU cost and wait times in multiprocessing environments

Aggregation implementation: MQ based implementation rather than database to give up to four times improvement in throughput

zSeries and z/OS technology exploitation

o XML Toolkit

Exploitation of Unicode conversion services and native hardware features

o IEE754

Exploitation of native hardware IEE754 floating point operations

o New Compiler algorithms

Generation of machine instructions for latest hardware ARCH(3) and above

Aggressive compiler optimization OPT(3)

64 bit multiply and divide algorithm enhancements

Native Unicode string generation

o z/OS 1.5 or above

Complete XPLINK exploitation of LE, Broker, JVM and ODBC

New features

New features in Message Broker V6 let you perform existing processes more effectively:

Java Compute Node to enable zAAP offload

DATETIME and field formatting enhancements to simplify the most common transformation operations and reduce their CPU cost

Semi-persistent environment to improve message routing and counting scenarios

MQGET node to maintain, where appropriate, processing context; and improve request response processing performance

Compact parsers for XML to reduce the CPU to read, write and navigate XML documents

Unicode database support to efficiently store data from worldwide sources without loss

New pricing

IBM has reduced the price of Message Broker V6 compared to V5. In addition, V6 is available in a "start-small-and-grow" edition at a reduced cost. This edition includes all Message Broker V6 capabilities, and you can scale vertically by exploiting multiple CPUs, including zAAPs. The only limitation is a capacity restriction of a single execution group per broker, limiting processing to a single z/OS address space, which is sufficient for typical initial deployments of Message Broker V6.

Operational characteristics

Using Message Broker V6 is a familiar experience for z/OS users. Whether you are dealing with installation, customization, command and console support, problem determination, coexistence, or security, Message Broker V6 looks and feels like a z/OS product. So you can use all of your existing z/OS skills when creating and managing your Message Broker V6 infrastructure on z/OS.

Installation and customization

Message Broker V6 is installed using SMP/E, which makes it a familiar experience for z/OS systems programmers. Fixes are delivered at PTFs and can be applied as necessary using SMP/E. Collections of fixes delivered as fix packs supersede any installed PTFs, which gives you a seamless upgrade path to the latest level of code.

Creating brokers, configuration managers, and user name servers is all JCL-based. Since most z/OS users know JCL, they can integrate z/OS customization procedures for broker components with existing procedures.

Command and console support

Broker component commands are available as JCL commands and via the MVS console. All JCL command output is written to the JES SPOOL as expected. All MVS console output appears on the MVS LOG.

Problem determination

Message Broker V6 writes informational, warning, and error messages to z/OS JOBLOGs for each execution group, which gives operators a time-stamped record of all events in a broker execution group. Messages for z/OS brokers and configuration managers also include a JOBLOG audit trail to detail all changes and operations. Examples of these operations include new and changed deployments, and actions on message flows such as starting and stopping them. Combined with message flow and message set versioning, this lets operators quickly determine the source of changes to their broker environment on z/OS.

If Message Broker V6 detects an internal error during processing, it produces a system dump with code S2C1. This dump is written to a regular MVS dump dataset and can be used by IBM Support to determine the reason for the error, and if necessary, provide a fix or temporary workaround for the problem.

Coexistence and migration

Message Broker V6 is typically installed alongside previous versions, and you can have multiple versions installed and operational. Therefore you can take a piecemeal rather than big-bang approach to migration, moving artifacts to V6 on a schedule that fits your business needs. You can also migrate Message Broker V6 components forwards and backwards between versions, which is useful if the rollout of a migrated broker needs to be backed off, or if business readiness requires it.

Security

You can secure all Message Broker V6 components using SAF-compliant security manager. Broker, Configuration Manager, and User Name Servers all run as started tasks and are assigned an appropriate z/OS user ID. Their access to z/OS resources nay be controlled according to this user’s rights by a SAF-compliant security manager. The Configuration Manager provides access control lists based on RACF users and groups to determine which users are allowed to interact with the broker domain, and the level of command support to which they are entitled.

Resource Recovery Services (RSS)

RRS is the transaction coordinator for Message Broker V6. Most z/OS subsystems are now RRS enabled (MQ, DB2, CICS, VSAM), and hence any work performed by the broker is by default within a fully transactional unit of work. Any node within a message flow that interacts with an RRS-enabled resource manager is automatically enlisted in a transaction, including user-developed and third-party nodes.

The Message Broker V6 transaction model is extremely powerful, enabling arbitrary nodes within a message flow to participate within a transaction. In most cases, all resources are updated as a single unit of work, but there can be cases where the ability to commit work independently of a larger transaction is desirable, such as in logging successful and unsuccessful transactions.

Disaster recovery

All key broker components needed for production systems are available on z/OS, providing a solid platform for building a disaster recovery solution. Message Broker V6 is not a resource manager like WebSphere MQ or DB2, so it does not have any transaction logs or page sets to manage, which simplifies disaster recovery solutions. An effective disaster recovery procedure requires all components and resources to be considered, and this article discusses only Message Broker V6 aspects.

Message Broker V6 resources under consideration fall into three categories:

Topology information such as brokers and any inter-broker domain connections, execution groups within these brokers, and assignment of message flows within execution groups.

Development Artifacts such as message flows, message sets, JAR files and style sheets.

Run-time state information such as durable subscriber details, retained publications, and in-flight aggregation state, which is held in WebSphere MQ queues and DB2 database tables.

In a disaster, all of these resources may be lost on the active system and may need to be restored on a backup system at a state as close as possible to the state at time of failure.

First, all topology information must be restored. Whenever a change to a production configuration is made, a record of the change needs to be made. Re-creation of topology information can performed using JCL command scripts or the Configuration Manager programming interface, as preferred. The record of the topology information is used to re-create the environment from the last deployment change.

The vast majority of development artifacts are contained in BAR files. At the time of deployment to a production system, a copy of the deployed BAR file should be made available on the backup system. Any development resources deployed by hand should also be made on the backup system. In the event of a failure, JCL command scripts or programming interfaces are used to redeploy resources to brokers and execution groups as necessary.

Finally, run-time state is either restored from disaster recovery of WebSphere MQ or DB2 resources, or manually by end user applications if this is not possible. If this failed state is not recovered, end users will have to remake the lost state. For infrequently changing information such as durable and retained publications, it is relatively easy to make this information, but restoring in-flight aggregation states is more difficult.

Message Broker V6 lets you create a fully scripted disaster recovery procedure that can be rehearsed and followed by operational staff in the event of a disaster.

z/OS Specific nodes

Message Broker V6 contains all components and capabilities available with the family of platform offerings, as well as significant design enhancements to support z/OS, as described above. However, some nodes are available only on z/OS for interaction with unique z/OS datasources and subsystems.

VSAM nodes

Message Broker V6 can process VSAM records in the same way as it processes messages from or to other data sources. Message Broker V6 support for VSAM consists of a suite of five nodes that let you perform record-oriented processing on VSAM files, including input, read, write, update, and delete operations. You can combine these nodes for VSAM access with other nodes to integrate VSAM processing into message flows, or use VSAM files to drive message flow processing. Consider the following scenarios:

Batch input processing

Read a specified number of records from a VSAM data set and propagate each record to subsequent nodes in your message flow

With update processing allows record locking for update later in a message flow

Data Enrichment and Routing from VSAM

Use VSAM as a database to perform data enrichment or message routing

Data logging to VSAM

Record interesting events to a VSAM file

Deletion of VSAM data

Remove VSAM file records on the basis of message processing

These nodes are delivered as a category 3 fully supported SupportPac -- IA13. For details, see Resources below.

QSAM nodes

A set of z/OS-specific nodes is also available for QSAM processing. These are similar in concept and usage to the VSAM nodes, but oriented around sequential files, rather than record-oriented files. These nodes are delivered as a category 3 fully supported SupportPac -- IA11. Details on where to get the node are are provided in the resources section.

CICS node

It has always been possible to drive CICS transactions using MQ messages generated by the broker, either directly, if the CICS transaction program is MQ enabled, or via the CICS DPL or 3270 bridge. However, there are disadvantages with this approach from a broker perspective:

The flow is broken into several legs, which means that processing is more complex.

More transactions are required to achieve processing.

The requesting context needs to be re-established when the response from CICS is returned, which may involve expensive operations such as reparsing the original input message.

The CICS request node lets a CICS program be driven synchronously within a message flow, simplifying the flow structure, reducing the number of transactions, and maintaining the processing context while the request is being handled by CICS.

Message Broker V6 processing using the CICS node is greatly simplified and improves performance up to 3X (for details, see Support Pac IA12). The CICS node extracts a COMMAREA from a node-defined portion of the input message and uses the EXCI interface to execute the appropriate transaction program. The resulting COMMAREA is added back to the message tree upon completion of the transaction. The CICS transaction program may operate within the RRS coordinated unit of work, or be committed immediately according to a node attribute.

The CICS node is delivered as a category 3 fully supported SupportPac -- IA12. For details, see Resources below.

Conclusion

This article has described how Message Broker for z/OS, V6 offers a high performance, highly available, scalable and manageable enterprise messaging backbone for a diverse range of messaging styles, protocols and formats.

Message Broker V6 provides a first class z/OS subsystem implementation. It is very well integrated with the key characteristics of the z/OS platform, which its users expect for their business processing. These include:

Availability

Reliability

Scalability

Workload management

Operational control

Comprehensive reporting

Security

Disaster recovery

Message Broker V6 and z/OS combine to form a powerful integration platform for messaging.