Exchange, SharePoint and Lync. These products represent the key collaboration offerings from Microsoft and are indeed platforms of great interest for anyone wanting to enhance collaboration within an organization. The promise of Office 365 is to be free from the chores of provisioning and managing a complex collaboration infrastructure, but that in itself has created a new challenge for developers who need to build the applications enterprises are used to having when the servers are out of reach.
When Office 2013 was announced not all that long ago, Office 365 Home Premium and Small Business Premium are to a great extent about Web versions and online integration of the traditional Microsoft Office applications. Both offer e-mail, and the Small Business version provides access to Lync functionality. At this point, I am not sure if there is any single feature that is shared across each and every offering that bears the name Office 365.
The developer story for now is about the collaboration pillars, and that is what we will cover in this article.
The APIs decide what you can do
Each of the core pieces of Office 365 provide APIs for integrating your collaboration applications. In each case, the API controls what can and cannot be done in terms of integration with the platform. There is not a common interface for each piece, and, as we will see, they each bear the marks of their history and place in past iterations of Microsoft’s world order.
Exchange has been the most enduring of the collaboration servers. It has a long history of allowing developers to enumerate collections of messages or contacts via data interfaces like ODBC or ADO. For Exchange Online, there is the Exchange Web Service (EWS), which is a SOAP-based XML Web Service that offers developers used to programming against local resources access to most of the underlying Exchange objects. For example, in the latest version, you can manipulate private distribution lists.
The EWS is an object-oriented API, and presents classes such as Appointment, Contact and EmailMessage. The API is well defined, and it helps that those of us who have been developing products and applications that lean on Exchange are already used to being held at arm’s length from the server. E-mail admins are not known to allow developers direct access to their servers.
For Lync Online development, Microsoft provides the Lync Automation API. The Lync Automation API is a different take on things than the Exchange Online interfaces. It could be that this is because Lync is newer than its Office 365 companions, but I think that for Lync, Microsoft is slow in providing ways to emulate functions on the server, such as processing items like contacts.
Instead, for Lync, you get to instantiate a client object that can let your application start a conversation, add a contact or join a conference. The name indicates this is less of a management API and more of an automation API.
There is a recurrent cycle in Microsoft Server products where the first versions are much more like black boxes than Lego sets. Exchange and SharePoint both have emerged from the server product black-box stage. I do not think Lync has made it that far yet, but the fact that it is included in Office 365 is likely to accelerate things dramatically in this regard. Then again, some of the developments on the SharePoint Online side may indicate that the server side is going to be less accessible to developers as time passes.
The Online SharePoint developer story is a bit different from either the Exchange Online or the Lync Online API stories. There are multiple ways to make various things work with SharePoint, thanks to its position as a platform of great importance in the Microsoft world over the last few years. For example, WebDAV can be used to upload and download files, and like Exchange, there are Web services that provide access to lists and libraries as if they were relational data. Microsoft Developer Network points out that “Developers can also access the Excel Services REST API in SharePoint Online. This API enables developers to access workbook parts or elements directly through a URL. This allows for a flexible, secure and simpler mechanism to access and manipulate Excel Services content.”
All of these Web Service interfaces are actually considered legacy with regard to SharePoint Online. Instead developers are encouraged by Microsoft to use the Client Object Model where possible. As we will discuss, this is currently the preferred API for programming against SharePoint Online.
#!
Adapting to cloud development
The biggest culture shock for enterprise developers when confronted with the need to build a solution integrating with Office 365 is that the server and its DLLs are not readily available. This removes the tried-and-true Component Object Model programming model from the list of possible integration methods. To make things a bit more confusing, the Client Object Model offered for SharePoint Online development can also be referred to by its initials. The important thing to remember is that Software-as-a-Service and cloud computing as a whole are driving the need for developers to consume APIs made up of services.
The Client Object Model actually represents three different APIs that can be called from three distinct environments. Whether you are using JavaScript to provide a browser-based solution, developing for the .NET Framework version 3.5 or later, or working with Silverlight 2.0, there is an API in the Client Object Model available. Each of these provides a subset of capabilities taken from the Microsoft.SharePoint.dll. In the name of limiting size, these new APIs concentrate on client capabilities rather than server functionality.
This is similar to the client functionality focus of the Lync API. It is plausible that less server-side access is in our future, which would make sense given the need for Microsoft to ensure stability in a multi-tenant SaaS environment, but this could represent the biggest justification for larger enterprises and medium-sized businesses with aggressive internal developer teams to pass on Office 365 and stick with self-hosted implementations of their collaboration servers.
As a developer, you also have to contend with the features present in the levels of the offerings. The SharePoint component of the small business plan (Plan P1) SSL is not available, and the evidence that this is a common roadblock are the numerous posts by developers trying to figure out why they cannot make SSL work on their solution. Larger organizations would most likely not have this problem given that the Enterprise plans (referred to as E Plans) do support SSL.
This does not make larger organizations immune to the issue, since sometimes departments will acquire their own subscription, especially when piloting or doing proof of concept for the larger organization. This could result in larger organizations hitting the roadblocks that have seemingly been put in place to entice smaller organizations to take the higher-priced Enterprise offerings.
Marketplaces for all occasions
Microsoft Marketplace is the app store for Windows 8 and Windows Phone 8 apps, especially those conforming to the new user-interface model.
Microsoft Marketplace has gotten a great deal of attention, but there is also a marketplace for Office 365 available. If you visit office365.pinpoint.microsoft.com, you will find a searchable list of vendors and their offerings. Currently, the Office 365 Marketplace is mostly a clearinghouse for consultants looking to help monitor or implement Office 365 for clients rather than product offerings that enhance Office 365 offerings. This is in large part due to the fact that in these early iterations, Office 365 is a bit of a black box hosted by Microsoft. There is not much room for applications to install on the server running Exchange or SharePoint, meaning that the ecosystem is limited to those hoping to wrangle the offering itself.
The lack of a single consistent programming model across the components means developers have to ramp each up on its own time. It is likely that things will be more uniform sometime down the road, provided Microsoft does not change its mind about how these platforms fit together.
