 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > The Dynamic, Smart, e-Business, .NET World of Web Services |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||
Introduction to Web Services In this rendition of The Hurwitz Trend Watch, several of our analysts consider the impact of Web Services in seven software, services, and sourcing markets. When we decided to take this admittedly early stab into the trends that might unfurl due to Web Services, we discovered we could not agree on a common definition of Web Services. When we examined our definitional incongruity, we discovered that our differences largely reflected the markets we cover. For example, as an analyst I cover markets having to do with development tools, middleware, and business intelligence. My primary focus on application servers, portals, content management, and core programming development environments means that I therefore tend to track major infrastructure software vendors, like Microsoft, IBM, Sun/iPlanet, Oracle, and others of that ilk. It is mainly this group of vendors who claim responsibility for engendering the Web Services movement. Given the context of the markets and vendors that I analyze, I possess a very specific idea of what Web Services means. My definition reflects the formal, W3C (World Wide Web Consortium) overseen, multiacronym (consisting mainly, though not exclusively, of SOAP, XML, and UDDI) version of Web Services. To me, much like the viewpoint of the vendors I track, Web Services represents a programming protocol that can expose aggregations of objects and content over the Internet, thereby turning the Internet and its various incarnations (the Web, intranet, extranets, and some others) into a dynamic medium for programmable information exchange. My infrastructure software born explanation must sound like double talk to analysts that cover service providers, like systems integrators, consultancies, VARs, ASPs, and ISPs. Those analysts think they already know what web services (note the lack of capitalization) are, since the service providers they cover have been using the "web services" term for several years, albeit without the standards bearing intellectual property stamp of the W3C. Other types of unique web-oriented provisioning vendors that supply content delivery as an extension of your infrastructure (like Akamai), or virtually real-time credit processing (eCredit), or payment processing (like Cybercash) also sometimes refer to what they provide as web services. So, our analysts who keep track of e-Commerce vendors might naturally think that "web services" already existed before the big infrastructure software vendors and the W3C hatched "Web Services." Definitions even run amok among infrastructure software vendors themselves. Several of the biggest vendors have already branded their implementation flavor of Web Services (.NET, dynamic e-Business, dynamic services, smart services, ad nauseam). Not to be completely outflanked by these first mover Web Services vendors, other infrastructure software vendors argue that you don't need a Web Service of the W3C variety to treat the Web as an object-oriented, content-infused, programmable medium. That indeed, when all programming parties agree, CORBA, COM, JINI, JNDI, and other distributed object related approaches offer the means to develop and consume web services, or perhaps Web services or even web Services. The Web Services crowd would argue back, rightfully so, that there really should be a single standard. THE HURWITZ TAKE: All these analysts, and all these vendors, and service providers, are right. Web Services, regardless of capitalization, can mean many things to many people, and even to many software programs. Even if you buy into the idea that Web Services, of the formal W3C variety, will in fact become the dominant definition for Web Services, or even the dominant standard and technique for turning the Web into a programmable medium, the other web services will survive. How can that be?
The net result -- Web Services for web services -- no matter how you define web services. Like so many movements, Web Services will unfold at different rates for different suppliers, and therefore for different buyers. As usual, the first vendors and correlating service providers that champion Web Services will be those down in the infrastructure and tooling layers; these layers of the software stack need to get Web Service-enabled before the rest of the stack can pump out Web Services. At the far end of the Web Services food chain we will find enterprise application vendors; why should they adopt Web Services until they can derive value, as in revenue, from Web Services? The beauty of these huge movements in the software industry is that every single supplier at some point has to sit down and figure out (a) how to position itself vis-a-vis Web Services, and (b) what kind of research and development investment it should make to bring its own Web Services-based offerings to market. The resulting complexity and confusion, arguments within product management groups, the failures and successes, the hype and the reality, will offer us a stunning spectacle for years to come. As a corporate IT person, should you worry yourself over Web Services? If you can't program Web Services by the end of 2001, should you simply burn your computer science degree and take up a job requiring a less stringent set of skills (perhaps an industry analyst job might suit you)? Fortunately, there is no need to panic, and here's why:
Our general advice: Watch with interest, learn if you have the time, but Web Services will have little commercial impact during 2001, some impact in 2002, and might reach gale force by 2003. Don't forget, Web Services will not replace all that old software plumbing. In fact, Web Services depends on that plumbing being there -- that's why the oft-asked question "Will Web Services replace Java?" is pretty naive. Web Services must demonstrate business added value, and until it does, all this seeding, watering, and fertilizing by the supply side will yield trunk, branches, and leaves, though not fruit. We sincerely hope you enjoy our treatises on Web Services. At this early stage, our goal is to help you think about Web Services. Whether you are a supply-side vendor working out positioning, a CIO trying to figure out how Web Services might apply to your corporate IT puzzle, a developer wondering if Web Services offers a way to upgrade a career, or even a line of business manager or CFO wondering what all the fuss is about, we hope we challenge your views a little and offer some education.
Copyright 2002 Hurwitz Group Inc. This article is excerpted from TrendWatch, a weekly publication of Hurwitz Group Inc. - an analyst, research, and consulting firm. To register for a free email subscription, click here.
For More Information:
|
|
|
|
|||||||||||||||||||||||
| ||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
Service providers will offer consulting, planning, training, and implementation support for solutions that, in part or in whole, consist of the formal Web Services. Thus, these service providers will offer web services regarding Web Services.
