Friday, 23 September 2016

SharePoint App Model Architecture Overview

What is an App?
An app in SharePoint is a solution that connects to a SharePoint server/installation via client-side API’s (JSOM), CSOM or REST.  It can either be embedded into a SharePoint page or can be deployed as a seperate application that leverages OAUTH 2.0 protocol to authenticate and access SharePoint functionality.  They are managed through the “App Management Service” to manage, secure and license apps.  Since the interaction between the App and SharePoint is controlled through OData-compliant REST interface, remote .Net client API’s and OAuth security protocols, an app can be developed in any language with any development tool.  Apps can be developed either through Visual Studio 2012 or by using web-based development environment called Napa Office 365 Development Tools available free of charge.  Apps can be purchased from SharePoint store (a public app marketplace) where users can find free and premium apps that can be installed onto individual sites (or managed through the App catalog).

Advantages of SharePoint Apps
  1. Apps are independent of server deployments and are self-contained.  This eases the job of developers by allowing them to develop and deploy SharePoint app’s without worrying about farm deployments or administrator approvals.
  2. Apps eliminates the hassles to be dealt with Microsoft updates to the underlying SharePoint platform through product updates, service packs etc., as they run as a separate web application (running in an IFrame) well outside the SharePoint server and are never affected because of the changes done to SharePoint.
  3. Since Apps are designed to support multi-tenant installations, a site administration-controlled approach to manage and install functionality eliminates accidental farm-level customization’s that affect other/all numerous distinct tenants that occupy/share the same farm.  In other words, the App architecture is of pivotal use in Office 365 environments where custom solution packages can be deployed and managed independently without affecting other tenants that share the same environment.
  4. Apps supports heterogeneous languages and widens the scope of leveraging any flavor of ASP.Net, Java, Ruby, PHP, CoffeeScript, TypeScript etc.,  as long as they can emit HTML, CSS and Javascript.
How are they different from Farm (or deprecated Sandbox) Solutions?
With the introduction of the new App model in SharePoint 2013, Microsoft has indicated to the developer community to discontinue the use of “Sandbox” solutions and start looking at the direction of “Apps” as the next generation feature aimed at supporting the development and rollout of custom applications targeted against the SharePoint environment.  Having said that, the below table summarizes (at a high level) the difference between a “Full Trust” (or Sandbox) solution against an App based solution :
Farm Based Solution App Based Solution
Rarely developed as standalone applications and are always intended to customize or extend the OOB functionality. Best suited for Standalone applications that are aimed for achieving specific functionalities.
Requires Full Trust and deployed by site administrators, hence not so flexible. Very Flexible as there is no need of full trust and individual developers can deploy updates without need for approval from Farm / Site administrator.  Site administrators are individually notified on updates and they can choose to update on their convenience.
Doesn’t support multi-tenant scenarios as they often impact all web/sites in the environment. Designed for Multi-tenancy.
Installed and Managed only by Farm Administrators. Managed through the App Catalog by IT administration team.
Hosting Options
Since Apps are rendered in the  browser as HTML, CSS and Javascript, they are flexible by supporting three hosting options :
  1. Provider-Hosted App – They support server side coding and needs to be deployed on a separate server (hardware) external to SharePoint (either on-premises or on cloud – as a VM).  In other words, these apps reside on a local IIS server (or on cloud) with support for a wide variety of language choices such as PSP or java.  It uses the OAuth protocols to connect and communicate with the SharePoint environment and leverages SharePoint 2013 REST / OData-based web service to interact with SharePoint.  This type of app can be of choice in scenarios where the app needs to consume SharePoint data (such as list etc.,) and external entities, services that are non-SharePoint in nature.
  2. Azure Auto-Hosted Apps – They are available only for Apps deployed on Office 365 which consist of Windows Azure website, an optional Azure Sql database that are automatically provisioned by Office 365.
  3. SharePoint-Hosted Apps – These types of apps are deployed in SharePoint (as a sub web) and their custom business logic executes within the client browser.  No Server side coding are allowed in this app type of app and they cannot interact with other app as they run in isolation.  They can reuse web elements like lists and files and allow only client-side code for logic and UX.  In other words, its effectively an aspx page full of JavaScript that implements the necessary behavior via client-side script and service calls.  Hence these types of app can either use JSOM or can expose/embed Silverlight client (which internally can use Silverlight object model to access SharePoint data).
Irrespective of how the app is developed and deployed, once installed into the SharePoint instance, the SharePoint app management engine secures the app and underlying platform by enforcing a level of isolation.  Any time an app executes, it actually executes on a unique appdomain with a unique, generated URL.  This is done to prevent deliberate/accidental cross-site scripting attacks and well provide tenant isolation during execution.
App Shapes (i.e., App Rendering options)
SharePoint 2013 allows multiple different ways to interact/access apps.  App shapes define the experience for interacting with and using an app.  There are 3 app shapes available and are list below:
Immersive (or full-page app):  This kind of app offers a fully immersive experience by rendering the app using the entire real estate of the page.  Even though it gives complete control over the app experience, its important to make sure that the app properly links back to the SharePoint site, just so the user experience feels integrated and not lost.  In order to make it possible, SharePoint offers a “Chrome” control that not only lets the app to automatically point back to their SharePoint environment (By providing a link in the top left), but it also provides the same UI look and feel by using the same CSS as in the main SharePoint site.  So at any point when the SharePoint theming changes, it automatically takes effect on the app as well.
App Part:  The second option is to use an app part which is an IFrame hosted in a Web Part that is represented by the ClientWebPart class.  The IFrame can take parameters which can change the user experience of the app part, except that they do not interact in the same way legacy Web Parts do.
Extension app: Extension apps are just custom actions that can direct to a page in your app. This could be a page hosted on SharePoint, or, in the case of a cloud-hosted app, a remotely hosted webpage. You can think of extension apps as entrance points to your app. They don’t provide a user experience in themselves.

Conclusion
With the introduction of the new App model in SharePoint 2013, Microsoft has given more choices for developers such as webparts, Farm-solutions, apps etc., for achieving the necessary customization’s per our requirements. However care needs to be taken to understand the challenges in each of these models before adopting one to ensure smooth integration with SharePoint. 

0 comments:

Post a Comment