Before I go any further I want to point out that I am not against UDDI. I am not trying to replace UDDI. UDDI is the right and standard approach for discovering Web services. In fact I think that my idea can compliment UDDI - more on that later.

The problem for some people is that UDDI is a substantial investment in terms of licensing, programming to the APIs, and perhaps hosting. When I say some people I mean organizations that have only a a few services. UDDI seems like a lot of infrastructure for basically looking up a Web service. And if I don't want to bootstrap what other alternative do I have?

Well I thought why not use RSS as a place to syndicate Web services in a "simple" way. I found this site useful in describing RSS and it's various "flavors". RSS stands for Really Simple Syndication and is used by news web sites and bloggers to create feeds. Basically RSS has a channel that contains items. These items have, among other things, a title, a description, and a link. Usually the link is an HTML link to the news or blog content. However why can't that link be to a WSDL?

I Googled to see if anyone else had described doing this but I couldn't find any references to using RSS as a Web services registry - a kind of Really Simple Syndication of Services (or RS³). I did see mention of some uses of RSS around Web services (similar to other ideas I had when looking into this) but nothing about using it as a services registry. Not even from the REST community.

Last night I downloaded Celtix, an open source ESB and RSSLib4J and RSS feed parser for Java. I wrote a simple class that wrapped the RSSLib4J APIs in order to use them for a name lookup for a WSDL from the feed.

A friend of mine Barry O'Mahony was over with me. Barry has been helping me with the IP Babble web site. Barry set up an RSS feed on IP Babble that pointed to a WSDL that was also loaded on ipbabble.com. The WSDL was directly from Celtix's simple "Hello World" sample - unmodified.

Both the service consumer and provider were to run on my Powerbook G4 laptop. I modified the Hello World client to use my new RSSSRegistry class and passed in the IP Babble based RSS feed URL to the client. I searched for the Hello World service title in the item title field and returned the WSDL link to the celtix client. Celtix took care of the rest.

It worked! Beautifully.

Obviously this is just a POC and I'd like to add some features, even to the demo. E.g. validating that the feed is a services feed rather than a news or blog feed. That's why it might be useful in defining RSSS or RS³ where some standard definitions are used to make this more useful. But we must make sure we keep the Really Simple part. And for Celtix it would be much better that it's a plugin that gets configured with the feed URL rather than the client having to program to the APIs.

So there are lots of questions about the use of this technique, e.g. what about security or other governance issues? Though posting to a feed has some security built in, i.e. not anyone can post to news feeds or blog feeds, that's not really the point. If you are thinking about serious governance issues then you need to look at UDDI. This is not for you. If you want a quick, simple, standards based approach to Web service lookup then RSS can be useful. Remember too that many ESB products build in some security, routing, transaction etc. information into the WSDL (see Artix ).

In fact rather than just being an alternative to using UDDI, RSS could be very useful for UDDI users. A UDDI implementation with an RSS plug-in can populate some of its metadata from such RSS feeds! RS³ feeds themselves would be syndicated providing a larger structure than the current 15 item limit of RSS - (which is soft limit for the most part).

Anyway, I'll be posting my demo to the Celtix web site either today or over the weekend. The demo will be in the samples/hello_world_RSS directory. It's not in the current (milestone 3) download but will be.

Thanks again to Barry O'Mahony for his help. And thanks too to Mark Rogers for inspiring me by mentioning RSS around a different area of Web services.