jUDDI is an implementation of the UDDI version 2 spec that stores metadata on web services. We're using it for a private registry, and JBoss is rolling it into their product. The strange thing about it is that a Release Candidate was published in 2005, but never graduated to a full 1.0 release.
I have jUDDI running on MySQL v5, which is one of the several databases it is compliant with out of the box. But we programmers aren't the only people in IT, and it would be polite to those at the other end of our floor to do what we can to not introduce additional platforms if we can help it. So I made a perfunctory pass at getting jUDDI to work with MS SQL Server 2000, with unhappy results.
In order to use Microsoft SQL Server 2000 with jUDDI, you need to make some source changes and recompile. That's because MS SQL Server disallows the definition of two TIMESTAMP typed columns within a single table.
But if you really want to make it work, the obvious thing is to modify the jUDDI set up script to use DATETIME when setting up the AUTH_TOKEN table instead of TIMESTAMP, because you can define an arbitrary number of those within a single table). But Microsoft states that DATETIME is not supported as an equivalent. Moreover, once you attempt to access your registry, you'll get the following error:
2007-07-09 10:42:16,742 [https-8080-Processor25] ERROR org.apache.juddi.function.SaveBusinessFunction - java.sql.SQLException: Disallowed implicit conversion from data type datetime to data type timestamp, table 'uddi.uddiuser.BUSINESS_ENTITY', column 'LAST_UPDATE'. Use the CONVERT function to run this query.
So you'd need to get the jUDDI Java source to convert your TIMESTAMP calls to create a DATETIME just for accessing the AUTH_TOKEN table, modify the data accessor, recompile, and redeploy. The obvious downside here is that you'll have to do extra work to ensure you're stil compatible with MySQL. The trade off isn't great here. So the question becomes one of long-term maintenance. I think we'll quietly stick with MySQL for this.