Service Applications in SharePoint 2013
While SharePoint Server 2013 Preview provides a service application architecture consistent with SharePoint Server 2010, its new services are designed to maximize your investment and make information available to more people, in more formats, with more efficiency. In Microsoft SharePoint 2013 Preview, the service architecture model provides a framework in which you deploy and manage services across a farm or across multiple farms. A service application represents a deployed instance of a service that you can configure and manage centrally and that many web applications can consume. You can configure individual services independently and third-party companies can add services to the platform. Please see below for a list of service applications, new Service Applications in 2013 are highlighted in RED Rectangles.
As seen above, some new service applications are available in SharePoint 2013 and there are huge improvements in existing ones. For example, Office Web Apps is no longer a service application, it is separated as own product (so it can be used in Exchange 2013 and Lync 2013 and can be patched separately). Also, Web Analytics is no longer service application (it is incorporated into search service application). Deployed services are called as service applications.
Cross Farm Services in SharePoint 2013:
You can share some services across server farms. Services that support sharing across farms can be run in a central farm and consumed from other farms in the environment. For services to work in a consuming farm we first need to enable publishing within the service application on the master farm and then consume it on the child farm by creating a service end point or a service application connection proxy. Sharing across farms is currently supported only in below services. Some of which are not recommended in WAN environments because of latency issues.
- Machine Translation Service (highly recommended in WAN Environments)
- Managed Metadata Service (highly recommended in WAN Environments)
- Search (highly recommended in WAN Environments)
Business Data Connectivity (moderately recommended in WAN, depending on situation)
- Business Data Connectivity can be used in WAN depending upon the location of Line of Business Application and how the connectivity is actually done (performance implication).
Secure Store Service(Not recommended in WAN Environments)
- Secure Store Service actually works in a WAN environment, but is not recommended as it could have performance impact of the service across WAN.
User Profile Service (Not recommended in WAN Environments)
- UPS requires direct database access, which means there are some operations which do not follow service application proxy (this is to improve performance). If you still need to use UPS, then there is UPRE (User Profile Replication Engine – could be available as a separate download). UPRE could be utilized to replicate user profile entities across farms.
As seen above, each web application can be configured to use services from different farms. For example, you can share the User Profile Service across web applications in several server farms while using some services, such as the Excel service, locally.
In large environments, computing-intensive services can be run in a central farm to minimize administration overhead and to scale out easily and efficiently as requirements grow.
PS: Remote farms do not need direct permissions to the parent farm’s configuration or services databases.
How are Service applications deployed?
Service applications can be deployed using Initial Configuration wizard, Central Admin console and Windows PowerShell (Recommended). Deploying service application from PowerShell provides you with a flexibility to provide process isolation by deploying them in specific application pools. You can apply different service accounts to service application. You can assign database names and implement naming convention. You can implement custom settings when the service application is deployed.