|
Anne brings up some interesting points. There is some overlap between ESB, Web Services Management, and pure-play Web Services Platforms. However, I don't think anyone should take this as spelling gloom and doom for ESB. She is pointing out that there is going to be some consolidation in functionality and shakeout in the number of vendors as the lines between these different product categories blur. I'm OK with her conclusion "In the long run, maybe 4-5 players will survive. My bets are on Sonic, Systinet, TIBCO, and webMethods." :-)
One place where I disagree with her and with Rich Turner is on the view that the addition of more robust WS-* support such as WS-Rel* and WSS into the application platforms will greatly diminish the value of an ESB. An ESB is based on a philosophy that the entire design center around a SOA is about the "whitespace" that is between the endpoints--not just the SOAP stack at the endpoints themselves.
Process coordination, routing of service invocation based on the content of the message that represents the service invocation, data transformation, auditing and process tracking are all integral parts of an ESB implementation. Having WS-Rel* and WSS built into some of the application endpoints doesn't necessarily give you all of that by default. An ESB will still provide value as the common infrastructure between the various implementations (and interpretations) of WS-* specifications.
In fact, an ESB can even provide a degree of insulation from the uncertainty that exists today with overlapping standards initiatives. Because an ESB is all based on standards, and is capable of evolving with standards as different ones become predominant, its a much safer bet.
And what of the application endpoints that aren't built in .NET or some other "superplatform"?
Can all IT departments out there safely say that they have a roadmap that shows all applications will migrate to .NET, WLS, SAP etc or else?
Dave
|
