This article provides an architectural perspective on the new SharePoint App model and thoughts on how enterprises using SharePoint should prepare for it.

A Brief History of Personal Applications

In its youth, Microsoft was true to its name as a supplier of microcomputer software. In the early days, microcomputer operating systems (such as MS-DOS) were intended for a single user running one application at a time. There were no limits on what an application could do; it could take over any part of the system and could interact with other applications as it wished. There were no rules in the playground.

 
Figure 1 – Classic Microcomputer Application Model

This model persisted even as users began to run multiple programs in window-based systems such as Microsoft Windows (from Windows 1.0 through Windows ME) and Apple’s classic Mac OS (through OS 9). Any application could easily destabilize the system, and in practice, the more applications that were installed the less stable the computer became. Applications would often interfere with one another, or inadvertently break parts of the operating system, creating endless headaches for users and the people who support them.

Meanwhile, multi-user operating systems such as Unix or Digital’s MVS provided a level of application isolation to protect the environment from rogue or buggy applications (and, let’s face it, all applications have bugs.) This is shown in Figure 2. This model solidifies the line between the applications and the runtime environment, and forces applications to access resources using an Application Programming Interface or API.

Figure 2 - Classic Multiprogramming Application Model

Eventually, personal operating systems moved to this model, however it was a painful and lengthy experience. Microsoft graduated to this model with Windows NT 3.1, having hired Dave Cutler, designer of Digitial’s VMS system, to design it. Apple followed suit with OS X, which is based on Bell Labs’ UNIX multiprogramming OS. Application developers complained loudly – suddenly there were rules in the playground, and the OS enforced them strictly. Any application which depended on breaking these rules had to be rewritten, and there were compatibility challenges for a while until everybody got used to the new way of doing things.

This application isolation isn’t perfect, however. Although applications can’t take over the operating system or reach into each other’s memory, for example, they can still render the system unstable, usually by updating content or data that they shouldn’t, or by leaving behind content even after they’ve been removed. The mobile phone industry took this into account and built in even more robust app isolation into systems such as iOS, Android, and Windows Mobile. (These same principles are also present in the new Windows 8 App model, which we’ve done a lot of work with at BlueMetal Architects). We could call these modern applications, and they share certain attributes:

• Complete isolation of applications so they can’t overstep their bounds or destabilize the system
• Central distribution of applications so we can vet their quality (and, in some cases, boost profits by limiting distribution channels to a single “app store”)
• Users and system administrators can effectively control what applications can do when they’re installed
• The system can completely clean up after applications when they’re removed, rather than leaving this up the application developer, to ensure they don’t leave data or configuration changes behind

These capabilities result in a new level of reliability and simplicity. Applications rarely interact badly or destabilize the system, and when a user wants an application to go away, it doesn’t leave a mess behind.

Microsoft’s Productivity Suite

“It’s déjà vu all over again”
                - Yogi Berra

Just as Microsoft took the industry by storm in the personal OS market in the 1990’s, it’s taken over the productivity and collaboration software, and remains a strong market leader. Microsoft Office and SharePoint are all but ubiquitous, and so far, would-be competitors such as Google and Atlassian have had only limited success in dethroning them. However when it comes to extending Office and SharePoint, the application model has suffered the same problems as we saw in MS-DOS. Applications aren’t very well isolated; we’re back to the model shown in Figure 1. They can easily break the environment that hosts them, and can interfere with one another in unexpected ways.

This has made many organizations reticent to even install these applications. An application or SharePoint “solution” can pretty much do as it pleases, and developers need to carefully follow best practices in order to avoid destabilizing the system. And anyone who’s ever had Microsoft Outlook crash complaining about an “add-in” can attest to the fact that this problem extends to the client side of the Office product line. Microsoft attempted to address this by adding “sandboxed solutions” to the playground, but it had a number of problems which limited its adoption (including severely limited functionality and scalability issues.)

With the advent of Office and SharePoint 2013, Microsoft introduced a new app model to finally address these issues by applying the same principles used in mobile apps. This is a 3^rd app model to go with its Windows Phone and Windows 8 apps. Adoption has been slow, and it will probably take years and multiple iterations of both applications and the platform to get there. App developers are already complaining, much as they did when Windows NT prohibited them from taking over the display drivers or writing to memory unimpeded.

Office 365 is a primary driver for these apps, but enterprises who distribute Office and host SharePoint on premises can benefit from it as well. No longer will SharePoint administrators toss and turn at night wondering if the application they just installed on SharePoint will bring down the whole server farm. Yet it’s likely to be a long road.

This article is about this 3^rd app model and how it works at an architectural level. The sections which follow will describe three core design principles which provide the application isolation and trust of a modern application in SharePoint and Office.

At BlueMetal Architects, we’ve been working on how to apply these principles in our client solutions, even outside of the app model. I’ll be talking about this at SPTechCon Boston and SharePoint Connections later this year, and will show attendees how to apply these principles in any version of SharePoint to get the same benefits and to make the transition to the app model easier.

Principle #1 – Isolate Apps in the Browser

“Good fences make good neighbors”
                - Anonymous

The first element is that application integration no longer happens in SharePoint or Office, but in the web browser. Yes you read that right – even the Office apps run in the browser, and unbeknownst to users, programs such as Word and Excel 2013 quietly host a browser window to run these apps.

There are a couple advantages to this:

1. Web browsers are already good at isolation. This was forced by cross-site scripting attacks and other problems that plagued early browsers; now there are standards which work consistently across all browsers to prevent, say, a casual gaming site from reaching into your online banking site to play games with your personal finances.
2. These applications are all potentially browser based anyway. SharePoint is primarily accessed via a web browser, and the new Office Web Applications are on the rise, allowing Word, Excel, and PowerPoint to run in the browser. Outlook has had a browser-based version for years. So running apps in the browser allows them to work with rich client and browser based versions of Office.

Figure 3 shows the new app model applied to SharePoint. SharePoint doesn’t run the apps as it has in the past; instead it stores metadata about the apps and adds them to the web page so they can run in the browser. These apps are rendered in IFrames, which may point to a special, isolated SharePoint site or to any page on the web. In order to isolate the apps, they are always given URL’s on a different host name than the SharePoint one; this causes the browser to isolate the apps as it would isolate any two web sites.

Figure 3 - SharePoint App Model

In practice, application code runs as Javascript in the browser itself, or in some external server somewhere outside of SharePoint. SharePoint can host all-Javascript apps (these are called “SharePoint Hosted” Apps), or they can be hosted by an external server (so-called “Cloud” or “Provider” Apps).

Regardless of whether the code is running in browser script or on some external server, it can only access SharePoint using services. API’s such as the Client Object Model are available to run inside the app, but ultimately they access SharePoint indirectly, using web services. These services control access to SharePoint, so apps can only put content where they’re supposed to.

Principle #2: Be Careful How You Trust

“With great power comes great responsibility.”
                - Spiderman

Traditionally, applications run with the permission of their user. For example, if you try to open a document with Microsoft Word, and you don’t have permission to the document, the operating system won’t let you open it and Word will bubble up the error message.

This model falls over when an application wants to do something that the end user isn’t allowed to. For example, a workflow application might want to log something to an audit trail, yet it might be important not to let the user running the application to access the audit trail through other means. SharePoint solves this with something called SPSecurity.RunWithElevatedPrivileges(); when an application runs this method, it is suddenly omnipotent.

Being omnipotent might sound like fun, but it’s a lot of responsibility. It used to be that users were pretty much omnipotent when they ran Windows applications; Windows introduced User Access Control (UAC) to address this. This feature prompts users when applications want elevated privileges, but it isn’t ideal since users often don’t have enough information to make an informed choice.

The SharePoint app model provides much more selective access. When a user installs an app, he or she is asked what permissions the app should have (and they can’t exceed that user’s permissions). Then SharePoint gives the app its own identity and uses its existing permission system to enforce access control. Thus you can give an app permission to the audit list when you install it, and still deny end users access to the same list.

SharePoint 2013 has added a vast library of services, which are available through a client-side API called the “Client Object Model”, or directly using RESTful services. The app’s identity is conveyed to these services by SharePoint’s cross-domain library [http://msdn.microsoft.com/en-us/library/fp179927.aspx] when app code runs in the web browser, and by OAuth [http://msdn.microsoft.com/en-us/library/fp142382.aspx] when the app runs in an external server. OAuth is a standard which allows an application to access services on behalf of a user without having access to the user’s password or other shared secret; it’s based on work by Flickr, Google, and Yahoo who all needed a way to allow “apps” to access user content without giving away the user’s password.

Principle #3: Clean Up Your Mess

“Keep your house and its surroundings pure and clean. This hygiene will keep you healthy and benefit your worldly life.”
                - Sri Sathya Sai Baba

The gray market for Windows cleaning software is indicative of a major problem of applications not cleaning up after themselves. Even if you uninstall that “cute kitty” game that someone downloaded, there’s a good chance nobody will remember to scoop out the litter box. Traditional SharePoint solutions are like that; they routinely leave web parts, SharePoint data, and other junk laying around. Part of it is developer sloppiness, but Microsoft doesn’t make it any too easy to seek and destroy the artifacts users have created with your app, so it’s no wonder this happens so often.

SharePoint apps are much better in this regard. By default, apps store their content in an isolated site called an “app web” – delete the app, and SharePoint will delete the app web and everything in it. SharePoint will also police web pages and remove any leftover web parts or other references to the app.

Q: So how do we get there?
A: Start thinking like Office 365, even if you’re on premises

The new app model has gotten a slow start. This is partly due to the time it takes for enterprises to adopt SharePoint 2013, partly due to limitations in the model, and partly due to the fact that you pretty much have to rewrite applications to adopt the new model.

For example, a traditional “web part” solution would be written using C# running on the SharePoint server, accessing the SharePoint server API. The equivalent app might be written in Javascript running on the web browser, accessing the SharePoint client API. Unless a SharePoint solution is developed with the app model in mind, it’s not going to be an easy transition.

If an entire app is written to run in the web browser, it can easily be hosted on premises or Office 365, but browser script only goes so far. If the app needs to run on an external server, someone has to host it. On premises, this is left as an exercise to the IT department; there are no special tools for this. ISV’s and service providers need to provide their own hosting.  Office 365 provides an option for “autohosted” apps which are automatically provisioned in an Azure environment; this seems like a great idea, but at this writing, “autohosted” apps aren’t fully enabled and can’t be sold in the Office Store.

In addition, since they can only talk to SharePoint using web services (either directly or via a client API), there are many things they simply can’t do. This rules out a whole group of SharePoint solutions that do administrative chores or reach under the covers to change the way SharePoint data is stored. In general, the app model is very much a “version 1” implementation.

That said, it has great promise. It’s like going from Windows 95 to Windows 8… it’s not going to happen overnight, but it’s worth it. Microsoft might want to turn off traditional solution capabilities, and has already hinted at that by “deprecating” sandboxed solutions [http://msdn.microsoft.com/en-us/library/jj163114.aspx]. (Sandboxed solutions still work, their capabilities are likely to be phased out though maybe not all at once; for example site templates now depend on the user code service even though they don’t include any user code.)

So what’s an IT shop to do?

The answer is to start thinking as if you’re Office 365. Maybe you’re already on Office 365, in which case this is easy! But even if you’re on premises, start to think as if you might be going to Office 365 soon. Select 3^rd party applications that run on Office 365, and start writing your own solutions to run outside of SharePoint, ideally in Javascript in the browser. SharePoint 2010 provided enough services – especially when supplemented with client libraries such as SPServices– that you can start developing code that is much closer to the app model without waiting for SharePoint 2013.

The reason for this isn’t so much that you’ll have to go to Office 365; there will probably always be plenty of options for hosting SharePoint, including on premises. The reason is because over time you should strive to make your on-premises hosting more like Office 365 for the same reason Microsoft hosts SharePoint this way:

• The application isolation and clean-up make SharePoint more stable and easier to manage
• Application distribution is controlled centrally, and users can install apps without IT assistance
• Isolated apps make it easier to upgrade SharePoint; you don’t have to worry as much about how apps interact with the platform if they’re only accessing web services and not actually running on the server
• The more granular permission model is more secure; there are limits on what a rogue app could do, and apps are never omnipotent

I’ll have a couple of different takes on how to do this at upcoming conferences. I’ll introduce the concepts next month at SPTechCon Boston 2013  and dive even deeper at SharePoint Connections in Las Vegas this fall. Both sessions will include demonstrations of how to develop solutions for SharePoint 2010 or 2013 which can easily be ported to the new app model. Following these practices, you can start preparing to adopt the new app model when you’re ready to, regardless of your hosting environment.

By moving towards the new model, you’ll receive the benefits of stability and manageability gradually over time, and will open up more flexible hosting options for the future.

Reading List

• Microsoft SharePoint 2013 App Development, by Scot Hillier and Ted Pattison
  Great starting point for App development: concise, well-written, and a great value
• My thoughts on the SharePoint App Model, Office 365, SharePoint Store and the Business of SharePoint Apps Today, by Andrew Connell
  Great perspectives on the app model that explores its strengths and weaknesses, as well as the realities of selling in the SharePoint store
• App Approaches to Common SharePoint Customizations, by Richard diZerega
  In my opinion, this article overstates the viability of the SharePoint app model, but it’s still a helpful piece of work. The author goes through dozens of SharePoint development scenarios and shows how they could be accomplished using the app model. Read carefully, you can see the ones where it’s a slam dunk and others where it’s a stretch!