Andrew, I think you are overloading _SOAP_ web services a bit too much. At their simplest, _SOAP_ web services are a message-passing technology. I pass you a request message, you pass me a response message. Our message exchange pairs might be used as the basis for an RPC system, they might not (and work best when they aren't, as distributed objects don't scale.) To implement _web services_ (be sure to note the difference between web services and SOAP web services, as all of these protocols we're rambling about are used to expose web services), you could use functional programming, object-oriented programming, or even simple bare procedural programming. All of these can result in "web services" regardless of message passing vs. RPC style, their technology ala SOAP vs. XML-RPC (though doing a message-passing style in XML-RPC would probably be a bit silly) vs. XML-over-HTTP, and/or their "RESTfulness". With few exceptions, these implementation technologies, service styles, protocols, and RESTfulness can be mixed and matched arbitrarily in order to best utilize your implementation skills, meet your requirements in terms of client integration technology, etc.

Object-oriented programming isn't "all about nouns". Object-oriented programming is about co-locating information and the functions that operate on that information, placing only a slight emphasis on the noun, as you put it, so as to enable said co-location. Functional programming is not "all about verbs". Functional programming is about idempotent operations and specification as code, and makes use of things like immutability and matching to help achieve those goals. These _result_ in the functional style.

I think you need to take a step back away from the details for a bit, and think more in the general. Seeing the forest instead of just the trees, and all that. ;)

Yeah, I think you are right Jeremy. I didn't mean to over simplify things that much.