One interesting section of this document on Reliability is a bit of a pet peeve for me -
Anyone who has worked with the product knows it doesn’t work this way out of the box. It takes a serious amount of architecting at the IS and broker level to achieve this. It also takes architecting at the flow level to achieve this as well (think handling runtime failures with database connections, or ftp or http etc).
The other issue is the comment about distributed architecture. webMethods components tend to be pretty heavy for distributed architecture. And with the introduction of the my webMethods Server it is getting a bit worse(Eventually all administration of webMethods components will be done through the MwS which requires a one to one relationship with an IS Server). Yes you can distribute the individual components but again it takes a fair amount of architecting to achieve the right balance.
In the end, it can be done of course. My main issue is the tone of the document makes it sound a lot easier than it actually is.
I always chuckle when statements like “eliminates the single-point-of-failure liability associated with pure hub-and-spoke systems” are made. Are they kidding me? All of their docs tend to lead one to create a pure hub and spoke solution, with Broker in the center of it all. Now Broker is very rock solid, but it is the single point of failure in most of the solutions I’ve seen–lose the Broker and service is down. It doesn’t matter if the IS is still running if it can’t talk to anyone.
I agree on the components being a bit heavy for distributing. Prior threads have covered this a bit where the discussion focused on IS as adapter run-time vs. the old model. Licensing is another aspect that tends to force centralized solutions, IMO.