The Service Application Framework is commonly represented as a new addition in SharePoint 2010. So that you can fully understand how services are provisioned and managed within a SharePoint farm, we need to look at the overall services architecture. Although new additions are included in SharePoint 2010, a lot of the underlying framework will be familiar to users of previous versions of the product.
If you’ve read the preceding, you will be familiar with the notion of a farm within the SharePoint platform. A farm represents one or more servers that are logically grouped together for the purposes of administration, scalability, and reliability. Within the SharePoint object model, the farm is represented by the SPFarm object.
Clearly, there’s more to SharePoint than just hosting web sites; much of the additional functionality, such as the ability to service search queries or functionality for sending and receiving e-mail, is provided by a range of discrete platform services. Each of these services is managed at the farm level and is represented within the SharePoint object model as an object derived from SPService.
In a simple environment with one server, it may be sufficient to have a single object that allows configuration and management of a single service; however, the SharePoint platform has been designed to be scalable across many servers, with each server potentially running one or more instances of a service. As a result, the SharePoint Object Model makes use of two additional objects to manage services: The SPServiceInstance object represents a single instance of a service that is installed on a particular server (represented in the object model by the SPServer object). The SPServiceApplication object represents a single farm-level instance of a particular service.
For example, within a farm it is possible to run more than one instance of the Managed Metadata Service. Each instance will have its own configuration, and this configuration, defined at farm level, is represented by an SPServiceApplication-derived object. Although we’ve got an object to configure and manage the service at the form level, we need another object so that we can control the service on individual servers within the farm, and that’s where the SPServiceInstance-derived object comes in. The SPServiceApplication object is a new addition in SharePoint 2010, and as you’ll see later, it provides a much greater degree of flexibility than was available in earlier versions.
The services architecture within SharePoint is very clever and provides a lot of functionality out of the box. The SPServiceApplication object (I’ll use this term to also include any object that’s derived from SPServiceApplication), acts as an endpoint for potentially many server-level instances of a service. As a result, by making use of the SPServiceApplication object for all calls into the service, you can easily implement advanced functionality such as load balancing and fault tolerance. Furthermore, since the configuration of the service is also done at the SPServiceApplication level, providing backup and restore functionality is also relatively straightforward.
You’ve seen how services are configured and managed on the server side within a SharePoint farm. The primary focus of the service object model is on the configuration and management of services as opposed to the actual implementation. When it comes to physically doing whatever the service needs to do many implementations are possible, each appropriate in different situations. For example, the SharePoint Server Search Service makes use of a Windows Service that can be installed on various servers throughout the farm, whereas the Secure Store Service uses a central database to store its data and instead handles requests in real time on the server where they are received. In both of these cases, and for all situations where communication is made with a service that’s managed using the Service Application Framework, communication between client and server occurs via the SPServiceApplication server object.
From a client perspective, because the SPServiceApplication object is well defined, you can create an appropriate matching proxy object. This is represented in the object model by the SPServiceApplicationProxy object, as shown next. This client/server proxy pattern makes it easy to develop code that uses a particular service, since a strongly typed proxy object is readily available that exposes the appropriate functionality. We don’t need to worry about where the service is running, how it’s implemented, or even how the SPServiceApplicationProxy object communicates with the SPServiceApplication object; all we need to know is which methods to call and which parameters to pass in. I’m sure you’ll agree that this is pretty powerful stuff.
So the SPServiceApplicationProxy is our entry point into a service application on the SharePoint platform. This raises the question, How do we pick up a reference to the appropriate proxy object? More than one instance of a service may be running on a farm, so how can we be sure that we have the correct one? The answer is the SPServiceProxy object. As you saw in the discussion of server objects, each service is represented by an SPService object that in turn provides a collection of SPServiceApplication objects that each represent a single instance of a service. The same is also true on the client side: the SPServiceProxy object provides a collection of SPServiceApplicationProxy objects, each representing a proxy for a single instance of a service.
NOTE :I’ve one a lot of talking here about client and server components. It’s important for you to recognize that on many occasions, both client and server are essentially different aspects of the same server farm. Both SPServiceProxy objects and SPService objects can be referenced via the Service and ServiceProxies properties of the SPFarm object.
You’ve seen that the communication mechanism between client and server is abstracted by means of the strongly typed SPServiceApplication and SPServiceApplicationProxy classes. In fact, the SPServiceApplication and SP Service Application Proxy classes are abstract classes—to usethese objects, a concrete implementation must first be created. Out of the box, we can use two default concrete implementations in our custom applications: SPUsageApplicationProxy, which is used to communicate with services such as the Web Analytics Data Processing Service and the SPIisWebServiceApplicationProxy, which is used for all other services. The main difference between these implementations is the underlying communications mechanism used between client and server. The SPIisWeb Service Application Proxy makes use of the Windows Communication Foundation (WCF) for all communications and therefore offers a high level of built-in flexibility. This is why it’s used by almost all of the services available on the SharePoint platform.
NOTEYou can create custom implementations of the SPServiceApplicationProxy and SPServiceApplication. This may be appropriate when communication is being made to a legacy system.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
Share Point 2010 Tutorial
The Microsoft Sharepoint 2010 Platform
Developing With Sharepoint 2010
Presentation Layer Overview
Client Object Model
Infopath Forms Services
Enterprise Content Management
User Interface Customization
Application Services Overview
Service Application Framework
Word Automation Services
Data Access Overview
Linq To Sharepoint And Spmetal
Business Connectivity Services
User Profiles And Social Data
Packaging And Deployment Model
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.