"In research conducted by the SIIA (Software and Information Industry Association), ComputerWorld and Systinet, which will be published in October, 2002, we found that among the 800 developers and IT managers we interviewed, over 68% planned to deploy Web services applications in the next 12 months. As Web services enter the mainstream, we should expect them to proliferate and become more sophisticated and interdependent, which begs a question: If my organisation has many Web services, how do I discover them and consume them? If I've just built the 'killer app' using Web services, how do I let all my colleagues, business partners and the boss know that it exists?
Along with SOAP and WSDL, UDDI (Universal Description, Discovery and Integration) is one of the core technologies that enable Web services. A UDDI implementation is a Web service registry that provides a mechanism to advertise and discover Web services. A UDDI registry contains categorized information about businesses and the services that they offer, and it associates those services with technical specificiations of the Web service. These technical specifications are usually defined using WSDL. WSDL describes what a Web service does, how it communicates, and where it lives. A Web service consumer queries the UDDI registry to find the WSDL descriptions to determine how to use the Web service. A UDDI registry is itself a Web service. The UDDI specification defines an API based on SOAP messages, with a WSDL description of the registry service. Most UDDI registries also provide a browser-based human interface," says Zdenek Svoboda this article from theserverside.com:
Very interesting question indeed: "how do I let all [anybody] know that [my Web Service] exists?"
The answer?:
"Most UDDI registries also provide a browser-based human interface."
Well....wrong approach. If you try one of those browsers you immediately realize that the Web Services movement is heading towards a huge wall when it comes to services meant for humans. The UDDI registries are filled with services that are *not* for humans, and many services are long dead. Besides that there is almost no organisation of the services. It's one huge collection with a very broad categorisation (unfortunately one size doesn't fit all). It looks like an organisation of Web Services which makes them easier to navigate (for humans) is going to be an afterthought (just like code mobility/security/usability). And that's a pity, because many services will be for humans. Say that your future VCR provides a Web Service that allows humans to program it, how in the world will you find *your* VCR in an unorganised UDDI registry that is filled with every possible service you can think of?
The answer will be a system that explicitely deals with the organisation of services from the ground on up, else we will end up with a Google of services (I heard 'Spoogle' in the hallway) that returns with 98123741 VCR's if you search for yours. The best example of a project working on organising services is the Place Project (http://www.artima.com/jini/cyberspace/index.html), which allows for the organisation of human-centered Jini services (the ones that provide a ServiceUI) into places. Humans are more likely to find the exact service they are looking for if the organisation is easy to understand; it will minimize the chance of mistakes and make our lives easier.
> Well....wrong approach. If you try one of those > browsers you immediately realize that the Web > Services movement is heading towards a huge wall when > it comes to services meant for humans. The UDDI > registries are filled with services that are *not* > for humans, and many services are long dead.
I think the intent of UDDI browsing is that the only kind of human that would be browsing UDDI registries would be that funny, special kind of human called a programmer. Programmers are human, for the most part, but they may be expected to deal with uglier, unfriendlier interfaces if they are being paid to find something in a UDDI registry.
A question I've had is, how often will programmers look for services that way? I don't the get message from the web services movement that client programs are going to be looking things up by type, like you hear about in Jini all the time. Instead, various businesses in a supply chain, or various departments in an enterprise, will get together and decide to offer each other these web services. That makes since to me, but that means that programmers won't be looking up things by type either. They'll be told to call into this or that departments web service, and by the way here's the URL and the interface specs.
So in practice when will human programmers actually need to browse UDDI registries?
> Instead, various > businesses in a supply chain, or various departments > in an enterprise, will get together and decide to > offer each other these web services. They'll be told > to call into this or that departments web service, > and by the way here's the URL and the interface specs
Yep. This touches upon an interesting question: are Web Services mainly meant for businesses to offer their services to other businesses, or is it scalable enough for, say, small devices to offer their services to humans? I believe the former is the case, and I personally see many problems in the latter case. If the Web Services movement were able to pull *that* off, they would bump into the problem of navigation. Negotiating with a company's department that offers the service doesn't make sense when a microwave offers the service.
Some kind of registry is inevitable for the discovery of services, and when it is users who have to do the discovery the search mechanism of the registry has to comply to some fundamental usability requirements.
So the bottomline is the question whether Web Services are meant for humans as well. And if they are, will it be users who provide the service?
Previous Topic
