Comments on: Advanced Messaging with a dash of DDD

By: Colin Jack

Colin Jack — Wed, 03 Sep 2008 19:54:11 +0000

@Udi
I’d also be interested in reading more about the way you use these “extra” style properties for versioning. I get the idea but I’m torn between that approach and the approach where you would just create a new type of message.

By: shawn

shawn — Sun, 06 Jul 2008 21:23:09 +0000

udi,

could you provide a pointer to your follow up article about using the “extra” field for versioning? (hopefully you’ve gotten to write it)

thanks!

By: thesoftwaresimplist

thesoftwaresimplist — Sun, 24 Feb 2008 09:58:57 +0000

Ollie,

The thing about TimeToBeReceived is that clients need to know about this as well, although the receiving process can’t count on them to do that correctly.

So, one thing that’s needed is a “reaper” process which checks to queue every once in a while for messages that should be thrown away.

I’ve been thinking about ways to communicate this information as a part of the contract, as well as configure it locally, but haven’t found anything that’s significantly better. The thing is that application code should not be passing this information as a parameter to send/publish/reply methods.

Thus, when this information changes, doing a recompile of just that project isn’t a big deal. We’ve set it up to be done automatically – the admin uses a simple UI to configure the data, and we change the information in the attribute and recompile, and then the admin deploys it.

Does that make sense?

By: Ollie Riches

Ollie Riches — Mon, 18 Feb 2008 18:12:42 +0000

Also Udi you define a field in the message ‘extra’ as state this will be used for versioning – ‘As we version our system and schema, we’ll be adding fields to the message.’

Does this mean in future versions it will serialise all new properties\fields via the ‘extra’ field? If so isn’t this kind of mixing the message structure so that there are both strongly typed properties\fields and weakly typed collection of new properties\fields in the primary message class? – if that makes sense…

eg. How would I add properties like ‘BuildingId’ and ‘RoomId’?

From my past experience versioning of message always gets complicated I’m coming round to the idea of making a clean break when new versions of messages are required and just great a new assembly or extend the current assembly with a new class representing the new message – obviously this could be an issue if message versions change frequently…

Ollie

By: Ollie Riches

Ollie Riches — Mon, 18 Feb 2008 17:54:40 +0000

Udi,

You stated:

‘The way to figure out how long to set is by looking at the smallest amount of durable storage you have available at your nodes, divide that by the size of the average message, and then again by the rate you need to process messages – and leave yourself at least 100% spare.’

Correct me if I’m wrong but doesn’t this subtly suggesting hard-coding hardware performance characteristic into the messages via the TimeToBeReceived attribute?

If this is true then logically this could be abstracted away with a config file or service locator but that would require references to other assemblies in the message assembly which wouldn’t be ideal.

I would have thought it would be better to define the timeout as a business SLA value which is independent of hardware configuration.

Ollie