Applying "Digital Hub" Concepts to Enterprise Software Design, Part 6by Adam Behringer
Welcome back to the Digital Hub Enterprise Software series! Today we are going to use web services to pull weather data out of our database "hub" and chart the data using Perl and AppleScript.
Though we will type some code and create some working software in this article, my primary goal is not to teach you Perl, AppleScript, or even web services. There are already great resources on those subjects (see the links at the end of the article for a few of them). Instead, I would like to use these technologies to spark your imagination and get you thinking about what is possible, particularly in business applications, when you combine diverse technologies and are no longer limited to completing tasks on one computer at a time.
We can do some really fun stuff when we combine server-based data repositories (the hub) with client-based display technologies (spokes). Web services technology provides a standard means of communication between your components, as well as between your software and third-party services.
This is the final article in a series of six articles on enterprise software design. To get the full value of the series, I recommend that you start at the beginning. I realize that there will be some of you who are just here for the subject of web services, so I will try to keep the dependencies on code that we previously covered to a minimum. You are at least required to build the database described in part two and the WeatherHub application that we built using WebObjects in part four.
What are Web Services? What Are They Good for?
Web services are a standardized way to move data between computers on a network using common Internet protocols. Many different computer languages have methods available for both vending and consuming web services, which makes them pretty easy to use in a cross-platform environment. If you want a more technical definition, there are a bunch of them out there on the net, but I find it is best not to get too bogged down in the details. Consider a common office scenario: you call your vendor and ask them to send their latest prices to you, which they send back to you in a fax. Now, imagine that instead of people, two computers make that transaction. A web service would be a great way to make a transaction like that happen.
Yes, but what are they good for? That is the real question, isn't it? Here are some initial ideas. By the end of the article, you should have a much better idea of specific applications.
Collaborative tools requiring centralized data storage.
Data input from a remote device (such as a thermometer in a polar ice cap).
Remotely querying the status of a server process.
Client-side report generation tools.
Cross-platform or cross-language data transfer.
The tutorial will focus on number four. Since Mac OS X has some great graphic tools and powerful scripting abilities, it is a great platform for building graphical reports. Also, tutorials are more rewarding when there are nice graphics as a reward for your efforts!
Creating a Web Service
How do we build a web service? We already did!
You say that you do not remember building a web service? Check out the last page of part four, near the end. We added one line of code to our WebObjects project:
XML.java class had a public method for adding weather data to the database, and a public method for building an XML string that contains the entire set of weather data. By registering that class with the above line of code, its public methods become accessible through as web service. Simple!
Of course, you can also vend a web service with just about any computer language that you like. Since our WeatherHub already has this functionality, though, most of our efforts in this article will deal with consuming the data provided by the web service.
Transferring XML with a Web Service
In the third article, we discussed a design for wrapping all of the weather data from our database into a single XML file. While you can certainly use web services to transfer simple data types like integers, we can also use a web service to transfer our complete XML. After all, it is just a long string, isn't it?
Imagine that you want to compute the average temperature of all of the temperature readings that are stored in our weather database. The result will be a single number. It would certainly be the most efficient use of network bandwidth to add a Java function to our
XML.java class that computes the average temperature on the server and then makes this result available through a web service. In fact, you could even do it at the database level before the data even gets passed to your WebObjects application. If you have huge data sets, it is better to process the data closer to the source so that the bulk of the data does not need to be processed by each component.
However, we are going to send the complete XML data set in our tutorial for a few reasons. The first reason to send all of the data is that we already have a function to generate the XML on the server. In real-world applications, you probably will not want to change the server software very often so that it can stay running 24 hours per day, seven days a week. Providing access to the raw data means not having to change the server application for each new situation that comes up. The second reason is that, as the designer of the server software, you may not know what the client applications are going to do with the data. Perhaps you want to give your customers access to the web service so that they can write their own spoke applications. By making all of the data available in an XML file, you provide maximum flexibility for web service clients.
Of course, when it comes to your own applications, you will have to make the decision based on your circumstances as to whether you will pre-process data on your server or vend it raw over your web service.
Displaying Data with Style: The Tutorial
Let's build a system for charting our weather data on a graphical timeline. We are going to leverage a Cocoa application I developed, called Bee Docs' Timeline. Please download the latest version from MacUpdate or VersionTracker. The demo version will be fine for our tutorial. Here is a screenshot of the application:
Bee Docs' Timeline can chart a timeline from a tab-delimited data file, so we will be using Perl to generate this data file based on information retrieved via a web service from our WeatherHub application. Then, our Perl script will call some AppleScript to load the data file into the timeline software and format it to look nice.
Before we build our script, there are a few preparatory chores that we need to attend to:
Perl is pre-installed with Mac OS X, but our script with take advantage of the following Perl modules which will need to be installed on your computer:
You should be able to download and install them using the
cpancommand in Terminal.
sudo cpan -i SOAP::Lite.
- Open your WeatherHub project in Xcode. Find the Properties file under the Resources group. In this file, uncomment the line
WOPort=55555. This will insure that the WeatherHub is accessible on a consistent port, which is important, since our Perl code will need to connect to a consistent URL.
- Run the WeatherHub application by pressing
Apple-Rin Xcode. It needs to be running for the Perl script to interact with it. In the real world, you would probably deploy the WeatherHub on a server in a data center, but everything can run on a single computer for our tutorial purposes.
Pages: 1, 2