十几年前, 许多公司刚刚开始学习因特网技术, 不断发掘他们使用基于HTML的内容来联系客户的能力. 那时, 许多公司仅维护一个单个的面向公众的网站. 想要广告自己的产品和服务, 这样的站点也就足够了.
时代已经不同了. 今天的公司们使用网站的目的不仅仅是联系客户了, 还包括为供应商, 雇员和高级管理人员提供应用程序. 现在一家大公司创建上百甚至上千个网站已经不是什么不寻常的现象了. 比如说, 某些大公司甚至有为每一个市场活动和每一个雇员创建一个网站的需求.
在一个没有SharePoint产品和技术的世界里, 一家公司要满足这样的需求, 不断的创建和管理网站, 无疑是非常费时和昂贵的. 让我们拿创建一个用来跟踪销售趋势和客户的站点来做个例子吧.
首先, 这个过程需要一个数据库管理员在SQL Server或者其他的DBMS中创建一个新的数据库和数据表. 之后, 开发人员必须创建一个ASP.NET站点, 其中包括网页还有用来读取或修改销售数据的代码. 一旦ASP.NET站点开发结束, 准备部署, 系统管理员就必须将ASP.NET应用程序的文件拷贝到Web前端服务器上, 配置IIS服务来创建虚拟目录. 如果ASP.NET引用程序是被部署在一个Web服务器场的环境中, 需求还会更多, 因为这些管理动作必须复制到场的全部前端服务器上.
你可以想象, 使用这个方式来得到一个新的站点并使他运行起来通常得需要几个星期, 要不就是几个月, 因为至少, 你还要花费时间和精力在系统管理员, 数据库管理员, 网络开发人员中协调沟通. 为了站点能更快地更高效地创建, WSS技术被创建出来了.
从最核心的观点来看, WSS是一个站点的供应引擎. WSS的架构是被特别设计用来在Web服务器场的环境下来使用的. 在WSS中, 创建站点的动作可以由IT部门的人在不到一分钟的时间里, 通过仅仅是在浏览器的表单中填写一些必要的信息, 点一下OK按钮, 就可以搞定了. 没必要让数据库管理员来创建一个新的数据库或者任何新的数据表. 也没有必要让ASP.NET开发人员来创建一个新的ASP.NET站点. 系统管理员也用不着费劲地去在前端服务器之间拷贝文件和重新设置了.
WSS站点创建引擎基于一个涉及到多个SQL Server数据库来存储内容和配置的集成存储模型. 在你安装WSS的时候, 你可以选择使用SQL Server产品, 在更简单的情形下, 你可以选择SQL Expres, 这样你就不用花钱去买拥有微软许可的SQL Server的拷贝了.
关于MOSS
Windows SharePoint Services(WSS)和Microsoft Office SharePoint Server 2007(MOSS)是不同的, 他们的区别挺重要的. 这两个产品都是由微软Office团队开发的, WSS是Windows Server 2003的一部分, 而MOSS是一个要求你购买的单独的产品. 你可以认为WSS底层的平台, 而MOSS是一个基于WSS的一系列增值组件和增值服务的集合.
WSS没有申请许可证的机制. 作为替代, WSS的使用是借Windows Server 2003的许可来约束的. 这使得想要使用WSS平台创建站点的公司可以花费更低的成本. MOSS就有自己的许可证机制了, 包括服务器端的许可和客户端访问许可两部分. MOSS分为标准版, 和企业版两种.
场的概念
=============
每个WSS的部署都基于一个服务器场的概念.
简单的说服务器场就是一台或多台用来为客户提供WSS功能的协同工作的计算机的集合. 在最简单的场景, 一个WSS的场仅仅有一台服务器计算机组成, 它自己扮演前端和数据库服务器两种角色.一个更加复杂的WSS服务器场可以包括多个Web前端服务器, 和一个专门的数据库服务器, 见下图.
IIS站点在WSS中的角色
===========
WSS基于IIS上的, 换句话说WSS依赖IIS的站点来接受浏览器发过来的HTTP请求. 所以, 你需要理解IIS站点是什么. 一个IIS站点提供了一个进入IIS Web服务器基础架构的入口. 举个例子, 默认站点时由IIS自动创建的, 它在80端口监听进入的HTTP请求. 你还可以创建其他的IIS站点, 从而可以使用其他的端口, IP地址或者主机标头(host header)获得进入IIS Web服务的更多入口.
一个重要的IIS站点的特点是它拥有独立的安全设定, 与其他IIS站点的设定无关. 比如说一个站点使用basic认证, 而另一个使用NTML(Windows集成认证)来允许客户端的访问.
Web application
===========
作为WSS站点服务的IIS站点必须经过一些特别的配置. 经过特别配置的IIS站点被称作Web application. 每个WSS站点都在某个特定的web aplication的上下文中工作. 这很重要, 因为寄宿着站点的web application 提供许多WSS环境的重要技术方面, 包括安全设置和用户认证.
WSS的安装会创建一个叫做WSS 3.0 Central Administration的web applicaiton, 一般叫做管理中心. WSS管理中心web application提供了一些页面, 允许你执行一些管理上的诸如将IIS站点转换为WSS Web application一类的零零碎碎的操作. WSS管理中心还提供了创建新的IIS站点并自动的转换为WSS Web application的选项, 这个过程中你根本就不需要去直接使用IIS的管理工具做任何事, 它都为你做好了.
Web Application和Virtual Server的区别
在WSS2中, 产品组使用Virtual server这个术语来描述被WSS扩展了功能的IIS站点. 在WSS3中, 术语Virtual server被术语Web application取代了, 这样做是为了也微软的另一个也叫viatual server的产品区分开来, 避免混淆. 不管怎样, 作为WSS的开发人员, 你必须记得新的术语Web application和老术语virtual server是一回事儿, 可以互换. 比如说WSS对象模型中提供了SPVirtualServer的类, 它对应着Web application这个概念.
在一个典型的WSS场中, 通常会有许多的web application. 管理中心在WSS安装的时候被放在单独的一个web application中. 之后, 你需要创建一个或多个web application来创建和管理面向普通用户的站点. 比如说, 默认站点可以被配置为WSS web application, 从而使WSS站点可以通过80端口来访问. 你也可以在端口1000上创建另外的一个web application.
设置数据库和内容数据库
============
整个服务器场水平的配置信息存储在设置数据库之中(configguration database). 与WSS站点内容相关的数据存储在另一种类型的数据库之中, 叫做内容数据库(content database). 当你在管理中心中创建一个新的web application的时候, WSS会创建出一个新的内容数据库. 如果你坚持使用简单部署模型的话, 你的服务器场中的每一个web application都会包括一个内容数据库. 在有更高的安全需求和存储基元需求的情形下, 有可能通过一些复杂的管理操作过程将存在于一个web application中的许多站点分配到不同的内容数据库中去.
注意: 在使用WSS的时候, 是不允许直接访问配置数据库和内容数据库的. 你必须阻止任何的使用ADO.NET的代码来读取或者修改这些数据库中数据的企图. 作为替代, 你必须使用WSS提供的编程接口, 让WSS系统的代码来代替你来访问配置数据库和内容数据库.
<Inside Microsoft Windows ShaerPoint Services 3.0>