Navigate Up
Sign In
Supporters of Developer
Web

The new SharePoint application model

Item is currently unrated. Press SHIFT+ENTER to rate this item.1 star selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+ESCAPE to leave rating submit mode.2 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.3 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.4 stars selected. Press SHIFT+ENTER to submit. Press TAB to increase rating. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.5 stars selected. Press SHIFT+ENTER to submit. Press SHIFT+TAB to decrease rating. Press SHIFT+ESCAPE to leave rating submit mode.

You may also be interested in: SharePoint-based solutions by B&R Business Solutions

 

With the public announcement of the new major release of SharePoint and the availability of the public beta, I thought it would be a good time to introduce and share my opinions on the new application model in SharePoint 2013.

As hopefully you have seen our announcement, we have released a new app into the Marketplace which is available for free in the preview period within the Office 365 Preview SharePoint Online environment. This app was developed by our AvePoint Labs team, which we formed in January of this year to focus on building prototypes on new technology, extending a research and development arm outside our existing DocAve platform. I have had the pleasure of working on this team with some amazing developers to build this app along with other prototypes on top of Windows 8 and Windows Phone 8 and other upcoming platforms. I am very passionate about technology and love the fact that every day I get to be on the bleeding edge. If you haven’t guessed already, I love my job! To see more on our app please check out the AvePoint MyView microsite and download it in the Marketplace.

Our journey started when we were invited by Microsoft to be involved in a program to help give feedback on the SharePoint Product Group’s vision on the next wave of SharePoint, much like we have done in the previous 2007 and 2010 waves. Since that initial briefing, we have been more and more involved in deeply investigating the new features of the platform in early builds of SharePoint. This involved building proof-of-concept solutions to help get a deeper understanding of the platform changes. This also helps us understand how changes may affect our existing products and identify opportunities for new products such as MyView.

The 2010 application model

The 2010 application model evolved from 2007 in one key way, with the introduction of sandboxed solutions. For those of you who sucked the fire hose of information when this was announced, the intention was to “start first with sandboxed solutions, and only move to full trust solutions as needed.” Sandboxed solutions gave Microsoft the ability to offer Office 365 SharePoint 2010 Online with support for custom, managed-code solutions, a big improvement over BPOS SharePoint 2007 Online which only allowed for Web UI and SharePoint Designer customizations.

Microsoft believed that there would be uptake on-premise also, but the general feedback is that sandboxed solutions are too limiting which usually pushed you to use client-side development approaches such as JavaScript or Silverlight. The newly introduced Client Object Model did make the platform more extensible but there were, and still are, limitations of this API that require you to use the more extensive Server Object Model and many of these calls are only available through full-trust solutions.

Terminology changes

With the confusing combinations of on-premise, private/public clouds, multi-tenanted, partial-trust and full-trust environments, I think it’s important to introduce some new terminology to clarify the code execution options we have. Companies like Fpweb.net, Rackspace, Amazon, and the new Windows Azure all provide hosted VM-based solutions where you have full control of the servers. This means you can remote into the servers and you can also deploy full-trust code solutions if you wish. You may also have on-premise servers where corporate governance policies restrict you from deploying these same solutions. Microsoft’s SharePoint Online and other hosting providers also offer a restricted multi-tenant model where only sandboxed solutions are supported.

While you have a lot of options for hosting SharePoint, in terms of code execution, there are only two choices that are relevant. For this article and moving forward I’m going to use the terms “Full Control SharePoint environments” and “Multi-Tenant SharePoint environments.” I have asked many if terms for these have already been defined, but so far I’ve not encountered a distinction as clear as this. Please let me know in the comments area if I’m wrong here or if you have other suggestions.

Where to begin

The sandboxed solution model was introduced to control the execution of managed code on a SharePoint server within the farm, because you didn’t want one solution de-stabilizingthe rest of the SharePoint farm as it may have been shared by other tenants. The code within a sandboxed solution is executed in a separate worker process on one or more SharePoint servers and monitored for overall usage. This usage was calculated into a point system which was determined by the requests made in the code. Once the solution consumed more than the allocated resource points for the site collection within a 24 hour period, the entire sandbox was disabled. Yes, that’s right. It didn’t just disable the solution, but effectively took down all other sandboxed solutions running in that site collection. For more information on the resources measured please check TechNet.

Monitoring and policing sandboxed solutions prevented to a degree how one tenant affects other tenants on the farm. A flaw in this model was that if the code excessively calls the client-side APIs, these are not monitored. Furthermore, this remote invocation has been encouraged by the huge adoption of JavaScript and jQuery from within the development world. Microsoft needed to come up with an answer to “off-shore” the solutions so that it didn’t affect the underlying SharePoint platform.

SharePoint-hosted application model

Virtual file systems have always existed in SharePoint and you can deploy files by uploading through the Web UI, through SharePoint Designer or in by referencing them within Solution Packages (WSPs). The new SharePoint-hosted application model allows you to use Solution Packages to deploy files, typically .aspx pages, into a new App Web which is a SharePoint Site (SPWeb/Subweb).

The big drawback to these solutions is that they cannot have *any* server-side managed code and rely purely on client-side coding languages such as JavaScript. These solutions will be able to call the SharePoint client-object model much like you can in SharePoint 2010 now.

This way you have less flexibility for building true SharePoint-hosted apps and is certainly less control than Sandboxed Solutions. The key here is that they are available to be submitted for the marketplace.

Remote hosted web application model

Back in the early days of my IT career as a graduate in 2003, I worked on a platform called Plumtree Portal, which eventually got bought by BEA and is now called AquaLogic. This is a Java based server side platform with a JavaScript client-side development platform. It essentially allowed you to drop “portlets” on your portal pages that were windows through to other web applications via IFRAMES. The really neat part about this technology back then was that they allowed controlled communications via JavaScript between the hosted portal page and the web application running in the portlet. Again, ring any bells? You’ll hear this being compared to Facebook app model a lot!

What the Microsoft team has done is introduce the ability for an “App” which is a SharePoint subsite that can host pages from a remotely hosted web application. That application also has context of the site collection in which this subsite is stored. The SharePoint site collection has a trust relationship with the remotely hosted web application through OAuth. This does mean that, like the SharePoint-hosted app model, you can leverage the building blocks of SharePoint within the site collection but also have other things running in the remote web application if you want. A good example here would be that documents would likely be stored in the SharePoint site, but the UI layer would be run from the remote web application rather than as .aspx pages deployed to the virtual file system.

Platform language:

The main benefit of remotely hosting an app and hooking into SharePoint is the remote web application can based on any web technology you choose. So ASP.NET MVC, LAMP, Perl, or any other HTML5/JavaScript based platform is an option. This model is very similar to the push Windows 8 Metro apps as well. This design means you no longer use the SharePoint server-side object model and all its intricacies to “host” an application in SharePoint anymore. It appears Microsoft’s goal here is to allow new or legacy apps to be quickly integrated to SharePoint with little code changes. Our new Governance Automation product that we launched in June this year was purposely built outside of SharePoint as an ASP.NET MVC 3 app because we knew we could hook it into SharePoint via this app model very quickly.

I can see architects here who have typically committed to SharePoint Developer resources who spent a lot of time in learning the platform and leveraging all the building block features of SharePoint instead turning to core .NET Developers who use the .NET framework stuff hosted remotely. One major reason is because of the lack of quality SharePoint resources. Plus SharePoint developers in general are more expensive than developers who write on other platforms. I can see some fall out here and a transition period for these SharePoint Developer resources who’ll most likely have to drop their rates as the learning curve is simplified by being able to use a well-known development platform instead of having to learn SharePoint’s.

Object model access:

The main benefit of this approach is that you can execute managed code in your own remote processes and then call the client object model of SharePoint with the OAuth trust. From a Microsoft perspective, this means that they have offloaded or externalized this process from the SharePoint farm. Since server-side SharePoint code is only executed inside an application-pool on a SharePoint web server in the farm, these remotely-hosted apps must rely on the client-object model. In SharePoint 2013, the parity between the client-side object model and the server-side object model is much closer with the introduction of service application APIs and much more. That said, there will likely be cases where you’ll be unable to do something because it’s not available through a client API.

App Permissions:

One thing to bear in mind here, is as you add the App to your site collection as a subsite, the App can request that it be granted permissions. This is a new concept to SharePoint, as now not only can SharePoint Users & Groups and Claims be granted permissions in the security hierarchy, but so can Apps.

One of the key limitations of this permissions model is that it can only ask up to full control of the site collection the App is added to. It isn’t that granular in permission choices either. You have Full control, manage, contribute or view (TechNet). For a lot of solutions, developers will need to have permissions to more than just one site collection and therefore this App would need to be added and granted permission to each site collection. In this instance, you’ll most likely look at a Full-Trust Solution to do this on scale in a Full Control SharePoint environment.

Provider-hosted and auto-hosted:

There are two key types of remote-hosted apps (TechNet):

  • Auto-hosted – this approach leverages Windows Azure SQL and Web Roles. The Azure projects built in Visual Studio will be automatically provisioned to the Office 365 tenancy’s linked Windows Azure tenancy. This is great where as an app vendor you don’t want to host the web application in a multi-tenant way and let the customer host it and pay the bills. The downside of this approach is that you don’t control the updates to the web application.
  • Provider-hosted – this approach means that you have to host the web application on your own infrastructure and it has to handle a multi-tenant approach. The advantage of this is that you control when you update the app. The disadvantage is that as your app grows tenants, you have to grow your tenancy which will cost money.

High-trust apps:

For Full-Control SharePoint 2013 environments, OAuth isn’t supported because there is no connection to the Azure Access Control Service (ACS). There is a way of using Remote-hosted apps by using the high-trust apps model (TechNet).  High-trust apps run on stand-alone servers on your intranet and use a signing certificate to digitally sign the access tokens that the app generates.

Marketplace

The marketplace is new to SharePoint 2013 and allows users to pick Apps from the marketplace to then add to your site collection. The marketplace offers companies the opportunity to sell Apps to a broad audience of organizations that are using SharePoint 2013 Preview.

Corporate Catalog

One of the big limitations with the marketplace is that it only supports the new application models (self-hosted and remote-hosted). This means that existing sandboxed solutions and full-trust solutions are not supported in the marketplace. There is a concept of a Corporate Catalog that can be controlled in Full Control SharePoint Environments by Farm administrators.

What app model to use?

Much like the confusion in SharePoint 2010 around whether to use Full-Trust Solutions or Sandboxed Solutions in full control farm environments, the same question will be asked now of whether to use Sandboxed Solutions, SharePoint Hosted Apps or Remote Hosted Apps. The problem now is that with “Multi-Tenant SharePoint environments”, this question is now in play also. Hopefully this matrix helps clarify your options.

2012-07-19-NewSPApp-03.png

Wrap Up

Where do you start? Check out the training videos put up by Microsoft on MSDN. Please also be sure to check posts on this topic by my good drinking buddies’ Andrew Connell and Chris Johnson. Please also keep an eye on my delicious social bookmark feed for #SharePoint2013 content I discover which is tagged appropriately.

Hopefully this has been useful for you and please feel free to add your comments below.

Categories: SPF 2013; dev; SharePoint 2013

Comments

Thanks for this explanation

Hi Jeremy, In your app model matrix did you mean AutoHosted by "Sharepoint HostedApps" and ProviderHosted by "Remote HostedApps" ? Could you give us where to find the main limitations for server object model API in RemoteHosted & HigTrusted Apps ? Tks !

Posted 01-Aug-2012 by paslatek
tammy

tammy

playing the jogos de cozinhar and cooking is my passion, as they include almost the same steps in them plus having them all over is good and informative also love the jogar jogos de moto as they are very fast to play and enjoy

Posted 06-Aug-2014 by tammy

Notify me of comments to this article

E-mail:
   

Add Comment

Title:

 
Comment:
Email:

   


Name:

 
Url: