Web services build upon HTTP, but they don't build upon the Web. The Web uses HTTP as an application contract which enables the loosely coupled exchange of documents between applications, while Web services uses HTTP as a bit pipe - as a transport protocol. Doing the latter instead of former means that you're starting from scratch, and not taking advantage of the existing network effects in the Web.
This is new for me about the difference between the web and another "web" in web services. I consider the web to be a space of information, and the end applications of web so far are agents(web browsers) with humans behind them. So how about the space of services? I imagine most agents(services) in that space are autonomous, and they are not directly controlled by the human users. In the case that most current services, e.g. google.com, amazon.com, are targeting human customers, there is no big difference between the space of information and the space of services. However, I suspect that there will be in the future.
I agree with his point that SOAP is essentially a generic XML envelope. However, I cannot see what to replace the roles of WSDL and UDDI for service description and discovery. My opinions have a root in the study of agent-based software systems.
His suggestion about starting REST is
It's technically possible, but from what I've seen of Web services toolkits (even those that claim to "support REST"), there's a very good chance that it'll be more trouble than it's worth. My advice would be to start with mature client and server Web frameworks in your language of choice, and to read up on what others are doing with REST/POX/XML-HTTP style services as replacements for traditional "Web services". Then apply that to the simplest possible problem you have, and once you've conquered that, move on to more complex problems.
Again, the assumption of this method is that services are just part of the web.