Thursday, September 25, 2008

What I want from a Web Service Registry

Coming back to web services after a break has revealed the necessity for a good governance system, and the weaknesses of the one I have now. Mule Galaxy is just not up to it. It is clunky to use, and I randomly get some errors when updating. What I need is:



  • A central repo where I can store all web service related metadata - the name, URL, purpose, dates, owners, version numbers, dependencies, etc.


  • A one page list of the current web service URLs, what they do, and what their status is (live/dev/test etc). This is the one that I am sorely missing right now! One web service per line


  • Keeping the WSDL in source control is useful, but there needs to be an easy way to get it in there, to compare differences, and to link the source code URL into the metadata repo; and there needs to be a clear process for when (at what stage in the dev process) the WSDL in source control gets updated


  • I need to regularly test/ping these services to ensure they are still up and alert if they aren't. This could be done through something like Servers Alive. Ideally it should dynamically look-up my metadata repo and automatically test the services that are at the right status. Otherwise I'll just forget to add the test into Servers Alive. The repo can hold the names of the people to alert. It would be nice if it could update back into our repo the date/time of the last successful test, and the current test status (up/down)


  • Most of all, it needs to flow well and be intuitive to use - buttons/links that lead me through high-level tasks. I don't do this everyday so I don't want to have to refer to a manual every time I want to do something (like upgrade a web service and deploy it).


  • What I don't want is run-time web service look-ups!


  • What I also don't want is some giant heavy-weight system that does all of this, plus 1,000 things more. Well actually, I don't mind if it does 1,000 things more, as long as they are hidden/unobtrusive and don't turn it into a click-coffee-click tool.




I can see why so many people end up writing their own registries!

2 comments:

Dan Diephouse said...

Hi,
Thanks for your comments on Galaxy, its very helpful to know where people feel the weaknesses are.

I believe the first item is doable with Galaxy currently. Items 2 & 3 are pretty high on our roadmap.

For the fourth item, there is a way to potentially do that with Galaxy. We have a new scripting shell in 1.5. You could write a script which pinged the web services and updated a status metadata property on the entry in the registry.

If you're interested in the last point, one of us can probably help you write the script. Just send an email to the forums or mailing list... (I'll probably try to write this up anyway soon)

Anonymous said...

Thanks for the feedback. regarding the last two points, Galaxy does not do run-time WS lookups. I agree it's generally a bad thing.

As for the last point, one o fthe reasons we started Galaxy as an open source product is that folks should not have to write their own. We don't want to be come the next heavy-weight registry/governance platform, which is why we spend a lot of time getting feedback from our users. Also, having an open source code base means users can suggest changes and maybe even get involved in the project to make the changes. It's a better use of time to work on something that already exists rather than building your own. please feel free to ping dan or ross directly @mulesource.com or jump on the mailing list.