Consider a function that's common to most 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
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.
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 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
Applications as Services
In the example shown in the earlier 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 figure below.
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 more subtle distinction is that integration
of changes to the tax- and shipping-rate portion of the application have
been deferred until run time--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
[Excerpted from Loosely Coupled: The Missing
Pieces of Web Services]
Posted Tuesday, March 18, 2003 10:01:48