SharePoint 2010: Client Object Model – An Introduction

Introduction

SharePoint 2007 allows using its Object model to run against a server running SharePoint. For clients (not running SharePoint in the box), the simplest way to communicate with SharePoint server is web services. SharePoint Client Object Model (OM) can be run on client PC (where SharePoint is not installed) to communicate with SharePoint server. So whereas SharePoint (Server) Object Model runs in a SharePoint server and can manipulate SharePoint objects, client OM can run in client PC and communicate with SharePoint server remotely.

SharePoint 2010 introduces three new client APIs which can be used to interact with SharePoint sites. The three APIs are targeted for three different types of clients:

1. For .NET managed applications (for example, console applications, window applications, web applications, etc. which are not running inside SharePoint Context).
2. For Silverlight applications.
3. For using with JavaScript (called ECMAScript). This API is only available for applications hosted inside SharePoint (for example, web part deployed in SharePoint site can use this JavaScript API for accessing SharePoint from browser using JavaScript).

I'll explain all of these API sets gradually. In this post, I'll explain some basic problems SharePoint developers faced during development with SharePoint 2007 in the absence of Client Object Model.

Why Client Object Model (OM)? 

SharePoint 2007 had no Client Object model available. So you may ask why this is introduced in SharePoint 2010? We had no problem without Client OM and millions of sites are running smoothly without having Client OM. The main reason is that Microsoft has found lot of requests from SharePoint users to introduce more and more web services to get data out of SharePoint in the last couple of years. But introducing web services will not fix the issues, as Microsoft found, because then the request for more functionality in the web services will continue. Even if Microsoft provides a good numbers of web services with SharePoint, customization in web services will be required for different clients and this will make the out of the box web services unusable. Also introducing a large number of web services will be a waste as not all companies will use all the web services functionalities.

In response to add more web services from users, Microsoft has taken a different approach called Client Object Model (OM). This SharePoint Client OM will allow getting data out of SharePoint from PCs that are not hosting SharePoint. Also Client OM provides complete API to interact with SharePoint Server which is more intuitive and useful and very much similar to the SharePoint Object Model.

Similarity with SharePoint Object Model 

Now SharePoint developers will fear that the Client Object Model will introduce a new burden for them to get used to it. But thSharePoint team provided great efforts to keep the Client OM familiar with SharePoint Object Model. The following table shows the equivalent objects in Client and SharePoint Object Model.

So the class names in Client OM are similar as in the SharePoint Object Model. However the way client OM will be used is a bit different than the usual SharePoint Object Model that we will explore in the upcoming posts.

How Client OM is Developed and Work under the Hood? 

It’s interesting how SharePoint team has developed the same set of classes for three different sets of applications (Managed, Silverlight and ECMAScript). There is the same class ListItem for three different sets of applications. As shown in the following table, three different assemblies/files are used for three different types of applications.

To ensure the same class object (say ListItem) behaves similarly in three different types of applications, the SharePoint team followed the steps described below:

1. SharePoint team first set attributes to the SharePoint classes and methods and properties that need to be exposed in Client OM.
2. Then a code generator is run against the SharePoint object model to generate client OM automatically.

This automated code generation has ensured maximum compatibility between these three sets of APIs. As the following figure shows, client communicates to the server thorough Client OM which under the hood uses Client.svc WCF service to communicate with SharePoint Server. Client.svc service uses Server OM as per client request and returns the result to the client in JSON format.

With this new Client OM, we almost don't need to use web service to communicate with SharePoint server. However, the client OM has just been released and we will find its shortcomings as well as use it more and more in live projects. In my next posts, I'll go through three different kinds of Client OM (Managed .NET, Silverlight and ECMAScript).