8.1 Web services: A SWOT analysis
8.1 Web services: A SWOT analysis
In terms of being just a component technology for facilitating distributed computing, Web services is in no way unique or even that radical . In this field Web services can be thought of as being the latest offspring from strong lineage that has included the Distributed Computing Environment (DCE), Microsoft s DCOM, and CORBA. In the area of remote software functionality invocation, XML Web services, with its ties to SOAP, leverage the tried-and- tested RPC methodology. Despite these ties with the past, XML Web services tangibly raise the ante when it comes to being a powerful and persuasive distributed-component technology. The new capabilities that Web services bring to the table include:
-
Consistent self-description mechanism thanks to WSDL
-
Expansive and extensible self-advertising capability via UDDI
-
Inextricable ties to XML ”still considered by much of the computer industry as the best means for facilitating data integration and application interoperability
-
Strict compliance to industry standards with bodies such as WS-I validating true, multivendor consistency
-
Genuine platform and programming language independence on both sides of the invoker-invokee boundary when it comes to deployment as well as development
-
Tight integration with pivotal Web protocols such as HTTP and SSL
Thanks to these capabilities, Web services, in essence, deliver a standardized, programmatic equivalent of the hitherto interactive Web experience. Popular services routinely available to browser users (e.g., Google search, Amazon query for all the books by Edward Rutherford ) can now be packaged and delivered for use within other applications to create even more sophisticated, highly integrated applications for e-business, corporate portals, and intelligent phones.
Cut to the chase, Web services extend the now commonplace Web paradigm to embrace software component technology. With Web services, applications can gain access to software functionality in much the same way, and with the same convenience, that a browser user locates and accesses an information retrieval (e.g., stock price quote) or data processing (e.g., loan payment calculation) capability on the Web. Figure 8.3 illustrates how Web services extend the hitherto primarily interactive Web experience to now include applications and software components . This is where the concept of a software smorgasbord on the Web comes in. The software model made available by Web services has the added attraction of being able to support any and all of the payment options that one may desire , ranging from free services to pay-as-you-go subscription schemes, with or without an initial one-time or annual payment.
Figure 8.3: Web services extend the hitherto primarily interactive, people-driven Web experience to now include programmatic access involving applications and software components.
Obviously, as repeatedly discussed in this book, one of the big factors that has precluded this software smorgasbord on the Web model from really taking flight, as had been hoped by so many, has been prevailing concerns about data security and privacy. But this model for software services across the Web is sound, compelling, and much needed. Thus, it will prevail and prosper ”possibly not exactly in the form in which it was originally conceived but as a derivative of it. This potential divergence from the original XML/SOAP/WSDL model is the one danger of the ongoing delay in widescale use of XML Web services.
8.1.1 Web services: Weaknesses and threats
At this juncture, as XML Web services continue to lean more toward theory than practice, one has no choice but to reflect as to whether there have been any pertinent historic precedents , particularly in the distributed computing arena. Unfortunately, there are two that immediately come to mind. Both of these, as with Web services, were widely endorsed by the computer industry; incessantly hyped by the media; were industry standards in their own right; and, as a net result of all of this, had lavish R&D funding behind them.
These two technologies were always behind the curve when it came to living up to their expectations. They flirted with fame for years . But in the end they were unceremoniously swept aside by alternate schemes. These two, always a bridesmaid, never a bride technologies, as some of you may recall, were OSI and ATM ”where OSI was ISO s seven-layer Open Systems Interconnection model, and the acronym ATM, in this instance, stood for asynchronous transfer mode.
OSI was cherished by the computer industry for over a decade as being the next standard for global, distributed communications. One of its strengths was going to be application-to-application communications via an RPC scheme. Though it was a direct competitor of its then market-leading SNA networking scheme, even IBM, toward the end of the 1980s, endorsed it, set up an OSI-specific development center in Rome, Italy, and spent millions developing OSI-compliant offerings.
Then there was Asynchronous Transfer Mode, which, in the early 1990s, was ardently embraced by the entire computer industry as the only way to realize the bandwidth that was going to be required to support networks that would have to handle data, voice, and video traffic. IBM, a major promoter of ATM from the start, invested well over $4 billion in ATM-specific R&D! Though ATM is still around as a means for realizing broadband WAN bandwidth in some scenarios, including some parts of the North American Internet backbone, it is very much a bit player in today s networking culture (and the pun was intended). There is a danger that Web services, in time, might join this select group ”and that is without even pointing out that a decade ago CORBA was widely endorsed and touted as the end-all and be-all of standards-compliant, platform-independent software component technology!
This is why some, including me, who believe that history can repeat itself start to get nervous as months slip by and Web services fail to come of age in terms of commercial success. The problem is that there are some uncanny parallels one can draw between Web services, OSI, and ATM ”without even getting bogged down in the debate that object-oriented technology, as a whole, has always lagged behind expectations. OSI and ATM, disconcertingly like Web services, were never out of the news ”until they got brushed aside. There was not much, if any, talk about disappointing performance in relation to expectations or that maybe everybody got it wrong about the real promise of these technologies. Vendors and the media kept on acting as if everything were fine and that there was ample justification for the slow ramp-up , until BOOM they were no longer strategic.
September 11 was unprecedented. However, ATM, much like Web services today, came to be just ahead of a global economic slowdown ”in that case the one that peaked in 1992 and led to the famous U.S. election catchphrase of: It s the economy, stupid. Thus, many waited for the economy to turn around so that enterprises would start investing in ATM. Around 1996, spurred by the growth of the Web, the economy did turn around and companies started spending heavily on networking and IT ”with Y2K now on the horizon. The problem was that Fast Ethernet, Gigabit Ethernet, Frame Relay, and the Internet as an extremely affordable WAN all conspired to diminish corporate interest in ATM. Then, and this is what is most unnerving, ATM, like XML and Web services, also had a tacit aura of high overhead and thus a somewhat suspect efficiency quotient .
XML, as we all know, is powerful, flexible, and extensible. But these attributes come at the cost of it also being somewhat verbose, complex, and requiring mutual intelligence at both ends. One only needs to look at an XML representation of an Excel spreadsheet, as shown in Figure 2.3(b), to appreciate that there could be developers who believe that there are better and more efficient ways to interchange data between applications ”particularly if one only has to worry about a fixed set of applications between a closed group of partners .
ATM had a similar issue. Though its value proposition was all about high bandwidth and speed, ATM insisted that all data had to be sliced and diced into minuscule, 53-byte cells before it could be transmitted over an ATM pipe. Though this slicing and dicing and the reassembly at the receiving end were all done by very fast, ATM-specific hardware chips, there were some, including me in one of my prior books, who agonized that this 53-byte cell architecture was too counterintuitive for technical comfort . The question now is whether XML is bumping up against a similar sentiment, which basically says that the overhead of XML per its intent to be totally unconstraining is too much of a luxury and that it might be more practical to revert back to industry- or application-specific data interchange mechanisms.
To this end, one can already see various camps pushing derivatives of XML Web services. Interestingly, these derivatives fall into two distinct categories: those who like the high-level Web services model but want to use it without XML and those who are totally committed to XML but want to use it directly over HTTP without getting involved with SOAP, WSDL, and even UDDI. In the normal course of events one would treat some derivatives as par for the computer industry and inevitable given the large population of vendors, developers, and end users involved. The problem in this particular instance is that these derivatives could come to pass, over the next few years, at the expense of the original SOAP/WSDL-centric XML Web-services model. But this is not a given. It is but a possibility ”a potential threat.
8.1.2 SWOT: Strengths, weaknesses, opportunities, and threats
Table 8.1 presents a SWOT analysis of XML Web services.
| Strengths |
|
| Weaknesses |
|
| Opportunities |
|
| Threats |
|
![Web Services[c] Theory and Practice](/icons/blank_book.jpg "Web Services[c] Theory and Practice"){kind=icon}