The definition of a web service is a service that uses WSDL as a description language and SOAP as message format. The term 'web' suggests that it is a service using web-technology, but REST services aren't typically described as web services. The term it selves suggests a protocol, but this isn't necessary for a specific implementation. Sometimes the combination of web services over MQ is used. My point is this: the term web service is ambiguous.

A service is a way of two computers/information-systems interaction with each other. This requires some input and often some output. A service consists of three components: the service description, the message format and the transport protocol.

The service description or contract can be (among others) a WSDL, a XML template or a document. This will describe the input and output of the service. A combination of these can be used for a service. For example a WSDL can be used among a document describing the behavior of the service.

The message format can be (among others) SOAP, XML, CSV, JSON or fixed length format. This will be the way the input and output is described while interacting with the service. Of course it is possible to use more than one message format for a service. Remember: if you use more than one format, maintaining the service gets more complicated. The message format can also be used to create multiple versions of the service.

The transport protocol can be (among others) Http, MQ, the file system or FTP. In this case it is possible to disclose the service over more than one protocol. If you do this, it will also complicate the maintenance of the service.

Of course it is possible to create a matrix for the service. To use more than one message format over more than one protocol. This will be really complex and probably not really used by other systems. But if you have to integrate with different types of systems, disclosing the service using more than one combinations of message formats and protocols is useful. For example disclosing the service with SOAP over Http and MQ can be handy for different types of systems. Or disclosing with SOAP over Http and CSV over the file system can be useful to integrate with a mainframe and Windows applications.

When discussing services I like to use all three components. This way everyone knows what we are talking about. In my opinion it is much better to talk about a service using WSDL that is disclosed with SOAP and Http than it is to be talking about a web service. The latter will make discussing much harder if your definition isn't clear to everyone and everyone uses the same definition.