GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Conceptos de MOSS 2007: Aplicación Web, Accesos Alternativos, Colección de Sitios, Base de Datos de Contenido de MOSS


Este pequeño artículo tan sólo pretende introducir algunos de los conceptos básicos necesarios desde el punto de vista de arquitectura e infraestructuras de Microsoft Office SharePoint Server 2007 (MOSS 2007). ¿Qué es una Aplicación Web en MOSS 2007? ¿Cuándo es necesario extender una Aplicación Web de MOSS? ¿Qué es una Colección de Sitios (Site Collection)? ¿Cómo se organizan las Bases de Datos de Contenido en MOSS 2007? ¿Para qué sirven los Accesos Alternativos en SharePoint (Alternate Access Mapping)?

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


Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.