Mercury Interactive’s announcement earlier this week that it is to acquire UDDI repository specialist Systinet could be taken to show that the UDDI standard has utterly failed to live up to its expectations. One of its leading proponents has just been taken out. So is UDDI the web services standard that missed its mark?
There was a time when universal description, discovery and integration (UDDI), XML and SOAP were held up as the key triumvirate of web services standards. Back in the day, web services, remember, were going to be coarsely grained things that an application would call as and when they were needed.
So you might have several e-commerce web sites but only one credit card authorisation service – as and when an application needed to authorise someone’s card, they would look in the UDDI-compliant repository to see if such a service existed and how to use it.
But it never really happened like that, and the reason is not so much a problem with the UDDI standard as it is that people just don’t use web services in that way, at least very few do. Because while web services were initially envisaged as being used to hook up services that supported various B2B and B2C web sites, in fact they are far more commonly used as a way of underpinning composite applications within the enterprise.
I first started to understand this when I spoke with a real-life user of web services, the Standard Life group, back in February last year. Unlike many companies that claim to be using web services but go strangely quiet when you get into the specifics, Standard Life has exposed 250 business processes as services, any of which could be reused by other applications as they all conform to the XML standard and the company’s own design pattern and support framework.
Standard Life’s application design manager Derek Ireland told me that of 250 services, about 123 are used by more than one application, some by three or more applications. There are 70 applications that consume those 250 services, so the ultimate goals of web services – less time-intensive application development, the potential re-use of web services and simplified change management – appear to have been realised at Standard Life.
It had started by getting its development team fully up to speed with XML. Before 1999, when the company trained its developers in the XML standard, it was only able to produce relatively fine-grained components using CORBA and writing components in C++, and to achieve only limited reuse. Since adopting the XML standard, the company has been able to make the services far more coarse-grained, so for example a service might now be a pension quotation, a direct debit authorization, a money laundering check for compliance purposes, or a customer search.
Content from our partners
So what of UDDI? Was a UDDI repository playing its part in the storage, discovery and implementation of those web services? Not a bit. “To do SOA you don’t need web services with a capital ‘w’ and a capital ‘s’,” said Standard Life’s Ireland. “The most important thing is people and process.”
Instead the company stores the web services in an IBM DB2 database, and catalogs them in a Lotus Notes database – adding the context about each service like who built it, its interdependencies with other web services, versioning and so on. The Notes and DB2 databases are linked so they do not become out of synch.
The web services are not called at run-time, but at ‘application design time’. Any developer building a new application first searches the Notes database for reusable services that could save on development time and cost. In fact, IBM’s DB2 supports UDDI (as well as SOAP), but Standard Life didn’t see any value in making use of its UDDI capabilities.
The point, though, is that Standard Life didn’t need UDDI because it’s not calling the services at run-time. It uses the services to assemble composite applications long before the services that underpin those applications are actually called. More on my story of Standard Life’s SOA strategy here.
Avrami Tzur is Mercury Interactive’s senior director of strategy, and he was heavily involved in the decision to acquire Systinet and its UDDI repository. I asked him if they know of any cases where UDDI is being used at it was originally intended – to call web services at run-time: “Right now I don’t know of any implementations of SOA that dynamically discover services,” he told me. “Which is because web services are mainly being used inside the enterprise, so there is not that need for dynamic discovery.”
“In fact UDDI is not really an appropriate name for it any more,” Tzur continued. “Systinet’s product is really used as a web services repository, used to store web services and enforce the policy surrounding each service.”
There were slightly more encouraging noises from Systinet’s CEO, Thomas Erickson, who told my colleague Tony Baer on Monday that in terms of how clients are using its registries, run-time discovery ranks third out of four use cases. But as Tony points out, another reason for the seeming absence of people using UDDI for run-time discovery is the concern over just how to enforce policies over each web service at run-time.
Indeed, Mercury’s strength in application testing, or the broader discipline that it calls Business Technology Optimization (BTO), may help to redress some of those concerns.
But that won’t happen until Mercury manages to achieve some sort of integration between its BTO suite and the Systinet products. Tzur suggested it would happen eventually though, telling me future integration between the Systinet and Mercury’s BTO products could include the ability to use the registry as a central point of control when using Mercury’s testing tools – for example using the registry to check version numbers and dependencies when doing functional testing of services.
“You could also see integration in terms of demand management,” said Tzur, “looking through the registry to see what you already have before you set out to create a new service. Also there is likely to be integration in change management and control.”
So what conclusions can we draw? The first is that UDDI is still valuable, but is being used more for policy enforcement than run-time web services discovery, for which it is barely being used at all. Secondly, that Mercury’s skills in application testing, integrity and performance management, could actually start to make the use of UDDI for run-time discovery more feasible, if it is able to integrate its products with Systinet’s. Whether there will be any more demand for web services discovery at run-time as all of these technologies mature, is quite another question.
For those who skipped to the end to see if I think Systinet’s acquisition is the final nail in UDDI’s coffin, the answer is that I don’t. I don’t think it’s stretched out in a coffin in the first place. But I do believe that UDDI is not being used as it was originally intended.
