-
Questão "certa", jeito CESPE.
Segundo Thomas Erl - SOA - Princípios do Design:
"Ativar serviços com um nível significativo da interoperabilidade natural dentro de um limite de um inventário de serviços. Isso reduz a necessidade de transformação de dados , porque os modelos de dados consistentes são utilizados para troca de informações."
-
Galera, essa questão afirma que quando eu ofereço serviços por meio de Web Services e seus contratos (i.e., suas interfaces), eu tenho um grande potencial de evitar a transformação. Isso é verdade! Nós sabemos que mudar a implementação do serviço é irrelevante desde que se mantenha sua interface. No entanto, eventualmente eu posso precisar alterar a interface de um serviço – e, nesse caso, não dá para evitar a transformação do contrato do serviço. Logo, o contrato não é imutável, ele realmente muda raramente, mas ele não é imune a mudanças e não evita completamente transformações. No entanto, a questão afirma que o uso de contratos tem o “potencial” de evitar completamente a transformação. Ter o potencial significa ter a capacidade de realização ou execução de algo. E isso é verdadeiro nesse contexto.
-
eu errei... interpretei essa transformação como parser de objetos
-
Afirmativa correta, vamos ver o que Thomas Erl tem a falar sobre isso no capítulo de "Contrato de Serviços"
"6.4 Padronizando a representação de dados e evitando a transformação"
" [...]
Uma vez implementados e fazendo parte do ambiente de produção, os contratos de Web Service não padronizados resultam na criação e implementação de diferentes modelos de dados que representam os mesmos corpos de dados. Superar essas diferenças requer o uso de tecnologia de transformação de dados e a definição de fazer o mapa da lógica entre um esquema e o outro. Esse mapa é implementado em um componente de software real, como uma folha de estilo XSLT, que, posteriormente, executa a lógica de transformação em runtime toda vez em que o serviços precisam trocar informações.
As tecnologias de trasformação de dados fornecem recursos importantes, essenciais para habilitar conectividade em arquiteturas corporativas intergradas. Mas, ao padronizar o design de serviços como parte de um inventário de serviços bem-definido, um de nossos principais objetivos é evitar a transformação de dados onde for possível.
A tranformação de dados introduz vários problemas, incluindo:
[...]
"
Portanto questão CORRETA!
-
Reduzir/evitar é diferente de "evitar completamente". Mas a questão vai e coloca na frente "tem o potencial de". rsrs.
-
Segundo esta fonte[1], "Within service-orientation, the design of the service contract is of paramount importance—so much so, that the Standardized Service Contract design principle and the aforementioned service-oriented design process are dedicated solely to the standardized creation of service contracts.
Perceba q o princípio de desenho de Contrato de Serviço, bem como o processo de desenho orientado a serviço é que criam a padronização.
Quando a questao deixa a "deixa" potencial, permite ou não essa possibilidade. É só ela estar no contrato.
Fonte:
[1] SOA eBook Patterns, Mashups, Governance, Service Modeling, and More, A.W.