Solace Integration with IBMDataPowerDocument Version 1.3October 2018This document is an integration guide for using Solace with IBM DataPower.Solace message routers unify many kinds of data movement so companies can efficiently andcost-effectively move all of the information associated with better serving customers and makingsmarter decisions. The Solace 3560 message router is the highest performance data movementtechnology available, with the capacity and robustness to support the most demanding enterprisemessaging, big data, cloud computing and Internet of Things applications.IBM WebSphere DataPower Appliances offer purpose built hardware appliances which focus onsecurely delivering advanced services and applications. With a focus on service-orientedarchitecture connectivity, these appliances enable application integration, transformation, anddynamic content routing and natively support a variety of connectivity options including HTTPREST and JSON integration.Similar to Solace message routers for messaging, DataPower appliances cut operations costs,reduce complexity and improve performance of businesses service-oriented architectures andenterprise service busses. Solace Corporation.

Solace Integration with IBM DataPowerTable of ContentsSolace Integration with IBM DataPower. 1Table of Contents . 21 About This Document . 31.1 Related Documentation . 32Why Solace . 4Superior Performance. 4Robustness . 4Simple Architecture. 4Simple Operations . 4Cost Savings . 43Overview . 53.1 Solace REST Interface . 53.2 Introduction to IBM DataPower Integration with Solace . 54IBM DataPower Integration – Sending to Solace . 74.1 Using a Direct HTTP Back-End for each Service . 74.1.1 Benefits.74.2 Using Central Multi-Protocol Gateway for Solace connectivity . 84.2.1 Architecture Overview .84.2.2 DataPower Configuration .84.2.3 Benefits.94.3 Integration Notes . 104.3.1 Header Injection.104.3.2 Configuring for Solace HTTP Basic authentication .105IBM DataPower Integration – Receiving from Solace. 115.1 Individual External DataPower Services . 115.1.1 Architecture Overview .115.2 Enterprise Gateway Framework Pattern . Overview .12Integrating with the Solace Message Router .14Managing Services .15Benefits.15IBM DataPower Integration – Use Cases. 166.1 API Integration . 166.2 Mainframe Integration. 166.3 B2B Integration . 172

Solace Integration with IBM DataPower1 About This DocumentThis document is intended for system architects and developers to understand the architecture, features anddeployment patterns related to integrating IBM DataPower appliances with Solace message routers. Solace messagerouters can replace existing IBM WebSphere MQ in DataPower applications improving existing architectures andenabling new next generation functionality. The goal of this document is to help architects and developers to integrateeffectively and efficiently with the Solace message router so DataPower configuration is minimized and overall systemperformance is maximized.This document assumes that the reader is familiar Solace message routers and as appropriate with IBM DataPowerappliances.1.1 Related DocumentationThese documents contain information related to the feature defined in this documentDocument IDDocument TitleDocument Source[Solace-Portal]Solace Developer Portal[IBM DW DPGW]Implementing the Enterprise Gateway Frameworkservice for WebSphere ere/library/techarticles/1211 saddal/1211 saddal.html[SOL FG]Solace Messaging Platform Feature latform-featureguide[SOL REST CON]Solace REST Integration est-messaging-concepts[SOL PRTCL REST]Solace REST Interface est-messaging-protocolguideTable 1 - Related Documents3

Solace Integration with IBM DataPower2 Why SolaceSolace technology efficiently moves information between all kinds of applications, users and devices, anywhere in theworld, over all kinds of networks. Solace makes its state-of-the-art data movement capabilities available via hardwareand software “message routers” that can meet the needs of any application or deployment environment. Solace’sunique solution offers unmatched capacity, performance, robustness and TCO so our customers can focus on seizingbusiness opportunities instead of building and maintaining complex data distribution infrastructure.Superior PerformanceSolace’s hardware and software messaging middleware products can cost-effectively meet the performance needs ofany application, with feature parity and interoperability that lets companies start small and scale to support highervolume or more demanding requirements over time, and purpose-built appliances that offer 50-100x higherperformance than any other technology for customers or applications that require extremely high capacity or lowlatency.RobustnessSolace offers high availability (HA) and disaster recovery (DR) without the need for 3rd party products, and fast failovertimes no other solution can match. Distributing data via dedicated TCP connections ensures an orderly, well-behavedsystem under load, and patented techniques ensure that the performance of publishers and high-speed consumers isnever impacted by slow consumers.Simple ArchitectureModern enterprises run applications that demand many kinds of data movement such as persistent messaging, webstreaming, WAN distribution and cloud-based communications. By supporting all kinds of data movement with a unifiedplatform that can be deployed as a small-footprint software broker or high-capacity rack-mounted appliance, Solace letsarchitects design an end-to-end infrastructure that’s easy to build applications for, integrate with existing technologies,secure and scale.Simple OperationsSolace’s solution features a shared administration framework for all kinds of data movement, deployment models andnetwork environments so it’s easy for IT staff to deploy, monitor, manage and upgrade their Solace-based messagingenvironment.Cost SavingsSolace reduces expenses with high-capacity hardware, flexible software, and the ability to deploy the right solution foreach problem. Solace’s support for many kinds of messaging lets you replace multiple messaging products with justone, built-in HA, DR, WAN and Web functionality eliminate the need for third-party products.4

Solace Integration with IBM DataPower3 OverviewThe Solace REST interface allows for easy integration with DataPower appliances enabling the Solace message routerto be an excellent choice for the messaging backbone for DataPower applications. The Solace REST interface isexplained in the referenced document [SOL REST CON].3.1 Solace REST InterfaceThe Solace REST interface makes use of bi-directional HTTP POST requests to exchange messages in both directionsas show in the following figure. This enables REST clients to send messages to and receive messages from any Solacemessage router clients.REST producers send message contents in the body of an HTTP POST request. For request / reply scenarios, theresponse contents are carried in the body of the HTTP POST 200 OK responses. For REST consumers, the Solacemessage router sends the message in the body of an HTTP POST request. And again for request / reply scenarios, theresponse contents are carried in the HTTP POST 200 OK responses. This is explained in more detail in both the[SOL FG] and [SOL PRTCL REST] documents.The use of bidirectional HTTP POST requests in both directions has several benefits. First it removes the possibility ofmessage loss which can exist when using HTTP GET requests to poll for messages. It also enables much higherperformance and overall message rate when multiple, parallel HTTP connections are used.3.2 Introduction to IBM DataPower Integration with SolaceIf you take an existing DataPower architecture and then migrate this to using Solace as the messaging backbone youcan end up with an architecture that looks like the following.5

Solace Integration with IBM DataPowerThe Solace message router can handle the messaging needs of most of the applications. Legacy Native MQIapplications can maintain connectivity via the DataPower appliance. DataPower appliances interface with themainframe and continue to handle the transformation requirement of the services. By adding a Solace message routerto the architecture, it enables new next generation applications like Big Data, Cloud, IoT etc.The next sections of the document provide more details on how to integrate a DataPower appliance with Solacemessage routers for messaging, including best practices, and a look at some sample use cases. It is divided into thefollowing sections to accomplish this.1.IBM DataPower Integration – Sending to Solace2.IBM DataPower Integration – Receiving Message from Solace3.IBM DataPower Integration – Use Cases6

Solace Integration with IBM DataPower4 IBM DataPower Integration – Sending to SolaceThis section looks at how to enable DataPower to send messages to a Solace message router. There are two mainpatterns to consider. Direct HTTP Back-End connectivity to Solace. Using a common Solace integration Multi-Protocol GatewayMost often for large deployments, the common Solace integration Multi-Protocol Gateway will work nicely and parallelexisting MQ Queue Manager or Cluster configuration. However, for small configuration where the maintenance load isnot large connecting each DataPower service directly to Solace works well.The sections that follow get into the details of each of these patterns and look at the relative benefits.4.1 Using a Direct HTTP Back-End for each ServiceFor simple DataPower configurations with only a small number of services, the easiest way to integrate with the Solaceappliance is to simply use an HTTP back end that points to the Solace REST interface IP and port. This could beaccomplished by either using a static back end or a dynamic back end configured in the multi-protocol gateway policy.Directly connecting the DataPower service to the Solace REST interface would give you an overall architecture thatresembles the following figure.Each service individually connects to the Solace appliance to send messages. This means that each service canindependently configure the Solace connectivity.4.1.1BenefitsThe benefit of this approach is that it is very simple to setup and use. It also allows each service a unique configurationof the connection if that were required. However, as the number of services scale the maintenance requirement ofdirectly connecting each service to Solace will also grow. Eventually it often becomes simpler to use the central MultiProtocol Gateway for Solace connectivity as described in the next section.7

Solace Integration with IBM DataPower4.2 Using Central Multi-Protocol Gateway for Solace connectivityThe goal of creating a common shared multi-protocol gateway for Solace connectivity is to allow administrators tocentralize and group some common properties together in a shared multi-protocol gateway to minimize maintenanceoverhead. This is similar to how MQ queue managers contain shared connectivity related properties and can be usedby many multi-protocol gateway services in parallel as the messaging back-end.4.2.1Architecture OverviewThe following figure outlines this architecture. In DataPower, a Solace multi-protocol gateway is created. This multiprotocol gateway handles the connectivity to Solace. This allows admins to specify common connection properties thatapply to all Solace messaging like connection timeouts and certain message properties. Then DataPower services usethis multi-protocol gateway as their back-end.On the Solace appliance, this will create one or more Solace REST clients depending on the number of parallel HTTPconnections configured in DataPower. When messages arrive at the Solace message router they are converted to theinternal Solace message format (SMF) and routed as normal messages. They then can be received by any clients. Thiscan be JMS, SMF, MQTT, HTTP or any other client that Solace supports.4.2.2DataPower ConfigurationThe DataPower required configuration can be divided into two parts. Solace Multi-Protocol Gateway Creation Individual Service Configuration UpdatesThese are described in the subsequent sections. Solace Multi-Protocol Gateway CreationThe Solace Multi-Protocol Gateway is very similar to an MQ queue manager of queue manager cluster in function. InMQ the queue manager contains connection properties like host name, channel name, heartbeat, username etc. It isconvenient to group these properties in a single DataPower configuration object and then reuse this object across manyDataPower services that need messaging.8

Solace Integration with IBM DataPowerThe Solace Multi-Protocol Gateway performs the same role. It is where Solace connectivity details can be configuredlike the Solace host IP and port, Solace client username. It is also a good place to tune DataPower properties related tothe HTTP connection like HTTP persistent connection timeout, HTTP response timeout, error handling, etc.In addition the Solace Multi-Protocol Gateway can be a good place to inject some Solace specific HTTP headers tocustomize the messaging behavior for all clients. For example it might make sense to set the following properties: Solace-DMQ-Eligible – Enforce that all messages are DMQ eligible. Solace-Time-To-Live-In-ms – Apply a common time to live for all messages sent Solace-Delivery-Mode – Enforce that all messages are sent with a specific delivery mode like persistent. Solace-User-Property – Add some common custom properties to all messages for end application processing.These properties and their values are described in more detail in the [SOL PRTCL REST] document.In addition this Solace Multi-Protocol Gateway can contain the Solace authentication and authorization configuration. Individual Services Configuration UpdatesIndividual DataPower services can enable sending to Solace by setting the Solace multi-protocol gateway as the backend either statically or dynamically within the policy. In general this is sufficient to allow a service to send messages viathe Solace message router.However, services may want to enhance their policies to take advantage of some of the additional Solace RESTinterface features. For request / reply scenarios, a service will need to set one of the Solace properties which signal thereply to the Solace message router depending on whether the reply is synchronous or asynchronous. Solace-Reply-Wait-Time-In-ms – This property specifies how long to wait for a synchronous reply. The replycontents will be received in the body of the response. Solace-Reply-To-Destination – This property specifies that the reply should be returned to a specificdestination. This reply will be received asynchronously be DataPower through a configured front side handler.The message can be correlated using the correlation ID. Solace-Correlation-ID – Allows the specification of a correlation ID string to allow DataPower to correlateasynchronous replies with the original message that was sent. Solace-User-Property – These properties allow the specification of custom header properties. In this wayapplications can provide end systems with additional information about message content and format or anyother message properties that are required.These properties and their values are described in more detail in the [SOL PRTCL REST] document. Solace ConfigurationOn the Solace appliance, the configuration is minor. The REST service must be enabled globally on the Solacemessage router and within the message VPN it must have a port assigned and the service must be enabled. This willallow basic message flow to be established.More advanced configuration can enable SSL and different client authentication options. This is documented in the[SOL FG].4.2.3BenefitsAs outlined in the previous sections, the main benefit of this approach is that it allows DataPower admins to centralizethe connectivity to Solace in the same way as they would normally do with IBM MQ. This means that porting existingservices from IBM MQ for messaging to Solace is easy and straight forward. It also allows new services to be addedeasily with only minor per service configuration. Overall system maintenance costs will decrease with the architecturalsimplicity.9

Solace Integration with IBM DataPower4.3 Integration NotesThis section provides some notes and best practices when integration DataPower with Solace.4.3.1Header InjectionThe Solace REST interface makes use of HTTP headers to signal message properties. As such it is often required toset message headers within DataPower. The following sections outline some common ways of accomplishing this. Static Header InjectionFor instances where the HTTP headers needed are static, it is easy to use the header injection contained in the multiprotocol gateway. In DataPower this is found in the GUI admin under the multi-protocol Gateway’s “Headers Tab”. Hereit is possible to added static header injection or suppression. You can also control which direction this applies to so thatit is possible to inject the headers only on sending on the back end towards Solace. Dynamic Header Injection using User AgentsThe User Agent is also a convenient place to inject HTTP headers. User Agents are configured as part of a MultiProtocol Gateway’s XML Manager. They contain a “inject header policy”. It is this tab that it is possible to inject headersbased on URL match criteria. This makes it possible to dynamically inject headers based on the URL of the messagebeing processed. Dynamic Header Injection using a Transform actionIt is also possible to add headers in the transform action of the multi-protocol gateway policy. Adding a header in theXSL transform provides the most flexibility in criteria to dynamically trigger the header injection. It is however likely themost advanced of the options discussed as well.Headers can be added in the transform by using the “set-request-header” XSLT extension function provided byDataPower. For example to set the Solace-Reply-Wait-Time-In-ms to 30 seconds you would add the following to thetransform. dp:set-request-header name " Solace-Reply-Wait-Time-In-ms" value "'30000'"/ 4.3.2Configuring for Solace HTTP Basic authenticationWhen using HTTP basic authorization, there are multiple support ways to have DataPower include the basicauthorization header in the outgoing HTTP request towards Solace. One convenient method is to use the user agentheader injection to add the correct HTTP authorization header.10

Solace Integration with IBM DataPower5 IBM DataPower Integration – Receiving from SolaceThis section looks at how to integrate a Solace message router so it can send messages to a DataPower applianceeffectively and efficiently.There are two main patterns to consider. Exposing each service externally individually – Useful for fine grained control over a small number of services. Enterprise Gateway Framework Service – Useful if there is a large number of DataPower services to manage.Choosing which pattern will work best in an existing deployment will be related to how this deployment is configuredcurrently. Often DataPower architectures with a large number of services will have followed the IBM best practice ofcreating an Enterprise Gateway Framework service to act as a common entry point for DataPower. If so then it makessense to continue to use this approach when enabling Solace message routers to send to DataPower.If there are a smaller number of services to manage or for other reasons each service must maintain its own externallyaccessible front side handler, then again this is the approach that should be used when integrating with Solace.However in general this approach will lead to higher overall maintenance. So far large deployments it is often not thebest choice.These patterns are described in more detail in the sections that follow.5.1 Individual External DataPower ServicesFor deployments where there is only a small number of DataPower services involved it can make sense to keep theDataPower appliance configuration simplified. To do this each service maintains its own unique external front sidehandlers. Then Solace is configured to connect to these different services directly. The simplicity of the DataPowerappliance configuration requires that the Solace message router configuration be more complex.As the deployment grows and the number of services on DataPower grows this architecture will hit the drawbacks thatare addressed by the Enterprise Gateway Framework service. These drawbacks are that maintenance andconfiguration overhead for adding new services become more complex and the overall architecture configuration will bemore difficult to maintain.5.1.1Architecture OverviewWhen Solace message routers are integrated with DataPower appliance that are setup to expose each individualservice on a different IP and port, the Solace message router configuration must be adapted to match each service.The following figure shows an example of how this would be accomplished.11

Solace Integration with IBM DataPowerOn the Solace message router, there still needs to be one queue for each target service. However, because eachservice has its own unique IP and port for connectivity, each DataPower service will need to have its own RESTdelivery point in order to have traffic correctly routed to the service by the Solace message router. So each service willhave a REST delivery point with a single queue binding and one or more REST consumers configured depending onscale and fault tolerance needs of the service.5.2 Enterprise Gateway Framework PatternThe Enterprise Gateway Framework service is a configuration pattern for WebSphere DataPower that minimizes thenumber of DataPower service ports that need to be configured enabling easier external management of DataPowerconfiguration in firewalls or the Solace message routers. It makes it easy to roll out new services on DataPower.This service architecture is described in the IBM developerWorks article referenced in [IBM DW DPGW]. The followingsections describe the Enterprise Gateway Framework service as it applies to integrating with Solace message routers.5.2.1Architecture OverviewAll services running within WebSphere DataPower require a unique IP and port combination. In general, as the numberof services installed on a DataPower appliance grows then this can lead to a large number of external ports beingrequired with corresponding configuration in firewalls and other systems. This can cause a maintenance burdenmaintaining all the matching configurations.Specifically when integrating with a Solace message router, the requirement to have a unique IP and port per serviceoften leads to a single REST delivery point object being required for each DataPower service. This requirement createsextra maintenance overhead on the Solace message router in a similar way to firewall configuration.IBM suggests a simple solution for dealing with this issue which applies equally well to integration with the Solacemessage router. This is to create a framework service or single entry point service on the DataPower appliance. Thisservice is called the Enterprise Gateway Framework service. For integration with Solace message routers, this solutionprovides the following features which address the issues mentioned above. Provide a single point of entry for all services running inside DataPower. Handle requests over HTTP, HTTPs protocols.12

Solace Integration with IBM DataPower Requires only two ports (one for HTTP and one for HTTPs) to be configured in the firewall. The service canoptionally be configured to use the standard HTTP (80) or HTTPS (443) ports to simplify any firewallconfiguration. Authenticate all incoming requests based on the security requirement, such as mutual authentication or oneway SSL. Identify the client from the incoming request and route the request to the appropriate service or backenddestination. Deploy once to any WebSphere DataPower environment and require no code changes to incorporate newservices. Each DataPower service has a unique URL that is made accessible externally through dynamic routing in theEnterprise Gateway Framework service. On the Solace message router, requests for each service are stored in separate queues. Each queue will havea unique queue binding within the REST delivery point which allows messages to be routed to the appropriateDataPower service by the External Gateway Framework service.Because of these benefits, this is the preferred way to integrate Solace message routers with DataPower applianceswhen Solace sends messages to DataPower appliances with many services. Creating a DataPower Enterprise Gateway Framework ServiceThe process of creating an Enterprise Gateway Framework service for integration with Solace is no different than thegeneric gateway service described in [IBM DW DPGW]. For a step by step walk through of how to create this servicesee the IBM document. This section will describe the different components that you will create and how they are used. Environment ConfigurationIBM recommends creating a transform and corresponding XML file to indicate the type of environment for theDataPower appliance. This would generally be one of DEV, QA, or PROD but can be customized as requireddepending on individual company needs. These values in the configuration file must simply match the values used late

IBM WebSphere DataPower Appliances offer purpose built hardware appliances which focus on securely delivering advanced services and applications. With a focus on service-oriented architecture connectivity, these appli