New and enhanced nodes in WebSphere Message Broker V6.1

This article describes the new and enhanced nodes in WebSphere Message Broker V6.1 for Message Broker administrators, application architects, and developers.

Share:

Dan Lee (leed@uk.ibm.com), Software Engineer, WebSphere Message Broker Test team, IBM

Daniel Lee is a Software Engineer at the IBM Hursley Software Lab in the UK. He works for the WebSphere Message Broker Test team. You can contact Dan at leed@uk.ibm.com.



Sarah Styles (sarah.styles@uk.ibm.com), Software Engineer, WebSphere Message Broker Level 3 Service team, IBM

Sarah Styles is a Software Engineer at the IBM Hursley Software Lab in the UK. She works on the WebSphere Message Broker Level 3 Service team, and before that, on the WebSphere Message Broker Development and Test teams. You can contact Sarah at sarah.styles@uk.ibm.com.



Paul Thorpe (paul.thorpe@uk.ibm.com), Software Engineer, WebSphere Message Broker Development and Test teams, IBM

Paul Thorpe is a Software Engineer at the IBM Hursley Software Lab in the UK. He works on the WebSphere Message Broker Development and Test teams. You can contact Paul at paul.thorpe@uk.ibm.com.



28 May 2008

Introduction

This article introduces a number of new nodes in IBM® WebSphere® Message Broker V6.1 (hereafter called Message Broker), and describes enhancements to existing nodes. The new nodes are grouped in the following categories relating to their function:

  • Web Services – The Web Services nodes enable applications to participate in a Web Services environment.
  • Routing – The Routing nodes are used to dynamically update and route messages through a flow.
  • WebSphere Adapters – The WebSphere Adapters nodes provide a two-way interaction with a number of major Enterprise Information Systems.
  • File – The File nodes provide built in support for file processing at runtime.
  • Transport – The Transport nodes provide enhanced support for the JMS transport as well as providing support for Email.

The enhancements made to existing nodes are as a response to user requests. This article covers:

  • Improvements to the MQ and HTTP transports.
  • Improvements made to the Trace nodes.
  • Improvements made to the Mapping node
  • Improvements made to the XSLTransform node (formally the XMLTransformation node).

New nodes

In this section we will look at each of the new nodes in the category of function that they belong.

New Web services nodes

Message Broker has introduced a set of Web Service nodes to enable applications to participate in a Web Services environment as a service provider, a service consumer, or both.

A Web Service is a self-contained, self-describing modular application designed to support interoperable machine-to-machine interaction over a network. It fulfills a specific task or a set of tasks and is described by a service description in a standard XML notation called Web Services Description Language (WSDL). A WSDL definition tells a client how to compose a Web services request and describes the interface that is provided by the Web service provider.

Message Broker has introduced:

  • Provider nodes (SOAPInput, SOAPReply)
  • Consumer nodes (SOAPRequest, SOAPAsyncRequest, SOAPAsyncResponse)
  • Helper nodes (SOAPExtract, SOAPEnvelope)

Along with a single SOAP parser and domain to support all SOAP message formats these nodes may be combined to support a fully integrated Web Services environment.

Provider nodes

The provider nodes are used to construct a message flow which implements a Web Service provider. They may be used to present an existing message flow as a web service or facade an existing application as a web service.

If the broker has existing message definitions which are going to be used by other Web Services then the broker can export those definitions as a WSDL file which may then be consumed by other toolkits such as .NET.

SOAPInput

The SOAPInput node listens for incoming Web Service client requests. It is the entry point to the message flow that accepts and processes SOAP messages.

SOAPReply

Once the request has been processed by the message flow, the response is usually returned to the originating client by the SOAPReply node.

The SOAPInput, SOAPRequest and SOAPReply nodes are similar in concept to the HTTPInput, HTTPRequest and HTTPReply nodes that were shipped in earlier versions of WebSphere Message Broker.

Consumer nodes

The consumer nodes are used to construct a message flow which calls out to other Web Service providers. This may be another message flow which provides a web service interface, or an application in a completely different product such as WebSphere Application Server or CICS that also presents a web services interface..

If the broker needs to interact with an existing Web Service then a WSDL definition for that service can be imported into a message set. The resulting message set contains message definitions which model the SOAP envelope and the content of the corresponding SOAP messages.

SOAPRequest

The SOAPRequest node will make the call synchronously which means it will block after sending the request until the response is received.

SOAPAsyncRequest

The SOAPAsyncRequest node will make the call but continues processing and does not wait for the response.

SOAPAsyncResponse

The SOAPAsyncResponse node waits in a separate thread for the response which may be in a different message flow altogether. This allows for multiple Web Service requests to be handled in parallel. A unique identifier is used to correlate the logical pairing between the SOAPAsyncRequest and SOAPAsyncResponse nodes. This is helpful in a situation where the web service may take a long time to respond or is not required to obtain a response immediately. The value of asynchronous web services is that resources such as threads and memory are not tied up whilst waiting for a response.

Helper nodes

Helper nodes simplify the processing of SOAP payload and headers.

SOAPExtract

The SOAPExtract node removes SOAP envelopes, allowing just the body of a SOAP message to be processed. It can also route a SOAP message based on its operation name. Both functions are optional; they are contained within one node because they are often used together.

SOAPEnvelope

The SOAPEnvelope node is used in conjunction with the SOAPExtract node and simply adds a SOAP envelope onto an existing message.

Web services functionality

A number of improvements to Web services processing go beyond their HTTP node counterparts and conform to new Web services standards and specifications:

Web Services Addressing

Web Services Addressing provides a standard way to aid interoperability between Web services using endpoint reference information and message addressing properties (MAPs).

Web Services Security

Web Services Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication.

Message formats

All the Web service nodes and the SOAP domain support common Web service message formats: SOAP 1.1, SOAP 1.2, SOAP with Attachments (SwA), and SOAP Message Transmission Optimization Mechanism (MTOM).

Message exchange patterns

A WSDL operation type defines the expected use of the WSDL input, output, and fault elements in the WSDL definition. The Web Service nodes support common types such as request-response and one-way. In the case of one-way, no response message is expected.

WSDL wizards

There are multiple wizards to help you work with WSDL files in Message Broker:

  • Import of WSDL to create message definitions in a message set.
  • Generation of WSDL from a message set.
  • WSDL editor with text and graphical design views.
  • Use of WSDL to configure nodes in the SOAP domain. For example, you can drag-and-drop WSDL onto a Web Service node.
  • Use of WSDL to create a skeleton message flow by dragging-and-dropping WSDL onto the message flow editor canvas.

WebSphere Service Registry and Repository

These nodes were first included in the IA9Q Category 3 SupportPac, released in 1Q07 with limited capability. The function they provide has been extended and they are now integrated into Message Broker V6.1. The enhancements made to these nodes have focused on improving the initial user experience and making the nodes easier to use. Included in this is a name change for both nodes. The SRRetrieveITService node is now called the EndpointLookup node, and the SRRetrieveEntity node is now called the RegistryLookup node. Both nodes can be found in the Web services drawer of the node palette.

EndpointLookup

The purpose of the EndpointLookup node is to retrieve Web Service endpoints from WSRR. The retrieved Web Service endpoint can then be used for dynamic routing at runtime, and ultimately allows for the insertion of a WSDL endpoint into a message flow.

RegistryLookup

The purpose of the RegistryLookup node is used to retrieve Web Service metadata from WSRR. The node itself can be used for the retrieval of any WSRR entity, and has the ability to search entity names for a specific entity. The RegistryLookup node allows for the retrieval of the entire contents of the WSRR entity at runtime.

Routing

Message Broker has introduced a set of new nodes to dynamically update the contents of a message, route messages appropriately through a flow, and create message collections:

  • DatabaseRetrieve -- to ensure that information in the message is up-to-date.
  • DatabaseRoute and Route -- to direct messages down different paths of a message flow based on certain criteria.
  • Collector -- to create a message collection from one or more sources based on configurable criteria.

No programming is needed in order to use these nodes in a message flow. They are configuration only, which makes it easier and quicker to include them in a message flow.

DatabaseRetrieve

The DatabaseRetrieve node is used to add information to a message from a database. A key contained in the message could be used as the lookup for information in the database. It looks up values from the database and stores them as elements in the outgoing message assembly tree. If a message element already exists in the outgoing message tree, the new value overrides the old value otherwise the target element is created and its value is stored.

DatabaseRoute

The DatabaseRoute node synchronously applies filter expressions for a specified selection of data in the database to make routing decisions. The node provides the routing logic using a table of filter expressions. Each filter expression in the table can be applied to:
  • The input message
  • The collection of named column values that are selected from a matched database row
  • Both the input message and the returned column values
  • Neither

Route

The Route node applies filter expressions to the input message to make routing decisions. The Route node could be used to bypass unnecessary steps such as checking to see if the message is missing any data before routing to a DatabaseRetrieve node. As with the DatabaseRoute node, the routing logic is provided using a table of filter expressions which are applied to the input message.

Collector

A message collection is the generation of a single message derived from multiple messages from one or more sources. These various message input sources are added as dynamic input terminals to the collector node. The Collector node creates these message collections so that they can be processed together by nodes downstream in the message flow.

The Collector node will collate messages from different sources at different times and in an unknown order so that their information may be combined, extracted and transformed further downstream in the message flow. Any of the existing input nodes in WebSphere Message Broker are supported as a source of messages for the Collector node.

A collection is defined by configuring an event handler for each input terminal. Each event handler controls the acceptance of a message into a collection according to the following properties:

  • Number of messages
  • Collect messages for a set period of time
  • Match the contents of a correlation path
  • Match the contents of a correlation path against a correlation pattern

WebSphere Adapter nodes

WebSphere Adapter nodes provide two-way interaction with a number of major Enterprise Information Systems (EIS's): PeopleSoft, SAP, and Siebel. This functionality is provided by WebSphere Adapters V6.1 technology with Message Broker media. This functionality is provided to the Message Flow developer as a series of Input and Request nodes. This adapter support replaces the previous support for the WebSphere Business Integration Adaptors. The adapters discussed in this section are packaged as part of WebSphere Message Broker V6.1.

Some of the terminology with the new adapter support has changed. The term inbound refers to changes occurring with the EIS component that triggers a message flow in WebSphere Message Broker V6.1. An outbound operation refers to information moving from the flow to the EIS component.

As part of the new function, an adapter connection wizard is provided to allow configuration of the adapter as well as the discovery of business object information for the appropriate system.

PeopleSoft nodes

The PeopleSoft nodes support PeopleTools V8.22, and 8.40-8.49.

PeopleSoftInput

Provides access to the PeopleSoft adapter in inbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an input node, the functionality will be inbound only.

PeopleSoftRequest

Provides access to the PeopleSoft adapter in outbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an output node, the functionality will be outbound only.

SAP nodes

The SAP nodes support SAP Web Application Server V6.20-7.00 and SAP R/3 V4 applications.

SAPInput

Provides access to the SAP adapter in inbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an input node, the functionality will be inbound only.

SAPRequest

Provides access to the SAP adapter in outbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an output node, the functionality will be outbound only.

Siebel nodes

The Siebel nodes support Siebel Business Applications V7.05, 7.5, 7.7, 7.8, and 8.0.

SiebelInput

Provides access to the Siebel adapter in inbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an input node, the functionality will be inbound only.

SiebelRequest

Provides access to the Siebel adapter in outbound mode. The Adapter component associated with this node will define what functionality is available to the node at runtime. As this is an output node, the functionality will be outbound only.

File nodes

The file nodes provide built in support for file processing, including retrieving and outputting large files at run time, comprehensive support for record detection, and FTP transfer.

FileInput

The FileInput node can retrieve one or more messages from a specified local or remote file at runtime.

FileOutput

The FileOutput node can write one or more messages to a specified local or remote file at runtime. Remote files are supported through the use of ftp.

Transport nodes

WebSphere Message Broker V6.1 has introduced two new nodes to improve transport support. In particular the JMSReply node has been introduced to improve support for the JMS transport, and the EmailOutput node has been introduced to provide support for Email.

JMSReply

The JMSReply node is used to send a message to the recipient specified in the JMS header (JMSReplyTo field) of the message. Essentially this node provides similar functionality to the MQReply node, but for the JMS transport..

EmailOutput

The EmailOutput node is used to deliver an email message to one or more recipients from a message flow to a specified SMTP server. There are several options for generating the email message. These include:
  • Configure an e-mail with a statically-defined subject and text to a statically-defined list of recipients.
  • Configure a statically defined e-mail as a MIME message, with the location of an attachment derived from the message tree.
  • Create a dynamic e-mail message where the SMTP server, list of recipients, subject, text, and multiple attachments are determined at run time by values specified in the Local Environment. This option requires preceding nodes in the message flow to construct these overrides.
  • Pass a MIME message to the EmailOutput node using the MIME parser to write the MIME message to a bit stream. LocalEnvironment overrides are not taken into consideration when a MIME message is passed.

Enhancements to existing nodes

This section describes V6.1 enhancements to nodes that existed in previous versions of Message Broker.

Browsing WebSphere MQ messages with the MQInput and MQGet nodes

In previous versions of Message Broker, when the MQInput or MQGet node got a message from a queue, the message was always removed by a destructive MQGET call. In Message Broker V6.1 the ability to browse a queue has been added, meaning the contents of a message can be accessed but the message remains on the queue to be reused by the same or other applications.

This ability to browse is useful when configuration data or constants are stored on a queue and used multiple times, or when applications need to examine the content of a message before deciding whether to remove it from the queue. A single message can serve multiple MQInput or MQGet nodes when using browse:

Figure 1
Figure 1

Use browse to examine the contents of a message before determining whether to remove it from the queue – such as in this sample gallery flow:

Figure 2
Figure 2

To specify that the MQGET operation should include the browse option, check each node’s "Browse Only" property.

Using the MQOutput node without an MQMD

In previous versions of Message Broker, the use of an MQOuput node required the presence of a valid MQMD in the message assembly. In Message Broker V6.1 the MQOutput node will apply a default MQMD should one not exist. Users are therefore not required to add a Compute node to create an MQMD manually.

For example, in the Timeout Processing sample a Timeout Notification node operating in Automatic mode generates messages without MQMDs. Previously in this sample a Compute node AddMQMD was used to add a default MQMD, this step is no longer required as this processing is now done automatically by the MQOutput node.

Messages generated by a Timeout Notification node in Automatic mode no longer require an MQMD before they can be output by an MQOutput node:

Figure 3
Figure 3

Additional instances on the MQInput node

For message flows that contain more than one input node, the pool of additional instances is shared between all the input nodes. There is no guarantee which will get the additional instances and in some cases one node might get them all.

Additional instances can now also be set at a node level rather than just at a message flow level, avoiding thread starvation.

Use additional instance pools at a node level when you are unable to avoid the use of multiple input nodes within a single flow, and you wish to ensure that each input node will have a minimum number of instances. Additional instances can be set at a node level on the MQInput node’s properties. If a node is instructed to take additional instances from its own pool, then it is no longer entitled to additional instances from the message flow pool.

XSLTransform node

In Message Broker V6.1 the XMLTransformation node is now called the XSLTransform node.

Previously, a ResetContentDescriptor node was required downstream of the XMLTransformation node in order to specify parsing properties for the message as the results from the stylesheet were a BLOB and had no message domain, set, type or format specified. This can now be done by setting properties in the XSLTransform node’s Output Message Parsing panel so removing the need for the ResetContentDescriptor node. The XSLTransform node now lets you specify output properties for the message:

Figure 4
Figure 4

Switching Trace nodes on and off

In previous versions of Message Broker, Trace nodes could not realistically be left inline within message flows because, even with no trace destination set, there was a performance cost involved with each trace node. In Message Broker V6.1, you can disable Trace nodes for an execution group, or a message flow within an execution group, to improve performance.

When an execution group is created or a message flow is deployed, its Trace node switch is set to on by default (this includes execution groups and message flows migrated from a previous version).

If the Trace node setting for an execution group is off, all Trace nodes in its flows are disabled. If the Trace node setting for an execution group is on, the Trace node switch setting of each message flow determines the effective settings. Use the mqsichangetrace command with the –n option to enable or disable trace nodes. Use the mqsireporttrace command to check the settings for message flows and execution groups:

mqsichangetrace WBRK61_DEFAULT_BROKER -n off -e default [-f TraceNodeFlow]

You can also enable and disable trace nodes from the Broker Administration Perspective in the WebSphere Message Brokers Toolkit.

In addition to mqsichangetrace, the trace nodes can be disabled from the domains view:

Figure 5
Figure 5

XPath support

The XML Path Language (XPath) is used to uniquely identify or address parts of an XML document. In the Message Broker Toolkit, you can use XPath expressions as property values in supporting nodes. You can use the XPath Expression Builder to visually build XPath expressions to set the relevant properties. The XPath Expression Builder is launched from buttons located beside property fields in the Properties viewer.

The MQInput, HTTPInput and JMSInput are existing nodes that have added XPath support in V6.1.

Using Java in mapping nodes

Message mappings define the blueprint for deriving a target message from a number of possible sources such as input message elements, database tables, constant values or WebSphere MQ constants. Mappings are created using a drag and drop facility in which source elements are connected to target elements.

Functions can also be used within the Mapping node to make comparisons, perform arithmetic, or create complex conditions. The node can call predefined or user-defined functions such as ESQL, or now Java methods. There are two ways to call an existing Java method from a mapping node in Message Broker V6.1:

Select the method from the Call Java Method wizard

Figure 6
Figure 6

If the method requires input parameters, select one or more fields in the Source pane. In the Target pane, right-click the required target field to be mapped to the return value of the Java method and select Call Java Method. The Call Existing Java Method wizard opens. The target field must be a simple, non-wildcard type.

Enter an XPath expression in the Edit pane

Figure 7
Figure 7

Content Assist can be used by selecting it from the Edit menu. Input parameters can be added by dragging the appropriate source fields to the method's parameter area.

Security

Message Broker V6.1 extends security support, and as part of this provides a security manager. The security manager enables access to message flows to be controlled on a per message basis using the identity of the message. If message flow security is not enabled, the default security facilities in Message Broker are based on transport specific facilities. Instead of delegating this authority to the transport, the broker can:

  • Extract the identity from an inbound message.
  • Authenticate it (using an external security provider).
  • Map the identity to an alternative identity (using an external security provider).
  • Check that the alternative identity or the original identity is authorized to access the message flow (using an external security provider).
  • Propagate the alternative identity or the original identity with an outbound message.

Two external security providers are supported: Lightweight Directory Access Protocol (LDAP) for authentication and authorization, and Tivoli Federated Identity Manager (TFIM) for authentication, mapping, and authorization.

In V6.1, existing input nodes MQInput and HTTPInput support identity extraction. The MQOutput and HTTPRequest nodes support identity propagation.

Conclusion

WebSphere Message Broker V6.1 has introduced a lot of new function covering all aspects of message flow development to runtime deployment. In this article, we covered the new and enhanced node function support. There is new node support for:

  • Web Services
  • WebSphere Service Registry and Repository
  • Routing
  • WebSphere Adapters
  • File
  • Transport

There are new enhancements to existing nodes such as:

  • Browsing WebSphere MQ messages with MQInput and MQGet nodes
  • Using MQOutput node without an MQMD
  • Additional instances on the MQInput node
  • Specifying message parsing properties on the XSLTransform node
  • Switching Trace nodes on and off
  • XPath expression builder
  • Calling existing Java methods from the Mapping node
  • Extends security support to external security providers such as LDAP and TFIM for HTTP and MQ nodes

We hope you will find this article useful as a starting point for developing new broker applications or improving existing ones with the new capability that Message Broker has to offer.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=311770
ArticleTitle=New and enhanced nodes in WebSphere Message Broker V6.1
publish-date=05282008