|
Sharepoint 3.0 is an add-on for
Windows Server™ 2003. At its
core, Sharepoint acts as a scalable
site-provisioning engine,
easing the process of
creating and managing
hundreds or thousands of Web
sites and making them
accessible to tens of
thousands of users.
Sharepoint
scalability is achieved by
using an architecture
designed with a Web-farm
environment in mind. This
architecture is based on
stateless front-end Web
servers that rely on SQL
Server™ for storing content
and other site-related data.
The added value Sharepoint brings
to the ASP.NET 2.0
development platform results
from its extensibility
model, which facilitates
provisioning and storage for
pages, lists, and document
libraries. The provisioning
can be driven through either
custom code or user actions
in the browser-based UI.
Behind the scenes,
Sharepoint
automatically works out how
and where to store the
content, and it also
supplies the UI elements
that let users add, view,
and modify content.
I’m going to concentrate on
the most significant
developer enhancements to
version 3, and on the
accompanying changes in
terminology. Keep in
mind that research and code
samples for this article are
based on the Beta 1 release
of Sharepoint. It’s possible that
some of the terms and code
might change in the released
version.
Integration with ASP.NET 2.0
Sharepoint 3.0 provisioning starts with an
IIS Web site. Before you can
create your first Sharepoint site,
you need to run an
administrative procedure
that extends the Sharepoint
functionality to one or more
IIS Web sites. With
Sharepoint 2.0,
the term "virtual server"
was used to describe an IIS
Web site extended with
SharePoint functionality. To
avoid confusion with another
Microsoft product of the
same name, the Sharepoint 3.0
documentation now refers to
an IIS Web site extended
with Sharepoint functionality as a
Web application.
Sharepoint 2.0 was integrated with
IIS 6.0 and ASP.NET 1.1
using an ISAPI filter DLL,
which resulted in IIS
routing requests to
Sharepoint
before ASP.NET. That routing
could be problematic in
certain situations because
Sharepoint takes control of an
incoming HTTP request before
it has had a chance to be
properly initialized with
ASP.NET context.
But Sharepoint integration with
ASP.NET has been completely
redesigned in version 3.
First, Sharepoint 3.0 is built on
ASP.NET 2.0, which provides
significant enhancements
over ASP.NET 1.1.
Furthermore, the routing
infrastructure was improved
by removing the ISAPI filter
and by adding an HttpModule
and an HttpHandler that are
registered with ASP.NET
using standard web.config
entries. This means that
incoming HTTP requests
always enter the ASP.NET
runtime environment and are
fully initialized with
ASP.NET context before they
are forwarded to the code
that carries out Sharepoint-specific
processing.
When you extend an IIS Web
site to become a Web
application, Sharepoint 3.0 adds a
wildcard application map to
the IIS metabase. This map
routes all incoming HTTP
requests to the ASP.NET
runtime regardless of file
type (.pdf, .doc, .docx, and
so on). ASP.NET then
forwards the request to
Sharepoint
for processing.
The new architecture also
deals with shortcomings
related to how .aspx pages
are parsed and compiled. The
.aspx page parser used by
ASP.NET 1.1 works only with
pages that reside on the
local file system. But
Sharepoint
architecture relies on
storing .aspx pages in a SQL
Server database so it
couldn’t take advantage of
the ASP.NET 1.1 page parser.
And, unfortunately, the
SharePoint parser developed
in its place does not
support many of the cooler
features offered by the
ASP.NET page parser.
But ASP.NET 2.0 introduced a
new pluggable component type
known as a virtual path
provider. The idea is that a
developer can write a custom
component that retrieves .aspx
pages (or any other content
that ASP.NET processes) from
any location, including a
database such as SQL Server.
Once a custom virtual path
provider retrieves an .aspx
page, it can then hand the
page off to ASP.NET to
conduct the required parsing
and compilation. A separate
component, PageParserFilter,
lets SharePoint control how
pages are parsed and
compiled and what executes
on those pages.
Sharepoint 3.0 includes its own
virtual path provider named
SPVirtualPathProvider, as
illustrated in Figure 1. As
you can see,
SPVirtualPathProvider is
able to retrieve .aspx pages
from SQL Server and then
hand them off to the .aspx
parser that is supplied by
ASP.NET 2.0. As a result,
Sharepoint 3.0 does not suffer from
a reduced feature set with
respect to page parsing as
did the previous version of
Sharepoint.
More information can be found at:
http://msdn.microsoft.com/msdnmag/issues/06/07/Sharepoint30Preview/default.aspx
|