SharePoint 2013 and Windows Azure (part 1) - Understanding SharePoint Cloud-Hosted Apps and Windows Azure

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

SharePoint and Windows Azure are two sizeable platforms unto themselves. SharePoint is one of Microsoft’s leading server productivity platforms — the collaborative platform for the enterprise and the Web. Windows Azure is Microsoft’s operating system in the cloud. Separately, they have their own strengths, market viability, and developer following. Together, they provide many powerful benefits. For example:

  • They help expand how and where you deploy your code and data.
  • They increase opportunities to take advantage of the Windows Azure “metered usage” model while at the same time reducing the storage and failover costs of on-premises applications.
  • They provide you with new business models and offerings that you can take to your customers to increase your own solution offerings.

SharePoint and Windows Azure have evolved quite a bit since mid-2010 (when Microsoft introduced the topic) into a mature set of integrated technologies. Figure 1 illustrates the fact that each of the three categories of Windows Azure can in some way, shape, or form be integrated with SharePoint. For example, within the IAAS category, you can stand up servers in Windows Azure with fully functional SharePoint farms (whether they are stand-alone servers or connected servers that include Web front ends, index servers, SQL Servers, and so on). You can see here it’s possible to support SharePoint for Internet Sites (FIS) sites, or Business Intelligence (BI) servers that run SQL Reporting apps. You can also create development and test or training environments on Windows Azure Virtual Machine (or IAAS). Within PAAS, you use the core services within Windows Azure to build applications, so much of what you would do here to integrate with SharePoint apps or sites would be hosting WCF or REST services in the cloud, integrating with workflow, building media-rich applications, hosting data, and so on. Finally, the SAAS model extends on the subscription-based Office 365 core functionality to integrate with Windows Azure and build complete cloud-based solutions (for example, a training solution that uses Media Services to stream videos to your SharePoint site) or line-of-business (LOB) applications such as Dynamics CRM integration or data-synchronized apps that reflect on-premises LOB applications.



Windows Azure is not just about the integration of cloud apps with SharePoint though; it’s also about extending your apps in other directions and to other endpoints. For example, you can also build services that not only integrate Windows Azure SQL Database data with SharePoint but also wrap cloud-based services that project to devices, phones, and Windows 8 tablets. With the integration of SharePoint and Windows Azure, cloud-based applications are entirely possible.

1. Understanding SharePoint Cloud-Hosted Apps and Windows Azure

In SharePoint 2010, Windows Azure and SharePoint were two distinct platforms and technologies; you could integrate them easily enough, but they were not part of the same “system.” However, in SharePoint 2013 this has changed.You can build two types of Windows Azure integrated applications. The first type of application is Autohosted, and the second is Provider-hosted (sometimes referred to as self-hosted). The major difference between the two is that Autohosted applications natively support a set of Windows Azure features (for example Web Sites and SQL Database) with the SharePoint development and deployment experience, and Provider-hosted applications are meant to integrate with a broader set of web technologies and standards than Autohosted applications, one of which is Windows Azure. Thus, you can take advantage of the entire Windows Azure stack when building Provider-hosted apps that use Windows Azure.

To show just how closely integrated Windows Azure and SharePoint have become, for the Autohosted app model, Office 365 has its own flavor of a Windows Azure site that it uses behind the scenes. You can use it to effectively leverage the core Windows Azure features. Not only is this important from the feature-sharing aspect between the two platforms, but it’s also important from a security perspective — HTTPS is supported across these two connected domains.

This HTTPS support extends to Provider-hosted applications that are deployed to Windows Azure as well. For example, if you build and deploy a Windows Azure Web Site, you’ll note that it natively supports HTTP and HTTPS. This has significant implications for when you want to secure your web assets and have them conversant with SharePoint. That is, you don’t have to purchase a certificate from a trusted body such as GoDaddy, upload it, build it into your Windows Azure application, and so on. All you need to do is deploy your website to Windows Azure and then register the HTTPS-based URL with SharePoint and connect the applications.

You use the Autohosted cloud app model to build and deploy smaller, cloud-hosted apps to SharePoint. The Autohosted app leverages a smaller subset of the Windows Azure platform — namely Web Sites and SQL Database. Using these areas, you can build some lightweight, data-driven apps where the code lives in Windows Azure and the configuration for that code lives in SharePoint. Figure 2 illustrates how an app deployed to SharePoint comprises two main parts: the .APP that is deployed to SharePoint, which contains configuration and registration information, and the functional code, which is deployed to Windows Azure.



One of the principal items to keep in mind with Autohosted apps is that they’re an evolution towards a more cloud-hosted model. When you compare Autohosted apps to Sandboxed solutions, for example, you have much more power and developer capability at your fingertips with the former. But similar to Sandboxed Solutions, Autohosted apps get your code off of the server, while still allowing you to build interesting applications.

Autohosted apps are different from Provider-hosted apps in that the SharePoint environment executes code that is deployed to Windows Azure; this is abstracted from the view of the developer but is still a native part of Windows Azure. This is really good for singular deployment and billing, and enables you to build once, but automatically deploy to the right places.

Provider-hosted apps are a slightly different breed with which you can build more broad-reaching web apps that integrate with SharePoint. Within Provider-hosted apps, you’re managing your own hosted web environment and then integrating the applications, services, or data from those separate domains with SharePoint (for example, one domain being SharePoint and the other being Windows Azure). Thus, using a Provider-hosted app is not as simple as using the Autohosted app in regards to integrating Windows Azure. The Autohosted app model automatically registers the code that is deployed to Windows Azure, but in the Provider-hosted model you need to configure the registration of the Windows Azure application to authenticate the app and the events in that app such that they can fire within the SharePoint environment. As discussed previously though, there are mechanisms between Windows Azure and SharePoint that make the authentication process a smooth one (such as HTTPS support across SharePoint and Windows Azure Web Sites). Also, the SharePoint client-side APIs facilitate cross-domain events such as reading or writing list items.

Provider-hosted apps are also different because you can deploy and integrate apps that go beyond Windows Azure. Thus, it’s not just about Windows Azure; the Provider-hosted apps support PHP, Java, and so on.

  •  Sharepoint 2013 : SharePoint Installation and Configuration - Create a New Subsite
  •  Sharepoint 2013 : Join a Server to the SharePoint Farm, Create a New Web Application, Create a New Site Collection
  •  Sharepoint 2013 : Install Without a Product Key in the Configuration File, Configure a New SharePoint Farm
  •  Sharepoint 2013 : Prepare the Microsoft SharePoint Installation Module , Install SharePoint Unattended
  •  Sharepoint 2010 : Putting Your Site on the Web - Additional Features
  •  Sharepoint 2010 : Putting Your Site on the Web - Key Terms and Architecture , Richer User Experience
  •  Sharepoint 2010 : Putting Your Site on the Web - Web Content Management (part 2) - Web Publishing 101
  •  Sharepoint 2010 : Putting Your Site on the Web - Web Content Management (part 1)
  •  Sharepoint 2010 : Using an External Data Column, Building a Composite Application
  •  ASP.NET 4 in VB 2010 : Page Tracing (part 3) - Application-Level Tracing
    Top 10
    Free Mobile And Desktop Apps For Accessing Restricted Websites
    MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
    TOYOTA CAMRY 2; 2.5 : Camry now more comely
    KIA SORENTO 2.2CRDi : Fuel-sipping slugger
    How To Setup, Password Protect & Encrypt Wireless Internet Connection
    Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
    Backup & Restore Game Progress From Any Game With SaveGameProgress
    Generate A Facebook Timeline Cover Using A Free App
    New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    - Messages forwarded by Outlook rule go nowhere
    - Create and Deploy Windows 7 Image
    - How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
    - Creating and using an unencrypted cookie in ASP.NET
    - Directories
    - Poor Performance on Sharepoint 2010 Server
    - SBS 2008 ~ The e-mail alias already exists...
    - Public to Private IP - DNS Changes
    - Send Email from Winform application
    - How to create a .mdb file from ms sql server database.......
    programming4us programming4us