SharePoint Client Object Model ( SP - COM )

Part - 1

[ Introduction : Theoretical background and Overview]  

One Project which I involved as a developer from the scratch is Called ShawCor, this system ( intranet ) was developed for ShawCor Ltd. ( ShawCor Ltd. is a growth-oriented, global energy services company). so we decided to develop this based on COM (Client Object Model), so Why we decided ? and What is this COM ? will be Discussed. 

What is Client Object Model in SharePoint ? 

The definition of Client Object Model is kind of a boring but you can extract some of the words and get an idea so here we go please have a look at the words which highlighted 

"The Client Object Model (OM) is a new programming interface for SharePoint 2010 where code runs on a user’s client machine against a local object model and interacts with data on the SharePoint Server. Client OM methods can be called from JavaScript, .NET code or Silverlight code and makes building rich client applications for SharePoint easy."

So in Simple words this is a new programming interface which come with SP 2010 and using JS, silverlight kind of a Scripts which runs on a Client machine but still it interact with SP server to extract data.

Why we needed it ? [What do we want to achieve?]

 As in the ShawCor Project, Sometimes we want to extend SharePoint by adding functionality which will execute on the client-side. imagine is it requires no post-backs (specially in New popups Animations), in other words, we want some mechanism to execute code on the client-side but then still interact with SharePoint data and functionality which reside on the server.

• Building Silverlight components, 
• Build web parts which contains client side code like ajax or silverlight, 
• Extend an existing Windows forms application which contains client-side code.

  What about SharePoint 2007 ? 

In SP 2007 you had to use the native SharePoint Web Services or build new custom web services which will be hosted on the SharePoint server. Remember that custom web services will use the server object model. Deploying custom web services onto the server creates an administrative overhead and introduces a risk. so I can not recommend 

This is How SP 2007 works in similar process.

So it is very obvious that we needed some mechanism to build client-side code which has an awareness and access to the SharePoint Server Object Model.

This is what Required.

Microsoft helped solve this problem for us by introducing the SharePoint 2010 Client Side Object Model. Now we have a mechanism to extend SharePoint functionality through client-side code..without using SharePoint Web Services !!!

›Mechanism(s) behind it.

Here I have put a simple fig: to understand how this works. 

1) First When your written ECMA (will explain later ) Script convert into a ECMA Script Object model like Ajax Object do

2)It go through a Proxy do security validations.

3)And reach a client.svc, it's a WCF service which analyze this Clint object and understand the requirement then Convert into the Sever Codes which SP server can understand.

4) send the Server code into the SP server 

5/6) then sever will communicate with the content Data base and do what it asked, things like get data or write records. 

7)Then send the response to the web service 

8)Web service again analyze the Server Code and Filled the return data into a ECMA Object and send it to the Browser to do that it required. 

Advantages of Client Object model.

• We can access SharePoint data from the client side browser itself with Silverlight and ECMAScript applications. 
• Web parts with very rich user interface can be developed with the help of Silverlight and jQuery 
• COM along with JavaScript or jQuery can be implemented with just a Content Editor Web part within the browser or from SharePoint designer without opening Visual Studio. 
• When you save your site as a template. The application developed with an ECMAScript or Silverlight application implemented with Client Object Model would come along with the template. 
• No IISREST is required. 
• No SharePoint installation is required in the development machine.

Disadvantages of Client Object Model.

• We cannot elevate the privilege or Impersonate in COM as in the Server Object Model. That is, we cannot use the RunWithElevatedPrivilege kind of a delegate. Therefore, the result retrieved using COM will always be security trimmed by default. 
• The range of classes available to access SharePoint data is very limited in COM. For example, we do not have Classes for accessing User Profiles. 
• We cannot access the objects of another site collection in COM while implementing in Silverlight or in an ECMAScript. We will get “The security validation for this page is invalid.”

So those are the theoretical thing you need to know on using COM, in the Next part [Let's Code] you get to know how to code it. 

ok That's It ... 

HAPPY CODING