This graphic shows the services, CFSIs (configured farm-scoped instantiations), and service instances on a hypothetical 10-server farm. Note the following things about this example:

• The translucent rectangles represent services. These services are modeled in the SharePoint Foundation object model with SP*Service classes.

• The darker translucent rectangles represent CFSIs ("service applications") that are modeled in the SharePoint Foundation object model with SP*ServiceApplication classes.

• The smaller, solid rectangles represent instances of services that are modeled in the SharePoint Foundation object model with SP*ServiceInstance classes.

• The Diagnostics Service has instances running on all servers (except the dedicated database server), but the object model has no SPDiagnosticServiceInstance class (because there is no need for one in SharePoint Foundation), so there are no sold rectangles for these instances.

• The Administration, Timer, Workflow Timer, User Code, Diagnostics, and Usage services run on all servers (as they must), except the dedicated database server.

• Only the five front-end Web servers run the Web Application Service.

• There is a dedicated search server.

• There are two dedicated Business Data Connectivity (BDC) servers.

• The BDC service has two CFSIs (service applications). One has an instance on each of the dedicated BDC servers, but the other is running on just one of them. The front-end Web servers must have separate service application proxies targeting these two different CFSIs.

• A fourth, multipurpose application server runs Central Administration, the e-mail services, the subscription service, the security token service, and the application discovery and load balancer service. Since the Central Administration Web service hosts a Central Administration Web application, this server would also have service application proxies running on it if it needed to consume any of the services that implement the Service Application Framework. This is an exception to the usual principle that consumer proxies in the framework run on front-end Web servers.

• When the SharePoint Foundation databases are on a dedicated server, as in this case, SharePoint Foundation need not be installed on that server. The Database Service is just a wrapper for the SQL Server service running on the database server. Hence, SharePoint Foundation code is not running on the dedicated database server. The service and its instance appears in the figure because it is represented in the object model with the SPDatabaseService and SPDatabaseServiceInstance classes.

For more information see Background: Service Entities in Microsoft SharePoint Foundation​

This diagram shows where supported extensions fit into the PerformancePoint Services architecture. The front-end web server hosts custom editors, web services, and other web applications, and the back-end application server hosts custom renderers, providers, and scorecard transforms. For more information, see Development Scenarios with PerformancePoint Services, PerformancePoint Services Architecture, Getting Started with PerformancePoint Services, and Fundamentals of PerformancePoint Services.

This diagram shows the high-level architecture of PerformancePoint Services in Microsoft SharePoint Server 2010 Enterprise. Its multi-tiered architecture includes components on the client tier, the front-end Web server, and the back-end application server. For more information, see PerformancePoint Services Architecture, Getting Started with PerformancePoint Services, and Fundamentals of PerformancePoint Services.

Note the following about this graphic:

• The User Code Service (SPUCHostService.exe) creates the sandbox worker processes and assigns each HTTP request to a sandboxed solution to one of these processes.
• A sandbox worker process (SPUCWorkerProcess.exe) is the process in which custom code that is a part of a sandboxed solution executes. 
• A full trust proxy process (SPUCWorkerProcessProxy.exe) hosts the portion of the SharePoint object model that sandboxed solutions can access and enables second stage calls to the rest of the object model.

For more information, see Sandboxed Solutions Architecture, Sandboxed Solutions​, Sandboxed Solutions Execution Model, and Chapter 4: Sandboxed Solutions.

The illustration depicts the flow of actions associated with synchronous and asynchronous before and after event handlers in SharePoint Foundation 2010. Handlers for synchronous events (all Before events are synchronous) are called in their sequential order in the main thread–-that is, in the thread in which the user action occurred. Their sequence order is determined by the value of the sequence number property (SPEventReceiverDefinition.SequenceNumber) for each event. This applies to both Before and After synchronous events.

On the other hand, event handlers for asynchronous events (After events can be asynchronous or synchronous using the SPEventReceiverDefinition.Synchronization property) behave differently. First, they execute in a different thread from the one in which the triggering action occurred. Furthermore, successive asynchronous event handlers execute in successive threads.

Second, although asynchronous handlers are initiated in sequential order (again, based on the SequenceNumber property), there is no guarantee that they will execute or be completed in that same order. Note, too, that handlers for an asynchronous After event can start at any time after its triggering action occurs.

For more information about events, see the following resources in the SharePoint 2010 SDK:

• Events in SharePoint Foundation 2010
• Introduction to Events in SharePoint Foundation 
• Creating an Event Handler
• Table of SharePoint Events, Event Receivers, and Event Hosts
• Event Receiver Methods Compared:  Windows SharePoint Services 3.0 and SharePoint Foundation 2010

This diagram shows the platforms on which SharePoint Server and SharePoint Foundation are built.

• The boxes with a blue fill represent independent platforms and each depends on the platforms below it.
• The empty boxes inside the larger boxes are selected important subparts or features of the platform.
• The thin downward arrows indicate selected dependency relations. Not every sub-platform or dependency relation is shown.
• The thicker, green, sideways arrows indicate that one entity accesses the entity to which the arrow points. Again, only some selected access relationships are shown.

For more information, see Conceptual Overview of SharePoint Foundation and its child nodes.​

Welcome to the SharePoint in Pictures blog! On this blog, you will find diagrams that visualize SharePoint as a development platform. These diagrams will include various object models, application stacks, network topologies, user interface extensions, and highly customized SharePoint sites. Each diagram will have a small description along with links to more in-depth information on Microsoft Developer Center (MSDN). A new diagram will be posted on a weekly basis.

Your feedback is very important! Feedback helps with the creation of future diagrams and helps improve the SharePoint Software Development Kit (SDK) and the SharePoint content on MSDN. One of the goals with SharePoint in Pictures is to make the SharePoint developer content more visual rather than text-based as it is now. A few questions to think about while viewing these diagrams:

• Were the diagrams helpful?
• How can they be improved?
• Are there areas that were missed in these diagrams? 

If you have an idea for a diagram, please provide the ideas using the feedback form.

I hope you enjoy SharePoint in Pictures, and I look forward to sharing ideas and getting your feedback. Enjoy!