mopdf.com

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.4.2.2.1 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.4.2.2.2 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.4.2.2.3 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.4.3.1.1 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.4.3.1.2 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.4.3.1.3 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.5.2.1.1 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.5.2.1.2 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