How to Design a SharePoint Application to the Cloud

There is a very common misconception about the uses for SharePoint and I would like to talk about one of them: Using SharePoint as a file repository. Of course SharePoint has great features to enable file sharing and versioning control across the enterprise, but is it so much more than this. So I decided to elaborate a challenge: How would you go about to setup a SharePoint/MOSS solution as an application architecture?

And let’s make the challenge a bit more interesting, shall we. WPF Composite Application Guidance (PRISM), Windows Azure, Sculpture, MVC, ASP.NET. What all these new technologies have in common? They all have deployment options for the Cloud.  So, our challenge will be not only design an application using SharePoint but also design a SharePoint application using the Cloud as subsystem.

 

How can we design an application for the Cloud?

There are many approaches, but I would say the most likely models are:

• Line of Business running as services  that can keep their data in the Cloud and have web pages as UI.
• Web applications hosted entirely in the Cloud.
• Various systems designed as message-based applications using the Cloud as media and components like HTTP, REST and SOAP as protocols.

One of my passions is photography so let’s design an application where people can contribute with pictures to the cloud via SharePoint. In our case study, we have to consider the following scenario:

• many pictures can be uploaded by a single user.
• many users can submit their pictures at the same time from several locations across the world.
• Every picture will have a little story about it. Whoever upload the picture must tell the story associated with it.
• the pictures and the stories can have multiple formats
• many devices can be used to upload the pictures (desktop, notebook, mobiles)

In the other side, we will have customers (agencies) consuming these contents via exposed services:

• one agency can query as many times they want for shared and approved content.
• many agencies can submit their queries at the same time
• many devices can be used to query the results (desktop, notebook, mobiles)

 

So let’s take a look at our suggested model:

 

Our main enterprise application will be hosted in a SharePoint/MOSS application where the business owners can control it from there, use the BI tolls and apply KPI tools if they wish to. Also via developed custom web parts hosted in our SharePoint site they will have access and create reports targeting our File System impersonated by Windows Azure in the Cloud.

Web services will be developed and exposed using our own APIs to allow communication with our file system in the Cloud. At this point, we want to be agnostic and pragmatic. Just because we are using SharePoint and Microsoft Cloud, it does not mean we have to be attached to Microsoft tools. Since Web services and the Cloud itself work under well-known protocols any client can then interact with them. We can have desktops running Macs searching for pictures and text, we can have mobiles using embedded Java to upload pictures to our application and we can have other agencies using our own exposed API and integrating our system into theirs and querying the results via SQL Reporting Services via XML.

What should be our focus when designing such application ?

It does not matter the chosen technology provider. IMHO, the most important factors to cover here are: Scalability and Application Services

Why Scalability?
Let’s take a step back and think about how is this application going to be in 2 years time.  Scalability means provide a good tolerance for expansion without compromising the quality of service in our case. Overtime we expect a growing user base and file storage usage by pictures, descriptions, user profiles, texts or whatever it is; but not only this, we should expect a growing number of requests per day by users all over the place. If we wanted, we could even expose services as plug-in for third-party consumers to provide our services in their own applications. Scalability must provide enough room for this to grow in the future

That’s when comes a brand new concept: Infrastructure as a service. High scalability and high availability are the main features of such environment. Who today can offer such a worldwide service? the Cloud. and with another good thing to take: The Cloud is agnostic.

So, here we have our chosen infrastructure media.

We are going now to develop .NET custom code implementing the Windows Azure APIs and make them as components in our SharePoint application, which can be distributed in our SharePoint pages as web parts hosted on Web part Zones.

 

Why Application Services?

Here the biggest concern is relating to the many devices allowed by the system per user. It is impossible nowadays to have an application dictating what the user/client must use or not, and if you ever do this it will be in no time your competitor's biggest strength.

At the same time, many RIA – Rich Internet Applications are available and will want to be using such a service base, like iPod Touch and other mobile devices. To implement these we need to think about Composition Interfaces.

Composition Interfaces are many pieces of various design patterns combined to allow writing flexible UIs according to the user. We can even use ASP.NET adaptable rendering controls to minimize our design time. So by using a ASP.NET text box within a custom web part in our SharePoint site page to upload pictures, it will be rendered with no problems when this page is accessed via Firefox browser or a Nokia cell phone as well.

Flexible UIs allows us to develop both simultaneously and with personalization according to the user’s needs.

This given scenario is also a great model for sub locating tasks to other groups via design by contract.

To design an application by contract is to specify, document and make available all the expected inputs and returned outputs from our system, in our case our SharePoint site, so others can develop targeting our platform in a very interesting way because now you can give them a task, tell them the APIs to use (for uploading photos or querying texts) and they then develop the module based on the contract. It also introduces a very important aspect of it which is the atomicity. If their part somehow breaks down or has a bug, it won’t affect the main system because the calls specified by contract are already sanitizing the inputs and outputs.

Another added benefit is that such architecture is modular enough from the solution interface. You can clearly give a demonstration to the project’s stakeholders explaining the contract’s model and the interfaces without touching the internal processes and they will most likely to understand. It is like having a helicopter view of the solution.

So, there you go. Now when someone tells you that they use SharePoint to save files and share resources in their Intranet you can tell: “SharePoint can do so much more than this!”

By Edge Pereira