Microsoft Office 365 development: A collaborative story

By Patrick Hynds

October 29, 2012 — (Page 1 of 2)
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.

Office 365 development

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.

Related Search Term(s): Microsoft, Office 365, Windows

Pages 1 2

Share this link: http://sdt.bz/37114

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Ballmer announces Windows 7, Windows Server 2008 R2 betas Microsoft CEO Steve Ballmer used the CES 2009 spotlight to announce the availability of betas for the upcoming version of Windows. Preview versions of Windows 7 and Windows Server 2008 R2 have been distributed to testers, with general availability coming tomorrow.

Microsoft reports record revenue for quarter Business Division sales grow 20% from prior year; Kinect motion-control sensor launch drives Xbox sales

Microsoft details WCF and WF in next-gen .NET Easier creation of REST-type applications and more seamless integration between WCF and WF are some of the main focuses in Microsoft's plans. Also, "Dublin," an update to Windows Server 2008, will allow it to host composite applications by extending the Application Server Role.

Ballmer announces Windows 7, Windows Server 2008 R2 betas
Microsoft CEO Steve Ballmer used the CES 2009 spotlight to announce the availability of betas for the upcoming version of Windows. Preview versions of Windows 7 and Windows Server 2008 R2 have been distributed to testers, with general availability coming tomorrow Read More...