WS means different things--sometimes much different things--to different organizations. This paper explains the buzz around WS, the place of WS as a computing technology, and what such companies as Microsoft, Oracle, and IBM are trying to sell when they talk WS. WS can indeed help solve several of the problems of on-campus information systems. Clear understanding is essential to make that possibility real, and to avoid misapplications of a technology that's still quite young.
Similarly, WS is a collection of standards that make it far more straightforward to access remote computing power. With WS, a developer can automate retrieval of weather information, generate telephony messages, request solution of specialized scheduling or engineering problems, archive documents, and much more. In doing so, she has to pay no more attention to the characteristics of the remote host--its operating system, underlying hardware, human "locale", and so on--than a Web "surfer" does in bouncing from disparate sites in Germany to Canada to India while tracking down information.
The WWW has become an amazingly rich "resource ecology" for humans in search of information, products, and conversation. The technical idea behind WS is to enable a comparably rich infrastructure for distributed computing. WS promises to allow distant computers to co-operate on tasks too complex for them individually.
There are a couple of problems. First, the name "Web Services" is a terrible one, at least from the engineering perspective of working developers. WS can share networking software with the WWW, but it doesn't have to; WS can exist, in fact, utterly disjoint from the Web. Moreover, there are many "Web services" that aren't WS--all the ones targeted at human readers, for example. Keep in mind that WS is about computation--automated solutions, not ones that depend on human mediation.
The misnomer is in part an accident of history; an organization with more marketing than technical prowess diffused the label at a time when the technologists still had all their attention on engineering details.
At the same time, there have been powerful incentives for vendors including Microsoft and IBM to obscure and oversell the WS reality. The public pronouncements of these companies equate WS with a foggy and variable combination of e-commerce, subscription business models, and XML as a fictive universal solution.
Microsoft needs subscription revenues. The Internet is the most important medium of the future. The WWW, though, has largely been a fee-free domain. How can Microsoft solve the riddle this presents? The technical basis of WS has no more connection to the security and authentication mechanisms necessary for paid subscriptions than does the WWW; in fact, there are no-charge WS in operation, while a few outposts of the WWW already demand payment.
Microsoft presents WS, though, as a subscription-oriented
technology, and also generally identifies WS with its
proprietary .NET definition. Many other vendors
also see profit in the misidentification of WS with
e-commerce solutions, as this facilitates sale of the WS
products they have available now.
Intel wants all computing to be done on modestly-powered units--Intel chips--and none on "mainframes" or "servers". Therefore, the message Intel is broadcasting now, and will intensify in 2002, is that WS makes "peer-to-peer" (P2P) computing competitive with "server-based" architectures. In fact Linux running on an IBM mainframe makes an excellent host for several WS applications. That's not the way Intel wants decision-makers to think, though; for Intel, the warm marketing glow that currently surrounds WS should focus on a world filled with peering desktops.
IBM is like Microsoft superficially, in that it has
made a strategic decision to emphasize services in its
future revenues. For IBM, WS is all about development
in Java, where it holds several comparative advantages.
WS standards are carefully crafted to preserve their
language-neutrality, and there's certainly no necessary
connection between Java and WS. A belief to the contrary
serves IBM far better, though, than Microsoft's equation
of WS and .NET.
Other industry players are largely reactive. Sun
doesn't want .NET to succeed, because it
has difficulty imagining .NET-committed
organizations hosting their services on its mid-range
hardware. Hewlett-Packard owns a range of interesting
e-commerce and management technologies; its most coherent
WS tactic is to try to accelerate sales of these existing
products by re-branding with a WS affiliation.
Oracle has arguably achieved more than any of these
actors in construction of industrial-strength service
offerings; it's rarely able to articulate more in its
marketing, though, than that it is WS- and Java-enabled in
every way it wants to be.
Why is there so much more excitement about WS than DCOM or CORBA ever inspired? DCOM requires Microsoft licensing, and that's severely limited several aspects of its development. CORBA has almost the opposite problem; in many organizations, CORBA is perceived as antagonistic to Windows use. Although there's no technical basis for this in 2001, CORBA's destiny appears confined to niches including high-performance financial and medical computing.
A couple of technical "accidents" have particularly benefitted WS. WS relies on XML, and is better-suited to at least some XML-related tasks than CORBA. During a year when XML is one of the few technologies still in undeniable growth, its XML connection makes WS seem more modern than CORBA.
Most crucial, though, is that WS applications have the reputation for successful deployments, while CORBA is "hard". In practice, what this often means is that firewall policies in place on many networks block conventional CORBA traffic. Current WS most often re-uses Web technology, and thus passes through firewalls as permitted Web browsing. As superficial and transient as this situation is, it's determined a surprising amount of WS's goodwill.
WS standards come in several parts, only loosely federated. It's a contrast, in this way, to CORBA and DCOM, which are far more unified. There's hope that the loose coupling will encourage more responsive evolution of WS components. In any case, abundant material on WS technology is available online. Begin with [discuss with Kyler.]
On the other hand, there are opportunities for WS now, and even areas where it makes for a compelling answer. Any project considering DCOM or CORBA, or even COM, should evaluate WS also.
One of the domains where WS has achieved its quickest payoffs is in administrative consolidation. Organization-wide definitions of interfaces are making it possible to treat resources hosted on everything from mainframes to desktops in a unified way. While these projects tend not to be visible externally, and they're unglamorous at best, they often boast robust returns-on investment. This is one of the best matches for WS's XML base, and immaturity in WS's rather complex extensibility mechanisms doesn't hurt a project which most often has a straightforward datatyping scheme.
In any case, higher education should set its own WS agenda. Realize that vendors concentrate on WS as a solution to their own revenue problems, rather than the information-systems problems on the campus. Recognize that, despite this, there's a valuable technical core to WS.
URL: http://lairds.org/Kyler/UCMerced/Web_services