It's always been hard to develop applications for Exchange Server. I base this statement on my experience as a developer and on the number of comments I've heard from other developers who have tried to extend, modify, or remove certain Exchange behaviors. This development problem has a direct bearing on all of us because it restricts the number and type of third-party solutions available for Exchange.
Microsoft has been justly criticized for not providing APIs for some Exchange functionality, having multiple layers of APIs that appear to do the same thing, and providing a confusing thicket of interfaces that come and go with each new version of Exchange. In fact, just about the only fully supported interface I can think of that has remained available since Exchange Server 5.5 is Messaging API (MAPI), which is now called the Outlook-Exchange Transport Protocol, and which isn't easy to use in any event. With the introduction of Exchange Server 2007, Microsoft has dramatically simplified the development story for Exchange-aware applications by doing three things: cutting several old APIs, deprecating some APIs to indicate that they shouldn't be used going forward, and introducing a new set of APIs. (For a list of the cut and deprecated APIs, see the Microsoft Exchange Team Blog post "E12 Developer Roadmap.")
I've written before about one of these new APIs, Exchange 2007's support of Windows PowerShell through Exchange Management Shell. Technically, Exchange Management Shell isn't an API, but it's already helping third parties (and administrators) write scripts and tools for Exchange 2007. However, I haven't talked much about Exchange Web Services, a complete API that lets you do a large number of things with Exchange, mostly focused on actions of interest to clients.
In general, Web services are service-oriented components that run on an application server. You make requests of them by using Simple Object Access Protocol (SOAP), which is essentially a way to pass a chunk of XML to a remote Web service so that the Web service can do some work and return a result. The Web services model is widely supported by many of Microsoft's competitors as well as by some major open-source application toolkits and frameworks.
Exchange Web Services uses this method to expose Client Access server functionality to SOAP-based applications. For example, you can easily use Exchange Web Services to either query or set the out-of-office state of a mailbox, to create a message, to find out when a given resource is free or busy, and so on. (Of course, your code must run under an account that has permission to get the requested data!) This ability is a big deal for two reasons. First, there have always been client operations that have been difficult or impossible to emulate without writing a ton of MAPI code. Second, SOAP with XML is an open and widely supported standard, so you can easily access or create Exchange data from a much wider variety of applications and platforms than ever before. Microsoft Office Communications Server 2007 implements its own set of Web services as well, raising the possibility of integrating these two products with your line-of-business applications or with systems you use for activities such as manufacturing resource planning, team scheduling, or project management.
Microsoft Office Outlook 2007 is probably the best example of what Web services applications can do because it uses Exchange Web Services to communicate with Exchange 2007 servers. I also expect the forthcoming Microsoft Entourage 2008 to show off Exchange Web Services' power. Because none of us have the source code for these two programs, though, Microsoft has posted several Web services samples on the MSDN Web site. If you're familiar with the basic concepts behind Microsoft .NET Framework programming, you'll find the samples immediately intelligible.
The appearance of Exchange Web Services means that ISVs now have a well-supported and open means to do things that were difficult or impossible in previous versions of Exchange—but what will they do with this tool? That remains to be seen. If there are specific features or behaviors that you'd like to see built with Exchange Web Services, drop me a note and I'll post the best suggestions in a future column.
