Overview 

 Se você já ouviu falar da nova arquitetura do SharePoint 2010, já deve então saber que nosso querido SSP (Shared Services Provider) foi extinto. O SharePoint através do SSP oferece serviços de Pesquisa, Perfis de Usuários, Audiência, My Sites, Excel Services, Business Data Catalog, entre outros, porém devido a sua estrutura, os administradores encontravam grandes dificuldades e pouca flexibilidade ao trabalhar com eles. Na nova versão do SharePoint, o SharePoint 2010 implantou uma nova estrutura de trabalho, o chamado Service Application. 

Solução

A nova estrutura de Service Application do SharePoint 2010 trabalha de forma multi-tenant, ou seja, alguns serviços, podem ser configurados de maneira a fazer com que cada coleção de site ache que está trabalhando de forma dedicada, quando de fato, estão trabalhando de forma compartilhada sem perceber.

Os Service Applications parecem simples da primeira vez que instalamos o SharePoint, iniciá-los parece a tarefa mais fácil do mundo, mas entre iniciar um serviço e fazer funcionar da forma que necessita é uma tarefa um pouco mais complexa. Toda esta estrutura foi mudada, sendo assim, todos os serviços individuais podem estar no seu próprio Service Application. A baixo, os Serviços a tabela lista os serviços disponíveis para cada produto:

SharePoint Foundation Service Applications
  Tem Banco de Dados? Cross-Farm?
Business Data Connectivity Sim Sim
Usage and Health Data Collection Sim Não
Web Analytics Não Sim
Microsoft SharePoint Foundation Subscription Settings Service Sim Não

 

SharePoint Server 2010 Standard Service Applications
  Tem Banco de Dados? Cross-Farm?
Managed Metadata Service Sim Sim
Search Sim Sim
Secure Store Service Sim Sim
State Service Sim Não
User Profile Service Sim Não

 

SharePoint Server 2010 Enterprise Service Applications
  Tem Banco de Dados Cross-Farm?
Access Service Não Não
Excel Service Não Não
Visio Graphic Service Não Não
Word Automation Services Não Não
PerformancePoint Service Não Não

Com esta nova estrutura ganhamos mais flexibilidade, e podemos trabalhar de forma isolada sem precisar ter redundância nos serviços. Fazendo uma analogia, podemos entender da seguinte forma: imagine que fomos a um restaurante em que o jantar era prato feito, então você pede o prato XYZ. Seu acompanhante adorou o seu pedido, mas ele só queria comer um dos ingredientes que havia no seu prato e no caso ele precisa pedir o “prato feito” pois é o que a casa oferece. Neste caso, ele acabou recebendo todos os ingredientes, mas comerá apenas aquilo que lhe interessa, e o resto será um grande desperdício e o gasto ($$) maior, pois ele pagou e não consumiu. Este era o modelo utilizado pelo MOSS (Microsoft Office SharePoint Server) na sua versão 2007. Imagine que agora então, você tem a opção do “prato feito – Default” , ou se desejar, você quer comer apenas um dos ingredientes deste prato, você pode pedir ele isolado.

Fundamentos da estrutura do Service Application

Para conseguir ser escalavél e flexível, os Service Applications trabalham com diversas associações e conexões com os Web Applications. As Web Applications se conectam a um Grupo de Serviços que por sua vez são construídos por uma ou mais conexões de Service Applications, e este determinado serviço podem possuir ou não uma base de dados para armazenamento.

Esta arquitetura e conceito é representada da seguinte maneira:

 

Figura 1: Estrutura do Service Application

O Service Application Group(Proxy groups ou application proxy groups) são associados ao seu Web Application assim que você os cria. Caso você tenha executado o assistente de configuração (Wizard) para configurar o SharePoint, ele deverá ter configurado os serviços automaticamente e os incluído no grupo padrão, você então pode utilizar este grupo padrão na criação da sua Web Application, não podendo assim alterar a associação aos serviços (como mostrado na imagem abaixo), ou escolher a opção “custom” para customizar os serviços de aplicação que deseja utilizar.

 

Figura 2: Configuração do Service Application Connections

Pela Central Administration, em Service Applications, você também tem a opção de criar manualmente um novo serviço no Link Manage Service Applications. Quando você cria um novo serviço, você pode optar por incluí-lo no grupo Default, selecionando a opção “Add to default proxy list”. O grupo Default é configurado por padrão lá no início quando comentei da inicialização dos serviços utilizando o Wizard, mas você também pode criar novos grupos. Estes grupos são utilizados para associar serviços e disponibilizá-los para um determinado Web Application.

 Nota: Quando você utilizar a opção “Custom”, lembre-se de que será determinado apenas Serviços específicos para esta Web Application que estará criando, e não é a mesma coisa que um Proxy Group, e não será reutilizável. Proxy Group e Custom são termos distintos.
 

 Nota: Se você deseja criar Proxy Groups, você realizar esta tarefa com o Management Shell, utilizando o comando New-SPServiceApplicationProxyGroup.

Desenvolvi um artigo ilustrando como cria Proxy Groups utilizando PowerShell, para acessá-lo como referência é só clicar no link: Criando Proxy Groups com Windows PowerShell no SharePoint 2010 .

Caso você queira ver um resumo de como seu SharePoint ficou configurado depois da utilização de Application Proxy Group, é só acessar a Central Administration, na sessão Service Application e clicar em Configure service application associations, como mostra na imagem:

Figura 3: Resumo das Associações dos Serviços

Clicando no link “Default” ou “Custom, você pode alterar ainda mais as associações a estes grupos, podendo assim habilitar ou desabilitar um serviço específico para uma determinada Web Application.

A Service Application Connection representa a conexão entre os Serviços e a Aplicação Web.  Em outras palavras, a Web Application está associada então há um Service Application Group, que lista todos os serviços que ela pode utilizar. Se você der uma olhada no IIS, verá que tem um site nomeado como SharePoint Web Services, se você expandir este site, irá encontrar as conexões do Service Application e seus Web Services. Caso você tenha configurado o SharePoint utilizando o Wizard, irá aparecer um nome extenso com 32 caracteres.

Por sua vez, então vem o Service Application, que é o responsável por providenciar o serviço que você precisa uma vez que você tem permissão.

Nem todos os serviços precisam necessariamente ter um armazenamento em uma base de dados, o que é representado pelo Service Application Database. Alguns exemplos que podemos citar é o Excel Services, que precisa apenas exibir os dados armazenados em outro lugar, ele não armazena nenhum dado. Quando o Serviço trabalha com um banco de dados, assim como o Managed Metadata Service e Search, estas bases trabalham de forma  exclusiva para cada aplicativo.

Os Service Application Services são os serviços que encontramos na Central Administration, em Application Management >> Service Applications em  Manage services on Server, aonde podemos configurar o serviço ou parar o seu funcionamento, ou até configurar o balanceamento de carga para determinado serviço.

 

Ligação entre as Farms (Cross Farms)

Alguns Service Applications são capazes de serem publicados e utilizados em diferentes Farms. Agora para publicar ou utilizar Service Applications entre as Farms, é necessário estabelecer uma relação de confiança, aonde são criados e configurados certificados entre as Farms. Uma vez que o Service Application é publicado, basta se conectar ao serviço publicado pela sua URL.

Nota: Para otimizar o desempenho, a melhor prática é sempre manter todos os seus Service Applications em um único Pool de Aplicativos, pois os Pools de Aplicativos utiliza muito recurso de Memória, sendo assim, quanto mais pools distintos vocês tiverem, mais ele vai consumir do seu Servidor.

 
Anúncios