When ever you click on a hyper link like http://jonas.follesoe.no, mailto:me@email.com the Windows component "Url.dll" will do a look up in the register and execute the correct application. For links to regular web pages it will launch your default browser. For mailto links it'll launch your preferred e-mail client. You can use the link concept in a wide range of applications, ranging from linking inside web pages to adding links to e-mail messages, spread sheets, word documents, sidebar gadgets, IM chats and more. The way we can link information together is one of the core fundamentals of the web. Applications that handle a specific type of links is called a protocol handler. In this post I'll discuss how you can create your own protocol handler for a custom application and how this might be a powerful way to achieve light weight  and easy to implement integrations between your applications.

To illustrate the concept of protocol handlers I've created a simple Windows Forms Application called HelpDeskClient. The application can be looked at as your typical line of business application you want to "tap into" from other applications. The application contains code to write/delete the registry keys needed to register the protocol handler. To illustrate some simple "integration" the application hosts a HttpListener (a small web server) to display some simple HTML and RSS. The application is implemented as a single instance application, meaning that there will only be one instance of HelpDeskClient.exe running at any time.

To register a new protocol handler all you need to do is add a few lines to the registry:

[HKEY_CLASSES_ROOT]
  [helpdesk]
    (Default) = "URL:HelpDesk Protocol"
    URL Protocol = ""
    [DefaultIcon]
      (Default) = "HelpDeskClient.exe"
    [shell]
      [open]
        [command]
          (Default) = "c:\whatever\HelpDeskClient.exe "%1""

The most important part is the URL Protocol value under the "helpdeks" key. This will register the helpdesk:// protocol with "Url.dll". When ever Windows encounters a helpdesk:// link "Url.dll" will execute your HelpDeskClient.exe file passing the URL as a command argument. So when "Url.dll" executes a link to "helpdesk://open/?id=7" it'll execute "c:\whatever\HelpDeskClient.exe helpdesk://open/?id=7". In your main method you need to parse the arguments and take appropriate action. Fore another example on how to create a Visual Source Safe protocol handler check out this CodeProject article.

To make things easy the application can write/delete the registry keys needed to register the protocol handler. The code to do that looks as follow:

When you have your protocol handler registered you need to parse the command line arguments. In this example I've created a single instance application, meaning that any attempt to start "HelpDeskClient.exe" while the application is running will not create a new instance. Instead it'll show the all ready running application. Single instance applications are quite common, Outlook 2007 is one example of it. There are several ways to implement single instance applications. If the name of the executable is unique you can simply check the list of running processes. A better way is to use a mutex. If the mutex is used it means the application is all ready running. The easiest way however, if you're writing.NET 2.0 code, is to derive the WindowsFormsApplicationBase class which is part of the "special" VB.NET libraries. The VB guys has always had a few extra classes to help them out, like the "My.*" namespaces introduced in .NET 2.0. The cool thing about .NET is that you can take advantage of these classes your self. All you have to do is to add a reference to "Microsoft.VisualBasic.dll" in your C# application. I guess this will raise a few eyebrows in the C# camp, but trust me, it's safe! Below is my SingleInstanceApplication.cs and Program.cs class. If you want to learn more about how to create single instance applications check out this blog post.

As the title of this post suggests the idea of using protocol handlers is that they can be used as a ultra thin layer of integration between your applications. I'll try to elaborate more on this…. Most Windows applications supports some kind of hyper linking. You can type in a link in a mail message, a Word document, an Excel spread sheet and off course on any HTML page. This opens up for some simple "work flows" that just works. I can write an e-mail, paste a link and tell some one to check out this cool YouTube video… Or I can look up and address on Google Earth and copy the location as an hyper link and send it to some one on MSN Messenger. By registering your own protocol handler you can open up to this kind of "integration" your self. By creating some kind of URL scheme to navigate to important parts of your Windows application, open up customers or help desk requests (as in this example) you can open up for some really fluid and easy to implement workflows for your end users. For instance you could send an e-mail to your manager telling them to "help you out with this item", and hyper link directly into your ERP system. Or even more interesting you could start exposing feeds of important items that your users could integrate in any way they want. You could subscribe to "my work items" in any RSS application, and clicking the link would bring up the correct application, pre-loaded with that specific item. You could write a few neat Sidebar Gadgets providing glanceable data from your business applications  saving your users from having to click through several screens just to check if they have any urgent items to take action on.

To illustrate this (and provide some XML data for further examples) the HelpDeskClient application will start a HttpListener when it loads. You register the HttpListener on any url and port (under local host off course) and can start serving incoming HTTP requests. When a request is received you get access to the HttpRequest object you're used to from ASP.NET and can start creating the HttpResponse. In this example I serve two URLs: http://localhost:8080/taskhtml/ and http://localhost:8080/taskfeed/. The first one servers a simple HTML page with a list of open and closed items. Each item is a helpdesk://open/?id=xx link. When you click the link the HelpDeskClient application will execute and show the selected item. The feed page is a RSS 2.0 feed with all open help desk requests. This feed can be added to any RSS reader, or integrated into a Vista Sidebar Gadget or used where ever you want.

The code to create a HttpListener is shown below:

This post fits nicely together with yesterdays post on how gadgets can bring the service oriented architecture all the way to the desktop. By creating a protocol handler for your line of business application you provide a ultra thin layer of integration to hook into from "any" application. This simple concept could make your users more productive, save them lots of clicking, and open up to some nice workflow integrations. I hope you found the posting interesting, and as usual all comments are more than welcome! Before I wrap up, a few of disclaimers. The application has to run as administrator under Vista (because of registry settings and HttpListeners).Using protocol handlers like this isn't expressed best practices from Microsoft and can only be considered an idea I'm throwing out in the open. I haven't implemented it in any real world applications my self yet.