Não há como escapar... o processo de implementação de um serviço (também chamado de "Service Enablement") é um evento intrusivo no ecossistema das aplicações existentes de uma companhia. O nível de intrusão pode ser baixo ou alto mais dificilmente deixará de ocorrer.

É claro que os Serviços de Integração tipicamente terão nível de intrusão mais alto por se tratarem de serviços de baixo nível de abstração e com responsabilidades de resolução de problemas técnicos consideráveis.

Um exemplo parece que ajuda neste caso: autenticação de usuários. Independentemente de quais sejam os propósitos e objetivos do projeto SOA, todo consumidor dos serviços expostos (usuário final, Serviços de Negócio, BPM, aplicações externas à companhia, etc) deverá ser autenticado. A autenticação de usuários é, então, um serviço corporativo e, por conta disso, um excelente exemplo para estar na Camada de Serviços. Não se trata de um Serviço de Negócio, e sim, digamos, de um Serviço Utilitário, que será usado por aqueles mais cedo ou mais tarde.

Agora, se pensarmos um pouco na implementação de tal serviço, vamos observar que se trata de uma questão complexa e bastante intrusiva nos sistemas legados. Vejamos: a questão de autenticação de usuários é quase que universalmente implementada de forma repetida por cada aplicação. Ou seja, cada aplicação, quando foi desenvolvida implementou do seu modo esta funcionalidade, armazenando usuários em seus bancos de dados, implementando a sua própria interface com o usuário, etc. Em alguns casos, há o uso de tecnologias como servidores de diretório (LDAP, MS ActiveDirectory, etc) para o repositório de dados de usuários mas a lógica da autenticação ainda está presente na própria aplicação.

O desejável é que um Serviço de Autenticação de Usuários fosse utilizado horizontalmente por todas as aplicações. Ou, pensando ao contrário: as aplicações e os Serviços de Negócio deveriam delegar a autenticação de usuários a um Serviço Utilitário específico. Em outras palavras: é preciso que isolemos a funcionalidade de autenticação de usuários em um serviço para que possa ser reusada por quaisquer consumidores.

Em última análise, as aplicações e sistemas não deveriam possuir em seus domínios funcionais a capacidade de autenticação de usuário, posto que tal questão estaria consolidada em um serviço externo. Só que esta fatoração funcional não é barata. Não que não seja factível de ser implementada. Ela é. A questão é outra: o que fazemos com as aplicações já existentes e que possuem esta lógica fortemente acoplada às suas outras funções? Este é um exemplo de intrusão que um "Service Enablement" tem que considerar. Eventualmente a fatoração tem custo alto e talvez não seja possível (por exemplo, em pacotes de mercado onde não temos o controle do código). Técnicas de mapeamento de identidades talvez devam ser usadas, por exemplo.

Outro ponto importante: em implementação usando Web Services e WS-Security, um dos modelos mais usados para o mecanismo de autenticação é aquele baseado em "tokens SAML" ("Security Assertions Markup Language"). Uma mensagem SOAP deve incorporar tais "tokens" pois para, atingir o destinatário, atravessará vários nós intermediários. Mais um motivo para termos Serviços específicos para autenticação e, neste caso, validação e consumo de "tokens".

A conclusão é que a importância da análise de "gap" aumenta de forma considerável quando analisamos o eventual nível de intrusão de um serviço. Por conta disso, recomenda-se mais uma vez um processo formal para a elaboração e controle do ciclo de vida de um serviço.





More...