Living in the Tech Avalanche Generation

In a time where mankind had come to think of itself as highly evolved, there was a technology princess known as JezebelScript. She was a Queen in waiting and in her latter years she strode throughout the land upon her faithful horse who went by the name High.

JezebelScript roamed upon High Horse, preaching her gospel to any and all that would listen; “free yourself from the hub of central control and lay seed at the root of communication” she cried. The arbiters of the peoples forums were locked in debate, a dark cloud of quandary hovered, alas so many prophets, so many gospels, even at the seat of power there seemed to be great confusion in how to best identify the “one true way”¹.

The Princesses message was simple, her key tenet was “freedom in Ubiquity” and as her powers grew as the message took root. The Oligarchs of the day were seduced by her call and they too began to preach her message, concordantly  it appeared to be reaching its crescendo, her followers gained strength in numbers, they began flexing muscles of vindication in the hallways of the propaganda machines. And then a metamorphosis took shape…something unexpected in this rich time of spiritual and intellectual evolution, the followers of JezebelScript came to outnumber those who followed the false prophets, an ugly mob mentality which had been festering, manifested itself in an un-mandated charge to suppress the new minority. The airwaves became filled with bile, hatred and self serving pronouncements of worship to JezebelScript, they shouted her name as though it laid claim to legitimacy. Finally it seemed the oppressed were now becoming the oppressor.

Her story is ongoing, her epitaph yet to be written and who knows she just may end up capturing the hearts and minds of those who have until now ignored her dance of seduction.

¹ Billy Hollis “Living in peaceful co-existence”

On the back of running his ADSD course in Sydney this year Udi Dahan will be also running a one day NServiceBus introductory course. The one day course is a highly condensed event so its sure to pack a wallop and if you are interested in taking NServiceBus for a spin and see what all the fuss is about then I suggest you quickly book yourself a place.

Mark and I will also be sharing our experiences of how NServiceBus has served us as an enabler in designing and delivering successful solutions for our clients as an ISV and as consultants.

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:

The Generic Host

The Profiles

Sample

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.