- 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 Service Application Packages
The wider use of Web services within an organization would be considerably enhanced if application package suppliers start making their packages available as Web services. Such an application package is different from a traditional package in that it does not provide an end-user interface (except possibly as an example). A huge advantage of such as approach is that it makes the package easier to integrate with multiple channels, such as a branch network, a Web server, and a call center.
The next logical step from having a Web services package running in the organization is to have a web services package running outside the organization. This is illustrated in Figure 4.
){kind=link}
Figure 4 Web services dispersed across organizations.
Whereas the previous architectures were about technology change—they are really variations on the original integrated architecture—this architecture is about business change. Put simply, the idea is to outsource some of the business back-end IT functions to another organization. Taking the idea to the extreme, you can envisage some organizations that outsource all their back-end IT services. The growing application service providers (ASP) market indicates some degree of willingness to move to this model even without the Web services underpinning. It could go much further. A Microsoft whitepaper on Hailstorm paints a picture of a Web service holding customer data that can then be used by many other organizations for e-commerce. The advantage of this approach is that the customer themselves would be responsible for keeping their data up-to-date. The customer data could include not only name and address and preferred method of payment, but also e-mail address, calendar, and location. Clearly, there are obvious security and privacy concerns with this idea. I also wonder whether the other service providers will tolerate the lack of information about their customers. The customer list, after all, is a valuable business asset.
Many organizations today use outside services, especially in certain industries such as the travel business. What is done today is essentially the architecture illustrated in Figure 2, but using standards agreed upon between the two connected organizations rather than Web services standards. The difference between today's solutions and Figure 4 is that the applications become essentially one-tier; the server is directly on the Internet (okay, perhaps with a firewall for protection). The advantage of putting the Web services directly on the Internet is not only simplicity (versus existing EDI), but also the ease by which new organizations can use the Web services and existing organizations can outsource IT services.
Technically, the barriers to this scenario are formidable but solvable. Web services must mature. Many organizations will need convincing that Web services' security is up to scratch. In many parts of the world, the Internet itself is not as reliable and as fast as desired. Perhaps more serious barriers lie in the services themselves. The services would have to support the Web service interface directly; as noted earlier, these are likely to be different from existing transaction server interfaces.
Figure 4 is not the only possibility; Figure 5 offers an alternative.
){kind=link}
Figure 5 Web services directly connectable from devices.