I had my first encounter with web services about two years ago. I was contracting at the time, and Adobe had just announced the end of development of the software where I had most of my reputation, Authorware.  I needed to retool my skills to Adobe Flex, and I needed to convey to potential clients what kind of skills they could expect as I was retooling.  I decided I wanted my company website to reflect the bleeding edge of what I was doing. But I was also devoting a lot of time to blogging and participating in online newsgroups to try to spread the word, and I just didn't have time to manually update my site as often as I felt I needed to.

Luckily, Blogger, the web logging service I use, allows you to publish your blog as an RSS feed, so I realized that I could get double duty out of my blog—I could consume my own blog on my company website, simultaneously keeping my site fresh and in the moment and demonstrating that I could at least spell RSS.  I went looking for a tutorial on how to do this at my favorite tech site, 4guysfromrolla.com, and I found that the tutorials they had at the time were ASP.net.  I didn't want to learn ASP.net just for this one task, so I reluctantly turned to the Adobe website. I say reluctantly because 4guysfromrolla tutorials will usually teach you all of the concepts you need to do a task from start to finish, whereas Adobe articles often focus on how Adobe tools make it possible for you to perform a task without needing to know much about the underlying details of the technologies involved.  And, indeed, I found a nice article on Adobe's Dreamweaver Developer Center that gave me enough information that I could add this functionality into my web site in a couple of hours without having any clue as to what actually happens when you call a service.

For much of the time since then, the whole process has been shrouded in mystery to me.  A web service was a piece of specialized code that was created by some process I didn't have time to research and that made its way into your page in a way that was hidden from the sight of mere mortals by the magic of Dreamweaver's automatic code generation.  But then I was hired by VOIP.com, and I was asked to work on some pages that did a curious thing.  They submitted an xml request to a page on another server, and that server would respond back with an xml response which my pages then parsed and displayed. After working on a few of these pages, I realized that I had discovered by accident the side of the code that had been hidden behind the curtain by Dreamweaver.

I probably would have still considered the process a bit magical and mysterious—after all, what we do with these xml-based services can be pretty complex at times—but for one of those coincidences that turns an idle observation into an aha! moment. Some of my contracting clients have been with me for years, so if I can possibly find a way to support their projects while still honoring my full time job, I do it. One of my clients had decided to move his hosting from a Windows server to a Linux server, and by the time I knew anything about it, the transition had already been made. 

The problem is that the proprietary activation system on his DVD-based Authorware courses depended on an Access database on the server, and any Access drivers I could find for Linux required that a Windows machine be physically attached to the Linux machine. I had a feeling that if we asked his hosting company to do that, it would wind up being very expensive. And that's where the aha! came in—since a Windows server had to be involved anyway, couldn't we use some of the same techniques that I was using on my full-time job to get data from a cheap Windows hosting account and feed it through into the "real" website?  The php page sitting in between would mean that we could even point to the "old" Windows server and then change that to point to a different server at some future date, without needing to issue new DVD's.

And even at that point, I have to admit I was picturing a complex scenario where I was going to have to submit an XML request from php, rewrite the ASP pages to return XML formatted results, and then reformat those results to return the simple return- and tab-delimited results the existing application expected.  So I started looking into what the php version was of MSXML2.ServerXMLHTTP, the object that we typically use to send these types of requests in ASP classic.  It turns out that php has something called the cURL library, which essentially serves the same purpose.  When I started looking at the php examples, I realized that the task was much simpler than I'd thought—all I had to do was pass the request parameters through to the original ASP pages using cURL and my PHP pages would simply serve up the content from the ASP pages.  Only the URL would be different.

All of this has been a long way around to say that a web service is really any piece of content that you call on the web and use as a resource in your own page.  So, if the service is XML you can iterate through it like a recordset, for instance, or format it via XSLT and CSS.  If it's plain text, you can either just pass it on through, as I did, or process it line by line to wrap it in HTML. Or you can pass XML on through without processing.

This last application is very important, because sometimes we need to use AJAX or Flash to access services on a domain that we have no control over.  Both these technologies have restrictions on requests to other domains, but the normal ways around these restrictions, such as a crossdomain policy file for Flash, involve the need to put files on the server that hosts the feeds.  By consuming a service from your own page without processing it, you can make it available to Flash and AJAX files hosted on your server.

Read more from Amy Blankenship.