The UDDI protocol (nor its data model) was never intended to directly support human interaction. Both were designed to support programmatic interaction. (The protocol is a set of APIs, after all.) UDDI.org always envisioned that folks would build much more interesting UIs for humans.
But as I said, UDDI is too constrained to enable a decent search UI. And that's why I position UDDI primarily as a means to enable information exchange among myriad infrastructure components. Not as a means for humans to discover services. A repository with an open content model and free-form search is a much more appropriate discovery tool. Nonetheless, I totally agree that the idea that any large organization will have one and only repository is a pipe dream. Especially when dealing with service metadata. For example, the system-of-record WSDL for a service is managed and maintained by the service platform that hosts it. If you have a copy of that WSDL in a repository, it's a copy, not the WSDL-of-record. But that brings me to another differentiating feature of Systinet's repository -- it doesn't need to host a metadata artifact to manage its lifecycle or to detect its relationships and dependencies. No other registry/repository offers that feature. I also think the REST design is an import differentiating feature because of the capabilities it lends to the UI. To be honest, it's the combination of search and REST (rather than REST by itself) that really sets Systinet apart. Systinet's search system is based on XQuery. (Also a unique feature.) It provides a Google like free-form search bar, which it then converts to an XQuery expression, and it provides an advanced search dialog screen that gives users the ability to specify more specific search criteria, which again gets converted to an XQuery expression. A user can save an XQuery expression in the repository -- it becomes a managed artifact just like any other artifact in the repository. And because it's REST, it also gets a URL. And you can reissue the query any time by performing a GET on the URL. And you can hyperlink to it. And you can set it up as an RSS feed. And you can apply a stylesheet to it for rendering in a portlet. And all kinds of other things. XQuery is what gives the repository a powerful search capability. REST is what enables users to more readily exploit the search capability. I think Systinet did a pretty good job putting love into its UI. Its competitors have a long way to go. (Systinet still has a lot of stuff to do to enhance its product, and it really needs to fix its performance problems, but its just way beyond with the other folks have done.) Anne ps. And no -- I have no personal stake in HP or Systinet. I've just completed a pretty thorough analysis of the leading products, and I was astonished by the differences. On 2/10/07, Paul Downey <[EMAIL PROTECTED]> wrote:
On 9 Feb 2007, at 12:32, Anne Thomas Manes wrote: > Yes -- open content model, automatic detection of relationships, > hyperlinks, REST architecture, excellent search. This is what > differentiates Systinet's repository from the other players. It > doesn't have a built-in wiki capability, although it does have a > free-form description field for all artifacts. And the content > model is extensible, so you could add/extend the description or > comments field to allow folks to add more information. I periodically get to attend meetings where someone has a vision which involves a single registry/repository to rule them all. There follows a list of all the great metadata which this single truth will "own". Usually a can't hear what they're saying due to the sound of "Darth Vader's Theme" trumpeting in my lugholes. Empire building.. Empire building .. Beyond the obvious political motivations for a central registry, I just don't like the outcome. Flickr, Google, Amazon, etc all put more love into their developer web pages. It's no coincidence they're adopted more widely by developers that services shoved into a UDDI at the edge of the known universe. Web sites rock. Spreadsheets suck. Paul -- http://blog.whatfettle.com
