Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Web Services Devices
The point is that all that the browsers call the Web services directly. Given the huge and continuing advances in chip technology, there is no question that this will be possible. But today there are some major technical issues. Suppose that the application is grocery shopping, and you want one Web service entry point to download the list of items for sale and another Web service entry point to upload the shopping list. Issues that arise include these:
- How is the client program distributed?
- How is the end user authenticated?
- It would be nice to incremental distribute changes rather than all the data every time. How could this be done?
These issues have been solved in another context, so there is no reason to believe that they will be showstoppers here. In some Web services literature I have seen, there is an implication that the client can be totally generic—presumably using WSDL to find out what the service does. That might be possible, but I am skeptical. Developing a generic Web service client application that is both functionally rich enough and easy to use looks to me to be formidably hard.
Both the options described in Figures 4 and 5 are major architectural changes. If this architecture becomes prevalent, it would truly be the fourth stage in the evolution of IT. Will they happen, and, if so, when?
In the short term, I believe that option 2, the Web services channel, makes the most sense for most organizations. The reasons, as discussed earlier, are the doubts about the Internet (especially its security) and the difficulty of recasting the interface of existing services. In the short term, middleware vendors (or whatever they now call themselves) are safe.
But, in the longer term, option 2 might not prevail. It all depends on how the market develops. I will explore both a pessimistic and an optimistic scenario.
The pessimistic scenario goes like this. In the past, there have been many attempts to standardize the format of electronic messages. The only examples of large-scale success have been through organizations such as the Society for Worldwide Interbank Financial Telecommunication (SWIFT), which have been capable of imposing a standard because they have supplied a much-needed service. Where organizations have come together to define a common format, such as EDI-based standards, they have mostly failed, either because the same organizations have not implemented the standard or because the standard is too unwieldy to be practical. So, whether XML-based standards will succeed where other standards have failed is open to doubt. If there are no standards, Web services as a means of interorganization communication becomes too hard because you need a new interface for each new organization that you want to talk to. Thus, Web services will be the new EDI—perhaps cheaper and more widespread than existing EDI, but having a similar niche and importance in IT thinking.
The optimistic scenario is that an unstoppable force will build around this technology. There will be two prongs to the attack. First, when a Web service provider sells a service that is cheaper and better than what is done in-house, the organization will be forced by competitive pressure to use the service. Second, devices, especially mobile devices, will be Web service–enabled. The organization that can sell the best Web service client application will create a de facto standard and force other Web server providers to follow suit.
Although I don't know what architectural changes will come about as a consequence of Web services, I do know what will be the driving force for change. If you look at the stages in IT evolution that I discussed near the beginning of this article, you will notice that the key driver for each new stage comes from the business, not from IT. Although technology opens up new opportunities, the business must lead in grasping those opportunities; technology is an enabler, not a driver. Plenty of IT technology has made little or no impact outside the computer room, and there have also been architectural changes that have failed, with client/server being the outstanding example. The fact that Web services is a concept that is being promoted by both Microsoft and IBM does not guarantee its success. Web services will happen when the business needs it.