webMethods Broker is deprecated for use with other webMethods products version 10.2 and higher. You can still use webMethods Broker 9.6 with these versions with the following limitations:
You cannot install webMethods Broker 9.6 in the same directory as other webMethods 10.2 (or higher) products. You will need to use an instance of webMethods Broker installed in a different directory (or different machine) from an older product version selection in Installer.
Although deprecated, the use of webMethods Broker is still supported by Software AG Global Support until the announced end-of-life dates of webMethods Broker.
I know this is a done deal and Broker is gone, but I want to express extreme disappointment.
I understand that UM, nee, Nirvana, is the chosen direction forward for SAG for messaging since the acquisition of my-Channels and that having multiple messaging tools can present challenges on a number of fronts.
But what do Broker users really gain when switching over to UM? The only major feature I see is active/active clustering – the need for which varies certainly but experience with Broker for the past many years shows that active/active for the messaging engine isn’t necessary for many (most?) implementations.
So now we get to go through the same growing pains we lived through back in the day with Broker. We get to replace the one component that is stable and not the source of any real trouble with one that is less so. Just to get back the functionality we already had.
When my-Channels was acquired, there was an SAG blog post stating “Nirvana was rock-solid, never failed and continued to perform predictably and reliably.” One could have substituted in “Broker” for Nirvana in that and would still be an accurate statement.
SAG will eventually work through and resolve the issues of IS and UM interactions, the same way the same sort of issues were resolved when IS and Broker were first tied together. It’s just a bit aggravating to have to go through that for no meaningful additional capability.
Agreed, there may be some pain in adopting UM, but, for large installations, I can see the benefit of a single IS being able to connect to multiple UM Servers as opposed to being able to connect to only one Broker Server.
Oh right. I forgot about that. I recall being disappointed when IS and Broker were really integrated and IS could connect to just 1 Broker – and switching the Broker was painful, if needed, so it was something to be avoided.
I guess I forgot about that because after a time it wasn’t really an issue, even for large installations. With territories as an alternate approach of sorts, one could effectively set up a multi-Broker environment. Also, one could use JMS instead – you could connect multiple to providers (including Broker, with caveats).
But indeed being able to connect to multiple Brokers would have been a nice option to have had. Thus, connecting to multiple UM is a nice option too.
