MOSS As An App Dev Platform WP

Microsoft Office SharePoint
Server (MOSS) 2007
As an Application
Development Platform

JANUARY 30, 2007
BY VISHWAS LEE

VISHWAS LELE
Vishwas Lele is Chief Technology officer (.NET
Technologies) at Applied Information Sciences, Inc,
where he has worked for the last fourteen years. In his
current role, he is responsible for assisting organizations
in envisioning, designing, and implementing enterprise
solutions that are based on the .NET technologies.
Vishwas also serves as the Microsoft Regional Director
for the Washington DC area. As a Microsoft endorsed
expert, he is regularly consulted by clients for his insight
and informed perspective on implementing .NET based
solutions.
A regular industry speaker and author, he has presented
at a number industry conferences as well as community
user groups.

2 | Microsoft Office SharePoint Server (MOSS) 2007

TABLE OF CONTENTS
OBJECTIVE ..................................................................................................................................................................... 4
WHY MOSS AS AN APPLICATION DEVELOPMENT PLATFORM? .................................................................................... 4
APPLICATION LAYERS ................................................................................................................................................... 6
Presentation Layers .................................................................................................................................................. 6
Site Definition ...................................................................................................................................................... 6
End User Customization ....................................................................................................................................... 8
Data Access Layer ..................................................................................................................................................... 9
List and Content Types ......................................................................................................................................... 9
Business Date Catalog ........................................................................................................................................ 13
Shared Services Layer ............................................................................................................................................. 15
Shared Service Provider (SSP) Concept .............................................................................................................. 15
OTHER PLATFORM CHARACTERISTICS ........................................................................................................................ 14
Extensibility ............................................................................................................................................................ 17
Provider Model .................................................................................................................................................. 17
Master Pages ...................................................................................................................................................... 17
ASP.NET Forms ................................................................................................................................................... 18
Custom Virtual Path Provider ............................................................................................................................ 18
Workflow Integration ......................................................................................................................................... 18
Business Intelligence (BI) Integration ................................................................................................................. 18
Toolsets .............................................................................................................................................................. 19
Development...................................................................................................................................................... 19
Deployment ....................................................................................................................................................... 19
Non‐Functional Attributes ...................................................................................................................................... 21
Scalability and Reliability .................................................................................................................................... 21
Localization ........................................................................................................................................................ 23
Consistent Object Model ................................................................................................................................... 23
LIMITATIONS ............................................................................................................................................................... 24
CONCLUSION .............................................................................................................................................................. 24
REFERENCES ................................................................................................................................................................ 25
WHO WE ARE .............................................................................................................................................................. 14


OBJECTIVE
The purpose of this white paper is to present Microsoft Office SharePoint Server 2007 (MOSS) as a
development platform for building rich collaborative web applications. First we will discuss the
primary reasons and motivations for utilizing MOSS as an application development platform. We will
then evaluate the specific features that enable companies and organizations to use MOSS as an
application development platform. Finally, we will review and examine some of the fundamental
requirements ‐ such as reliability and scalability ‐ which an application development platform must
meet.
Please note that core concepts described in this white paper are either MOSS features or are features that are
inherited from underlying technologies on which MOSS is based, including Windows SharePoint Services (WSS)
and ASP.NET 2.0. For a detailed feature breakdown, along with the different SKUs, please refer to reference {1 }.
Please also note that in this white paper we will use the term SharePoint to collectively refer to these features.
The primary audience for this paper includes architects, IT managers, and consultants involved in building rich
collaborative web applications. The secondary audience is technical decision makers who want to make the
business case for portals and collaborative web application investments.

WHY MOSS AS AN APPLICATION DEVELOPMENT PLATFORM?

Regulatory compliance requires companies and organizations to securely manage records for long periods of
time in a safe and unalterable state. The appropriate archival of documents is just one component of a larger
records management process that also includes the collection, management, and expiration of corporate
records (information important for the history, knowledge, or legal defense of a company or organization) in a
consistent and uniform manner in accordance with a company’s corporate governance policies.
ASP.NET is a rich platform for building web applications. The latest version (2.0) provides a number of
enhancements including: Master Pages that allows for visual inheritance,Webparts that enable end user
customizable controls, and Provider Model that allows for integrating custom data stores (as opposed to using
AD). Additionally, Microsoft has introduced platforms/products such WSS and MOSS that build on ASP.NET
technology to provide higher‐level building blocks such as the document library and lists, end‐user‐defined
forms, search, personalization and workflow.
The following diagram (Figure 1) illustrates how these technologies stack up. At the bottom of the stack is the
Operating System Services layer that includes the ASP.NET 2.0 .NET framework. Above it is the Core Workspace
Services layer provided by Windows SharePoint Services. This layer provides services such as content storage,
security, administration and navigation. At the top,of the stack lies the Portal layer that provides services such as
search, content management and business data catalog, etc.
There are two primary motivations for choosing SharePoint as an application development platform:
1. The need to provision more than one website based on a logical grouping ‐ such as department, region
or country ‐ rather than have one website that serves all users.
For example, a company needs to develop a web application for its partners that allow them access to
pertinent sales information. It would be perfectly reasonable to start out with an ASP.NET application,
however as the application usage grows, partners would like to customize the site based on their own


unique needs. The partners may want the sales information to surface differently (i.e. grouped by
regions vs. grouped by cities), or they may want to co‐locate additional applications on the same page
(i.e. a tax calculator). Rather than building all of this personalization in code, it is easier to provision a
site for each partner that is based on a single common site blueprint. Each partner can then customize
their site based on their specific needs via a single code base.
2. The need to manage un‐structured content (i.e. documents, web casts, etc.) along with the structured
data stored in a SQL database.
Most modern websites need to manage ever increasing digital content. A distinction between the
structured content and unstructured content is that the former deals with data that can be viewed and
managed using set‐based groupings (database views), whereas, the latter deals with data that is
managed as explicit standalone entities along with the associated metadata. Not only is it important to
manage the integrity and security of standalone entities (such as documents); it is also important to
manage the relationships among them (for instance, the association relationship between a document
and structured application data). Additionally, provisions need to be made to facilitate business process
workflow (routing, approval, regulatory compliance, etc.), and document and folder‐level access control
and search. Again, rather than building these capabilities into an application, it is far easier to rely on
Content Management Services provided by SharePoint.
Figure 1: SharePoint Technology Stack


APPLICATION LAYERS
Like any development platform, SharePoint provides platform elements for building a layered application. Let us
look at the different layers of a SharePoint based application:
PRESENTATION LAYER
Site Definition
Any web application is ultimately a collection of static or dynamically generated web pages. For manageability
and other reasons, the web pages are typically grouped into logical organizational units such as sites or sub‐
sites. WSS has two core entities, SPWeb and SPSite, which support such an organization. A SPWeb entity is a
collection of web pages and can be thought of as a sub‐site. A SPSite is a collection of SPWebs. A sample
hierarchy is depicted in Figure 2 below. In this diagram, http://contoso is the root site (SPSite). Underneath the
root site there is a collection of applications – Report Center, Blog, etc. – that are nested inside the root site.
These are, of course, logical abstractions on top of a physical IIS publishing directory. Multiple SPSites can be
hosted inside one IIS publishing directory. A multiple IIS server farm setup, represented by SPFarm and
SPWebApplication, is also supported. We will discuss server farms later in this paper.

Figure 2: Site Hierarchy


Together SPWeb and SPSite allow the creation of custom web application topologies by defining what is known
as a site definition. A site definition is a blueprint of a web application. For example, a site definition would
include a number of SPWebs and how they are nested. It will also include the structure of individual pages –
such as navigation, contents and custom code ‐ that are part of a SPWeb instance. Once the template or site
definition has been defined and registered, administrators can use them to provision sites. The following
diagram (Figure 3) illustrates the concept of site provisioning.
Figure 3: Site Provisioning
The important thing to note in the above diagram is that all the provisioned sites of a certain type are based on
one common definition, requiring the development team to manage only one template across all sites. In the
event that the site needed to be modified after it has been provisioned, Features allows change to an existing
functionality associated with a provisioned site. Examples of modifications include adding a new control on the
page; updating the workflow logic; and adding a new action menu. Like SiteDefinition, Features is a collection of
XML files that, once registered, becomes available to site administrators.
Site administrators can use screens like the one shown in the Figure 4 below to enable or disable registered
Features. To make modular provisioning easier, Features can be applied at different scopes of the
SPWebApplication, SPSite and SPWeb. For example, a Feature applied at a SPSite scope is automatically
available to all nested SPWebs. Feature referencing, wherein a SPWeb instance references a feature installed at
the SPSite scope, is also supported. Feature referencing makes it possible to change the feature installed at a
higher scope and have that change apply to all nested scopes where the feature is referenced.
For advanced scenarios, there is support for setting up dependencies amongst individual features.


Figure 4: Feature Activation
End User Customization
In the previous section we saw how the site can be provisioned. Individual pages inside a provisioned site can
also be customized using WebParts. WebParts are end user customizable reusable units of UI that implement a
well‐known interface. A canonical example is a stock ticker WebPart. An end user can customize the stock ticker
WebPart by including stocks of interest. End users with the appropriate permissions can personalize a page by
adding or removing WebParts as well by reorganizing the layout of a web page by moving WebParts around. The
biggest benefit of WebParts is the ability to leverage all the WebParts that ship with SharePoint [2]. Additionally,
there is a thriving market for vendors that sell WebPart libraries.
It is easy to develop custom WebParts by deriving from the ASP.NET WebPart class. The SharePoint
infrastructure takes care of infrastructure for personalization. This includes the ability to:
Allow users to add/remove Webparts and personalize them.
Serialize all the Webparts, along with their state, and save them to the content data store.
For detailed information on building Webparts please refer to Figure 8.


DATA ACCESS LAYER
List and Content Types
One of the most important benefits of using SharePoint as an application platform is the ability to use its storage
containers for storing application data, especially in the form of a list ‐ which is the fundamental data structure
in SharePoint.
There are two kinds storage containers inside SharePoint: 1) Administration Store ‐ This store contains data related
to site administration, containing information such as server farm and node setup, etc. ; and 2) Content Store ‐ This
store contains data related to site hierarchy as well as the content associated with the site, including user data ,
layout, menu items, etc. The content database is where most application data will tend to reside. The use of
SharePoint storage containers is centered on the notion of list. A list is a collection of items or rows and can be used
to store application data.
List and List Items are enabled via two core classes SPList and SPListItem. The SPList class represents a generic
list of items or rows. While the SPListItem class, as the name suggests, represents a generic item that can be
stored in SPList class instance. For example, a helpdesk application can store open request tickets in a list (let’s
call it Open Tickets List). Each ticket would represent an individual row instance in the list and can itself be made
up of multiple fields. Each field would represent some information about the ticket (the requestor’s name, date
created, severity, etc.).SharePoint provides the common column types including (string, datetime, integer, etc.)
that can be used to capture the data associated with the ticket. Once the Open Tickets List has been created, not
only is the application storage (and the code to access it ) taken care of, the user interface to add, update and
delete request tickets is also in place without the need to write any custom code. Of course this is a contrived
example. Most applications will need to define fields that represent complex data structures. For example, Open
Ticket may need to store the barcode of the equipment along with a picture as one field. To allow applications
to define custom fields, SharePoint supports the notion of extensible fields. Extensible fields can be defined
using a custom class that inherits from SPField class (or one of the other built‐in classes such as SPFieldChoice,
SPFieldUrl, etc.). The inherited field class can define rendering, data validation, etc.
Custom fields are useful but are inextricably tied to a list. In other words, there is no way to separate the data
schema associated with a custom field from the list it belongs to. Fortunately, there is a notion of content types.
Content types encapsulate a data schema in a reusable manner. Continuing with the previous example, a data
schema that includes the barcode as well as a description can be defined using a content type. Once the content
type is defined, it can be associated with lists to achieve the same functionality as provided by custom fields.
Note that it is also possible to associate more than one content type with a list. Any change made to the content
type will impact all lists that have associations to it.
Content types also support the notion of inheritance. This means it is possible to build a hierarchy of content
types as shown in Figure 5. In this figure Document is the base content type. Content types Dublin Core, Form
and Custom1 derive from Document. So for example, Dublin Core will inherit the schema characteristics of
Document. Any changes to the Document content type will automatically be propagated to Dublin Core and as a
result be reflected in all lists that have associations to Dublin Core.


Figure 5: Content Type & Inheritance
In addition to allowing application data to be captured inside the SharePoint data store, lists provide the
following additional cross‐cutting features that can be used by applications to implement custom functionality:
Alerts allow email notification to be sent out to all subscribers when a change is made to a List or a List item. For
instance, this occurs when items are added, deleted or modified. It is possible to consolidate the email
notifications based on the frequency (daily, weekly, etc). In addition to email notification, RSS‐based
subscription is also available.
Versioning on List, as well as on list items, is supported. This means it is possible to have multiple versions of the
same documents. In addition, users can obtain exclusive right to modify a document using the check‐in and
checkout functionality. Figure 6 shows an example of how versioning can be applied to a document in a list.
Version 3.0 of a document is the public version. A new version (3.1) created from version 3.0 is only available to
a group (Authors). An individual user can checkout the document exclusively, modify it and check it in to create
version 3.2. At a later point in time, a new public version of document (4.0) is published.
Auditing allows applications to track changes made to the List. This includes changes such as security changes,
check‐in/check‐out operation, updates made to associated content types, etc.
Events allow custom event handlers to be fired when a List is changed. For example, Add Item event is fired
when a new item is added to the list. Multiple event handlers for one event are supported. Both synchronous as
well asynchronous event handlers are supported.
Recycle Bin allows deleted list items to be restored. Recycle bin is implemented as a two‐stage process. The first
stage allows user restoration of deleted documents. The second stage is a system‐level document restoration.


Security follows a cascading model wherein permissions flow down from a SPSite to a SPWeb to a SPList.
Security granularity is an item.
Search across one single site or across multiple sites is supported. Fields in the list can be marked as indexed to
improve the query performance.
Let us consider an example that will help us
understand the applicability of lists: Imagine that we
are required to build a web page that displays a list of
webcast recordings. Users with administration
permissions are allowed to upload new webcast
recordings, and update (and delete) existing items in
the list. Other users can only view existing items in
the list. Further, we also have a UI requirement to
customize the list rendering such that in addition to
the name of the webcast and an icon (that allows
users to initiate streaming), the list also allows users
to download the associated presentation slide deck
as well as view the description of the webcast.
One approach for implementing the above
requirement would be to define a webcast content
type that has fields that correspond to the columns
described above. We can then associate the webcast
content type with a SharePoint list. Using CAML
(Collaborative Application Markup Language) we can
customize the UI of the list to meet our
requirements. Note that we could have just created a
list using site columns instead of defining a content
type. The benefit of using a content type is that it is a
reusable type that can be associated to other list
instances. We can also create new content types that
derive from webcast content type. SharePoint uses
ASP.NET forms to allow users to insert and update list
items. All data associated with the list is
automatically stored in the content database. Figure
7 depicts a custom webcast list.
Figure 6: List Versioning


Figure 7: Custom Webcast List
While it may not seem difficult to add a list control on an ASP.NET page and hook‐up some ADO.NET code to
persist the data in the database, it should be noted that we have not written a single line of code thus far. We
have relied on SharePoint list handling and content database to implement the list.
But imagine if we are required to extend the above functionality. For example, it is required that each item of
the list be secured individually. Users also want to subscribe to any changes to the list (new recordings) made to
the list either via RSS or email. From a QA standpoint, a content management process needs to be enforced
when a new webcast recording is uploaded requiring versioning, check‐in/check‐out, and approval workflow.
Content management requirement invariably necessitates the ability to maintain an audit trail of changes as
well as the ability to undelete an item that was inadvertently deleted. Last but not the least, a search function
on the site should include the information about the webcasts.
Now with the need for additional features, the custom ASP.NET solution is not easy. Fortunately, all of the
above functions are provided by SharePoint List by default. We can even extend the SharePoint List
behavior using event handlers.
All of the information stored inside a list is accessible, not only via the SharePoint UI, also via the Object Model
(Class Library as well as Web Service based OM). This means that processes outside the host process can access
the list information – a key to building transparent applications that are reusable.


Business Data Catalog
In the previous section we discussed how application data can be stored inside SharePoint storage. In many
cases however, the application data needs to reside outside of the SharePoint storage. Consider for example a
line‐of‐business application that needs to be integrated into SharePoint. Typically, the line‐of‐business
application will need to rely on a dedicated relational store that can meet its specific storage management
(physical database schema), performance and query optimization, as well as custom reporting needs. For such
applications the Business Data Catalog (BDC) service can be used to integrate data stored in external storage
with SharePoint. By integrating external application data using BDC, it becomes possible to leverage built‐in
SharePoint functions including the ability to add external data to a list, search, security, versioning, etc. Figure 8
illustrates the architecture of BDC.

Figure 8: Business Data Catalog Architecture
Central to the BDC architecture is the notion of a metadata that defines how the external data source can be
integrated into SharePoint. Metadata contains information on how the external data can be accessed. BDC can
access the data directly via a database instance or by invoking a web service‐based interface provided by the
external system. In BDC terminology, each external application is a System. Discrete objects (roughly nouns)
such as customer that are part of external applications are defined as Entities. The operations that can be
invoked on Entities are represented as Methods. Methods can be of different types including a Finder method
(that return instances of an Entity) and SpecificFinder (that return a specific instance of an Entity). The
relationship between Entities, such as master detail, can be modeled as Associations. Figure 9 illustrates the
syntax for setting up the BDC metadata.


Once the metadata is completely defined it can be uploaded into SharePoint. At this point the external data can
be integrated into SharePoint. For example, it is possible to create a list that uses a BDC Entity Customer as a
custom column. It is interesting to note that all of the list semantics, including security, text search, etc., apply to
a BDC‐enabled list. Under the covers, SharePoint is making calls to the external system to obtain the relevant
data about the Entity. Also note that data is not cached inside a SharePoint list.
Up to now we have discussed read‐only access to external data. It is also possible to enable write back to the
external system as well. BDC allows Entities to be tagged with Actions. Actions are link to custom form (InfoPath,
Web, etc.) that can be used submit information back to the external system.

Figure 9: BDC Metadata Example
Once the metadata is completely defined it can be uploaded into SharePoint. At this point the external data can
be integrated into SharePoint. For example, it is possible to create a list that uses a BDC Entity Customer as a
custom column. It is interesting to note that all of the list semantics, including security, text search, etc., apply to
a BDC‐enabled list. Under the covers, SharePoint is making calls to the external system to obtain the relevant
data about the Entity. Also note that data is not cached inside a SharePoint list.
Up to now we have discussed read‐only access to external data. It is also possible to enable write back to the
external system as well. BDC allows Entities to be tagged with Actions. Actions are link to custom form (InfoPath,
Web, etc.) that can be used submit information back to the external system.


SHARED SERVICES LAYER

SharePoint provides a number of building‐block services that are available to SharePoint applications. This
includes services such as the Search Service, Single Sign‐on Service, Forms Services and Excel Services. These
services can provide higher levels of functionality. For example, Forms Service allows applications to add
interactive forms more easily than developing a custom ASPX‐based form.
Before we look at examples of services offered by SharePoint, it is important to understand the concept of
shared services. Shared services can be setup to run outside the process context of the SharePoint application
(in a separate IIS virtual directory). Running the service in a separate process has two benefits: 1) Multiple
applications across different topologies can share one instance of the service, thus reducing the overall load, and
2) Shared services can be administered separately from the SharePoint central administration. This means
shared service administration can be delegated to users without the need to assign them administration rights
on the sites. Figure 10 illustrates the architecture of shared services. There are one or more shared service
providers configured. Each provider can in turn enable one or more services that are shared across SharePoint
applications. Please note, however, that each application can only access one shared provider. One team site
could be accessing a shared provider while another team site could be accessing another provider. A number of
factors go into deciding how Shared Service Providers are setup, including the user load, process execution
times, and topology of sites. For more information please refer to the capacity planning guide on TechNet [9].
The Shared Service Provider model is extensible and can be used to create a custom shared service by deriving
from the SPService class.
Shared Service Provider (SSP) concept

Figure 10: Shared Service Provider
Here is a brief description of the services provided:
Excel Services
Excel Services enable two primary functions: 1) It allows a server‐side rendering of an Excel workbook inside
the browser, and 2) It exposes the calculations within a workbook as a web service endpoint. Each of these
functions can help minimize the need for custom code by enabling business users to contribute some
portion of the application.


Forms Services
Forms Services, as discussed earlier in this section, is designed to make it easier to add interactive forms to a
SharePoint‐based application. Figure 11 illustrates the Forms Services architecture. An InfoPath designer can
be used to design the forms. The completed InfoPath form can then be exposed to the clients by placing
them on the SharePoint sever. Based on whether the client is a rich InfoPath client or a browser‐based
client, automatically adjusts the rendering. For a browser client, a HTML equivalent of the form is rendered.
When the end user submits the completed browser‐based form, XMLHTTP‐based Ajax calls are used to send
the information back to the SharePoint server. SharePoint server in turn posts the information to the data
source (such as web service end‐point) that the form was originally bound to. The rich InfoPath clients can
post information back to the data source directly. The primary benefits of using Forms Services are: the
built‐in forms designer, the data submitted via the form is strongly typed XML, and the ability to render
forms inside a browser (as a standalone HTML page or as part of an ASP.NET page using the InfoPath user
control).
Single Sign‐on Service
The Single Sign‐on (SSO) service provided by SharePoint allows applications to cache credentials to external
systems.
Search Service
As the name suggests, Search Service enables searches across the contents of the site as well as external
data sources. SharePoint‐based applications can incorporate search capability by either leveraging the built‐
in search pages or by programmatically invoking the search web service methods. Using XSLT it is also
possible to transform the results returned by the search service.

Figure 11: Forms Services Architecture


OTHER PLATFORM CHARACTERISTICS

For a technology to be seen as an application platform, it must meet certain characteristics ‐ Scalability,
Reliability and Extensibility [3]. In the following section, we make a case for SharePoint as an application
development platform by highlighting and overview of SharePoint’s key features.
EXTENSIBILITY
According to Wikipedia [4] “extensibility means that the system is so architected that the design includes hooks
and mechanisms for expanding with new capabilities.” One of the major design objectives for SharePoint was to
achieve a tight integration with ASP.NET – the core .NET web application development technology. Tight
integration with ASP.NET has two important benefits for SharePoint developers:
The platform is more approachable as it is based on familiar ASP.NET constructs. For example, SharePoint
routing is implemented using ASP.NET Pipeline, a concept very familiar to the ASP.NET developers, and
It provides the ability to leverage ASP.NET mechanisms for extending the out‐of‐the‐box capabilities. For
example it is possible to use ASP.NET based forms to edit/insert items in the list.
In this section we will look at some of the ASP.NET integration aspects in greater detail.
Provider Model
An ASP.Net Provider [5] is a software module that provides a uniform interface between a service and the data
source. Consider the ASP.NET membership service that provides the functions such as login, password
management, etc. Rather than directly accessing the membership data source, the membership service interacts
with it via a provider. Being squarely based on ASP.NET, SharePoint sites can leverage the membership provider
to store login credentials in a custom store in lieu of the default Active Directory‐based membership store.
Another example where SharePoint can leverage the Provider model is the role provider. Role provider is used
to store authorization information about the users. Please note, however, that SharePoint keeps a copy of
membership and role information in its content database. This is how SharePoint maintains permissions (full
control, read‐only etc.) and roles (administrator, contributor, etc.) that apply to a SharePoint objects (such as a
web site or a list). SharePoint stores this additional information in its content database.
Master Pages
ASP.NET Master Pages allow web page layouts to be consistent across applications. A single master page can be
used to define the look and feel and the standard behavior for a group of pages. The individual pages can then
define the content that needs to be displayed. At runtime, ASP.NET merges the master page layout with the
individual content pages. SharePoint utilizes ASP.NET master pages to allow a consistent look and feel. Figure 12
provides an example of a SharePoint team site master page. Master pages are a design time concept inside
ASP.NET. This means the master page layout of a content page is determined at design time. With SharePoint, it
is possible to dynamically pick an alternate master page from a list of master pages stored in the list called
Master Page Gallery. SharePoint Master Pages can be edited using a WYSWYG editor such SharePoint Designer.


Figure 12: SharePoint Team Site Master Page
ASP.NET Forms
Earlier in the paper, we talked about how content types can be associated with a list. SharePoint provides a
default form template for a list that allows users to either edit existing items in the list or to create new ones.
Developers can customize the default template by providing an ASP.NET‐based custom form template. As you
can imagine, various ASP.NET constructs, such as controls and validators, can be used to build these custom
forms.
Custom Virtual Path Provider
Similar to the provider concept mentioned earlier, ASP.NET 2.0 supports the notion of a virtual path provider.
Virtual path provider allows files with ASP.Net extensions (such as .ASPX, .ASMX, etc.) to be loaded from custom
store (instead of the defaulting to the file system). SharePoint utilizes this extensibility option to build a SQL‐
based virtual provider. SQL virtual provider allows ASP .Net files to be loaded from the SharePoint content
database. This is another example of how a key SharePoint implementation mechanism is based on a service
provided by the ASP.NET layer.
Workflow Integration
Earlier in the paper, we mentioned the need to apply business process (i.e. approval or disposition) to
unstructured content (i.e. documents). SharePoint integration with Windows Workflow Foundation (WF) allows
this capability. WF is a component of .NET 3.0 that provides a programming model for development and
execution of workflow‐based applications. SharePoint utilizes WF to allow workflow to be associated with list


items or documents. For example, it is possible to kickoff an approval workflow when a new document is added
to a document library. The approval process can be based on organizational needs (i.e. a single approver vs.
multiple approvers). Based on the complexity of the workflow to be implemented, it is possible to choose
between VS.NET‐based designer (custom code, multi‐site deployment, etc.), or SharePoint Designer (non‐
custom code, limited to a specific list or document library).
SharePoint acts as a host for WF instances. When users need to interact with the Workflow instance (i.e., a
workflow initiation screen that allows the user to pick approvers for the approval process), it is possible to do so
using ASP.NET forms as well as Forms Services‐based InfoPath forms.
Business Intelligence (BI) Integration
An important portal requirement is the ability to surface Business Intelligence data. SharePoint allows BI data to
be aggregated from different sources such as KPIs (Key Performance Indicators) defined inside SQL Server
Analysis Services, reports defined inside SQL Server Reporting Services, and Excel Services based workbooks. The
easiest way of achieving this integration is via the out‐of‐the‐box Webparts (a number of third party Webparts
provided by BI vendors are also available). These Webparts allow SharePoint pages to consume these sources in
real‐time. If the integration provided by Webparts is not adequate, it is possible to create custom consumers
using a SharePoint‐defined interface. Additionally, filter Webparts can be used to personalize the information
presented to the user. For example, it is possible to connect to an Analysis Services instance and filter the data
based on a dimension such as a region or date. SharePoint also provides a BI site template (called the Report
Center) to make it easy to setup a BI Dashboard.
Toolsets
No application development platform is complete without adequate tooling. In this section we will discuss the
tools you will use for SharePoint development. Unfortunately, this is an area that needs improvement. For
example, many of the common configuration tasks – like installing a custom workflow into SharePoint ‐ require
manually creating feature XML, etc. Hopefully future versions of VS.NET will improve the tooling support.
Development
Visual Studio 2005 is the primary tool for development. As part of the November CTP, Microsoft has released
Visual Studio extensions [11] for developing custom SharePoint applications. These extensions include Visual
Studio project templates for Web Parts, site definitions, and list definitions; and a stand‐alone utility program,
the SharePoint Solution Generator.
Regular VS.NET development techniques of attaching to the w3c process or using debug breaks can be used for
debugging Webparts and other custom SharePoint assemblies. In this sense, SharePoint development is similar
to regular ASP.NET development.
Deployment
The following options are available for deploying SharePoint solutions:
Stsadm
Stsadm is a command‐line tool that allows SharePoint objects such as features and sites to be installed and
activated. Please refer to the stsadm.exe documentation [6]. All the functionality available via stsadm tool is
also available via the SharePoint object model.


Figure 13: Solution based deployment


Solution Packages
Using the command line tool such as stsadm is a convenient way to deploy features individually during
development; however, it does not lend itself well when deploying multi‐featured solutions to a number of
different servers (for testing, staging or production). Solutions can be handy in such situations. Developers
can package all the artifacts (site definitions, assemblies) into a solution package. Figure 13 depicts the
solution‐based deployment. This figure provides an example of a solution that consists of feature manifests
and template files, as well as assemblies. It is possible to define code access security policies that are
associated to a solution. This is a way for developers to assert the code access security permissions needed
for the solution to run successfully. Once the solution package is registered with the SharePoint
configuration databases, administrators can activate them on the servers that make up the server farm.
Windows Installer (MSI)
In many cases it makes sense to use a hybrid approach that combines multiple solution packages with MSI.
This approach allows for combining the power of solution packages with the flexibility of invoking custom
actions, as well as ability to take the advantage MSI functions such as rollback.
NON-FUNCTIONAL ATTRIBUTES
Scalability and Reliability
According to “Characteristics of scalability and their impact on performance” [7], scalability is a desirable
property of a system, a network or a process, which indicates its ability to either handle growing amounts of
work in a graceful manner, or to be readily enlarged. To achieve the desired scalability, SharePoint enables a


variety of topology options that allow for increasing its throughput by adding hardware. SharePoint consists of
the Web Server Tier, Application Tier, and Database Tier, as depicted in Figure 14 and discussed below.
• Web Server Tier. This tier comprises of one or more stateless web server nodes. These nodes can be
load‐balanced using software (Network Load Balancing) or hardware (switch box) schemes. Based on
the scalability requirements, additional web server nodes can be added.
• Application Tier. This tier is a collection of application services such as Excel Services, Search Service,
and Project Server. Many of these services (such as Excel Services and Query) can be installed on
multiple nodes to improve the throughput, as the web server tier automatically load balances the
requests it forwards to the application tier. The other benefit of adding more then one node to the
application is to build redundancy into the system. Note that certain application services (such as Index)
do not support redundancy.
• Database Tier. This tier is where the configuration database and all the content databases reside. Based
on the scalability needs, content can be broken up into multiple instances to distribute load on the
database tier. Clustering or mirroring options are available for supporting redundancy.

Figure 14: SharePoint Tiers


Localization
It is quite likely that the SharePoint applications you develop will need to be localized. SharePoint supports the
following two mechanisms to achieve this localization: 1) Feature Localization – any XML file in a feature or site
definition can be tokenized to allow feature localization, and 2) Language Packs – each solution can define sets
of XML resource files resource binaries, etc. SharePoint will then load the appropriate language pack based on
the locale of the incoming request.
Consistent Object Model
Almost all the services enabled via the SharePoint UI are also exposed via the SharePoint object model.
Furthermore, the object model is available via the class library for in‐process access, as well as a web service
interface for remote access. Figure 15 illustrates a snapshot of web services that relate to the SharePoint store.
Services are available that allow for accessing and manipulating data residing inside SharePoint objects such as
Sites, Lists, etc.
Figure 15: SharePoint Store Web Services


LIMITATIONS
It is important to note that the SharePoint development platform is still evolving, and as a result, there are
always limitations. For example, the end user reporting on list data is not easy unless the list data is transferred
to another reporting‐enabled data source. Similarly, cross‐site searching across large lists can be expensive
because of limited indexing options (for instance, only one column can be indexed). Another area of limitation
related to the lists is the transactional update: there is no way to bracket multiple list operations inside an ACID
transaction. To address many of these limitations with really large lists, you may want to consider placing the
data in an external store and integrat ing it with SharePoint using a service such as the BDC. Finally, a server OS
(Windows Server 2003) is required for SharePoint development. This means that developer workstations need
to be have a server OS (or use some virtualization techniques).

CONCLUSION
According to a Microsoft press release [10], over 75 million licenses of SharePoint were sold until May 2006.
With the momentum of broad adoption behind it, SharePoint has transitioned from a portal product into a
platform for building collaborative web applications. Developers can reap productivity gains by leveraging
building blocks such as built‐in list functions, forms and personalization services, and at the same time, have the
flexibility to drop down into the ASP.NET layer as needed. Many of the collaborative functions needed by
modern websites such as unstructured content management, workflow, and compliance are core platform
services. Applications built on this platform will be in position to leverage future enhancements to the platform
including an expected closer integration with BizTalk Server and Windows Communication Foundation.


REFERENCES
[1] SKU Comparison Matrix
http://download.microsoft.com/download/1/d/c/1dc632e8‐71e1‐466f‐8a2f‐
c940f1438e0a/SharePointProductsComparison.xls
[2] To MOSS or not to MOSS, Web Parts may be the answer
http://www.wssdemo.com/blog/Lists/Posts/Post.aspx?ID=190
[3]. What You Need To Know About Using Office as a Development Platform
http://msdn.microsoft.com/msdnmag/issues/06/08/BusinessApps/
[4] Extensibility
http://en.wikipedia.org/wiki/Extensibility
[5] Provider Toolkit
http://msdn2.microsoft.com/en‐us/asp.net/aa336558.aspx
http://download.microsoft.com/download/2/a/e/2aeabd28‐3171‐4b95‐9363‐
22150625a6a5/aspnet%20provider%20model.pdf
[6] Command‐Line Operations
http://technet2.microsoft.com/windowsserver/WSS/en/library/f9f9a3eb‐ce46‐4dbb‐a15c‐
9fad9eb32ec71033.mspx?mfr=true
[7] ScalabilityAndré B. Bondi, ‘Characteristics of scalability and their impact on performance’, Proceedings of the
2nd international workshop on Software and performance, Ottawa, Ontario, Canada, 2000, ISBN 1‐58113‐195‐X,
pages 195 ‐ 203
[8] A Developer’s Introduction to Web Parts
http://msdn2.microsoft.com/en‐us/library/ms916848.aspx
[9] Planning and architecture for Office SharePoint Server 2007
http://technet2.microsoft.com/Office/en‐us/library/0a7b2b45‐f633‐46d2‐a4fd‐78691d4b8f631033.mspx
[10]SharePoint Server Conference May 2006
http://www.microsoft.com/presspass/press/2006/may06/05‐15SPConference06PR.mspx
[11] Windows SharePoint Services 3.0 Tools: Visual Studio 2005 Extensions
http://www.microsoft.com/downloads/details.aspx?familyid=19F21E5E‐B715‐4F0C‐B959‐
8C6DCBDC1057&displaylang=en


WHO WE ARE

For 25 years, Applied Information Sciences (AIS) has provided software and systems
engineering services to government agencies and businesses around the world. Our
analysis‐driven approach to business problems combined with our commitment
to deadlines and budgets results in successful projects and long‐term relationships
with our customers, employees and partners.

For 13 years AIS has been a Microsoft Managed Gold Partner, the highest partner
relationship offered by Microsoft. Additionally, several key AIS employees have
been selected to be members of Microsoft Partner Advisory Councils. Joining a
select few from around the world, these council members have the opportunity
to review and provide feedback for Microsoft technologies and products. This
unique partner status results in special product trainings and technical readiness
programs years ahead of their market release, enabling AIS to help our clients
prepare with the long‐term planning of their technology evolution.

AIS, Inc. is headquartered in Reston, Virginia with additional offices in Columbia,
Maryland and Austin, Texas.
Contact Us
Corporate Headquarters
11400 Commerce Park Drive
Suite 600
Reston, VA 20191
Phone: 703.860.7800
Fax: 703.860.7820
Central Regional Office
7718 Wood Hollow Drive
Suite 150
Austin, TX 78731
Phone: 512.651.5220
Fax: 512.651.5241
Contact Information by Department Sales
Phone: 703.860.7815

WWW.APPLIEDIS.COM
26 | Microsoft Office SharePoint Server (MOSS) 2007 800‐AIS‐4553

MOSS As An App Dev Platform WP

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MOSS As An App Dev Platform WP

Uploaded by

Copyright:

Available Formats

WHY MOSS AS AN APPLICATION DEVELOPMENT PLATFORM?

DATA ACCESS LAYER

SHARED SERVICES LAYER

OTHER PLATFORM CHARACTERISTICS

You might also like