1.A) SharePoint Farm
A SharePoint farm is a group of front-end servers, applicative servers (Shared Services), indexing servers and database servers. A SharePoint farm can be deployed to a particular location according to objectives (Internet access, geographical localization, …).
1.B) Service applications
This is a set of services that are available at farm level. Because of this, it is shared between the different web applications and site collections.
These services are responsible of:
- User Profile (profile properties, synch parameters)
- Search (scopes, properties mappings, content sources, …)
- Excel Services
- Business Data Catalog
- …
Each service can be enabled or disabled on each SharePoint servers. This allows SharePoint infrastructure to be the most efficient and met security and availability requirements.
2) Web Application
There is nothing new for ITs or developers that already worked with sites or applications powered by ASP.NET, PHP or all server-side technologies. A web application characteristics are:
- A site in IIS
- A particular url
- A authentication method associated with this web application
We can notice that a web application uses its own database in a SharePoint context (to be more precise, it is the case for new application. There is the possibility to create Web Applications extensions. These extensions can use different parameters that the main web application. We will use this when we want to share data between web applications and use different authentication modes for example).
Furthermore, SharePoint is an ASP.NET application so it uses Web.config files. We will be able to add differents entries according to the objectives of the web application. We will remove some features if the web application is used by partners for example.
Finally, a web application is always associated with a SSP.
3) Sites Collection
A sites collection is a virtual container (there is no physical file as it is the case for previously described elements) and sites collection structure is stored in a configuration database.
Form an IT point of view, sites collection has some advantages. The main advantages are:
- Content quota templates
- Ease of maintenance (backup / restore is performed by site collection by default)
From a content manager point of view, we will notice that an administrator is defined each site collection. This administrator can manage:
- Second level Recycle bin
- Customized search
- Users of the site collection
- …
Lastly, site collections is used to bring customized elements together and shared them with a audience that will access data across this sites collection (per example a department):
- Master Pages
- Images
- Sites and lists Templates
- Web parts
There is always a root site in a site collection.
4) Sites and subsites
In the beginning of this post, we told a lot of time of IT guys, a little bit about developers but I didn’t told about about end users even though they are the driving force of SharePoint content.
At this level, everything is related to content management. According to the users permissions, they can:
- Create sites
- Create lists
- Attach workflow to lists
- Grant permissions
- Restore deleted content
- A lot of others operations!
At this level, there is only one important thing to manage and organize data: company best practices and rules. It doesn’t matter where data are logically based, it will be physically stored in the same database. However, data should be spread all around sites and sub-sites. Do not hesitate to use important feature as permissions inheritance. It will help to organize data efficiently.
It is possible to add some code or reporting tools but the most important thing is the end-user and power-user training.
Here is a SharePoint structure example:
- Farm
- Web Application 1
- Sites collection A (with top-level site)
- Sites collection B (with top-level site)
- Web Application 2
- Sites collection C (with top-level site)
- Sites collection D (with top-level site)
Fuentes:
http://didierdanse.net/blogs/dev_en/