Last week in Santa Barbara, during the ESIP Federation summer meeting, the NASA SPG hosted a Web Services technical session. I somehow got the job of lining up speakers and moderating the session, always a bit of a nail-biter. The session went well and we had some great speakers.

The presentations can be found on the SPG web site.

First up, I tried to set the stage a little bit, based on where I thought the audience was in terms of knowing about web services and REST. My biases probably showed through, but I really do think that anyone building web services that are meant to be generally accessible should not be using straight “SOA” (i.e. SOAP, WS-*, etc.) with no regard to REST. Furthermore, I think that REST wrappers around RPC-style interfaces is stopping short of where things could be.

Next, Josh Lieberman gave a presentation about OGC’s current mindset vis a vis REST. It looks to me like there is some critical thinking going on inside OGC on this topic. It remains to be seen whether there is also going to be any real motion towards specs that use REST the way it could be used. Look at some of Sean Gillies postings about APP for how OGC could benefit from REST. (Sean was, unfortunately just arriving in France and unavailable to come to UCSB).

Michael Burnett talked about ECHO. ECHO is a full-bore SOA implementation of a metadata clearinghouse for granule level NASA data. ECHO is actually testing out the REST waters a bit with some early experiments. Given when ECHO was initially designed, and the need to continue long-term, stable operation, I don’t think I can fault them for where they are today. There’s a lot to be said for keeping a stable API that can itself be wrapped in newer skins.

Switching gears a little, Jason Symonds from NOAA showed us how he’s been building a drought portal. His portal acts as a web services client to pull information from many other web sites into a single set of web pages. Along the way he’s had to develop a few web services of his own which he’s also making available via the portal.

Tyler Stevens demoed a new service offered by GCMD (his presentation is here, the portal itself is here), namely a web services discovery portal. GCMD has been a mainstay for dataset discovery for a number of years. More recently, they have been accepting submissions of web service descriptions that now can be found in the portal. What I really liked here is the way the services themselves can provide information about how to use them. For instance if you click on the WMS service link for this DataFed service entry, it brings you to a forms builder that helps you build WMS URLs.

Karl Benedict’s talk about the New Mexico Geographic Information System showed how they are developing a RESTful set of services to allow data upload and subsequent automatic generation of WxS services on that data. As the system has become easier to use, the amount of data being made available has been increasing by leaps and bounds.

The last talk came from the astronomy community, who seem to be a bit out in front of the earth observation community when it comes to a concerted effort to move to REST principles. Matthew Graham gave a great overview of what is going on in Virtual Observatories. I’m always a little surprised when I see how other communities really are not all that different from the ones I’ve been working in for years. When you get right down to it, I guess everyone has data ingestion, integration, storage, and service delivery problems, so I should not be surprised. The VO community seems to be tackling the problem with gusto and has been making good progress, from the look of it.

At the end, we had a discussion about the questions raised in the initial session description and also touched briefly on how NASA could work to maximize its benefit from being an OGC member (broadly speaking, not restricted to web services). Two whiteboard pictures (one, two) emerged, and there will be summary information posted soon, I think.

[Update: Summary meeting notes were just posted on the site. -- July 16]

Has anyone ever run a service discovery and orchestration scenario like the one on page 7 of this document in any setting other than a demo? How far away from being able to do this in “real life” are we?

My overall impression is that it’s slower than the beta and slower than Safari 3. But that’s gut feel, not with hard data. The “loading” bar is also far less obvious now, and I always find myself wondering whether Safari has stopped working because it takes a while to even start showing activity.

Is there anything that’s more nerve-wracking than taking down a perfectly functioning server in order to do something with it? This morning I had to move two servers (a PowerMac G5 running Leopard Server, and a Mac Mini running 10.4) a whopping 6 feet in order to put them onto a dedicated power circuit. I also needed to install software updates.

Before I ever install any updates on a server, I clone the disk with SuperDuper or CCC. That means I also have to first shut down all the services and pull the system off the net, clone the disk, boot the clone to make sure it’s ok, boot the normal disk, do the update, and test everything. Coupled with having to move the computers, 5 disk drives, and a D-Link switch, I didn’t have a fun few hours this morning.  I didn’t update the Leopard Server machine because I couldn’t get the alternate disk to boot. It turns out that the Iomega portable drive I was using (I love these little disks!) wasn’t getting enough power from the G5’s front connector and needed to be plugged in the back. By the time I figured that out, it was too late, the museum staff people were coming in and I had to have the server running again. So I’ll have to do the update another day.

Now one of the remote users on the updated Mini is having trouble getting in via ssh. So is it due to the move, the upgrade, or something completely unrelated? Having tried a bunch of things and looked at the log files, I’m leaning towards “something else”.

The one good thing that comes from this kind of thing is that you learn whether all the services are properly set up to start at boot time.

The IFC Media Project came to town today, to hold a panel discussion at the MIT Museum. They brought in more equipment than we’ve ever had anyone bring in. We had to run an auxiliary 60 Amp power drop for their cameras, lights, and recording studio. 

The panel discussion was about crime reporting in various media outlets, primarily print, radio, and TV. Tucker Carlson, Juan Williams, Martin Baron, Candy Altman, and Josh Silver were on the panel. 

There’s not too much of a technology angle to this event, other than that it’s nice to have people come in who know what they are doing. They brought in all their own equipment and a huge staff. Setup started yesterday, went into the wee hours of the night, and resumed again at 5AM this morning. 

The event was held in our Innovation Gallery, where exhibits are meant to come and go. Right now there’s relatively plenty of floor space but we’re going to be putting in a few new exhibits soon so things are going to get tighter again.

Rumors about the death of the Mac Mini and now, the rebirth of the Mac Mini prompted me to post my own personal wish that the Mac Mini retain many of its current characteristics. At the MIT Museum, we use Mac Minis whenever we can. They are insanely reliable and are easy to place in just about any situation. Here are four different setups we are currently running on the first floor.

This one is hung in a box near the ceiling. It’s been running for over a year. We set them all to reboot after a power loss, so we almost never need access. When I do need to do anything to it, I grab a ladder and plug in a keyboard & mouse.

This one has also been running for about a year. Prior to that it was sitting in a server room for about two years. The enclosure gets a bit warm. We used to have a Shuttle XPC inside but it failed after about 4 months. I think it was the heat.

We have two display tables with baskets attached underneath. The Mini fits in the basket. We used to have two additional setups just like this. This photo is of the CityCar interactive exhibit. There’s another Mini at the other end of the floor in the MIT & the Sea interactive exhibit (below the Mini-in-a-box pictured above).

The latest one to be put into service is a Mini that we strapped to the top of a monster Panasonic projector. The Mini drives the smaller projector to the left in the photo. This Mini is running Vine Server so I can access it remotely. Once we’re done tweaking it, I’ll probably shut off the Vine access.

Our Admissions Desk also uses two Minis, one for the staff to access various admin tools, mail, etc. The other to drive a sign displaying admissions prices, welcoming groups, etc.

In January we’re going to be installing an exhibit developed by the Sociable Media Group at the Media Lab. So far it will have seven Mac Minis in it, as well as an iMac. There will also be a couple of Dells so I guess we’ll see how they hold up in comparison.

My wishlist for the Mini: Keep being ultra-stable, don’t get too heat sensitive. Faster graphics would be nice, but not at the expense of being more finicky.

PS – I have one in my basement at home as well, it’s running this blog, among other things. I think it’s about 3 years old. I have it on a small UPS to deal with short power outages, connected to the web via Verizon FiOS (also very reliable!).

Just a quick plug for some Mac applications that make my life a lot easier.

Namely. It’s a free application launcher for Mac OS X 10.5. I used to use MenuStrip in 10.4 but really only used it for the Quick Launcher feature. When I upgraded to 10.5, I found Namely, which does just one thing. You set a hot-key combination that lets you pop open the Namely window. Then type in a few letters of the application you want to launch, and hit enter. I find myself using the dock less and less these days.

Fluid. Another Mac OS X 10.5 only application. It lets you build a “site specific browser” i.e. a separate application out of a browser window. I’ve wrapped my Google Calendar in Fluid and just keep it running all the time.

VoodooPad Pro. I use it for two things. I have one document to keep track of stuff I’m doing. I have another that I lock with a password to keep track of all my passwords. I haven’t done any scripting with its built-in Lua script engine, but I keep meaning to…

FlySketch. I use this for screen grabs all the time. One great use is to capture those web receipts you get when you buy something or pay for something. I grab them with FlySketch and put them into VoodooPad Pro.

Li’l Snitch. A great little app that lets me know what’s happening on my net connection.

At the museum, we’re setting up a kiosk to let people browse our online collections database. We’re very much in the mode of trying things out using a simple setup and then when we see how that works, we can tweak it as needed.

The basic requirements were to let visitors browse a single website (http://webmuseum.mit.edu) but not to be able to follow any of the outgoing links. Additionally, the visitors should not be able to leave the web browser and start mucking about with the underlying computer.

Even though our old PowerMac G4’s are dropping like flies with broken power supply units, we have two left in the “good enough to reuse” bin. So I set one up with Mac OS X 10.5. Using MacPorts, I installed Squid and set up the network to use that squid as a proxy. Squid lets you configure which URLs it will go out and get, and which ones it will return an error on. I set it up to only return pages in the webmuseum.mit.edu site, and whenever a link outside that site is requested, it returns the toplevel page at http://webmuseum.mit.edu.

So far so good. The next thing I needed was a browser that won’t let visitors do too much other than browse. Luckily last week I bumped into Plainview. Plainview is a webkit based browser with no chrome. It also happens to have a kiosk mode that requires a password to get out of.

Then I set up a user account with Parental Controls, and only allow it to run the Plainview app and nothing else. I have the Mac boot up with that user login coming up automatically, and Plainview starts as a login application. Presto, a nice web kiosk. If users break out of Plainview, they can’t do anything else but log out of the system. We’ll see how long that takes…

One minor hitch in the entire setup – I don’t know whether it’s possible to set up Plainview to go directly into kiosk mode. Right now you have to type ⌘-/ and enter an administrator password to start kiosk mode.

Today I found myself sitting in a classroom discussion when the need arose to figure out how far each of 344 survey respondents had come to the place where the survey was being conducted. The survey included the home zip code of the subjects, and we knew, of course, the zip code of the survey location.

While I was Googling for how to best geocode the zip codes, I happened to also ask in the #geo irc channel (on oftc.net) whether there were any free distance calculation web services. Rich Gibson, who constructed geocoder.us piped up and said he was adding to the API for its web services and did people have any requests. What luck! I asked for something that given two zip codes would return a distance.

Not long thereafter, here’s what he came up with:

  http://geocoder.us/service/distance?zip1=41080&zip2=02139

which would return the distance between Petersburg, KY and Cambridge, MA.

So I was off to the races! I copied the list of zip codes from the Excel spreadsheet and pasted them into an Emacs buffer, then saved them as ‘zips’. Then in the shell (I use tcsh…):

First to get rid of duplicates:

% sort zips | uniq > zips2

Then, loop through them. I put line breaks with continuation characters into the geocoder line to fit inside this blog post.

% foreach zip ( `cat zips2` )
foreach? echo ${zip} `curl \
"http://geocoder.us/service/distance?zip1=41080&zip2=${zip}" \
 | sed -e 's/.*=//' | sed -e 's/ miles$//'` >> distances
foreach? end

And that’s it! I pasted the results back into the spreadsheet, got rid of the three bogus zipcodes in the data that resulted in errors from geocoder.us, used VLOOKUP to pull out the distances and I was done.

The service returned errors three times. I used the USPO zip code reverse lookup to verify that the codes were indeed bogus.

That’s my kind of web service. No WSDL, WADL, or WS-anything.

(Yes, I could have used Perl, Python, Ruby, etc. but I learned shell commands in 1981 before we had all that fancy stuff and it’s the first thing I try.)

I’ve been a Vonage customer for 3+ years now. Lately, though, the vultures and doomsayers have been close at hand as Vonage gets sued over and over. Since I have two lines, our home phone and my office phone with Vonage, I thought I’d hedge my bets and move my home phone to Verizon VoiceWing. The main appeal of going with VoiceWing was that they could actually supply E911 at my location.

That was a bit of a disaster. They sent the new modem pretty quickly, but the installation never worked. I spent about 3-4 hours on the phone with them over a couple of days and they were unable to get it to work.

There was nothing particularly weird about my setup. In fact, my Vonage adapters are sitting in pretty much the same configuration, right behind my main router. What became apparent after talking to the VoiceWing people is that they don’t have the capacity to deal with installation problems at all.

Luckily, I was able to cancel before the first month was up and got (most of) my money back.

Meanwhile, I’ll stick with Vonage for VoIP.