I have been investigating use of Rhino ESB for use with an existing application, which consists of a UI client (WinForms) and a server application running as a Windows service. I'm looking to change the way the WinForms client interacts with the server application, and I like the disconnected approach in Ayende's excellent MSDN articles on Alexandria.
I investigated using NServiceBus, Mass Transit and Rhino ESB, and I am currently leaning towards ESB, as it seems to suit ISV applications a little better than the other two. I have spent plenty of time single- stepping through the code and trying to understand how it all works, but there are a few issues I am still struggling with a bit. I am wondering if maybe, after all, I am trying to use this tool for the wrong job. Things that I really like about this approach are: 1. The code in my presenters seems much cleaner than before (no more BackgroundWorkers or IAsyncResults). The presenters just package up a message, send it to the bus, and when the response is ready the correct Consume method is called. 2. All my business logic code on the server tends to fall into the same sort of pattern, and it is considerably easier to test. 3. My service process can shutdown and restart (which it does very occasionally -- long story), and the clients might notice a slight delay, but everything still works uninterrupted. It would even be possible to upgrade the server while the system is being used, in a pinch. 4. Server can publish events that are reliably received by all interested clients, which helps keep the information displayed on each client application up-to-date without having to refresh periodically. Areas I am struggling with are: 1. When my client application starts up, I do not want to process any messages on the input queue. (Another hint that maybe I am trying to use the wrong tool?). In NServiceBus there is a simple way to configure a client to purge its input queue on startup, but I can't find a straightforward way to do this in ESB. 2. Is there a way to easily unsubscribe everything? If somebody shuts down their desktop application and does not start it for a few weeks, I do not want to have to deal with potentially thousands of messages that might be waiting to be processed because there does not seem to be a way to opt out of all subscriptions. I know this is a feature of ESB, but for desktop applications, I do not want it (there's the feeling that I am trying to use ESB for the wrong reasons, again). 3. In almost all of the cases where my code handles a response or an event from the server, the main work is to update the UI, which must be performed on the main thread. I know that I can write a consumer that will raise an event with an event aggregator, but for most cases that is additional code that does not buy me much. I would like to be able to force individual consumers to be marshalled on the UI thread, but as far as I can see that means implementing my own IReflection interface, and that interface does *way* more than invoke the Consume method, and it is not all that pluggable. I am guessing that if something like this is not all that easy yet, perhaps I am trying to do something that nobody else wants to do? I'd really appreciate some pointers from people who have tried this sort of thing in production environments. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
