Hacking on the NServiceBus Generic Host with IronPython–TBC.
This (now series of) posts(s) will be something of a stream of consciousness, an exploration that has no single objective, rather a journey of discovery with no guarantee (sought nor otherwise) of any practical application. Something tells me that there is some niche lurking behind the premise however beyond my initial instinct I am prepared to let any hidden benefits (if there are any) reveal themselves to me along the way.
A while back I posted on how it was possible to self host an NServiceBus endpoint in a custom built IronPython / WPF REPL process. Since that time NServiceBus has experienced several feature enhancements and now supports a rich hosting model of its own, the Generic Host. I wont regurgitate what has already been written about the Generic Host as its been covered in several places and if you wont to know more about it I suggest you look at these links:
So Why an IronPython Host
In short, the ability to throw ad-hoc messages at your NServiceBus ecosystem and observe your systems behaviour (eye to eye) and some dynamic debugging! The typical debugging scenario has me sitting with four or more console windows open acting as either clients, servers and or publishers and some of those windows will be waiting for input (from me), the kind of input you typically see in a console application “Press y to send a message” (usually a fairly statically crafted and compiled one). When speaking about clients and subscribers sometimes (going into production) that just might be a windows desktop application.
In the world of dynamic languages developers have come to expect the ability to test / play with / mess with / debug their code in a Repeat Evaluate Print Loop which has some significant benefits.
Start-up
Using the NServiceBus Full Duplex sample I added a reference to my hacked version of the Generic Host and set the project to start-up the executable as per the usual approach (when you have chosen not to self host in your own executable).
After starting the Server project the console fires up as expected and is then followed by the IronPython console where the hosted Bus (instance) has been made available to the script scope context we have started in.
Next I proceed to hack out a message and send it on to the Bus. What isn’t clear below is that Message1 is actually an already dialled up instance of a RequestDataMessage as defined in the message project that is part of the Full Duplex sample that comes in the NServiceBus download.
Here is the Message Handler (in the Server project) for the RequestDataMessage (in the script above Message1 is an instance of this type.
Once the script above gets executed then the REPL reports back to us (I have hijacked the STD/IO and redirected it to the REPL’s TextWriter.
Ok, so it seems obvious enough that the Generic Host is now starting up in the context of our Python REPL and I can adhoc hand craft messages and observe the behaviour of the hosted endpoint, but there are some still some issues, one immediate and obvious one is that the REPL Host is doing two things or rather taking on two independent roles namely the Client and Server. If you run the Full Duplex sample you will note that there are two processes in the solution, a client configured AsA_Client and another configured AsA_Server; when I run the Server project using the Generic Host Shell I am freeing the console window and instead running the REPL window in its place. What this means quite literally is that in this instance, the REPL Host is allowing me to send messages to the Server Endpoint (which it too is hosting), without the Client endpoint running at all, thereby effectively spoofing some of the behaviour found in the Client process (project) without actually loading the client endpoint at all.
Alternatively I can run both projects (Client and Server) as I normally would, with the exception that they are both being hosted in the IronPython host. This (arguably) offers more fidelity with respect to the two services operating entirely within their own process which is in line with a production deployment.
What the image above demonstrates is that we now have two REPL Hosts running simultaneously, one endpoint configured AsA_Client and the other AsA_Server endpoint.
I am going to leave part 1 here for now and end with an idea that has come to mind: perhaps it would be useful to run a solution (furnished with hosted endpoints) and have all the REPL hosts start up within a container, perhaps an MDI host where all the REPL windows tile / cascade? It also occurs that perhaps such this REPL host would be useful for inspecting and returning source messages to their queues or performing functions like those found in the Grid UI or perhaps even something akin to an integrated shell where an Administrator might walk up to a machine hosting NServiceBus endpoints and issue those endpoints with administrative messages? Anyway I will meditate on it for a while and perhaps stay open for some outside input.
In the next post I will talk about some of the issues facing me currently and should be able to include a link to the working example by then. In the meantime you can find the old post here and download the REPL as it was back then.
Finally, the prototype IronPython console I built some time ago is really just that, a prototype and given that I plan to use it as a live runtime tool embedded in my commercial products (at some point in time) then its really time to take it from prototype to working draft and that means its time to get serious about styling the window beyond battleship grey.
