IT Strategy Letter, March 19, 2003

Aberdeen Group: Overhyped. "Overhyped, underperforming tools will result in a flat-to-shrinking market for Web services tools this year." [Source: InformationWeek]
Posted Tuesday, March 18, 2003 7:38:14 AM

No .Net at bCentral Yet. According to CNET's News.com, there's a "disconnect between bCentral, which delivers business applications over the Internet, and the Microsoft .Net initiative." The story quotes a customer who developed a web site using ASP .Net, but was forced to look elsewhere for hosting when it learned it couldn't host the site at bCentral. "The main reason for the lack of support for .Net Framework is that few of bCentral's 15,000 customers have asked for it, according to a Microsoft representative."

Analysts and CIOs should track the availability of .Net at bCentral as an important milestone in the adoption of web services.
Posted Friday, March 14, 2003 7:40:59 AM

The Overhead of SOAP. Mike Olson and Uche Ogbuji of Fourthought benchmarked the performance of SOAP as compared to XML-RPC, CORBA, and communications via raw sockets. [Blogged by James Robertson.] Not surprisingly, SOAP is slower by far than the others. In spite of the overhead, Jay Han posted his reasons to choose either XML-RPC or SOAP over CORBA.

Comparing apples to apples, the overhead for SOAP may be a deal killer for performance-sensitive RPC-style interfaces. Too slow? It really comes down to straightforward modeling and analysis. But certainly there's no one-size-fits-all rule.

The more interesting comparison is for document-style asynchronous interactions in which case the granularity of SOAP can be much greater and far fewer exchanges may be required to achieve the same results as a larger number of smaller RPC-style exchanges. And to the extent that these asynchronous document-style interactions involve disparate systems under the control of different organizations, the cost/benefit of SOAP continues to improve.
Posted Thursday, March 13, 2003 11:21:06 PM

Web Services--The Only Way to Make Wi-Fi Fly For Business? "Web services are the missing link to make Wi-Fi suitable for business use, according to integration specialist Iona. Mobile computing using Wi-Fi is not good enough for business use until applications are shielded from the unreliability and insecurity of the wireless connection." [Source: Silicon.com]
Posted Thursday, March 13, 2003 10:55:20 AM

I'm Darren, and I'm a Web-Services Nerd. Want a great introduction to web services? Check out this video clip produced by and starring Darren Barefoot. I think it says it all. [Source: Jon Udell]
Posted Tuesday, March 11, 2003 8:40:30 AM

REST vs. SOAP. Sam Ruby and Mark Baker are the latest to debate the relative merits of REST and SOAP, and RPC-and document-style interaction of web services. I don't want to add fuel to the fire (there's been more than enough of that), but I see the benefits of all of these models. They all have their places.

OTOH, I do think many organizations will eventually receive tremendous value from the more loosely coupled interaction models. As Sam wrote:

IMHO, the model of the future is going to be more closely based on events and alerts than on request/response. Applications will simply know to construct a given configuration of molecules when they receive a given stimulus. They won't necessarily even be aware of who the intended recipient of such "requests" is.

I learned much of this from the time I spent with John McDowall of Grand Central Communications. John helped me see that the asynchronous model is really all about event-driven architectures and techniques. I'll post more on this later in the week. In the meantime, you can bet the REST/SOAP and RPC/document discussions/arguments will continue.
Posted Monday, March 10, 2003 3:31:23 PM

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.

[Excerpted from Loosely Coupled: The Missing Pieces of Web Services]
Posted Tuesday, March 18, 2003 10:01:48 PM

The IT Strategy Letter is published weekly by Doug Kaye. The content is identical to Doug's weblogs.