“Web Services” is 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 about two years, yet when you look around and try to find useful Web Services, you'll be rather disappointed. Worse, most services that are offered publicly are wrappers around HTML-based content available on the Web, wrapped into a passthrough Web Service that basically performs screen scraping of HTML content.
Take a look at a site like XMethods.com and look down the list of services. You'll find only a handful of really useful ones, and most of those are not provided by the owners of the data. For example, there is a Web Service from a third party provider for FedEx shipping data, but FedEx doesn't provide a Web Service. Why is there a third-party wrapper for airline flight information, but none from 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 sense, as they do away with a lot of the formatting and data transfer coding necessary for two applications to 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, ironically, I was presenting two sessions on distributed applications and Web Services. I was having a discussion with one attendee about his application, which was primarily a shrink-wrapped Fat Client data service application with updates being retrieved over the Web occasionally. For his type of business, it seemed natural to look into Web Services to provide access to the data directly over the Web. But to my surprise, the gentlemen was vehemently 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?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. 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. You, 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 application, 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 AltaVista 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) have taken the time to wrap this interface into a Web Service that you can call 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 that on my Web site, I want to use the BabelFish service to translate messages on my message board into other languages. It works, although a little slowly and it's super easy to integrate this functionality into my existing Web site with a few lines of code. As a developer, I'm stoked at how easy the integration process is; my customers are happy because they can now view messages in stumbling translations of their own language. But, notice that in this process, AltaVista and Babelfish and even XMethods got completely lost. The users of my site (the visitors to the message board) don't know that the translation was actually performed by Babelfish. Neither XMethods, Alta Vista or The Babel Fish Corporation (which 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? Fee-based 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 difficult to use, due to completely non-standard interfaces that had to be coded in C++. This type of environment is exactly what the Web Services technology is supposed to address, but cannot provide at this time 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.
Therein lies the rub. I see a future where 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 Services prospering in vertical applications that deal with data served from the companies that make these products, or from one of their partners. But, all of these interfaces will likely be hidden from end users and the general developer, replaced by a licensing model that the providers charge for as part of the integration into larger applications.
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, more than two 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 (now .NET My Services) is aimed at providing the infrastructure to make this model possible. At the heart of it lies Microsoft's Passport technology, which has gotten off to a rocky start so far, with bandwidth and administration issues (see Markus Egger's Passport article in Issue 3 ? 2001 of Component Developer Magazine) and an SDK that's inadequately documented. But, Passport is crucial for the success of Microsoft's Web Services and it's important to keep an eye on how the .NET My Services architecture evolves 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 technology is important. While I think there has been too much hype about 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 applications! Those are the ones that have most to gain from Web Services, which allow integration of the Web as a network a lot easier than previously possible.
This group encompasses 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. 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 to use Web Services, to reduce the amount of code involved on the client side. It has also allowed me to plug this functionality into other applications much more easily because, the amount of code and dependencies have been reduced significantly. For example, the offline reader's message posting capabilities via the Web Service also allow users of my development tools to post pre-formatted bug reports directly from their development environment or from within the program in question. This technology is easy to integrate in an encapsulated Web Service environment. This is an example of a semi-internal use of Web Services.
Web Services will also 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, developers can spread application logic over multiple servers that provide data via Web Services. Most large providers are already using heavy transaction-based servers (Web servers or application servers), but in special scenarios, a Web Service approach can be very valuable. This is an internal use of Web Services.
Server-side Web Services will also be used, but not nearly as often, in my opinion. Server-side services will likely be of the “internal” or proprietary kind, providing 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. Instead, I anticipate 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, but there's very little to show for it and an even lower adoption rate of the few industry standards that have evolved.
Applications based on Web Services can in some cases be built easier than with other technologies, because of the standardized and more reusable interface. Web Services make life easier, but until a business model exists for providing Web Service content, count on seeing Web Services primarily in the “internal” domain rather than in the public domain.
For comments, you can post a message at:
http://www.westwind.com/wwthreads/default.asp?forum=Code+Magazine.
