Introducing the SharePoint 2013 Application Model

SharePoint 2013 introduces a new mechanism for custom code deployment known as “Apps”. Mostly targeted at online solutions, the purpose of the App model is to overcome the severe limitations of the 2010 isolated execution model (also known as the “Sandbox”) and provide developers with a way to run rich web applications in SharePoint without negatively impacting the underlying infrastructure. Much has already been made about this new model and a lot more will be written about it over the coming year as 2013 gets released and adoption spreads. Before we get too far off the beaten track into a debate about whether or not developers should or should not be using the new App model, it’s helpful to first understand why Microsoft chose this path and what it really means for both new application developers coming onto the platform and existing developers who need to support the next release.

Background

At its core, SharePoint has always been an application platform. While it has been possible since 2001 to create custom components for SharePoint (does anyone even remember digital dashboards?), it wasn’t until the 2003 release of Windows SharePoint Services that developers really began to take notice of the capabilities that the platform offered. In those days, custom code was pretty much confined to web parts, with some limited interaction with deeper system layers. Due to the complexities of code deployment and lifecycle management, mostly due to lack of good tooling, custom production code in SharePoint wasn’t all that common. Nevertheless, it was at this point that some real weaknesses began to appear in the structure, namely that one bit of bad code could effectively bring the system to a standstill. In most cases, this was relegated to a single page being inoperable due to a misbehaving web part but in some instances things like malfunctioning event receivers could wreak havoc throughout an entire deployment.

The release of 2007 changed everything. Suddenly, developers were coming onto the platform in droves. Although tooling was still lagging far behind other Microsoft platforms (especially ASP.NET) there were enough third-party solutions and guidance from the greater community to get people going down the right path rather quickly. SharePoint rapidly grew from a niche Intranet application and started to take on the aspects of the rich middle-tier platform it would eventually become, with a deep set of API’s that offered developers access to nearly the entire application stack. It is also when things began to go horribly wrong for many customers. In some ways, Microsoft was a victim of their own success – people were adopting the platform far faster than the company ever imagined and the support systems, in terms of training, documentation, tooling, and especially infrastructure, simply weren’t in place to accommodate the massive amount of custom development taking place. Consequently, the 2007 release, while it drove adoption to stratospheric levels, also resulted in a tsunami of support nightmares as custom code ran amok in a multitude of deployments.

For the 2010 release, Microsoft was faced with a difficult paradox. On the one hand, the capabilities of SharePoint as a development platform made it irresistibly “sticky” – the more code that went into SharePoint the more it became a critical part of technology infrastructure and business operations. On the other hand, IT departments were being overwhelmed by the negative impacts of badly written and poorly performing code on their (often very expensive) SharePoint farms. This led to what seemed an acceptable compromise – execution of code in an isolated “sandbox” process with built-in monitoring and administrative controls. As it turned out, the Sandbox was really only beneficial to administrators – the amount of restrictions required to ensure limited impact on the farm infrastructure meant that there was very little functionality available to developers from the core API’s. To bridge this gap, Microsoft also introduced the Client Object Model – a set of API’s designed to supplant the existing web services and offer remote application integration. But this, too, was overly restrictive and failed to provide sufficient depth for serious application development.

So how has Microsoft addressed these issues in SharePoint 2013? The Sandbox taught us that platform integrity is of supreme importance (which we should have realized all along) but also that developers cannot be sidelined or adoption will wane. The new approach is to give developers the capability to create whatever applications they might dream up but they will have to run outside of the core SharePoint framework. Similar to the application plug-in model used by sites like Facebook, the SharePoint 2013 model allows the execution of full-fledged applications (in whatever language the developer prefers) while sharing some portions of the SharePoint UI. It also greatly expands the capabilities of the client object model and REST-based services, giving programmers a way to interact with SharePoint data remotely. Microsoft is obviously hoping that this will satisfy both constituencies and lead to renewed focus around creating rich applications that tie into SharePoint.

Architecture

In order to understand the application model architecture, it is important to first get a grasp on the new terminology changes. In 2013, just about everything is called an app – lists, libraries, templates, custom components, and so on. The App Model, on the other hand, defines a particular type of deployment. There are three primary ways in which code can be deployed on-premise in 2013 – traditional full trust, the Sandbox, or the App Model. In the cloud, the full trust model is still off limits – only the Sandbox and App Model can be used. It is important to note that the Sandbox really only exists for backwards compatibility – it should not be considered as a valid deployment type for new applications.

Figure 1 – SharePoint 2013 Custom Code Deployment Types

Apps1

The Full Trust model will continue to offer the greatest API depth and flexibility for on-premise applications. Essentially, nothing has really changed in 2013 for these types of solutions; however, customers should carefully consider whether or not their solutions really need the extensive platform integration of a Full Trust solution running inside of SharePoint or if an app running on a remote web server and only sharing the basic SharePoint chrome is more applicable. This is an important decision point. In the past, customers who adopted SharePoint as their intranet platform had to incur the costs of rewriting and migrating existing applications to run on the platform. This cost could be quite high, especially if they had no in-house development expertise or existing staff did not have any .NET or SharePoint training. There simply wasn’t any good way to preserve existing knowledge and code while running applications side-by-side with SharePoint that offered a decent level of interoperability.

This has completely changed in 2013. The ability to run an application within SharePoint on a web server somewhere in the enterprise (or even hosted externally), along with the increased levels of integration offered by the expanding client object model and REST services, makes the line of demarcation less clear. A primarily Java development shop can quite easily adopt SharePoint 2013 alongside their existing applications, adding the ability to retrieve data from SharePoint lists and libraries, perform searches, and query user profiles all via Javascript and asynchronous service calls. Likewise, an organization with a multitude of .NET web applications may now consider extending the lifecycle of those applications, running them alongside SharePoint without having to convert them to internal SharePoint apps.

The primary decision point for on-premise applications will be the capabilities of the client object model and REST services. Although greatly enhanced from 2010, they still only offer a subset of the full server object model functionality. Many higher-level API’s, especially those related to enterprise features, are simply not available to remote applications. And, perhaps even more importantly in the long run, app deployment on-premise is not a streamlined process. The pure simplicity of WSP deployment, even in a restricted Sandbox environment, has been supplanted by registrations, permission grants, catalogs, certificate authorization, metadata documents, app principals and token services. For non-Windows authorization methods, such as OAuth, there will also be Azure Connect to deal with and two-way authorization and data exchange through the firewall. Whether or not these are acceptable trade-offs for guaranteed operational stability will have to be determined by each individual customer.

For those who choose to adopt SharePoint online, there really isn’t much of a choice – the app model is how cloud functionality will be extended going forward. The same considerations for client object model and REST functionality apply but at least the OAuth and ACS pieces are already taken care of in Office 365. If CSOM + REST are insufficient then the customer will need to consider an on-prem deployment with full trust solutions or possibly even a hybrid implementation with some sites on O365 and some on-premise. The good news is that it’s fairly simple to preserve an app across the various deployment methods once it has been built. Solutions aren’t 100% portable but they come pretty close and can even be deployed to Azure with a little additional effort.

Hosting

Apps for SharePoint 2013 can be deployed in three hosting models – no hosting (traditional SharePoint artifacts such as list templates, content types and web templates), SharePoint-hosted and provider-hosted. SharePoint-hosted applications run inside of SharePoint with actual functionality provided by an external resource and surfaced within an IFRAME element – they are essentially wrappers for remote web applications. They come in two flavors – app webs and app parts. An app web is a special subweb which provides the chrome and contextual elements, including a module-deployed page which contains the IFRAME and dependent resources, such as javascript files and stylesheets. Although it exists in a subweb, permissions are provided by the parent web and context is passed through to the parent for purposes of client object model calls to site resources. An app part, also known as a Client Web Part, is simply a web part which exposes the remote resource within an IFRAME and can be added to any page in the web where it has been activated.

Figure 2 – SharePoint 2013 App Hosting

Application Model

Provider-hosted apps are standalone applications which run completely outside of SharePoint. When a user clicks on the application icon, they are redirected to the destination web site. A set of Javascript libraries are available to enable retrieval and display of a very basic set of chrome elements from the referring SharePoint site (including the base stylesheet) to preserve the user experience. Developers must craft provider-hosted application in a specific manner to exchange authorization information with SharePoint and permit callbacks to site collection and web resources. They also need to be careful how page transfers are handled in order to preserve context and become comfortable with asynchronous REST operations. These types of applications aren’t SharePoint apps in the traditional sense nor do they need to run on the Microsoft technology stack (although managing the authorization process is very much simplified in ASP.NET applications via some C#/VB.NET helper utilities provided in the development sample toolkits). They are simply web applications which look a bit like the source site and exhibit some level of pass-through authorization (although it is important to point out that OAuth is not the same as authentication – cloud apps need to either handle data security in code based on the tokens provided by SharePoint or force users to authenticate separately).

Which type of hosting to choose depends upon the purpose of the application, the type of deployment model and the authentication/authorization requirements. If the solution contains only classic SharePoint elements then no hosting is necessary and the app can be deployed directly in the target web. If the app has a simple, compact user interface and really only needs to retrieve data from an external resource (much the same as a classic web part) then an app part may be most applicable. A more complex, full-screen UI that can be contained within a single page and exchanges data with a remote resource may be a good fit for an app web. A full-on web application that needs maximum screen real estate and performs extensive data operations outside of SharePoint, or which has to support extensive multi-tenancy, is better suited to a provider-hosted app. There are, of course, many cases where the lines may be blurred or any of the hosting models will work, in which case the customer will need to dig deeper into the feature requirements to make a decision. An overriding concern will be authorization – if the app uses an authentication method other than Windows and is on-premise, it will require an internal OAuth implementation, which has a number of ramifications. This consideration alone may dictate the hosting model in many organizations.

Implications

So what does all this mean for developers moving to the SharePoint 2013 platform? For starters, it means a lot more thought will need to be put into how an application is constructed and deployed. The app model is best suited to HTML + Javascript solutions – traditional code-behind ASP.NET and SharePoint developers will have to enhance their skill set in order to adapt. There will be a lot of discussion around the high trust model for on-premise app deployment as it is rather complex and doesn’t scale well in environments with a large number of web applications and site collections. Internal OAuth will also be a challenge, especially with security concerns over two-way external communications, and pass-through authentication to forms-based apps will require some additional coding.

The conversation will also continue around the capabilities of the client object model. It is more extensive than in 2010 but by no means does it offer parity with the server object model. The REST services, while much improved, are also not on par with legacy web services and they don’t offer a good solution for large data sets. And the implications of all the additional web traffic, much of it large blocks of JSON and XML, can’t be overlooked from an infrastructure perspective. As with the Sandbox, API limitations may cause some reluctance to adopt the new model but it will likely be the additional overhead of configuring and deploying apps internally that will push on-premise customers back to full trust solutions despite the platform stability concerns.

With regards to cloud solutions, it really comes down to a question of delivering a full or partial user interface, along with considerations of data access and transport. App parts will likely be popular where standalone web parts have traditionally been applicable or where external data was required that the Sandbox wouldn’t allow. The app web or remote web picture is less clear. There are cases for both, although the separate subweb concept will take some getting used to and just may not work for certain solutions. Full remote webs will require a complete ground-up rewrite to handle token authorization, chrome display and data transfer – it may be more applicable to retrofit existing apps for partial rendering in app webs and write new applications as remote webs.

What is certain is that SharePoint solution design and deployment has gotten a bit more complex in 2013. While we have gained some clarity around the online model we’ve also introduced some confusion for on-premise customers. Gone are the restrictions and limitations of the Sandbox, with its inscrutable points system and heavy-handed penalties for excessive resource consumption, replaced by a set of options that essentially drive customers to one extreme or the other. In 2013, code is either on the server or it’s not and there isn’t much middle ground. Only time will tell which path developers adopt and whether or not the app model strategy will pay off in terms of increased adoption and solution availability. One big advantage should be the ease with which developers with no previous SharePoint experience can adapt their solutions to work in a SharePoint context – that alone could potentially drive adoption in ways the Sandbox never could. The real question will be if, and to what extent, existing SharePoint developers embrace the new model. As with anything SharePoint, the answer is most likely “it depends”, although what, exactly, it depends upon will likely be quite different this time around.

This article by Eric Shupps was first published on SharePoint Cowboy . Check out our resource centre for more SharePoint content from Eric and other SharePoint specialists!

Share this on...

Rate this Post:

Share: