“Vamos imaginar um lindo mundo de SOA-happiness onde as necessidade de computação de uma empresa são divididas em inúmeras aplicações pequenas que prestam serviços entre si para permitir uma colaboração eficaz. Uma bela manhã um serviço consumidor precisa de uma informação do serviço fornecedor.” Martin Fowler fala sobre os problemas que qualquer unidade de negócio múltiplos de uma infra-estrutura SOA enfrenta.
Em um mundo ideal os desenvolvedores do serviço consumidor somente pedem serviço do fornecedor para desenvolver um serviço potencial e isso tudo é lindo. Mas a vida real não é ideal - o ponto problemático aqui é que os desenvolvedores do serviço fornecedor tem outras coisas para fazer, normalmente coisas que são mais importantes para o seu cliente e gerenciamento do que ajudar a equipe do serviço consumidor.
Martin aponta para um exemplo de uma solução do mundo real para o problema, empregado pelo colega Erik Dörnenburg.
Eles tiraram uma folha do livro de regras do open source e fizeram todos seus serviços em sistemas open source internos. Este permite aos desenvolvedores do serviço consumidor escreverem o serviço por si próprios.
Ele sugere que alguém poderia trabalhar no aprimoramento de serviço e submetem "Patches" que são analisados e "aplicados" por um tutor do serviço. Ele compara o papel de um tutor de serviço a um mantenedor de open-source e “embora a abordagem de tutor não elimina o problema de desenvolvedores consumidores que precisam esperar por desenvolvedores fornecedores, ele faz muita coisa para reduzir as dificuldades”. Ele sugere que é mais fácil para o tutor aplicar "patches" do que desenvolver aprimoramentos de serviço e que o processo escala muito bem já que o desenvolvedor do serviço consumidor ganha a confiança do tutor ao longo do tempo.
A responsabilidade do tutor de serviço pode ser vital para o sucesso desta abordagem. A solução que Martin sugere, pode ser erlacionada com SOA de Guerilla do Jim Webber, um esforço massivo de SOA. Tony Baer, a partir do SOA Insights podcasts, adverte dos riscos potenciais de tal abordagem.
O que acontece se o projeto crescer tanto que, para responder a um novo requisito, você cria uma novo serviço a partir do zero porque você vai fazer o trabalho de uma forma muito mais rápida? Isto é exatamento como o código espaguete (onde você tem um emaranhado de programas) é criado -- mesmo que seja mais rápido para produzir, você não quer acabar tendo que manter todo esse crud.
A reutilização de serviços precisa ser institucionalizadas e governadas pelos respectivos times funcionais ou deveriam ser um movimento popular open-source dentro da empresa e gerenciado por um Tutor de Serviço em cada um dos times funcionais? Certifique-se de consultar o post original de Martin Fowler e compartilhar suas experiencias.