Playing with web services

Some of you may know that I run a website for displaying the temperature in Seville which has many visitors, mainly from Seville. I’ve run that website since 2001 and it is actually number one when you perform a google search on temperatura en sevilla. I find it quite useful.

Eversince I have implemented various related services, basically playing around in my free time. Some of them are a RSS service and a jabber service (which you can subscribe by adding to your jabber application - even Gtalk -). There are people that use it on a daily basis and I am glad that they do :)

So, I had this idea in mind since some time, I just wanted to create a web service so other people could use it on their applications, be it web or desktop application. that would me let me play with webservices and, also, with Ruby.

So, I did some coding and implemented something that I would like you to know.

The web service

The temperature is read from a couple of sensors from Dallas Semiconductor using a program called digitemp. It is a unix command line program that is used by a set of shell scripts that create all the fancy graphics you can see at using rrdtool. These scripts are executed every five minutes to both insert the data into the database and generate the graphs. The system usually works ok, but it has some flaws, mainly because of old hardware and by the fact that I am living in London and the machine is in Seville.

In order to avoid problems with the actual system, I added a ruby script to the previous shell scripts to generate an XML file that would be later on used by the web service. The file content is

    Wed Aug 16 03:00:05 CEST 2006

    Wed Aug 16 03:00:06 CEST 2006

This is what I am using to feed the web service. Notice that each of the sensors has a unique serial number and that would be used by the calls to the webservice. I created a small ruby program mapped to the url in order to work. There are two different methods now:

  • list_sn* used to discover all the S/N available.

  • read_temp(sn)* used to read the data from a sensor. sn is the serial number of the desired sensor.

Client programs

So here are two different client little programs that you can use to access the data. One in ruby and another one in python. Very simple, no error check.


#!/usr/bin/env ruby

require 'soap/rpc/driver'
proxy ="",
proxy.add_method('read_temp', 'sn')
puts "List S/N: #{proxy.list_sn}"
puts "reading from s/n  1030AC15000800CB"
puts "#{proxy.read_temp("1030AC15000800CB")}"
puts "reading from s/n  10952F1A00080063"
puts "#{proxy.read_temp("10952F1A00080063")}"


#!/usr/bin/env python

from SOAPpy import SOAPProxy

url = ''
namespace = ''
server = SOAPProxy(url, namespace)
print "Printing S/N"
print "Temperature for 1030AC15000800CB"
print server.read_temp("1030AC15000800CB")
print "Temperature for 10952F1A00080063"
print server.read_temp("10952F1A00080063")

you can test both right now or come up with a new version in another language or improve these ones. Here is a typical output:

$ ./client.rb
List S/N: 1030AC15000800CB, 10952F1A00080063
reading from s/n  1030AC15000800CB
27.31 degrees at Wed Aug 16 03:20:05 CEST 2006
reading from s/n  10952F1A00080063
21.25 degrees at Wed Aug 16 03:20:06 CEST 2006


Yeah, this is a work-in-progress thing. I have no idea if this is the way to do it. No WSDL, not yet. Expect it to fail at some time, as I have yet to implement more error checking, etc.

So, I would like all of you, if you have an opinion on these kind of things, to comment or suggest, say if you would like it to do something different or better.

I have done some assumptions basically because my lack of knowledge on the matter.

  1. I have created the webservice using ruby’s webrick own webserver on a high port and mapping it to an apache url using proxypass directives. Is this the way to do it?

  2. I only created two methods. Would make sense to have more methods? Like one that would only return the temperature value?

Have something to say? Go ahead :)

Tags// , , ,
More Reading
comments powered by Disqus