Estou assumindo um projeto para substituir um antigo sistema legado desde o início. Antes de eu entrar, a empresa contratou um consultor que montou um esboço básico do sistema e pressionou fortemente a SOA. Isso resultou em uma longa lista de "serviços de entidade", com a intenção de serem compostos em combinações de serviços mais complexas. Por exemplo, um usuário que deseja informações sobre o comitê acessaria o serviço "Comitê", que chama o serviço "Pessoa" para obter seus membros e o serviço "Reunião" para obter suas reuniões, e assim por diant

Compreendo os ganhos de flexibilidade nisso, mas minhas preocupações são sobre desempenho. Parece-me que um sistema construído com um nível de granularidade tão fino para seus serviços gasta muitos recursos na tradução de mensagens de serviço e o desempenho será inaceitável. Parece-me também que os ganhos de flexibilidade ainda podem ser obtidos com objetos reutilizáveis básicos, embora nesse caso o benefício de uma interface independente de tecnologia seja perdido para obter desempenh

Para obter mais informações: atualmente, a organização que solicita esse software não possui um conjunto estável de suítes de software de terceiros que precisam ser integrados. Este software substituirá todos os conjuntos. Atualmente, também não há consumidores externos que precisem acessar os dados fora da interface do site fornecida - todas as chamadas de serviço serão de outras partes do sistema. A escolha da SOA neste caso parece inteiramente baseada no conceito de "preparação".

Então, minha pergunta - que nível de granularidade é aceitável em um estábulo de serviços sem sacrificar o desempenho? Estou sendo muito cético em relação aos resultados de desempenho que levaremos para implementar todas as nossas entidades como serviços? A funcionalidade deve estar disponível como serviço da Web somente quando necessário, com o foco de "preparação" entrando no design da camada de negócios para que a probabilidade de os serviços sejam descartados posteriormente sobre ela?