In response my posting on proposals to take the "Web" out of Web services, Loek Bakker [formerly with Capgemini] alerted me to a similar posting in which he took up the "Web" question. (Do great minds run in the same rut, or what?)
Bakker debates whether to call it Web services, XML services or just plain services:
First of all, "Web services" doesn't exactly fit what we're doing anymore, he writes. The "Web" in Web services implies HTTP and REST. It also implies RPC (remote procedure calls), Bakker adds, "a bad thing, I think, in general for scalable services."
"XML services" may fit, as SOAP does not need the Web. However, XML services do not require SOAP -- both RSS and REST are SOAP-less protocols.
Just plain "services" creates a hairball. Likewise, just plain "services" creates confusion with the stuff vendors are supposed to do for you. Complicating matters further, Bakker also notes that "services do not require XML" either.
Bakker's bottom line: Use any and all of the terms, as the situation fits. "We should use the terms wisely and appropriately, and using the terms should be aimed at providing maximum clarity on what kind of services we are talking about. A lot of the naming issue depends on the abstraction level at which you look at your architecture. On a conceptual level, you get away with calling it just 'service,' but especially when talking about the physical architecture (the implementation), it might help to precisely brand the service 'XML Service,' 'SOAP Service' or even 'CORBA Service.'"