- Introduction
- When Is a Web Service Not a Web Service?
- Web Services in a Small to Medium-Sized Enterprise (SME)
- Web Services in Bigger Enterprises
- Web Services in the Large
- Take the Long View
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Web Services in Bigger Enterprises
The concerns about how far we can treat Web Services as "interoperable RPC" come into starker relief when we look at using Web Services within larger organizations or between organizations. Many organizations have been searching for the Holy Grail of reuse, and may see Web Services as an easy way to deliver this goal. If all their distributed components can be exposed as Web Services, then their developers can just select from all the services available on the intranet—right? Unfortunately, things are not quite that simple. First, how do you find the services that are available? The obvious answer is UDDI (Universal Description, Discovery, and Integration), which leads us to the questions of where you find the UDDI service and who takes responsibility for creating and maintaining it. Also, who governs what goes into it? Can anyone advertise their services there, or is it only for "authorized" services? Even for an "authorized" service, who takes on responsibility for the ongoing maintenance of that service once the project in which it was used is complete? Who will keep track of which clients are using which services and ensure that services are not removed while they're still needed?
Second, even if you decide to have a "Web Service librarian" who will take on responsibility for the registration of Web Services, what about the scalability of the services that are being used? Were they intended for the increased amount of traffic? Will the increased load cause the original application to fail? Who owns and maintains the hardware on which the services run? Can the different stakeholders (and budget holders) agree to jointly fund hardware upgrades for these servers?
Another role for the Web Service librarian would be to reduce the proliferation of datatypes across an organization. How many definitions of a customer do you really need? Can you create common, XML-based datatypes and impose them across the organization? Indeed, can you impose common services? How many times must you reinvent the wheel? There is a major amount of work in pursuing this route—it's not an "easy option."
A final point here is that while WSDL is okay for interface description, it has no scope for semantics. It's important to understand the "sweet spots" of the services so that you use them in the manner intended. Using them in other ways can cause more problems than the benefits gained. There are ongoing initiatives to define the expected flow of interactions between a service and its clients, such as XLANG and Web Services Flow Language (WSFL). Without this capability, the use of Web Services will be more manual and error-prone than you might hope.