Remote desktop to another OS and back again

As you surely know, XP is a single-user OS which means that there can be only a single user logged-in at one time. If the administrator logs in from a remote machine using the remote desktop tool, the current user is logged off and a message shows up saying "this machine is currently in use [...]"

If you have a spare 3 minutes, try to reproduce following steps:

1. Log into a non-virtual Windows XP
2. Use Virtual PC to boot a virtual Windows XP and log into it
3. Use remote desktop in the virtual Windows XP to log back to the non-virtual Windows XP (which hosts the virtual one)

What happens to your non-virtual Windows session after you log into it from the virtual machine? Will the "this machine is currently in use" message show up?

Well, if you do it using two XPs, the host screen goes black and the machine stops responding. The non-virtual XP is controlled "from the inside".

What's great is that the non-virtual machine still runs - you can access all it's services, the application server, the database server and others run perfectly. You just cannot control the machine anymore using the keyboard.

I belive that there are few other interesting options to continue this experiment.

For example, can you regain the control of the OS by accessing it with the remote desktop from yet another machine? What happens when the Windows Server 2003 is used instead Windows XP?

Lightweight Service Bus frameworks

The application environment I work on needs an architectural fundament capable of a loose-coupled integration. There's a reference handbook on integration patterns, the "Enterprise Integration Patterns" by Hohpe/Woolf (also take a look at the "Integration Patterns" book from Microsoft Patterns & Practices group).

 

Anyway, there are four major integration patterns:

• File Sharing - where application share data by exchaning files
• Shared Database - where applications are build around a single database
• Remote Procedure Calls - where applications expose their data through remote interfaces
• Messaging - where applications exchange messages with the help of a centralized component (called a "Service Broker" when the messages are processed synchronously or the "Enterprise Service Bus" when a messaging component is used to store and handle messages) which acts as a backbone of the application environment

[http://msdn.microsoft.com/en-us/library/aa475433.aspx]

One of the most interesting aspects of an ESB implementation is handling various MEPs (Message Exchange Patterns: synchronous, asynchronous, send-and-forget, publish-subscribe). The latter, publish/subscribe seems the most attractive option to integrate an environment consisting of different components.

There are plenty of fully fledged ESB implementations but the core of a service bus can be built using much a simple environment based solely on a messaging component like MSMQ or IBM Webshpere MQ. And since the "low level" integration with a messaging component could be painful, we need lightweight service bus frameworks just to wrap unnecessary calls into friendly APIs.

After some research, I've found three such lightweight service bus frameworks for the .NET platform:

• nServiceBus - uses MSMQ as messaging component and Spring.NET as the IoC container. Supports so called "sagas" which are just long-running workflows as well as the scalability over a large enterprise system.
• Simple Service Bus - built on top of the nServiceBus. At first look seems like the porting of few nServiceBus features is not completed at the moment. Uses the Castle.Microkernel as the IoC container.
• MassTransit  - seems to take a more universal approach, supports MSMQ / ActiveMQ as messaging components and  different IoC containers. There's not much to evaluate since the useful versions cannot be downloaded at the moment.

I hope to write more on the topic soon since this is not only the top-priority task I work on at the moment but also, in the same time, it's just just quite fun to play with.