Revista MSDN Magazine Edição 10 - SHAREPOINT Use o Windows SharePoint Services como uma plataforma para criar aplicativos de colaboração

Clique aqui para ler todos os artigos desta edição

SHAREPOINT

Use o Windows SharePoint Services como uma plataforma para criar aplicativos de colaboração

por Jason Masterman e Ted Pattison

Nos últimos anos, a Microsoft fez investimentos significativos em tecnologias de colaboração. O WSS (Windows® SharePoint® Services) e o SPS (SharePoint Portal Server) são dois produtos líderes posicionados neste espaço. Neste artigo apresentaremos a arquitetura fundamental do SharePoint e discutiremos as oportunidades fornecidas pelo SharePoint para os desenvolvedores que utilizam o Microsoft® .NET Framework.

O Windows SharePoint Services é um produto add-on que é considerado parte oficial do sistema operacional Windows Server 2003. O WSS fornece um framework para a criação de Web sites de colaboração que permitem que uma empresa compartilhe, de maneira fácil e confiável, informações e documentos entre equipes, departamentos e grandes empresas. Qualquer usuário pode acessar um Web site WSS usando um navegador Web ou através dos novos recursos de colaboração incluídos nos produtos do Microsoft Office 2003, tais como o Word e o Excel.

O WSS também fornece a infra-estrutura para a geração de interfaces de usuário, disponibilizando Web Part Pages e Web Parts. As Web Part Pages e as Web Parts representam um aspecto avançado do SharePoint porque cada site WSS fornece uma interface de usuário baseada em navegador que é totalmente personalizável. Os Web Parts também podem ser usados para rastrear as informações de personalização de cada usuário.

O SharePoint Portal Server 2003 é usado para criar sites de portais no nível de empresa que são partes do Microsoft Office System 2003. É importante notar que o SPS é criado em cima dos WSS. O SPS complementa o WSS, adicionando recursos de gerenciamento que foram projetados para auxiliar os usuários durante a navegação em grandes volumes de informações e documentos. O SPS também fornece funcionalidades adicionais para aprimorar os sites de portal que usam indexação, busca, audiência e assinaturas únicas.

Existe uma diferença fundamental nas funções desempenhadas pelo WSS e o SPS, conforme mostrado na Tabela 1. O WSS é baseado na idéia de colaboração, no sentido de que ele é projetado para armazenar e compartilhar documentos e dados baseados em listas. O SPS, por outro lado, é baseado na idéia de agregação. Um portal SPS é útil para agregar informações e documentos de vários lugares diferentes. O SPS agrega valor porque dá aos usuários uma maneira fácil e rápida de localizar informações e documentos que estejam espalhados em uma rede privada ou na Internet.

Tabela 1 As funções do WSS e do SPS

Em essência, o WSS fornece um local onde colocar todo o seu conteúdo, enquanto o SPS fornece os meios de navegar e pesquisar o conteúdo quando você precisa. Essas duas funções se complementam entre si. O WSS permite que uma empresa crie e mantenha milhares de Web sites de colaboração, enquanto um ou mais sites de portal SPS permitem que os usuários pesquisem todo esse conteúdo para encontrar o que procuram.

Você precisa compreender que o SPS depende do WSS para fornecer muitos serviços essenciais. Por exemplo, o WSS dá ao SPS capacidade de rastrear membros e compartilhar listas e documentos. Além disso, o SPS não precisa reinventar seu próprio mecanismo de renderização para gerar o HTML para a interface de usuário de um site de portal. Em vez disso, o SPS aproveita a infra-estrutura do WSS Web Part Page e do Web Part para construir a interface de usuário de um site de portal SPS.

Windows SharePoint Services

O WSS é gratuito para qualquer indivíduo ou empresa que tenha adquirido o sistema operacional Windows Server 2003. É possível fazer o download dos arquivos de instalação do WSS por meio do serviço Windows Update ou diretamente no site Microsoft.com.

O framework WSS é criado no topo do Windows Server 2003, IIS 6.0 e ASP.NET. A Figura 1 mostra como as peças fundamentais do framework WSS se encaixam. Note que, para instalar com sucesso o WSS no Windows Server 2003, você precisará primeiro configurar o computador host como um Application Server, ativando o IIS 6.0 e o ASP.NET 1.1.

Figura 1 Arquitetura do WSS

Aprender sobre o WSS é fácil depois que você conhece alguns aspectos da história do produto. O WSS é parte da segunda geração de produtos e tecnologias SharePoint. A primeira geração foi criada sobre um framework baseado em IIS, denominado STS (SharePoint Team Services). O framework STS é semelhante ao WSS no sentido de que ele fornece um framework de colaboração para o compartilhamento de dados e documentos baseados em lista. No entanto, o STS não foi desenvolvido sobre o .NET Framework ou ASP.NET. Em vez disso, ele usava uma extensão ISAPI proprietária.

A personalização e a extensão dos Web sites STS foi sempre relativamente difícil devido ao suporte limitado à ferramenta. A personalização do site é muito mais fácil com o WSS e com a segunda geração do SharePoint devido aos Web designers compatíveis com WSS, tais como o FrontPage® 2003. O WSS também oferece um modelo de extensibilidade muito melhor porque você pode escrever aplicativos e Web Parts personalizados para sites WSS e de portais SPS com Visual Studio .NET, usando C# ou Visual Basic® .NET.

O STS e a primeira geração de produtos e tecnologias SharePoint também sofreram problemas de escalabilidade. Uma arquitetura subjacente que execute um design stateful em servidores Web de front-end é responsável. Essa falha torna impossível escalonar Web sites STS usando um ambiente de Web farm. Quando os engenheiros da Microsoft começaram a projetar o WSS e a segunda geração de produtos e tecnologias SharePoint, eles estabeleceram como principal meta solucionar os problemas de escalonamento do STS. Conseqüentemente, eles projetaram a arquitetura de modo a oferecer suporte a implantações WSS e SPS com milhares de usuários e Web sites.

A arquitetura WSS é baseada em servidores Web de front-end stateless. Ela é fundamentada em uma estratégia de armazenamento integrado na qual todos os dados e documentos baseados em lista e associados a um Web site são armazenados em um banco de dados SQL Server, conforme mostrado na Figura 2. O principal objetivo dessa estratégia de armazenamento integrado é permitir a implantação de servidores Web WSS visando a um escalonamento eficaz em um ambiente Web farm.

Figura 2 Configuração de ambiente Web Farm

Bancos de dados

O WSS depende de dois tipos diferentes de bancos de dados SQL Server: bancos de dados de configuração e bancos de dados de conteúdo. Como você já deve suspeitar, o banco de dados de configuração armazena informações de configuração específicas à implantação para cada servidor Web físico, servidor virtual IIS e Web site WSS. Os bancos de dados de conteúdo, por outro lado, armazenam os dados associados aos Web sites WSS.

O WSS requer exatamente um banco de dados de configuração para cada implantação de servidores Web WSS. Uma implantação simples pode envolver um único computador host (que execute tanto componentes de servidor Web de front-end WSS como SQL Server com o banco de dados de configuração) como um banco de dados de conteúdo único. Uma implantação WSS mais escalonável envolve um cenário Web farm com vários servidores Web de front-end. Uma implantação WSS também pode envolver vários servidores de banco de dados back-end. Por exemplo, em algumas implantações, é possível obter as vantagens de escalonamento espalhando vários bancos de dados de conteúdo em diferentes computadores host que executam SQL Server. No entanto, existe apenas um banco de dados de configuração para cada implantação de WSS. O banco de dados de configuração fornece um repositório de informações central para coordenar todos os servidores front-end e back-end.

Cada banco de dados de conteúdo armazena os dados de um ou mais Web sites WSS. Os dados do WSS que são armazenados em cada site, individualmente, incluem listas, documentos e informações referentes à personalização do site. Essa estratégia de armazenamento integrado permite um aprimoramento definitivo no STS onde os dados específicos ao site eram armazenados no sistema de arquivos e no registro, além de no banco de dados. O fato de que tudo que pertence ao site seja armazenado dentro de um único banco de dados SQL Server torna significativamente mais fácil fazer backup e restaurar os Web sites sob WSS.

Se estiver apenas começando com o WSS, você pode instalar tudo que precisa em um único computador executando Windows Server 2003. Uma vez instalado o Windows Server 2003, configure o computador como um Application Server ativando o IIS 6.0 e o ASP.NET 1.1. Quando você configurar o IIS e o ASP.NET, certifique-se de que não tenha instalado o FrontPage Server Extensions porque elas são incompatíveis com WSS. Depois que puder instalar o WSS por meio do programa de instalação STSV2.EXE.

No caso de implantações em máquina individual, o WSS não exige que você use a versão full-blown do SQL Server. O programa de instalação do WSS pode opcionalmente instalar uma versão especial do MSDE denominada WMSDE (Windows MSDE). WMSDE é diferente da versão padrão do MSDE porque ele não limita você a 2GB de armazenamento e 10 conexões de banco de dados. No entanto, o WMSDE é mais restritivo que o MSDE porque ele só suporta esquemas de tabela assinados pela Microsoft. Isso significa que você não pode usar o WMSDE para criar suas próprias tabelas e bancos de dados personalizados.

Se você quiser instalar o SPS em uma estação de trabalho de desenvolvimento, o processo de instalação será mais complicado. Em primeiro lugar, existem vários recursos do SPS que exigem o uso do Active Directory. Desse modo, você deve instalar o SPS em servidores que façam parte de um domínio do Active Directory®. Antes de instalar o SPS em um computador host que execute o Windows Server 2003, adicione primeiro essa máquina a um domínio Active Directory existente ou configure-a para ser um controlador de domínio. Como o computador que executa o Windows Server 2003 é um domínio, configure-o para que seja um Application Server, ativando o IIS 6.0 e o ASP.NET 1.1. Com o SPS, também recomendamos que você instale o SQL Server em vez de depender do WMSDE para armazenar o banco de dados para os sites de portais.

Uma vez instalado o Windows Server 2003 em um computador com o IIS 6.0, o ASP.NET 1.1 e SQL Server, e após adicioná-lo a um domínio Active Directory, você está pronto para instalar o SharePoint Portal Server 2003. A primeira coisa que o programa de instalação do SPS fará será instalar o WSS. Em seguida, o SPS se auto-instalará no WSS. Por fim, o instalador do SPS exibe um assistente que o guiará durante a criação do banco de dados de configuração e do site de portal inicial.

Observe que o SPS cria bancos de dados adicionais para rastrear dados de serviços SPS, perfis de usuário, audiência e credenciais de segurança para o serviço de assinatura única. O SPS também estende os esquemas do banco de dados WSS padrão para o banco de dados de configuração, bem como para os bancos de dados de conteúdo que contêm sites de portal.

Antes de instalar o WSS ou o SPS em uma implantação com SQL Server (ao contrário do WMSDE), é possível que você seja solicitado a adicionar um login SQL para a conta do Windows que funciona como a identidade dos pools de aplicativo IIS usados pelo SharePoint. Por padrão, o WSS e o SPS configuram os pools de aplicativos IIS para serem executados sob a identidade da conta NT AUTHORITY\NETWORK SERVICE. Caso não goste dessa configuração padrão, você poderá reconfigurar qualquer pool de aplicativos IIS para usar uma conta do Windows diferente. No entanto, seja qual for a conta Windows que decida usar, você precisará ter um login SQL para se conectar ao SQL Server.

Depois de adicionar o login de SQL para a conta apropriada no SQL Server, você precisará adicionar a conta aos Server Roles of Security Administrators e aos Database Creators. Se não seguir essas etapas, ocorrerão erros quando você instalar ou configurar o WSS ou o SPS. Isso ocorre porque, por padrão, o WSS e o SPS usam pools de aplicativos IIS que são executados com a identidade da conta NT AUTHORITY\NETWORK SERVICE, que não tem permissão para fazer logon no SQL Server. Você precisa configurar o SQL Server para conceder a essa conta as permissões apropriadas para criar bancos de dados e configurar suas definições de segurança.

Web sites IIS e servidores virtuais

A configuração do Web site WSS começa no nível do Web site IIS. Uma instalação default do IIS cria um Web site IIS denominado "Default Web Site", que é configurado para escutar as solicitações de HTTP de entrada feitas na porta 80. Você pode usar as ferramentas administrativas do IIS para criar Web sites IIS adicionais que escutem as solicitações de HTTP de entrada em uma porta diferente ou com um cabeçalho de host diferente. A Figura 3 mostra um exemplo de um servidor Web IIS com dois servidores virtuais que foram configurados para acesso do usuário.

Figura 3 Dois servidores virtuais para acesso de usuário

Note que a instalação do WSS adiciona seu próprio Web site IIS especial, denominado SharePoint Central Administration. O WSS usa esse Web site IIS para executar as páginas HTML do SharePoint Central Administration. O Web site SharePoint Central Administration é configurado para usar um número de porta aleatório durante a instalação.

Na terminologia do SharePoint, um Web site IIS é conhecido como um servidor virtual. Para executar Web sites WSS, é necessário que o servidor virtual seja estendido com WSS. Quando você instala o WSS com as configurações padrão, ele estende automaticamente o servidor virtual que está escutando na porta 80. Você pode estender o WSS para outro servidor virtual, usando as páginas HTML do SharePoint Central Administration ou uma ferramenta de administração de linha de comando denominada STSADM.EXE.

O WSS é diferente do ASP.NET, já que ele não usa um diretório virtual IIS para configurar cada Web site. Em vez disso, o WSS rastreia todas as informações de configuração dos Web sites WSS dentro do banco de dados de configuração e dos bancos de dados de conteúdo. Isso significa que, quando o WSS tive estendido um servidor virtual e você começar a criar Web sites WSS, eles não aparecerão no metabase IIS. Em vez disso, será criada uma entrada no banco de dados de configuração e no banco de dados de conteúdo apropriado. Na realidade, o IIS não sabe se um servidor virtual estendido para WSS contém um único Web site WSS ou 10.000 Web sites WSS. Como o WSS não precisa configurar um diretório virtual do IIS para cada novo Web site WSS, você obtém uma escalabilidade melhor e uma manutenção aprimorada.

Quando o WSS se auto-estende em um servidor virtual, ele instala um filtro ISAPI personalizado denominado WSS filter (STSFLTR.DLL), que intercepta cada solicitação roteada para aquele servidor virtual e determina se a solicitação deve ser tratada pelo WSS ou pelo IIS. Para fazer essa determinação, o WSS filter inspeciona a URL da solicitação de entrada e consulta o banco de dados de configuração para determinar quem deve processá-lo. Lembre-se de que você pode ter um servidor virtual no qual planeje executar sites WSS e outros aplicativos ASP e ASP.NET.

Quando o WSS se auto-estende em um servidor virtual, ele adiciona um arquivo web.config ao diretório-raiz do servidor virtual host. Esse arquivo web.config fornece as definições de configuração iniciais para o WSS e para todo o código ASP.NET que é executado de dentro daquele servidor virtual. Por padrão, esse arquivo web.config contém definições de segurança bastante restritivas. É possível que você seja solicitado a modificar seções desse arquivo web.config quando quiser executar o código com permissões elevadas ou se quiser testar ou implantar uma nova Web Part personalizada.

Na terminologia do SharePoint, um espaço URL é o conjunto de todas as URLs possíveis que levam a um servidor virtual. O WSS divide o espaço de URL do servidor virtual estendido em vários caminhos gerenciados. Os caminhos gerenciados pelo WSS são considerados caminhos incluídos, enquanto os que não são gerenciados pelo WSS são considerados caminhos excluídos. Quando o WSS filter vê uma solicitação de entrada com uma URL que seja parte de um caminho excluído, ele sabe como rotear a solicitação de volta para o IIS para um processamento ASP ou ASP.NET padrão.

O que você deverá fazer para alojar um aplicativo ASP.NET padrão dentro de um servidor virtual que tenha sido estendido com WSS? Por exemplo, imagine que você queira implantar um aplicativo Web ASP.NET em http://AcmeServer/webapp1, de modo que ele esteja disponível junto com os sites WSS no mesmo diretório virtual. Neste ponto, você precisará entender como configurar os caminhos incluídos e excluídos.

Especificamente, você precisará adicionar um caminho excluído ao espaço URL usado pelo aplicativo Web ASP.NET. A Figura 4 mostra parte da interface de usuário fornecida pelas páginas HTML do SharePoint Central Administration para a definição dos caminhos gerenciados.

Observe que a Figura 4 mostra o caminho incluído do servidor virtual, bem como seus caminhos excluídos. Alguns caminhos incluídos (tais como sites) são definidos como "inclusões de caracteres-curinga". A finalidade de uma inclusão de caractere-curinga é tornar mais eficiente a análise da URL. O WSS não permite aninhar caminhos excluídos dentro do espaço de URL de uma inclusão de caractere-curinga. Assim que o WSS filter vê que a primeira parte da URL de uma solicitação de entrada coincide com uma inclusão de caractere-curinga, por exemplo, http://AcmeServer/sites, ele sabe que a solicitação deve ser direcionada ao WSS para processamento.

Figura 4 UI de admin do WSS para definição de caminhos gerenciados

Quando o WSS filter determinar que a URL de uma solicitação de entrada está dentro de um caminho incluído, ele consultará o banco de dados de configuração para localizar o site WSS de destino. O WSS rastreia cada um de seus sites no banco de dados de configuração usando a URL do site URL e uma GUID de identificação. O banco de dados de configuração contém informações adicionais que associam cada site a um banco de dados de conteúdo de destino.

Em uma implantação WSS, é geralmente útil estender mais de um servidor virtual. Você pode querer fazer isso para ter mais flexibilidade. Cada servidor virtual pode ser configurado por meio de um IIS Application Pool para executar seus Web sites WSS em um processo isolado. O IIS também permite configurar os requisitos de autenticação de segurança de maneira diferente para cada servidor virtual. Um servidor virtual pode ser configurado para requerer Basic Authentication, enquanto outro pode ser configurado para requerer Integrated Windows Authentication.

Em algumas implantações, cada servidor virtual estendido para WSS terá seu próprio banco de dados de conteúdo separado. Também é possível estender um servidor virtual de modo que ele seja associado ao mesmo banco de dados de conteúdo usado por outro servidor virtual. Isso permite que um par de servidores virtuais forneça dois pontos de acesso diferentes a um conjunto comum de sites WSS. Isso é valioso porque permite configurar as definições de segurança de cada servidor virtual de maneira independente. Por exemplo, um servidor virtual usado para fornecer Web sites voltados ao público será geralmente configurado para requerer SSL e Basic Authentication. É possível configurar um segundo servidor virtual (que forneça acesso aos usuários além do firewall) para que ele exija Integrated Windows Authentication.

Coleções de sites, sites e Workspaces

Em um servidor virtual, os sites WSS são particionados por meio de coleções de site, um conjunto de um ou mais sites que constituem uma unidade de propriedade. Criar uma nova coleção de sites requer que você forneça uma conta de login do Windows e o endereço de e-mail do proprietário da conta. O WSS rastreia as informações dos proprietários da coleção de sites a fim de que possa conceder a eles permissões administrativas e enviar notificações de e-mail relacionadas a questões de manutenção da coleção de sites.

Uma coleção de sites conterá sempre um site de nível superior que utilize a mesma URL da coleção de sites propriamente dita. Quando você criar uma nova coleção de sites, o site de nível superior será criado automaticamente. Além de seu site de nível superior, a coleção de sites poderá conter, opcionalmente, outros sites secundários que sejam relacionados ao site de nível superior por meio de relacionamentos pai-filho, conforme mostrado no diagrama da Figura 5. Cada site precisa ser criado dentro de uma coleção de sites específica e todos os sites da mesma coleção de sites serão armazenados no mesmo banco de dados de conteúdo.

Figura 5 Coleções de sites em um servidor virtual

A coleção de sites funciona como uma unidade de backup e recuperação no WSS. A ferramenta administrativa STSADM.EXE oferece comandos fáceis de usar para o backup e recuperação da coleção de sites. Após fazer o backup da coleção de sites, você poderá recuperá-lo mais tarde no mesmo servidor Web ou em um servidor diferente. Você perceberá que o WSS torna um pouco mais difícil o backup e a recuperação dos sites individuais existentes em uma coleção de sites situada abaixo do site de nível superior. Caso esteja criando um site para o qual deseje fazer o backup e a recuperação de maneira independente, você deverá criá-lo como um site de nível superior, dentro de uma nova coleção de sites.

Ao executar manutenção diária em uma implantação WSS de grande porte, com centenas de milhares de coleções de sites, você não precisará fazer o backup das coleções de sites individualmente. Em vez disso, você poderá efetuar backups no nível do banco de dados de conteúdo. Para muitas empresas, o backup dos bancos de dados será um procedimento razoavelmente fácil, já que elas usarão os mesmos procedimentos de manutenção usados no backup de outros bancos de dados SQL Server.

Agora, vamos retornar um pouco e fazer uma pergunta fundamental: o que é um site WSS? Em primeiro lugar, um site é um container para o armazenamento de conteúdo. Os conteúdos do site são basicamente armazenados em forma de listas, bibliotecas de documentos e sites filhos. Segundo, um site é uma entidade que pode ser protegida e cujo conteúdo é acessível a um conjunto configurável de usuários. Um site pode definir seu próprio conjunto de usuários ou pode herdá-los de seu site-pai. Cada usuário do site é mapeado a uma conta Windows definida em um domínio Active Directory ou a um banco de dados de contas de segurança do Windows local. O site também contém um conjunto de grupos e permissões configuráveis que definem o nível de acessibilidade que os diversos usuários têm para as bibliotecas de documentos e para as listas dos sites.

Terceiro: um site também é um aplicativo Web com sua própria interface de usuário totalmente personalizável. O proprietário ou o Web designer do site podem personalizar o layout e a aparência das páginas do site e modificar sua estrutura de navegação usando o browser ou o FrontPage 2003.

Por fim, um site é a base para o uso da tecnologia Web Part Page e Web Part. Os proprietários e Web designers do site podem personalizar as Web Part Pages adicionando e configurando Web Parts compartilhadas. O usuário poderá personalizar ainda mais a Web Part Page por meio de modificações, inclusões ou exclusões de Web Parts. Todos os dados de personalização associados com as Web Parts em uma Web Part Page serão automaticamente armazenados no banco de dados de conteúdo.

O WSS suporta diferentes modelos de site para "workspaces". Tecnicamente falando, uma workspace é na verdade apenas um site WSS padrão. No entanto, a finalidade de uma workspace é definida de forma mais detalhada do que em outros tipos de WSS, porque ela geralmente enfoca um único documento ou reunião. Além disso, os sites que atuam como workspace contêm listas predefinidas para fornecer maior integração com os produtos Microsoft Office, como Word, Excel, Access e Outlook®.

Todo site é inicialmente criado a partir de um modelo de site. Um modelo de site é um esquema que define um conjunto inicial de listas, bibliotecas de documentos, Web Part Pages e Web Parts existentes no novo site. O WSS é fornecido com oito modelos de sites, incluindo Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace e Multipage Meeting Workspace. Da primeira vez que o site é acessado, o WSS pede ao usuário que selecione um dos modelos de site disponíveis, usando a página HTML mostrada na Figura 6.

Figura 6 Selecionando um modelo de site

O WSS suporta a criação e o uso de modelos de site personalizados. Você pode personalizar um site de acordo com o seu gosto no FrontPage 2003 e, em seguida, salvá-lo como um modelo de site. Para salvar o site como um modelo, bastam apenas alguns cliques no browser. Uma vez criado o modelo de site personalizado, ele estará disponível para a criação de novos sites dentro da mesma coleção de sites. Com um pouco de trabalho extra, o modelo de site personalizado poderá ser exportado para outras coleções de sites e ser usado para criar sites de nível superior.

Arquitetura do SPS

O SPS é criado acima da camada de arquitetura fornecida pelo WSS. Quando cria um novo site de portal SPS, você está na verdade criando uma nova coleção física de sites WSS. No entanto, existem algumas restrições dignas de nota a respeito da maneira como o SPS usa o WSS. Só pode haver um site de portal por servidor virtual. Além disso, a coleção de sites que contém um site de portal deverá ser sempre criada na URL-raiz do servidor virtual host.

Uma vez criado o site de portal na raiz do servidor virtual, você poderá então criar coleções de sites WSS padrão adicionais dentro do mesmo servidor virtual. Na verdade, é exatamente o que o SPS faz quando você executa o comando Create Site a partir de um site de portal. Ou seja, o SPS cria um site de nível superior dentro da nova coleção de sites. Quando um usuário de site de portal cria um site pessoal por meio de um clique no link "My Site", o SPS também cria esse site pessoal como um site de nível superior na nova coleção de sites. Essa estratégia facilita o backup e a recuperação de sites pessoais e compartilhados em uma implantação SPS.

O SPS estende a maneira na qual o WSS armazena o conteúdo introduzindo áreas e listagens. Lembre-se de que o SPS é um produto projetado para agregação. As áreas e listagens são usadas pelos gerentes de conteúdo do site de portal para agregar informações de outros locais. Uma área é um container de listagens e subáreas aninhadas. Ocasionalmente, uma listagem conterá texto baseado em HTML. Geralmente, a listagem contém um link para um conteúdo que não faz parte do portal, tal como um documento, uma Web page ou uma lista WSS na rede. O ponto principal é que as listagens permitem que o SPS vincule usuários a informações que não fazem parte do portal, tais como pastas compartilhadas, pastas públicas do Microsoft Exchange, sites WSS, sites Web públicos e Lotus Notes, conforme mostrado na Figura 7.

Figura 7 Listagens do SPS

As áreas do site de portal são estruturadas em uma hierarquia pai-filho. A Figura 8 mostra a interface baseada em HTML fornecida pelo SPS para o trabalho com áreas. Essa interface de usuário torna relativamente simples aos gerentes de conteúdo do site adicionar e excluir áreas e listagens da hierarquia de áreas de um site de portal. O SPS também permite que qualquer pessoa use o browser para realocar uma área ou listagem dentro da hierarquia de áreas.

Figura 8 Áreas do SPS

As áreas e listagens permitem a agregação porque facilitam a navegação pelo conteúdo interno e externo do site de portal. As áreas e listagens também são integradas ao serviço de busca (pesquisa) do SPS. Quando você executa uma busca no SPS dentro do escopo de uma área, o SPS procura nos conteúdos e links das listagens dessa área, bem como no conteúdo e nos links das listagens das subáreas aninhadas abaixo dela.

O serviço de busca do SPS é complementado pelo serviço de indexação do SPS. O serviço de indexação é projetado para criar índices a partir de pesquisas nos links de conteúdo fornecidos pelas áreas e listagens. O serviço de indexação sabe inclusive como pesquisar em documentos do Word e em planilhas do Excel e busca palavras-chave específicas. Uma vez criado o conjunto de índices, o serviço de busca do SPS é capaz de executar buscas rápidas que permitem que os usuários encontrem o conteúdo de que precisam.

Conclusão

Este artigo apresentou um exame detalhado da arquitetura dos produtos e tecnologias do SharePoint. O WSS e o SPS são dois produtos diferentes que foram projetados para trabalhar em conjunto. O WSS fornece a base para criar Web sites de colaboração que ofereçam suporte à personalização. O SPS complementa o WSS, atuando como um agregador de conteúdos. Você viu também que o SPS é totalmente dependente da infra-estrutura subjacente do WSS. Na verdade, quanto mais você conhecer os fundamentos do WSS, mais fácil será obter o máximo dos SPS.

Em certo sentido, os produtos e tecnologias SharePoint reduzem a necessidade de desenvolver softwares personalizados, já que o WSS e o SPS proporcionam inúmeras funcionalidades instantaneamente. O WSS e o SPS também oferecem oportunidades valiosas de escrever aplicativos e Web Parts personalizadas.