As a developer working on a Web Services Development Platform, it is very important to me that UDDI and the web services revolution succeed. I think they certainly have that capability; Web Services are here to stay, and UDDI will probably become pretty useful in a year or two. However, there is no doubt that there are significant problems with UDDI as it now stands. Here are a couple, and you can email me if you're interested in more.
1) No fact-checking mechanism: As it now stands, any business can go to one of the main UDDI providers (Ariba, Microsoft, and IBM), and register their company. This company could be legitimate, could be pornographic, or could be entirely false and fraudulent. Moderation and arbitration is always a tricky subject, as demonstrated by the last couple hundred WIPO cases, and this case is no exception. If I register in IBM's UDDI directory as "Microsoft Corporation," who decides that I'm not actually Bill Gates? If I register a fraudulent service, charge for it, and then screw my customers, who is liable? With a rotating management (executives from each of the three administration companies take turns being in charge), how are UDDI placement rules defined and enforced?
At the last UDDI advisory board meeting, the proposed answer was "self-administration." The administrators believe that as UDDI grows in popularity, there will be service providers offering background checks and ratings, similar to the Gomez reviews for B-to-C providers. I can almost accept this explanation, but it is certainly not in place yet.
2) No standardization of entries: At its heart, the point of UDDI is to find services. These standards-based services are supposed to be available for use and integration by consumers, businesses, etc. Not only are the service descriptions buried beneath several levels of marketing, company information, and other useless junk, but there is also currently no standardization of entries. The standards are there, the services are there, but they aren't being referenced correctly....and that defeats the purpose. At the lowest level (the green pages referenced in the article), each Web Service should have a service description file, written in WSDL (Web Services Description Language), that specifies available methods, inputs, and outputs. Currently, the lowest level is a hodgepodge of text, Word documents, phone numbers, and a very few WSDL files.
Even if the services were available, the UDDI administrators have not released their web-based search interface yet. Visit http://www-3.ibm.com/services/uddi/find.htm to see an example....the "Find Services" button is unavailable, six months after UDDI's adoption.
We need some form of standardization, and it's not coming any time soon. At the UDDI advisory meeting, this question was pretty much blown off. There is nothing planned for the next two UDDI iterations that will fix this situation, and that means a couple of years at least. If the idea is to have our machines access and execute the services without user intervention, UDDI is a far cry from done.
----
As it stands now, UDDI is relatively unusable. I have high hopes for its future, but I think smaller directories and private service repositories will be quite a bit more useful until UDDI gets past its toddler stage. In-fighting between the administrator companies will probably delay this process, especially since UDDI won't cause money to flow directly back into their pockets any time soon.
As long as Tito goes through the proper training regimen, and is certified by NASA, he can't be much more of a liability than John Glenn was when he went up a few years ago. Glenn, though trained as an astronaut, was way past his prime, physically, and might have been a liability in a crisis situation. Tito is younger and (I would guess) stronger, and would have less physical limitations. When Glenn's last flight returned to earth, the astronauts were not allowed to leave the shuttle right away, because Glenn had become sick in the cockpit and they didn't want to embarrass him.
I can understand the Canadian's reticence to send Tito up with their robotic arm, as he wouldn't be able to help unless he was specifically trained on that mission, but he should be able to go at some point, having made the deal with Russia long ago.
garoush seems to have hit the nail on the head. SOAP is important not because Microsoft is using it, but because everyone can use it. If you're a Microsoft junky and want to communicate your data through.Net, go for it. If not, there's no reason Microsoft should have to be involved in your SOAP implementation.
There are open-source SOAP implementations all over the place. Somebody has already mentioned the xml.apache.org/soap SOAP server, and there's a nice Perl SOAP client at Soap::Lite. A search for "SOAP XML" on Google will provide a plethora of pinatas...I mean matches.
My company is working on a product that will tie SOAP Web Services to back-end databases, legacy systems, wireless devices, and more. The possibilities are endless.
Slashdot Mirror
Spam drifts like snowfall
Where is the mail from my friends?
Lost in the blizzard.
As a developer working on a Web Services Development Platform, it is very important to me that UDDI and the web services revolution succeed. I think they certainly have that capability; Web Services are here to stay, and UDDI will probably become pretty useful in a year or two. However, there is no doubt that there are significant problems with UDDI as it now stands. Here are a couple, and you can email me if you're interested in more.
1) No fact-checking mechanism:
As it now stands, any business can go to one of the main UDDI providers (Ariba, Microsoft, and IBM), and register their company. This company could be legitimate, could be pornographic, or could be entirely false and fraudulent. Moderation and arbitration is always a tricky subject, as demonstrated by the last couple hundred WIPO cases, and this case is no exception. If I register in IBM's UDDI directory as "Microsoft Corporation," who decides that I'm not actually Bill Gates? If I register a fraudulent service, charge for it, and then screw my customers, who is liable? With a rotating management (executives from each of the three administration companies take turns being in charge), how are UDDI placement rules defined and enforced?
At the last UDDI advisory board meeting, the proposed answer was "self-administration." The administrators believe that as UDDI grows in popularity, there will be service providers offering background checks and ratings, similar to the Gomez reviews for B-to-C providers. I can almost accept this explanation, but it is certainly not in place yet.
2) No standardization of entries:
At its heart, the point of UDDI is to find services. These standards-based services are supposed to be available for use and integration by consumers, businesses, etc. Not only are the service descriptions buried beneath several levels of marketing, company information, and other useless junk, but there is also currently no standardization of entries. The standards are there, the services are there, but they aren't being referenced correctly....and that defeats the purpose. At the lowest level (the green pages referenced in the article), each Web Service should have a service description file, written in WSDL (Web Services Description Language), that specifies available methods, inputs, and outputs. Currently, the lowest level is a hodgepodge of text, Word documents, phone numbers, and a very few WSDL files.
Even if the services were available, the UDDI administrators have not released their web-based search interface yet. Visit http://www-3.ibm.com/services/uddi/find.htm to see an example....the "Find Services" button is unavailable, six months after UDDI's adoption.
We need some form of standardization, and it's not coming any time soon. At the UDDI advisory meeting, this question was pretty much blown off. There is nothing planned for the next two UDDI iterations that will fix this situation, and that means a couple of years at least. If the idea is to have our machines access and execute the services without user intervention, UDDI is a far cry from done.
----
As it stands now, UDDI is relatively unusable. I have high hopes for its future, but I think smaller directories and private service repositories will be quite a bit more useful until UDDI gets past its toddler stage. In-fighting between the administrator companies will probably delay this process, especially since UDDI won't cause money to flow directly back into their pockets any time soon.
As long as Tito goes through the proper training regimen, and is certified by NASA, he can't be much more of a liability than John Glenn was when he went up a few years ago. Glenn, though trained as an astronaut, was way past his prime, physically, and might have been a liability in a crisis situation. Tito is younger and (I would guess) stronger, and would have less physical limitations. When Glenn's last flight returned to earth, the astronauts were not allowed to leave the shuttle right away, because Glenn had become sick in the cockpit and they didn't want to embarrass him.
I can understand the Canadian's reticence to send Tito up with their robotic arm, as he wouldn't be able to help unless he was specifically trained on that mission, but he should be able to go at some point, having made the deal with Russia long ago.
garoush seems to have hit the nail on the head. SOAP is important not because Microsoft is using it, but because everyone can use it. If you're a Microsoft junky and want to communicate your data through .Net, go for it. If not, there's no reason Microsoft should have to be involved in your SOAP implementation.
There are open-source SOAP implementations all over the place. Somebody has already mentioned the xml.apache.org/soap SOAP server, and there's a nice Perl SOAP client at Soap::Lite. A search for "SOAP XML" on Google will provide a plethora of pinatas...I mean matches.
My company is working on a product that will tie SOAP Web Services to back-end databases, legacy systems, wireless devices, and more. The possibilities are endless.