Differences between WSS and Moss

Microsoft Office SharePoint service 2007 is Microsoft's latest enterprise collaboration application and development platform. Moss for short, Moss is developed based on window shareponit service 3.0, and WSS for short. Moss is charged, and WSS is free. you can install WSS for free as long as you have the Windows server2003 license.

WSS provides website, list, document library, document management, Web part, cluster deployment, intra-site search, and WF-based workflow functions. Moss extensions implement enhanced document management, enterprise search, extended workflows, and web content management, form service, Excel service, and personal websites.

Unless otherwise specified in the following sections, all content is applicable to WSS and moss. All content suitable for WSS must also be suitable for moss, otherwise.

WSS extension to IIS

WSS is developed based on the standard Asp.net 2.0, which is always remembered in WSS development. To be proficient in WSS development, you must be proficient in Asp.net.

Each time a WSS site is created, a website is also created in IIS. We call this website an extended WSS website. So what happened after expansion?

First, all files on the IIS Site are processed by the Asp.net runtime engine. The standard IIS Site only contains files on the Asp.net (such as aspx and asmx) and other files are directly output to the client by IIS.

Check the Web. config file under the site. We can see that there is such a Configuration:

<Httphandlers>

<Removeverb = "Get, Head, post" Path = "*"/>

<Addverb = "Get, Head, post" Path = "*" type = "Microsoft. sharepoint. applicationruntime. sphttphandler, Microsoft. sharepoint, version = 12.0.0.0, culture = neutral, publickeytoken = 71e9bce111e9429c "/>

<Addverb = "options, PROPFIND, put, lock, unlock, move, copy, getlib, proppatch, mkcol, delete, (getsource), (headsource), (postsource) "Path =" * "type =" Microsoft. sharepoint. applicationruntime. sphttphandler, Microsoft. sharepoint, version = 12.0.0.0, culture = neutral, publickeytoken = 71e9bce111e9429c "/>

</Httphandlers>

Httphandler is an extension mechanism of Asp.net. By implementing an httphandler, you can directly program the request and response at the lower layer. WSS can process all the request files on the client through its own httphandler, in addition, the online editing of documents is implemented by extending HTTP requests (such as options, PROPFIND, put, lock, unlock, move, and copy). For the implementation principle of online editing, refer to this article.Article: Http://www.cnblogs.com/jianyi0115/archive/2007/07/15/818566.html

Note This configuration under the httpmodules node:

<Addname = "sprequest" type = "Microsoft. Sharepoint. applicationruntime. sprequestmodule, Microsoft. Sharepoint, version = 12.0.0.0, culture = neutral, publickeytoken = 71e9bce111e9429c"/>

Httpmodule is also an extension mechanism of Asp.net. By implementing an httpmodule, you can switch to a certain stage of the HTTP request to perform corresponding processing, such as identity verification and initialization of some common modules.

WSS implements the sprequestmodule to cut in HTTP requests for some necessary processing. Most importantly, WSS introduces spvirtualpathprovider through sprequestmodule. The oninit method of sprequestmodule contains the following key sentence:

Spvirtualpathprovider provider2 = new spvirtualpathprovider ();

Hostingenvironment. registervirtualpathprovider (provider2 );

Virtualpathprovider is also an extension mechanism of Asp.net. By implementing virtualpathprovider, you can control the provision mechanism of the Asp.net page. The default virtualpathprovider can directly access files on the server hard disk. WSS implements its own page provider mechanism through spvirtualpathprovider-WSS site pages are jointly stored by the file system and database.

After a WSS site is created, all its files are stored on the hard disk. We open a WSS site through shareponit designer and can see the complete directory structure, all these files are actually mapped to a file in the file system. This function is called Ghost. After we modify a file through SPD, WSS will save the modified file to the database. This file is separated from the file on the original file system, which is called unghost. through Ghost, WSS enables different sites to share the same file. Through unghost, WSS enables a site to modify the page without affecting other sites.

WSS concepts

1) farm-server farm

Server farm is the largest concept of WSS. All servers of the entire WSS, including front-end servers and data servers, constitute a server farm. One server farm has a configuration database and multiple Content databases, multiple applicationsProgram..

2) Application -- Application

An application corresponds to a site in IIS. It is an independent entity of Security and program files. That is, an application can have its own user identity authentication mechanism, and has its own independent set of running program files. An application will map to an independent directory on the hard disk, which is generally C: A directory in "inetpub" wwwroot "WSS" virtualdirectories. A single application can have multiple site sets.

3) site collection-site set

A site set is a virtual unit that is independent of content, users, and permissions. A site set can have multiple subsites.

4) web-site

The organizational unit of the site content and permissions. A site can have multiple sub-sites, multiple lists, document libraries, and multiple pages. the site can have independent permissions. A site can have subsites. The sites and subsites form a tree relationship. the sub-site permission is integrated with the parent site by default.

5) List-list and document library

The list can be understood as a database table used to store some business data. A list contains many fields.

The wss3.0 list can store multiple content types.

6) conenttype -- content type

Content types can be understood as data entities, such as users, contacts, and calendar data. A content type contains many fields.

7) Field-field

It can be understood as a database field. field is the underlying element of the WSS architecture.

WSS Object Model

A large part of WSS development is implemented by calling various WSS objects. common objects are stored in Microsoft. sharepont DLL. we usually start with the site set object for development.

Using (spsite site = new spste ("")

{

...

}

The spsite and spweb objects both need to release resources. If we construct these two objects by ourselves, we mustCodeCall the dispose method when execution is complete to release resources.

If our code is in the WSS running environment, that is, the code runs directly on the WSS page, we can get the relevant objects directly from the WSS context.

Spsite site = spcontext. Current. Site;

Spweb web = spcontext. Current. Web;

Spuser user = spcontext. Current. Web. currentuser;

Context objects provide better performance (no need to create objects again) and are directly linked to the identity of the current user. the context object is managed by the running environment, and we do not need to use code to dispose.

Moss2007 built on WSS V3 and added a lot of enterprise-level applications to it. The relationship is shown in:

 

 

From http://blog.csdn.net/figerdeng/archive/2010/04/26/5532029.aspx