A Brief History of Personal Applications
In its youth, Microsoft was true to its name as a supplier of microcomputer software. In those 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.
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 VMS 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, 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
Just as Microsoft took the industry by storm in the personal OS market in the 1990’s, it’s all but taken over the productivity and collaboration software market, and remains a strong leader in this area.
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.
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 SharePoint 2010, but there were 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 3rd 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 3rd 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.
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 when app code runs in the web browser, and by OAuth 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.
(Sandboxed solutions still work for now. The user code service, a part of sandboxed solutions, is the part that’s likely to be phased out. Other sandboxed solution features, such as the ability to deploy content to SharePoint using the Solutions Gallery is key to supporting site templates and even the new Design Manager, and thus are unlikely to be removed from the product.)
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 3rd 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
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.
![IC648720[1]](https://sharepointsamurai.files.wordpress.com/2014/09/ic6487201.gif?w=300&h=181)
![clip_image001[6]](http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-46-82-metablogapi/1072.clip_5F00_image0016_5F00_7FA6F1CB.jpg "clip_image001[6]")
One of the core concepts of Business Connectivity Services (BCS) for 
![PrimForWindowsRuntime[1]](https://sharepointsamurai.files.wordpress.com/2014/05/primforwindowsruntime1.png?w=474&h=307)
![2008040211105590dad[1]](https://sharepointsamurai.files.wordpress.com/2014/04/2008040211105590dad1.gif)
server(s)
Note
Important
![SspId replacements file_thumb[2]](https://i0.wp.com/lh6.ggpht.com/-6rZRafRhLOM/UjjSPTBgdSI/AAAAAAAACgY/l_Ks0NtL3Sc/SspId%252520replacements%252520file_thumb%25255B2%25255D%25255B4%25255D.png "SspId replacements file_thumb[2]")
![Continuous Integration - Office 365 - custom VS configuration_thumb[2]](https://i0.wp.com/lh4.ggpht.com/-xxiJ42sc-jA/UjjSSmZBpzI/AAAAAAAACgw/PJqyQjzT0y4/Continuous%252520Integration%252520-%252520Office%252520365%252520-%252520custom%252520VS%252520configuration_thumb%25255B2%25255D%25255B4%25255D.png "Continuous Integration - Office 365 - custom VS configuration_thumb[2]")
![Continuous Integration - Office 365 - Managed Metadata solution_thumb[2]](https://i0.wp.com/lh4.ggpht.com/-hzeQXGVA8Q4/UjjSTged1BI/AAAAAAAACg4/ba5hhFZChTo/Continuous%252520Integration%252520-%252520Office%252520365%252520-%252520Managed%252520Metadata%252520solution_thumb%25255B2%25255D%25255B4%25255D.png "Continuous Integration - Office 365 - Managed Metadata solution_thumb[2]")
![Define custom configuration_thumb[2]](https://i0.wp.com/lh3.ggpht.com/-brGWrsxe8U0/UjjSVOVC5fI/AAAAAAAACg8/4XfGf9wRNqQ/Define%252520custom%252520configuration_thumb%25255B2%25255D%25255B4%25255D.png "Define custom configuration_thumb[2]")
![Define custom configuration 2_thumb[2]](https://i0.wp.com/lh3.ggpht.com/-hxfY2yShqmI/UjjSWJdyneI/AAAAAAAAChI/opDSsZuHm-c/Define%252520custom%252520configuration%2525202_thumb%25255B2%25255D%25255B4%25255D.png "Define custom configuration 2_thumb[2]")
![Define custom configuration 3_thumb[2]](https://i0.wp.com/lh5.ggpht.com/-rJFQe757Shw/UjjSXSrHFAI/AAAAAAAAChQ/3F9gAeGu8Ow/Define%252520custom%252520configuration%2525203_thumb%25255B2%25255D%25255B4%25255D.png "Define custom configuration 3_thumb[2]")
Figure 2. Create a new Cloud Business App project in Visual Studio
Figure 3. Enter your Office 365 developer site
Figure 4. Solution Explorer
Figure 5. Add a new table in the Table Designer
Figure 6. Add some fields in the Table Designer
Figure 7. Enable Social feature in your app
Figure 8. Choose “Query” button to add a custom query for this table
Figure 9. Customize the query with the Query Designer
Figure 10. Add another query via the context menu
Figure 11. Customize another query
Figure 12. Add a screen via the context menu
Figure 13. Create a screen by choosing a screen template
Figure 14. Your UI elements are laid out in the Screen Designer
Figure 15. Change the visual control
Figure 16. We will display kudos as a tile list
Figure 17. Customize the tile list
Figure 18. Customize the look-and-feel of a visual control
Figure 19. Customize the font and alignment of a visual control
Figure 20. Add a button to the screen
Figure 21. Add Button dialog box
Figure 22. Choose an existing method
Figure 23. Create a screen to add a kudo
Figure 24. New screen created in the Screen Designer
Figure 25. Run the application
Figure 26. UI to add a kudo
Figure 27. App in a small form factor
Figure 28. Customize the UI in Visual Studio while the app is running
Figure 29. Customize the visual control
Figure 30. Customize the UI layout
Figure 31. Choose a person from the auto complete text box
Figure 32. A kudo is created in the app
Figure 33. Presence information inside of the tile
Figure 34. By default, there is one screen tab in the screen
Figure 35. Add a new screen tab
Figure 36. New screen tab is created
Figure 37. Change the display name of the screen tabs
Figure 38. Add a data member to the screen
Figure 39. Select a data member to add to the screen
Figure 40. A new data member is added to the screen
Figure 41. Create UI for the newly added data member
Figure 42. Customize the tile list
Figure 43. App displays 2 screen tabs
Figure 44. Kudos Received tab shows all kudos created by the current user
Figure 45. Entry points for writing business logic
Figure 46. Write validation logic
Figure 47. Validation logic is invoked in the running app
Figure 48. Publish your app
Figure 49. The app is published to the app catalog
Step 2:
Figure 1. Wikipedia app in Word
Although your inserted text takes the document formatting, you must insert HTML to do app-specific styling.
Once those two checks have successfully completed, go ahead and insert your data.
The status property of AsyncResult (result in the above code sample) returns an AsyncResultStatus enumeration, which indicates success or failure by its type.
SharePoint Samurai 
