If you have not seen this yet, there is a good recent read from Michael Nygard (of "Release It!" fame), on pattern languages in general and context / relationship between patterns: part 1 and part 2.

I don't mean this as a commentary on your patterns (have not had a chance to read what's available yet), just thought you might be interested since this is about the general approach of thinking in patterns ...

Looks like a good list of patterns, will any of these patterns cover issues with the "Entity Services" approach (even just the tradeoffs).

Another question about the book, I'm loving the content/format but I'm wondering if you are going to have a chapter with an example of a best-practice service.

For example I'm sold on the large scale business services encapsulating domain models, exposing resources and communicating with each other through messages (inversion of communication). Anyway I realize this is just one approach and there are lots of tradeoffs involved so an example/case study explaining a few approaches could be quite useful.

@Colin
On entity Services I'll see - I am not sure I can explain that clearly enough
On "best practices" - well, I don't like the term best practices, since different things are best in different contexts. There's a "putting it all together" appendix planned (Udi once said he'd be willing to do it - I need to see if he is still up for that) where the idea is to present a few patterns working in a larger context

Arnon

You are probably right on "best practices", it sounds like the "putting it all together" chapter will do the job.

Here's another question.

Just to put more detail than above, our plan is to have big autonomous business focussed services (CRM/Finance/Delivery). These wouldn't be specific web services, they're more along the lines of business services that Steve Jones/Udi and others discuss. Anyhow each will jealously control one or more databases and domain models, all good. However the plan is to expose (REST) resources from each of these services for clients to use but use normal messaging (NServiceBus/Mass Transit) between them (though Atom feeds would be an option).

Long winded explanation but I've used many of these technologies/approaches before other than REST and I wondered whether what I'm suggesting sound to you like I'm thinking in RESToid terms? Would you instead recommend using REST for read-only (caching as much as possible) but using a messaging metaphor for everything else? How about going the whole hog and using REST for all communication with and between services (so no messages but Atom feeds for communication between services)?

I'm especially interested in your view as not enough people who really understand REST and SOA seem to be discussing the trade offs you get when combining them. Oh and feel free to say "overly long question, wait for the chapter to appear" because it is too long and I really should just wait :)