SharePoint Processing Mechanism

What is Site

• Site is a collection of web pages which is used to store information in organised way.
• Site stores list of documents, discussion, events, task and many other types of information.
• Site provides controlled access to share information among user.  i.e. Only Authorize users are allowed to access shared information.

What is Site Collection

• Site Collection is collection of sharepoint site.  i.e. Sharepoint site collection is logical grouping of multiple sharepoint site.

Example illustrating difference between site and site collection.

Look following hearchical diagram. 

Here "ABC Company" is site collection.  i.e. Root site connecting multiple sub site.

And All department site are called Sharepoint site.

How SharePoint Page Processing and others

I know all SharePoint gigs knows what I am stating in this article. To be honest this is more for may quick reference.

ASP.NET Applications vs. SharePoint Sites

Windows SharePoint Services development and traditional ASP.NET development differ in many ways. To help you understand the differences, we can compare ASP.NET applications with Windows SharePoint Services applications.

Figure 1 displays the different components and the interaction flow of a mainstream ASP.NET application.

Figure 1. Components and flow of a mainstream ASP.NET application

Users send requests to the server running Internet Information Services (IIS) for specific resources. These requests are accepted by IIS and delegated to an ISAPI extension DLL for further processing. Typically, resources are retrieved from the file system, such as .config files, .aspx pages, cascading style sheets, custom-built .NET assemblies, and user controls. All of these can act on the final response that is delivered to the user in his or her browser. In many applications, an interaction with a data store is also needed to store and retrieve data that is used to process the request and generate the response. 

So, what is different when we compare Figure 1 with Figure 2, which represents the components and flow for a site based on Windows SharePoint Services?

Figure 2. Components and flow of a Windows SharePoint Services site

As you can see in Figure 2, Windows SharePoint Services abstracts developers from many of the details of hosting highly scalable, template-driven sites. In many cases, SharePoint administrators and experienced users do not even touch that low-level infrastructure. However, an understanding of it is helpful.

Windows SharePoint Services is a site-provisioning engine that relies heavily on schema definitions for templates of many types of artifacts that are important to its environment. There are definitions for site templates; for infrastructure pages such as the default.aspx, which make up the home page of a team site; for lists and libraries; and for helper pages that enable the interaction among the content that is stored in these different containers.

When starting a request for a Windows SharePoint Services page, there is interaction with the configuration database and the content database that retrieves the details of the request. This includes accessing the many XML files that contain the schema definitions, and accessing building blocks (Web Parts) that each have to execute their code that is encapsulated in a .NET assembly made available via either the global assembly cache or the local bin folder. The Windows SharePoint Services provisioning engine joins all these processes.

When we look at the traditional ASP.NET application again, what happens there if you need more than one application, maybe two, five, or even dozens? Figure 1 starts to look complex because there the same infrastructure is repeated for each additional application. Developers following the best practices and patterns can produce many re-usable building blocks, but much of the infrastructure must still be re-created each time.

By comparison, many Windows SharePoint Services sites—dozens, hundreds, even thousands of collaboration sites—can be delivered with one common provisioning engine. This is the power of using Windows SharePoint Services compared to using ASP.NET applications.