Segue minha contribuição considerando o assunto no outro post.
1) Em qual cenário você pretende utilizar SOA?
Uma arquitetura SOA deveria ser utilizada para integração entre sistemas de plataformas diferentes (Java x .NET x Cobol x Delphi..) ou então como suporte para uma iniciativa BPM onde analistas de negócio façam reuso à nível de negócio. Não é uma boa prática utilizar SOA com o propósito de reuso dentro da mesma plataforma (Java por exemplo), é pra isso existem as bibliotecas (JAR) e repositórios Maven.
2) Qual protocolo SOA utilizar?
- Se todas as aplicações a serem integradas estiverem rodando em Java, recomendo EJB 3 pois a comunicação é forma nativa.
- Para integração entre sites da Web ou serviços públicos, recomendo usar
REST, que nada mais é o protocolo HTTP e suas operações GET, POST e os menos conhecidos PUT e DELETE.
- Caso seja um sistema corporativo que terá vários módulos (ERPs, etc.) e integração com vários sistemas de mercado (NFe, RH, etc.), recomendo usar
SOAP com o Metro Plugin. O Metro é uma implementação do padrão JAX-WS 2.0 e tem a melhor compatibilidade entre plataformas como .NET.
3) Implementação de Serviços
Só se deve expor os métodos que serão utilizados por outro sistema. A própria camada Service pode ser utilizada como camada de exposição de serviços, através de anotações JAX-WS utilizando a lib Metro para determinar quais métodos serão expostos.
Contudo em Grails os plugins para SOAP facilitam muito ao utilizar o atributo 'exposes' de um Service. Automaticamente ele expoe todos os métodos como serviços SOAP.
http://grails.org/doc/latest/guide/webServices.html#SOAPJá para o estilo REST basta mapear o GET, POST, PUT, DELETE para os métodos de um Controller (e não para Service) e retornar XML ou JSON.
4) REST: XML ou JSON?
Toda plataforma hoje já tem uma biblioteca que lê o XML (DOM, SAX, etc.), o que não ocorre com o JSON para plataformas legadas.
Se seu serviço for exposto para integração de sistemas que você ainda não conhece, utilize XML. Caso contrário, vá de JSON pois é muito mais elegante para leitura, menos verboso (menos código para expressar a mesma coisa) e por consequência a mensagem tem tamanho menor. Faz muita diferença se você estiver consumindo um serviço que retorna acima de 100kb de dados. O JSON é muito mais rápido.
Para uma aplicação acessar um serviço JSON do lado do servidor ela precisa de uma biblioteca. Em Java temos o padrão JAX-RS, basta procurar uma implementação. Já do lado do cliente, o Javascript já recebe o JSON como um objeto diretamente. Isso pq JSON vem de Javascript Object Notation, ou seja, JSON na verdade é nada mais é que uma declaração de um objeto a ser instanciado em Javascript.
5) Modelagem de Serviços
O que eu exponho no meu serviço? Retorno todos os dados que preciso em um chamada? Faço vários métodos que retornar pequenas partes dos dados? Este é a primeira questão que surge ao modelar um serviço.
Este dilema se chama granularidade. Em SOA devemos evitar sistemas com alta granularidade, ou seja, vários serviços para realizar uma tarefa. Exemplo: um método pra retornar o cabeçalho da nota fiscal e outro método para retornar os itens. Se a nota tiver 100 itens, serão 101 chamados via HTTP! Porque isto é ruim? Não é somente pelo tráfego/latência de rede mas principalmente em converter em XML/JSON e depois carregar este XML/JSON novalmente (marshaling).
O ideal são serviços de baixa granularidade que retornam tudo o que você precisa em um determinado momento de uma vez só. Por exemplo, entregar ou receber uma nota fiscal e seus itens todos de uma vez. E se for um conjunto, entregar ou receber todas as notas com todos os itens em um só chamado.
Contudo se o sistema tiver granularidade muito baixa, isto prejudica o reuso e a composição de serviços (um serviço que usa outros para atender um objetivo). Para resolver este problema é necessário estudar os conceitos de Coesão e Acoplamento e praticar - muito!
6) Você já utilizou SOA? Existe vantagens além do reuso e integração?
Sim, várias vezes mas dentro dos princípios que foram definidos no primeiro tópico. SOA foi um "termo da moda" por muito tempo e depois caiu em descrédito devido a implementações ruins que não seguiam boas práticas. Agora está voltando pois boa parte do mercado amadureceu a idéia de onde e como utilizar, assim como aconteceu com XML.
Mas o mais importante hoje não é o SOA em si, mas sim o que você pode fazer com uma infraestrutura SOA. Hoje está mais em voga o BPM (Modelagem de Processos de Negócio) e o BAM (Business Activity Monitoring). Ambos agregam muito valor ao negócio, pois permitem Analistas de Negócio modelarem um processo completo que pode ser convertido em um sistema de forma rápida utilizando serviços que estão na infraestrutura SOA, seja diretamente (para serviços prontos) seja através da equipe de desenvolvimento (para novos serviços). E depois que o processo está automatizado, ele pode ser monitorado em tempo real através de relatórios e gráficos, como por exemplo, saber quantas OSs estão em status aberto ou concluídas em um período.
Muitas ferramentas tentaram alcançar este objetivo sem sucesso, porém a partir do BPMN 2.0 as coisas mudaram. Hoje existem boas ferramentas utilizando este novo padrão e conheço empresas que funcionam exatamente assim. Hoje é possível.
Bons códigos!