Estou envolvido em projetos que demandam diversas integrações com webservices de parceiros comerciais. Ao adotar o stack JAX-WS 2.1 do NetBeans e do Glassfish nossas aplicações facilmente se beneficiam de representações Java das operações e estruturas de dados com as quais temos que interagir. O JAX-WS também tem permitido velocidade para expor funcionalidades implementadas em Java, para aplicações internas desenvolvidas em outras plataformas.
Toda essa facilidade de integração pode nos animar a princípio, de modo a utilizarmos intensamente esses benefícios. As armadilhas residem em :
- ignorar o acoplamento com modelos de dados externos ao consumir webservices
- permitir a transitividade do modelo de dados interno ao prover webservices
O fato é que um contrato de webservice estabelecido hoje pode se tornar obsoleto em alguns meses. Naturalmente existem patterns de arquiteturas orientadas a serviço, adotados do lado do provedor dos webservices, que minimizam o impacto de tais evoluções. Uma prática interessante que tenho observado é o versionamento de serviços. Quando uma nova versão de serviço é disponibilizada a versão antiga continua operante, durante mais uma ou duas evoluções.
Entretanto, o surgimento de uma nova versão de um serviço ocorre por novas necessidades de negócio, e o consumidor do webservice se verá obrigado a migrar mais cedo ou mais tarde. Sob este ponto de vista a manutenção de versões antigas simplesmente permite adiar o impacto da evolução.
Se a aplicação consumidora estabeleceu dependência indireta com as representações Java geradas por ferramentas como o JAX-WS, esta ficará protegida do impacto de evolução dos serviços consumidos. A idéia não é novidade, e é bem discutida em uma publicação de Jens Coldewey, particularmente no tópico Subsystem-Façade (uma releitura do pattern GoF Façade).
Considerando o serviço a ser consumido e sua estrutura de dados como um subsistema, procuramos evitar a utilização direta das classes geradas pelo JAX-WS. Além de utilizar um componente Façade para converter as estruturas de dados do serviço consumido para as estruturas internas da aplicação consumidora, encontramos espaço para outra prática de integração, que eu tenho nomeada como 'Wrapper', e que devo comentar num próximo post.
O mesmo princípio de separação de subsistema é aplicado quando assumimos papel de provedor de serviços via JAX-WS. Considerando que nosso modelo de dados interno pode evoluir, este não é utilizado diretamente na interface dos serviços oferecidos. Combatemos a transitividade de nosso modelo de dados interno, seguindo o design pattern Value Object: criamos um modelo de dados customizado, que pretende permanecer estável para os consumidores dos serviços, ao longo de mudanças internas.
Considero que essas práticas podem ser adotas ao criar webservices em Java utilizando outros mecanismos como o JAX-RS para REST, ou ainda com os precursores JAX-RPC e Apache Axis.
Para expor webservices sem transitividade há também a abordagem Contact-First, utilizada pelo Spring Web Services. Tal abordagem também pode ser utilizada em JAX-WS. Neste caso sempre definimos o schema de dados e operações expostas em primeiro lugar, colocando a geração dos artefatos Java como uma atividade secundária.
A versão original desta discussão pode ser lida em meu blog.
Toda essa facilidade de integração pode nos animar a princípio, de modo a utilizarmos intensamente esses benefícios. As armadilhas residem em :
- ignorar o acoplamento com modelos de dados externos ao consumir webservices
- permitir a transitividade do modelo de dados interno ao prover webservices
O fato é que um contrato de webservice estabelecido hoje pode se tornar obsoleto em alguns meses. Naturalmente existem patterns de arquiteturas orientadas a serviço, adotados do lado do provedor dos webservices, que minimizam o impacto de tais evoluções. Uma prática interessante que tenho observado é o versionamento de serviços. Quando uma nova versão de serviço é disponibilizada a versão antiga continua operante, durante mais uma ou duas evoluções.
Entretanto, o surgimento de uma nova versão de um serviço ocorre por novas necessidades de negócio, e o consumidor do webservice se verá obrigado a migrar mais cedo ou mais tarde. Sob este ponto de vista a manutenção de versões antigas simplesmente permite adiar o impacto da evolução.
Se a aplicação consumidora estabeleceu dependência indireta com as representações Java geradas por ferramentas como o JAX-WS, esta ficará protegida do impacto de evolução dos serviços consumidos. A idéia não é novidade, e é bem discutida em uma publicação de Jens Coldewey, particularmente no tópico Subsystem-Façade (uma releitura do pattern GoF Façade).
Considerando o serviço a ser consumido e sua estrutura de dados como um subsistema, procuramos evitar a utilização direta das classes geradas pelo JAX-WS. Além de utilizar um componente Façade para converter as estruturas de dados do serviço consumido para as estruturas internas da aplicação consumidora, encontramos espaço para outra prática de integração, que eu tenho nomeada como 'Wrapper', e que devo comentar num próximo post.
O mesmo princípio de separação de subsistema é aplicado quando assumimos papel de provedor de serviços via JAX-WS. Considerando que nosso modelo de dados interno pode evoluir, este não é utilizado diretamente na interface dos serviços oferecidos. Combatemos a transitividade de nosso modelo de dados interno, seguindo o design pattern Value Object: criamos um modelo de dados customizado, que pretende permanecer estável para os consumidores dos serviços, ao longo de mudanças internas.
Considero que essas práticas podem ser adotas ao criar webservices em Java utilizando outros mecanismos como o JAX-RS para REST, ou ainda com os precursores JAX-RPC e Apache Axis.
Para expor webservices sem transitividade há também a abordagem Contact-First, utilizada pelo Spring Web Services. Tal abordagem também pode ser utilizada em JAX-WS. Neste caso sempre definimos o schema de dados e operações expostas em primeiro lugar, colocando a geração dos artefatos Java como uma atividade secundária.
A versão original desta discussão pode ser lida em meu blog.
Comentários