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#SOAP

Já 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!

Oi Ovídio,

eu costumo implementar APIs para alguns clientes que são integradas posteriormente com algum ESB.

Minha experiência tem sido bem positiva: o mais bacana na minha opinião é que o estilo de desenvolvimento se mantém igual ao de uma aplicação normal. A única diferença é que há raras páginas (quando há) e a saída dos meus controladores é basicamnete SOAP ou JSON.

No caso do REST, a coisa é bastante simples: desde as primeiras versões o Grails nos permite criar controladores de acordo com o padrão de uma forma muito, muito simples. Como a escrita do controlador é fácil, e a renderização da resposta em formato JSON ou XML é simples, a coisa fica "mamão com açúcar".

No caso de SOAP, nem controladores eu preciso, porque posso usar algum plugin de webservices do Grails, que já expõe os serviços que escolho como web services, o que facilita bastante a minha vida.

A maior dificuldade que pode surgir diz respeito à parte de segurança que é inerente à própria natureza deste tipo de projeto. Nestes casos, infelizmente (ou felizmente) eu ainda vario de cliente para cliente por causa das necessidades de cada um, mas o Spring Security tem se mostrado uma alternativa muito poderosa para a maior parte dos casos, assim como o Apache Shiro.

Um aspecto muito bacana do Grails é que ele nos facilita bastante a tarefa de escrever testes. Para serviços REST ou SOAP, isto é uma mão na roda e fica ainda mais fácil pelo fato de termos um contrato bem definido. Conta bastante ponto também.

Interessante: tenho visto cada vez mais a popularização do Apache Camel como "ESB light". Alguns clientes (e eu) o usam para implementar rotas que integram estes serviços que implemento. Quando você combina estas duas figurinhas (Camel e Grails), a coisa fica muito, muito interessante também.

Para mim o GRAILS é muito "pesado" para a implementação de serviços, deveria ter um grails-light ou alguma coisa parecida com o play2-mini. Várias instâncias que são carregadas no bootstrap do grails são para view, que não seriam necessárias para apenas a implementação do serviço. Comecei a desenvolver um lightweight Web Server com netty.io e Groovy para a implementação de serviços REST e SOAP, mas não consigo mais tempo para dar continuidade.

@mschneider

Se o objetivo é um lightweight server para expor serviços uma boa escolha é o vert.x. Ele é como o Node.js que pode ser programado em Groovy.

InfoQ: vert.x – JVM Polyglot Alternative to Node.js

@mschneider

O "pesado" na verdade é o tempo pra subir o contexto Grails/Spring (acredito que é por isso que está entre aspas). Depois que está no ar é como se fosse um webservice feito em Java com JAX-WS.

O que deve afetar é a agilidade dos testes em tempo de desenvolvimento. Mas você pode usar a opção de gerar o wsdl dinamicamente e alterar o ws sem precisar reiniciar o contexto Grails.

O que pesa muito é deixar o wsdl dinâmico ligado em produção (já tive sérios problemas de desempenho como citou), pq no Grails é fácil ser seduzido pela "mágica" de não se preocupar com geração de stubs. Mas acontece o mesmo problema de desempenho se ligar esta opção usando um Axis2 numa aplicação Java por exemplo. O desempenho é extremamente superior gerando os contratos previamente.

Wanderson

O vert.x não tem o GORM ;)

Por isto que estava desenvolvendo um outro, para implementar serviços com groovy usando toda a produtividade que o GORM oferece.

@mscheider

Já tentou usar o GORM Standalone? http://www.grails.org/GORM+-+StandAlone+Gorm

De qualquer forma daria pra utilizar o JPA 2 com uma produtividade similar ao GORM:

Mapeamento? Basta anotar @Entity e os joins. O resto fica tudo padrão como no GORM.
Consultas? Utilizaria o fantástico QueryDSL: http://www.querydsl.com/

GORM Standalone

Overview: http://www.slideshare.net/mrfritz379/standalone-gorm
Exemplo completo: http://garralab.blogspot.com.br/2012/04/gorm-standalone.html

Em tempo, se precisar controlar transações numa camada de serviço (Service) basta anotar os métodos com @Transaction do Spring. Bem simples.

@WANDERSON SANTOS

sobre seu comentário sobre a modelagem de serviços não haver a granularidade para reduzir as requisições HTTP, o que vc acha de granular os serviços e depois e reunir o resultado de todas estas granularidades em outro serviço e remeter a resposta completa?

A Latencia seria a mesma pois o processamento de execução de um serviço maior seria apenas distribuidos em outros menores e o tráfego não seria prejudicado uma vez que somente depois que o serviço final reunisse todos os resultados dos demais serviços granulados remeteria ao usuário em um webservice.

Acha que esta metodologia seria interessante?

Oi Wanderson,

eu já tentei usar o GORM stand alone. Veredito: não vale à pena.
O trabalho que você tem pra integrá-lo no seu projeto não compensa. E como evolui muito de versão pra versão do Grails, e hoje não passa de uma camada em cima de diversas abordagens de persistência (relacional ou não), perde o sentido.

Acaba que se for pra obter este ganho e tal, é mais interessante usar o Hibernate com anotações mesmo e alguma biblioteca como as que o próprio Spring oferece pra te dar alguma ajuda na criação de consultas e tal. Spring Data mesmo já te ajuda bastante nesta hora.

Sobre o peso pra iniciar: ô Schneider, mas isto não é feito uma única vez? Não é tão problema assim, é? Com relação à ficar pesado durante o processamento, tem modos de evitar este tipo de problema também com otimizações. Não entendi o porquê do pesado.

@ivgsilva

Sim. Esta metodologia eh chamada Composicao de Servicos e o padrao SCA+BPEL auxiliam muito.

Caso nao tenha uma ferramenta, prefira fazer esta granularizacao em nivel de Service no codigo Java e integrar todos eles em outro Service antes de expor como WebService.