White Paper On Moss 2007

J a n u a r y 3 0 , 2 0 0 7

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

b y V i s h w a s L e l e

Copyright 2007 Applied Information Sciences, Inc. All Rights Reserved.

On Time, On Budget, On Target…Every Time!

WHITE PAPER

Copyright 2007 Applied Information Sciences, Inc. All Rights Reserved

2 MOSS 2007 As An Application Development Platform | AIS White Paper

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 implement-

ing 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.

MOSS 2007 As An Application Development Platform | AIS White Paper �

Copyright 2007 Applied Information Sciences,Inc. All Rights Reserved.

CONTENTS

OBJECTIVE ........................................................................................................................................................................................ 4

Why MOSS as an Application Development Platform? ...................................................................................................... 4

Application Layers ......................................................................................................................................................................... 6

Presentation Layer .....................................................................................................................................................................6

Site Definition ....................................................................................................................................................................6

End User Customization .................................................................................................................................................8

Data Access Layer .......................................................................................................................................................................9

List and Content Types ....................................................................................................................................................9

Business Data Catalog .....................................................................................................................................................13

Shared Services Layer ...............................................................................................................................................................14

Shared Service Provider (SSP) concept ......................................................................................................................15

Other Platform Characteristics .................................................................................................................................................. 18

Extensibility .................................................................................................................................................................................18

Provider Model ..................................................................................................................................................................18

Master Pages .......................................................................................................................................................................18

ASP.NET Forms ....................................................................................................................................................................19

Custom Virtual Path Provider .......................................................................................................................................19

Workflow Integration .....................................................................................................................................................20

Toolsets ................................................................................................................................................................................21

Development .....................................................................................................................................................................22

Deployment ........................................................................................................................................................................22

Non-functional Attributes .......................................................................................................................................................23

Scalability and Reliability ................................................................................................................................................23

Localization .........................................................................................................................................................................24

Consistent Object Model ................................................................................................................................................25

Limitations ........................................................................................................................................................................................ 25

Conclusion ........................................................................................................................................................................................ 26

References ........................................................................................................................................................................................ 28


� MOSS 2007 As An Application Development Platform | AIS White Paper

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 scal-

ability - 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 inher-

ited 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 col-

laborative 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?

ASP.NET is a rich platform for building web applications. The latest version (2.0) provides a number of enhance-

ments 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:

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.

1.



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

Operating System ServicesOperating System Services

DatabaseDatabase SearchSearch Work�owWork�ow

ASP.NET (ASP.NET ( Web Parts, Personalization, Master Pages, Provider Model for nav igation, security, etc. ))

Operating System ServicesOperating System Services

DatabaseDatabase SearchSearch Work�owWork�ow

ASP.NET (ASP.NET ( Web Parts, Personalization, Master Pages, Provider Model for navigation, security, etc. ))

Core Workspace ServicesCore Workspace Services

StorageStorage

RepositoryRepositoryMetadataMetadataVersioningVersioningBackupBackup

SecuritySecurity

Rights/RolesRights/RolesPluggable AuthPluggable AuthPer ItemPer ItemRights TrimmingRights Trimming

ManagementManagement

Admin UXAdmin UXDelegationDelegationProvisioningProvisioningMonitoringMonitoring

TopologyTopology

Con�g. Mgmt.Con�g. Mgmt.Farm ServicesFarm ServicesFeature PolicyFeature PolicyExtranetExtranet

Site ModelSite Model

RenderingRenderingTemplatesTemplatesNavigationNavigationVisual BlueprintVisual Blueprint

APIsAPIs

Fields/FormsFields/FormsOM and SOAPOM and SOAPEventsEventsDeploymentDeployment

Core Workspace ServicesCore Workspace Services

StorageStorage

RepositoryRepositoryMetadataMetadataVersioningVersioningBackupBackup

SecuritySecurity

Rights/RolesRights/RolesPluggable AuthPluggable AuthPer ItemPer ItemRights TrimmingRights Trimming

ManagementManagement

Admin UXAdmin UXDelegationDelegationProvisioningProvisioningMonitoringMonitoring

TopologyTopology

Con�g. Mgmt.Con�g. Mgmt.Farm ServicesFarm ServicesFeature PolicyFeature PolicyExtranetExtranet

Site ModelSite Model

RenderingRenderingTemplatesTemplatesNavigationNavigationVisual BlueprintVisual Blueprint

APIsAPIs

Fields/FormsFields/FormsOM and SOAPOM and SOAPEventsEventsDeploymentDeployment

CollaborationCollaboration

DiscussionsDiscussionsCalendarsCalendarsEE --MailMailPresencePresenceProject Mgt.Project Mgt.

““LiteLite ””O�ineO�ine

EnterpriseEnterpriseContent Mgmt.Content Mgmt.

AuthoringAuthoringApprovalApprovalWeb PublishingWeb PublishingPolicy/AuditingPolicy/AuditingRights MgtRights MgtRetentionRetentionMultiMulti--LingualLingualStagingStaging

PersonalizationPersonalization

My SitesMy SitesTargetingTargetingPeoplePeopleFindingFindingSocialSocialNetworkingNetworkingPrivacyPrivacyPro�lesPro�les

SearchSearch

IndexingIndexingRelevanceRelevanceMetadataMetadataAlertsAlertsCustomizableCustomizableUser Exper.User Exper.

BusinessBusinessProcessProcessIntegrationIntegration

Rich FormsRich FormsWeb FormsWeb FormsBiz DataBiz DataCatalogCatalogData in ListsData in ListsLOB ActionsLOB ActionsSingle SignSingle Sign --OnOnBizTalk Integr.BizTalk Integr.

BusinessBusinessIntelligenceIntelligence

Server Calc.Server Calc.WebWebRenderingRenderingKPIsKPIsDashboardsDashboardsReport Ctr.Report Ctr.SQL RS Int.SQL RS Int.SQL AS Int.SQL AS Int.

ProjectProject

TasksTasksSchedulesSchedulesResourcesResourcesBudgetsBudgetsDeliverablesDeliverablesReportsReports

CollaborationCollaboration

DiscussionsDiscussionsCalendarsCalendarsEE --MailMailPresencePresenceProject Mgt.Project Mgt.

““LiteLite ””O�ineO�ine

EnterpriseEnterpriseContent Mgmt.Content Mgmt.

AuthoringAuthoringApprovalApprovalWeb PublishingWeb PublishingPolicy/AuditingPolicy/AuditingRights MgtRights MgtRetentionRetentionMultiMulti--LingualLingualStagingStaging

PersonalizationPersonalization

My SitesMy SitesTargetingTargetingPeoplePeopleFindingFindingSocialSocialNetworkingNetworkingPrivacyPrivacyPro�lesPro�les

SearchSearch

IndexingIndexingRelevanceRelevanceMetadataMetadataAlertsAlertsCustomizableCustomizableUser Exper.User Exper.

BusinessBusinessProcessProcessIntegrationIntegration

Rich FormsRich FormsWeb FormsWeb FormsBiz DataBiz DataCatalogCatalogData in ListsData in ListsLOB ActionsLOB ActionsSingle SignSingle Sign --OnOnBizTalk Integr.BizTalk Integr.

BusinessBusinessIntelligenceIntelligence

Server Calc.Server Calc.WebWebRenderingRenderingKPIsKPIsDashboardsDashboardsReport Ctr.Report Ctr.SQL RS Int.SQL RS Int.SQL AS Int.SQL AS Int.

ProjectProject

TasksTasksSchedulesSchedulesResourcesResourcesBudgetsBudgetsDeliverablesDeliverablesReportsReports

APPLICATIONS/PORTALS

SharePoint Technology Stack

Figure 1: SharePoint Technology Stack



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.

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). Under-

neath 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, represent-

ed by SPFarm and SPWebApplication,

is also supported. We will discuss server

farms later in this paper.

http://http:// contos ocontos o –– Intranet P ortalIntranet P ortal S P W eb

http://http://contos o/DocumentC entercontos o/DocumentC enter –– Document R epositoryDocument R epository S P W eb

http://http://contos ocontos o/R eports/R eports –– R eport C enterR eport C enter S P W eb

http://http://contos ocontos o/HR/HR –– Team S iteTeam S ite S P W eb

http://http://contos o/blogcontos o/blog –– B logB log S P W eb

http://http://contos ocontos o/HR /B ene�ts/HR /B ene�ts –– Team S iteTeam S ite S P W eb

http://http://contos ocontos o/HR /B ene�ts /C omp/HR /B ene�ts /C omp –– Team S iteTeam S ite S P W eb

http://http://contos ocontos o/HR /B ene�ts /C omp/status //HR /B ene�ts /C omp/status / ––Meetings W orkspaceMeetings W orkspace S P W eb

SPSite

SPSite

http://contoso/mysite

http://contoso

APPLICATIONS/PORTALS

Sample Hierarchy

Figure 2: Sample Hierarchy

MOSS 2007 As An Application Development Platform | AIS White Paper 7


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.

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

Users choose site de�nition

Site de�nition de�nes your web application

Site De�nition ProvisioningWebsite

Instances

Eg. http://server/DevCon/Instance of a Team Collab site with features, lists, web parts, views provisioned

Eg. Team Site, Meetings Workspace, Help Desk

WHAT IS PROVISIONING?

Core Component of SharePoint Platform

Figure 3: Site Provisioning



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.

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 remov-

ing 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 [8]

•

•

Feature Activation

Figure 4: Feature Activation



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 contain-

ers 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 render-

ing, 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 Cus-

tom1 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.

F older Item

Doc ument

Dublin C ore F orm C us tom 1

C hild A C hild B

Folder

Form Custom 1

Child A Child B

Item

Document

Dublin Core

Hierarchy & Inheritance

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.



Publish

Check-in

Check-out

3.0-Pubic Version

3.1-OnlyAuthors Can See

3.2-Only UserWith DocumentChecked-outCan See

3.2

4.0

List Versioning

Figure 6: List Versioning

Auditing allows applications to track changes made to the List. This

includes changes such as security changes, check-in/check-out opera-

tion, 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 synchro-

nous 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 restora-

tion of deleted documents. The second stage is a system-level docu-

ment 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 applicabil-

ity 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 require-

ments. 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.



Custom Webcast List

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.

MOSS 2007 As An Application Development Platform | AIS White Paper 1�


Business Data Catalog

In the previous section we discussed how application data can be stored inside SharePoint storage. In many cases how-

ever, 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.

MetadataMetadataB us ines s Data C atalogB us ines s Data C atalog

Lis tsLis ts S earchS earch Us erUs erP ro�lesP ro�les

Databas eDatabas e

WS P roxyWS P roxy ADO.NE TADO.NE T

W ebW ebS erviceS ervice

Lis tLis ts tores tore

S earchS earchIndexIndex

P ro�leP ro�leS toreS tore

MethodsMethods

S ys temS ys tem

E ntitiesE ntities

Associations

Associations

Business Data Catalog (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 inte-

grated 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


1� MOSS 2007 As An Application Development Platform | AIS White Paper

<Entity Name=“Customer”><Methods <Method Name=“GetCustomer”> <MethodInstance Type=“Finder” ... /> </Method> <FilterDescriptors> <FilterDescriptor Name=“Region” Type=“ExactMatch”/> </FilterDescriptors> <Parameters> <Parameter Name=“Region” Direction=“In”> <TypeDescriptor ... AssociatedFilter=“Region”/> ... </Parameter> </Parameters></Methods></Entity><Association Name=“CustomerToOrder“ AssociationMethodName=“GetOrdersByCustomer“> <SourceEntity Name=“Customer"/> <DestinationEntity Name=“Order"/></Association>

BDC Metadata Example

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

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.



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, includ-

ing 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

Web Application 1

Shared Service Provider 1 Shared Service Provider 2

Portal 2 Team Site 1

Web Application 2 Portal 1 WIKI

Shared Service Provider

SharePoint Server Farm

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, forms

services 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

Forms Services Architecture

Figure 11: Forms Services Architecture



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 trans-

form the results returned by the search service.



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 con-

structs. 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 capabili-

ties. 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

1.

2.



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.

Master Page Placeholders

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.

SIDEBAR:

Integrating existing ASP.NET applications

One common question about SharePoint is “How can

I integrate my existing ASP.NET application into a

SharePoint portal?” It is important to understand that

SharePoint is primarily about data (stored in lists, li-

braries, etc.). SharePoint content database can be used

to store all kinds of data – documents, calendar events,

and even a web page. However, SharePoint puts some

restrictions on what you can store as part of a web

page. For example, code behind assemblies cannot be

stored inside the content database. Another restriction

SharePoint places on an application ASP.NET page

is that it must inherit from a WebPartPage. One

approach for integrating existing .ASPX pages is to

convert them into one (or more, based on how the

ASPX is structured) ASCX controls. The markup to

include ASCX controls can then be placed on a no-

code ASP.NET page that inherits from WebPart-

Page class, thus adhering to SharePoint restrictions.

The code behind, associated with ASCX control, can

be placed inside the global assembly cache or the

bin directory of the application. The latter requires

Continued on page 21



that appropriate trust levels are set and controls are

marked as safe.

Integrating an existing ASP.NET application is

more than just hosting the pages inside SharePoint.

You will need to adjust the master page to make

the application pages consistent with the rest of

the SharePoint pages. You will probably also want

to leverage the SharePoint navigation and menu

controls to integrate application actions.

Finally, you will need to evaluate the need for includ-

ing custom role and membership providers instead of

relying on Active Directory (AD). For example, an

Internet-facing ASP.NET application is likely to be

based on a custom user store rather than AD. When

integrating such an application into SharePoint, you

will probably need to build a membership provider

that interfaces with the existing custom user store.

The other option would be to look at the Single

Sign-on Service provided by SharePoint.

Continued from page 20

SIDEBAR:

Integrating existing ASP.NET applications

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 in-

tegration 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.

Solution Deployment

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 test-

ing, 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.



SharePoint Tiers

Figure 14: SharePoint Tiers

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.

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.

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-

Store Web Services

Figure 15: SharePoint Store Web Services



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 virtualiza-

tion 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



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] Scalability

André 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


Corporate HQ & Eastern region11400 Commerce Park Drive Suite 600Reston, Virginia 20191P: (703) 860-7800

Central region7718 Wood Hollow Drive Suite 150Austin, Texas 78731P: (512) 651-5220

www.Appliedis.com800-AIS-4553

On Time, On Budget, On Target…Every Time!

AppLIED INfOrMATION SCIENCES

Applied Information Sciences (AIS) is a highly regarded

system and software engineering firm. Our mission is to create

and maintain an environment that fosters trusted, value based

relationships between our personnel, partners and clients. Go-

ing on 25 years, we’ve achieved this goal by focusing on specific

markets and solutions and investing in our people to be leaders

in our chosen field.

AIS has built a flawless reputation for technical excellence by

succeeding in every project we undertake. Very few companies

possess our breadth of experience and success in applying a

process oriented approach to systems and software engineering

projects. We deliver On Time, On Budget and On Target;

Every Time. AIS clients include Fortune 100 corporations as

well as Federal, State and Local Governments.