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       

3 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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     

4 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

   

5 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

 

 

   

6 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.     

7 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  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.   

   

8 | Microsoft Office SharePoint Server (MOSS) 2007    

 

  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.  

 

   

9 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  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.  

   

10 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

   

   

11 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  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.      

 

   

12 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.       

13 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.   

 

   

14 | Microsoft Office SharePoint Server (MOSS) 2007    

 

  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.      

15 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

   

16 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.   

   

17 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  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     

18 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.     

19 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  Figure 13: Solution based deployment 

       

20 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

  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     

21 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

   

 

   

22 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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 

 

   

23 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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.

  

 

 

   

24 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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   

 

   

25 | Microsoft Office SharePoint Server (MOSS) 2007    

 

 

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