Service-Oriented Architectures

A Web Service is an integration technology. To achieve the potential benefits, companies will need to create a service-oriented architecture.

Putting a Web Service Interface on an Application Doesn't Reap the Benefits

It's been called many things, including service-oriented architecture (SOA), service-oriented development architecture (SODA), and service-oriented integration (SOI); however, at the heart of all three is the realization that the benefits of Web Services are not going to come accidentally.

A service-oriented architecture is a company's explicit blueprint for how it is going to implement Web Services within the enterprise. It covers a lot of the ground we discussed in Chapter 12. When companies begin experimenting with Web Services, there will be a tendency to use them as direct replacements for remote procedure calls. This will merely replace one form of spaghetti integration with another (admittedly, one for which it is easier to develop applications).

The SOA needs to define what the applications are going to be in the future, especially where any major functionality can be pulled out of applications and reused. The SOA needs to encourage publish and subscribe– style interaction, asynchronous communication, and composite applications, because these define where the real benefits will be realized.

The benefits of using Web Services are not going to come automatically, merely from adopting the technology, just as switching from C to C++ did not deliver on the benefits of object-oriented technology until people learned how to design and program in a different way.

Performance Penalties

There is a significant performance penalty in using Web Services. It consists of several bits of overhead added on top of each other, including the following: converting binary representation to Unicode, tagging each value, including more data than is generally needed for each message, encrypting, and parsing and marshalling at each end. As Dan Davis and Manish Parashar of Rutgers point out in an unpublished manuscript, the latency involved when using SOAP over http can be as much as 10 to 100 times as great as using CORBA or RMI.^[103]

I'm a complete believer that the performance hit will turn out to be worth it for the flexibility, and that people will engineer in ways to speed this up or make it less of an issue. This is exactly what happened with relational databases in the 1980s: They had a huge performance shortfall compared with hierarchic or Codasyl databases, yet now no one is implementing any new systems based on hierarchic or Codasyl models. (Codasyl was a prerelational database standard that had much better performance characteristics than relational databases.)

However, while we are waiting for these performance problems to be sorted out, we would do well to adjust the way we intend to use Web Services. As mentioned earlier, everything that can be done asynchronously should be. Another area to investigate is whether the services being implemented are large enough make the performance penalty workable.

Fine-Grain and Coarse-Grain Services

Grain refers to the size of a service. A fine-grain service might be one that adds two numbers together. A coarse-grain service might prepare your corporate tax return.

At this stage in the market adoption, most of the services publicly available are fairly fine grained: currency conversion, unit-of-measure conversion, and even simple calculator functions. I believe that for the next several years, coarse-grain services will be the most economical to implement. Not only is performance overhead an issue, but the management tools aren't in place and the registry services are not yet mature. This means that there is a management overhead, and managing a few hundred medium-to coarse-grain services is going to be far easier than managing thousands or tens of thousands of fine-to medium-grain services.

^[103]Dan Davis and Manish Parashar, "Latency Performance of SOAP Implementations," unpublished manuscript. Available at http://www.cse.ogi.edu/~wuchang/cse581_winter2002/papers/p2p-p2pws02-soap.pdf.