At the Forge: Bloglines Web Services
Last month, we looked at ways in which we can gather, or aggregate, content from a number of different Web sites and put together a single summary of the day's news. Although it was amazing to see how much we could accomplish with a little bit of code, the application I presented is merely a toy when compared with actual aggregators. My example application supports only one user, is controlled by a primitive configuration file, doesn't categorize Weblogs into groups, checks for Weblog updates only when we explicitly ask it to do so and doesn't check for or handle errors.
Creating a robust, user-friendly aggregator is beyond the scope of this column, given the attention to technical and design details that would be necessary. But several days before I sat down to write this column, something amazing happened. The free, Web-based Bloglines.com aggregation service, which many people use to keep track of their favorite Weblogs, announced the availability of a Web service API that allows independent developers to create and deploy applications that use the data and applications developed by Bloglines. The publication and availability of the Bloglines API marks the growing popularity of Web services among well-known sites and opens the door to new applications built on the underlying Bloglines infrastructure.
This month, we take a look at the Bloglines API, including the creation of a simple application based on it. The API is brand new as of this writing (early October 2004) and undoubtedly will evolve as more people use it. If Weblogs interest you, and if you still are waiting to see practical uses for Web services, this combination of events might have come just in time.
The basic idea behind Web services is quite simple: the Web's success is due in no small part to the fact that the client and server operating systems are irrelevant. So long as the client and server adhere to the HTTP and HTML specifications, they can communicate seamlessly. Linux has made inroads into the server space precisely for this reason.
Web services take this one step further, saying that computers and not people should be the biggest users of the Web. Although computers exchange information over HTTP, they send and receive data in XML, the markup language or meta-language, that has caught on like wildfire in recent years. If my computer can send XML in the HTTP request it sends to your computer, and your computer then returns XML in its HTTP response, we can exchange information regardless of what languages and operating systems we're using.
The original form of this service, known as XML-RPC, still exists and is great for fast, easy communication. But this idea was extended further, and a variety of data types, error-checking mechanisms and object serialization techniques were introduced that XML-RPC lacked. This extension became known as SOAP (Simple Object Access Protocol). SOAP theoretically can run on top of a variety of protocols, but it most often is sent on top of HTTP.
SOAP is a great solution to many problems, except that it is terribly complex, can be slow and is difficult to implement. And, both XML-RPC and SOAP require that the HTTP request include a well-formed XML request containing the query. One response to this growing complexity is REST (representational state transfer), in which all transactions are initiated by a simple HTTP GET request and all parameters are specified in the URL itself. The response then is an XML document containing the records and fields appropriate to the request. All of the Bloglines API calls are done with REST, although it's hard to say if this reflects the relatively simple queries now provided or if it's a design preference of the developers.
Although Web services probably are taking off behind corporate doors, only a few of the larger Web sites have made their plans and APIs public. The best-known examples are some of the largest and most profitable sites on the Web, including Amazon, eBay and Google. eBay charges for access to its Web services, with annual fees as well as per-transaction costs. By contrast, Amazon and Google have made their APIs freely available to the public, subject to usage restrictions and without making any promises regarding future availability.
In making its API public, Bloglines is indicating its interest in creating the same sort of developer community that Amazon, Google and eBay have created. This move also demonstrates its interest in remaining a leader in the world of Weblog aggregation and applications. Given Google's purchase of Blogger several years ago and the extensive search features that Bloglines is making available with its API, we might be witnessing the beginning of a new type of application or platform battle, with the Google and Bloglines APIs competing for attention.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide