Having experience with various EAI and ESB tools like Oracle Service Bus (former BEA Aqualogic) and Webmethods summary would be that everything can be done with any technology.
However the difference may be the time needed in order to implement the same integration features based on the existing product features.
From my point of view a good EAI and ESB solution needs to have what Webmethods offers
- a layer on top to isolate developers from the J2EE implementation ie to avoid implementing integration services in pure Java as if you were just coding the integration in Java
- Provides needed adapters yes, but with an intuitive front end that allows you to configure and use them (e.g setup number of retries for transient connectivity errors) rather than program in Java to implement calls to use the adapters
- A platform that allows continuous integration with a deployment engine and dependencies (and their changes) resolved and centralized in the server as a repository.
Some features reviewed
- Unit testing & Debugging capabilities: Webmethods allows you to debug your services in a step by step mode with variable watchers whereas in other programming oriented EAI solutions the testing in not dynamic and we can only rely in SOAPUI executions and reviewing returned XMLs and logs. From my point of view this is a decision driver.
- Data Mapping capabilities and XML management: In Webmethods you don’t need to work with XML parsing (if you don’t really want to) and data mapping and transformation is natural and based on UI drag&drop capabilities (No need to use XQuery or XPath if not needed). In webmethods you work with the Pipeline concept and needed transformations using a GUI designer. Canonical document transformations can be created fairly simple. Document structure/schemas are centralized in the server repository so there are no discrepancies when a document structure changes. If a document structure changes all services using that document get automatically updated. I still recall how complicated it was to manage XML transformations, parsing and schema dependencies within other EAI packages. Mapping was basically relying again on coding, XSLT transformation and library dependencies.
- In other solutions, basic tasks (like setting up a DB connection and test that) should not start a huge discussion troubleshoot thread leading the developer to spend most of his time troubleshooting and discussing about technical issues e.g not why he/she cannot connect to the database.
- Deployment and code changes: Webmethods has a central repository where an app dev resource is locking a given resource. Until that resource is unlocked nobody else can work on that item. Once a component is changed there is no deployment, changes are already in that environment. Once the code has been changed and unit tested migrating this to the next environment is a matter of a couple of clicks (no need to restart the server or wait minutes before you can see the changes). This helps having a system that allows maintaining continuous integration.
- Audit and logs: This is natural and simple in Webmethods, you can flag any service to be audited in their log database (on success and/or errors, when the service starts, exits, including parameters or not). You don’t need to have any extra coding for that. You can then use those logs to run your reports in SQLServer.
- Small features that help speeding up development, just as an example: commenting steps in an integration process is fairly simple in Webmethods while in other EAI solutions is a nightmare or impossible.