Home > Blogs > Eric Shupps | The SharePoint Cowboy > Posts > Introducing the SharePoint 2013 Application Model
Eric Shupps eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational intelligence solutions for Microsoft SharePoint. Eric Shupps eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. he is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.sharepointcowboy.com. Presentations by Eric Shupps eshupps The SharePoint Cowboy Webinar - Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure featuring Eric Shupps Who are you and what do you want - Working with OAuth in SharePoint 2013 SharePoint is Talking Are You Listening? Eric Shupps SharePoint 2013 Performance Enhancements Taking Advantage of the SharePoint 2013 REST API Eric Shupps on Improving Performance with New Features in SharePoint 2013 SharePoint 2013 New and Improved Migrating Legacy On Premise Solutions to SharePoint Online and Windows Azure Eric Shupps Presents SharePoint 2013 Real World Help Desk App End to End Windows Azure Apps for SharePoint 2013 Eric Shupps Demonstrates Customizing the Visual Studio 2010 SharePoint Deployment Process Introduction to SharePoint Development SharePoint 2010 Unit and Integration Testing with Eric Shupps Building Enterprise Records Management Solutions for SharePoint 2010 Taming Information Chaos in SharePoint 2010 SharePoint 2010 Performance and Capacity Planning Best Practices Building Dynamic Applications with the SharePoint Client Object Model Articles by Eric Shupps eshupps The SharePoint Cowboy Eric Shupps' Ten Steps to Optimize SharePoint Performance Webcasts by Eric Shupps eshupps The SharePoint Cowboy Secrets of SharePoint Part 5: Configuring Microsoft Office SharePoint Server 2007 for Optimal Performance Creating End User SharePoint Solutions for Performance and Scalability SharePoint 2010 Performance Enhancements for Administrators by Eric Shupps Microsoft SharePoint Server 2010 for the ASP.NET Developer Eric Shupps on Following Best Practices and Avoiding Common Errors with Microsoft Office SharePoint Server 2007 Development Eric Shupps - SharePoint Performance and Capacity Planning Essentials Troubleshooting Common Performance Problems in SharePoint 2010 Videos by Eric Shupps eshupps The SharePoint Cowboy Channel 9 Interview with Eric Shupps SharePoint TechTalk with Eric Shupps - Different Views on Social Computing SharePoint Post-Deployment Planning and Management with Eric Shupps SmartTrack for SharePoint Feature Overview SmartTrack for SharePoint Podcasts by Eric Shupps eshupps The SharePoint Cowboy SharePoint Pod Show - Design for Performance (Eric Shupps) SharePoint Pod Show - Test Driven Development with Andrew Woodward and Eric Shupps eshupps The SharePoint Cowboy Run As Radio - Eric Shupps Improves SharePoint Performance
SmartTrack for SharePoint Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave

​The SharePoint Cowboy

photo of  Eric Shupps
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA
Eric Shupps and Eric Alan Shupps with BinaryWave the BinaryWave Inc in BinaryWave Incorporated around SmartTrack beside SharePoint Monitoring through SharePoint alongside SharePoint Monitoring visiting @eshupps via eshupps near SharePoint performance and SharePoint management. The SharePoint cowboy eshupps BinaryWave and more on Operational Intelligence via Eric Alan Shupps SharePoint blog. SharePoint monitoring is a hot topic along with SharePoint Performance Measurement and SharePoint tips and tricks from Eric Shupps for SmartTrack. Another Eric Shupps on Technology and Eric Shupps on SharePoint with a new SharePoint Post from Eric Shupps. New BinaryWave post through BinaryWave Inc. and with another SharePoint blog we get to Eric Alan Shupps Blog about SharePoint development. That's Eric Shupps - BinaryWave or Eric Alan Shupps Fort Worth Grapevine Texas Dallas of BinaryWave talking about BinaryWave Operational Intelligence at the SharePoint Cowboy blog and on twitter as @eshupps. Of course SharePoint Administration is on topic for eshupps and another great post from Eric Shupps regarding BinaryWave SharePoint and SharePoint Maintenance.
August 12
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.


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.


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


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.


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


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.


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.


Re: Introducing the SharePoint 2013 Application Model

Thanks for this excellent post, Eric...The ground is shifting for SP developers, consultants and service providers...The issue relating to perennial shortage of SP resources may possibly get resolved with the new model being less asp.net dependent...The good news is customers would benefit from many of these changes in SP2013...
 on 8/13/2012 11:38 AM

Re: Introducing the SharePoint 2013 Application Model

Thanks for some great information. Although many of the technical aspects were too much for me, it was very helpful. From a business side, this seems like a great improvement. The challenge has always been integration of Sharepoint for regular users into their regular workflow. These changes seem to help this, by allowing more tools to be closely integrated, or at least in the same spot in Sharepoint, which they use as their core toolset. Bottom line for business is greater utilization of an existing investment and broader acceptance by the user base. All good from my perspective.
 on 8/17/2012 12:41 PM

super explanation

Nice write up and full details. I have inspired from you and written a post on Apps and it found here:
 on 9/26/2012 12:31 PM

Good article - many reasons no to adapt it ;)

Foremost and worst:

I hate IFRAMEs (really problematic as a user interface, need to be locked to some space, which either is too much or too little - yack - the scrollbars).

I see that this may be a solution for some specific "alien" system connection, but having most of your site built with iframes from different sources is much worse than having site to know to knees every now and then ;)
 on 10/31/2012 5:26 AM

Even a year later...

Even a year later this article has been useful to me.  I'm not a developer but my team is currently in the process of defining the approach we will take to develop and deploy SharePoint custom applications in the future. 

Thanks you.
 on 8/23/2013 9:26 AM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.


Body *

Comment Date *

Select a date from the calendar.
Enter the current date to prevent automated spambot comments.

Spam Prevention *

How many letters, not including spaces, does it take to spell "SharePoint Cowboy"?


photo of Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave Eric Shupps
611 S. Main St., Suite 400
Grapevine , TX , 76051 USA

Eric Shupps Eric Alan Shupps eshupps @eshupps SharePoint Cowboy BinaryWave 

Eric Shupps LinkedIn Eric Shupps Twitter Eric Shupps Facebook Eric Shupps Google+



BinaryWave Eric Shupps eshupps The SharePoint Cowboy SharePoint monitoring SharePoint monitoring tool SharePoint metrics SharePoint administratrion SharePoint monitoring best practices SharePoint management SharePoint management tool SharePoint operations SharePoint operationsmanagement SharePoint administration SharePoint administration tool SharePoint SLA SharePoint service level agreement SharePoint operational intelligence SharePoint performance SharePoint performance monitoring SharePoint analytics SharePoint real-time SharePoint intelligence SharePoint ITIL SharePoint service operations SharePoint uptime SharePoint alerts SharePoint health SharePoint tools SharePoint metrics SharePoint diagnostics SharePoint SmartTrack SmartTrack Operational Intelligence

Copyright © 2013 BinaryWave, Inc. All rights reserved.
This site is brought to you by BinaryWave in cooperation with Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy. We hope you enjoy the SharePoint-related content on topics such as performance, monitoring, administration, operations, support, business intelligence and more for SharePoint 2010, SharePoint 2013 and Office 365 created by Eric Shupps The SharePoint Cowboy. We also hope you will visit our product pages to learn more about SmartTrack, Operational Analytics for SharePoint, SharePoint monitoring, and SharePoint administration, while also discovering great offers from our partners. Please visit the blog of Eric Alan Shupps, Twitter handle @eshupps, for more information on application development, the SharePoint community, SharePoint performance, and general technology topics. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy is the founder and President of BinaryWave, a leading provider of operational support solutions for SharePoint. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has worked with SharePoint Products and Technologies since 2001 as a consultant, administrator, architect, developer and trainer. He is an advisory committee member of the Dallas/Ft. Worth SharePoint Community group and participating member of user groups throughout the United Kingdom. Eric Shupps Eric Alan Shupps eshupps @eshupps The SharePoint Cowboy has authored numerous articles on SharePoint, speaks at user group meetings and conferences around the world, and publishes a popular SharePoint blog at http://www.binarywave.com/blogs/eshupps.