In answer to Contract-first: do you believe? here's my two cents. 


One of the reasons we're tolerating all this change in the tools and methodologies is to improve developer productivity.  Another, of course, is to enable interop.  But if you don't need interop (and most applications do not, or only need a small amount of it which can be easily isolated), then use the simplest technology you can to get the job done, and when the need for interop arises (which it will if you're successful), then you can design, build, and expose just the functionality you need for the interop you need to do.


In most of the systems I've worked on, I've had a common assembly that's contained the classes that are shared between the various components that make up the system, and the classes in that assembly are freely used (and passed between) components in the system.  Those classes are definitive - everyone shares them, and if I change one of them, everyone gets the change in the next compile. 


This is how is built, and I'm very happy with the result.  It's easy to work on, and has a web services interface, but the clients of the service are also applications that I've built, and share the same objects that the server side is using.  It's possible to come up with scenarios that could cause me to regret these choices, but those scenarios are unlikely and in the meantime, I've saved myself a lot of coding time doing it this way.


This is heresy according to some architects, but the point I'm making is that unless you're designing something expansive (and most of the stuff we work on isn't), recommended best practices will have you spending a lot of time working on stuff that isn't core to what your application is trying to do.   There are situations where WS-* is appropriate, and there are situations where it isn't.