SharePoint
au
Quotidien
avec
EROL
|
|
|
|
Windows SharePoint Services ArchitectureGo to see in french an article : http://www.laboratoire-microsoft.org/articles/teched_2003/3/ The architecture for SharePoint™ Team Services "v1.0" from Microsoft has been improved and enhanced for Windows SharePoint Services Beta 2. In Windows SharePoint Services Beta 2, site settings and information, along with all site information—such as all list data, all documents in document libraries, and other page content—is now stored in the Microsoft SQL Server™ or MSDE database. It is no longer split between the file system and the database. This change was made primarily for the following reasons:
Furthermore, because the new architecture greatly reduces the dependency on the Windows registry and the Internet Information Services (IIS) metabase for each server that runs Windows SharePoint Services Beta 2, you can now create a server farm system with multiple servers and host many more Web sites than you can with SharePoint Team Services "v1.0". Windows SharePoint Services Beta 2 ConfigurationsYou can choose between two configurations for Windows SharePoint Services Beta 2: stand-alone server or server farm. If you anticipate only light usage of your Web sites, you can use the stand-alone server configuration. If you are supporting Web sites in a large organization or as an Internet service provider (ISP), and anticipate heavy usage and a lot of data, you will most likely want to use the server farm configuration. The following describes a stand-alone server configuration:
The following diagram illustrates the architecture for the Windows SharePoint Services Beta 2 stand-alone server configuration.
The above diagram shows a similar architecture to that used for SharePoint Team Services "v1.0", with the exception that all data is now in the SQL Server database rather than split between the database and the file system. The following describes a server farm configuration:
The following diagram illustrates the architecture for the Windows SharePoint Services Beta 2 in a server farm configuration.
In the above diagram, you can see the larger effects of the architecture change. Because site information is stored in the content databases, you can distribute the load among several front-end Web servers running Windows SharePoint Services Beta 2, and they can all communicate with the appropriate database. So, a request coming from the client can go to any of the front-end Web servers and still be able to connect to the correct Web site data. In a server farm, each front-end Web server running Windows SharePoint Services Beta 2 can have multiple virtual servers. Each virtual server, in turn, can have multiple site collections, which can have one top-level Web sites and multiple subsites. The following diagram illustrates this hierarchy.
About Virtual ServersA virtual server is a way of breaking up the Web server structure, giving you finer control over settings for particular groups of Web sites. So, rather than configuring a setting for an entire server, you can configure it for just a virtual server. You can also configure authentication on a virtual server basis, so that different virtual servers can use different authentication methods. If you have some sites that are internal to an organization, and some that are accessible from the Internet, you can host them on separate virtual servers and use the appropriate authentication method for each environment. Using virtual servers in Internet Information Services 6.0 (IIS) can also allow you to isolate Web sites from one another. You can specify different applications pools for each virtual server, and be sure that changes made to a site on one virtual server will not accidentally be transferred to another site on a different virtual server. For more information about application pools and processes, see Windows SharePoint Services Security Model or IIS 6.0 Help. SharePoint Team Services v1.0 supported approximately 1000 virtual servers per server. Windows SharePoint Services Beta 2 supports many fewer virtual servers per front-end Web server (approximately 10). This difference is due to the use of ASP.NET, which creates a separate set of compiled DLLs for each virtual server. Because Windows SharePoint Services Beta 2 uses several, large DLLs, it is not practical to have them all in memory at the same time (when you extend a virtual server, approximately 50MB of memory is taken up by the base working set of processes, including ASP.NET). However, because you can host multiple site collections on each virtual server, you should not need to create as many separate virtual servers in Windows SharePoint Services Beta 2 as were needed in SharePoint Team Services v1.0. Structuring the URL NamespaceWindows SharePoint Services Beta 2 can be used in a variety of environments: from the small, departmental server, to a large server farm at an ISP. To suit these environments, Windows SharePoint Services Beta 2 on an IIS 6.0 platform allows you to set up your URL namespace in several configurations, all of which are based on the type of site you want to create. Windows SharePoint Services Beta 2 supports the following types of sites:
You can choose between these types of sites, depending on your organization's needs. After you decide which basic site types you will support, you can choose from the following namespace configurations:
Communication Between the Client and ServerThe FrontPage 11 (Beta) client communicates with Windows SharePoint Services Beta 2 using HTTP, the same protocol Web browsers and Web servers use to communicate. FrontPage implements a remote procedure call mechanism on top of the HTTP POST request, so that the FrontPage client can request documents, update the Tasks list, add new users, and so on. The Web server sees POST requests addressed to the Internet Server Applications Program Interface filter (ISAPI filter) forWindows SharePoint Services Beta 2 and directs those requests accordingly. FrontPage correctly communicates between client and server through proxy servers (firewalls). Note FrontPage does not use the HTTP PUT request. As described in the HTTP specification, PUT sends a document to a Web server; however, few Web servers implement PUT. Therefore, the FrontPage client uses the universally implemented HTTP POST request for all communication with Windows SharePoint Services Beta 2. Windows SharePoint Services Beta 2 does not follow the "create and then publish" model you may be used to with other Web sites. The moment you create a Web site based on Windows SharePoint Services Beta 2 it is live on the server; you do not need to publish the Web site to another server. You can still edit the Web site in a compatible Web page editor, such as FrontPage 11 (Beta), or add pages and documents to the site, but you do not need to publish your changes—they take effect immediately when you save the files. Mapping URLs to Physical PathsWindows SharePoint Services Beta 2 handles mapping incoming URLs to the site content in the databases. When using the server farm configuration, multiple sites are stored in each content database. A configuration database keeps track of which sites are mapped to which content database. The content databases themselves store all site content and serve up the appropriate content when the front-end servers request it. In SharePoint Team Services v1.0, because site content was stored both in the file system and in the IIS metabase, IIS was responsible for URL mapping. Because the mapping between a site and the content database is based on the site's URL, two URLs cannot point to the same site. For example, you cannot use both http://www.server_name.com/site1 and http://www.server_name.com/site2 to point to the same content in the database. You can, however, achieve the same effect by setting up http://www.server_name1.com/site1 to redirect to http://www.server_name2.com/site1. The exception to this rule is an intranet/extranet scenario, where you can have two virtual servers map to the same site content with URLs such as http://server_name/sites/site_name and http://extranet.company_name.com/sites/site_name. For more information about setting up an intranet/extranet scenario, see Installing and Configuring Windows SharePoint Services for an Intranet and Extranet. Handling ASP.NET Pages (ASPX Pages)Windows SharePoint Services Beta 2 uses ASP.NET pages (Active Server Pages or ASPX pages) for forms and lists. These pages can be customized, and you can add additional ASP.NET pages to run custom solutions on top of Windows SharePoint Services Beta 2. ASP.NET pages in the _layouts directory for a SharePoint site run in direct mode, which means the are allowed to run directly. The _layouts directory contains fixed application pages for Windows SharePoint Services Beta 2, such as the Create List, Create Field, and Site Settings pages, and so on. This directory is considered outside of the Web site, and these pages are supplied directly by IIS as requested. ASP.NET pages inside a Web site run in safe mode. In safe mode, the ASP.NET page does not get compiled into a DLL and only a specific set of controls (identified previously as "safe") are allowed to run. You can edit the list of "safe" controls allowed to run in Web sites on a specific virtual server by editing the web.config file for a virtual server.For more information about customizing or adding ASP.NET pages in Windows SharePoint Services Beta 2, see the Windows SharePoint Services Software Development Kit. 14/04/2005 Extrais de HELP Admin. (c) Microsoft. |
|
|
