Aunque son muchos los conceptos propios de MOSS, a continuación queremos introducir sólo unos pocos de los principales conceptos de MOSS, de utilidad tanto para conocer el producto, como para poder diseñar, instalar y configurar MOSS 2007.
Una Aplicación Web de MOSS (conocido en versiones anteriores bajo el término Virtual Server) podemos verla como un Sitio Web de IIS que actúa como un contenedor capaz de hospedar un Servicio o una Aplicación web de WSS (Windows SharePoint Services Web application), la cual ejecuta código ASP.NET v2.0. Es decir, de momento debemos diferenciar el concepto de Aplicación Web (que debemos asociar con Sitio Web de IIS) del concepto de Aplicación de SharePoint o Aplicación MOSS (algo más amplio, pues como veremos, una Aplicación de SharePoint puede ser servida desde múltiples Aplicaciones Web). En consecuencia, una Aplicación Web de MOSS es un elemento de configuración que nos permite asociar una URL o Sitio Web (es decir, una forma de acceso) a una Aplicación SharePoint.
Una Aplicación de SharePoint es un contenedor de Colecciones de Sitios. Así, al crear una Aplicación Web de MOSS estamos creando una nueva Aplicación de SharePoint, y además se crea por defecto una nueva Base de Datos de Contenido en SQL Server asociada a dicha Aplicación de SharePoint, de tal modo, que es posible crear múltiples Bases de Datos de Contenido asociadas a una Aplicación de SharePoint y del mismo modo crear múltiples Colecciones de Sitios en dicha Aplicación de SharePoint, pudiendo asociar cada Colección de Sitios con una Base de Datos de Contenido en particular. Es decir, para cada Colección de Sitios se puede especificar qué Base de Datos de Contenido se desea utilizar para su almacenamiento, de tal modo, que todos los SubSitios y contenidos de dicha Colección de Sitios se almacenarán en la misma Base de Datos (ver el Artículo Bases de Datos de Contenido y Creación de Colecciones de Sitios en MOSS). Se debe entener que una Base de Datos de Contenido es un contenedor de Colecciones de Sitios. Es importante, aprovechar esta funcionalidad para poder dividir el contenido de nuestra Aplicación de SharePoint, en múltiples Bases de Datos (y en consecuencia, en múltiples Colecciones de Sitios), por ejemplo, cara a minimizar tiempos de Restauración (al trabajar con Bases de Datos más pequeñas), y en general, facilitar el mantenimiento de base de datos.
Antes de continuar, puede resultar interesante responder a la pregunta ¿Qué es una Colección de Sitios (Site Collection)? Una Colección de Sitios es una agrupación de Sitios WSS y de Espacios de Trabajo (Workspaces, que al final, también son Subsitios) que existen por debajo de un Sitio Principal o Sitio de Primer Nivel (Top-Level Site), asociados a una ruta (ej: /), y que comparten todos ellos una misma Base de Datos de Contenido así como otras configuraciones (ej: Papelera de Reciclaje, Galería de WebParts, Galería de Plantillas de Listas, Master Pages, Page Layouts, Usage Reports, Content Types, Workflows, herencia de permisos, etc.). Otra forma de definirlo, es como un Contenedor de Sitios de WSS, formado inicialmente por un Sitio Principal o Sitio de Primer Nivel, sobre el cual se pueden agregar uno o varios SubSitios. Es decir, al crear una Colección de Sitios (desde la Administración Central - SharePoint Central Administration - o bien utilizando la utilidad STSADM.EXE), estamos creando de forma implícita un Sitio Principal o Sitio de Primer Nivel (Top-Level Site) asociado a una determinada Base de Datos de Contenido.
De este modo, sobre un Sitio Principal o Sitio de Primer Nivel, es posible crear SubSitios, y sobre un Subsitio a su vez es posible crear SubSubSitios. Ojo, que todos los SubSitios, SubSubSitios, etc., serán almacenados sobre la Base de Datos de Contenido asociada a la Colección de Sitios. A su vez, en cada Sitio o SubSitio es posible crear Listas, Galerías de Documentos, y otros contenidos. Esta es la forma en que tanto MOSS como WSS organizan los Sitios, la cual, da lugar a diferentes organizaciones (ej: crear una Colección de Sitios para cada área de nuestra empresa, y crear SubSitios para cada Proyecto existente en cada Área). Es interesante comentar el hecho de que el Administrador del Sitio Principal, es el Administrador de la Colección de Sitios.
Recapitulamos: Lo primero es crear una Aplicación Web (asociada a un nombre DNS o dirección IP, y con esto, creamos la Aplicación de SharePoint como tal, con su Sitio Web de IIS, una Base de Datos de Contenido, etc.), por lo cual, una vez creada la Aplicación Web ya tenemos una URL (ej: www.guillesql.local) sobre la que montar nuestros Sitios WSS, pero de momento no tenemos ningún Sitio creado. Seguidamente, lo que haremos será crear una Colección de Sitios (asociada a una ruta), muy probablemente sobre la raíz (/) de nuestra Aplicación Web, y con esto, ya tendremos un Sitio Principal cuando alguien acceda a la URL de nuestra Aplicación Web. Si es necesario, podemos crear varias Colecciones de Sitios sobre la misma Aplicación Web, eso sí, cada Colección de Sitios deberá estar asociada a una ruta diferente. Del mismo modo, podremos crear los SubSitios necesarios, etc.
La Colección de Sitios o Sitio Principal debe ser creada por el Administrador de la Granja MOSS, mientras que por el contrario, la creación de SubSitios debe ser realizada por los Administradores de la Colección de Sitios. Así, para poder crear una Colección de Sitios, es necesario conocoer:
- Sobre qué Aplicación Web se desea crear la Colección de Sitios.
- Sobre qué Base de Datos de Contenido se desea almacenar la Colección de Sitios.
- Qué nombre se desea aplicar a la nueva Colección de Sitios (puede incluirse una descripción también).
- Qué dirección URL se desea utilizar para acceder a la Colección de Sitios (ej: /sites/eBooks).
- Qué idioma se desea aplicar a la nueva Colección de Sitios (quizás sea necesario haber instalado algún Language Pack).
- Qué Plantilla de Sitio se desea aplicar al Sitio Principal de la Colección de Sitios (ej: Sitio de grupo, Sitio en blanco, Portal de colaboración, etc.).
- Quién será el administrador de la Colección de Sitios (puede especificarse hasta dos Administradores).
- Qué plantilla de quota se desea aplicar a la Colección de Sitios (muy importante, para así poder tener control sobre el almacenamiento, que no es gratis).
Siguiendo con el tema de las Aplicaciones Web de MOSS y los Sitios Web de IIS, como es de esperar, una Aplicación Web de MOSS (como Sitio Web de IIS que es) debe asociarse con un Pool de Aplicaciones (Application Pool) de IIS, siendo recomendable la creación de Application Pool independientes para cada Aplicación Web de MOSS cuando se desee garantizar que la caída de una Aplicación Web MOSS (Sitio Web de IIS) no impacte en el funcionamiento de otra Aplicación Web de MOSS (Sitio Web de IIS). Esto es debido a que un Pool de Aplicaciones (Application Pool) de IIS es simplemente un conjunto de uno o varios Sitios Web de IIS que son servidos bajo un único proceso (Worker Process) o conjunto de procesos (Worker Processes set) de IIS, de tal modo, que un Pool de Aplicaciones aísla a las Aplicaciones Web que contiene de otras que se ejecuten en otros Pool de Aplicaciones.
Ahora que ya tenemos algo claro los conceptos de Aplicación Web de MOSS y de Aplicación de SharePoint, vamos a introducir el concepto de Extender una Aplicación Web.
Al Extender una Aplicación Web, estamos creando una nueva Aplicación Web de MOSS o Sitio Web en IIS (con la ruta del sistema de ficheros, puerto TCP y hostheader que especifiquemos), asociado con una Aplicación de SharePoint existente (es decir, no estamos creando una nueva Aplicación de SharePoint). Además, durante la extensión de una Aplicación Web, debemos asociar al nuevo Sitio Web una zona de seguridad (ej: Default, Intranet, Internet, Custom, Extranet) y una configuración de autenticación y seguridad (especificar el proveedor de autenticación - NTLM o Kerberos -, especificar si se permite acceso anónimo y especificar si se utiliza SSL).
Es decir, después de extender una Aplicación Web existente, tenemos una única Aplicación de SharePoint, aunque tengamos dos o más Sitios Web en IIS a través de los que pueden recibirse las peticiones de los equipos clientes (es decir, tenemos distintas formas de acceso, por decirlo de alguna forma). Ojo con esto, que es un error de concepto muy habitual: no tenemos múltiples Aplicaciones de SharePoint asociadas a la misma base de datos de contenido (o mismas, si fuesen varias bases de datos), lo que tenemos, es una única Aplicación de SharePoint con varios Sitios Web de IIS para recibir las peticiones de los usuarios (eso sí, cada Sitio Web de IIS podrá tener una configuración de Autenticación diferente, o de utilización de SSL, o de acceso anónimo, o diferentes permisos NTFS, etc.).
Es importante recordar que también es posible utilizar Accesos Alternativos (Alternate Access Mapping) en vez de Extender una Aplicación Web, en aquellos casos que no existe ninguna diferencia de Autenticación y Seguridad, etc. Esto es debido, a que cualquier URL que se desee utilizar para acceder a una Aplicación MOSS debe estar registrada como Acceso Alternativo (Alternate Access Mapping), y aprovecho para recordar, que tanto al Crear una Aplicación Web como al Extender una Aplicación Web se crea de forma automática la correspondiente configuración de Acceso Alternativo. Por ejemplo, si tenemos una Aplicación MOSS a la cual deseamos acceder a través de diferentes nombres (ej: www.guillesql.es y guillesql.es), deberemos tener configurados dichos nombres como Accesos Alternativos (directamente, o indirectamente a través de la creación y/o extensión de Aplicaciones Web). Si no lo hacemos así, es importante tener presente que al acceder a una Aplicación MOSS a través de una URL no registrada como Acceso Alternativo, podemos encontrarnos con diferentes errores de funcionamiento (ej: problemas con las búsquedas, problemas al realizar determinadas tareas administrativas como activar algunas Features, etc.), además de que obtendremos errores en el Visor de Sucesos de Aplicación (Error Id 0, Category Topology). Un caso de ejemplo de Accesos Alternativos, es el caso de una Granja MOSS con dos frontales en un Cluster NLB, de tal modo, que nos puede interesar tener configurados Accesos Alternativos tanto para la URL del NLB (ej: http://www.guillesql.local) como para cada Nodo del NLB (ej: http://VMOSS01 y http://VMOSS02).
