Contenido
Vista general del sistema
Topología de servidores Web
Control de las solicitudes en IIS y a través del filtro ISAPI
Infraestructura de elementos Web
Código no administrado en Windows SharePoint Services
Contenido de la base de datos de configuración
Conclusión
Vista general del sistema
En una implementación de Microsoft Windows SharePoint Services, hay tres tipos de componentes de servidor activos:
- Uno o más servidores Web clientes.
- Una base de datos de configuración.
- Uno o más servidores de bases de datos de contenido.
Estos tres componentes se pueden instalar en un único equipo o se pueden distribuir entre varios equipos dentro de un conjunto de servidores. Toda la información de estado se mantiene en las bases de datos de contenido y de configuración, en Microsoft SQL Server.
Figura 1. Vista general de una implementación de Windows SharePoint Services
Servidores Web
En un conjunto de servidores que ejecuta Windows SharePoint Services, los servidores Web son clones sin estado. Las solicitudes se pueden enrutar a cualquiera de los servidores Web mediante el equilibrio de carga y cualquier sitio puede verse atendido por cualquiera de los servidores Web. El servidor Web se conecta a una base de datos de servidor para recuperar datos de modo que pueda construir y devolver la página Web al cliente. Cuando dentro de un conjunto de servidores no funciona un servidor Web, las solicitudes se enrutan hacia otros servidores Web. Para agregar capacidad a la implementación, se pueden agregar más servidores Web. Los documentos y demás información de los usuarios finales no se almacena en los servidores Web. Todos los valores de configuración y contenido de los sitios Web se conservan en los servidores de bases de datos.
Servidores de bases de datos de contenido
La base de datos de contenido de servidor almacena todo el contenido del sitio, incluyendo los documentos o archivos del sitio en bibliotecas de documentos, datos de listas y propiedades de los elementos Web, así como los nombres de usuario y los derechos. A diferencia de los servidores Web, los servidores de bases de datos de contenido no son idénticos. Todos los datos de un sitio específico residen en una base de datos de contenido en un único equipo. SQL Server ofrece protección de copia de seguridad de conmutación por error para evitar las interrupciones en el servicio en el caso en que un servidor de base de datos dejara de funcionar.
Base de datos de configuración
La base de datos de configuración controla toda la administración de la implementación, dirigiendo las solicitudes a la base de datos adecuada y administrando el equilibrio de carga para las bases de datos de servidor. Cuando un servidor Web cliente recibe una solicitud de una página de un determinado sitio, comprueba la base de datos de configuración para determinar cuál es la base de datos de contenido que contiene los datos del sitio. La base de datos de configuración se puede ejecutar en el mismo equipo que un servidor Web o en un equipo remoto que ejecute Microsoft SQL Server.
Topología de servidores Web
La topología, o diseño lógico, de los servidores Web en una implementación de Windows SharePoint Services varía en función del contexto. Cuando se implementa Windows SharePoint Services, se crean de forma predeterminada dos servidores virtuales o sitios Web en Servicios de Internet Information Server (IIS) de Microsoft. Uno de los sitios Web se crea para un servidor virtual administrativo y se amplía el sitio Web IIS existente en el puerto 80 para crear un servidor virtual de usuario final o de tiempo de ejecución.
Figura 2. Servidores virtuales administrativo y de usuario final predeterminados en IIS
Sólo se puede disponer de un servidor virtual administrativo en un único equipo, que se utiliza para configurar todos los servidores Web clientes y para ampliar nuevos servidores virtuales.
En cualquier implementación de Windows SharePoint Services, se puede implementar más de un servidor virtual. Los servidores virtuales se pueden configurar de dos maneras. La configuración predeterminada resuelve los nombres de dominio mediante servidores virtuales en IIS. En esta configuración, se pueden crear varios servidores virtuales, un nombre de dominio por servidor. La segunda configuración, denominada modo de encabezado Host escalable, aumenta la capacidad del modo de encabezado Host que se utiliza en IIS y que permite a un único servidor virtual alojar varios nombres de dominio, utilizando el encabezado Host o el nombre de dominio para resolver los sitios.
La entidad de escala para un servidor virtual de usuario final es la colección de sitios, que está compuesta por un sitio de nivel superior o Web raíz (por ejemplo, http://ServidorVirtual/[sitios/]ColeccionSitios) y cualquier cantidad de subsitios (por ejemplo, http://ServidorVirtual/[sitios/]ColeccionSitios/Subsitio). El sitio de nivel superior incluye, por ejemplo, las galerías de elementos Web, plantillas de lista y plantillas de sitio, y ofrece administración para todos los sitios dentro de la colección de sitios. Un servidor virtual se divide en colecciones de sitios, que permiten que un espacio de nombres de URL dado se divida en distintos segmentos, cada colección de sitios con su propio espacio de nombres (por ejemplo, http://ServidorVirtual/[sitios/]SuColeccionSitios, http://ServidorVirtual/[sitios/]MiColeccionSitios, etc.) Windows SharePoint Services puede equilibrar la carga de las colecciones de sitios entre distintas bases de datos de contenido, pero los sitios individuales siempre residen en la misma base de datos que su colección de sitios principal.
IIS no reconoce colecciones de sitios, que no equivalen ni a los sitios Web IIS ni a los directorios virtuales de IIS.
Nota para SharePoint Portal Server 2003 Cuando se implementa Microsoft Office SharePoint Portal Server 2003, el sitio del portal es una colección de sitios de Windows SharePoint Services con funcionalidad adicional. Existe un sitio de portal por cada servidor virtual, pero se pueden crear colecciones de sitios estándar de Windows SharePoint Services adicionales en el servidor virtual.
Control de las solicitudes en IIS y a través del filtro ISAPI
IIS se encarga de controlar las solicitudes HTTP base, pero Windows SharePoint Services implementa un filtro ISAPI (Internet Server API), STSFLTR.DLL, que modifica el comportamiento de IIS para controlar rutas administradas o inclusiones y exclusiones. El filtro ISAPI o bien redirige las solicitudes hacia la extensión ISAPI de Windows SharePoint Services o bien permite que las páginas ASPX (.aspx) y las direcciones URL de los servicios Web (.asmx) pasen por el filtro hacia el controlador ASP.NET de SharePoint.
Figura 3. Solicitudes HTTP enrutadas hacia ASP.NET o hacia la extensión ISAPI
Nota para SharePoint Portal Server 2003 Cuando se implementa SharePoint Portal Server, también se crean las bases de datos de servicios y perfiles en SQL Server, y se implementa una capa ADO.NET bajo ASP.NET.
La función de IIS
IIS enruta las solicitudes HTTP hacia la aplicación correspondiente y utiliza el controlador HTTP.SYS para escuchar en el puerto designado de un sitio Web IIS, o servidor virtual SharePoint, y para controlar los paquetes IP entrantes. De forma predeterminada, se utiliza el puerto 80 para las solicitudes HTTP y el puerto 443 para las solicitudes HTTPS. IIS resuelve las solicitudes utilizando el nombre de dominio, el puerto y la dirección IP del servidor virtual al que va dirigida la solicitud. En una implementación, los sitios Web IIS ofrecen límites administrativos, de seguridad y de recursos, pero el código de Windows SharePoint Services se ejecuta desde el nivel del servidor virtual hacia abajo para controlar la actividad del sitio.
IIS controla toda la autenticación de usuarios (anónima, autenticación de Windows integrada o básica) para cada servidor virtual de forma individual y administra la habilitación de solicitudes anónimas. Si se deshabilita el acceso anónimo en IIS, se desactivará para todo el servidor virtual y las solicitudes anónimas nunca llegarán hasta Windows SharePoint Services. No obstante, se debe configurar Windows SharePoint Services para aceptar solicitudes sin autenticar. Si se configura IIS para aceptar solicitudes anónimas pero Windows SharePoint Services no está configurado para ello, se seguirán rechazando dichas solicitudes.
Además de utilizar IIS para controlar la autenticación de usuarios, Windows SharePoint Services utiliza la nueva característica de grupo de aplicaciones de IIS 6 para permitir que los servidores virtuales ejecuten distintos grupos de aplicaciones. Cada grupo de aplicaciones tiene sus propios recursos de procesador y memoria para proporcionar un conjunto aislado de procesos de trabajo en los que se ejecuten las aplicaciones Web. Windows SharePoint Services utiliza grupos de aplicaciones para controlar la asignación de recursos, lo que ofrece las siguientes ventajas:
- Identidad del proceso: la conexión de Windows SharePoint Services a SQL Server se realiza mediante una identidad de grupo de aplicaciones, a menos que esté configurado para utilizar la autenticación de SQL Server.
- Aislamiento del proceso: el hecho de que distintos servidores virtuales residan en el mismo equipo no impide que sus bases de datos puedan ser completamente independientes si los servidores se ejecutan con distintas cuentas, aunque compartan una base de datos de configuración común. Los grupos de aplicaciones ofrecen un límite de seguridad, ya que cada grupo de aplicaciones requiere su propio conjunto de credenciales en el servidor.
- Reciclaje de aplicaciones: en versiones anteriores de IIS, los procesos podían estar ejecutándose durante mucho tiempo y las pérdidas de recursos suponían una seria amenaza para el servidor, sin embargo, la versión actual de IIS recicla los procesos de forma que dichas pérdidas no provocan interrupciones en el servidor.
Modificaciones que Windows SharePoint Services realiza en IIS
Aunque Windows SharePoint Services utiliza los grupos de aplicaciones y la autenticación de IIS sin modificación alguna, sí modifica otros servicios de IIS que utiliza, como son los servidores virtuales o el control de solicitudes, para su integración en la arquitectura de Windows SharePoint Services. Cuando se instala en un solo equipo, Windows SharePoint Services reemplaza el grupo de aplicaciones predeterminado de IIS, DefaultAppPool, con su propio grupo de aplicaciones, STSAppPool1, para utilizarlo con su servidor virtual de usuario final predeterminado y crea un grupo de aplicaciones adicional, STSAdminAppPool, para el servidor virtual administrativo. En el contexto de un conjunto de servidores, los administradores son los encargados de crear y asignar un nombre a ambos grupos de aplicaciones.
Nota para SharePoint Portal Server 2003 El nombre del grupo de aplicaciones administrativo que se crea de forma predeterminada en SharePoint Portal Server es CentralAdminAppPool.
A diferencia de SharePoint Team Services de Microsoft, Windows SharePoint Services no conserva los datos de configuración en la metabase de IIS debajo del nivel del servidor virtual. Toda la información del sitio o de la colección de sitios se almacena en la base de datos de configuración de SharePoint independientemente de IIS, lo que hace que la configuración de los conjuntos de servidores sea más sencilla de mantener.
Control de solicitudes para rutas a través del filtro ISAPI
Antes de la autenticación, el filtro ISAPI (STSFLTR.DLL) examina la dirección URL solicitada para determinar si la solicitud es para una ruta administrada de Windows SharePoint Services, de acuerdo con una lista controlada por el administrador que contiene las rutas incluidas y excluidas. El filtro ISAPI aplica la siguiente lógica para enrutar las solicitudes:
- Si no es una ruta administrada, permite el paso a través.
- Si es una ruta administrada y está ubicada en un directorio virtual como _layouts o _vti_bin, vuelve a escribir la dirección URL para _layouts o _vti_bin en el directorio raíz del servidor.
- Si es una ruta administrada, pero no está en _layouts y la solicitud es de un archivo .aspx o .asmx, permite el paso a través. En este caso, la solicitud se controlará mediante la extensión ISAPI de ASP.NET y, a continuación, mediante el controlador administrado de Windows SharePoint Services.
- Si no es una ruta administrada, no está en _layouts y la solicitud no se refiere a un archivo .aspx o .asmx, vuelve a escribirla para la extensión ISAPI de Windows SharePoint Services.
Las solicitudes para la extensión ISAPI de SharePoint se producen en el contexto de páginas HTML estáticas, protocolos heredados como puede ser el protocolo de llamada a procedimiento remoto (RPC) de las Extensiones de servidor de FrontPage, y en el contexto del nuevo protocolo DAV o de los comandos GET de páginas estáticas (por ejemplo, para obtener un archivo .htm o .doc).
La principal función de las rutas administradas es definir cuáles son los espacios de nombres de URL que administra Windows SharePoint Services, no obstante, también definen las rutas que se utilizan durante la creación personalizada de sitios, lo que permite a los administradores controlar el lugar donde se pueden crear sitios (por ejemplo, restringir la creación de sitios a un directorio especificado y que contenga una URL del tipo: http://Servidor/SitiosUsuario/).
Las rutas se pueden incluir o excluir. Las exclusiones especifican que un determinado espacio de nombres de URL no guarda relación con un sitio ampliado, lo que evita que Windows SharePoint Services intercepte la solicitud. Windows SharePoint Services ignora las solicitudes dirigidas a una ruta excluida. Las inclusiones, por el contrario, especifican cómo dividir un espacio de nombres de URL en distintas colecciones de sitios dentro de una implementación de SharePoint. Existen dos tipos de inclusiones.
- Inclusión explícita: significa que la raíz del servidor es en sí misma un sitio SharePoint y especifica un sitio Web que Windows SharePoint Services se encarga de administrar.
- Inclusión de caracteres comodín: especifica una colección completa de sitios por debajo de un determinado directorio que Windows SharePoint Services se encarga de administrar.
Nota Cuando se actualiza SharePoint Portal Server 2001 y se utiliza administración de documentos en almacenes Web, SharePoint Portal Server utiliza la exclusión para exponer la dirección URL al sistema de almacén Web, por ejemplo, bajo una ruta de directorio virtual del sitio raíz del portal. De forma predeterminada, SharePoint Portal Server implementa dos inclusiones de caracteres comodín, una para grupos y otra para sitios personales, y utiliza esquemas de partición (por ejemplo, "/grupos" o "/sitios") para evitar la confusión entre las carpetas de nivel superior del sitio y las colecciones de subsitios.
Controlador ASP.NET y procesamiento de páginas
En Windows SharePoint Services, el controlador ASP.NET actúa como un filtro que determina el modo ASP.NET que se debe utilizar cuando se ejecuta una página, que puede ser modo directo o seguro.
Las páginas ubicadas dentro del directorio virtual /_layouts, denominadas páginas de aplicación, se ejecutan en modo directo, es decir, Windows SharePoint Services no intercepta dichas páginas y permite que se ejecuten de la forma habitual en ASP.NET. Las páginas de aplicación incluyen, por ejemplo, las páginas nativas de SharePoint utilizadas para crear nuevas listas, modificar vistas, etc. El contenido del directorio /_layouts se considera ubicado fuera del sitio Web y es IIS el encargado de suministrar directamente las páginas cuando se soliciten. Se puede utilizar cualquier código dentro de las páginas ASP.NET personalizadas contenidas en este directorio.
Las páginas ASP.NET ubicadas dentro de un sitio Web, como la página principal, páginas para ver elementos y listas, o páginas de elementos Web, se denominan páginas de usuario y se ejecutan en modo seguro, es decir, Windows SharePoint Services sólo permite la ejecución de los controles de formularios Web si el administrador ha designado dichos controles como seguros. Estas páginas se pueden personalizar, por ejemplo, a través de la IU o utilizando Microsoft Office FrontPage 2003, pero no se podrá agregar cualquier código a una página de usuario, que sólo se procesa como texto en el explorador en tiempo de ejecución. A diferencia del modo directo, en el modo seguro la página ASP.NET no se compila en una DLL. La lista de controles seguros con permiso de ejecución en los sitios Web de un servidor virtual específico se puede modificar editando el archivo web.config del servidor.
Nota Para que una aplicación ASP.NET coexista con Windows SharePoint Services y se ejecute en el mismo servidor sin interferencias por parte del filtro ISAPI de SharePoint, se debe excluir la dirección URL de la aplicación. Además, se debe modificar el archivo web.config de la aplicación para borrar el controlador ASP.NET de SharePoint. Como el código de la aplicación deberá ejecutarse en una dirección URL excluida, no podrá hacer referencia al ensamblado de Windows SharePoint Services. Para obtener más información, consulte Working with web.config Files que se encuentra en el Kit de desarrollo de software Productos y Tecnologías de Microsoft SharePoint 2003.
Infraestructura de elementos Web
La infraestructura de elementos Web ofrece un control en modo seguro a Windows SharePoint Services y permite la adición de elementos Web a una página ASP.NET basada en la dirección URL de la página, el Id. del usuario actual y otra información almacenada en la base de datos.
Figura 4. Cómo rellenar las zonas en una página de elementos Web
Cuando se abre una página de elementos Web en el explorador, Windows SharePoint Services utiliza la dirección URL de la página y el Id. de usuario para devolver desde SQL Server una lista de los elementos Web especificados para la página y crear un objeto de página ASP.NET; dicho objeto rellenará las zonas de elementos Web de la página con los elementos Web especificados. Por ejemplo, la página principal de un sitio de SharePoint incluye de forma predeterminada dos zonas de elementos Web que contienen elementos Web que muestran vistas de resumen de las listas Anuncios, Eventos y Vínculos, así como un elemento Web Imagen que muestra un logotipo. Sin embargo, si el administrador permite la personalización de la página y un usuario la personaliza, Windows SharePoint Services mostrará distintos elementos Web dependiendo del usuario.
Código no administrado en Windows SharePoint Services
La mayor parte de la lógica utilizada en Windows SharePoint Services para trabajar con sitios y listas se basa en código no administrado, del que se pueden encontrar grandes cantidades en las bibliotecas de vínculos dinámicos (DLL) utilizadas en los anteriores SharePoint Team Services. Los elementos Web y otros objetos ASP.NET de Windows SharePoint Services, así como la extensión ISAPI, son en realidad finas capas sobre el código no administrado. Los elementos y servicios Web están creados sobre el nuevo modelo de objetos de SharePoint y, a su vez, el modelo de objetos sirve como empaquetador que llama al código no administrado.
El código no administrado es compatible con las Extensiones de servidor de Microsoft Office FrontPage 2003, el protocolo DAV, el procesamiento de vistas, los comandos GET de documentos estáticos y todas las entradas y salidas de bases de datos. La DLL principal, owssvr.dll, ofrece gran parte de la lógica para trabajar con listas, incluyendo la lógica que interpreta el lenguaje XML propietario, CAML (Collaborative Application Markup Language), que se utiliza para definir datos y emitir texto.
Todos los servidores Web cliente contienen definiciones de sitios y listas dentro del directorio de instalación (Unidad_Local:\Archivos de programa\Archivos comunes\Microsoft Shared\web server extensions\60\) que incluyen archivos de esquema CAML. Dichos archivos de esquema determinan, por ejemplo, cómo se crean instancias de nuevos sitios y listas, y cómo se presentan los datos. Para obtener más información acerca de las definiciones de sitios y listas, consulte Introduction to Templates and Definitions.
Nota para SharePoint Portal Server 2003 SharePoint Portal Server implementa de forma adicional acceso de código administrado a sus bases de datos a través de ADO.NET.
Procesamiento de vistas
CAML define cómo se procesan las vistas de las listas en un elemento Web. Cada tipo de lista de Windows SharePoint Services dispone de su propio archivo SCHEMA.XML ubicado en el directorio \web server extensions\60\TEMPLATE\Id_de_Idioma\Definición_de_Sitio\LISTS que define cómo se mostrará la lista en la página HTML cuando se muestre en el explorador. En la versión anterior, SharePoint Team Services, las vistas de lista se enviaban a través de la expansión de islas CAML en el explorador (indicada por el prefijo ows), pero en Windows SharePoint Services, la vista CAML se envía a través de un elemento Web, tal y como se muestra en la siguiente figura.
Figura 5. Procesamiento de una vista de lista a través de un elemento Web en Windows SharePoint Services
Un archivo SCHEMA.XML de CAML contiene definiciones para las vistas de lista predeterminadas y para los formularios utilizados para trabajar con elementos individuales. CAML se emplea para construir el código HTML y la secuencia de comandos que requiere el explorador cliente, incluyendo, por ejemplo, la secuencia de comandos, las barras de herramientas o los encabezados de columna utilizados en el encabezado de vistas, los nombres o valores de los campos utilizados en el cuerpo de la vista y las propiedades de lista o exploración de la página en el pie de la vista. CAML se puede utilizar en el contexto de Windows SharePoint Services para emitir en el explorador cualquier marcado, secuencia de comandos o texto que se pueda necesitar en la vista de elementos Web, por ejemplo, HTML, XML, WML, ECMAScript (Microsoft JScript o JavaScript), etc. CAML se utiliza para construir regiones complicadas, como la secuencia de comandos que se utiliza en la vista de lista de un control de calendario.
Nota El elemento Web Vista de datos construye XML a partir de una lista o vista de lista de SharePoint y utiliza XSLT (Extensible Stylesheet Language Transformation) para procesar la IU de la vista de lista, que le permite ofrecer un enfoque basado en estándares para crear personalizaciones de alta calidad. Windows SharePoint Services proporciona los datos en formato XML y FrontPage implementa un elemento Web alternativo para procesar una vista de los datos.
Además de SCHEMA.XML, en Windows SharePoint Services se utilizan los siguientes archivos de esquema CAML:
- WEBTEMP.XML: permite la utilización de varias definiciones de sitios en una implementación, como las definiciones predeterminadas incluidas en Windows SharePoint Services para la plantilla Sitio de grupo o Área de documentos, o para alguna de las plantillas Área de reuniones. La modificación de este archivo afecta a todos los sitios del conjunto de servidores.
- ONET.XML: define las listas y páginas que se incluirán en los nuevos sitios.
- FLDTYPES.XML: define la implementación SQL de cada tipo de campo utilizado en Windows SharePoint Services así como su procesamiento HTML.
- BASE.XML: define los esquemas de las listas globales, por ejemplo, las tablas Listas, Docs. e InfoUsuario ubicadas en la base de datos.
- DOCICONS.XML: especifica el icono que se mostrará para cada tipo de archivo y asocia el tipo de archivo con una aplicación.
Para obtener más información acerca de las definiciones de sitios y listas, consulte Introduction to Templates and Definitions y Customizing SharePoint Sites and Portals: Part 1.
Páginas personalizadas
El modo seguro permite a los usuarios personalizar el sitio sin que puedan incluir código en el servidor, pero este modo también mejora la escalabilidad al reducir el número de objetos que se deben crear para el sitio y la cantidad de datos que hay que almacenar en la base de datos.
En la versión anterior, SharePoint Team Services, si se deseaba crear mil sitios distintos en el servidor, era necesario crear mil copias distintas de cada página de usuario para cada lista, como el archivo AllItems.htm o los formularios de elementos. En Windows SharePoint Services, siempre y cuando no se haya personalizado una página de usuario, el archivo SCHEMA de CAML, ubicado en el directorio de instalación, contiene completamente la definición de las páginas y la definición se almacena en la memoria caché en el servidor Web cliente. El almacenamiento en caché de la definición evita que Windows SharePoint Services tenga que crear copias de las páginas de usuario cada vez que se crea un sitio o una lista. Dichas páginas son páginas virtuales cuyo contenido deriva de los archivos de esquema CAML, aunque parezcan ser páginas reales en el explorador. El almacenamiento en caché maximiza la escalabilidad permitiendo que las páginas que no se hayan personalizado se puedan reutilizar en varios sitios y reduciendo el almacenamiento de datos innecesarios y el gran espacio en memoria necesario para servir las páginas. Windows SharePoint Services consulta la base de datos para determinar si se ha modificado la página solicitada. Si no es así, la base de datos no incluye todo el contenido del archivo y la consulta sólo devuelve la ruta de una carpeta en el directorio de instalación que contiene la página no personalizada. En las páginas de elementos Web que no se han personalizado, sólo se consulta SQL Server para devolver la lista de elementos Web que se van a mostrar en las zonas de elementos Web.
Cuando se solicita la página default.aspx para un sitio, Windows SharePoint Services primero comprueba si se ha personalizado el código fuente de la página. Si es así, la columna Contenido de la tabla Docs. ya no contiene el valor NULL, como sucede con las páginas que no se han personalizado, sino que alberga el contenido de la página en formato binario. La definición no se extrae del directorio de instalación, sino de la base de datos. Una vez se ha personalizado una página, no se admite el regreso a la definición original de la página. De forma similar, cuando se personaliza una vista de lista en una página AllItems.aspx, la vista modificada se almacena en la columna tp_View de la tabla Elementos Web de la base de datos y la definición de la vista de lista ya no se extrae del directorio de instalación.
Contenido de la base de datos de configuración
Las instalaciones de Windows SharePoint Services tienen una base de datos de configuración que administra la implementación. Los valores de configuración de esta base de datos sólo se pueden modificar a través del servidor virtual administrativo; dichos valores son de sólo lectura para los servidores virtuales de usuario final.
La base de datos de configuración almacena los siguientes tipos de datos generales:
- Configuración global: información sobre el conjunto de servidores como, por ejemplo, cuáles son los servidores Web o de base de datos que hay en el conjunto.
- Servidor virtual: información sobre cada servidor virtual en la implementación como, por ejemplo, qué servidor SMTP se utiliza para un servidor virtual en particular o cuál es la configuración predeterminada para los sitios.
- Mapa del sitio: información sobre cuál es la base de datos de contenido que contiene datos para un determinado sitio. Cuando Windows SharePoint Services recibe la dirección URL de una solicitud, los valores de configuración de esta base de datos determinan cuál es la base de datos de contenido que contiene los datos del sitio.
En la figura 6 se muestra el funcionamiento de un mapa del sitio en una búsqueda en bases de datos de contenido.
Figura 6. Búsqueda en bases de datos de contenido basada en una dirección URL relativa al servidor virtual
Se envía una solicitud al servidor para http://MyServer/sites/mysite/Lists/AllItems.ASPX. La parte relevante de la dirección URL, sites/mysite, especifica la colección de sitios de la solicitud. Como, de forma predeterminada, sites ofrece inclusión de caracteres comodín de las colecciones de sitios creadas en el servidor, sites/mysite es un fragmento relativo al servidor virtual que especifica la colección de sitios. Debido a que la parte relevante de la dirección URL excluye el nombre del equipo, dos servidores virtuales con la misma o distintas direcciones pueden servir el mismo contenido; los datos del sitio pueden tener, por ejemplo, tanto un sitio dirigido hacia la extranet y un sitio hacia la intranet.
En el ejemplo anterior, la base de datos de configuración especifica que los datos para el sitio residen dentro de un servidor de bases de datos denominado ITG_STS_1 en la base de datos llamada STS_01. Después de que se recopile esta información de la base de datos de configuración, el Id. de la base de datos (101 en la figura 6) se almacena en caché dentro de la cookie de la sesión del servidor Web y se utiliza para conectar con la base de datos correcta en las siguientes solicitudes. Windows SharePoint Services utiliza un esquema de caché optimista, es decir, que supone que el sitio no se ha movido desde la última visita efectuada por el usuario. Si la dirección URL almacenada en caché no está, Windows SharePoint Services consulta la base de datos de configuración para comprobar si se ha movido el sitio y un algoritmo de corrección automática permite el ajuste del sistema.
Nota para SharePoint Portal Server 2003 Cuando se instala SQL Server, SharePoint Portal Server agrega tablas propias a la base de datos de configuración y utiliza esta base de datos para realizar el seguimiento de la actividad de los servidores dentro del conjunto, como, por ejemplo, quién está realizando una búsqueda, una indización o un inicio de sesión único. SharePoint Portal Server también agrega asignaciones para un acceso alternativo y una asignación a la extranet para llevar a cabo la agregación entre varios almacenamientos alternativos.
Esquema de la base de datos de contenido
Windows SharePoint Services almacena todos los datos de usuario final en la base de datos de SQL Server, que ofrece las siguientes ventajas:
- Almacenamiento de datos de lista, documentos y metadatos en tablas normalizadas.
- Actualizaciones transaccionales de documentos y metadatos de documentos.
- Copias de seguridad sistemáticas de documentos y metadatos de documentos.
- Una capa de almacenamiento programable.
- Detección y resolución de interbloqueos.
Mientras que el anterior SharePoint Team Services implementa una base de datos por sitio y una tabla por lista, Windows SharePoint Services utiliza un esquema de bases de datos fijo y un número fijo de bases de datos por servidor para mejorar la escalabilidad. Una tabla de base de datos dispersa almacena todos los datos de lista y la asignación de esquemas de lista para las tablas físicas es lógica. Además, los procedimientos almacenados minimizan el número de intercambios de información que se deben realizar con SQL Server y acercan la lógica de entrada/salida al almacenamiento de datos.
Figura 7. Esquema básico de una base de datos de contenido
La tabla Sitios contiene la configuración relativa a cada colección de sitios representada dentro de la base de datos; se trata de una configuración predeterminada que se aplica a todos los subsitios creados dentro de cada una de las colecciones de sitios. La tabla representa cada uno de los sitios de nivel superior de cada una de las colecciones de sitios, así como el sitio raíz y Mi Sitio en el contexto de un sitio de portal. La tabla Sitios Web contiene la configuración que se aplica a cada uno de los sitios dentro de una colección de sitios.
La tabla Docs. almacena todos los documentos de todos los sitios de una colección de sitios representada por la base de datos, incluyendo, por ejemplo, documentos en las bibliotecas de documentos, datos adjuntos y nodos para cada lista, y también las páginas default.aspx y de usuario para todas las listas si se han personalizado. La columna Contenido de la tabla Docs. contiene el valor NULL si no se han personalizado las páginas. Cuando se crea un sitio por primera vez, la columna Contenido contiene el valor NULL para todas las páginas del sitio que hay en la tabla porque no están personalizadas, sus definiciones de página extraídas de archivos de esquema ubicados físicamente en el servidor Web cliente.
La tabla Listas (o la lista de listas) contiene una fila para cada lista de todos los sitios de la base de datos. Esta tabla contiene la configuración de cada lista, en la que se especifican las listas o bibliotecas de documentos que se incluyen en los sitios y de qué esquema se crea una instancia con cada lista. La tabla Datos de usuario contiene todos los datos de lista para los elementos creados por los usuarios en los sitios; cada fila contiene los datos de cada elemento.
La tabla Vínculos contiene los vínculos utilizados en la reparación de vínculos para volver a calcularlos, lo que simplifica enormemente la administración de los mismos ya que, en la versión anterior, los archivos secundarios, con todos los vínculos que procedían del documento y los que se dirigían a él, se tenían que crear en el sistema de archivos detrás de cada documento.
La tabla Elementos Web contiene información acerca de todos los elementos Web y vistas de lista utilizados en los sitios; esta tabla reemplaza a la tabla Vistas de la versión anterior, igual que los elementos Web reemplazan la utilización de las vistas CAML directamente en las páginas de usuario. La columna tp_View contiene CAML para vistas modificadas y el valor NULL para las vistas que permanecen sin personalizar. La información de personalización de los elementos Web se conserva en la tabla Personalización.
Nota para SharePoint Portal Server 2003 La base de datos de contenido de SharePoint Portal Server es un superconjunto de la base de datos de Windows SharePoint Services, a la que se agregan tablas y procedimientos almacenados. SharePoint Portal Server utiliza relaciones de clave externa en las tablas y no modifica el esquema de bases de datos de Windows SharePoint Services, sino que agrega dos bases de datos. La base de datos Perfil almacena perfiles personales y definiciones de audiencia del contenido y los elementos Web, y la base de datos Servicios admite búsqueda e indización, así como suscripciones y los resultados de estas.
Conclusión
La arquitectura de Windows SharePoint Services ofrece modificaciones que directamente tratan asuntos de interés en relación a temas de escalabilidad y rendimiento frente a la arquitectura de la versión anterior, SharePoint Team Services. Windows SharePoint Services se expande y diversifica a sí mismo como una plataforma de desarrollo Web gracias a la integración de .NET Framework en su propia funcionalidad. Además, los cambios significativos realizados sobre el esquema de base de datos permiten aprovechar mejor las características de SQL Server. Como resultado de los cambios en las bases de datos de Windows SharePoint Services, IIS juega un papel menos destacado en relación con la arquitectura SharePoint que el que tenía en SharePoint Team Services. Comprender esta arquitectura le permitirá determinar cómo desarrollar aplicaciones en la plataforma Windows SharePoint Services. |