This is what customers want, said Christopher Lochhead, chief marketing officer of Mercury. They want a system of record, covering policy and interoperability.
Mercury, which began its life with testing tools, has shifted the spotlight towards IT governance. It has pointedly avoided the middleware deployment marketplace, where instead it has forged strategic deals with BEA and SAP.
So Mercury has staked claim to the development of software and tracking whether the software delivers what is promised.
It is deliberately ambiguous as to whether that means run time. Mercury has designed its governance tools to deal with the here and now so dashboards could indicate when promises such as service levels might be broken.
But where the rubber meets the road, actually instrumenting what happens on servers and networks remains the domain of the systems management frameworks, not Mercury’s Business Technology Optimization (BTO) centers.
As to Systinet, when we asked CEO Thomas Erickson how clients were using its registries, runtime discovery ranked far down as third of four use cases. When he describes current R&D, he focuses on idea like contract management with service consumers, a function that doesn’t exactly sound like runtime discovery.
To recap, UDDI was one of three core building block standards created for web services. As we noted last year (see Computergram, April 18 and 22, 2005), UDDI was the slowest of the three to attain adoption.
In large part, it was due to the fact that you needed the first two SOAP (the protocol for making services requests) and WSDL (the protocol for declaring, or describing the service being offered) before it made any sense to use registries. Furthermore, you only needed registries when you accumulated multiple services to track and manage.
But the notion of service requests discovering services on the fly has not been a popular one for several reasons. First, runtime discovery only makes sense if there are multiple services, or versions of services to choose from. In most cases, organizations are only now just starting to ramp up the number of services that they offer.
Another concern is governance or compliance. Theoretically, if you enforce policies properly, you shouldn’t have to worry about letting requests spontaneously discover services, because policies will be automatically enforced.
But the art or science of policy management in web services and services-oriented architectures is still sufficiently immature to give compliance officers the willys at the notion of introducing any sort of unpredictability.
In our earlier reports on UDDI, we noted that Systinet and rival Infravio were battling for hearts and minds, not with who could devise the better run time capability, but with thought leadership over service planning and governance.
Systinet launched its Governance Interoperability Framework (GIF), providing APIs for integrating user interface, alerts and notifications, and policy.
And it drew endorsement from nearly a dozen players like HP, Actional, AmberPoint, Reactivity, and Layer 7. Not to be outdone, Infravio asserted its claim to thought leadership with the Oasis SOA Blueprints initiative.
Either way, the direction of all these initiatives pretty thoroughly endorsed the notion that the value of UDDI was as a policy, rather than run time execution mechanism.
On the other hand, if Mercury with its governance framework were to shift Systinet’s focus towards real-time discovery, you could end up with a registry backed up with many of the governance features promoted by some of Systinet’s current partners, like Actional and AmberPoint.
Not surprisingly, when news of the deal went out over the wires, Systinet rivals like Flashline trash talked the deal, saying that Mercury’s entry would drive the loss of some of GIF partners.
However, neither Actional nor AmberPoint sounded concerned. They were both quite upbeat claiming that Mercury’s buy-in validated the need for SOA management. Of course, it wouldn’t make sense for both to say otherwise, because both share a quarter to a half of their business with Systinet.
Consequently, they certainly wouldn’t mind a stronger partner, and they certainly wouldn’t want to bait Mercury into invading their space.
Not that there isn’t any overlap. Mercury says that, with real-time updates to its governance dashboards, that it might duplicate some functions performed by the likes of Actional, AmberPoint, or SOAs Software (which offers a registry and an SOA management framework).
And of course, given Mercury’s current regulatory issues (it needs to get relisted onto Nasdaq), it’s not going to go out of its way and announce future initiatives, like whether it will do web services management. But our strategy is to remain in more of a Switzerland like position, said Zohar Gilad, senior vice president of Strategy at Mercury.
