Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript
Megnut

Web Topics
All Articles
Browsers
ColdFusion
CSS
Database
Flash
Graphics
HTML/XHTML/DHTML
Scripting Languages
Tools
Weblogs

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab






Web Services with AppleScript and Perl
Pages: 1, 2, 3

Creating the SOAP Client in AppleScript

Now, for the other side: the AppleScript client that will contact this server. You can see the entire script, along with line numbers, here. I must caution the reader here: while this code is workable, it is not as robust as it might be. It is only a simple example of using SOAP services with AppleScript. For more complete information, see the techpubs documentation.



Lines 1 to 5 define the subroutine that lets you go from AppleScript to a Perl SOAP server.

=1= on fetch_SOAP_lite(endpoint, method, p)
=2=   using terms from application "http://www.apple.com/placebo"
=3=     tell application endpoint to return call soap 
        {method name:method, method namespace uri:endpoint, 
        SOAPAction:(endpoint & "#" & method), parameters:p}
=4=   end using terms from
=5= end fetch_SOAP_lite

The using terms from line 2 I got from Apple's AppleScript guide for SOAP. Apparently, when the application in a tell application ... is variable, AppleScript has no clue what vocabulary to use for the interactions. AppleScript does know, however, that if it's an HTTP URL, then we're using the SOAP or XML-RPC vocabulary. So you put in a dummy URL to keep AppleScript happy (the placebo), and all is well.

The endpoint parameter consists of both the URL as reported by the startup of the script, plus the name of the class I've selected for dispatching the methods. So, to get to the aforementioned server, we'll be using http://localhost:8001/Server here.

The method parameter is the particular SOAP method within the class. This will be fetch_headlines.

The p parameter is an AppleScript record corresponding to the named parameters received by the SOAP method.

Line 3 performs the SOAP call, connects to the proper endpoint, selects the right method, and passes the right parameters. The response is returned, unless a SOAP fault or exception is thrown, in which case the appropriate exception propagates outward.

Lines 7 through 9 define a fetch_headlines routine which uses the fetch_SOAP_lite subroutine to talk to our particular server:

=7= on fetch_headlines(uri)
=8=   return fetch_SOAP_lite("http://localhost:8001/Server", 
      "fetch_headlines", {uri:uri})
=9= end fetch_headlines

Given a URI parameter, I pass that as the named uri parameter to our Perl SOAP server, and then return the response. This effectively binds fetch_headlines in this AppleScript as if it was the fetch_headlines method in the remote server. And there's the magic of SOAP, if you ignore all the plumbing below.

Line 11 invokes the fetch_headlines subroutine (which calls the remote server to get a response), and stores the response in the response AppleScript variable:

=11= set response to fetch_headlines("http://www.perl.com/pace/perlnews.rdf")

I'm using the URI for the RSS headlines of O'Reilly's Perl.com web site, getting the latest information in the Perl world.

Lines 12 to 16 format the output of the response as a very minimal HTML page:

=12= set output to "<ul>" & return
=13= repeat with i in response
=14=  set output to output & "<li><a href=\"" 
      & (i's link) & "\">" & (i's title) & "</a></li>" & return
=15=   end repeat
=16=   set output to output & "</ul>" & return

A bullet list is created in output, where each item comes from grabbing the link and title items from the item records of the response. By using a record, the server can eventually return more than just the title and link (e.g., the age of the item) without breaking existing code. This is important to consider when writing client/server applications: designing the data so it can survive upgrades in an upward-compatible way.

Now that I've got the HTML, I need to write it to a file so a browser can read it. I'll select the name using the built-in temporary items folder special selector, appending fetch_headlines.html to the name, computed in line 17:

=17= set output_file to (path to temporary items folder as string)
     & "fetch_headlines.html"

Line 18 invokes the write_to_file subroutine (defined later) to put the content of the generated HTML into the designated file:

=18=	write_to_file(output, output_file, false)

Finally, Line 19 tells the Finder to open the file:

=19= tell application "Finder" to open output_file

As this file ends in .html, we'll be activating whatever we've designated as the default browser for HTML files. For me, that popped up an Internet Explorer window containing the appropriate links.

Lines 21 to 38 were lifted from a script found created by the AppleScript team:

=21= -- borrowed code
=22= on write_to_file(this_data, target_file, append_data)
=23=   try
=24=     set the target_file to the target_file as text
=25=     set the open_target_file to 
=26=       open for access file target_file with write permission
=27=     if append_data is false then 
=28=       set eof of the open_target_file to 0
=29=     write this_data to the open_target_file starting at eof
=30=     close access the open_target_file
=31=     return true
=32=   on error
=33=     try
=34=       close access file target_file
=35=     end try
=36=     return false
=37=   end try
=38= end write_to_file

Related Reading

Programming Web Services with SOAP
By James Snell, Doug Tidwell, Pavel Kulchenko

This takes the data in the first parameter and writes it (or appends it, depending on the third parameter) to the file named in the second parameter. I'll just treat it as a black box and give it to you in the same manner. One of the nice things about AppleScript is that it's been around long enough to have lots of snippets like this available online.

Conclusion

And there you have it. Stick that into a compiled script using something like Script Editor, and then run it. The application will contact the Perl SOAP server to get the current headlines from Perl.com. The data then gets reformatted by AppleScript into a nice bulleted list, and your browser is automatically opened to that page. If you see a headline you like, click on it and get the whole story.

In real life, I'd probably have the AppleScript pop up a dialog box asking me to choose from a list of sites instead of just hard wiring the one name into the script. In fact, you could build it as a full Cocoa application using AppleScript Studio and have the application itself show the headlines and make clickable links, which then get opened by a browser. And with an on idle loop, the AppleScript side could fetch the headlines once every five minutes or so, flagging new items in a bright color to get your attention. You could then leave it running on some corner of your screen, so you'd see the news as it happens.

Now that you know how easy it is to create a SOAP web service with Perl, you can provide services for your local AppleScripts and access much more than AppleScript can do on its own.

Randal L. Schwartz is a two-decade veteran of the software industry. He is skilled in software design, system administration, security, technical writing, and training.


Return to the Web Development DevCenter.