The primary feature the Broker brings to the table is the pub/sub facility. It’s been my experience that most business integrations don’t require pub/sub. Pub/sub is a great decoupling mechanism but quite often processing requirements end up negating that decoupling (I need to make sure that the PO got to app X, I need to send 10,000 records as a group to be processed by a DB, etc.). Even one of the main operations of pub/sub, the request/reply, works to re-couple applications.
IMO webMethods positioning of IS and the Broker is confusing. We hear the same question repeatedly–when to use IS alone and when to use the Broker? It isn’t clear. wM positions IS as both a Broker adapter run-time and as stand-alone integration broker. This is why things are confusing.
IS has been and is still a very capable integration broker. It can handle real-time, event-driven processes. It can support multiple integration points. The concept of source–>canonical–>target formats is just as doable in IS as it is in the Broker. Dispersing IS boxes geographically offers the same advantages as dispersing Broker boxes. Pub/sub is doable in IS though it requires a bit more work for pre-6 versions.
The pub/sub facilities of the Broker need to be rolled into IS. And the idea of a “small footprint” IS for an adapter run-time to easily enable the distribution of adapters needs to be accelerated.
IMO, if an integration can be accomplished without the Broker then it should be done that way. The Broker is helpful when: 1) there are multiple subscribers to events (Is the magic number 2? 5? 100? That’s up to individual architects.) 2) the subscribers will change from time to time (If subscribers don’t change, then what’s the point?).
Lest someone think I’m an IS bigot that has never used Broker, I’ve used Broker for several years, back to the Active Software days. It’s a powerful tool. But IMO IS is better, on many counts.
My 2 bits.