to homepage
 Weekly emails: how to advanced search
 Glossary lookup:


> opinion > book excerpt

Why services?

by Doug Kaye
July 11th, 2003

Most of us no longer install our own television antennas; instead, we subscribe to cable-TV or satellite services. Instead of walking to the corner store to buy our morning newspapers, we use delivery services. In business, we outsource our human-resources tasks to payroll services, our gardening to landscaping services, and our office maintenance to janitorial services.

• print  • comment

Services are a new way of building distributed applications. We have five decades of experience with traditional applications, but just a few years with those built from services.

Doug Kaye is the author of Loosely Coupled: The Missing Pieces of Web Services, from which this article is taken. Read Doug's weblogs, sign up for his free IT Strategy Letter, or listen to his IT Conversations, a series of audio interviews with industry figures, at

Glossary terms: service-oriented, distributed, runtime, integration, lookup tool

Services are rapidly gaining ground in the IT world as well. Services are a new way of building distributed applications. We have five decades of experience with traditional applications, but just a few years with those built from services.

Consider an example that's common to most interactive applications (those on the World Wide Web) as well as to web services-based retail e-commerce applications: the calculation of sales tax or VAT. The traditional approach to integrating sales-tax calculations into an application is to license a software package, and subscribe to updates to an associated database or tax-rate table. A number of tax-calculation software vendors offer easy-to-integrate modules for a variety of programming languages, and they distribute updates to their sales-tax databases via CD-ROM or make them available for download over the Internet.

Sales taxes have a nasty habit of changing, which means you may need multiple versions of the database (and, perhaps, the code) running at the moment such changes take effect. And given the number of countries, provinces, states, counties, cities, and special districts with the authority to levy such taxes, these changes occur frequently. Consider what happens when not just the rates, but also the calculation algorithms change — then it's not just the data that must be updated, but the software as well.

Dealing with sales tax is most likely not one of your company's core business activities. You'd love to solve the problem just once, and let someone else worry about keeping that solution up to date. You'd probably like to receive sales-tax calculation as a service, just as you'd rather pay someone else to clean your office bathrooms.

Traditional application architecture
The figure below illustrates the architectural implications of an e-commerce application that uses a traditional solution for sales-tax calculation combined with a similar one for calculating shipping costs. Traditional Application Architecture

In this example, the vendors of tax- and shipping-rate information provide both algorithms (code libraries) and data. The tax data is delivered on CD-ROM, while the shipping-rate data is downloaded periodically over the Internet.

Consider this application architecture in terms of its life cycle. There are three distinct phases, separated by time:

Build time. A developer builds the application by using a linker or linkage editor to combine the application module and the library routines that support tax- and shipping-rate calculations. The result is an integrated application, with the tax- and shipping-rate logic built in, but not the data. (With some programming languages, modules are combined at runtime using class loaders — but since the relationships are still determined at build time, the effect is the same for the purposes of this discussion.)

Configuration time. On a regular or as-needed basis, the tax- and shipping-rate vendors deliver updates to their respective data. These updates are then copied into local databases by operations personnel. Updates might occur weekly or monthly — certainly more frequently than re-builds of the application.

Runtime. At runtime, the application calls the linked-in rate-calculation algorithms, which in turn query the local databases and return their results.

We could have merged the data with the application at build time, but that would require that we re-build the entire application every time a simple tax- or shipping-rate change occurs. By delaying the data-update process to the configuration phase, we've made the application less brittle, or better able to cope with change. This concept of postponing the reference to volatile data — or at least merging it as late as possible in the application life cycle — is an example of the concept of delayed binding.

Applications as services
In the example shown in the above figure, the shipping-rate information is obtained via electronic transfer in batch mode, perhaps using FTP. Suppose, instead, that the tax- and shipping-rate data were available over the Internet in real time. And suppose that through the use of web services, the algorithms that computed the tax and shipping rates ran at the sites of their respective vendors rather than at the application's site. The results would then look like the figure below. Service-Based Application Architecture

As compared to the traditional architecture, one based on services has two distinct characteristics. First, the algorithms and data are no longer parts of the application's local infrastructure, but are located off-site instead. The second and subtler distinction is that integration of changes to the tax- and shipping-rate portion of the application have been deferred until runtime — the last possible stage.

In fact, this e-commerce application is now immune to — even ignorant of — any changes in the rate algorithms or data. There will never be any new code modules or database updates to worry about. The service-oriented architecture has future-proofed the application.

More on this topic


Web services spell death for packaged apps
According to a new report from analyst group Ovum ...


Loosely Coupled: The Missing Pieces of Web Services
coverby Doug Kaye Explains the key concepts that need to be understood when deploying web services for practical business objectives. (352 pages, Apr 2003, RDS Press)


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.