Web Service Registry


For anyone with a Web Service, or anyone who wants to consume a Web Service, I have some exciting news. At the end of March, Miles Crawford sent out an email to the Appdev list soliciting help building a registry for such items. I’m happy to announce not only did he get a response, there is actually some tangible code.

The original desire was “…a technical tool to help identify and locate resources, but also as an outreach tool to better connect the groups behind services.”  To anyone who has tried to obtain data from anywhere around campus the need is certainly apparent.  Even though there is a trend to create Web Services and offer data, as before, finding out what data is available and tracking down who has it is a huge problem.

In the spirit of openness and the chance to work with new people and technologies the following team was born:

    Miles Crawford – Learning & Scholarly Technologies
    Tony Chang – Office of Information Management
    Chris Heiland – UW Marketing

We knew we needed a framework, source control, and a server.  The last part was the easiest to decide, Catalyst was kind enough to allow us a temporary home on one of its servers.  Since we had near-complete freedom on the choice of technology we spent a bit of time deciding on the technology needed to implement the service.

I want to stress strongly that our choice in frameworks, languages or source control is not going to be the best choice for every job.  Yes, there are numerous other options and they all have their pros and cons.  The goal for the technology was to support rapid development and a short learning curve, none of us wanted to spend the entire project lost in a manual.

The project was a temporary solution to a current problem, but the solution had to last from several months to longer.  Thus we were not looking for something that would scale to an enterprise deployment (thousands of services, millions of hits, constantly changing data), but if there was the ability to handle the load then we wouldn’t turn it down.

We decided to use Python as our language and Django as our framework.  The framework is fast to deploy and certainly excels at CRUD-style applications.  If this does become the permanent solution then we certainly have the option of leaving the registry as a Django app.  A bit more caching in a few places and no more pilot status.

For source control we did not require an elaborate solution, any system could handle what we needed.  Also, as we saw this as a chance to stretch a bit we decided to look at Distributed Version Control, specifically Git.  Git may not be worthy of all the hype, but there are some very clear advantages versus systems like SVN or CVS.

Again, there is no perfect tool for every job, we could have easily set up Subversion and been done with it.  However this was a chance to learn a new tool.  There was also the opportunity to host our code at GitHub, which had space and fell under the ‘nifty’ factor.

After a few short meetings of discussing what features to include and adding some  more to the Scope Creep Bin, we started coding.  In a short amount of time we had a working application and the ability to quickly manipulate test data using the built-in admin interface.

There is still a bit more work to do before the application is released, but we are very happy with the progress.  Very little code is needed to put together something functional and the framework is very straight forward.  Overall we are excited and preparing for launch.  Until then you know how to reach us.

  1. #1 by Tony Chang - May 7th, 2009 at 14:57

    Here is the direct link to our GitHub UW Registry Repository http://github.com/tonychang/uw-registry-v1

  2. #2 by Sean J. Vaughan - May 8th, 2009 at 08:30

    This looks great. We’ve also deployed django for our internal web services development. We’ve moved python in a preferred position over perl for internal development. Perl is dying :( . We also do plenty of Java.

    I’ll be interested in hearing how your git experience goes. We’ve been using the UW Technology subversion service internally and have been planning on using SourceForge’s Trac system for our next shared software project (we’ve used google code for exchangeling and some other things).

  1. No trackbacks yet.

Comments are closed.