Wiki Home

Web Services Wishful Thinking

Namespace: VFP
-Something's bothersome about Web Services.

Is it just me, or is there something missing from the hype of web services? For starters, how about one, just one, compelling application?

For example: In the summer 2001 there was a discussion on the West Wind Message Board asking folks to brainstorm about possible future web services. The outcome was several dozen developers could not think of a single compelling application beyond the mundane (and revenue agnostic) "stock quote" and "weather alert" type of application.

Elsewhere I've been reading about web services being useful for booking a plane, hotel, and car, all from a single website. For example, you could go to the Delta Airlines website and, without leaving the Delta site, book a car from Dollar, and a room at the Hyatt. It's hard for me to see how this adds any value or convenience to a process which is already rather painless and, moreover, is less risky if you deal directly with these obviously independent entities. It's hard for me to imagine Delta Airlines rebooking me a room down the road from the Hyatt at 1:30 a.m. when this hotel is overbooked, and it's hard for me to imagine the Hyatt employee having much sympathy for my Delta Airlines confirmation number that's somehow not showing on her screen.

Here's another example: Fox Central DotNet. It's a portal that's used as a central square for news about the Fox community. That's fine, as far as it goes, but when quizzed about what other services could run through this portal, nothing valuable comes up.

So in short, I don't get it. A lot of people are going to invest a lot of time and a lot of money investing in web services that deliver marginal or insignificant value. This is hardly the foundation for the next generation of computing. More likely, by this time next year, it will be a past fad, just like "portals (1996)", "push computing (1996)", "network computing (1997)", "Convergence (1998)", "ASPs (1998), "B2B (1999)". All cool stuff, all not much to write home about, or to invest in.

-- Steven Black

A Web service is only a part of the philosophy of Bill Gates and Microsoft. .NET is really an idea that all computers at some point will be sharing information. With the CLR and XML standards, the tower of Babel is challenged and the next universal language is in place. This language and philosphy will result in a model of a world joined and information cascading back and forth to appropriate users. The "bigger" picture is not the specific application of the idea, it is the idea itself. Plato would greatly enjoy this. -- MarinoStathakis

I think this is bullshit. I wish more people would examine this critically. New technology should be presumed guilty unltil proven innocent. It's as if JP Morgan declared one day long ago that ceramics are the material of the future. Immediately all authors write about this, uncritically lauding the idea, and engineering goofballs, most without any original idea in their heads, try to build demo bridges, demo dams, and demo buildings out of ceramics. In spite of compelling evidence that web services are going to be a small if never significant piece of the information age, that's all that most engineering goofballs and sycophant writers are writing about.

The next universal language is not in place. It's just another language, another substandard versionable piece from Microsoft, in place to perpetuate the Continuous Obsolescence that's the cornerstone of the ubergeek's empire. Come aboard, suckers. Put the richest man on earth in charge of a so-called "visionary" software project and what do you get? What do you expect? Microsoft never has any insight into applications. They've never built a single successful development framework. But it's now decided by the sycophant cogniscendi, a priori, that this is the the way of your professional development and future. Who's kidding who? -- Steven Black

Actually, the best use that I could come up with would be to move some of the processes of an app, which needs regular maintenance or updates to a web service, to simplify deployment. For example, I work on a payroll program. If the tax calculation routine were moved to a web service, we would just have to update the web service when the tax tables changed, and not ship a new application. Same issue if a bug were found. We could also do this for imputed income tables, reporting layouts, etc.

Similar things could be done with other apps. Of course, I don't think this will become ubiquitous until the 'net' is much faster and more reliable. Also, requiring a customer to have a high speed internet connection may close the door to some smaller customers. Of course, we could install the service on their lan and move to the current model of shipping updates, which brings us right to where we are today.

I think the main issue of web services is that it is an easier way to do what many are already doing with XML or other web page parsers etc.
-- Bob Archer

It's confusing that people seem to use the term "web services" in two different ways. On the one hand there is the obvious interpretation simply as the concatenation of two familiar concepts. On the other hand, there appears to be a some more narrowly defined notion of a "Web Service", which is frequently referred to in the context of .NET. It would be helpful to see a concise definition of the meaning (or meanings) that people ascribe to this phrase.

If we're talking informally about "web services" (as implied by your use of lower case), wiki itself would seem to be a good example of a compelling web service, or are you just being modest, Steve? :-)

As far as "one application", that's not the intention of Web Services. That may be why its not very attractive to you. So how am I using web services? Think of an applicaton that times employees in an out of an employee time sheet. If I were to create a web service that did that, and I were to store all of the data, anyone with any type of application in any language on any platform could add the ability to log employees' hours or how their system is being used with 5 or 6 lines of code. They woudln't need to worry about the data base, or the logistics of that system, they just need to add 5 lines to their ASP app, or VFP app, or Linux app, or MS Office documents and that's it.

That's how I view web services anyway, creating an application by sticking together a bunch of pre-written pieces, with little or no work involved. It is a nice theory, currently, the web isn't in the shape to bet your business on that theory, but its coming. JMO. -- Mike Helland

I'd be happy to hear about one economically compelling application however it's structured. I understand the engineering imperative, my question is where's the business case in all this? Clearly this whole area's been oversold by its promoters. For me the question is just how big is this schmozzle going to be? Unless someone shows me where the money lies, it looks like this may be the largest pre-selling of a negative value proposition in the history of computing which, believe me, is some doing. At best this is minor ineroperability improvements dressed up as an impending software engineering revolution. A generous 3, dressed up like a 9. It's an imminence front. It's a put on. I could be wrong, but I doubt it.-- Steven Black

I'd say Web Services are about integration, and you bet there's a compelling business case for companies that provide content and data in any way. Ok, here's a scenario. Let's say you use Quicken and one of those bill paying services like What if Intuit published a Web Service interface spec that would allow people to directly import their bills into Quicken/Quickbooks and then pay them by posting back through the API to PayMyBills (or whatever other companies decide to implement the API as a Web Service). A Web Service would be much easier than whatever specs they have now, because you could access it with your tool of choice over the Web. PayMyBills could write it using Perl or PHP if they chose. Ok, where's the money in that? No direct money but both Intuit and PayMyBills benefit because of the ease of use it provides to the user who doesn't see the integration. If this is an open spec - even better. Intuit could publish available providers as they come online and allow users to pick the ones that would like to integrate with. I think there are tons of scenarios for this type of interaction. However, I think that for the 'small' player there are much fewer opportunities out there with this sort of stuff as it relies on partnerships. Unless someone has a compelling data source to share, I think most Web Services will end up being about integration. Kind of a like a remote data source...

Even no-win services like the FedEx/UPS services are really win solutions for those companies. By being easier to use more people will use their services - it's another sales feature. You bet a lot of people would want to use a FedEx package tracker *if* it came directly from FedEx (which it does not now). There's opportunity, but you can't blame the technology for lack of vision to utilize it in the business community. It's not all about direct money in the bank but of perceived value of a product in this case.

-- Rick Strahl

You're absolutely right. By implementing Web Services today we'll move our Windows specific DCOM components to completely open accessible? extensible (gotta get in all those buzzwords *g*) modules that will work nicely over the internet when it stabilizes. Then there's all the jazz about a 'universal' authentication system (Passport, which, IMO, is actually a pretty good idea) plus being able to store your documents on a central server? blah blah blah. I hope this anwers your question (otherwise, smack me and explain what a business case is), but what I think about is, well, imagine being able to easily create an application that uses a web service for inventory management and another one for your accounting. We just pieced together an application (cheaply and quickly, theoretically) that thousands of small retail stores could use. Maybe, your store needs to handle currency conversions or food stamps, instead of writing in that functionality, just subscribe to the web services that make quick work of those problems. Next we plug in the web service for the employee time card and maybe one that manages and stores all of your inventory promotions, oh, and there's a cool one out there that actually generates store signs based on your promotions. Say, now you've got a pretty nice app that you don't have to maintain, deploy, or even host. And in theory it was easy and inexpensive to create quickly. So, that's what you get you when look at our first dabblings in web services. Where will web services be in 5 years? Thats when the marketing types really have fun, so I'm not gonna bust in on their turf, but I think it will be exciting. -- Mike Helland

"Say, now you've got a pretty nice app that you don?t have to maintain, deploy, or even host." And, to boot, you've got one with a half-dozen failure points which you barely influence much less control. No client I have would allow such a situation to evolve around their mission critical software functions. For internal intranet processes I can see the case for web-services (AP offers a soap interface to the sales dept etc). Beyond that, I have yet to see how the risks of someone else's hardware problem impacting your bottom line pay off in reusabilty. In fact, recent and frequent MS Passport outages have demonstrated the folly in relying on others, no matter how large and well marketed, for mission critical software functions. -- Lauren Clarke

Correct. I'm going out on a limb here, and am putting my confidence in the people that make this stuff happen (hardware and software parts). I've noticed I have an unsurprisingly optimistic point of view here. Maybe thats because I'm a young idealist (what you "old timers" are probably thinking *g*), but I think it might be that I'm envisiong these apps 20-30 years from now, when I'm sitting in your shoes, when there really is no reason to look that far in this business. I dunno, just a guess, but like I said, what I can look out and see is exciting. -- Mike Helland

Old timer Ouch. That hurts *bg*. I suppose, if we were willing, we could use the past to predict the future and look at RPC/DCOM. SOAP is basically (and I realize this oversimplifies) a cross-platform way of doing the same thing which happens to use the internet for the plumbing. Given that, I can't imagine in the end, that SOAP will make too much more of a splash than these existing technologies did. -- ?lc

Let me give three examples of web services that I think point out the potential. The first was presented at DevCon, the FedEx tracker. It is a service that, when passed a tracking number, returns formatted information about the status of the package. Now shipping applications can include this service, showing when the package left, arrived and it?s current location. This can be a selling point for your software, a convince for your customers and as long as FedEx's competitors are behind, a compelling reason to use FedEx. The second example is Microsoft's new HailStorm set of services. Take the myContacts section of their service, for this example. This is a service that offers contact storage and manipulation on a central database. To start, HotMail will be using the service to store all of their contacts. Future versions of Outlook will also connect to the service so both applications use the same contact list. Cell phones may be configured to access this service over its wireless web access, meaning you can organize your contacts in Outlook and have them for use on your phone. And personal website can be configured to offer to place their contact information in your listing. The third example is more of a concept piece for now. DCOM works over a TCP/IP network and we use it to allow separate front ends to attach to the same middle-tier. By exchanging web services for DCOM, which will still work over internal networks, you have allowed your same front end to be used in house as well as remotely. How nice would it be to allow your advanced users to run the same client from work, home and the road. These are some of the possibilities that I see for this new concept in computing. This is the future, have no doubt, but also know that this will continue to evolve before it is complete. -- Louis Zelus

Steve, I would be interested in your comments on Confer Carl Web Services - ?CFK

Being someone who does internet development full-time, I can attest to the value of web services. We utilize UPSOnline to calculate shipping costs in real-time and Verisign's products for secure credit card processing. We have also created numerous extranets for clients which give them a competitive advantage over their competitors. The most common extranets we've developed help companies communicate with their dealers more effectively, including features like online invoice history, order entry and warranty submission and tracking. While it is true that these features could be developed as a traditional windows application, using a web site enables centralized management. Changes to the site are propagated to all their dealers immediately. -- Brian Marquis

Brian, while it is true that these are web services in the "business" sense, I think what Steve is referring to is web services in the technical realm, whereby you have a new architecture and tools for tying these services together. I think the argument or question is, "is it worth the investment to do the same things you are doing now a different way?". (Am I correct in this assumption, Steve?) Also, "Web Services" is sort of a misnomer. It should be called "IP Services" because it is not only for browser/web based applications. It's just another fancy way of saying "distributed". To me, this is one of the great advantages of "Web Services", the ability to be non-browser based but use the same protocols. I've never been a fan of browser based for practical business applications or transaction processing. (Retail E-commerce being the exception to the rule until something better comes along.) The other advantages I see are better standards for calling in and out and getting data in and out of remote services. But again, the question is, is it worth it to embrace this across the board and create huge re-engineering projects? I don't know, maybe it could help the economy. -- Randy Jean

The other issue I don't hear being raised that often is security. As a high-level developer, I heavily rely on the foundation I'm building on being secure. Has Microsoft covered this (critical) base as it promotes web services? Or, are we in for a rude awakening? Don't want to be alarmist, just prudent. -- Art Bergquist

Since web services use HTTP to talk between the server and client, the security level that exists between an internet browser and a web server should be the same between a web service consumer and the same web server. Security is definitely being addressed. -- Mike Helland

As someone who has been using Web Services in one form or another for about 5 years now I have to say I agree with Steve. I was in fact the one who posted the question a while back on WW message board regarding what would you use a Web Service for. In fact I wrote an editorial on this subject which you can look at at:

Basically I think that there will be a very limited market for broadband Web Services because there's a business model issue - what's in it for the provider. Currently there's no technology that deals with administration and a payment model which will hold back those that actually have content to provide.

However I think that Web Services are tremendously useful for internal APIs that are published to the outside world. Anything that pulls data off the Web programmatically is useful here whether it be data for your own private application or for a vertical app that you've built to push data up to or pull it down from the server. You can do this without Web Services and SOAP but it's more work that way... I use this type of set up for a number of things from order processing on my Web site, to managing inventory online to posting messages to the message board. All of those things could be done with pure HTML interfaces but the integration into a VFP Fat Client application makes these tasks much easier and convenient. Web Service offer nothing new - they only present a more convenient front end for it.

As to commercial applications, I think semi-proprietary interfaces are where this technology will shine. One good example would be my CC provider which now provides an XML interface along with a complicated TCP/IP based SDK. It would so much easier if I could actually access that API using SOAP messages from the client of my choice without having to go through the providers proprietary interfaces.

The biggest hurdle to greater acceptance of this technology is the age old problem of interoperability. LIke Steve said, it's one thing to publish data, it's another to be able to get the same data from lots of places in a consistent format. We've never had the industry manage to resolve issues along these lines and I don't see that changing. Microsoft's Hailstorm technology is trying to address that, but I'm by no means sure that MS can pull this off especially with the pricing model they have in mind.

-- Rick Strahl

This might be of interest:,1282,48105,00.html
Call me a pessemist, but I can't see how any universal authentication scheme could ever be safe...breaking into it would always be the holy grail of the hacker tribe. Not being able to use something like passport would take a lot of the convienience out of building an app out of web services. Personally, I think that after a few more widely publicized security breaches, the whole .Net idea will go the way of CP/M. Of course, Microsoft will doubtless be peddling something else by then. Russ Menapace

See also:

Software Development Magazine: Web Services: The Economic Argument - November 2001: Cost avoidance, complexity management and interoperability could create a new business model, by GradyBooch

Let me just throw out one more example of where I can see web services becoming helpful. I agree that many of the immediate examples are very specific to one or two purposes (wiki, Fox Central, even the Fedex tracker - who's going to pay money for that?). However, there is a huge area where businesses gather information that could and should be validated without requiring additional development. Example: address or name validation. A company builds a validation service which lets other companies validate name and/or address information during data capture. The requesting application can add this functionality with a few lines of code while it performs other duties. The publishing company may use the information for other purposes but would still be providing a "chargeable" service that could be tracked, monitored and eventually billed for. Another example: credit checks. Instead of having to pay for a full credit report and limit yourself to customers who actually want to pay, a credit company could offer a credit validation service for pennies per transaction that many companies would use to validate if a person has valid credit. I think there are business cases out there - the current list of examples however, border on the hobbyist or "can it be done" variety.

Another example on how the value of a web service might be looked at besides the direct revenue generating services (however they are paid for: through a subscription, per-use micro-payment, etc.) and the UPS/FedEx example of providing a service that others find so useful that they bring their business to you because of it: providing a web service that helps you, the provider of the service, do your job better and more efficiently (ie. more profitably). The first example that comes to mind is the U.S. Postal Service providing a web service that returns a correct POSTNET barcode for an address that is fed to it (probably validating the address before doing so) so that they can handle a piece of mail with that address and barcode printed on it better once it enters their system physically. Theoretically, they could then change how barcodes are generated from the service if they later decide to add information that they find would improve how they move and track pieces of mail (maybe(?) keeping the old way of barcoding backwards compatible so that they don't break outside systems that they have already certified to generate POSTNET barcodes that are not using the web service still usable. Several issues here that go off topic and I won't go off on that tangent). It seems like other service oriented businesses could benefit from this angle but other examples that come to mind at the moment probably could be done just as well from a web page and not need a web service... (ABC Oil Change Inc. has website where you type in your personal info (I know I can enter that stuff faster/more correctly than those people can, without trying to correct some 2-finger typist trying to spell your own name) and indicate the services you want done and you print a generated webpage that has a barcode with your ID and the services encoded that can be scanned at the service location: gets a bit impersonal but hopefully makes the work more efficient and reduces potential errors) Andy Needham
For an example of an app that makes great use of Web Services using a plug-in architecture, check out Watson. Unfortunately for most of you reading this, this killer app is OS X only, so you can only read about it. But take my word for it, it really does a great job of connecting many of these publicly available Web Services into a single, consistent and useful interface. -- Ed Leafe

If these are truly open "Web Services", then it seems like somebody (not naming names here) could develop a similar fat client, non-browser based VFP7 application that consumes these services as well, eh? Then it wouldn't be Mac OS X only. -- Randy Jean

For some reason I'm dissapointed about this offering. I think what I'm seeing here is that someone develops a web site for a standard web browser (HTML). And now, the redevelop the web site for another web browser (a web service version). Web Services shoudln't be requireing more work to do what already exists. Seems like the point was missed. -- Mike Helland

I don't see it like this. The point is a richer user experience by not being confined to the limitations of so-called browser "standards". I've always felt that the browser was just a glorified dumb terminal. Sure, there are lots of things you can do with Flash, Director, etc. to improve the on the browser UI, but I still think a "thick" client can deliver a much more robust platform and be much more secure/stable and a lot less "kludgy".

Here's another one for you. Our primary vendor is now offering a web service to access pricing and stock information. By incorporating this into our in-house application, we will be able to get real time information for generating quotes. Like the Fedex example, the fact that they offer this as a value-add and their competitors still do not gives them a definite advantage.
Someone else mentioned Quickbooks - with the latest release, they do offer an XML interface. Something else I am going to try to leverage.
All that's left is to come of with some compelling web service that we can offer our clients, so we can be a producer as well as a consumer of web services. -- Randy Rinker

Seems to me someone could eventually make a living by "brokering" web services -- sort of like being a portal and a search engine for them, and publishing and updating public interface details for a small fee. This would NOT be a business case for web services per se, it would simply be a business model built on top of existing web services, which may or may not have a solid business model behind them.

For me, personally, it would be a questionable proposition to rely heavily on any external web service, not knowing if they are going to be in business after the euphoria subsides. Had I built mission critical systems on top of some of the famous flash-in-the-pan dot-coms, I would be in the same Chapter 11 heap with the rest of them by now.

So, external web services can be a nice additional touch to a system, but nothing to bet the farm on. Internal web services is another story, because you know how solid or flaky they are going to be. -- PerttiKarjalainen

First of all, the portal and search engine exists. Its the UDDI. In your IE bar type in "uddi west wind" and hit enter. As far as payments go, I see the ISPs taking over this responsibility in the future. Its like TV, we don't pay NBC and CBS every month, we pay our cable company. -- Mike Helland

There goes that idea... UDDI seems a bit forbidding to a casual user, though... I wonder if there could be a simpler interface (heck, maybe there is, I just don't know it ). The current one is fine for programmers, but how's a Joe Doe going to insert, say, a price quote request service from Barnes & Nobles into his mom-and-pop website, easily... -- PerttiKarjalainen
Contributors: MarinoStathakis, Steven Black, Bob Archer, Mike Helland, Lauren Clarke, Louis Zelus, CFK, Brian Marquis, Randy Jean, Art Bergquist, Andrew MacNeill, Ed Leafe, Randy Rinker, PerttiKarjalainen
Category Business
( Topic last updated: 2002.01.19 02:18:53 AM )