Provider-Hosted
The Provider-hosted deployment model is a
richer and more flexible version of the Autohosted deployment model. In
this model, your code runs in a different domain — often framed in the
context of cloud deployment. For example, you can deploy your code to
Windows Azure and then register it to authenticate and integrate with
SharePoint 2013.
NOTE You can also deploy an application to IIS and it could be considered Provider-hosted.
When users access a cloud-hosted application
deployed using the Provider-hosted app model, they are redirected to a
web page that resides in an external domain or server — where the
application code resides. One of the key reasons this is relevant is
that the external server doesn’t necessarily need to be a Windows
Server–based application; you could be running a PHP app on a
Linux/Apache server and still have that web application integrated with
SharePoint.
For example, Figure 13
illustrates an ASP.NET MVC4 web app that is deployed to Windows Azure.
It uses jQuery, MVC, HTML5, and other modern web development techniques
to create rich web applications. It is possible to integrate this app
with SharePoint 2013 — and more. The bigger question is, “How does it
work?”
Similar to the Autohosted model, a special Visual
Studio project template is available for you to use to create,
integrate, and deploy a web application that is married and registered
to SharePoint 2013. At a high level,
though, you need to ensure you have registered the application such that
SharePoint is aware of the app. You do this through the creation of a
client ID (that is, a GUID), which is included in the web.config of the web app and the AppManifest.xml file. To follow is an example of a Provider-hosted AppManifest.xml file.
<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="http://schemas.microsoft.com/sharepoint/2012/app/manifest"
Name="MyFirstProviderHostedApp"
ProductID="{4b640267-b19a-4555-8af4-80a67ecf6f88}"
Version="1.0.0.0"
SharePointMinVersion="15.0.0.0">
<Properties>
<Title>MyFirstProviderHostedApp</Title>
<StartPage>http://mysalesdataapp.azurewebsites.net/?{StandardTokens}
</StartPage>
</Properties>
<AppPrincipal>
<RemoteWebApplication ClientId="9F579786-BD34-4736-8E30-97D6AF648E7B" />
</AppPrincipal>
<AppPermissionRequests><AppPermissionRequest
Scope="http://sharepoint/content/sitecollection/web" Right="Read" /></AppPermissionRequests></App>
You also need to ensure that the application is registered and secured using the TokenHelper
class, much like you did with the Autohosted app. You might also need
to register and associate a certificate with the app and your developer
site given that SharePoint Online is HTTPS. After you’ve created and are
hosting the Windows Azure (or another type of Web app) in your hosted
domain, you can then integrate it with SharePoint. The Windows Azure application is now fully
integrated and loading from a separate domain — but looks and feels
like a SharePoint app and is registered with SharePoint.
The Provider-hosted model is the most flexible of
the three new types of deployment models. The key item to remember with
the Provider-hosted deployment model is that you own the management of
that code in a separate domain — this would include managing the billing
of apps, data, or services deployed to Windows Azure in a
Provider-hosted app. (The Autohosted model is managed automatically by
SharePoint with one bill through your Online Services subscription.)
This also means you own updating, testing, integrating, and so on for
this separately hosted application. With that management overhead,
though, comes quite a bit of power to integrate an array of different
types of web applications and technologies, making it necessary to have
all three options available from which to choose.
