Much noise has been made in recent months about SOA governance and management. Acquisitions, pronouncements, etc. One reason I believe that Microsoft’s SOA story is not well understood by many customers and software architects is that we don’t offer much in the way of technology in those spaces. And we’re very reluctant to pile on to the hype-cycle on SOA, we’re not a faddish company.
The untold story about Microsoft technology is that when it comes to SOA governance and management, you’d be hard pressed to find software that is easier to configure, manage and, well...govern.
Craig McMurtry is a rock star Technical Evangelist in our Platform Evangelism group in Redmond. He’s done a superb job of explaining the story and demonstrating how the Microsoft application platform can be used in conjunction with the industry’s widely used governance and management software. I’m passing this along for your reading pleasure. If you are interested in learning more please post a comment or send us email via the blog.
Take it away Craig…
Background: Windows Communication Foundation (WCF) has a superb management story:
The governance story that folk also want to hear is how all the services in the enterprise can be discovered, monitored and controlled from a central point.
In particular, CTO’s apparently dream about being able to centrally mandate policies to which selected services must conform.
Systinet, recently acquired by Mercury, and then more-recently by HP, is a leader in the “SOA Governance” space.
Their Systinet 2 suite sits in front of a UDDI registry. Services enumerated in the UDDI registry are surfaced in the suite and their conformity or otherwise to stipulated policies can be evaluated.
Thanks to WCF’s interop, flexibility and extensibility, WCF can be used together with Systinet 2 to make the CTO’s dream come true.
As shown in this video, I’ve programmed a Custom Service Host for WCF, which registers services as they come on-line, and periodically checks the registry for policy updates.
When the policies associated with the service change in the registry, the host restarts the service, and brings it back online reconfigured to conform to the policies stipulated in the registry.
Those of you familiar with WS-Policy will know that it merely defines a wrapper for any kind of policy expression whatsoever, and so naturally you can’t just invent a new policy and expect that my Policy Enforcement Host will be able to configure the service to conform to the policy. However, there is already an extension point within WCF that I rely upon that will allow you to plug in a policy interpreter for any arbitrary policy that you could author.
Any of the numerous WS-* policies that WCF already knows about simply work thanks to this line of code that WCF’s Description namespace allows me write:
Collection<Binding> bindings = new WsdlImporter(MetadataSet.ReadFrom(new XmlTextReader(this.metadataStream))).ImportAllBindings();
… which simply points WCF at stream of metadata, including WS-Policy, and gets an array of appropriately configured bindings in response.
And to be clear: this is simply a vanilla line of WCF code—my involvement in it is merely in making sure that this.metadataStream has the stream of metadata implied by the registry.
In a competitive situation, I would be inclined to ask to see the corresponding line of code from anyone else’s solution, because without that line of code, all the rest is vapor.
Also, Systinet implementations generally require an intermediate management layer, so the architecture is Systinet ß à eg. AmberPoint ß à Web services, whereas with WCF, you simply get Systinet ß à WCF, because WCF already has all the management tools and the extensibility (see above), so on our side, we’re discounting several $100K in licenses and consulting fees to make the governance dream come true.
Well, there you have it. Questions? Fire away!