Bridging tools allow a communications protocol or methodology change.Generally bridging tools are unique one-off solutions and need to be avoided in a SOA integration environment. There will be some instances where only a bridging tool will do, those are when basically the only way to connect or bridge is via that tool.
The general rule is reduce bridging tools to the minimum set needed, and use the more generic SOA bus tools to replace them with a single tool or a suite.
Why? Bridging tools usually require their own environment (their own server or region) and have specialized configuration parameters and settings. Supporting them is supporting another complete application and technology. But because they are narrow use, the knowledge to support them is usually concentrated within a small group (often just 1 or 2 people).
Often a variety of bridging tools are being used in an enterprise as they were brought in over time to make connections that only they could make...at that time. Some years later the enterprise may find itself with a collection of many such tools that could easily be replaced with a newer more global tool or even a direct switch to HTTP Web Services.
Don't perpetuate the use of the narrow tools, and take advantage of projects that touch the space to migrate the older connections from them. These narrow technologies often are a major source of integration unreliability, and maintenance costs!
Just because it's from IBM or Oracle doesn't mean it's not a narrow bridging tool. Older helpful integration products have been supplanted by easy web service interfaces. Bridging tools extended with or as transformation engines are still narrow, expensive, specialized, and have been supplanted by ESB capabilities.