Well we’ve seen a fair amount of reminiscing in the blogs to date. It’s interesting even to me to hear from the Exchange veterans about the high-flying times back in the 4.0 and 5.5 days. I’m a relative gremmie on the Exchange team although I did develop the administrative components for the Key Management Service on Exchange Server 2000 (Platinum). After a couple of years diverging into the untethered world of Mobile Information Server, I came back to help build some mobility into Exchange Server 2003. One of those pieces is Outlook Mobile Access. This browse application is similar to Outlook Web Access but much lighter weight and meant to be viewed on today’s latest cell phones. I thought that I’d walk you back through its development and share some of our experiences as we brought it to life.
As some of you may know, OMA’s roots come from Mobile Information Server. It was a much different beast back then, deriving its functionality from the unmanaged internals of MIS and IIS. After shipping a couple of versions, part of the dev team started looking at abstracting out the interface to the Exchange server and using the new-fangled C# managed environment. For one reason or a hundred, the MIS tent was folded but Exchange was still interested in OMA for its just-launched Titanium project.
One of the more painful issues of building an application for the cell phone market is the disparity in phone browsers that still exists today. Think of web development for IE+Navigator and multiply by a hundred. The dev team was swarmed by test engineers entering device-specific bugs. The markup looked great on one device and was illegible on another. Enter the .Net Mobile Controls. Our friends on the Visual Studio team were willing to take some of the browser disparity burden off of our shoulders and, at the same time, deliver a great device-agnostic framework for the phone-developer community at-large. We work closely with that team today in testing OMA with their latest device-update web releases for new/additional phones as they hit the market.
Another area where the OMA developers were pushing the envelope was the use of the .Net Framework and ASP.Net. OMA is the only Exchange server component that runs under the managed environment. Originally we were worried about performance, but we found that OMA can handle quite a few client sessions without server degradation.
I’d love to hear any feedback from those of you who have deployed or used OMA. Let us know what’s not working for you and how we can make it better. In the meantime, we’re dreaming up our own ways to make it better.
