Design time Service Governance: I am particularly happy to see this category listed on the chopping block (from David's perspective) and here is why. Over the last decade or so, we have seen significant run-time SOA Governance deployments at the edge of an enterprise used for interacting with SaaS platforms using SOAP, XML or REST. We have seen customers choose not use glorified UDDI registries. Instead, they have focused on using the SOA/Cloud/XML Governance Gateway as the system of truth for services produced and consumed (import and export WSDLs). The Gateways serve as the catalog of services aggregated for centralize control at design-time. Based on consumer credentials, access to only authorized services is provided to the consumer.
David is spot on in stating: "Many of the existing runtime SOA governance players support enough design and implementation capabilities that separate design-time tools are not required." The burden of design-time SOA Governance has entirely been taken over by XML Gateways including service generation and consumption, service cataloguing, service virtualization, and most importantly, service monitoring. Gateways are, by nature, non-intrusive and agent-less, whereas classic service monitoring companies are historically rooted in agent-based monitoring with weak gateway products, if any. Such agent-based solutions are unlikely to work in highly distrubuted environments typical of cloud computing. Try asking your SaaS partner to put an agent in their container -- good luck!
The writing is on the wall, so I quote David here directly:
Cloud computing is simply accelerating the focus on the requirement for runtime SOA governance, and sooner or later design time will fall by the wayside.For addtional technologies that face a not-so-fun-filled future, see David's ominous article: "Cloud Computing will kill these three technologies."
cyfuture cloud
ReplyDelete