- The Impact of Web Services on IT Architecture
- The Significance of Web Services
- Web Services' Role in the Architecture
- Web Service Application Packages
- Web Services Devices
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Significance of Web Services
The question that I want to address in this article is this: Are Web services just a new twist on the integration phase, or are they something genuinely new? Are Web services a fourth stage in the history of IT?
Judging from press releases and articles, many people clearly think so. There are some odd side effects. For instance the word middleware has become deeply unfashionable. For instance, consider the following quote from Steve Ballmer of Microsoft (quoted in UK Computing magazine, July 5, 2001): "What is the middleware business? It's the business for the guys who lost the operating system business. IBM tried, lost, got thumped in the operating system business." It seems to me that, for an organization that got thumped, IBM looks in remarkably good shape.
The starting point of this investigation is the architecture in the integration stage. This is illustrated in Figure 1.
){kind=link}
Figure 1 Architecture in the integration stage.
This figure illustrates, at the top, multiple end-user interface channels. At the bottom are transaction servers. I haven't split out a separate data layer because I believe that, in most cases, there is high cohesion between the transaction logic and the data; separating them is usually a poor choice. In the middle is a middleware layer tying the elements together. This architecture, of course, is simplified. There might be local systems, such as bank branches and factories. There might be data warehouse systems. There might be integration servers mediating among several of the back-end servers. Batch and business intelligence applications need a place. But the picture will do for the purpose of this discussion.
Technically, Web services are, as their name implies, involved in providing directly callable service entry points over the Web. The basic standard is the Simple Object Access Protocol (SOAP). SOAP is usually described as providing a Web-friendly version of Remote Procedure Calls (RPCs). The most notable differences to conventional RPCs are that the parameters are encoded in XML and that the protocol can be (but doesn't need to be) HTTP.
I strongly suspect that, in real life, Web services won't seem like RPCs at all. RPCs calls are typically fine-grained things and SOAP calls will in practice be much coarser-grained things. In other words, the XML in the SOAP call will encode a chunky piece of data rather than a few parameters—for instance, a complete order form rather than a single order line. There are two reasons for my suspicions. First, the overhead of SOAP will be far greater than that of RPCs, and there are performance problems with the Internet (at least, outside the United States). Therefore, when a service is called, you will want it to do as much work as possible before sending back a response. Second, services must be understandable to potential users, and it is easier to describe a complex data structure than to describe a complex sequence of procedure calls. But this is only a suspicion; I (and everybody else) don't have the real-life experience of using Web services in anger.
SOAP is only the basic building block. A range of standards exist for finding and describing Web services—in particular, Universal Description, Discovery and Integration (UDDI) and the Web Services Description Language (WSDL). Above them, many more standards are being developed for exchanging business rules, managing cross-business workflow, and specifying contractual agreements. Looking vertically, so to speak, many industry-specific or function-specific standards are being developed for common business documents such as invoices and order forms. It is true that most of these standards are aimed at wider e-business problems rather than Web services specifically, but because almost all these standards are XML-based, there is a tendency to lump them together. It is hard to keep up with all this standardization effort, and it is possible that the perceived complexity of this technology will slow down acceptance.