Composição de Serviços - Parte I: Coordenação

Uma das principais características de um Serviço, que deve ser perseguida desde o momento da especificação, é a sua capacidade de se compor com outros Serviços para a elaboração de um novo de mais alto nível de abstração. A figura abaixo ilustra esta capacidade.


Os próximos posts têm como objetivo apresentar algumas das opções de implementações para a Composição de Serviços.

Usualmente, a tecnologia de orquestração (geralmente associada a BPM) é a primeira a ser lembrada. Contudo, dependendo dos requerimentos, outras opções devem ser consideradas:

• Coordenação ("Coordination")
• Orquestração ("Orchestration", como mencionado acima) e Coreografia ("Choreography". Não, ela não é sinônimo de Orquestração como frequentemente é encontrado em diversos materiais).

Neste post descrevo de forma introdutória o primeiro item. O segundo fica para a parte II.

Coordenação
Este modelo, primeiramente, define a figura do Coordenador. O Serviço é o responsável pela execução dos Serviços Compostos, também chamados de Participantes. Usualmente, é ele que é exposto aos Serviços Consumidores, abstraindo para estes a existência dos seus Serviços Compostos. Como podemos imaginar, os Serviços Compostos tipicamente são independentes entre si, promovendo mais uma vez o conceito de baixo acoplamento.

A figura abaixo ilusta a situação. Um exemplo clássico para uma composição de serviços é aquele sobre um Agente de Viagens. O Agente cumpria o papel de Serviço Coordenador, enquanto uma Companhia Aérea, um Hotel e uma Locadora de Carros forneceriam os Serviços Participantes.


Há alguns padrões para Web Services que definem frameworks para Coordenação de Serviços. Dentre eles destaco:

• WS-Transactions: família de especificações da OASIS que compreende:
• WS-BusinessActivity (WS-BA)
• WS-AtomicTransaction (WS-AT)
• WS-Coordination (WS-C): framework genérico que suporta WS-AT e WS-BA

Segundo o WS-Transactions, todos os Serviços pertencentes à composição dependem de um runtime ou framework específico chamado de Coordinator (não confundir com o Serviço Coordenador descrito acima). O Coordinator expõe dois serviços: Activation Service e Registration Service. A figura abaixo ilustra os Serviços da Coordenação e o Coordinator. O Coordinator é tipicamente implementado por engenhos como um Servidor de Aplicação.

O fluxo entre os Serviços da Coordenação e o Coordinator seria mais ou menos assim:

1. O Serviço Coordenador (no nosso exemplo, a Agência de Viagens) faz uma requisição ao Activation Service do Coordinator.
2. O Coordinator inicia uma nova coordenação e responde ao Serviço Coordenador com um contexto. O contexto possui informações diversas. Dentre as mais importantes, a identificação da coordenação e o endereço do próprio Coordinator.
3. O Serviço Coordenador faz uma chamada ao Registration Service do Coordinator indicando que irá conduzir a coordenação.
4. O Serviço Coordenador invoca o primeiro Serviço Participante (por exemplo, a Companhia Aérea) passando as informações de contexto recebidas do Coordinator. Tais informações são inseridas no cabeçalho SOAP da mensagem
5. O Serviço Participante faz uma chamada ao Registration Service para registrar-se como integrante da coordenação.
• Os passos 4 e 5 são realizados para os demais Serviços Participantes (no nosso exemplo, o Hotel e a Locadora de Carros).
6. Os Serviços Participantes finalizam o seu processamento e informam o Coordinator. Note que os Serviços Participantes são totalmente independentes entre si e, portanto, não há uma ordem definida para o término e consequente resposta ao Coordinator.
7. O Coordinator informa ao Serviço Coordenador sobre o finalização dos Serviços Participantes.
8. O Serviço Coordenador envia ao Coordinator uma requisição para finalizar a coordenação.
9. O Coordinator envia uma mensagem para finalização de coordenação para cada Serviço Participante.

Todo o processo fica mais interessantes em situações de exceção: suponha que o cliente da Agência de Viagens (representado pelo Serviço Consumidor) não fique satisfeito com as reservas realizadas. Neste caso o Serviço Coordenador envia uma requisição de compensação ao Coordinator. Este, por sua vez, requisita que o Serviço Participante relativo desfaça a reserva feita.

Os passos descritos acima são chamados, dentro da família WS-Transactions, de Business Activity, definido pelo padrão WS-BusinessActivity (WS-BA). O WS-Transactions define também o padrão WS-AtomicTransaction (WS-AT). A diferença é clara: por um lado o WS-AT define o conceito de Transação Atômica em um cenário de "tudo-ou-nada" entre os Serviços Participantes. Por outro, o WS-BA define o que chamamos de Long-Running Transactions. Eu fiz uma discussão sobre este tema em um post anterior. O exemplo foi dado justamente porque acredito que tenha mais aderência em uma Arquitetura Orientada a Serviços.

A figura ilustra uma situação onde temos somente um Coordinator interagindo com todos os Serviços. Isso quase sempre não é factível: em um ambiente absolutamente distribuído usualmente temos a presença de diversos Coordinators, um em cada ambiente onde os Serviços estão rodando. Deste modo, os Coordinators trocam mensagens a respeito das atividades realizadas pelos Serviços em relação à coordenação (por exemplo, os registros realizados pelos Serviços Participantes). O primeiro Coordinator (responsável pela interação com o Serviço Coordenador) é chamado de root, enquanto os demais são chamados de proxy.

Há inúmeras referências a respeito de Composicão de Serviços, mais precisamente, Coordenação (e Transações). Gostaria de destacar:

• Service-Oriented Architecture, Concepts, Technology and Design de Thomas Erl, capítulo 6.
• Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More de Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey e Donald F. Ferguson, capítulo 11.
• Understanding SOA with Web Services de Eric Newcomer e Greg Lomow, capítulo 10.

SOA e IAM - Segurança em Web Services

Quando há o uso de Web Services para a implementação de uma Arquitetura de Serviços, os padrões WS-Security têm uma importância indiscutível. São eles que permitirão que o processamento de mensagens SOAP seja feito de modo seguro.

Este "post" tem como objetivo ilustrar um pouco o uso deste padrões. Entretanto, em primeiro lugar, gostaria de descrever o que tipicamente acontece em um ambiente sem Web Services. Acho que podemos encontrar muitas analogias importantes depois.


Web Single Sign-On (SSO)
Comentei no "post" passado sobre a típica arquitetura de segurança de aplicações usando um servidor específico de Autenticação e Autorização. Abaixo uma imagem ligeiramente diferente daquela que utilizei:

A fatoração entre as lógicas de Aplicação (apresentação, negócio, acesso a dados, etc) e de Autenticação e Autorização é uma excelente idéia em qualquer lugar. Em um ambiente Web, com o usuário manipulando um "browser", não é diferente.

Antes de descrever o fluxo de processamento, é importante notar que a inserção de um Servidor de Autenticação e Autorização na arquitetura de software, apesar de trazer inúmeras vantagens, implica em um evento intrusivo no ambiente:

• O primeiro momento de "intrusão" no ambiente é a própria presença deste servidor.
• As aplicações são protegidas por um componente de software posicionado entre o browser e elas próprias. Tal componente é chamado de agente e é tipicamente localizado em um Servidor Web ("Web Server"). Este é o segundo momento de "intrusão" no ambiente. As responsabilidades do agente são (1) verificar se o usuário já foi autenticado e (2) autorizar o uso, ou controlar o acesso a um recurso da aplicação pelo usuário.
• O terceiro momento de "intrusão" no ambiente ocorre pela necessidade de alteração da aplicação, posto que as lógicas de autenticação e autorização foram implementadas pela própria.

No momento da autenticação do usuário o que acontece é mais ou menos isso:

• O usuário requisita a execução de uma aplicação através de uma URL bem conhecida.
• Um sistema de proteção da aplicação, ou o agente mencionado acima, verifica se o usuário já foi autenticado. Esse passo consiste em analisar a presença de um token de autenticação na requisicão HTTP enviada pelo browser. Caso o token não esteja presente, significa que o usuário nunca foi autenticado e portanto deve ser redirecionado ao Servidor de Autenticação e Autorização (o redirecionamento ocorre pela resposta 302 à requisição HTTP).
• O usuário é submetido ao processo de autenticação previamente estabelecido. Novamente, tal processo é tão complexo quanto se queira, envolvendo diversos tipos de credenciais, fatores de autenticação, etc.
• O Servidor de Autenticação e Autorização faz uso das bases de dados existentes (LDAP, SGBD, etc) para autenticar o usuário.
• Caso o usuário tenha sido autenticado com sucesso, o Servidor de Autenticação (1) cria um token de autenticacão e (2) redireciona novamente o usuário à aplicação. A requisição é a mesma daquela original emitida pelo usuário com a diferença que desta vez há a presença do token de autenticação.
• Como o token, desta vez, está presente na requisição HTTP, o agente permite que a mesma seja enviada à aplicação.
• A aplicação inicia o tratamento da requisição. Note que não ocorrência de autenticação por parte da mesma.

O "Single Sign-On" é atingido quando todas as aplicações estiverem protegidas pelo agente. Ou seja, o token de autenticação é reconhecido pelo agente e transferido a quaisquer aplicações. Deste modo, o usuário é requisitado para apresentar suas credenciais somente uma vez. Diria que uma arquitetura como essa traz vantagens bem mais valiosas do que o próprio "Single Sign-On". Mais uma vez, a flexibidade dos processos de autenticação, juntamente com a sua separação em relação aos processos de negócios implementados pelas aplicações são os seus maiores benefícios.






Basic Web Services
Os fundamentos de Web Services são bastante simples: há um Provedor de Serviços ("Service Provider") e um Consumidor ("Service Consumer"). Mensagens SOAP trafegam entre os dois elementos para requisição de informações e respectiva resposta. A figura abaixo exibe o que chamamos de "Basic Web Services".


Contudo há pelo menos duas questões que inicialmente devemos considerar em relação à segurança: (1) não há qualquer referência ao usuário responsável pela requisição de um Web Service e (2) as mensagens SOAP, muito provavelmente, atravessarão nós intermediários até o seu destino. Cada nó intermediário poderá ser um sistema específico responsável por um tipo de processamento a ser imprimido na mensagem SOAP até chegar no provedor do serviço.
.

O uso de tecnologias como SSL ("Secure Sockets Layer"), apesar de necessário, garante somente a segurança das informações entre nós. Outras tecnologias devem ser adicionadas para endereçar não somente os dois itens acima mas outros que também podem surgir.

Web Services Security
Entra o padrão Web Services Security (WS-Security ou WSS), conduzido pelo OASIS. Trata-se de uma extensão que permite a inserção de mecanismos baseados em tokens em mensagens SOAP.

A figura abaixo exibe a estrutura de uma mensagem SOAP sem o padrão WSS. Importante notar a presença de um "header" na mensagem. Este "header" é usado para descrever características da mensagem. O WSS, então, define como inserir informações de tokens de segurança no "header" da mensagem. Isso é ilustrado na mesma figura.


Note que o WSS permite o uso de diversos tipos de tokens como certificados digitais X.509, tickets Kerberos, etc. O uso mais comum atualmente para este token é o padrão SAML, também do OASIS.

STS (Security Token Service)
Postas as novas variáveis, uma pergunta aparece: qual componente da arquitetura é o responsável pela emissão de tokens SAML? Novamente aparece a figura do STS. Este servidor cumpre um papel semelhante àquele desempenhado pelo Servidor de Autenticação e Autorização em ambiente Web Single Sign-On explorado anteriormente. De fato, tipicamente, temos à disposição no mercado produtos que podem ser usados em ambas as situações (Web SSO e STS). A figura abaixo ilustra a situação.

Além do STS, a figura exibe o padrão WS-Trust também do OASIS. Esta padrão estende o WSS para que um elemento da cadeia de mensagens Web Services possa requisitar a emissão, renovação, validação, etc de tokens de segurança (SAML, mais uma vez, é um padrão disso).
Em resumo, este framework percorre o seguinte fluxo:

• O consumidor faz uma requisição WS-Trust para o STS para autenticação informando credenciais.
• O STS verifica as credenciais nas bases de dados de usuários existentes.
• Caso o usuário seja autenticado, um token SAML é criado.
• Os tokens SAML são usados por WS-Security para a sua inclusão no cabeçalho da mensagem SOAP.
• Todos os nós seguintes, incluindo o destino da mensagens têm acesso à mensagem, e consequentemente ao token SAML.

Como conclusão: em um ambiente corporativo de Web Services para a construção de uma Arquitetura Orientada a Serviços, o uso dos padrões WS-Security, WS-Trust, SAML, além do próprio STS é absolutamente obrigatório. Infelizmente, estes elementos não recebem a atenção necessária em um projeto de implementação SOA. Como se vê, esta questão deve ser encarada com seriedade e diria que deveria ser conduzida como mais um subprojeto dentro do espectro amplo de SOA.

Segurança SOA - Arquitetura de Serviços e Gerenciamento de Identidade e Acesso II

A disciplina IAM ("Identity and Access Management" - Gerenciamento de Identidade e Acesso) pode ser dividida em diversos temas. Para simplificar, em uma primeira classificação, teríamos as questões funcionais separadas em dois grupos: (1) gestão de usuários e (2) garantia ou execução ("enforcement") das políticas descritas a tempo de gestão.

A figura abaixo ilustra este agrupamento:

Toda a estória começa aqui: em um ambiente corporativo, é natural que tenhamos uma infinidades de bancos de dados que armazenam as contas de usuários de aplicações e sistemas. Dentre eles:

• Sistemas Operacionais
• Servidores de Diretório: LDAP, NIS, X.500, Microsoft Active Directory, etc
• Gerenciadores de Bancos de Dados
• Sistemas de Autenticação: RADIUS, Kerberos, RACF, TopSecret, etc.
• Pacotes de Aplicações: ERP, CRM, SCM, etc
• Bancos de Dados proprietários de aplicações caseiras
• etc, etc, etc.

Gestão de Usuários
Nem todo usuário deve existir em todo sistema ou aplicação. Os processos de Gestão de Usuários (basicamente Aprovisionamento e Gerenciamento de Perfis) preocupam-se em definir quais usuários devem ser inseridos em quais sistemas e bancos de dados de usuários. Chamamos de Ciclo de Vida dos Usuários as operações realizadas desde a criação de um usuário, eventuais alterações, até a sua eliminação dos sistemas.

Veja que os processos de Gestão de Usuários deve se relacionar com diversas categorias de bases de dados e sistemas, localizados em diferentes níveis de abstração desde sistemas operacionais, pacotes de mercado, bancos de dados de aplicações customizadas.

Autenticação e Autorização de Usuários
Definições sucintas:

• Autenticação de Usuário: processo de reconhecimento de um usuário por um sistema. Uma credencial é fornecida pelo usuário para a sua autenticação: par usuário/senha, certificado digital, "tokens" de senhas, dado biométrico, etc.

• Autorização de Usuário: processo de controle de acesso a recursos protegidos. Recursos são quaisquer elementos que um usuário ou aplicação deseja manipular: tabelas de banco de dados, URLs, arquivos, impressoras, etc. O processo de autorização ocorrre após a autenticação do usuário.

Estes processos basicamente consomem as informações inseridas e manipuladas pelos processos de Gestão para implementar uma inteligência específica e necessária que não seria possível de ser realizada por uma única base de dados de usuários. Dentro deste contexto, é possível então que tenhamos autenticação baseada em contexto (por exemplo, considerando data e hora, endereço IP, etc), autenticação multi-fator, etc.

As aplicações basicamente resolvem estas questões de duas formas:

• As lógicas de AuthN e AuthZ fazem parte da própria aplicação: neste caso a aplicação faz um contato com alguma base de dados de usuário como LDAP, X.500, MS Active Directory, etc.

• As lógicas de AuthN e AuthZ são implementadas por servidores específicos. Neste caso, as aplicações enviam requisições a estes servidores e o contato com as bases de dados é feito por estes servidores.

Distribuição e Consolidação de Processos

Outra observação importante é que os processos de Gestão de Usuários (Aprovisionamento, Gerenciamento de Perfis, etc) tendem a ser consolidados enquanto os processos de Autenticação e Autorização são inerentemente distribuídos. Em uma arquitetura de software corporativa é absolutamente natural que tenhamos vários pontos de autenticação e autorização de usuários. A figura abaixo ilustra esta questão. Veja que há domínios de aplicações que fazem uso, para efeito de Autenticação e Autorização de Usuários de um infraestrutura própria. Aplicações Mainframe, por exemplo, provavelmente apoiam-se em softwares como RACF ou TopSecret.

Em SOA, é bastante comum o uso de servidores STS ("Secure Token Service") também representados na figura acima. Um STS é responsável pela autenticação dos usuários que consumirão os serviços disponíveis. Como qualquer Servidor de Autenticação, o STS permite que vários tipos de credenciais sejam fornecidas. Caso a autenticação tenha ocorrido com sucesso, o STS emite um "token" de autenticação que deverá ser "carregado" pelo consumidor de serviço em interações seguintes.

A figura abaixo ilustra uma composição básica com a Arquitetura de Serviços, STS e Intermediador de Serviços.

A figura aponta a interação entre o Intermediador de Serviços (responsável pela Governança em tempo de execução ("run time")) e o STS. Na verdade quaisquer outros pontos da arquitetura podem eventualmente se relacionar com o STS. Por exemplo, um dos consumidores de serviços pode vir a ser um engenho BPM ("Business Process Management"). O contato com o STS pelo BPM pode ocorrer para que o "token" seja criado no momento de uso de um Processo de Negócio definido pelo BPM. O "token", posteriormente, é transferido para os demais elementos da arquitetura como o próprio intermediador, Serviço de Negócio, etc.

O "post" seguinte tratará com mais detalhes o componente STS e os padrões de mercado que normalmente são implementados por ele.

Segurança SOA - Arquitetura de Serviços e Gerenciamento de Identidade e Acesso

Como disse no "post anterior", o assunto Segurança em uma Arquitetura de Serviços deve ser tratada de modo amplo. Alguns aspectos muito importantes são aqueles tipicamente resolvidos por aquilo que o mercado qualifica como Gerenciamento de Identidade e Acesso (ou, em inglês, IAM - "Identity Access and Management").

Na verdade, aqui, aqui e aqui, eu já havia discutido temas relacionados a IAM e SOA. Os "posts" seguintes têm como objetivo descrever um pouco melhor a relação entre esses dois assuntos.

Desde o início, gostaria de salientar que ambos os projetos, SOA e IAM, deveriam ser conduzidos separadamente com um horizonte de sinergia entre ambos. Idealmente, o projeto SOA seria responsável pela implementação de serviços de negócio enquanto o projeto IAM ficaria com a oferta de serviços de segurança.

Resumindo:

• Projetos IAM possuem vida própria e oferecem um conjunto de serviços de segurança a serem consumidos por quaiquer classes de sistemas, SOA ou não.
• Projetos SOA também possuem vida própria e são mais um dos potenciais consumidores das funcionalidades implementadas pelo sistema IAM.

Dentro do espectro de IAM, um bom início é a arquitetura de referência definida pelo Burton Group. A imagem abaixo está em diversos documentos produzidos por ele, incluindo referências externas como esta palestra realizada em Outubro 2009.


Como se vê o espectro funcional é bastante amplo envolvendo diversos temas como:

• Aprovisionamento de Usuários
• Autenticação e Autorização de Usuários
• Sincronismo, replicação e/ou virtualização de dados de Usuários
• Auditoria dos processos realizados
• Definição de Federação

As questões pertinentes têm se ampliado com outros temas como

• Gerenciamento de Perfis de Usuários ("Enterprise Role Management")
• "Compliance" de Identidades
• Gerenciamento de Granularidade Fina dos Atributos de Usuários ("Entitlement Management")

Nos próximos "posts" abordarei com mais detalhes a implicação destes temas em um contexto de Arquitetura de Serviços.

Segurança SOA

SOA não é sinônimo de Web Services. Portanto quando falamos de Segurança SOA, não faz sentido reduzirmos o assunto aos padrões pertinentes a segurança de Web Services como Web Services Security, WS-Trust, SAML, etc, etc, etc.

Mais uma vez é preciso que tenhamos uma visão mais ampla sobre o tema, envolvendo todos os componentes da arquitetura, e não somente o ESB ou motor BPEL ou qualquer outro software específico isoladamente.

Com este objetivo, um modelo de segurança SOA foi elaborado aqui na Sun, há mais ou menos 3 anos. O modelo parte de conceitos bem conhecidos pertinentes ao tema e é basicamente definido em uma matriz de 7 aspectos por 6 facetas específicas de segurança. Por outro lado, o modelo é extensível para permitir a adição de novos mecanismos de segurança, novos aspectos, padrões, especificações, etc.

Aspectos de Segurança

1. Autenticação: Identificação de um sujeito (humano, processo, componente, sistema externo).
2. Autorização: Avaliação de permissão de recursos por parte da entidade. Acontece, usualmente, após a autenticação.
3. Integridade: Garantia de não modificação de informações durante a transferência do seu originador. Tipicamente atingida por assinaturas digitais.
4. Confidencialidade: Garantia que informações não estão disponíveis para sujeitos não autorizados. Tipicamente atingida com criptografia.
5. Responsabilidade (“Accountability”): Associação histórica de eventos que ocorreram com sujeitos.
6. Aprovisionamento de Usuários: Manipulação de bases de dados para inclusão, alteração e remoção de usuários.
7. Políticas de Segurança: Conjunto de regras de negócio que estabelecem o comportamento de um sistema de computação. Podem ser definidas em quaisquer participantes SOA.

Facetas de Segurança

1. Transporte: Proteção de informação durante o trânsito entre duas partes. Fácil implementação através de SSL ou TLS.
2. Mensagens: Proteção de requisições individuais quando são roteadas entre os consumidores, intermediários e provedores de serviços. Em comunicação baseada em SOAP é definida no padrão emergente WS-Security.
3. Aplicação: Mecanismos de segurança da lógica da aplicação. Por exemplo: um diretor pode aprovar ordens de compra até $50K e valores superiores necessitam de aprovação de algum VP.
4. Ativos (Dados): Proteção de quaisquer ativos usados e/ou encapsulados em um serviço. O mais comum é a proteção de dados mas outros tipos de ativos como dispositivos devem ser considerados.
5. Conhecimento: Proteção de informações que descrevem serviços, aplicações e outros ativos sensíveis. Exemplos são: WSDLs e schemas, repositório de políticas, etc.
6. Controle: Inclui todos os mecanismos de segurança que existem para a proteção da solução de governança propriamente dita. Dentre eles estão: violação dos dados de governança, “bypassing workflows”, ataques à infra-estrutura de governança e gerenciamento de serviços.

A idéia é que, de posse destes aspectos e facetas, construamos uma matriz onde possamos identificar o nível de aderência entre estes dois grupos. A matriz abaixo é um exemplo disso:


Os símbolos descrevem o nível de suporte de um determinado aspecto em relação a uma faceta. A tabela abaixo indica o significado de cada símbolo.
Fornece: solução provê esta funcionalidade nativamente ou com mínimo suporte dos consumidores e provedores de serviços.
Suporta: solução facilita a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Permite: solução não atrapalha a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Não fornece: esta funcionalidade está fora do escopo de atuação da solução.

Então, como exemplo: a matriz acima indica que o ambiente usado para a implementação de SOA fornece e implementa o aspecto de autenticacão na faceta de Transporte mas não na de Conhecimento ("Knowledge"). Claro que o ideal é que todas os aspectos sejam endereçados corretamente em todas as facetas do ambiente.

Como conclusão temos que as questões envolvendo Segurança SOA devem ser pensadas de forma mais ampla do que aquela envolvendo as mensagens trafegando por entre os componentes da arquitetura. Melhor seria que o projeto de Segurança SOA fosse encarado como subprojeto de Governança. Em outras palavras, Segurança SOA é melhor entendida como uma dos diversas dimensões ou um caso particular de Governança SOA.

Sobre as decisões para construir uma Arquitetura Orientada a Serviços

Eu comentei em um "post" antigo sobre as razões pelas quais uma Arquitetura Orientada a Serviços deve (ou deveria) ser construída. Gostaria de voltar ao tema.

Fundamentalmente, a decisão para criar uma Arquitetura Orientada a Serviços não deveria ser de responsabilidade do Departamento de Tecnologia de qualquer empresa. Esta decisão deveria necessariamente ser de Áreas de Negócio da companhia.

Esta forma de tomada de decisão não é absolutamente nova. Serve para quaisquer tecnologias desde sempre. Ou deveria servir. Exemplos são inúmeros: bancos centenários sobreviveram durante muito tempo sem o uso de qualquer tecnologia digital. A decisão sobre a introdução de sistemas de computadores em instituições financeiras é dramaticamente mais nova do que o próprio banco.

Neste passado remoto, a substituição de tarefas manuais por sistemas de computadores tinha como objetivo atingir resultados que não são muito diferentes dos atuais: agilidade nos processos, melhor atendimento ao cliente, redução de custos, inovação em produtos, etc, etc, etc. Mais uma vez, nesta época, as decisões não foram tomadas baseadas nas belezas tecnológicas existentes ou por diletantismo mas sim, em reais necessidades de negócio.

Atualmente, é assim também com SOA. Não somente com SOA mas com toda e qualquer tecnologia que se possa discutir.

Contudo, por algum motivo, essa lógica (necessidades de negócio fazendo uso de tecnologia) foi se invertendo: tecnologias são empregadas sem que haja uma real consciência sobre o seu benefício. Não precisamos pensar muito para concluir que tal lógica não é sustentável.

Assim, acredito que SOA não pode ser um fim em si mesmo. Tem que ser um meio para resolução de problemas reais de negócio. Então a lógica original deveria produzir alguma coisa como:

• Forças de mercado e concorrência geram pressão nas empresas por melhores resultados.
• Empresas acreditam que recursos tecnológicos podem ajudá-las a melhorar o seu desempenho, distinguirem-se da concorrência, etc, etc, etc.
• Dentre as diversas opções tecnológicas disponíveis, SOA endereça exatamente estes pontos.
• Áreas de negócio invocam e pressionam a área de tecnologia para entregar tal requerimento.

Dentre os vários motivos pelos quais SOA ainda não teve a adoção pelas empresas, gostaria de citar dois:

• As forças que regem o mercado e a concorrência entre as empresas não tiveram ainda intensidade suficiente para que estas buscassem coisas como SOA.
• A inabilidade de "vender" o que é realment SOA para as áreas de negócio e tomadores de decisão das empresas.

Acho que, quando as pressões de mercado forem de tal ordem, as empresas buscarão soluções como SOA para os seus problemas. E então, teremos investimentos em equipes específicas com conhecimento apropriado. Portanto, reafirmo, enquanto SOA for tratado somente com os seus atributos tecnológicos, com o trato de APIs, produtos, etc, não será adotada plenamente pelas empresas.

Governança SOA e Intermediação de Serviços

No último "post" sobre Governança SOA, eu elaborei um exemplo com duas versões de um mesmo Serviço. Cada versão seria invocada de acordo com condições estabelecidas pelo "Governance Officer" como perfil do consumidor do serviço, hora de requisição do serviço, ou qualquer outra particularidade.
Toda essa mecânica não acontece por mágica: é preciso que tenhamos um componente novo para (1) permitir que as condições sejam descritas e (2) aplicar tais condições no momento da requisição dos serviços.

Esse componente novo é chamado e implementado de diversar formas: Service Gateway, Service Proxy, SOA Governance Gateway, XML Gateway. Eu gosto do termo "Intermediador de Serviços". Usualmente implementado como software, há versões também disponíveis como "appliances".
Uma figura ilustrativa do Intermediador de Serviços pode ajudar:


O Intermediador de Serviços, então, posta-se entre os Consumidores e os Provedores de Serviços. Toda requisição de serviço deve, necessariamente, atravessar o Intermediador.

Alguns comentários:

• O "Governance Officer" estabelece o que chamamos de Aspectos de um serviço, ou características não-funcionais, que são passíveis de configuração para atingir um determinado objetivo.
• Os Aspectos podem ser relativos a questões como Segurança, Performance, Disponibilidade, etc.
• Todas as descrições dos Serviços, juntamente com os Aspectos, ficam armazenados em um Repositório de Serviços, normalmente o mesmo que possui os WSDL usados a tempo de implementação dos serviços.
• Note que a tecnologia empregada para a implementação dos Consumidores e Provedores de Serviços é totalmente irrelavante para o "Governance Officer" pois é abstraída pelo Intermediador. Note também que o BPM, nesta perspectiva, é novamente considerado apenas como mais um Consumidor de Serviços.
• Claro que a alteração de um Aspecto pode ser dependente da infraestrutura onde os Serviços foram implementados. Por exemplo: caso a requisição de um serviço tenha um acréscimo, de nada adiantaria o "Governance Officer" configurar novas instâncias deste serviço (para melhor atender a demanda de requisições) se a infraestrutura de Serviços não estiver preparada para isso.

Diversos benefícios podem ser observados a partir deste modelo:

• O Intermediador de Serviços está fracamente acoplado em relação aos Consummidores e aos próprios Provedores de Serviços.
• Por esta razão o Intermediador é independente dos serviços, do contâiner onde os serviços estão instalados e da própria tecnologia que foi empregada para a implementação dos mesmos.
• A incorporação de novas tecnologias e novos padrões se daria de forma mais barata.
• A consolidação das requisições de serviços permite que tenhamos um controle mais apurado sobre as mesmas e, deste modo, processos de auditoria e até mesmo cobrança para casos onde os serviços são usados externamentes, são dramaticamente melhorados.

Conclusão: a dimensão de Governança é ampla e complexa. Em SOA, não seria diferente. Há uma coleção específica de questões, cobrindo todo o ciclo de vida dos serviços na arquitetura que merecem uma atenção mais do que especial e não deve ser encarada como "coadjuvante".

Há pouca literatura formal ainda sobre o assunto. Um excelente começo é "SOA Governance" de Todd Biske. A coleção gerenciada por Thomas Erl tem agendado para este ano um livro também sobre o assunto.