Which brings me back to Steve’s basic argument. The essence of your service design must be:
what is the functionality that needs to be exposed?
what messages must be exchanged in order to achieve that functionality?
After you have designed the fundamental requirements of the service, then you can expose that functionality using as many middleware technologies as you need in order to support your customers’ requirements. As long as you maintain clean separation of interface from implementation, you can do that.
Coming from Anne, this surprises me. I agree that there are many issues related to SOA that are independent from any technology choice — organizational issues, roles, cultural changes, business case, relationships to external partners, coupling of internal business units, to name a few — but on a technical level, the whole service design and the messages exchanged in SOAP/WS-* based and a REST-based scenario are clearly different.
I’ll say it again: Whether you build a service-oriented or resource-based system is not an implementation detail.