- 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
Web Services' Role in the Architecture
So where in the architecture do Web services reside? One possible place for Web services is as another channel. This is illustrated in Figure 2.
){kind=link}
Figure 2 Web services as a channel.
This concept is to have a separate Web services server that would use the existing middleware structure to communicate with the back-end servers. I suspect that many organizations will take this approach, at least in the short term, because it has a great advantage: You don't have to change the back-end services or the security and system-management infrastructure. While Web services technology is maturing, this option is probably the only choice. The least impact scenario for Web services is that Web services will end up as one, out of many, delivery mechanisms in a B2B server.
But there are challenges in this approach. As I noted earlier, I think that the input messages to the Web service likely will be large. Therefore, for each Web services input message, there will be many back-end messages to the transaction servers. Thus, there will be challenges ensuring data integrity and high performance. If your organization has not reached the integration stage in its IT development, these challenges might be severe.
Having Web services as a new channel is an extension to the integration architecture. It certainly does not imply a new IT stage, and middleware still plays a key role. The previous quote from Steve Ballmer clearly implies that Microsoft certainly has a different vision.
An alternative architecture is illustrated in Figure 3. Here the Web services are used internally to replace the middleware. You could argue that Web services technology is middleware (but let's not get lost in semantic disputes).
){kind=link}
Figure 3 Web service replaces middleware.
An obvious reason for not taking this approach is that, at least in the short term, Web services technology likely will be far less efficient than well-established middleware such as MQ Series and IIOP. But processing speeds and network capacity are going up year by year, so the cost of the additional overhead could be swamped by savings elsewhere.
So where are the savings? Do they exist? Some will argue that there are savings inherent in using XML. XML is flexible: You can add a new field to the message format, and the receiver does not need to be recompiled if it doesn't need to look at the field. In addition, lists in XML don't have a maximum number of elements, so changing the permitted list size doesn't mean recompiling everywhere. Some will argue that Web services directory and service description standards (UDDI and WSDL) give a greater ability to change the location and functionality of the services without changing client code. There is truth in all these points, but currently we don't know how much difference they really make. Loosely coupled systems do not eliminate the need for first-class configuration management, first-class deployment control, and first-class systems testing. The case that needs to be made is whether Web services provide a basis for making configuration management, deployment, and testing significantly easier.
It is also likely that Web services will see a role alongside traditional middleware. Web services might be an effective way of integrating disparate systems run by different divisions of a large organization. Several of the systems might be organized around a private middleware backbone of their own.