1. Enterprise Architecture
When the enterprise architecture plan for SharePoint 2010 was
being developed, the following core concepts were central to the
long-term vision for success. The team wanted a product architecture
that would be
Modular
Extensible
Scalable
1.1. Modular
The architecture of
SharePoint 2010 is highly modular—that is, it is composed of separate
parts—which represents a separation of concerns that improve the ability
to maintain the product by enforcing logical boundaries between
components. Central to a modular architecture is the concept that each
modular component has minimal dependency on other components. This
allows the larger application to be broken down into smaller component
modules that, although they are not dependent on each other, come
together to form the larger application.
Another feature of
module architecture is the ability to reuse each module when needed as a
building block for higher-level application elements. For example, the
User Profile Service exists as a composition of various modular
components. Each of those components potentially can be reused to create
other services as well. Higher-level application components lay on top
of the User Profile Service and its components.
Each separate encapsulated service within the system is connected through a set of common rules and standards known as a provider framework.
This allows the underlying services to be exposed for presentation,
management, and deployment processing. These services are the building
blocks on top of which the application rendered in the browser becomes
available.
1.2. Extensible
Extensibility is an
architecture and design principal ensuring that an implementation takes
future growth into consideration. Planning for future growth within the
current architecture can minimize the effects of future changes.
Extensibility provides integration capability that can be utilized in
the implementation of future change or enhancement.
The architecture of
SharePoint 2010 is highly extensible. In fact, many of the underlying
components are built with an exposed application programming interface
(API). As expected, these interfaces are available to third-party
developers through the release of a software development kit (SDK).
Furthermore, the product teams developing SharePoint also use this
extensibility when developing many of the user-facing features of the
product. Many included product features are delivered as SharePoint
Features and Feature Elements, which represent extensions to the modular
building blocks that form the base architecture of the system.
1.3. Scalable
One
of the most important aspects of the overall system architecture for
SharePoint 2010 is scalability. Microsoft wanted to be sure that the
deployment of the software could be tailored to the specific anticipated
needs of each individual implementation. SharePoint 2010 provides you
with the ability to scale both out and up to meet the specific demands
of your implementation. If you need more user interface capacity, you
can add more Web front-end servers. If you need additional service
capacity, you can add more application servers. If you need additional
database capacity, you can add a database server. If you need to be able
to handle more file caching or larger upload file sizes, you can add
more system resources to existing servers. Whatever your particular
needs, SharePoint 2010 allows you to design a topology that meets those
needs with almost limitless flexibility.
2. Logical Architecture Components
The
system architecture of SharePoint 2010 allows many of the application
tier services to leverage the same underlying common services, such as
storage and security. This allows for the uniform management of these
services across the enterprise.
Likewise, the presentation layer components share compatibility with
the application tier services. This ensures that the entire service architecture is grouped logically both from the bottom up and from the top down.
From the bottom up, the
architecture is organized into a set of independent services, whereas
from the top down, the architecture is organized into a set of
applications that use those services. The grouping of services into
applications has simplified both the administration and the deployment
of SharePoint 2010.
2.1. Service Architecture
With SharePoint Server 2007,
Microsoft went to great lengths to move toward service-oriented
architecture (SOA). Although the spirit of SOA was embodied within the
product through the Shared
Services Provider (SSP), having a single service application endpoint
through which multiple services were exposed led to limitations. For
example, most of the underlying interfaces for the SSP
were not extensible by third parties, making it impossible to create
your own services for use within the architecture. Other limitations,
such as the inability to consume services including search and user
profiles across the wide area network (WAN), also hampered the concept.
In SharePoint 2010,
the service application architecture has been completely reorganized.
The SSP concept has been abandoned in favor of a federated type of
service application architecture that allows separate services to work
together efficiently.
Note:
Federation
is the standardization of information systems and their means of
interconnectivity, allowing user’s data in one system to be transferred,
and used by, another system.
The service architecture is based on two main components, the service
application and the application proxy or connector. The service
application is the manifestation of the actual service itself, which is
reliant on a service instance running on an application server. The
service is self-contained in that it includes both the functionality
and the administrative interfaces for managing the service. The service
is exposed to other applications using an endpoint that is made
available through a service proxy. Each application connects as a client
to the proxy, which in turn takes requests from the application and
makes requests of the service on behalf of the application.
This architecture is incredibly flexible and extensible, allowing third parties to create service
applications for use within the architecture, as well as providing for
the consumption of those services across the entire enterprise. For
example, this architecture could allow a single User Profile Service
application that is consumed by multiple farms in different geographical
locations.
Table 1 represents the service applications included with SharePoint 2010 by default.
Additional service applications are present, but those listed in this
table are the only ones that are configurable through the SharePoint
Central Administration interface.
Table 1. SharePoint 2010 Service Applications
| SERVICE APPLICATION | EXPLANATION |
|---|
| Access Database Services | Provides server-side processing and rendering of data stored in Microsoft Access databases. |
| Business Data Connectivity | Provides server-side access to line-of-business application data. |
| Excel Services | Provides server-side processing and rendering of data stored in Microsoft Excel spreadsheets. |
| Managed Metadata Service | Provides enterprise taxonomy, managed metadata storage, and content type syndication. |
| PerformancePoint Service Application | Provides Business Intelligence functionality previously provided as part of Microsoft PerformancePoint Server. |
| Search Service Application | Provides unified content crawling and indexing as well as federation. |
| Secure Store Service | Replaces the single sign-on (SSO) feature. |
| User Profile Service Application | Provides user profiles, user profile synchronization, My Site settings, and social tagging. |
| Visio Graphics Service | Enables dynamic viewing, refreshing, and sharing of data-driven Microsoft Visio 2010 diagrams. |
| Web Analytics Service Application | Provides Web analytics and usage analysis. |
| Word Automation Services | Provides server-side conversion of documents into formats that are supported by the Microsoft Word client application. |
Figure 1
illustrates the larger logical component and application architecture
of SharePoint 2010. In the following sections, you will review each of
the logical components presented in the figure, to provide you with more
detailed information about how the various service and components fit
together to form the SharePoint product.
2.2. Operating System Services
Windows Server
2008 provides the underlying architecture for the entire product.
SharePoint 2010 requires the Windows Server 2008 64-bit edition and will
not run on Windows Server 2003 32-bit or 64-bit editions.
The operating system
provides access to storage, system level execution rights, and Internet
Information Server 7.0 (IIS), on which the SharePoint service
application and Web processes run. By separating the underlying
operating system’s logical architecture and management from the service
architecture of SharePoint 2010, the application remains abstracted from
the operating system, and therefore largely isolated. This helps
separate the management of the operating system from the management of
the application, and it follows good architecture practices. It also
provides the application architecture more flexibility to run on future
version of the operating system.
2.3. Database Services
SharePoint 2010
stores both configuration and content in Microsoft SQL Server databases
and provides a common storage architecture across the entire system.
This removes the incompatibility issues associated with multiple
disparate database systems. Although you can enable external storage of
binary large objects, this requires additional setup and configuration;
the out-of-the-box product uses SQL Server for content storage.
SharePoint 2010 can run on Microsoft SQL Server 2008 or Microsoft SQL
Server 2005, although SQL Server 2008 is recommended because of new
database mirroring and external storage capabilities.
2.4. Workflow Services
A hallmark capability of
SharePoint 2010 is the workflow engine. Workflow services provide
workflow capabilities exposed to end users in the system, as well as the
ability for the system to execute tasks needed to facilitate
administration of the system. Workflow services also facilitate the
automation of the content life cycle for documents, including approval,
publishing, and disposition. In SharePoint 2010, workflow services are
provided by Windows Workflow Foundation (WF), which is part of the .NET Framework 3.5.
2.5. Supporting Services
The supporting services shown in Figure 2-1
include Web Parts, Personalization, Master Pages, and the Provider
Framework. These services are provided by the .NET Framework and ASP.NET
3.5. These dependencies provide the underlying process architecture
within which most of the SharePoint 2010 application services run.
2.5.1. ASP.NET 3.5
ASP.NET 3.5 is a Web
application development framework that was first introduced by Microsoft
in 2002. It allows developers to build highly dynamic websites,
applications, and services. SharePoint 2010 has been built on top of the
ASP.NET 3.5 Framework, and consequently uses the Framework as a
provider of many core functionalities provided in the product. Rather
than create a custom rendering engine, the team at Microsoft wanted to
ensure that the page rendering and extensibility framework of ASP.NET
3.5 was employed within SharePoint 2010 both to enhance performance and
as a way to provide third-party developers with a well-defined
technology platform for integration and extensibility.
In addition to providing a
native page rendering engine, which renders pages on behalf of
SharePoint 2010, ASP.NET 3.5 provides code execution security features
such as the Safe Mode Parser and Safe
Controls List. The Safe Mode Parser ensures that only code that is
authorized for execution will be run on the server side. This ensures
that inline code included in content pages uploaded to a site will not
be executed. Administrators can control the compilation of pages within
the Web.config file and specify the scope through which application
pages can be rendered. The Safe Controls List provides administrators
the ability to specify which controls are safe for execution on the
server. This is done by using the bin directory on the server for a
given Web application.
2.5.2. Web Parts
The Web Part Framework
used within SharePoint 2010 is inherited from ASP.NET 3.5. This provides
additional flexibility for developers as well as a standard interface
for the rendering of Web Parts within the system. Web Parts are modular,
reusable, application server controls that can be added by end users at
run time using the browser. Web Parts allow for end users to control
the content, appearance, and behavior of the page. Web Parts can be
dropped into a well-defined Web Part zone, which is a basically a
designated place on the page within which Web Parts can be arranged and
used. In specific circumstances, Web Parts also can be used within
content areas on publishing pages. This capability is new in SharePoint
2010.
A Web Part consists of an
assembly control that is installed on the server side and a Web Part
Descriptor file. The assembly must be marked as a safe control for
execution and must be stored either in the Global Assembly Cache (GAC) or in the Web application’s bin directory. The assembly provides all of the functionality
of the Web Part, such as the placement of content configured for a Web
Part instance and what to do with the configuration settings specified.
The Web Part Descriptor file is an XML file that provides the capability
to export and reuse the configuration settings and content stored
within a Web Part instance. Each Web Part used on a page is the
application of the stored descriptor file being laid over the
server-side assembly. Users cannot upload Web Parts directly to the
server but can apply exported descriptor files through import to
instantiate a new instance of a Web Part already installed on the
server.
2.5.3. Personalization
SharePoint 2010 provides a rich
set of features and functionalities for personalization. Users can
personalize Web Part Pages and list views
so that they see their personalized view of the content stored in a way
that meets their own needs. The content is shown through what is called
a personal view
of the content, as opposed to the shared view that is available to other
users. Administrators can specify if users should be allowed to create personal views of content within a given Web application, site collection, site, or list.
SharePoint 2010 adds
new social features that enrich the personalized experience for end
users, making it easier to establish their own personal identity with
the organization as well as to connect with others. Additionally, users
can target content to specific groups or users with audience targeting,
making that content appear only to those users when viewed from the
browser.
Note:
Audience targeting is not
meant to be used as a security measure. The content that is targeted is
still present in the content page or Web Part Page, so it will be
viewable to users who have access to those pages in edit mode.
2.5.4. Master Pages
Master pages are also
derived from ASP.NET 3.5. Master pages provide a structured content
presentation framework for all pages within a given site or site
collection. Designers can define specific content areas within a master
page for used by page authors. After they are defined, master pages are
used in conjunction with layout pages. Layout pages provide an even more
detailed definition of how content may be rendered on a page. Only the
content areas defined on a master page can be used within a layout page
at design time. Only the content areas and/or elements (such as Web Part
zones) specified within the layout page can be used by the page author
when creating or modifying the page.
Together master
pages and layout pages provide a uniform way for designer to present a
consistent look and feel through a site, maintaining that experience
over time. Master pages and layout pages are stored at the root of each
site collection. Publishing sites provide additional flexibility and
functionality in both master pages and layout pages.
2.5.5. Provider Framework
A provider
framework is a set of rules and guidelines for communication between
otherwise isolated system elements. Services are offered by providers
using these rules and standards.
SharePoint 2010 uses services
provided by the operation system, such as storage and security.
SharePoint 2010 also uses services provided by IIS 7.0 and ASP.NET 3.5.
You have seen how these services lay over one another to provide the set
of unified services needed by SharePoint 2010. But how does SharePoint
consume these services, and how does IIS get what it needs from the
operating system? Because these services are provided through a
framework, they can leverage the well-defined standards and guidelines
for communication. This makes it possible to integrate additional
services and elements at a later time that can also leverage underlying
services and provide services to application level components.
The
.NET Framework provides the set of rules and guidelines used by
SharePoint 2010 for communications between services and application
elements. Based on a
common language runtime (CLR), the .NET Framework provides a flexible
development environment for creating new application components and
allowing them to interface with other dependent services or objects.
Combined with its enforcement of code security and trust, managed code,
and runtime complication of code for different processor architectures,
the .NET Framework offers a solid set of standards that can be used by
developers and vendors alike for the creation of interoperable
components that will fit into an integrated provider framework.
