David Kline : Windows Communication Foundation

The Journey of the Lunch Launcher: Part 6 - Processing messages

DavidKlineMS — Wed, 17 Oct 2007 23:07:41 GMT

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007
Part 3 - Managing the Transport
Part 4 - Sending messages
Part 4b - The output channel
Part 5 - Receiving messages

Last time, I talked about how the Lunch Launcher receives messages. Today's topic is now the messages are processed.

As with all entries in this series, please note that the following disclaimer covers all examples contained herein.
//----------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //-----------------------------------------------------------------------
MEDC 2007
Just like the listeners, the MEDC 2007 version of the Lunch Launcher demo contained three nearly identical processing methods.
/// <summary> /// Processes a received lunch invitation /// </summary> /// <param name="msg"> /// The lunch invitation message /// </param> /// <param name="from"> /// The email address of the sender /// </param> private void ProcessInvitation(Message msg, String from) { LunchObjectSerializer serializer = new LunchObjectSerializer(typeof(LunchInvitation));

// get the buddy who sent the invitation Buddy buddy = LookupBuddy(from); // ignore invitations from those who // are not in the buddy list if(null != buddy) { // get the invitation LunchInvitation invitation = msg.GetBody<LunchInvitation>(serializer); // notified registered event handlers SendInvitationReceived( new InvitationReceivedEventArgs(buddy, invitation)); } }
When a message is processed, the method creates a serializer for the LunchInvitation object to be used when the message body is extracted.

Next, the sender of the invitation is compared with the user's buddy list. This is done to avoid unsolicited invitations from people with whom the user would rather not have lunch.

If the sender is found in the buddy list, the message body is retrieved and the user interface is notified. When the user interface handles the event, it presents the user with a 'you have been invited' form.

Current version
In the current version (October 2007), the processing methods have been consolidated into a single generic method.
/// <summary> /// Process a received message /// </summary> /// <typeparam name="T"> /// The type of object contained within the message /// </typeparam> /// <param name="msg"> /// The lunch invitation message /// </param> /// <param name="from"> /// The email address of the sender /// </param> private void ProcessMessage<T>(Message msg, String from) { // get the buddy who sent the message Buddy buddy = LookupBuddy(from); // ignore invitations from those who // are not in the buddy list if(null != buddy) { // get the serializer LunchObjectSerializer serializer = GetSerializer<T>();

// get the invitation T payload = msg.GetBody<T>(serializer); // notified registered event handlers SendMessageReceived( new LunchLauncherMessageReceivedEventArgs<T>(buddy, payload)); } }
There are a few changes to this version. First, like last time's example, the serializer is retrieved from a class-global collection. This saves on reflection costs and reduces the amount garbage generated as the application receives messages.

The second change is the consolidation of the event handlers into a generic method. As I was reviewing the code right after my session, I took notes on the areas where code was highly similar. Wherever possible, I merged the methods into generic versions. This has resulted in much less code to review :) and fewer issues to investigate. Fixing once is much better than fixing multiple times, or worse yet, forgetting to apply the fix to one of the duplicates.

Lastly, I moved the serializer retrieval into the conditional block. There is no need to fetch it unless we recognize the sender of the message -- a very small performance increase.

In closing
We are getting towards the end of this series -- there are only a couple more topics that I would like to cover. I hope you are enjoying reading about my experiences writing the Lunch Launcher demo. As I mentioned last time, as I continue to work on the demo, I plan on keeping the examples in this series fresh. This will likely result in edits (read: extensions) to the posts in this series. As I make changes, I will post a topic pointing them out.

Next up, a look at the 'lunch manager'.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher - Part 5: Receiving messages

DavidKlineMS — Fri, 12 Oct 2007 22:21:00 GMT

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007
Part 3 - Managing the Transport
Part 4 - Sending messages
Part 4b - The output channel

In the series so far, we have seen how the Lunch Launcher manages the Store and Forward Messaging transport objects and how it sends messages (invitations, replies) to buddies. Now, it's time to see how the messages are received.

As with all entries in this series, please note that the following disclaimer covers all examples contained herein.
//----------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //-----------------------------------------------------------------------
When the Lunch Launcher starts, it creates three child threads to listen for incoming messages. The details of how these listeners are managed will be discussed in a future post.

As mentioned previously, when I was first writing the Lunch Launcher to show at MEDC 2007, code optimizations were not my primary concern. The code had been written so that it was easy to describe in a big room (~400 people) during an introductory (200 level) session. As such, there was a significant amount of near-exact duplication.

MEDC 2007
Let's start by taking a look at the original demo code (circa May 2007). Given the level of similarity between each of the listeners, we will look only at how lunch invitations are received.
/// <summary> /// Receive lunch invitation messages /// </summary> private void InvitationListener(Object state) {     Thread.CurrentThread.Name = "LunchManager - Invitation Listener";     TimeSpan timeout = new TimeSpan(0, 0, 0, 0, this.m_ReceiveTimeout);                 this.m_InvitationTransportObjects = new TransportObjects(InviteChannelName);     try     {         // initialize the transport objects         this.m_InvitationTransportObjects.Initialize();                         Boolean keepRunning = true;                         while(keepRunning)         {             IInputChannel channel =                 this.m_InvitationTransportObjects.InputChannel;                                     try             {                 // wait for an invitation                 Message msg = channel.Receive(timeout);                                         if(null != msg)                 {                     // there is a message to process                                                 // get the sender's email address                     String from = (String)msg.Properties["FromEmailAddress"];                                                 // process the message                     ProcessInvitation(msg, from);                 }                 else                 {                     // there is no message to process                                                 // determine why we did not receive a message                     switch(channel.State)                     {                         // transport faulted                         case CommunicationState.Faulted:                             // attempt to recover from the fault                             keepRunning = this.m_InvitationTransportObjects.Recover();                             break;                                                             // channel is closing/closed                         case CommunicationState.Closing:                         case CommunicationState.Closed:                             break;                                                             // unexpected state                         default:                             break;                     }                 }             }             catch(TimeoutException)             { /* there was nothing to receive */ }             catch(CommunicationException)             {                 // failure communicating with the service                 // sleep for awhile to allow it to recover                 Thread.Sleep(timeout.Milliseconds);             }             catch             {                 // fatal error                 keepRunning = false;             }         }     }     catch     { /* fatal error */ }     finally     {         // uninitialize the transport objects         this.m_InvitationTransportObjects.Uninitialize();     } }
Here we have a pretty straight forward listener thread delegate. Each loop iteration, it checks to see if it should stop and if not, try to receive a message. Once received (msg != null), the message is passed to a processing method (to be talked about next time). If the transport faults (CommunicationState.Faulted), we attempt a recovery.   On a CommunicationException, we pause for a few seconds and resume receiving.

Did you see the problem when the channel is closed? On CommunicationState.Closing and CommunicationState.Closed, the loop retries and falls into the same path. The reason this originally went unnoticed is that the InvitationListener is a background thread (started via ThreadPool.QueueUserWorkitem). Background threads are terminated when the main thread exits, so I missed the bug.

Current version
Since returning from MEDC, I have made some significant changes to the listeners. Most importantly, I have consolidated the code so that there is little, if any direct duplication. This reduction in duplicate code allows bugs found in one listener to be fixed in the other two automatically, as evidenced by the example above.

Let's take a look at the current (October 2007) version. I'll start by showing all of the thread delegates.
/// <summary> /// Receive lunch invitation messages /// </summary> private void InvitationListener(Object state) {     Thread.CurrentThread.Name = "LunchManager - Invitation Listener";     Listen<LunchInvitation>(this.WaitMilliseconds); } /// <summary> /// Receive lunch invitation reply messages /// </summary> private void ReplyListener(Object state) {     Thread.CurrentThread.Name = "LunchManager - Reply Listener";     Listen<LunchInvitationReply>(this.WaitMilliseconds); }

/// <summary> /// Receive lunch details messages /// </summary> private void LunchDetailsListener(Object state) { Thread.CurrentThread.Name = "LunchManager - Lunch Details Listener"; Listen<LunchDetails>(this.WaitMilliseconds); }
Quite a bit smaller and very similar, aren't they? All of the common listening code, that had been triplicated, has been factored into a generic method called Listen<T>. Let's look at that next.
/// <summary> /// Receive incoming messages /// </summary> /// <typeparam name="T"> /// The type of messages that will be received /// </typeparam> /// <param name="waitMilliseconds"> /// The length of time, in milliseconds, to wait before restarting after a communications failure /// </param> private void Listen<T>(Int32 waitMilliseconds) { TransportObjects transport = null; try { Type objType = typeof(T);

// get the transport transport = GetTransport<T>(); transport.Initialize(); // get the serializer LunchObjectSerializer serializer = GetSerializer<T>(); Boolean keepRunning = true; while(keepRunning) { IInputChannel channel = transport.InputChannel; try { // wait for a message // // note: there is no need for a timeout when calling Receive() // when the channel is closed, Receive() will return Message msg = channel.Receive(); if(null != msg) { // there is a message to process // get the sender's email address String from = (String)msg.Properties["FromEmailAddress"]; // process the message ProcessMessage<T>(msg, from); } else { // there is no message to process // determine why we did not receive a message switch(channel.State) { // transport faulted case CommunicationState.Faulted: // attempt to recover from the fault keepRunning = transport.Recover(); break; // channel is closing/closed case CommunicationState.Closing: case CommunicationState.Closed: keepRunning = false; break; // unexpected state default: break; } } } catch(CommunicationException) { // failure communicating with the service // sleep for a short time to allow it to recover Thread.Sleep(waitMilliseconds); } catch { // fatal error keepRunning = false; } } } catch(Exception e) { // fatal error // TODO: log failure } finally { transport.Uninitialize(); } }
The Listen<T> method looks pretty similar to the InvitationListener from the MEDC version. The changes were mostly to make the code reusable, yet still type safe by turning it into a generic method.

The key change here is to retrieve the appropriate TransportObjects and LunchObjectSerializer from collections managed by the lunch manager (to be talked about in a future post). The rest is mostly just fit-and-finish and "tidying up" (ex: eliminate the TimeoutException that occurred whenever there was no message to receive).

Since this is an in-progress journey (as noted by the presence of 'TODO' in the snippet), there is still some testing and fine tuning to be done within the Lunch Launcher. As changes are made, I plan on updating this and other posts in the series.

Upon reflection -- not the .NET type of reflection :) -- I realize that code clarity is not that much different between the MEDC to Oct 2007 versions of the listener. In fact, the Oct 2007 version showcases just how similar the listeners are and might, in fact, be the clearer of the two.

Take care,
-- DK

[Edit: changed titile, we'll talk about processing next time]

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher - Part 4b: The output channel

DavidKlineMS — Wed, 03 Oct 2007 20:59:19 GMT

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007
Part 3 - Managing the Transport
Part 4 - Sending messages

There is a time honored tradition in some television series of having, for example, 'Season 4' and 'Season 4b'. This weblog is no different. Welcome to Part 4b!

Last time, I described how the Lunch Launcher sends messages. As I was working on the project, I noticed that I had referenced a TransportObjects method that I had not explained in my description: CreateOutputChannel.

As with all entries in this series, please note that the following disclaimer covers all examples contained herein.
//----------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //----------------------------------------------------------------------- /// <summary> /// Create an output channel on which messages will be sent /// </summary> private IOutputChannel CreateOutputChannel(List<String> recipients) { IOutputChannel outputChannel = null; // build the recipient endpoint Uri uri = MailUriHelper.CreateUri(this.m_ChannelName, recipients.ToArray()); EndpointAddress endpoint = new EndpointAddress(uri); // create the output channel outputChannel = this.OutputChannelFactory.CreateChannel(endpoint); return outputChannel; }
This method uses the MailUriHelper object (part of Store and Forward messaging) to create a single Uri that addresses all recipients. This Uri is then used by the output channel factory to create the channel on which the message will be sent.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher: Part 4 - Sending messages

DavidKlineMS — Sat, 29 Sep 2007 00:52:28 GMT

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007
Part 3 - Managing the Transport

Last time, I talked about how the Lunch Launcher manages the transport objects used to communicate via Store and Forward Messaging on the .NET Compact Framework. Today, I'm going to discuss how messages are sent.

As with all entries in this series, please note that the following disclaimer covers all examples contained herein.
//----------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //-----------------------------------------------------------------------
MEDC 2007
When preparing for MEDC 2007, I wrote the code mostly to be functional and illustrative. I was not as concerned about optimizations. The example below comes directly from the MEDC 2007 demo project. In a little bit, we will see how it has changed since then. In both versions of the project, the SendMessage method is a member of the TransportObjects class that I introduced in part 3.
/// <summary> /// Send a message /// </summary> /// <param name="recipients"> /// Collection of recipient email addresses /// </param> /// <param name="messageBody"> /// The message contents /// </param> public void SendMessage(List<String> recipients, Object messageBody) { // create the serializer LunchObjectSerializer serializer = new LunchObjectSerializer(messageBody.GetType());

     // create the output channel
    IOutputChannel outputChannel = CreateOutputChannel(recipients);
    outputChannel.Open();
            
    // create the message
    Message msg = Message.CreateMessage(
                           // use the channel's default version
                           outputChannel.GetProperty<MessageVersion>(),
                           "urn:Microsoft.ServiceModel.Samples.LunchLauncher",
                           messageBody,
                           serializer);

// send the message outputChannel.Send(msg); // close the output channel outputChannel.Close(); outputChannel = null; }
How does it work? SendMessage is called with a collection of email addresses corresponding to the user's buddies (managed by the lunch launcher engine) and the payload for the message.

The first thing SendMessage does is to construct a LunchObjectSerializer (an implementation of XmlObjectSerializer) and tells it what type of object it will be serializing (via messageBody.GetType()). Next, SendMessage creates and opens the channel used to send the message to the recipients.

Once we have the output channel, the Message object can be created from the message body and serializer. The message is then sent an the output channel is closed (it is no longer needed).

That's how all messages are sent in the Lunch Launcher. There is no custom code for any of the message types.

Current version
Since coming back to Redmond and spending some time on the Lunch Launcher project, I have made a change to how messages are sent Here's how the SendMessage method looks today.
/// <summary> /// Send a message /// </summary> /// <param name="recipients"> /// Collection of recipient email addresses /// </param> /// <param name="messageBody"> /// The message contents /// </param> /// <param name="serializer"> /// The serializer used to encode the message for sending /// </param> public void SendMessage(List<String> recipients, Object messageBody, LunchObjectSerializer serializer) { // create the output channel IOutputChannel outputChannel = CreateOutputChannel(recipients); outputChannel.Open(); // create the message Message msg = Message.CreateMessage( // use the channel's default version outputChannel.GetProperty<MessageVersion>(), "urn:Microsoft.ServiceModel.Samples.LunchLauncher", messageBody, serializer);

// send the message outputChannel.Send(msg); // close the output channel outputChannel.Close(); outputChannel = null; }
Did you spot the change? SendMessage is now called with a third parameter -- the LunchObjectSerializer. The LunchObjectSerializer had previously created within SendMessage. This was done to optimize memory use and performance.

Every time an XmlSerializer is created for an object, that object must be examined via Reflection to determine how to convert its contents into XML. As has been discussed on many weblogs and conference presentations, Reflection is expensive. By reducing the number of times the LunchObjectSerializer object is created, the memory footprint is lower and performance improves (less reflection, fewer garbage collections). In fact, I was able to get the number of serializers down to exactly three for the entire application. The same serializers are used for sending and receiving messages.

In the MEDC version, there was a performance penalty for being popular (sending more messages). In the current implementation, the popularity penalty has been eliminated. :)

Next time, we'll look at how messages are received and processed.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher: Part 3 - Managing the Transport

DavidKlineMS — Wed, 12 Sep 2007 01:04:19 GMT

Part 1 - The origins of the 'lunch launcher'
Part 2 - MEDC 2007

In the first two installments (linked above), I introduced the lunch launcher and talked about getting ready for its debut at MEDC 2007 in Las Vegas. Now it's time to start looking at how the .NET Compact Framework v3.5 Store and Forward Messaging feature makes this application possible.

At the heart of the lunch launcher are the Windows Communication Foundation channel pairs (input and output). You may ask 'what do you mean channel pairs, isn't the one channel that sends and receives'? Excellent question! The answer is no. The Store and Forward Messaging feature is built upon one-way communications channels (IInputChannel and IOutputChannel). This is necessary due to the nature of email as a transport. Email has, what I term, variable latency. By variable latency, I mean that once a message has been sent, the time it will take for it to be received cannot be determined. It may be received in a few seconds, a few hours, a few days or never depending on when and if the recipient checks their email. This leads to some very interesting challenges in writing applications which leverage Store and Forward Messaging. I plan on discussing these challenges in a future post (separate from this series).

Back to the topic at hand... How does the lunch launcher manage the transport? All objects required to send and receive messages, for all three of the lunch launcher channel pairs (invitations, replies and notifications) are contained in a TransportObjects class, as shown below. This example is taken directly from the MEDC 2007 demo project.

Please note that specific details of property implementation and object construction have been removed for space reasons and that the following disclaimer covers all examples contained herein.
//----------------------------------------------------------------------- //THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY //KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE //IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A //PARTICULAR PURPOSE. //----------------------------------------------------------------------- /// <summary> /// Object to encapsulate and simplify working with /// Windows Communication Framework objects /// </summary> public class TransportObjects { /// <summary> /// The binding used to create the channels /// </summary> public WindowsMobileMailBinding Binding { get; } /// <summary> /// The name of the input channel (ex: "MyServiceChannel") /// </summary> public String ChannelName { get; } /// <summary> /// The input channel /// </summary> public IInputChannel InputChannel { get; } /// <summary> /// The channel factory used to create output channels /// </summary> public IChannelFactory<IOutputChannel> OutputChannelFactory { get; } }
The application engine creates the TransportObjects object and then initialize them (create the necessary Windows Communication Foundation objects) by calling Initialize().
/// <summary> /// Initializes the Windows Communication Foundation objects /// </summary> public void Initialize() { try { this.m_Binding = new WindowsMobileMailBinding(); this.m_Binding.AcceptExistingMessages = true; // create the binding parameters used by our channels BindingParameterCollection bpc = new BindingParameterCollection(); // NOTE: input channel gets the email address from the binding Uri inputChannelUri = MailUriHelper.CreateUri(this.m_ChannelName, "");

        // create the input channel listener         IChannelListener<IInputChannel> listener =             this.m_Binding.BuildChannelListener<IInputChannel>(inputChannelUri, bpc);         listener.Open();                         // create the input channel         this.m_InputChannel = listener.AcceptChannel();         this.m_InputChannel.Open();                         // now that we have the input channel,         // it is safe to close the listener         listener.Close();         listener = null;                         // create the output channel factory         this.m_OutputChannelFactory = this.m_Binding.BuildChannelFactory<IOutputChannel>(bpc);         this.m_OutputChannelFactory.Open();     }     catch     {         // initialization failed, make sure we cleanup         Uninitialize();         throw;     } }
When the application engine is done with a channel pair (at shutdown) or if anything bad occurs (exception on initialization, for example) Uninitialize() is called.
/// <summary> /// Uninitializes and cleans up the Windows Communication Foundation objects /// </summary> public void Uninitialize() {     if(null != this.m_InputChannel)     {         this.m_InputChannel.Close();         this.m_InputChannel = null;     }     if(null != this.m_OutputChannelFactory)     {         this.m_OutputChannelFactory.Close();         this.m_OutputChannelFactory = null;     }     if(null != this.m_Binding)     {         this.m_Binding.Close();         this.m_Binding = null;     } }
In the event that the application engine encounters a faulted state on the transport, recovery is performed by the Recover() method. Recover calls Uninitialize and Initialize. If both succeed, success is indicated by the method returning true. Upon a true return, the application logic continues to send and receive messages. A false return aborts the channel pair's functionality.
/// <summary> /// Recovers from a transport fault by uninitializing and reinitializing /// the Windows Communication Foundation objects /// </summary> /// <returns> /// True if recovery was successful, false otherwise /// </returns> public Boolean Recover() {     Boolean recovered;                 try     {         Uninitialize();         Initialize();                         // successful recovery         recovered = true;     }     catch     {         // unsuccessful recovery         recovered = false;                         Uninitialize();                    }                 return recovered; }
Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher: Part 2 - MEDC 2007

DavidKlineMS — Tue, 11 Sep 2007 02:01:43 GMT

In part 1, I introduced the lunch launcher. Today, I'm going to talk a bit about the preparations for the "world premier" of the lunch launcher from MEDC 2007.

Before getting started, I set out a few goals:

Provide an introduction to the Store and Forward Messaging feature of .NET Compact Framework v3.5
Demonstrate point-to-point device communications via Store and Forward Messaging
Implement invite / reply functionality (voting and destination notification were not a goal for the demo)
Minimize duplicate communications code where possible
Use additional .NET Compact Framework v3.5 new features as appropriate and/or interesting

With the goals defined, I sat down to write my vision of the lunch launcher. I installed an almost beta 1 release of Visual Studio 2008 (then node named 'Orcas') and created a Windows Mobile 6 Professional project.

The first thing I wanted to be sure to do was to reinforce some of what I would be talking about in my Thursday session -- GUI-Logic separation. While not split into separate assemblies for MEDC (they are split now) the user interface and business logic (aka the engine) were contained in a collection of classes across two namespaces.

My next goal was to design the communications to be as simple, and re-usable as possible. Though I did not completely achieve this in the MEDC demo, it has since been accomplished. I will talk about the changes between the MEDC and current designs in a later installment.

The communications required by the lunch launcher fall into three transactions: invitations, invitation replies and destination (where to meet for lunch) notifications. I implemented separate channel pairs (send and receive) for each transaction. By designing this way, each input channel knows how to receive exactly one message type, no complex "what type of message did I receive" logic. Similarly, output channels need only know how to send a single message type.

For the sending of the messages, I discovered that the code was nearly identical for all three of my transactions. The only differences were the message type and the name of the channel that would be receiving the message. This got me thinking about encapsulation. As a result, I created an object that contained all of the required Windows Communication Foundation objects and a method to send the message. This was very effective and allowed me to fix issues in all three channel pairs with one code change.

For the receiving of messages, I actually had three copies of very similar code. Since this was an introductory demonstration, I elected to not factor the common code until after MEDC. Instead, I used the duplicated code to illustrate how similar the transactions actually were.

Remember when I said I installed an "almost beta 1" release? I went into panic mode when I installed the final beta 1 build and found that I could not build my application (see Mark's post for the why's). The issue identified (and worked around for the trip), I went back to fine tuning the demo.

Tuesday morning, Las Vegas: In the final morning session of the first day of MEDC, I took the stage in what I called "the big room" (as opposed to the "really big room" where the keynote was held) to present in front of my largest audience to date. The room held about 400 people and I was told that there was standing in the aisles and in the hall (wow!).

When it came time to unveil the lunch launcher, I wondered (not for the first time) if I had too much coffee as my nerves were on high alert. Demonstrating pre-release software live on stage is a scary thing. Any of a number of little things could easily go wrong. Fortunately for me, things went extremely well. Even the delays waiting for message delivery through the server were minimal -- so minimal, in fact, that I was still explaining what was occurring when the messages arrived.

The lunch launcher was now officially real. :)

With a successful demonstration of peer-to-peer social messaging complete, it was time to show how it worked. Since this post has gotten a little long winded, I will save that discussion for the next installment.

Take care!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

The Journey of the Lunch Launcher: Part 1 - The origins of the 'lunch launcher'?

DavidKlineMS — Sat, 08 Sep 2007 01:44:55 GMT

Several years ago, when I first joined the .NET Compact Framework team, we took some time (a week, if memory serves) to play with our product. We called that our "app building" time. At it's heart, app building is an opportunity for us to get a feel for the experience our customers will have with our product. Whenever app building time is scheduled, I'm like a kid in a candy store. :)

During that first app building week, many of us got together to brainstorm cool applications. One of these we called the "lunch launcher". In a nutshell, the lunch launcher would be a social application that allowed friends to invite each other to lunch at a specific time and collect votes for the desired restaurant. Shortly before the scheduled time to eat, a notification would be sent to everyone with the selected restaurant.

Unfortunately, the lunch launcher was an application whose time had not yet come. It was not technically feasible to write a networked application that communicated point-to-point with other devices to schedule lunch, so we shelved the idea.

Shelved, that is, until we started planning .NET Compact Framework version 3.5... enter the Windows Communication Foundation.

About two years ago, Roman Batoukov wrote a post titled "Windows Communication Foundation (Compact Edition) and the story of the Lunch Launcher". As Roman (and later, Mark Prentice) described, version 3.5 adds a subset of the Windows Communication Foundation that was released as part of version 3.0 of the .NET Framework. While planning the Windows Communication Foundation subset, an epiphany occurred. Why not implement a Windows Communication Foundation channel that uses email as the transport? Using email for communications would provide a number of big benefits, most specifically a means for addressing the device, regardless of which network it is currently on, and a way to store messages for later transmission if the device is offline at the time of the send.

As a member of the Windows Communication Foundation feature team, I started thinking about the lunch launcher again. When we were preparing for MEDC 2007, I had the privilege of writing and debuting the concept in front of more than 400 attendees and talking about it one-on-one with many throughout conference. The lunch launcher was finally alive!

For the remainder of this series, I will be talking about my journey of writing the lunch launcher (one that I am still embarked on). I will start with the original MEDC 2007 demo application and go through the evolution of the application wanted to write when we first dreamt of the lunch launcher. I hope you will find my tale interesting and informative.

Take care!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Handy "What is supported" table for Windows Communication Foundation in .NET Compact Framework v3.5

DavidKlineMS — Sat, 08 Sep 2007 00:30:09 GMT

Last month, Andrew Arnott posted a very handy table that compares the Windows Communication Foundation features found in .NET Framework v3.0 with those found in .NET Compact Framework v3.5. This is an invaluable resource for anyone writing Windows Communication Foundation code for both PC and Mobile devices.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Mark Prentice Introduces Store and Forward Messaging in .NET Compact Framework v3.5

DavidKlineMS — Thu, 26 Apr 2007 21:11:00 GMT

Yesterday, Mark posted a 'Hello World' example using the Store and Forward Messaging technology which will ship with version 3.5 of the .NET Compact Framework (currently in beta).

For me, this post is particularly exciting since it allows me to start talking about the feature that I have been busilly working on for the past several months - Store and Forward Messaging.

As Mark mentions in his post, Store and Forward Messaging is built on the Windows Communication Foundation and uses our new Email transport to enable devices to communicate with PC / Server systems as well as other devices. For me, the coolest aspects of Store and Forward Messaging are that it makes devices addressable and I no longer need to worry about whether or not I have connectivity when I send or receive a message -- the email infrastructure takes care of that for me automatically.

If you are coming to MEDC 2007 next week, I highly encourage you to attend Mark and Sergey's session (APP325) on Tuesday afternoon. They will be introducing Windows Communication Foundation for the .NET Compact Framework and Store and Forward Messaging. If you would like to give Store and Forward Messaging a test drive while you are there, Anthony will be presenting an Instructor-Lead Lab (ILL317) on Tuesday (right before Mark and Sergey's session).

And, I would be remiss if I neglected to mention my own session during which I will introduce .NET Compact Framework version 3.5 and demonstrate the cool new features we will be delivering with Visual Studio 'Orcas' including Store and Forward Messaging.

Last October, Roman wrote about the Windows Communication Foundation and an application that he called the "Lunch Launcher". Back in the early days of the .NET Compact Framework, I was one of the folks who was trying to implement a Lunch Launcher (I owned networking and web services testing back then). This coming Tuesday, during my session (APP214), I will at long last be demonstrating a Lunch Launcher built on Store and Forward Messaging! I cannot wait to finally get to show it to you.

Take care and hope to see you all at MEDC!
--- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

Windows Communication Foundation for .NET Compact Framework

DavidKlineMS — Tue, 27 Mar 2007 21:27:00 GMT

Yesterday, Mark Prentice posted an introduction to the Windows Communication Foundation for .NET Compact Framework. Like him, I would like to recommend reading Roman Batoukov's post from last October.

One of the reasons that I have been slow to post to this weblog in recent months is that I have been busy working with Mark and others to deliver the Windows Communication Foundation for .NET Compact Framework.

I will be posting more on this cool new feature after beta 1 of Visual Studio, code name 'Orcas' has been released and you can take it for a test drive.

If you are planning on attending MEDC 2007 in Las Vegas (May 1 - 3), I highly recommend Mark and Sergey Kuryata's session on the Windows Communication Foundation. They have some great information and demos planned.

Take care,
-- DK

[Edit: add link to MEDC site]

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.