Fog Creek Software
Discussion Board

Web Services

Hi, just need some info..I am just wondering how to explain in simple terms what webservices means to some executives in my office who don't have technical background.

All info will be appeciated...thanks

Friday, February 28, 2003

I have a technical background, but I don't really know what it means either.

Actually, that's the point. It doesn't mean anything, unless you put it to use. So try to explain what you can use it for, and how it might be more appropriate for that use than other solutions.

Executives, as do end-users, do not care about technology or its meaning. They care about the goals it lets them achieve...

Practical Geezer
Friday, February 28, 2003

Web services = RPC using XML via HTTP

Jan Derk
Friday, February 28, 2003

The most basic explaination for non-technical management is that web services allow computer programs to surf the web. They allow the programs to go to specific web servers and get information just like a person going to a specific web site and reading or downloading something.

I've found that gets the ball rolling nicely.


Friday, February 28, 2003

Tell them it's simply a buzzword for a program that exchanges data with other computer programs over the Web. Then give examples.

A good example is the way a manufacter would use a Web Service to accept orders from wholesaler's computer systems. The wholesaler's computer program would automatically connect to (consume) the manufacter's Web Service each night to send their orders to the manufacter in a big xml flie.

What are some other good simple examples?

Friday, February 28, 2003

As Jeff says a good example minus the techincal terms is the best way to describe it.

You should start put by explaining the current system, its drawbacks; then proceed to explain with an example about web serivces. My fav is the one about a hotel and rent a car company.

THen proceed to explain about XML, HTTP, WSDL, UDDI - this and where it would fir in with the explanation you gave

Prakash S
Friday, February 28, 2003


That is a good summary for techies that understand RPC (assuming you mean Remote Procedure Call), XML, and HTTP.

To an executive, or at least, an end-user, it means nothing.
I usually choose not to understand it, if only to force you to explain it in terms of "ends", not "means".

I assume you would have said something similar to the posters after you, had I made that clear enough to begin with, assuming you respond to my response.

Practical Geezer
Friday, February 28, 2003

What about : a way for a program located on your PC to send a query to a web server, and receive an answer? As a practical example, querying Amazon for a particular book through its ISBN, and displaying it in a dedicated application.

Frederic Faure
Friday, February 28, 2003

Just tell them this is the first time in history the whole industry agrees upon a way to let many computers work together. Bottom line is it will cost us less money to do it this way.

Just me (Sir to you)
Friday, February 28, 2003

"What about : a way for a program located on your PC to send a query to a web server, and receive an answer?"


"As a practical example, querying Amazon for a particular book through its ISBN, and displaying it in a dedicated application."

Now that's more like it. Now you have to explain why you can't do that without web services, or why web services are better than current technology.

Put's things in perspective.

Practical Geezer
Friday, February 28, 2003

Use an example the audience can relate to.  For executives, the "Stock Quote" example has worked for me in the past - nearly all executives use their online brokerage account. 

Using this example, the benefits of "real-time" data access across the net will be immediately understood my most Execs.

Jeff MacDonald
Friday, February 28, 2003

It's a way to share information and services. It
only works when everyone uses it. So a few tried.

Saving was mostly lost trying to get everyone to
stop meaning something different when they were
say the same thing. This was key, the saving
depended on the man power saved when everyone was
saying the same thing and meant the same thing.

The documentation of a web service, the real
world agreement to bind oneself to the
specification, and the on going effort to
understand the specification and improve upon
them when possible with the participation of
all parties is more crucial than the transport
protocols involved.

-- Not a salesguy

Li-fan Chen
Friday, February 28, 2003

The stock quote example is a good one.

I've shown how a user can use a stock retrieval web service to retrieve their stocks into Excel, and how they can use the same web service to update a list of stocks on a web page. Then show how they can use the same service to get their quotes on their cell phone.

I always try to show the web service being used in a multiple ways, since if you just show it being used on way they fail to see how it is different from a "regular" program.

Go Linux Go!
Friday, February 28, 2003

Expense a new PowerBook and start up Sherlock.

Friday, February 28, 2003

I enjoyed these recent relevant posts by Michi Henning:

Steven E. Harris
Friday, February 28, 2003

The best explanation I've heard was breaking up Web Services into two items; XML and then Web Services.

Think of XML like an Excel spread sheet. It holds lists of data. And much like Excel, it can contain multiple "sheets" with different data in them. And also like Excel, you can link data in one sheet to another.

NOTE: When I witnessed this explanation, the IT guy actually opened up Excel and gave an example. Because it was so simple (list of prices on one sheet, list of quantities and the calculated total (sheet 1 price * QTY) on the second sheet. The executives instantly understood this because most of them have had some experience in Excel (although two of them said, "I didn't know I could do that in Excel, cool").

A Web Service is just like a Web Server. The only difference is a Web Service sends a web page while a Web Service sends an XML file.

Hope this helps. I will say that this can get confusing, even if you know what you're talking about.

Friday, February 28, 2003

Someone said: "Web services = RPC using XML via HTTP"

In the Delphi world at least, I know there's a lot of stuff going on with n-tier development and putting services on internet servers, but which has nothing to do with XML and isn't necessarily transmitted via HTTP.  For example, see RemObjects at, kbmMW at , Rinse at .

I assume there's equivalent work going on for .NET, Java, and other languages by developers who feel the standardized XML or SOAP RPC's are too cumbersome, restrictive, or slow.

Is there any reason that these proprietary methods of implementing remote procedure calls shouldn't also be called "web services"?

Herbert Sitz
Friday, February 28, 2003

"Is there any reason that these proprietary methods of implementing remote procedure calls shouldn't also be called "web services"? "

Clarity? Why confuse an issue deliberately (Yes, I know that in this age of "total information war" this is a favorate tactic loved by many IT companies)?

Just me (Sir to you)
Monday, March 3, 2003

Sir -- Yes, that is one reason, I guess.  But what do you mean by "not confuse an issue deliberately?"

XML-RPC and SOAP are both fairly technical standards for doing remote procedure calls over the internet.  Why should these two particular standards coopt the generic label "web services", while lots of other proprietary methods of doing the same thing need to be called something else? 

It seems to me that "web services" is a generic term that should apply to any method of doing remote procedure calls over the internet.  Now you might want to call non-XML-RPC and non-SOAP methods something like "proprietary web services" or "non-standard web services".  But it's pretty damn hard to say that they aren't web services at all.  They do the same thing as the standardized web services (XML-RPC and SOAP); they just aren't standardized.

Herbert Sitz
Monday, March 3, 2003


I agree that "web service" in general is a pretty generic term. Generically speaking there is also no reason to just limit it to explicit RPC type protocols. Amazon offering me to buy books via the browser could also be called a "web service". We could say that any company offering me a service by means of some webpages is providing me with a "web service” and that would be correct, in the generic sense of the word.
However, in the more restricted sense of differentiating between HTTP based RPC architectures, "web service" has been used to refer to a specific one based upon particular core technologies (SOAP, UDDI, WSDL). This more restricted sense has gained widespread acceptance. To then suddenly argue that we should now reapply it to a more generic meaning in this context seems not in the best interest of clarity.

Just me (Sir to you)
Monday, March 3, 2003

Sir -- Well, regarding the "services" part of things, it's easy enough to say that a "service" is something that provides a response to a remote procedure call.  It's a generic term, but also a technical one, so that a web page you bring up in a browser can't be called a "web service" (though it may make use of a web service behind the scenes).

But even accepting everything you say, what category name would you suggest using for proprietary remote procedure calls over the internet?  It seems to me the only difference from XML-RPC or SOAP is that these services have proprietary formats.  Otherwise they do the exact same thing. 

I would call these other remote procedure callls "proprietary web services", to show that they don't comply with any standard, but that they are still remote procedure calls over the web.  (I realize web may technically be limited to port 80, but humor me here, or just call them "proprietary internet services" when they don't use port 80 or http). 

If you invent a new category all it's own to apply to these proprietary services, you're going to be masking the fact that these proprietary services are identical in function to the standardized web services.  They are the same thing, they just look different behind the scenes.  One generic term should apply to all.  If you've got a better term than "web services", what is it?

Herbert Sitz
Monday, March 3, 2003

How about "HTTP based RPC", or even WebRPC? One thing is for sure. Whatever I say here will not make a difference, nor should it :-).

Just me (Sir to you)
Tuesday, March 4, 2003

There are those out there (Don Box, for one) who would argue that Web Services is all about XML documents, and has nothing to do with RPC.

Chris Tavares
Tuesday, March 4, 2003

Thanks a lot people. I have all the info I need.
This forum has one of the most helpfull group of people around.


Tuesday, March 4, 2003

*  Recent Topics

*  Fog Creek Home