 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > Loosely Coupled: The Missing Pieces of Web Services |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||
Book Excerpt and Webcast
Essay: Why services? 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
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
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:
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
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, "
Watch our webcast with guest Doug Kaye called, 
