Académique Documents
Professionnel Documents
Culture Documents
Published: February 2011 Summary: Learn about the architectures of Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010, including the platform stack, the Microsoft ASP.NET-IIS integrated request pipeline, the server and client object models, and the execution process system for sandboxed solutions and farm solutions. Applies to: Microsoft SharePoint Foundation 2010 | Microsoft SharePoint Server 2010 Provided by: Ricky Kirkham, Microsoft Corporation Contents
Overview of SharePoint Foundation and SharePoint Server Architectures What Is SharePoint? SharePoint Development Platform Stack SharePoint as an ASP.NET-IIS Application SharePoint Configuration Stack SharePoint Deployment Models Process and Execution Trust Model Pages, Parsing, and Safe Mode Data Model, Data Management, and Query System Services and the Service Application Framework Site Definitions and Web Templates SharePoint Security Server Object Model in SharePoint Client Object Models in SharePoint Workflows in SharePoint Conclusion
1|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
What Is SharePoint?
The use of the plural term "architectures" in the title is not a mistake. SharePoint has many architectures, partly because "architecture" has many meanings in the context of software development, but also because SharePoint itself is many thingsthings that in the past would have been distinct applications or platforms. The following is a selection of some of the most important things that SharePoint is: A portal server with delegated administration. SharePoint enables information workers (IW) who have no knowledge of website design or website administration to create, almost instantly, attractive and functioning websites. This relieves information technology (IT) departments from the burden of creating and administering the sites, and it empowers the IWs to create their own sites for teams, blogs, wikis, and other purposes. A groupware application kit. SharePoint provides a platform on which IWs can create collaboration solutions that include document libraries and workspaces, workflows, wikis, blogs, and team-oriented lists, such as Events, Announcements, and Tasks. Microsoft SharePoint Workspace (formerly Microsoft Office Groove 2007) provides an offline experience for these collaboration solutions. A workflow host. Business processes can be systematized and modeled with workflows that are triggered by associated events; for example, the addition of a document to a document library. A content management application. SharePoint Server Enterprise Content Management (ECM) features include document management, records management, and web content management. A Business Intelligence (BI) application kit. The Microsoft Business Connectivity Services (BCS) features of SharePoint enable data from non-SharePoint sources, such as a SAP installation or Oracle database, to be accessed (read/write) just as if it were an ordinary SharePoint list. The operating system of an intranet. SharePoint can provide for an intranet many of the functions that an operating system provides for a computer, including storing and copying files, hosting services, starting applications, and securing data. (This is not to imply that SharePoint can only be used on an intranet. SharePoint can also host extranet and Internet-facing solutions.) A host for services. SharePoint deployments make data available through a client object model, the REST-based Windows Communication Foundation (WCF) Data Services (formerly ADO.NET
2|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
This article discusses the architectures of SharePoint 2010 (with many links to more detailed information) in several senses, including the platform stack on which SharePoint runs, the configuration layers, the client and server object models, the services framework, the HTTP request pipeline, and the worker process system.
3|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Perhaps the most noteworthy aspect of the figure is that IIS and ASP.NET are shown as a single platform. This is because SharePoint requires that IIS operate in integrated mode with ASP.NET. Hence, from a SharePoint point of view, they are effectively a single web-hosting application. For more information about this, see the next section, SharePoint as an ASP.NET-IIS Application. In Figure 1, the smaller boxes that have no fill represent some selected subparts of the platform that contains them, or on which they depend. The two thin, downward-pointing arrows indicate some specific dependencies that are shown only as examples. Many other specific dependencies are not shown in the figure. The thick, left-pointing arrows indicate that the entity on the right side accesses the entity to which the arrow points. For example, BCS accesses external databases.
4|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
5|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
6|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
ASP.NET development experience can be an advantage for a SharePoint developer, but the SharePoint development experience is different from the ASP.NET experience in many ways. Some examples of the differences are as follows: SharePoint has its own installation and deployment model. For more information, see SharePoint Deployment Models later in this article. SharePoint makes a distinction, unknown in ASP.NET, between application pages and site pages. For more information, see Pages, Parsing, and Safe Mode later in this article.
7|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
For more information about how SharePoint development differs from ASP.NET development, see ASP.NET vs. SharePoint: How Development Differs.
8|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Thus, SharePoint Solution Package files are never installed to the file system of any server, although elements of a farm solution may be installed to the file system when the solution is deployed. 2. Deploying: The solution package is unpacked and its elements are deployed to their appropriate places. For a farm solution, this step also requires a farm administrator and can be done by using either Central Administration or SharePoint Management Shell, or the object model. Some examples of how elements are deployed: user control files (.ascx) are copied to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\ControlTemplates and assemblies are deployed to the global
9|P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
It is also in this second step that any Features in the solution are installed in the Feature Gallery of the farm, web application, site collection, or website, depending on the scope of the Feature. (For more information about the relations of farm, web applications, site collections, and websites to one another, see Content Hierarchy later in this article.) Within a SharePoint solution package, there can be an additional level of encapsulation because a solution can have one or more SharePoint Features. A Feature can be installed at the scope of the farm, the web application, the site collection, or the website. After it is installed, a Feature must be activated by owners of any website within the scope; so Activating becomes a third step of installation for Features. Features can contain content types, controls, custom actions, custom fields, files, workflows, list instances, list templates, event receivers, and document converters; although some of these cannot be included in certain scopes. (Features that are deployed in sandboxed solutions can be scoped only to a site collection or website. For site collection-scoped features in sandboxed solutions, the second and third steps are combined. The Features are activated when the solution is deployed.)
Note : SharePoint is not consistent in its terminology with regard to installation. The terms adding, deploying, and activating are the most frequently used to refer to the three steps of installation; but depending on what tool is used to complete a step and whether the solution is farm or sandboxed, you will see a variety of terminology. The first step may be called adding, installing, or uploading. The second step may be called deploying, activating or installing. There is a similar inconsistency in the terms for reversing these steps; but most commonly, reversing the second step is called retracting and reversing the first step is called removing. The third step, which applies only to Features, is always called activating, and its reversal is always calleddeactivating.
Some SharePoint solutions target one of the client object models, either exclusively or in addition to targeting the server object model: the JavaScript, Silverlight, and Microsoft .NET Framework client object models. (For more information about the client object models, see Client Object Models in SharePoint later in this article.) There is nothing unusual about the installation of the client portion of such solutions. The script files that define the JavaScript object model are downloaded to a client computer when a page that references them is opened.
10 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
For more information about the processing of client-side logic in SharePoint, see Client Application Models in SharePoint 2010. For more information about the deployment system, see Building Block: Features, Building Block: Solutions, and Packaging and Deployment.
However, unlike a standard ASP.NET application, SharePoint makes a distinction between sandboxed solutions and farm solutions. Farm solutions run in the IIS worker process just like any ASP.NET application. Sandboxed solutions run in a specially restricted execution environment. This is necessary because sandboxed solutions are installed on (and scoped to) SharePoint site collections without the intervention of the IT professionals that are managing the SharePoint farm. To prevent rogue or poorly performing code from slowing or crashing the application pool, SharePoint imposes restrictions on what the code in a sandboxed solution can do. As a crucial part of the implementation of this system, sandboxed solutions must run in a special sandboxed worker process (SPUCWorkerProcess.exe). When a request attempts to access a sandboxed solution, a SharePoint execution manager that runs in the IIS worker process finds a sandbox worker process (or starts one, if none is running) in which the code of the sandboxed solution will run. In principal, this sandboxed worker process can be started on any server in the farm that is running the SharePoint 2010 User Code Host service (SPUCHostService.exe). (In the UI of the Central Administration application, this is known as the Microsoft SharePoint Foundation Sandboxed Code Service.) The server that is running the SharePoint 2010 User Code Host service can be, but does not have to be, the front-end web server on which the IIS worker process is running. Which server is used is configurable in the Central Administration application: Administrators can choose to have each sandboxed process run in "local mode," which means that each request for a sandboxed solution is processed on the same frontend web server on which the IIS worker process is running; or they can have the execution manager start each sandboxed process in "remote mode," also known as "affinity mode." In affinity mode, the execution manager looks for a server that is running the SharePoint 2010 User Code Host service and which already has created an application domain inside its SPUCWorkerProcess.exe process for the very same sandboxed solution. (This would be the case if that same sandboxed solution was requested before, possibly by another user on another site collection.) If there is a matching application domain, the request is sent to that same application domain for handling. If none of the servers that are running the SharePoint 2010 User Code Host service already has an application domain for the sandboxed solution, the execution manager assigns the request to the least busy of those servers. The server then creates the needed application domain and processes the request for the sandboxed solution. The application domain stays alive after the request is processed and is reused if there is another request for the same sandboxed solution. By default, all sandboxed solutions that are handled by a given server run in the same sandbox worker process, but this is configurable through the object model. Each sandboxed solution gets its own application domain within the common process, and this, too, is configurable through the object model. The SharePoint 2010 User Code Host service runs in an account that has the same rights as a typical
12 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Note : The CAS policy makes an exception for strong-named Microsoft Office assemblies. These are granted full trust.
2.
Secondly, the sandboxed worker process has a low-privileged security token. The token denies the process the right to read from or write to the file system. The token denies the process the right to call to the network. Therefore, only resources available on the server that is running the sandboxed worker process may be accessed. An external database, for example, cannot be accessed. The token denies the process the right to write to the registry. The token denies the right to call to any assembly that is not in the general assembly cache, even if it has the AllowPartiallyTrustedCallersAttribute attribute and would otherwise be eligible to be called from the sandboxed worker process.
13 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
shim assembly and the standard Microsoft.SharePoint.dll run in a full-trust process, permitted APIs in the SharePoint object model can do some things that would otherwise be forbidden in a sandboxed solution. For example, the GetLocalizedString method can read .resx files even though sandboxed solutions cannot generally read from the disk. (However, a file cannot be deployed to disk in sandboxed solution, so the .resx file would have to be previously installed as a farm solution.)
The following are some of the restrictions on the SharePoint object model that can be accessed: The SPWebApplication class cannot be accessed. Among other things, this means that a sandboxed solution cannot access anything outside its hosting site collection. Almost all classes in the Microsoft.SharePoint.WebControls namespace cannot be accessed, which means that you are mainly restricted to ASP.NET controls in sandboxed solutions.
For a complete list of APIs in Microsoft.SharePoint.dll that are available to sandboxed solutions, see Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions. Important : The deployment
stage of a sandboxed solution itself runs in a sandboxed worker process and is subject to the same execution constraints. For example, you cannot deploy a file to the disk when you are deploying a sandboxed solution. This is the main reason why a user
14 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Resource Usage Restrictions on Sandboxed Solutions Sandboxed solutions are also subject to three kinds of resource usage restrictions that can be organized based on the kind of entity to which the restriction applies and the kind of entity on which the penalty for exceeding the restriction is imposed. Per Request with the Request Penalized: There is a hard limit to how long a sandboxed solution can take to finish. By default, this is 30 seconds. If a sandboxed solution exceeds the limit, the request (but not the sandboxed worker process) is terminated. (This limit is configurable, but only through custom code against the object model. The relevant parts of the object model cannot be accessed by sandboxed solutions, so no sandboxed solution can change the limit.) Per Request with the Process Penalized: A set of 15 resource limits apply to requests. If a request exceeds one of them, the process (and all the sandboxed solutions that are running in it) is terminated. Per Day/Per Site Collection with the Site Collection Penalized: Each site collection is subject to a configurable maximum of daily resource points. These points accumulate based on an algorithm that takes into account the use of resources in the 15 resource categories by the sandboxed solutions that are installed in the site collection. When a site collection exceeds its maximum allowed points, all sandboxed solutions in the site collection are terminated and no more can run for the rest of the day.
SharePoint provides a solution validator framework that can be used to develop custom solution validators, such as a validator that verifies whether a solution is signed with a specific certificate. The validators in a site collection run when a sandboxed solution is activated (that is, deployed, in the terminology used earlier in this article). The activation of any invalid solution is blocked. If a validator is updated or a new validator is added, each activated solution is rechecked by the validators the next time it is executed. Invalid solutions are deactivated. For an introduction to custom validators, see Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010. For more information about the sandbox restrictions, see Sandboxed Solutions in SharePoint 2010 and its child topics and the Microsoft patterns and practices guidelines for Sandboxed Solutions. Figure 5 shows how an HTTP request is handled when it accesses a sandboxed solution.
15 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
The SPUCHostService.exe, SPUCWorkerProcess.exe, and SPUCWorkerProcessProxy.exe files are located at %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. Note : A
solution that is designed to run in the sandbox can be deployed by a farm administrator as a farm solution. It might perform better if it is, because it would run in the IIS worker process instead of the sandboxed worker process.
Not all SharePoint execution is in an IIS worker process, a sandboxed worker process, or the proxy process. The following are some examples: The SharePoint Timer Service (owstimer.exe) runs on all servers and is used to execute prescheduled timer jobs. It runs under the farm account. The SharePoint Tracing Service (wsstracing.exe) runs under the local service account.
16 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Noncompiled files for both kinds of farm solutionsincluding, for example, images, user controls, and string resourcesare deployed to subfolders of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\. Sandboxed solutions are deployed inside a SharePoint solution package (.wsp file) to the Solution Gallery of a specific site collection. Thus, they are deployed and persisted in the site collection's content database. As noted earlier, they do not run in full trust: Instead, they run within a highly restricted CAS policy and can only call a restricted subset of the SharePoint object model. A sandboxed solution can be accessed only in site collections to which it is deployed. When a sandboxed solution is accessed for the first time, such as when a user navigates to a page that contains a Web Part from a sandboxed solution, any assemblies in the solution are unpacked from the solution package and copied to the file system of the server that is handling the sandbox request. The default location isC:\ProgramData\Microsoft\SharePoint\UCCache, but this is configurable on each server that is running the User Code Host Service. (Recall that the server that handles the sandbox request is not necessarily the front-end web server that is handling the initial HTTP request. The User Code Host Service can be run on back-end application servers in the farm instead.) Because the sandboxed worker process cannot copy anything to the file system, the copying is done by the User Code Host Service. The assemblies do not stay in the file cache perpetually. When the user session that accessed the assemblies finishes, the assemblies stay in the cache for only a short time, and they may be reloaded from there if another user session accesses them. Eventually, if they are not accessed, they are removed
17 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
developers, and third-party code should not add, remove, or load anything from the UCCache. It should be accessed only by the SharePoint infrastructure.
Hybrid Solution Techniques The SharePoint solutions architecture includes a technique by which a sandboxed solution can call custom operations that run in full trust. The technique requires that a farm solution be developed that includes one or more classes that derive from SPProxyOperation. Each of these defines an operation that will run in full trust and can be called from sandboxed solutions by using the ExecuteRegisteredProxyOperation method. Specifically, these full-trust proxy operations execute in the same proxy process (SPUCWorkerProcessProxy.exe) that was described earlier in Worker Processes, Farm Solutions, and Sandboxed Solutions. The proxy operations can return data to the sandboxed solution. Like all farm solutions, the assembly with the proxy operations can be deployed only if it is from a trusted source. Figure 6 shows how a request that accesses a sandboxed solution is processed when the sandboxed solution makes a call to a full-trust proxy.
18 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
The preceding description might give the impression that, with the hybrid technique, a farm solution and a sandboxed solution are always developed together by the same development team. In fact, the farm solution may be developed specifically to provide certain operations to any and all sandboxed solutions that need those services, including sandboxed solutions that are developed by other teams. For example, because a sandboxed solution cannot write to the SharePoint Unified Logging Service (ULS) logs, a farm solution that opened proxy logging operations tosandboxed solutions would be very useful. Another hybrid technique uses client-side code to access the resources that cannot be accessed from a sandboxed solution. For example, a sandboxed solution could include a custom site page with JavaScript that makes calls to the SharePoint JavaScript client object model. Also, a sandboxed solution could include a Web Part that hosts a Silverlight application. The latter application can make calls to the SharePoint Silverlight client object model. For more information about the client-side code in SharePoint, see Client Object Models in SharePoint later in this article. For more information about hybrid solution techniques, see Hybrid Approaches.
Note:
Even an uncustomized site page has an entry in the content database; but whereas the entry of a customized page contains the ASPX markup that constitutes the page, the entry for an uncustomized page contains the path of the .aspx file on the local front-end web server. An uncustomized page can be shared by many websites. If it is, it is referenced in each website's
20 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Note:
The terms safe mode parsing, safe mode processing, and safe mode rendering are used interchangeably in SharePoint documentation.
Security and performance are the motivations for the two kinds of pages, especially the difference in processing mode. One of the purposes of SharePoint is to delegate administrative control to ordinary business users instead of requiring the intervention of network administrators and IT professionals. For this reason, users are allowed to add new pages and customize existing pages. If these users were allowed
21 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Security Note:
It is possible to allow inline code, unsafe controls, or both, on selected customized site pages. You can do both things by adding one or more <PageParserPath> elements to the <SafeMode> element of the <SharePoint> section of the web application's web.config file. You can use the attributes of the <PageParserPath> element to specify a customized site page or set of customized site pages, and to enable inline code and unsafe controls for the designated site pages. However, you should use extreme caution when you make these kinds of changes, because they cancel the security benefits of safe mode. For example, if you allow inline code for all pages that have names on the pattern Contoso*.aspx in the directory/sites/contoso/SitePages, anyone with the right to add pages can create a page that has a name following that pattern and add it to that directory, including a page that contains malicious or poor-performing code. (The directory path is a "virtual path" that points to a set of files in the content database.) Notice that allowing unsafe controls only enables such controls that are added in an editing tool, such as SharePoint Designer. When an end user adds a Web Part to a page in the browser, the Web Part must still be registered as safe even if unsafe controls have been enabled in a <PageParserPath> element. You can turn on compilation for selected customized site pages by using an attribute of the <PageParserPath> element. This might be useful if you have reason to believe that the customized page will be visited often enough to justify compiling it into a DLL cached in memory.
Within the category of site pages, there are additional distinctions. In SharePoint Foundation, there are standard site pages and Web Part site pages. Standard site pages are wiki-enabled pages that allow inline Web Parts. Standard pages are objects of a class that derives from WikiEditPage. Web Parts pages, on the other hand, derive from WebPartPage. They have one or more Web Part zones into which Web Parts can be added, and they have no wiki-editable area. SharePoint Server 2010 adds a third kind of site page: PublishingPage. (There is also a PageLayout class in SharePoint Server 2010, but this is an extension of the master page/content page system of ASP.NET, not another kind of site page.)
22 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Caution:
Directly accessing the back-end computer that is running SQL Server by using SQL
23 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
A list can have a column whose possible values are the values of a column on a different list. The lookup column relationship between the lists is somewhat like a foreign key relationship between two relational tables. However, the field on the target list that provides the values is not necessarily the foreign key. All SharePoint Foundation lists have an ID column. This column is, in effect, always the foreign key in any lookup relationship. For more information about lookup relationships in SharePoint Foundation, see Lookups and List Relationships and List Relationships in SharePoint 2010. Lists can be joined just as tables can, but with some restrictions. There must be a lookup relation between the lists or they cannot be joined. For more information about list joins, seeList Joins and Projections. A SharePoint Foundation document library is a special kind of list in which each row includes an attached document, and the other columns are data about the document, such as its author, when it was last edited, and who has it checked out. Picture libraries are similar except that the attached file is an image file. For more information, see Building Block: Lists and Document Libraries.
Every list has a list type, and SharePoint Foundation includes many built-in list types that enable end-users to create the most common kinds of business and team solutions. Among these are Announcements, Tasks, and Calendar. Developers can also create custom list types. For more information about list development, see SharePoint List Data Model. Content Types and Field Types A row in a listthat is, a list itemalso has a type. These are called content types. Each is basically a set of columns and metadata. The simplest is the built-in Item content type. All other content types are derived from Item. SharePoint Foundation includes many built-in content types, such as Event and Announcement. Developers can create custom content types. For more information about content types, see Building Block: SharePoint 2010 Content Types, Content Types, and SharePoint Columns, Lists, and Content Types. A column in a list, also known as a "field," also has a type, and it is distinct from the data type of the values that can be stored in the field. A SharePoint Foundation field type includes not only information about the underlying data type, but also information about how the data is formatted and rendered on forms, such as the forms for creating, displaying, and editing specific list items. For example, it is the field type that determines whether a field value is entered as string or from a drop-down list of values. Many field types are built-in to SharePoint Foundation, such as the Modified By field on a document library and the Due Date field on a Task list. Developers can create custom field types. For more information, see Building Block: Columns and Field Types, Custom Field Types, and SharePoint Columns, Lists, and Content Types. External Lists and the Business Connectivity Service External data, such as data in an SAP installation or Oracle database, can also be represented as a list on a SharePoint Foundation page and within SharePoint Workspace and Microsoft Office client applications.
24 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
25 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
The BDC service is built in conformance with the Service Application Framework of SharePoint Foundation. See also Services and the Service Application Framework and Services Hierarchy later in this article. For more information about BCS architecture, see BDC Architecture, Mechanics of Using Business Connectivity Services, Business Data Connectivity (BDC) Service, and External Data in SharePoint 2010.
Applications that need to consume a particular CFSI of a service do so through proxies. The front-end web server that hosts the application has a proxy to represent the service itself and a second proxy to represent the CFSI that is being targeted. The proxies are not depicted in Figure 8, but Figure 9 shows a single-server SharePoint Foundation farm immediately after installation. Note also the following: Web services that implement the Service Application Framework are represented with a dotbordered box. At initial installation, each has a single CFSI, sometimes called a "service application". The service proxies belong to the farm, but each CFSI proxy (also known as a service application proxy) belongs to a web application. The content publishing web application and the Central Administration web application each have their own proxy for the Business Data Catalog CFSI, and they each have their own for the Usage and Health Data CFSI. Neither has a proxy for the Subscription or Application Discovery and Load Balancer CFSIs at initial installation.
Figure 9. Services, CFSIs, service instances, and web applications in a new single server deployment
27 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
28 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
29 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
SharePoint Security
The SharePoint security system protects deployments from both errant users and errant code. User Security SharePoint Foundation supports security for user access at the website, list, folder, and item levels. Security management is role-based at all levels. The authorization process assumes that the user has already been authenticated, which refers to the process by which the current user is identified. SharePoint Foundation does not implement its own system for authentication or identity management, but instead relies solely on external systems, whether Windows authentication or non-Windows authentication. Authentication SharePoint supports several forms of authentication. The default is Windows claims-based authentication. The claims-based identity model for SharePoint is built upon Windows Identity Foundation (WIF). Under this model, the user presents an identity to your SharePoint farm as a set of claims. One claim could be the user's name, another might be an email address. An external identity system is configured to give SharePoint all the information that it needs about the user with each request, along with cryptographic assurance that the identity data comes from a trusted source. Other types of supported authentication include Windows classic authentication and ASP.NET forms-based authentication. For more information about authentication and SharePoint, see the Getting Started with Security and Claims-Based Identity Model and SharePoint Claims-Based Identity nodes of the SharePoint Foundation SDK.
30 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
34 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
The following kinds of objects are persisted in the configuration database because these classes inherit from SPPersistedObject: SPService SPServiceApplication SPServiceInstance
35 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
For more information about the services object model, see The Services Hierarchy of Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.
Figure 11. Client and server interaction with the client object models
Note:
The Silverlight client object model in SharePoint is not supported on Windows Phone 7.
For more information about the client object models, see the following topics: Using the SharePoint Foundation 2010 Managed Client Object Model Using the SharePoint Foundation Client APIs
37 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Note:
The client object models are not the only way to query SharePoint list data from a client application. SharePoint also supports a WCF Data Services (formerly ADO.NET Data Services) interface to the list data. For more information, see Data Model, Data Management, and Query System earlier in this article. The section Low Level Object Model earlier in this article mentions that the server object model treats content types and their field types in a weakly typed manner, but that the SPMetal tool enables strongly typed programming against these entities. A parallel point applies to client-side computing: Content types are weakly typed in the client object model, but they are strongly typed when you are programming against the WCF Data Services interface.
Workflows in SharePoint
Like all workflows, SharePoint workflows model and systematize business processes. However, SharePoint workflows are generally oriented around the SharePoint list data model. In most cases, each instance of a SharePoint workflow embodies processes that surround an item in a list or document library. Indeed, the most common kinds of SharePoint workflow are workflows that are associated with a list or with one or more content types. Some SharePoint workflows are manually started, but they are most commonly designed to start automatically in response to some event connected with a list item or library item, such as adding, deleting, or updating an item. There are also workflows associated with websites rather than lists or content types. These are always started manually (or programmatically), not automatically in response to some event. In addition, they are generally used to systematize processes that transcend particular list items, such as retrieving and setting values of multiple list items across different lists, or performing non-list operations, such as creating and configuring subsites.
Note:
SharePoint Designer envisages two Reusable and Globally Reusable workflows. These are really just list workflows that you can use on multiple lists without having to re-create them for each of those lists.
Workflows in SharePoint are built on the framework provided by Windows Workflow Foundation (WF). When a workflow is running in SharePoint, the WF runtime engine is hosted in the SharePoint process. The WF runtime engine loads and unloads workflow templates and provides sequencing and persistence for workflows. The persistence services are crucial because they enable workflows to remain active
38 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
You can store these XML files in either of two locations. The first is %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\lcid\Workflow. For example, the template definition of the built-in moderation workflow is stored in the moderationworkflow.xml file. The second location is the Workflows list of the root website of a site collection. The built-in Three-state workflow is an example. Regardless of where it is stored, at run time, the workflow template definition is used to create an SPWorkflowTemplate object, which is cached to speed up the creation of workflow instances. You can associate workflow templates with lists (including document libraries), content types, and websites. For any workflow template that is associated with a list or content type, an item of that list or content type can have an instance of the workflow in progress. Although there can be only one instance of a specific workflow type in progress at any one time for a given item, any item can have multiple workflows in progress, each of a different type. You can create compiled workflows by using the Microsoft Visual Studio workflow designer. You can also create declarative workflows by using SharePoint Designer. Workflows are installed as Features at the site collection level. But you can also "publish" a workflow directly from SharePoint Designer to a website, in which case there is no Feature.
39 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199
Conclusion
Even an article as long as this one cannot cover all the SharePoint architectures or say everything that could be said about the architectures that it does cover. It does provide an overview of the most important SharePoint architectures and should enable you to do further research on each of them.
40 | P a g e
Abad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.sa T: +96614918199 | M: +966545156659 | F: +96614918199