"There’s no mention of interoperability with other clouds like Google or Salesforce.com; that will have to be left to third parties like Vordel" From Cloud Computing Journal: http://cloudcomputing.sys-con.com/node/1003149
Besides security, the other big push-back against Cloud Computing is interoperability. Most organizations do not want to have to choose one Cloud Computing vendor exclusively. Certainly, in cases like the US Government (with its new emphasis on Cloud Computing) , using a provider which doesn't explicitly offer interoperability with other providers is unthinkable.
Unfortunately, when a new Cloud Platform doesn't address the interoperability issue, it is adding to the problem, not fixing it. Gateways are the answer to that particular problem.
It is frightening to think about how many organizations deploy SOA (or even "just a bunch of Web Services") but have no idea about how the services are being used, who is using them, what the service uptime is, and what response times their clients are experiencing. Visibility is a big issue for SOA.
This is why we build VordelReporter. By sourcing its information from Vordel Gateways, it allows administrators to see in real-time who is using services. They can drill into individual gateways in order to see the usage and performance of services which are in that Gateway's sphere of control.
Using Gateways for SOA visibility is non-invasive, requiring no changes to the services themselves. By using the information from a product which is already deployed, the XML Gateway, it removes the danger of creating a new, standalone "SOA Governance silo".
You can do neat things like discover if a service is not performing to its SLA, and then take remedial action by offloading its XML processing on the Vordel Gateway where it benefits from XML Acceleration. Then you can see in real-time how the service response time increases. So you're actually solving a problem, using products which also perform other functions (acceleration, protocol mediation, content inspection) rather than just putting a "governance silo" in place for its own sake. With Gateways, if you discover that a service is running slowly, you an solve the problem by offloading processing onto the Gateway. With a standalone "SOA Governance silo", you can discover that a service is running slowly, but that is that.
Here's a short video showing the drill-down from a SOA topology, to a Gateway, to individual service invocations:
Paradoxically, one great feature of VordelReporter is that you don't even have to view its reports. How is that possible? The answer is that because VordelReporters real-time monitoring sources data from Vordel Gateways via a secured REST-ful pipe (here we are eating our own dogfood), can also simply send the metrics to products such as Oracle Enterprise Manager. This also helps SOA visibility, and is another example of using existing infrastructure rather than creating a "SOA Governance silo".
Tony Baer put it well back in January: "...we also believe that the run-time governance of SOA or services cannot be divorced from the physical aspects of running IT infrastructure. Service level management of SOA services is directly impacted by how effectively IT delivers business services, which is the discipline of IT Service Management (ITSM). When there is a problem with publishing a service, it should become an incident that is managed, not within its own SOA cocoon, but as an IT service event that might involve problems with software or infrastructure." http://www.sandhill.com/opinion/daily_blog.php?id=1&post=488
