Slashdot Mirror

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.

If you're into Perl, check out Velocigen - it's like mod_perl, but a much, much better/faster design. Depends on if you want a free solution, or a commercial one and how fast you want to go. Everything Solaris will be doing a "shoot out" between Apache w/mod_perl and Zeus w/Velocigen, among others like iPlanet and Roxen shortly.

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.

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.

Uh, there was a commercial FastCGI module available for the Netscape servers. Does the same thing most people use mod_perl for: it allows slightly-modified CGI code to be compiled and cached by a persistent Perl interpreter.

The only problem is that it was sold to another company, which was in turn acquired, and it was taken off the market. You may want to contact Adero to see if they'd be so kind as to point you in the right direction.

If you're running the Netscape/iPlanet webserver on NT or Win2K, you can also use ActiveState's PerlEx, which is another similar persistent-Perl engine.

There also appears to be a reasonably modern Perl NSAPI module, which is philosophically the closest thing to mod_perl in that it lets you get close to the metal and write true server modules in Perl. It's here.

Velocigen, another commercial product, isn't exclusively a Perl engine. It's a logic and content caching engine that uses XML tags that can hook to cached and embedded code--including Perl. It's probably a different development experience from these other systems, but if persistent Perl is your goal, this should do it too.

Ever tried searching the Web?

I've been developing Perl-based software for Web Services (see velocigen.com), and so far the best way to deal with all the changing standards (cough Microsoft cough) has been to damn the torpedoes and use modules like SOAP::Lite to hack together something that works now, with the intention of shoring it up when the standards change.

A perfect example is (bloody damn) WSDL. It's a great idea for a good standard, but it's a lousy specification thus far. I had to read between the lines a lot and select which parts of the standard I could reasonably implement. It worked, though; I have a working WSDL implementation, client and server; it may be the only one on the planet so far. :)

I should say that it is extremely cool once it works. We've been playing with it for a few weeks and we've done some amazing things. That alone makes it worthwhile.

If you want to speed up perl, take a look at Velocigen. For serving static content, see kHTTPd.

If you have several servers that you do things like load content off of, and aren't using round-robin DNS, then you can speed up what the customer sees by cutting the number of DNS lookups. Use IP addresses in your URLs (URLs on servers that you control the IP of only!).

I have yet to look into support for compressed HTML, but I can imagine for some things (mailing list archives) it would be a real blessing.