The Best/Simplest Way to Req/Reply completely async.

Replies to This Discussion

Permalink Reply by CM on October 30, 2009 at 2:48pm

Purely asynch with correlation in headers would be the most natural if you wanted one party to take action in its on receive that was a "response" to a message it had published earlier for something that went over days.

You could use the custom properties in the message header for the correlation values.

• ▶ Reply

Permalink Reply by Richard Lowe on November 4, 2009 at 8:35am

Ok, that's cool. Is this something you've seen before - any recommendations about the way to strucure the topics and parties in a situation like this... for example, let's say it's a simple CRUD type request for creating an account. Would you have a Topic/Subtopic hierarchy like so:

Accounts (Topic)
Accounts.Create.Request
Accounts.Create.Reply

Or would this be better split up in another way? I ask because I think you may have some reason why we would want to do it one way or another.

• ▶ Reply

Permalink Reply by CM on November 4, 2009 at 9:00am

I think that's fine.

I use subtopics a lot for segmenting operations or for Service Connectors that respond to a Client Connector On Ramp.

You can align your subtopics with either operations or with states and that should work out well.

When it comes to long running operations I'm a much bigger fan of completey asynchronous messaging with with either context based (headers) or content based correlation.

I bought into state based engines for a while until I saw what happens under load and trying to debug complex compensation scenarios.

There's also the whole loosley coupled aspect...There's really nothing loosely coupled about state based engines...They need to maintain control of all aspects of processing otherwise they can't guarentee dehydration and rehydration, transactions, etc...

On the other hand, shuttling things asynchronously and managing persistence with an independent data store that also holds state transition information that allows you to know the next or previous step in a process or even store a complete state transition history is very scalable and will allow you to add functionality quickly.

You won't drag and drop your way there with the design tools many state based engines provide but you'll be able to add functionality, custom reporting, or switch out the backing store database (or even use multiple databases) much easier than if you start with a state based tool.

• ▶ Reply