|White Papers Home |  White Papers | Message Board |  Search |  Products |  Purchase | News |  |
The slippery slope of Web Services
by Rick Strahl
West Wind Technologies
Web Services are a popular topic these days. Microsoft and most other major vendors are pro-actively promoting Web Services as the solution to many of computing's problems in the area of Web and distributed application development. The concept of a Web Service standard and the SOAP specification has now been around for around 2 years, yet when you look around and try to find useful Web Services you'll be rather disappointed at the dearth of services that are available. Worse, most services that are offered publicly are wrappers around HTML based content available on the Web, wrappered into a passthrough Web Service that basically performs screen scraping of HTML content. Take a look at a site such as XMethods.com and look down the list of services and you'll find a handful or really useful ones, and even of those mostly aren't provided by the owners of the data. For example, why is there a Web Service from a third party provider that provides FedEx shipping data, but why doesn't FedEx have a Web Service. Why is there wrapper for airline flight information, which is provided by a third party and not by the FAA or the various airport authorities? Stock quotes, news the list goes on. Very few actual data providers have jumped on the Web Services bandwagon although these folks are the prime suspects for making this technology fly.
So, what's the problem?
There's good reason that Web Services have been so popular in the development community. They solve a technical problem through a standard interface to access remote data and logic on a server. Technically, Web Services make a lot of sense as they do away with a lot of the formatting and data transfer over the network involved in having two applications communicate over the Internet. In short, they make life easy for developers who need to pass data over the wire.
But let's look at things from a business perspective. What's in it for the provider? This point really was brought home to me at a recent conference where I was giving, ironically, two sessions on distributed applications and Web Services. I was having a discussion with one attendee about his application which was primarily a data service type application that currently runs as a shrink wrapped Fat Client application with updates being retrieved over the Web occasionally. For his type of business it seemed natural to look into Web Services and providing access to the data directly over the Web. But to my surprise the gentlemen vehemently was opposed to this model. When I asked why I got a very clear answer: It does away with product and data branding.
The Web today serves data of all kinds and you can find just about anything online. Most of that content is in HTML format and it's branded. You go to Yahoo to get your news, FedEx to get your tracking information. And of course you're bombarded with the company logos and additional Web advertising that is making these sites a pretty penny. And you definitely know who you are getting your information/data from even if it's otherwise free.
If these companies make their data available as Web Services the data becomes a commodity that is no longer branded. The idea behind a Web Service is that you can plug it into any application and consume the data. The problem from the provider's perspective is that they don't get any bennies off that data they collected it, they provided it, and you're even using their server resources when you call the Web Service on their Web site. You as the consumer get all the benefits, while the provider pays for all the expense of providing the data. If you integrate this functionality into a third party vertical app the end users of the application don't even know where the data is coming from and the provider gets no brand recognition whatsoever.
Let me give you an example. Many of you have probably heard of the Babelfish translation facilities that Alta Vista provides on their Web site. A Web Service of this functionality would be pretty cool and sure enough the folks at XMethods (and several others actually) have taken the time to wrap this interface into a Web Service that's callable as a single method with two parameters. Nice and easy, but it's pretty slow because it's a passthrough service that calls out to another Web site to get its data.
Let's say on my Web site, I want to use the BabelFish service to translate messages on my message board into other languages. It works, albeit a little slowly and it's super easy to integrate this functionality into my existing Web site with a handful of lines of code. As a developer I'm stoked how easy the integration process is and my customers are happy because they can now view messages in stumbling (<g>) translations of their own language. But notice that in this process Alta Vista and Babelfish and even XMethods got completely lost. The actual users of my site the visitors of the message board don't know that the translation was actually performed by Babelfish. Neither XMethods, Alta-Vista or The Babel Fish Corporation (which actually creates the translation software SDK used by Alta-Vista) got any credit.
Paying the piper
So, what's the provider's incentive to provide data in Web Service format if they don't get credit for it? For pay Web Services haven't really caught on yet because there's no standard mechanism to provide for the security and metering that's required to make this happen. You can of course build a custom solution that requires login information being passed back and forth for each Web Service hit or passing back and forth session information of some sort. Does that sound familiar? If you've ever used any third party IP based libraries that provide proprietary service data (usually using a proprietary SDK) this is exactly what these tools have done in the past. For example, my old credit card provider used a huge SDK to provide a client side IP/SSL/Transaction library to pass credit card data over the wire and bring back the validation data. The data was proprietary and the SDK was a bear to use using completely non-standard interfaces that had to be coded using C++. This type of environment is exactly what Web Services are supposed to address but at this time cannot provide due to the missing payment and security models. As a service provider you can still build an SDK and use Web Services to make the SDK internals work, but externally you're still exposing an SDK rather than the native Web Service.
And therein lies the rub. I see a future were Web Services are widely used internally in situations where the provider passes data back and forth between two known parties and may even be in control of both ends of the connection (API to API). I also see Web Service prospering in vertical applications that deal with data served from the prospective companies that make these products or one of their partners that they have agreements with. But all of these interfaces will likely be hidden from end users and the general developer, opting for a licensing model that the providers charge as part of the integration into larger apps.
Generic Web Services that we all can use for free will likely take a while to come along if ever. Sure, for some companies it'll make sense to have this data available. It makes sense for FedEx and UPS to work to make their business services as accessible as possible the easier it is to get status information the more likely you're going to use them to deliver your packages. But even today 2+ years after the concept of Web Services was born, neither of these obvious providers has made a Web Service available.
The general model of Web Services is likely to be based on a fee structure and some sort of payment system to make the Web Service model economically feasible. Microsoft's Hailstorm initiative is aimed at providing the infrastructure to make this model possible. At the heart of Hailstorm lies Microsoft's Passport technology which has gotten off to a rocky start so far with bandwidth and administration issues (see Markus article in the last issue) and an SDK that's woefully underdocumented. But Passport is crucial for the success of Microsoft's Web Service and it's important to keep an eye on how Hailstorm's architecture works out to provide the payment framework necessary to make many Web Services viable. I'm sure you're going to see vast improvements there and hear a lot more about this initiative in the months to come.
A proprietary Web Service Future
It's important to understand even with these considerations in mind that Web Services are an important technology. While I think there's been hype to possibly the wrong end of the Web Service architecture, I think there are still many places where Web Services will be a perfect fit.
I think the most common use of Web Services will be in custom applications that have any sort of offline interface. That's right Fat Client desktop apps! Those are the ones that have most to gain from Web Services because it allows them to integrate the Web as a network a lot easier than previously.
This group can encompass most vertical applications that need to communicate with central servers to perform data updates or share data with a server application. Vertical applications already do this to pass proprietary data over the wire and can now take advantage of a standard interface that is much easier to implement on both the client and the server to perform these same operations. I have personally built a number of applications that do this from an offline order manager for my online Web store to an offline reader application for my message board. In the past these interfaces ran straight XML communications over HTTP but I've updated them recently by porting them to use Web Services instead to reduce the amount of code involved on the client side. It has also allowed me to plug in the functionality into other applications much more easily because the amount of code and dependencies has been reduced significantly. For example, the offline reader's message posting capabilities via the Web Service also allow my users of my development tools to post pre-formatted bug reports directly from their development environment or from within the program in question. Web Services make this technology easy to integrate in an encapsulated environment. This is an example semi-internal use of Web Services.
Web Services also will be important for large server applications that need to split up operations to handle load balancing scenarios. Rather than building centralized solutions running on single machines or even single networks application logic can be spread around multiple servers that provide data via Web Services. This is a rather specialized scenario for large providers that are already using heavy transaction based servers (Web servers or application servers), but to those that need perform these large operations this will be very valuable. This is an internal use of Web Services.
Server side Web Services will also be used but not nearly as much in my estimate. Server side services will likely be of the 'internal' or proprietary kind to provide backend access to data and application partitioning rather than providing raw content. E-Commerce business to business services also fall into this category but I wouldn't hold my breath for common standards, but rather proprietary interfaces to exchange data in customized formats that are application specific. There has been talk about standardization in various industries for years since the advent of XML and there's very little to show for it and an even lower adoption rate of the few industry standards that have evolved.
As you can see Web Services offer a number of opportunities to build applications in ways that although possible before can now be built easier and using a standardized and more reusable interface. Web Services make life easier, but until business can figure out a business model for providing Web Service content, count on seeing Web Services primarily in the 'internal' domain rather than in the public domain to provide content.
For comments, you can post a message at:
Rick Strahl is president of West Wind Technologies on Maui, Hawaii. The company specializes in Web and distributed application development and tools with focus on Windows 2000, ISAPI, .Net and Visual Studio. Rick is author of West Wind Web Connection, a powerful and widely used Web application framework for Visual FoxPro and West Wind HTML Help Builder. He's also a Microsoft Most Valuable Professional, and a frequent contributor to magazines and books. He is co-publisher and co-editor of CoDe magazine, and his book, "Internet Applications with Visual FoxPro 6.0", is published by Hentzenwerke Publishing. For more information please visit: http://www.west-wind.com/.
|White Papers Home |  White Papers | Message Board |  Search |  Products |  Purchase | News |  |