SOA Infrastructure

In the past few weeks I've read a lot of news surrounding SOA. Sonic Software, for example, just recently launched v6.1 of its SOA focused ESB suite of tools. Sonic's latest release includes its new Collaboration Server, for managing partner interactions, and its Database Service, which is designed to ease interaction (and I assume, integration) with relational databases.
What Sonic and others are banking on is the need for a unified messaging platform under the hood of SOA in order to make services reliable and to provide unified access. Its ESB, like those from other SOA focused vendors such as Cape Clear, which also recently expanded its ESB product, is the core infrastructure upon which these vendors believe a fully realized SOA infrastructure can and should be built.
Indeed, they aren't far from the truth. With more and more services being deployed in the enterprise - often times unknowingly as part of packaged application upgrades - it is beginning to be time to consider what needs to be implemented to provide a solid foundation for an SOA. While unified access to services is definitely within our grasp, it remains to be seen whether composite applications built upon disparate services or SOBA (Service Oriented Business Applications), comprised of services both within and without the enterprise, can withstand the load of daily enterprise use.
Issues of message reliabilty, transaction integrity and integration remain to be addressed and an ESB (enterprise service bus) such as is offered by Sonic Software appears to be the frontrunner in the race to address this particular need.