Estudando a ferramenta Sharepoint Services Santa Cruz do Sul, Rio Grande do Sul

O software Sharepoint Services possui infra-estrutura para a instalação de uma Intranet baseada no WSS. Esse sistema é de grande utilidade para a comunicação interna das empresas. "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", comenta a autora.

Marcos Cruz
053 - 91673898
Maurity Nº 432
Bagé, Rio Grande do Sul
 
Casa Victor S A Radiorefrigeradora
(51) 3221-6805
r Pedro II,Dom, 111, São João
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Copy Systems
(51) 9244-2593
Rua Ruropa 245
Canoas, Rio Grande do Sul
 
Manlec
8005-12324
r Flores,Dr, 88, Centro
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Comercial Eletrodomésticos Pedro Obino Júnior Ltda
(51) 3029-6151
av Azenha, 1099, Azenha
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Via Vento
(51) 3338-1200
av Montenegro, 11, Petrópolis
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Magazine Luiza S/A
8003-44000
av Assis Brasil, 2488, Passo D Areia
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Austral Indústria Eletro Mecânica Ltda
(51) 3343-1050
r Dezesseis de Julho, 42, An 6 Sl 603, São João
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
Giravento
(51) 3222-3103
r Otto Niemeyer, 1313, Tristeza
Porto Alegre, Rio Grande do Sul

Dados Divulgados por
DuoTech Tecnologia
(54) 3045-1488
Av. Sete de Setembro, 55 Sala 05
Passo Fundo, Rio Grande do Sul
 
Dados Divulgados por

Estudando a ferramenta Sharepoint Services

Resumo:

Este trabalho é de grande importância para os alunos, professores e profissionais da área de informática que fazem bom uso da Tecnologia da Informação, pois os mesmos poderão entender como funcionam as particularidades da ferramenta Microsoft Windows Sharepoint Services dentro de uma organização. O mesmo está em evidência, se expandindo a cada dia nas mais variadas empresas. Portanto, quem pretende utilizar esta ferramenta deverá conhecer bem sobre este sistema, ser organizado e saber que seu comércio será ampliado, tendo dimensões infinitas, e que deverá atender ao consumidor de forma mais ampla, pois o mercado atual é exigente.

A intenção desta pesquisa não é de abranger detalhadamente as questões envolvidas no âmbito desta ferramenta, mas apenas ter uma noção dos pontos chaves do tema, com base em autores conceituados e com grandes conhecimentos na área. O principal objetivo deste artigo é estudar e aprender um pouco mais a respeito da viabilidade desta ferramenta dentro das organizações enfocando a 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. Qualquer aprofundamento deverá ser buscado na bibliografia sugerida no final deste trabalho.

Palavras - Chave: Windows Sharepoint Services – Software da Microsoft integrado com aplicativos de servidor fáceis de usar, que aumentam a eficiência da organização.

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.

A maioria das situações decorrentes do compartilhamento de documentos que são freqüentemente atualizados acaba terminando em uma grande confusão como a duplicação de informação, perda de dados, alteracoes indevidas e etc.

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

» Suporte para templates de site e listas – Os usuários podem salvar listas como templates e reutilizá-los ou distribuí-los para outros sites.

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

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

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.

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.

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.

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.

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

» 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 podem estar em diferentes máquinas e compartilhar a mesma database e disponibilizando o mesmo conteúdo para criar uma intranet e uma extranet.

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

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

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:

A 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 e fiz por acreditar que realmente 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.

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

Vanessa G. Moreira

Empresa: VGM.net Design & Informática
Email:vgmnet@vgmnet.com .
Website:www.vgmnet.com.br
Hobbies: Web Designer
Sobre o Autor: Graduada e Pós-Graduada em Tecnologia da Informação.

Clique aqui para ler este artigo na Artigonal.Com