News Stay informed about the latest enterprise technology news and product updates.

Loosely Coupled: The Missing Pieces of Web Services

Doug Kaye is a consultant, author and speaker. He draws upon nearly three decades of experience as a CEO and CTO and spends most of his time translating between the languages of business and technology. His latest book is called, "Loosely Coupled: The Missing Pieces of Web Services," of which this essay is an excerpt.

Doug Kaye is a consultant, author and speaker. He draws upon nearly three decades of experience as a CEO and CTO and spends most of his time translating between the languages of business and technology. His latest book is called, "Loosely Coupled: The Missing Pieces of Web Services," of which this essay is an excerpt.

Watch our webcast with guest Doug Kaye called, Project-Planning Strategies for Web Services.

Book Excerpt and Webcast

Essay: Why services?
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 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.

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 binding.

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 the application.

Copyright 2003, Doug Kaye and RDS Press. Printed with permission. RDS Strategies, LLC helps Web services technology vendors develop and deliver their messages to the marketplace, and helps IT shops plan their strategies for Web services. To register for RDS Strategies free email subscription called the 'IT Strategy Letter,' click here.

For More Information:

  • Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
  • Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
  • For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
  • Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

  • Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
  • Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
  • Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest industry lingo.
  • Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
  • Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.