In many ways, the use of canonicals could be comparable to an SOA strategy with some similar challenges.
As already mentioned, you get the benefit of reuse rather than building multiple parts. This reuse provides the ability to build additional integrations off the base more quickly as well as a more stable environment because there are actually fewer integrations to a single source/target.
In an SOA strategy, the canonical is instead replaced by reusable web services which provides the ability to build more complex integrations even faster.
Whether using web services or canonicals, you will always encounter the challenge of managing change. Updating a canonical or web service that is being leveraged by hundreds of other integrations opens up the door for severe problems. Much like modifying a method that is being used throughout a custom application, you would need the ability to test and ensure that all of the services/messages further down the logical path, at every ‘step’ within an integration, are not affected.
Solstice Software has an integration test suite that allows you to record/replay a baseline at the message/service execution level and solves this problem.
In the interest of full disclosure, I am an employee of Solstice Software and am pointing this out because it is relevant to the discussion at hand. One of the Moderators, Mark Carlson, advised me that relevant postings should be posted but also asked me to point out that I am an employee when referencing Solstice.
#Flow-and-Java-services#webMethods#Integration-Server-and-ESB