[SP-pm] Resumo do Evento Técnico

[Alceu Rodrigues de Freitas Junior]

On 01-02-2015 10:57, Leonardo Ruoso wrote:

>
>     4) Como eu desacoplo os componentes? Eu preciso mesmo ter
>     baixo acoplamento? Por quê?
>
>
> Rest engloba uma proposta madura para desacoplar componentes, mas SOAP
> também dispõe de soluções viáveis para isso.
>
> Sempre que seu cliente dispuser de informações out-of-band específicas
> da aplicação ou do recurso você tem forte acoplamento.
>
> A desvantagem de forte acoplamento é que qualquer mudança em qualquer
> recurso/objeto requer uma atualização do cliente e isso é uma
> desvantagem até quando estamos falando de ThickClient com Swing, por
> exemplo. O Swing já foi feito para que fosse possível desenvolver
> ThickClient desacoplado ou menos acoplado aos serviços.
> Se falarmos de múltiplos clientes diferentes, integração entre
> aplicação, é quase imoral propormos interfaces fortemente acopladas,
> pois o custo de manutenção passa a ser algo como (O(n!)) e isso é
> insustentável economicamente.
>
>     5) E a performance? E o cache?
>
>
> Opa, performance e cache estão no amalgama das vantagens do Rest.
>

Pelo que estou acompanhando dos posts sobre este tema, meus conhecimento 
sobre Rest se encontram distantes da especificação original. :-)

Conheço um pouco de SOAP e já sofri bastante ao tentar implementar algo 
usando o "Programming Web Services with Perl" já que na época 
(2008/2009) o SOAP::Lite*** já não servia para praticamente merda 
nenhuma (não sei como está hoje) comparado a ferramentas de 
desenvolvimento para web services disponíveis para .Net e Java.

No entanto, essa história de baixo acoplamento/forte acoplamento tem 
forte relação com desempenho. Sei que o foco aqui é ambiente web, mas 
fica difícil uma interface com outro sistema ser de baixo acoplamento (e 
portanto ter uma série de abstrações) ter um desempenho melhor do que 
algo como fazer uma chamada RPC (Sun RPC, Java RMI, etc) ou mesmo 
incorporar no seu código uma biblioteca de terceiros.

A especificação do SOAP é complexa porque em teoria deveria permitir que 
sistemas fizessem integrações entre si com o menor esforço possível... 
mas alguém aí já viu UDDI funcionando?

Por outro lado eu já vi erros de integração usando SOAP que poderiam ter 
sido resolvidos em fase de projeto se simplesmente o XML Schema definido 
no WSDL tivesse incluído o tamanho máximo dos elementos (o que me faz 
pensar que a equipe de projeto estava tentando usar espoletas em uma 
Magnum 44).

Estabelecidas minhas limitações sobre o tema... como o Rest se propõe a 
lidar com essas questões? Garantir que o formato de dados trocados seja 
interpretado da forma correta, com baixo acoplamento entre os dois 
sistemas e com desempenho vantajoso?

Aliás, por desempenho vantajoso, estamos comparando o Rest com SOAP? XML 
RPC? JSON RPC?

Abraço,

Alceu

*** já que estamos falando de livro sobre o tema, a literatura 
disponível para Perl e web services está completamente defasada, não?