Em um posto anterior eu comentei que a Camada de Serviços, não somente pelo seu nome, era a mais importante e essencial para um projeto SOA. Isso se deve a dois principais fatores:

a) A definição dos serviços desta camada.


b) O "gap" tecnológico (funcional e não funcional) entre ela e a Camada de Recurso e Dados.

Enquanto a definição dos serviços necessita da participação intensa de analistas de negócio, a análise de "gap" normalmente é conduzida pelos arquitetos de tecnologia. Alguma coisa como: em um primeiro momento, os analistas de negócio são os principais responsáveis pelo recolhimento dos requerimentos de um serviços. Posteriormente, tais requerimentos são conduzidos pela equipe de tecnologia para a respectiva implementação. Neste ponto, uma das questões mais críticas é o "gap analysis" entre "o que se quer" (serviços) e "o que se tem" (legado).

A análise de "gap" deve ser considerado como ponto crucial na específicação e consequente implementação de um serviço. Infelizmente, é bastante comum verificar que tal análise não recebe a atenção e recursos necessários por parte da equipe de tecnologia que faz parte de um projeto SOA. Simplificações do assunto levam invarialmente a problemas críticos que necessariamente deverão ser corrigidos no futuro.


Poderiamos relatar algumas questões e problemas que nascem a partir de uma análise não completa do "gap":

  • É comum ouvirmos que SOA adota muito mais a postura de "wrap and reuse" do que "rip and replace". Isto é, SOA deve tomar vantagens de capacidades já existentes da camada de sistemas legado em vez de reescreve-las. Contudo, é preciso não confundir um serviço como uma "webficação" de um legado. O fato de inserirmos uma "casca" Web Services em uma transação CICS, por exemplo, pode ser necessária mas absolutamente não será suficiente. Nunca é demais lembrar que um servíço deve ser responsável, além de questões funcionais, por requerimentos não funcionais. Diria que atender os requerimentos funcionais é muito mais simples que do implementar os não funcionais.
  • A "webficação" tipicamente cria uma relação 1:1 com um aspecto funcional de um legado. O exemplo acima serve para isso. Tal relação é muito improvável: é bastante razoável imaginar que serviços dependerão de mais do que um legado para cumprir o seu papel funcional. A relação então seria 1:N. A definição de escopo funcional para cada legado não possui uma resposta simples. Eventualmente, encontramos duplicidade funcional dentre os sistemas do legado.
  • Como se não fosse suficiente, dentre os requerimentos de um serviços encontraríamos por exemplo, disponibilidade 24x7, escalabilidade, etc. Igualmente fácil de imaginar que há sistemas do legado que não estão em condição de atender esses requerimentos. É insuficiente termos uma camada de ESBs suprindo tais demandas se um legado não acompanhá-la. A solução não é trivial: deveriamos evoluir o legado ou reescreve-lo? Qual o custo de cada decisão? Não há uma resposta única para todas essas perguntas.
  • Em uma relação 1:N entre um serviço e os sistemas legado, é possível que tenhamos uma aplicação que atendam os requerimentos não funcionais e outras que não. Mais uma vez a resposta não é direta.
Por outro lado, processos de "webficação" de legado com relacionamento 1:1, pode ser (e normalmente é), o primeiro passo da implementação da camada de serviços em uma aproximação "bottom-up". Em outras palavras, a "webficação" de um aspecto funcional de um legado, acarreta na implementação do nível mais baixo de abstração da Camada de Serviços. Outros serviços (Integração, Negócio, etc) certamente, tirarão proveito da "webficação".

Outra questões importantes:

  • Um projeto SOA deve implementar níveis de abstrações novos sobre a camada do legado. Apesar de tentar enfatizar o "wrap and reuse", é a melhor ocasião para descartar sistemas obsoletos que, historicamente, não atendem os requerimentos de seus usuários finais.
  • Contudo, um projeto SOA não pode ter como principal responsabilidade a "modernização" do legado. Melhor seria se a modernização fosse considerada um "projeto derivado" ou um "subprojeto" dentro de um espectro maior. Em outras palavras, um projeto SOA não deve ser encarado primordialmente como a correção de problemas crônicos de aplicações já existentes.
Como conclusão direta: um processo formal para conduzir o ciclo de vida de um serviço se faz necessário.







More...