Thursday 2 October 2014

SharePoint development history

  SharePoint purely development solution history started with SharePoint 2007 version released. Microsoft came with the first fully managed solutions also known as farm solutions. Next release was SharePoint 2010 where Microsoft extended the option for hosted options available to developers by introducing sandboxed solution deployment as an alternative to farm solution deployment that enable the developer to write the code for hosted environment office 365 with some limitation. Most of the companies small scale IT companies move to the Office 365 environment and it is very popular. As other vendors come up with the Apps(Apple etc.). Microsoft comes with App model with this current version 2013 and its mostly focus on the cloud. So there was no big changes for Farm Solution, main focus on the App development (Sandboxed solutions are deprecated in SharePoint 2013).






Farm Solution: SharePoint 2007 represents the first version of SharePoint technologies where Microsoft invested to create a true development platform by introducing features and farm solutions. 
·     Managed solutions also known as farm solutions will be hosted within the main SharePoint worker process (w3wp.exe). 
·         Full trusted solutions can be installed on any scope (Farm, Web App, Site Collection, Sites). 
·   The deployment, most farm solutions require a Farm Administrator to do the deployment and mostly restarts the IIS on all the WFEs, which causes a disruption in the service. 
·         Down time considerations 
·         Cost 
·         High Availability and Disaster recover changes 
·         Monitoring 
·         Integrate with other applications using BCS (Business Connectivity Service), Web Services or build your own service application, this provided the end users with limited experience integrating with external applications. 
Sandbox Solution: SharePoint 2010 where Microsoft extended the options available to developers by introducing sandboxed solution deployment as an alternative to farm solution deployment. 
·         Sandbox solutions will run within the SharePoint sandbox worker process (SPUCWorkerProcess.exe). 
·         Sandbox solution or partially trust a solution is scope limited to Site Collections. 
·         Down time considerations 
·         Cost 
·         High Availability and Disaster recover changes 
·         Monitoring 
·     Only resources that are available on the server that is running the sandboxed worker process can be accessed. An external database, for example, cannot be accessed. This means that a BCS Model cannot be deployed in a sandboxed solution. 
·         Although the deployment of Sandbox solutions is a lot easier and straight forward but there’s no indication on whether or not it’s safe to activate this sandbox solution without actually activating it and giving the code inside aces to all the site collection’s content. Not required to reset the IIS. 
·         Sandbox Solution best use for Office 365. 
·         The limitation of sandbox solution click my recent post

App Solution: SharePoint 2013, Microsoft has now added a third option for SharePoint developer with the introduction of SharePoint apps. It is different from Farm and Sandbox Solution. Why it is different? The main reason “App runs 100% outside of the SharePoint server, and their custom code executes either within the context of the client browser or on other servers that are not running SharePoint such as Web servers in the cloud.” 
    Get rid of the custom code; that gives increases the scalability of SharePoint Farm.
     Farm Solution during migration creates problems while upgrade WSP from one version to another.
         No Need to maintained two solutions that runs Office 365 as well as in Farm Solution. Now the whole 
         point of an App is you don’t worry where it’s hosted or deployed as it should behave the same on both            On-Premise and Cloud environments.
         Not required to learn SharePoint object Model for App development. As App Model provides a loosely coupled architecture for building Apps in SharePoint 2013. Gives the freedom of choice for developers in the technologies they use to not only host their applications, but also the tools they use to write them. Apps can leverage industry web standards such as HTML, JavaScript, jQuery, JSON, REST, OData and OAuth to provide an integrated user experience.
         Visual studio 2012 templates support the App.
        Newly added event receivers that specially works for Apps.
         Debug your code by using Remote Debugging option.
         Deploy your app at “Site Scope” and “Tenancy Scope” level.
         Sandbox solution deprecated by the Microsoft for 2013 release. So only the App model will be used for development app that runs both on- Premise and cloud environments.
       Apps provide you with the simplest marketing and sales system based on a Microsoft-provided online app store.
         You can use the create the reusable solution to your farm later if you want you can sell the same on the Market Place to sell your app and generate revenues for your company. 

Disadvantage of App Model 

One explicit limitation of the SharePoint App Model is that server side code is explicitly prohibited from residing on the SharePoint farm as part of an App. Any server side code that is utilized in the context of an App must be hosted outside of SharePoint either in the cloud or on-premises. 
SharePoint 2010 (SharePoint Server 2010 and SharePoint Foundation 2010)

SharePoint 2010 was released with SharePoint Server 2010, both Standard and Enterprise for the majority, as well as with the free version of SharePoint Foundation 2010. SharePoint Foundation was originally going to be named WSS 4.0 but was later changed to SharePoint Foundation 2010 as that is what it is, the “foundation” of the 2010 version release.
Organizations were drawn to SharePoint Server 2010 for not only its much improved ECM \ RM capabilities but also its more robust workflow and Microsoft Office integration capabilities. SharePoint 2010 has been highly customized by some organizations using either the dreaded SharePoint Designer 2010 or via Visual Studio and “features” that could include anything from workflows to custom web parts or master pages. SharePoint 2010 contained the major user interface updates such as the “Ribbon” that allowed for management and layout changes to be completed in a manner that Microsoft Office 2007 users would easily understand.
SharePoint Server 2010 provided new content management features such as managed metadata, the ability to centrally define taxonomies that can be leveraged within and across farms, as well as Unique Document IDs, which provide for the ability to assign a document unique identification number users can use to retrieve a document even after it is moved. Document Sets in SharePoint Server 2010 were a welcomed feature by legal and compliance and records managers as they provided for the ability to group multiple work items into one consolidated atomic work product.
Note: SharePoint Server 2010 does have the optional SharePoint FAST Search capabilities. The FAST Search capabilities have been added to SharePoint 2013’s native search and now there is only 1 central search feature that includes all of these previously optional and more expensive licensing search features.
SharePoint 2007 (SharePoint Server 2007 (MOSS) and WSS 3.0)

SharePoint 2007, which is commonly referred to as either MOSS or WSS, also included the Microsoft Office SharePoint Server 2007 Standard and Enterprise versions as well as the free version, Windows SharePoint Services 3.0 (WSS 3.0), that was widely adopted throughout the globe. SharePoint 2007 was a major update from SharePoint 2003 as it introduced “item level permissions” as well as the new My Site capabilities that provided users with a personal “site” to store their information. In my 2007 publication of Windows SharePoint Server 3.0 (WSS 3.0), I recall referring to the My Site capabilities as the “MySpace.com of the enterprise” which is funny as it just goes to show what poor roadmap and strategy planning can do to a software platform. Project Server 2010 also came with a tailored WSS 3.0 release that project teams used to save their project documents which were stored on a separate site collection and content database.
SharePoint 2003 (SPS 2003 and WSS 2.0)

SharePoint 2003 was, in my opinion, the really first workable version of SharePoint that included Microsoft SharePoint Portal Server 2003 (SPS) as well as Windows SharePoint Services 2.0 (WSS 2.0). Many deployments of SharePoint 2003 were very highly customized by Microsoft FrontPage and this has caused a pain point for a lot of organizations as they faced a dilemma of recreating the customizations or simply migrating the content to a new and fresh installation of SharePoint 2007. Project Server 2003 also came with a tailored WSS 2.0 release that project teams used to save their project documents which were stored on a separate site collection and content database.
SharePoint 2001 (SPS 2001 and WSS 1.0)

Microsoft SharePoint Portal Server 2001 was Microsoft’s first release of SharePoint which came out of the project previously code-named "Tahoe," and provided the entry of a search solution for organizations as well as a web-based collaboration capability.
To quote Microsoft, “SharePoint Portal Server 2001 integrates a flexible Web portal based on Microsoft Digital Dashboard technology, content indexing and search, document management, and a collaborative applications platform. With SharePoint Portal Server, developers with basic or advanced skills can create collaborative solutions.
For Microsoft Windows and Microsoft Office users, SharePoint Portal Server is a portal solution for users to find, share and publish information. SharePoint Portal Server brings together a single solution for corporate portals, document management, and content indexing and searching.
     


Architectural Changes in SharePoint 15 (2013)

In general, SharePoint 15 (2013) model has stayed same as 2010 version. However, numerous platform level improvements and capabilities listed.
·                     Shredded Storage – Only update the changed content to storage
·                     SQL improvement – Support SQL 2012
·                     Cache Service – Distributed cache across servers to improve performance
·                     Request Management – Redirect request to individual server for large farm
·                     Themes – Better user interface
·                     Sharing – Improve content sharing and access control

The detailed major changed are summarized in the following categories. I will not copy all the content and please refer to Microsoft SharePoint 2013 resource center for details. The detailed video and presentation will help you to understand the details. Some summaryalso provided by some people.

1. Service application changes
·                     Office Web Apps is no longer as service application
·                     Web Analytics is no longer as service application, it’s part of search
·                     Other enhanced service applications
2. Enterprise Content Management
·                     Site –level retention policies
·                     Discover Center
·                     eDiscover capabilities
·                     Team folders to integrate with exchange
 3. Web Content Management
·                     Support the tools and workflow designers use
·                     Variations & Content Translation
·                     Search Engine Optimization
·                     Cross Site Publishing
·                     Video & Embedding
·                     Image renditions
·                     Clean Urls
·                     Metadata navigation
4. Social
·                     Microblogging – share and follow
·                     Activity Feeds – view activities related to content
·                     Communities
·                     Discussions
·                     Blogs 
5. Search

·                     Personalized search results based on search history
·                     Rich contextual reviews
6. Business Intelligence Enhancements

7. Mobile

8. Remove API Enhancements

When we looked at the architecture changes and major changes to us might be the office web apps and web analytics changes. There will be some design you should consider now before you run into the dead end. Here are the description, reason for change, and what you need to be prepared as architect for the two changes.

Description for change #1: Office Web Apps is no longer as service application. It is a separate application and recommended to be installed as separate farm.

Reason for change: Leverage Office Web Apps to integrate with SharePoint, exchange, Lync, and other third party application. The new architecture recommended is displayed in the screen shot.





What need to be prepared: Here are things you need to do as architect on SharePoint 2010.
If you have not deployed the Office Web Apps on SharePoint 2010 farm, serious consider NOT deploy this application unless this is absolutely needed by the business side. The critical issue for Office Web Apps installation on SharePoint 2010 is you could not un-deploy it unless to remove the server from the farm and rejoin as we discuss with Microsoft! The un-deploy will remove the servers from the farm and will take large amount time to rejoin all servers back with clean environment. 

If you have Office Web Apps on SharePoint 2010 farm, you might consider removing it from the farm before the upgrade! This might be the simplest way since I’ve not heard any upgrade process.


Following are the changes in the architecture of SharePoint 2013:
  1. Shredded Storage:
The goal here is to make changes equal to the size of the change, not size of the file. Let’s have a look at how it works in SharePoint 2010 and 2013 to understand the purpose.
How It Works in SharePoint 2010:
When a file is updated via Cobalt, only the bits that have changed are sent over the wire from the client to the SharePoint WFE. However, because SharePoint lacks the concept of incremental updates to SQL it is forced to:
    1. pull the entire file to the WFE
    2. merge the changes into it
    3. write the entire file back to SQL
How It Works in SharePoint 2013:
    1. The file is broken into pieces and stored in SQL
    2. On update only the shredded blobs that correspond to the updated bits are touched
    3. No more round tripping entire files to the WFE and back
  1. SQL Improvements:
In SharePoint 2013, Microsoft has tried to make significant improvements in server performance. They have reduced scenarios that might invoke full table scans. Also, there have been lots of improvements around finding docs for link fix-up and alert handling. They have reduced data redundancy for some features using advanced indexing features provided by SQL 2008 R2. The major change in architecture is to support wide lists, i.e. lists where a single item spans multiple rows in the database to hold the data.
  1. Cache Service:
There is a new distributed cache service in SharePoint 2013 based on Windows Server AppFabric Distributed Caching. It is used in features like authentication token caching and My Site social feeds. The same time it should be noted that SharePoint 2013 uses caching features that cloud-based cache (Windows Azure Cache) does not support at this time, so only local cache hosts can be used. Also, importantly, SharePoint ONLY supports the version of caching that it ships – you cannot independently upgrade it.
The config DB keeps track of which machines in the farm are running the cache service. It is all provisioned by the SharePoint setup. A new Windows service – the Distributed Cache service – is installed on each server in the farm when SharePoint is installed.

  1. Request Management:
Request Management in SharePoint 2013
The purpose of the Request Management feature in SharePoint 2013 is to give SharePoint more control and knowledge of incoming requests. This allows SharePoint to customize the response to each request. SharePoint 2013 is now able to determine the nature of incoming requests – for example, requested URL, source IP, or user agent. The Request Management feature is applied across all web apps; similar to how throttling was used in SharePoint 2010.
The goals of Request Management are:
Identify requests that are harmful and immediately deny them.
Route to WFE’s with better health, keeping low-health WFE’s alive.
Prioritize requests by throttling low-priority requests (bots), to serve those with higher priority (end –user requests).Route heavy requests to the machines with more power.
Route all requests of a specific type (like search for example) to specific machines.
Use isolated traffic to help identify and troubleshoot errors on a specific machine.
The Request Management feature is made up of three main components;
Request Throttling and Prioritization – Requests are filtered to determine which should be throttled and which should be prioritized.
Request Routing – Determine which WFE’s the request should be routed to.
Request Load Balancing – Using weighting schemes (for example – health) to determine which machine a request should be routed to.

Request Management uses routing rules associated with Machine Pools to determine request routing. Machine Pools contain servers which use either static weights or health weights for routing. As their names denote, static weights remain constant for WFE’s, while health weights change dynamically based on health scores. Routing rules which are placed in execution groups determine which server in a Machine Pool the request is routed to. Routing rules are placed in either execution group 0 or execution group 1, with 0 being the default. Rules are evaluated in each group until the correct match is found. Once a match is found no more execution groups are evaluated. Since the default is execution group 0, you would place your most important rules in that group.

Request Management in SharePoint 2013 offers great improvements from SP 2010. In SharePoint 2010, throttling used a system in which WFE’s attached their health scores to each and every response. But the responsibility to honor the health scores fell to the client and the system did not preclude possible WFE failure. This meant that clients would receive server-busy messages from low-health WFE’s when more healthy WFE’s were available. SharePoint 2013 has taken the process of throttling which was used in 2010 and made it a much more sophisticated process in which routing rules process requests and throttling rules stop them.
  1. Service Application Changes:
There are a few new service applications in SharePoint 2013:
    • App Management Service: allows you to install SharePoint apps from the Office Marketplace or the App Catalog
    • SharePoint Translation Services: does simple language translation of Word, PPT, and XLIFF files into HTML
    • Work Management Service: provides task aggregation across systems such as SharePoint, Exchange and Project.
    • Azure Workflow Server is new and not exactly a service app but similar. Provides an externalized host using REST and OAuth to run workflows.
Also, Office Web App and Web Analytics are no longer a service application. Web Application Companions (WAC) is now a separate product altogether and not a service application.You can create a WAC farm that can support multiple SharePoint farms. You can view files from a number of different data sources, including: SharePoint, Exchange, Lync, File servers. 3rd parties can integrate with WAC to provide access to documents in their data stores, e.g. EMC Documentum, IBM FileNet, OpenText, etc.
  1. Other Considerations:
Stretched farms are no longer supported in SharePoint 2013. “Stretched” means different data centers with less than 1ms latency. All servers in the farm must be in the same data center now. For 100% fidelity in 100% of features, all content must reside in the same farm.
SharePoint 2013 has a lot of exciting new features and it will be interesting to see how the SharePoint Product Team at Microsoft continues to build and package but the features and solutions within 2013 should give you and your organization added confidence in the fact that you have selected a solution that Microsoft is backing with its full support and has tagged SharePoint as its flagship product.
Description for change #2: Web Analytics in SharePoint Server 2010 has been discontinued and is not available in SharePoint 2013 Preview. Analytics processing for SharePoint 2013 Preview is now a component of the Search service. Details in Microsoft site.

Reason for change: A new analytics system was required for SharePoint 2013 Preview that included improvements in scalability and performance, and that had an infrastructure that encompasses SharePoint Online. The Analytics Processing Component in SharePoint 2013 Preview runs analytics jobs to analyze content in the search index and user actions that are performed on SharePoint sites.

SharePoint 2013 Preview still logs every click in SharePoint sites and still provides a count of hits for every document. User data is made anonymous early in the logging process and the Analytics Processing Component is scalable to the service.

This analytics data is used in SharePoint 2013 Preview to provide new item-to-item recommendation features, to show view counts that are embedded in SharePoint 2013 Preview and Search Server user interface, to provide a report of the top items in a site and list, and to influence the relevancy algorithm of search.

What happens to Web Analytics after upgrade: The Web Analytics Service is not upgraded to the Analytics Processing Component in SharePoint 2013 Preview. When you upgrade to SharePoint 2013 Preview, the databases that contain the data from Web Analytics in SharePoint Server 2010 are not removed. These databases are not used by or maintained by the Analytics Processing Component in SharePoint 2013 Preview. This means that documents on sites in SharePoint Server 2010 that are upgraded will show a hit count of 0.

When you upgrade to SharePoint 2013 Preview, do not attach and upgrade the databases that contain the data from Web Analytics in SharePoint Server 2010. We recommend that you turn off Web Analytics in the SharePoint Server 2010 environment before you copy the content databases that you want to upgrade to SharePoint 2013 Preview.

Reports from Web Analytics for the top items in a site are carried forward. Reports that show browser traffic, top users of a site, and referring URL are not carried forward and are not used by the Analytics Processing Component in SharePoint 2013 Preview.

Administrative reports for the quota usage of site collections in the farm are not available in SharePoint 2013 Preview.

SharePoint 2013 Preview does not support the Web Analytics Web Part. After a farm is upgraded to SharePoint 2013 Preview, all instances of a Web Analytics Web Part will not function. The page that includes the Analytics Web Part will render and a message appears that informs the user that the Web Part is no longer supported.

What need to be prepared: You should generate a report what pages are using Web Analytics Web Part and remove them before the upgrade.You should design to utilize the new search application service and new BI functions to replace current Web Analytics functions.

SharePoint expert Chris McNulty from Quest will detail five specific actions to prepare for the future, including:
·                     Establish governance today
·                     Choose code-free customization
·                     Perform inventory and analysis
·                     Implement data externalization
·                     Consolidate content

There are many other architect and design you should implement now to be prepared for SharePoint 15 (2013).

Hope it will help you .................