WSS – Windows Sharepoint Services

 

Parte 1 – Arquitetura e Instalação

 

Objetivo

 

O Windows Sharepoint Services (WSS), é um add-on grátis (logicamente para quem já comprou o Sistema Operacional), para o Windows Server 2003 que permite aos usuários trabalharem em regime de colaboração em projetos e preservar várias versões dos documentos compartilhados.  Ele é uma versão simplificada do Portal Corporativo da Microsoft, o Sharepoint Portal Server, que permite o desenvolvimento de Intranets departamentais e portais para empresas de pequeno e médio porte.

 

Vamos abordar nessa série, todas as particularidades do WSS esperando contribuir para sua popularização por se tratar de uma ferramenta poderosa e muito útil – principalmente para o segmento de Small and Médium Business – na divulgação do conhecimento corporativo, facilitação do trabalho departamental e consolidação de documentações de grande freqüência de atualização.

 

Iniciaremos abordando sua arquitetura, sua dependência de outros serviços e a preparação do ambiente e infra-estrutura da empresa para a instalação de uma Intranet baseada no WSS.

 

Introdução

 

As tecnologias e produtos Microsoft Sharepoint compreende o Sharepoint Portal Server para sites de portais corporativos e o Windows Sharepoint Services (WSS), para sites departamentais.

 

O Sharepoint Portal Server 2003 é um servidor de portal corporativo seguro e escalonável construído sobre o WSS que permite que você agregue sites Sharepoint, informações e aplicações dentro de um único site de portal.  Todos os recursos do WSS estão disponíveis no Sharepoint Portal Server 2003.

 

O WSS pode ser considerado o irmão menor do Sharepoint Portal Server da Microsoft, composto de uma coleção de serviços para o Windows Server 2003 que permite que os usuários organizem e compartilhem as informações de modo mais fácil em um ambiente colaborativo.  Ele pode ser utilizado para compartilhar informações, permitir a colaboração sobre documentações entre os usuários e criar listas e páginas baseadas em Web Parts.

 

História

 

A maioria das situações decorrentes do compartilhamento de documentos que são freqüentemente atualizados acaba terminando em uma grande confusão.

 

Uma das situações que geram essa confusão é justamente o fato de dois ou mais usuários poderem atualizar um mesmo documento que está localizado em uma pasta compartilhada.  Imagine, por exemplo, o que acontecerá se dois usuários tentarem fazer atualizações contraditórias ao mesmo tempo?  E se um usuário fizer uma atualização que cause estragos no documento durante o processo, inutilizando-o?

 

As empresas têm vivido com essas questões e problemas há anos e isso tem estimulado o desenvolvimento de soluções como o WSS.

 

Na tentativa de satisfazer as necessidades de um pequeno departamento, um grupo dentro da Microsoft criou um portal para resolver esses problemas. Como o grupo era responsável pelo Office, ele tomou como base o FrontPage Server Extensions.

 

Esta aplicação, batizada como Sharepoint Team Services (STS), permitiu o desenvolvimento de sites locais com mais rapidez, com menor custo e mais fácil de se manter.  Ela foi desenvolvida usando-se extensões proprietárias ISAPI2. Porém, devido a um conjunto limitado de ferramentas, a padronização e ampliação sites STS tornou-se difícil. O WSS é o fruto do aprimoramento dessa primeira versão e foi construído tendo com base na framework.NET permitindo a criação de Web Parts utilizando-se o Visual Studio.NET, com as linguagens C# ou Visual Basic.

 

As Web Parts são bibliotecas que possuem controles parametrizáveis e que se associam ao WSS para desempenhar funções específicas. Por exemplo, existem Web Parts de calendários, agendas, de criação de relatórios e muitas outras.  Isso permite que sejam montadas páginas padronizadas para cada funcionalidade, basta ter a Web Part para disponibilizar o serviço no site.

 

Com o WSS resolveu-se também o problema com escalabilidade, permitindo um ambiente com vários sites e usuários.   É interessante notar que, apesar de ser ‘descendente’ do FrontPage Server Extension, para instalar o WSS, o site não pode ter essas extensões instaladas, porque o WSS é incompatível com elas.  Desse modo, quando já temos um ambiente de web instalado na empresa, com o Outlook Web Access ou um Gerenciador de backup por exemplo, é importante não tentar instalar o WSS no Default Web Site.  Isso porque ele solicitará a desinstalação das extensões do FrontPage o que fará com que você provavelmente passe seu final de semana consertando o ‘estrago’ L.

 

Alguns dos novos recursos do WSS, em relação ao STS, para os usuários são:

 

» Manutenção de versões e check-in e check-out de documentos – Este recurso permite ao usuário ‘retirar’ o documento de circulação (check-out), bloqueando enquanto faz a edição para alteração do mesmo, impedindo que outros usuários reescrevam suas alterações inadvertidamente.

 

» Novas listas e Views – Este recurso cria uma biblioteca de figuras para o compartilhamento de gráficos e fotos digitais.  Também cria uma lista de rastreamento para manter um histórico sobre um assunto específico.  Os usuários podem incluir anexos nos itens da lista, incluindo páginas HTML, documentos imagens.  Os proprietários de listas podem aprovar, rejeitar e adicionar comentários aos itens que são submetidos a elas.   Eles também configurar permissões permitindo que somente usuários específicos façam alterações.

 

» Suporte para templates de site e listas – Os usuários podem salvar listas como templates e reutilizá-los ou distribuí-los para outros sites.   Os administradores e Web Designers podem salvar sites como templates para manter as melhores práticas ou definir um padrão consistente.

 

» Suporte para Web Parts e Web Part Pages – Cada lista em um site é uma Web Part que permite uma fácil customização e personalização utilizando o browser (Internet Explorer, por ex.).  Os usuários podem customizar as Web Parts e adicioná-las em uma página.

 

» Criação rápida de páginas e sites – Os usuários podem ir para uma página para criar qualquer lista do Sharepoint, como listas de discussão, biblioteca de documentos e outras.  Eles podem criar sites on demand sem o envolvimento do departamento de TI, utilizando o Self-Service Site Creation.

 

Arquitetura

 

A arquitetura do Sharepoint Team Services foi melhorada consistentemente e aumentada no WSS.  Suas configurações e informações do site, junto com todo seu conteúdo, como todas as listas de dados, todos os documentos em bibliotecas de documentações e outros conteúdos de página, são agora armazenadas no Microsoft SQL Server ou no Microsoft Windows SQL Server 2000 Desktop Engine (WMSDE).

 

Instâncias do SQL Server 2005 Express também podem ser utilizadas para esse fim.  Não é grande a distância que separa o File System e o banco de dados, porém essa alteração foi realizada pelas seguintes razões:

 

» Capacitar o WSS a se comportar de modo aceitável em instalações maiores – O dado em database pode ser controlado de modo transacional de maneira que não é necessário travar o web site sempre que um arquivo é salvo.

 

» Melhorar a disponibilidade do servidor – Se existem vários servidores web em um Server Farm, quando um sofre uma falha, outro pode tomar seu lugar sem perda de acesso a qualquer conteúdo.

 

» Melhorar a integridade dos dados armazenados – A possibilidade de conflitos entre informações da database e do file system foi removida e pode-se faze o backup da database facilmente.

 

Além disso, pelo fato da nova arquitetura reduzir a dependência do Windows registry e do metabase do IIS de cada servidor que roda do WSS, é possível agora, criar um sistema de Server Farm com vários servidores e hospedar mais web sites do que era possível com o Sharepoint Team Services.

 

Configurações do Windows Sharepoint Services

 

Existem duas configurações do WSS disponíveis para escolha: servidor stand-alone ou Server Farm.  Se houver a previsão de um uso light dos web sites, pode-se utilizar a configuração de servidor stand-alone.  Se houver a necessidade de suportar web sites em uma grande corporação ou em um Internet Service Provider (ISP), e uma previsão de uso pesado dos sites com uma grande quantidade de dados, é preferível utilizar a configuração de Server Farm.

 

Configuração Stand-alone

 

Uma configuração de servidor stand-alone possui as seguintes características:

 

» Há um único servidor rodando o Windows Sharepoint Services.

 

» Vários sites e sub-sites são agrupados em coleções de sites (site collections) em cada um dos servidores virtuais no IIS com o WSS.  Um filtro ISAPI (Internet Server Applications Program Interface) mapeia as entradas de urls para os sites específicos no servidor virtual.

 

» O escalonamento é conseguido pela adição de site collections em um servidor virtual ou por adição de sub-sites em uma site collection pré-existente.

 

» Cada servidor virtual tem seu próprio conjunto de databases de conteúdo em SQL Server ou WMSDE – A database de configuração direciona cada servidor virtual para a database de conteúdo apropriada para o web site.  O conteúdo para o web site top-level e qualquer sub-site dentro de uma site collection é armazenada na mesma database de conteúdo.

 

Figura - 1- Arquitetura Stand-alone do WSS

 

Nesta Figura podemos visualizar uma arquitetura similar àquela usada pelo Sharepoint Team Services, com exceção de que todos os dados agora estão em base de dados no SQL Server ao invés de dividi-lo entre a database e o file system.

 

Configuração Server Farm

 

Essa configuração tem as seguintes características:

 

» Existem vários servidores rodando o WSS e SQL Server;

 

» Os vários sites e sub-sites estão agrupados em site collections em cada servidor virtual no IIS com o WSS.  Um filtro ISAPI mapeia as urls que entram para os sites específicos no servidor virtual;

 

» Cada servidor virtual tem seu próprio conjunto de databases de conteúdo no SQL Server. A database de configuração para o Server Farm direciona cada servidor para a database de conteúdo apropriada para um dado web site.  O conteúdo do web site top-level e qualquer sub-site dentro de uma site collection é armazenado na mesma database de conteúdo;

 

» O desempenho e a capacidade aumentam pela adição de servidores com WSS e SQL Server;

 

» O escalonamento é alcançado pela adição de mais servidores web front-end (para aumentar a quantidade de trabalho para um conteúdo existente), e/ou pela adição de web sites top-level e sub-sites (para suportar mais conteúdo);

 

» O balanceamento de carga é alcançado utilizando-se switches e roteadores (hardware) ou softwares como o Windows Network Load Balancing Services.

 

Figura - 2 - Arquitetura Server Farm do WSS

 

Aqui podemos notar os maiores efeitos das alterações de arquitetura.  Pelo de fato de se armazenar as informações do site em databases, é possível distribuir a carga entre diversos servidores web front-end rodando o WSS que, por sua vez, se comunicam diretamente com a database apropriada.  Assim, a requisição que vem do cliente pode ir para qualquer servidor web front-end e mesmo assim conectar-se aos dados corretos do web site.

 

Em um Server Farm, cada servidor web front-end com WSS pode hospedar vários servidores virtuais.  Cada servidor virtual, por sua vez, pode ter vários site collections, que podem ter um web site top-level e vários sub-sites.

 

Figura - 3 - Hierarquia da Arquitetura Lógica

 

Servidores Virtuais

 

Um servidor virtual (Virtual Server) corresponde a um Web Site no IIS e é um modo de subdividir a estrutura de um Web Server, dando um controle mais detalhado sobre as configurações de grupos de web sites.  Assim, ao invés de configurar todo um servidor, podem-se configurar as propriedades para um único servidor virtual.  É possível também configurar a autenticação na base do servidor virtual, de modo que diferentes servidores virtuais podem usar diferentes métodos de autenticação.   Isso significa que, se existem sites na intranet da empresa e sites publicados na Internet, pode-se hospedá-los em diferentes servidores virtuais e usar o método de autenticação mais apropriado para cada ambiente.

 

Como podemos ver, o uso de servidores virtuais permite o isolamento de um site do outro.  É possível especificar diferentes Application Pools (um grupo de urls servidas por um worker process no Internet Information Services 6.0) para diferentes servidores virtuais e com isso, certificar-se de que as alterações realizadas nas configurações de um site não serão propagadas acidentalmente para outros sites em outros servidores virtuais.

 

O Sharepoint Team Services suporta aproximadamente 1000 servidores virtuais por servidor.  O WSS suporta muito menos – aproximadamente 10.  Essa diferença é devido ao uso do ASP.NET, que cria um conjunto de dlls compiladas para cada servidor virtual.  Devido ao fato do WSS utilizar várias dlls grandes, não é prático carregá-las todas na memória ao mesmo tempo, pois cada servidor virtual estendido com o WSS consome aproximadamente 50 MB de memória por base de conjunto de processos, incluindo o ASP.NET.  Entretanto, pelo fato de se hospedar vários site collections em cada servidor virtual, não deve ser necessário criar tantos servidores virtuais no WSS como era necessário no Windows Sharepoint Team Services.

 

Estrutura do URL Namespace

 

Como já vimos, o WSS pode ser usado em uma variedade de ambientes, contemplando desde servidores pequenos ou departamentais até servidores em um Server Farm extenso dentro de um Provedor (ISP).  Para processar esses ambientes, o WSS rodando sobre a plataforma do IIS 6.0, permite a configuração da URL namespace de vários modos, cada qual baseado no tipo de site que se deseja criar. O WSS suporta os seguintes tipos de sites:

 

» Sites baseados no nome do domínio – É possível criar vários site collections com o nome do domínio de rede na URL como por ex. http://servicos ou http://servicos.netkon.corp.  Isso permite aos usuários criarem urls simples e curtas.

 

» Sites baseados nos nomes de sub-pastas – É possível criar vários site collections com nomes de sub-pastas de uma url de domínio, por exemplo, http://www1srv/contabilidade/apagar ou http://www.netkon.corp/contabilidade/apagar/relatorios. Utiliza-se este tipo de estrutura para mostrar a hierarquia dos sites na empresa.

 

Depois de tomada a decisão sobre quais tipos de site suportará, de acordo com a necessidade da empresa, pode-se escolher uma das seguintes configurações de namespace.

 

» Um site baseado em nome de domínio por servidor virtual – Por exemplo, o www1svr pode conter os sites http: //servicos, http: //formularios, e assim por diante, com cada web site top-level como um servidor virtual separado e com a sua própria database.  Esse cenário permite o isolamento dos sites provendo melhor segurança.

 

» Vários sites baseados em nomes de sub-pastas por servidor virtual – Por exemplo, o www1svr pode conter os sites http://www1svr/rh, http://www1svr/ctb e assim por diante, com cada servidor virtual hospedando vários sites WSS e outras aplicações web ao mesmo tempo.  Todos os sites de um servidor virtual podem compartilhar a mesma database de conteúdo.  Isso permite que web sites de equipes coexistam com os portais de outras aplicações(com exceção daquelas que necessitam das extensões do FrontPage pra funcionar).

 

» Um site baseado em nome de domínio e vários sites baseados em nomes de sub-pastas por servidor virtual – Por exemplo, o servidor www1svr pode conter os sites http://ctb/apagar, http://ctb/areceber, http://ctb/apagar/forms http://rh/webfolha e assim por diante.  O servidor virtual contém um web site top-level baseado em WSS.  As sub-pastas desse site podem ser web sites WSS ou serem utilizadas para aplicações web.  Todos os sites em WSS no mesmo servidor virtual compartilham a mesma database.

 

» Dois servidores Virtuais hospedando o mesmo conteúdo (cenário de extranet) – Por exemplo, o servidor www1svr hospeda o http://intranet e o www2_Server hospeda o https://intranet.netkon.corp.  Ambos os servidores virtuais – que podem estar em diferentes máquinas – compartilham a mesma database e disponibilizam o mesmo conteúdo para criar uma intranet e uma extranet.   Os dois servidores podem ter diferentes configurações de segurança no IIS – requerer acesso SSL para a extranet e acesso anônimo para a intranet, por ex. – mas compartilham o mesmo conteúdo.

 

NOTA: A funcionalidade Recalculate hyperlinks do FrontPage 2003 não pode ser utilizada neste cenário porque fixar o link para um caminho url quebrará os links para os outros.

 

» Vários sites baseados em nomes de domínio por servidor virtual (Cenário de hospedagem em larga escala) – Por exemplo, o servidor www1srv hospeda http://gkonnus.netkon.corp, http://ekonnus.netkon.corp e assim por diante.  Cada um desses sites é um site top-level no mesmo servidor virtual, mas eles são mapeados para diferentes urls.  Pode haver uma ou mais databases de conteúdo, dependendo da escala.

 

A Comunicação entre o Cliente e o Servidor

 

O Microsoft Office FrontPage 2003 se comunica com o WSS utilizando HTTP, que é o mesmo protocolo que os Web Browsers e Web Servers utilizam para se comunicarem.  O Front Page executa um mecanismo de RPC (Remote Procedure Call) no alto da requisição HTTP POST, que permite que ele requisite documentos, atualize a lista de tarefas, adicione novos usuários, etc.

 

O servidor web vê as requisições POST endereçadas para o filtro ISAPI (Internet Server Applications Program Interface) para WSS e as direciona de acordo.  O FrontPage se comunica sem problemas com o servidor através de servidores Proxy (firewalls).

 

NOTA: O FrontPage não usa a requisição HTTP PUT.  Pelas especificações HTTP a requisição PUT envia um documento para o servidor web, entretanto, poucos servidores web executam o PUT.  Portanto, o FrontPage usa a requisição HTTP POST, que é executada universalmente, para todas as comunicações com o WSS.

 

O WSS não segue o modelo “Criar e depois Publicar” que muitos estão acostumados a seguir com outros web sites.  Um site criado no WSS é disponibilizado imediatamente no servidor, de modo que não é necessário publicá-lo.   É possível ainda editá-lo com um editor de web sites compatível como o Office FrontPage 2003, ou adicionar páginas e documentos ao site, mas não é necessário publicar as alterações.  Elas se tornam ativas imediatamente após salvar os arquivos.

 

Mapeando URLs para Caminhos Físicos

 

O WSS trabalha o mapeamento de urls entrantes para o conteúdo do site nas databases.  Quando é utilizada a configuração Server Farm, os vários sites são armazenados em cada database de conteúdo.  Uma database de conteúdo mantém a informação sobre quais sites estão mapeados para quais databases.  As databases de conteúdo, por sua vez, armazenam todo o conteúdo do site e disponibilizam o conteúdo requisitado pelo web servers front-end. Em comparação com o Sharepoint Team Services, pelo fato do seu conteúdo ser armazenado tanto o sistema de arquivos como no IIS metabase, quem responde pelo mapeamento é o próprio IIS.

 

Como o mapeamento de um site e de sua database é baseada na url do site, não podem haver duas urls apontando para o mesmo site.  Por exemplo, não se podem utilizar as urls http://www1svr/site1 e http://www.www1svr.com/site2 para apontar para o mesmo conteúdo na database.  Mas pode-se, entretanto, conseguir o mesmo efeito configurando a url http://www1sv/site1 para redirecionar para a url http://www.www1svr/site2.

 

A exceção para esta regra está no cenário intranet/extranet, onde se podem ter dois servidores virtuais mapeando o mesmo conteúdo do site com ambas as urls, como já dissemos.  Veremos como realizar essa configuração nos artigos posteriores.

 

Trabalhando com Páginas ASP.NET (Páginas ASPX)

 

O WSS utiliza páginas ASP.NET (Active Server Pages ou ASPX pages), para criar formulários e listas.  Essas páginas podem ser customizadas e é possível incluir páginas ASP.NET adicionais para rodar soluções customizadas no topo do WSS.

 

As páginas ASP.NET na pasta _layouts de um site Sharepoint roda no modo direto, o que significa, logicamente, que têm permissão pra rodar diretamente.  A pasta _layouts contém páginas de aplicações fixas.  Essa pasta não é considerada parte do web site e as páginas dela são disponibilizadas diretamente pelo IIS quando requisitadas.

 

As páginas ASP.NET dentro de um web site rodam em modo de segurança.  Nesse modo, as páginas ASP.NET não são compiladas em DLLs e somente uma parte específica de controles (identificada previamente como “segura”), têm permissão pra rodar.  Você pode editar a lista de controles “seguros” permitidos para rodar nos sites em um servidor virtual específico editando o arquivo web.config para um virtual Server.

 

Conclusão

 

Apesar de parecer ‘prosa para sonolentar o vacume’, esta parte de arquitetura é muito importante para a realização de um projeto de infra-estrutura de intranets, extranets e sites departamentais baseada em qualquer tipo de serviço de portal como o WSS.  Grande parte desse artigo foi traduzida do Guia do Administrador do WSS (que não existe em Português), e eu o fiz por acreditar realmente que os dados de arquitetura de um serviço devem ser estudados e entendidos pelo administrador de redes corporativas antes de pensar em utilizá-lo.

 

Muitas vezes, serviços como o WSS são instalados e configurados de forma errônea causando transtornos administrativos e, depois de disponibilizados, todos nós sabemos que se torna muito difícil, ou quase impossível, retroceder para readequar.

 

Por isso um planejamento adequado com o conhecimento do ambiente corporativo e das configurações que podemos criar torna-se extremamente necessário.

 

Se você pretende utilizar o WSS em ambiente de Small Business ou pretende realizar um projeto em uma grande corporação, precisa ter noção da capacidade e dos limites do produto para ser bem sucedido.  Lembre-se de que, para os negócios de uma empresa, a informação dispersa e sem padronização é pior do que nenhuma informação.

 

No próximo artigo veremos como instalar e configurar corretamente o WSS.

 

Bibliografia

 

» José Miguel de Bessa Carvalho - Integração On-line com Sharepoint – Monografia do Departamento de Engenharia do Instituto de Engenharia do Porto, Portugal.  2004. 115 pgs. - http://www2.dei.isep.ipp.pt/pest/2004-2005/docs/1990309_pest_rel.pdf

 

» Microsoft Windows SharePoint Services Help 2.0 - http://go.microsoft.com/fwlink/?LinkId=35839&clcid=0x409

 

» Administrator's Guide for Microsoft Windows SharePoint Services - http://www.microsoft.com/downloads/details.aspx?FamilyID=a637eff6-8224-4b19-a6a4-3e33fa13d230&DisplayLang=en Windows SharePoint Services V3 – SDK Documentation http://msdn2.microsoft.com/en-us/ms540025(MSDN.10).aspx

 

UNIVERSIDADE DO WINDOWS SERVER E AD

UNIVERSIDADE PRÁTICA DO WINDOWS SERVER E DO ACTIVE DIRECTORY - Planejamento, Instalação, Configurações, Administração e Segurança no Windows Server: 2019, 2016, 2012 e 2008.

Acesso Vitalício, Novas Aulas toda Semana, Suporte à Dúvidas e Certificado de Conclusão.

Para Todos os Detalhes, Acesse:     https://juliobattisti.com.br/windows-server-curso-completo.asp