Barry Briggs writes:
Here’s the conundrum (or at least thought experiment): today, integration servers largely serve the purpose of normalizing, or at least putting a facade upon, a wide variety of heterogeneous API’s, protocols, data formats, security models, transaction models, and so on.
Now, let’s posit a world in which all legacy protocols and formats melt away in favor of SOAP, XML, and WS-*. We all know that this transition won’t happen overnight — it may take decades, but that the transition over some period of time is inevitable is our assumption. So, if all these messy issues are going away, then does the integration broker go with them?
Put a different way: if every business application in your computing ecosystem exposes rich, standards-compliant services, then does the traditional hub-and-spoke model of integration still have value?
We need a refined notion of sequencing of services, of process, and we need a hosting environment where those processes can run, can be monitored, can be tracked. In the bad old days it was easy to do quick and dirty integration applications by writing a little VB here, a little Java there, and getting the data from one system to another in a point to point way. But as we learned, this didn’t scale; it was completely unmanageable. Today we recognize we want a server that provides the process execution environment.
