There is a difference between CQS (recently renamed to CQRS – see here for more info: http://www.udidahan.com/2009/12/09/clarified-cqrs/ ) and what’s known as Event Sourcing. CQRS doesn’t make any statement about how data in the storage serving commands is structured – it could be relational, hierarchical, object-oriented, or anything else.

I think the best place to ask these questions on the comment thread going on here:

http://blog.fohjin.com/blog/2009/11/12/CQRS_a_la_Greg_Young

Re: How scalable would this be if large numbers of clients were requesting data in this way especially over slow connnections?

This is the way clients that don’t use pub/sub do things anyway

The answer to the rest of your question deserves a full blog post of its own, if not more than one

The client could save the information to disk, however they may also be disconnected or off for long periods of time. You mentioned in your recent article ‘Lost Notifications? No Problem.’ that ['Publishers have no choice but to throw away messages after a certain period of time.'] What would you suggest in this situation (a differential query, P2P) or force the server to maintain the messages indefinitely (eg Outlook and Exchange)?

That’s correct.

> Why don’t you use async messages for any potentially remote communication?

When the architecture itself is synchronous, introducing one-way messaging brings quite a lot of complexity. Also, the robustness and scalability benefits are thwarted by the synchronous architecture.

You can’t be going both left and right at the same time.

> Why at all do you encourage people to use RPC?

I’m trying to encourage people to understand the tradeoffs between the various choices – one way/pub sub/rpc. What makes sense where, and why.

> Is your position more like “RPC is OK for in-service remote communication” or more like “Avoid using Messages for in-service communication”?

My position is that, if there’s any place where RPC will cause the minimal amount of damage, it’s within service bounaries.

I would definitely NOT suggest the latter. Messaging is such a strong paradigm that it requires the overall architecture to be aligned with it. When that occurs, you get tremendous benefits from using messaging within service boundaries as well.

Finally, the main point is to understand the different contexts for making decisions. Between services, under no circumstances should RPC be used – unless its an insignificant implementation detail in supporting a higher level messaging infrastructure (MSMQ makes use of RPC under the covers).

Hope that clears it up.

I’ll check on the comment feed, thanks.

Thank you very much, indeed.

I’m not quite sure I understand your question, but does the REST style solution I described in previous post correlate to the way your thinking about using GUIDs?

If so, then I’d use a long-running process like nServiceBus’ sagas to manage the allocation and cleanup of those GUIDs. You’d probably want to experiment with various cleanup times until you settle on a cleanup policy that works for you.

Hope that helps.

Alex, we’re toying with the idea of using an ID broker service for things that we can’t have GUIDs for. This way a client can send a RequestNextId message, the server generates the next id (and reserves it so no future entities can use it), and then sends back a message to the original sender. The correlation is done automatically for you in nServiceBus (via the IdForCorrelation property of the TransportMessage class if you’re using the MSMQTransport). The client receives the message and knows which RequestNextId message it correlates to.

However, in this case, a new question arises: how long should service keep correlation value?

Wikipedia is the outer join of the wisdom of crowds and the ignorance of herds, or so someone once told me

Actually, the SQL insert command doesn’t return the value of an identity column – you specifically have to query for it. That being said, all SQL statement do return the number of rows affected, an apparent violation of CQS.

Personally, I liked GUIDs for IDs.

So, to my understanding, CQS is really ‘only change state in methods with returntype == void’.

“Usual” return value of the CREATE command is a surrogate key of the inserted (or sometimes upserted) entity. Even if natural key exists, it may be to clumsy to use. How this (getting identity of the created entity) should be handled in CQS.

I have ment upsert to underline that it’s not always possible to generate identity on the client side.