Windows Communication Foundation (Compact Edition) and the story of the Lunch Launcher
A while ago, when .NetCF v1 wasn't released yet, we could only guess what kind of applications our customers would build. People on the team were coming up with various ideas of mobile applications they would like to build on top of our platform and try to figure out which platform features would be most valuable. We had application building days, when everyone on the team would go and work only on their personal application projects.
One of the really simple ideas that came up then and remained unimplemented was the "Lunch Launcher". Many folks on the team prefer local restaurants to Microsoft cafeteria. Getting several people to go out to the same place often requires lots of coordination over the phone or e-mail, especially when people are away from their offices, in different buildings. Usually someone wants Indian food, someone had Indian three days in a row and wants to go for Mexican and someone else have strong cravings for a slice of bad pizza...
As most people on the team have some sort of Windows Mobile device connected to WiFi or mobile carrier network, we thought it would be nice to have an application that allows one person to send a lunch invite with a list of a few good local restaurants to other people and let them vote where to go to. When the poll is finished, its' results (the place of choice) are communicated back to everyone and everyone hopefully is heading to the same place. Sounds trivial, doesn't it?
However there are a couple of problems that make this application idea really hard to implement using existing connectivity technologies. First of all, how do I address someone else's device? Device IP address is not stable and is not discoverable... This makes "push" scenarios and true P2P not feasible. Second, devices lose connectivity all the time and someone may be off-line when the message is sent. How do I make sure my message reaches the other person's device, if we may not be on-line at the same time?
Interesting enough, simple, well-known technologies exist today that can help solve both of these problems. Every connected Windows Mobile device can send and receive e-mail, i.e. it has a stable, discoverable address associated with it - e-mail address. E-mail also works pretty well in the on-line/off-line scenarios (occasional connectivity). So, at some point Mike Zintel started promoting an idea of using e-mail as a web service transport and putting a programming model on top of it. Hmm, e-mail!? I was really skeptical about this at first, as probably many of you are now. But let me ask you this - how many times did you use e-mail to transfer some data from one computer to another? I find myself doing this far too often. For example, when I need to get some document from my machine at work to read it later at home - I send it as an e-mail attachment to myself. If I want to get a couple of pictures from my home computer to my work machine - I send myself an e-mail. I even use e-mail to get documents from my desktop machine to my laptop, when my laptop is off-line. It's quicker than sharing the file, turning another machine on, going to the share and copying it over. Sure, there are some limitations. But there are a number of scenarios when it comes pretty handy. Now, you may ask what does it have to do with .NetCF and web services and how does this help application developers?
Well, .NetCF team has been very busy since we shipped CF 2.0. A number of exciting things are happening here. Earlier Mike gave away some "hints" about what's coming: "the NET CF team is working on WCF subset for the next release, with some interesting support for transiently connected networks." I think it's time to elaborate on what that really means.
We are bringing a subset of WCF (Windows Communication Foundation, formerly known as Indigo) to devices. WCF provides a new unified programming model for building connected applications with managed code. The cool thing I like the most about WCF is its' extensible channel architecture. It allows building applications that can work on top of completely different transports and protocol channel stacks. Using WCF programming model, now I can send and receive data in my application equally easily using HTTP, TCP or e-mail. In many cases I can maintain identical or very similar communication logic code - sending and receiving the data works on top of various channels (only the initialization part will be different, as different channel stacks need to be constructed).
WCF is built around the concept of a Message object. The structure of a Message object loosely represents a SOAP envelope, and consists of two distinct parts: the message's body and an extensible collection of headers. The body is application-defined data, and headers are added/processed by infrastructure (and can also be used by the application). It is this structured primitive which is the core of WCF power (and which departs from the classic networking primitive of a byte array). It allows for extensible interoperable protocols to be built, and combined together in different ways. (See the following blog entry for more details).
The WCF programming model support will be limited to channel layer messaging (no service model support on the device) which means your program will be sending and receiving messages and it will be up to the application to correlate messages with each other (no RPC semantics). However, we are working on a custom proxy generation tool (along the lines with SvcUtil) that would allow consuming WCF services running on the desktop by the messaging client on the device without the need to modify the public-facing service.
Transport Channels perform the actual send/receive of the Message to a network resource. Layered Channels perform a function based on the Message passed in, and then delegate further modification and transmission to other channels in the channel stack. Some examples of Layered Channels include Protocol Channels that use Message headers and infrastructure Messages to establish a higher-level protocol (such as WS-Security). .NetCF will support a subset of WS-Security to enable message-level security and mutual certificate authentication.
We'll expose all necessary extensibility points so people could plug in their own transport and layered channels, while maintaining a unified programming model. We'll deliver a couple of transport channels out of the box, but we expect the community to fill in the gaps and build a variety of custom channels. The channels we plan to deliver out of the box are Http and... yes, e-mail (for WCF on desktop and device). Our friends from WCF team played around with building custom e-mail transport channel before and proved that it's feasible. We decided to take this experiment one step furhter to address concrete problems mobile application devlopers are facing today.
Thanks to the e-mail infrastructure, now you can host a service app on any machine or device that can reach your e-mail server (Exchange). It provides a totally symmetric communication model. Exchange server acts as a relay that allows communicating between devices that aren't on-line at the same time. We built a demultiplexing scheme that allows multiple applications to share the same e-mail account (the only limitation - multiple instances of the same application sharing the same e-mail account can't be on-line at the same time. Think of this as a network port sharing problem). This works through firewall/NAT boundaries. And with AirSync "Always Up To Date" technology, it should allow prompt message delivery once network connectivity is available. We are going to leverage powerful Exchange 12 web services under the hood on the desktop side Thanks to WCF layered architecture, channel implementation details will be hidden from application developers.We are working with Exchange server team to make overall user experience nicer and enable separation of regualr e-mail traffic from "service" e-mail traffic.
So, finally we were able to build a "Lunch Launcher" app. We also built some interesting P2P casual games (like Poker), that tolerate the high latency of the transport. We see this channel as a powerful notification mechanism for mobile LOB applications - now you can easily "push" important notification messages to occasionally connected device on the mobile network. For example, a Mobile Sales application could easily push information about an item recall or inventory change to all devices in the field. Even if some of them are off-line, they'll pick up the message once the network becomes available:
I can also see this channel used as a light-weight notification mechanism to trigger more heavy weight data sync (through SQL Everywhere / Sql merge/replication or RDA) and avoid expensive polling.
We don't expect people to always use e-mail as a primary transport channel, if a good stable network connection is available. However, in many cases it can be used as a backup. Thanks to the unified programming model, switching from one transport channel to another is fairly easy. The e-mail channel will provide an off-line message store on the device, so application developers won't need to implement complex logic to detect network connectivity. Thus app developers can just call Send() and forget about the message - it's placed into the off-line queue (Outbox) and gets physically sent out when it becomes possible.
We'll leave it up to you to come up with more cool app ideas. And we'd love to hear from you what kind of mobile WCF applications you'd like to build. As usual, your feedback is very important to us.
Stay tuned...
- Roman
This posting is provided "AS IS" with no warranties, and confers no rights.
