NServiceBus, NHibernate, and GuidComb()

Question

Disclaimer: This is a follow-on question from my other question about NServiceBus which was answered very thoroughly.

My current question is this: If a website is built to be 'dumb' like the article referred to, above, suggests then how does the following scenario work?

A user registers on a website by filling out a form with relevant details. When the user clicks the 'submit' button on the form the web application takes the form data and creates a message which it sends to the application tier using NServiceBus and Bus.Send(). The application tier goes about the business of creating the new user and publishing the event that the user has been created (Bus.Publish()) so that other processes can do their thing (email the new user, add the user to a search index, etc, etc).

Now, since the web application in this scenario relies entirely on the application tier for the creation of the new user instance, how does it get to know about the user's id? If I didn't use NServiceBus in this scenario but, rather, let the website issue an in-process call to a DAL I'd use NHibernate's GuidComb() strategy to create the identifier for the new user before persisting the new row in the database. If the message handler application which receives the command to create a new user (in the current scenario) uses the same strategy, how is the userId communicated back to the web application?

Do I have to apply a different strategy for managing identifiers in a scenario such as this?

Newsman

Answer 1

You're free to come up with an ID to use as a correlation identifier by putting it in your message in the web application, allowing it to be carried around whatevery processes are initiated by the message.

That way, you can correlate the request with other events around your system, if only they remember to supply the correlation ID.

But it sounds like you want your user ID to be fed back to you in the same web request - that cannot easily be done with an asynchronous backend, which is what messaging gives you.

Wouldn't it be acceptable to send an email to the user when the user has been created, containing a (secret) link to some kind of gateway, that resumes the user's session?

Eklund

Hello. That's a good idea, and I've used something similar with exception shielding where an error is communicated between two systems and persisted with different identifiers in each system. However, in this scenario - what would the longevity of the correlation identifier be? I wouldn't necessarily need the user Id to be fed back to me in the same web request - but I'd like to be able to use the actual userId as much as possible in the system rather than use it and the correlation id in combination. Otherwise I will have to index on two ids... Hmmm! Food for thought. Good suggestion. Thanks! – Mallen

You should use the correlation ID only to correlate between messages/events that relate to the process of creating the user. – Eklund

As soon as the user has been created, and the user ID is known, I'd say the correlation ID should be discarded, as it is "local" to the process of creating the user. – Eklund

Try and design your commands so that they don't have a good reason to fail. Ie let your website validate that the username that the user selected is valid and available. Then use that username for correlation. Does that make sense? – Medina

Thanks for all the extra comments. I've been looking at this on and off all day and I think this could work. The user has virtually no rights until she's confirmed her email address, anyway, so she wouldn't be creating or changing any data at all until that point. So I could swap out the correlation id at that point. Nice! – Mallen

Answer 2

Wouldn't the UI be able to listen to the bus for the "user created" event? And then you could correlate either by having the event include some kind of event ID linking back to the "user creation requested" event or against some other well known data in the event (like the user name). Though you probably also have to listen to multiple events, such as "user creation failure" event.

This is not unlike normal AJAX processing in a web browser. Technically, you don't block on the out of band call back to the web server. You invoke the call and you asynchronously wait for a callback.

Svensen

In order for that to work, though, the thread would have to be kept alive, no? I think it's a no-go, but I'm happy to stand corrected. – Mallen

OK, let's assume this is an ASP.NET WebForms page. The concept already exists for async processing within a page. For example, the idea that you might initiate 3 SQL commands and wait async for them all to complete (the idea being to execute them concurrently vs consecutively. Usually, there would be some kind of timeout waiting for the async response. If the timeout is exceeced, you could still have some kind of refresh option which just re-subscribes and wait for the response message again. – Svensen