SharePoint 2013 Cloud Hosted Apps

Sometimes the client-side architecture of a SharePoint-Hosted App cannot satisfy our requirements. For example, we may want to query a server-side database or share a component among multiple users. In such scenarios, you can build a Cloud-Hosted App for SharePoint 2013. Cloud-Hosted Apps are also referred to as server-side apps.

Client-side Apps are restricted in their architecture because you can only include client-side code, written in JavaScript, and run in the browser. Because the CSOM has been greatly extended in SharePoint 2013 you will find that these apps are powerful. However, sometimes you require server-side components in apps. In such situations, you must write a Cloud-Hosted App. Also known as server-side apps, Cloud-Hosted SharePoint 2013 Apps include components hosted outside your SharePoint farm. Such components can be hosted on IIS servers, Apache servers, or cloud services such as Windows Azure.

Advantages and Disadvantages of Server-Side Apps

By building a server-side app instead of a client-side app you gain the following advantages:

A more flexible architecture. Because client-side apps are stored entirely with a dedicated sub-web, and can contain only client-side code, you are restricted to a single architecture. In server-side apps, you can use ASP.NET, PHP or some other server-side technology to host the code. You can also use a data-storage technology such as SQL Azure to ensure data-security.
An application that is always running. In client-side apps, you code can only run when a user is viewing a SharePoint page in the browser. In server-side apps, you can schedule code to run at any time, or to run in response to user input.
A familiar language. Client-side apps are written only in JavaScript. If you are unfamiliar with this language or if you prefer a strongly-typed language with complete IntelliSense support, you may prefer to write a server-side app.

However, the following could be considered drawbacks of server-side apps:

Extra infrastructure. You must provide a cloud platform or web server to host server-side components. Web servers require maintenance and cloud platforms incur monthly subscription fees.
Security Policies. Some companies have security policies that prevent them hosting business-critical data in the cloud. This is changing as cloud technologies prove they are secure but such policies may currently present a problem.

Architecture of Cloud hosted apps

A Cloud-Hosted App in SharePoint 2013 is an App that uses server-side components. In SharePoint, the app is presented either within a separate web page or else in an IFrame within an existing SharePoint page. No code runs within the SharePoint farm.

Choosing a Server-Side Technology

You have a wide choice of technologies to host the server-side components of your app and you are not restricted to Microsoft technologies.

Using Cloud Platforms

If you choose to host your server-side components in the cloud, you have the advantage that they are easily available to all SharePoint farms anywhere in the world, as long as there is a connection n to the Internet. If you choose to use Windows Azure, you can create Web Services or Windows Communication Foundation (WCF) services that the SharePoint page calls. You can encapsulate your business logic as .NET framework classes and use SQL Azure as a database layer to persist data. Alternatively you can choose to host your server-side components in a non-Microsoft cloud platform.

Using On-Premise Web Servers

Web services need not be hosted in the cloud. Sometimes you can choose instead to host your server-side components on a web server that runs and is maintained on your own premises. Some organizations use this architecture because their security policy does not permit data storage off-site. You might also choose this architecture because you have a server with spare capacity so you can host web services without incurring the monthly fees associated with cloud services. However, you must consider that on-premise web servers are restricted to one organization: If you are writing an app that will be added to the App Marketplace and sold to multiple tenants you must a have cloud platform instead. You can use the Microsoft Web platform for on-premise server-side apps. Internet Information Server (IIS) can host your Web or WCF services, SQL Server can store data, and you can write services in ASP.NET using VB, C# or other .NET languages. Again, you can choose non-Microsoft technologies. For example, the LAMP platform (Linux, Apache, MySQL, and PHP) is a popular alternative.

Ensuring Isolation

When you write an app that you will sell to multiple customers, you need to use the cloud to host server-side components and you must ensure that each customer's data is isolated from all the others. For example, if you publish a corporate accounting app in the SharePoint 2013 Marketplace you must guarantee that two of your customers cannot, by accident or malicious attack, view each other's financial data. There are two approaches to ensure this isolation:

Auto-Provisioned Apps: If you host your app in Windows Azure, you can make it an Auto-Provisioned App. In this case, whenever a customer installs your app, Windows Azure will automatically provision a new instance of it in the cloud. All processes, memory and data in these separate instances are automatically isolated.
Developer-Hosted Apps: Sometimes you may have more complex data isolation requirements. For example you may have some sensitive data that must be isolated per-customer and other data, such as currency exchange rates for example, that should be shared among all your customers. For such situations, you can build a Developer-Hosted App. In such an app, the developer is entirely responsible for ensuring isolation. This isolation model is more flexible but takes more work to create. Any app that is not hosted in Azure is a Developer-Hosted App.

Communicating with SharePoint

In a server-hosted app, all custom code runs outside the SharePoint farm. If you want to use or display SharePoint data in your app, you must write code that first authenticates with SharePoint and then accesses a SharePoint list, library, or other functionality such as search.

Authenticating by Using OAuth

OAuth is an internationally recognized open standard for authentication that is governed by the Internet Engineering Task Force. It is widely used by web sites such as Twitter, Facebook, and Hotmail to authenticate access to resources. For example, a mobile phone app could authenticate with Facebook through OAuth to display a user's photo albums. Importantly, the OAuth client does not have access to the user's credentials but only OAuth tokens. In the preceding example, the mobile phone app does not store the username and password but only the token that Facebook issues on first use. The token can specify that the app can access limited resources, such as only photo albums. OAuth tokens can also specify access for a limited time period, such as the next 3 minutes. SharePoint 2013 supports OAuth for authentication and this is the mechanism that server-side components in Cloud-Hosted apps for SharePoint use to authenticate before they access SharePoint data.

Accessing Data by Using OData

The Open Data Protocol, also known as OData, is a Web protocol that you can use to query and update data through HTTP requests. In OData, results are returned in the form of Atom or JSON format messages. These two standard formats for data exchanges can be easily parsed in JavaScript and .NET languages. In SharePoint 2013, you can access any content, such as items in a SharePoint list or library, by making OData requests. This is the way you access SharePoint data from a server-side app running outside the SharePoint farm. One important consequence of this approach for developers is that because OData works through HTTP, you can use Internet Explorer to examine the data within SharePoint. By typing specific URLs into the Internet Explorer address bar, you can query specific content and examine the XML that OData returns.This makes it much easier to write parsing code in your server-side App.