2. Connecting Across Farms
Once you understand the service
applications and all their proxies in your farm, the next logical step
is to add more connections. Some service applications are capable of
being published and then consumed across different SharePoint farms.
Even more impressive is the fact that none of the service applications
except the User Profile service application require the two SharePoint
farms to be in trusted active directory domains. In fact, a SharePoint
2010 farm can even consume services from a SharePoint 2013 farm, though
this capability is limited to the service applications and features
available in SharePoint 2010, of course. For example, SharePoint 2010
can’t consume the App Management service from SharePoint 2013.
Before you can publish or consume the service applications between two farms, you have to establish a farm trust,
which is done by using the SharePoint Management Shell to create and
register certificates between the two farms.
After the farm trust is configured, you can
access the publishing farm and select the service application you want
to publish. Once it is published, you get a URL for accessing the
published service.
From the consuming farm, you simply connect to
the published service by providing the URL. Then the connected service
application can be added to a service application group, and it will
provide services just as if the service application were part of the
farm. Figure 5 shows an example of four farms at work.
Farm 1 introduces a concept that hasn’t been discussed yet: the enterprise services farm.
The enterprise services farm highlights the advantage of the service
application architecture over the monolithic SSP model. Typically used
only in large companies, this type of farm is created and maintained
exclusively to provide services to other SharePoint farms throughout
the organization. This way, the services farm can be optimized for
hosting services and can be maintained in the same manner. For example,
a Search index might contain several million items, requiring several
days to do a full crawl, and hours to do an incremental crawl. In order
to do this efficiently, you need to optimize your hardware for Search.
If you have three SharePoint farms and each maintains its own Search
service application, it would be very expensive to do a lot of
repetitive crawling of content. Instead, a much better solution would
be to maintain the index in one farm and just consume the service from
the other farms.
Farm 2 is a simple farm for publishing content,
maybe hosting just informational websites or similar content. In this
farm, the demand for service applications is low, and all the service
applications it does require are provided by the enterprise farm.
Therefore, this farm actually has no local service applications and is
just optimized for displaying SharePoint content.
Farm 3 is a collaboration farm, and a busy place.
This farm has demands for all types of service applications — some are
consumed from farm 1, and others are hosted locally. The locally hosted
service applications are those not capable of being published across
farms, so they must reside in the farm where they are needed. Note that
the Managed Metadata service application from farm 4 is being consumed.
Other than that, there is nothing special about this scenario other
than the flexibility of consuming service applications from multiple
farms.
Farm 4 is very similar to the collaboration farm
in terms of purpose. It is hosting its own web applications and
consuming local and remote service applications. Additionally, it has
published the Managed Metadata service application for consumption by
farm 3. Although all three farms are using the default group in this
example, this isn’t a requirement. You very well could have configured
the [custom] group in any of the farms to consume the cross-farm
service applications.
Service Applications As a Framework
You have probably noticed by
now that all the service applications act slightly different. This is
because service applications are really a collection of individual
services built to plug into a framework. The advantage of this
framework is that anyone can plug into it. Third-party vendors and
developers can use it to add their functionality to SharePoint 2013
just as they did with SharePoint 2010; but instead of needing to create
a custom third-party application to administer their added SharePoint
functionality, developers just plug right into Central Administration,
providing administrators with a consistent experience. From an
administrator’s perspective, there is no difference between these
service applications and one provided out of the box with SharePoint
2013.
