Escalabilidade com SOA

Programação Arquitetura
#41

[quote=JoseIgnacio][quote=Alexandre Saudate][quote=HugoMarques]
E por fim, não sei onde você viu no meu post eu falando sobre objetos imutáveis. A única coisa que falei que isso aí é um exemplo real de uso de SOA para atingir escalabilidade, que vai de encontro a sua primeira afirmativa que SOA não escala.

[/quote]

Ele não viu. Desde o começo, está desvirtuando o que a gente fala só pra trollar. Esquece esse cara, não vale a pena.[/quote]

Não é só uma questão de evitar sessão no servidor. De que adianta os servidores usarem uma arquitetura share nothing, se o protocolo usado na comunicação não permite o cliente da versão 1 acessar a versão 2 do serviço.

Pra um especialista SOA, achei que vc poderia se aprofundar mais sobre o assunto escalabilidade, pelo visto estou enganado.[/quote]

Você está certo… em partes.

Tudo depende de um projeto muitíssimo bem detalhado. Existe um padrão de projeto para isso que se chama modelo canônico. Consiste em projetar os web services a partir de XML Schemas, de maneira que eles sejam menos suscetíveis a mudanças de versão.

No caso de inclusão de campos, por exemplo, os clientes em geral não quebram. Apenas calha que clientes com uma versão 1 que se comunicam com uma versão 2 não vão enviar o campo faltante.

Também pra evitar esse tipo de problema, é possível utilizar um ESB, que pode enriquecer a informação. Por exemplo, se você tem um cliente com uma versão 1, e o servidor com a versão 2 (ou seja, campos adicionados), é possível utilizar o ESB para incluir aquele campo faltante ou buscar em outros serviços a informação.

Ou seja, dessa maneira, você tem pelo menos três técnicas que podem ser utilizadas para contornar o problema. Existem outras, ainda, mas eu considero apenas como variações dessas.

E mais… repare que a única tecnologia de que eu falei, aqui, é o ESB. De resto, nenhuma dessas técnicas é exclusiva para SOAP (ou seja, REST também pode se valer delas).

[]'s

#42

[quote=kicolobo][quote=Hebert Coelho][quote=kicolobo]Oi gente, esta discussão tá massa hein?

Sabe o que da pra fazer pra melhorar ainda mais? Ignorem quem argumenta com coisas do tipo “eu digo x e a justificativa é porque sim” ok?
Só assim, cada um expondo seus argumentos e contra argumentos é que todos vamos conseguir aprender algo com esta discussão ok?[/quote]Tava legal o assunto aqui até que certo alguém apareceu… =/[/quote]

Então bora lá: eu quero entender melhor este assunto. Alguém aqui poderia me explicar o que seria um ponto que dificultasse a obtenção de uma boa escalabilidade com SOA?[/quote]

Justamente a tal da quebra de clientes. Aliás, esse ponto é uma constante em praticamente qualquer projeto de computação distribuída, SOA ou não. Mas SOA é até melhor, nesses casos, porque você pode usar técnicas tipo XSLT para aplicar mudanças no formato dos dados - sem mexer nem no cliente nem no servidor =)

[]'s

#43

[quote=Alexandre Saudate][quote=kicolobo][quote=Hebert Coelho][quote=kicolobo]Oi gente, esta discussão tá massa hein?

Sabe o que da pra fazer pra melhorar ainda mais? Ignorem quem argumenta com coisas do tipo “eu digo x e a justificativa é porque sim” ok?
Só assim, cada um expondo seus argumentos e contra argumentos é que todos vamos conseguir aprender algo com esta discussão ok?[/quote]Tava legal o assunto aqui até que certo alguém apareceu… =/[/quote]

Então bora lá: eu quero entender melhor este assunto. Alguém aqui poderia me explicar o que seria um ponto que dificultasse a obtenção de uma boa escalabilidade com SOA?[/quote]

Justamente a tal da quebra de clientes. Aliás, esse ponto é uma constante em praticamente qualquer projeto de computação distribuída, SOA ou não. Mas SOA é até melhor, nesses casos, porque você pode usar técnicas tipo XSLT para aplicar mudanças no formato dos dados - sem mexer nem no cliente nem no servidor =)

[]'s[/quote]

Oi Alexandre, cara, sou muito ignorante neste ponto.
Como esta quebra entre clientes causa a queda de escalabilidade? No tratamento de excessões? Como se da isto?

#44

[quote=kicolobo][quote=Alexandre Saudate][quote=kicolobo][quote=Hebert Coelho][quote=kicolobo]Oi gente, esta discussão tá massa hein?

Sabe o que da pra fazer pra melhorar ainda mais? Ignorem quem argumenta com coisas do tipo “eu digo x e a justificativa é porque sim” ok?
Só assim, cada um expondo seus argumentos e contra argumentos é que todos vamos conseguir aprender algo com esta discussão ok?[/quote]Tava legal o assunto aqui até que certo alguém apareceu… =/[/quote]

Então bora lá: eu quero entender melhor este assunto. Alguém aqui poderia me explicar o que seria um ponto que dificultasse a obtenção de uma boa escalabilidade com SOA?[/quote]

Justamente a tal da quebra de clientes. Aliás, esse ponto é uma constante em praticamente qualquer projeto de computação distribuída, SOA ou não. Mas SOA é até melhor, nesses casos, porque você pode usar técnicas tipo XSLT para aplicar mudanças no formato dos dados - sem mexer nem no cliente nem no servidor =)

[]'s[/quote]

Oi Alexandre, cara, sou muito ignorante neste ponto.
Como esta quebra entre clientes causa a queda de escalabilidade? No tratamento de excessões? Como se da isto?[/quote]

Não, na quebra de clientes… por exemplo, se você constrói um cliente de web service usando JAX-WS, ele cria um stub, que é representado por uma interface que vai ter os mesmos métodos do serviço. Mas se uma dessas operações sumir do contrato, o cliente quebra por completo - nenhuma das operações funciona mais, incluindo aquelas que ainda existem no contrato. O que, no final das contas, não deixa de ser um problema de escalabilidade.

Além disso, tem o formato dos dados propriamente dito. Coisa do tipo, você inclui uma classe X e gera o cliente pra ela. Depois, você altera o formato dos dados (vamos supor que antes era String e depois passa a ser int). Mas sem problemas, você pode usar ferramentas para substituir o dado, re-formatar e coisas assim. Só não dá pra apelar - aí entra a modelagem antecipada, não tem jeito.

No mais, questões até de inclusão/exclusão de campos são facilmente contornáveis. Se o cliente manda um campo que não existe no servidor, o servidor ignora. Se o cliente não manda um campo que o servidor precisa, ele pode ser enriquecido no meio do caminho. O cliente só quebra, nesse caso, se ele deixar de mandar um campo que o servidor precisa e ninguém, no meio do caminho, tem como “adivinhar” qual deve ser o valor. Mas vamos combinar que, assim como qualquer projeto de integração, testes de integração servem pra detectar esse tipo de problema, né?

Quando tudo é bem projetado, dificilmente as aplicações têm problemas desse tipo. Eu já trabalhei em empresas que tinham catálogos de centenas de serviços, com várias áreas da empresa produzindo serviços, e ninguém tinha lá muitos problemas desse tipo. O que costumava acontecer era de algumas integrações falharem por erros de lógica, ou de execução interna dos serviços… coisas que são corriqueiras em qualquer projeto, SOA ou não.

[]'s

#45

Oi Alexandre, bom ter você no fórum cara.

Então, aproveitando o gancho, mais uma pergunta: pelo que li aqui nas suas respostas, este papo de que SOAP é lento é lenda? Em caso afirmativo, por que existe este mito?
O fato do SOAP já nos fornecer as regras de validação bem definidas não deveria aumentar a performance, visto que fica mais fácil validar?

#46

Pessoal está confundindo 3 conceitos: escabilidade, performance e interoperabilidade.

1 - Escalabilidade em software, você consegue aplicando uma arquitetura Distribuída, “particioná-lo” em peças e fazê-lo responder em máquinas separadas.

Abaixo link para um excelente livro que dá uma boa base sobre Algorítmos Distribuídos - http://www.amazon.com/Distributed-Systems-Algorithmic-Approach-Information/dp/1584885645/ref=pd_sim_b_3

Aliás definição do Tanenbaum: “coleção de computadores independentes que se apresenta ao usuário como um sistema único e consistente” - Sobre sistemas distribuídos.

Com arquitetura distribuída, você endereça a questão de crescer o processamento à medida que seu software tenha um aumento de carga considerável.

Em termos de tecnologia, há uma série de formas de realizar essa distribuição das tarefas, com protocolos binários, proprietários etc. Um exemplo clássico é o Corba que faz uso do IIOP e na tecnologia Java - EJB. Vale à pena ler um pouco mais sobre Corba - http://searchsqlserver.techtarget.com/definition/CORBA

Eu não preciso de um protocolo comum para conseguir “escalabilidade” do meu software, como HTTP. O HTTP é uma forma que exige menos máquinas, já que você poderia se fazer valer de Caches. Contudo, não são todos os dados que são passíveis de cacheamento, ou seja “idempotentes”. Há uma série de restrições para uso de cacheamento, por exemplo, quando o dado é único à cada cliente, como conta-bancária.

Então o ato de Escalar, é distribuir o seu processamento em máquinas e essas agirem com única. Com sua arquitetura orientada a serviços, você já distribuiu sua plataforma de software e consegue adicionar mais máquinas para endereçar a demanda de processamento.

2- Performance - O HTTP é um protocolo síncrono e lento, ele não tem Performance alta, então o pessoal está confundindo escalabilidade com tempo de resposta. Um sistema de mensageria como o HornetQ processa 8.2 milhões de mensagens por segundo e vai trabalhar em cima de outros protocolos como AMQP etc. Você ainda tem protocolos de baixa latência, talvez tenha que trabalhar até com Sockets e TCP diretamente.

É importante saber se você está num projeto que necessita apenas de escalabilidade, como um FaceBook ou se você está criando um Broker para uma corretora e exigirá baixa latência e performance. São problemas distintos.

3 - Interoperabilidade: Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos ou ontologias - http://pt.wikipedia.org/wiki/Interoperabilidade

Aqui um sistema Restful em cima de HTTP utilizando Semântica como RDF, talvez tenha uma melhor interoperabilidade que os WebServices clássicos. Contudo, ambas opções são estilos arquiteturais de exposição da sua API à outras plataformas, ou seja SOA :-).

#47

[quote=kicolobo]Oi Alexandre, bom ter você no fórum cara.

Então, aproveitando o gancho, mais uma pergunta: pelo que li aqui nas suas respostas, este papo de que SOAP é lento é lenda? Em caso afirmativo, por que existe este mito?
O fato do SOAP já nos fornecer as regras de validação bem definidas não deveria aumentar a performance, visto que fica mais fácil validar?[/quote]

Não é lenda não. Ele acrescenta, de fato, uma porcentagem de overhead (não me lembro de cabeça quanto é, mas acredito que seja em torno de 30%), já que tem todo aquele trabalho de um JAXB da vida ler a classe de destino, jogar o conteúdo em cada campo, etc. Mesmo com as regras de validação que vão nos schemas, os serviços aceitam, na verdade, qualquer coisa. E se nós quisermos forçar essa validação, teremos o overhead do JAXB ler o schema e validar o XML contra ele. É mais vantagem fazer uma validação de dados programática mesmo.

Em contrapartida, como eu falei antes, é muito mais flexível do que um protocolo binário, já que existem várias ferramentas para se trabalhar com XML (XPath, XQuery, editores como SoapUI, XMLSpy, etc.), de maneira que essa perda de performance pode ser compensada pela flexibilidade do protocolo. De resto, trata-se de aplicar bem os princípios da orientação a serviços: não manter estado, ter serviços tão granularizados quanto possível, fornecer mecanismos para recomposição de serviços, etc. Aplicando esses princípios, a aplicação fica escalável horizontalmente - aí, é só questão de adicionar máquinas commodity e reconfigurar o Apache/NGinx/Squid/outros.

[]'s

#48

Na verdade, o SOAP é orientado à mensagens e hoje há formas de tramitar o SOAP como binário internamente - Fast Info Set - http://fi.java.net/standardization.html

Há um utilitário bem bacana, chamado Soap Stone e faz uns benchmarks sobre o tempo de resposta em cima dos protocolos e sua implementação.

Dêem uma lida nos resultados - http://soap-stone.sourceforge.net

Deixá-lo aberto sem uso de Fast Info Set, pode ser um erro de implementação e tramitar modelos canônicos acima de 100k pode ser um tiro no pé. Vale à pena conhecer os prós e os contras de cada escolha.

Como disse, se quiser altíssima performance, trabalhe com Sockets na mão ou RMI diretamente, dependendo do seu cenário.

PS: Novamente, performance não tem a ver com escalabilidade :slight_smile:

#49

[quote=Alexandre Saudate]
Você está certo… em partes.

Tudo depende de um projeto muitíssimo bem detalhado. Existe um padrão de projeto para isso que se chama modelo canônico. Consiste em projetar os web services a partir de XML Schemas, de maneira que eles sejam menos suscetíveis a mudanças de versão.

No caso de inclusão de campos, por exemplo, os clientes em geral não quebram. Apenas calha que clientes com uma versão 1 que se comunicam com uma versão 2 não vão enviar o campo faltante.

Também pra evitar esse tipo de problema, é possível utilizar um ESB, que pode enriquecer a informação. Por exemplo, se você tem um cliente com uma versão 1, e o servidor com a versão 2 (ou seja, campos adicionados), é possível utilizar o ESB para incluir aquele campo faltante ou buscar em outros serviços a informação.

Ou seja, dessa maneira, você tem pelo menos três técnicas que podem ser utilizadas para contornar o problema. Existem outras, ainda, mas eu considero apenas como variações dessas.

E mais… repare que a única tecnologia de que eu falei, aqui, é o ESB. De resto, nenhuma dessas técnicas é exclusiva para SOAP (ou seja, REST também pode se valer delas).

[]'s[/quote]

XML Schemas não são menos suscetíveis a mudanças de versão. Eles apenas centralizam o problema.

A solução é alternativas que não dependem de um modelo canônico, porque estas escalam muito mais facilmente (como sistemas baseado na arquitetura REST por exemplo).

Como sistemas baseados na arquitetura REST não tem esse problema e escalam sem problemas, não entendi porque REST precisa “se valer delas”.

#50

[quote=JoseIgnacio][quote=Alexandre Saudate]
Você está certo… em partes.

Tudo depende de um projeto muitíssimo bem detalhado. Existe um padrão de projeto para isso que se chama modelo canônico. Consiste em projetar os web services a partir de XML Schemas, de maneira que eles sejam menos suscetíveis a mudanças de versão.

No caso de inclusão de campos, por exemplo, os clientes em geral não quebram. Apenas calha que clientes com uma versão 1 que se comunicam com uma versão 2 não vão enviar o campo faltante.

Também pra evitar esse tipo de problema, é possível utilizar um ESB, que pode enriquecer a informação. Por exemplo, se você tem um cliente com uma versão 1, e o servidor com a versão 2 (ou seja, campos adicionados), é possível utilizar o ESB para incluir aquele campo faltante ou buscar em outros serviços a informação.

Ou seja, dessa maneira, você tem pelo menos três técnicas que podem ser utilizadas para contornar o problema. Existem outras, ainda, mas eu considero apenas como variações dessas.

E mais… repare que a única tecnologia de que eu falei, aqui, é o ESB. De resto, nenhuma dessas técnicas é exclusiva para SOAP (ou seja, REST também pode se valer delas).

[]'s[/quote]

XML Schemas não são menos suscetíveis a mudanças de versão. Eles apenas centralizam o problema.

A solução é alternativas que não dependem de um modelo canônico, porque estas escalam muito mais facilmente (como sistemas baseado na arquitetura REST por exemplo).

Como sistemas baseados na arquitetura REST não tem esse problema e escalam sem problemas, não entendi porque REST precisa “se valer delas”.[/quote]

Oi José Ignacio,

como assim sistemas canônicos? De que modo eles implicariam em problemas de escalabilidade na sua opinião?

#51

[quote=JoseIgnacio][quote=Alexandre Saudate]
Você está certo… em partes.

Tudo depende de um projeto muitíssimo bem detalhado. Existe um padrão de projeto para isso que se chama modelo canônico. Consiste em projetar os web services a partir de XML Schemas, de maneira que eles sejam menos suscetíveis a mudanças de versão.

No caso de inclusão de campos, por exemplo, os clientes em geral não quebram. Apenas calha que clientes com uma versão 1 que se comunicam com uma versão 2 não vão enviar o campo faltante.

Também pra evitar esse tipo de problema, é possível utilizar um ESB, que pode enriquecer a informação. Por exemplo, se você tem um cliente com uma versão 1, e o servidor com a versão 2 (ou seja, campos adicionados), é possível utilizar o ESB para incluir aquele campo faltante ou buscar em outros serviços a informação.

Ou seja, dessa maneira, você tem pelo menos três técnicas que podem ser utilizadas para contornar o problema. Existem outras, ainda, mas eu considero apenas como variações dessas.

E mais… repare que a única tecnologia de que eu falei, aqui, é o ESB. De resto, nenhuma dessas técnicas é exclusiva para SOAP (ou seja, REST também pode se valer delas).

[]'s[/quote]

XML Schemas não são menos suscetíveis a mudanças de versão. Eles apenas centralizam o problema.

A solução é alternativas que não dependem de um modelo canônico, porque estas escalam muito mais facilmente (como sistemas baseado na arquitetura REST por exemplo).

Como sistemas baseados na arquitetura REST não tem esse problema e escalam sem problemas, não entendi porque REST precisa “se valer delas”.[/quote]

Olha só, o fato de não ter um envelope não significa que um cliente REST não precisa conversar com um servidor num formato pré-definido. Acreditar no contrário é conversinha de quem nunca implementou um projeto assim E de pseudo-evangelistas por aí.

Dito isso, também é bobagem acreditar que REST não é suscetível a falhas e não precisa de contrato algum (taí o WADL que não me deixa mentir). Afinal de contas, REST é suscetível a exatamente os mesmos problemas de formato de dados de SOAP. Só o que muda é que, em SOAP (caso o encoding utilizado seja rpc), o nome do método vai no “pacote” para o servidor, o que o torna mais suscetível a mudanças de nome de método. Quanto aos dados em sí, o problema é exatamente igual. Sem tirar nem pôr.

[]'s

#52

[quote=Kenobi]Pessoal está confundindo 3 conceitos: escabilidade, performance e interoperabilidade.

1 - Escalabilidade em software, você consegue aplicando uma arquitetura Distribuída, “particioná-lo” em peças e fazê-lo responder em máquinas separadas.

Abaixo link para um excelente livro que dá uma boa base sobre Algorítmos Distribuídos - http://www.amazon.com/Distributed-Systems-Algorithmic-Approach-Information/dp/1584885645/ref=pd_sim_b_3

Aliás definição do Tanenbaum: “coleção de computadores independentes que se apresenta ao usuário como um sistema único e consistente” - Sobre sistemas distribuídos.

Com arquitetura distribuída, você endereça a questão de crescer o processamento à medida que seu software tenha um aumento de carga considerável.

Em termos de tecnologia, há uma série de formas de realizar essa distribuição das tarefas, com protocolos binários, proprietários etc. Um exemplo clássico é o Corba que faz uso do IIOP e na tecnologia Java - EJB. Vale à pena ler um pouco mais sobre Corba - http://searchsqlserver.techtarget.com/definition/CORBA

Eu não preciso de um protocolo comum para conseguir “escalabilidade” do meu software, como HTTP. O HTTP é uma forma que exige menos máquinas, já que você poderia se fazer valer de Caches. Contudo, não são todos os dados que são passíveis de cacheamento, ou seja “indempotentes”. Há uma série de restrições para uso de cacheamento, por exemplo, quando o dado é único à cada cliente, como conta-bancária.

Então o ato de Escalar, é distribuir o seu processamento em máquinas e essas agirem com única. Com sua arquitetura orientada a serviços, você já distribuiu sua plataforma de software e consegue adicionar mais máquinas para endereçar a demanda de processamento.

2- Performance - O HTTP é um protocolo síncrono e lento, ele não tem Performance alta, então o pessoal está confundindo escalabilidade com tempo de resposta. Um sistema de mensageria como o HornetQ processa 8.2 milhões de mensagens por segundo e vai trabalhar em cima de outros protocolos como AMQP etc. Você ainda tem protocolos de baixa latência, talvez tenha que trabalhar até com Sockets e TCP diretamente.

É importante saber se você está num projeto que necessita apenas de escalabilidade, como um FaceBook ou se você está criando um Broker para uma corretora e exigirá baixa latência e performance. São problemas distintos.

3 - Interoperabilidade: Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não). Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos ou ontologias - http://pt.wikipedia.org/wiki/Interoperabilidade

Aqui um sistema Restful em cima de HTTP utilizando Semântica como RDF, talvez tenha uma melhor interoperabilidade que os WebServices clássicos. Contudo, ambas opções são estilos arquiteturais de exposição da sua API à outras plataformas, ou seja SOA :-).

[/quote]

O problema é que HTTP escala, um protocolo SOA baseado em mensagens, ou baseado em um protocolo com schema centralizado não.

#53

Oi JosIgnacio, por que não?

#54

Exatamente, o Alexandre Saudate colocou muito bem.

Mesmo numa arquitetura Rest, você está sob comunicação Client-Server, ou seja, seu cliente precisa respeitar o modelo de dados do outro lado.

Há níveis de maturidade em REST, 5 níveis e o nível de adaptação a clientes, ou seja, esse não precisar ser recompilado ainda não foi atingido. Talvez seria atingido com clientes JavaScript através de JSON, que são Schema Less, mas para todas os outros formatos como XML e tipos Java estáticos (JAXB e Jersey) , você precisaria recompilar seu client de acordo com o servidor.

#55

[quote=kicolobo]

Oi JosIgnacio, por que não?[/quote]

Porque o custo por-usuário no sistema aumenta junto com o aumento do número de usuários.

#56

[quote=kicolobo][quote=JoseIgnacio]
O problema é que HTTP escala, um protocolo SOA baseado em mensagens, ou baseado em um protocolo com schema centralizado não.
[/quote]

Oi JosIgnacio, por que não?[/quote]

Ignore, ele não leu o que escrevi sobre escalabilidade. É um “Restafarian” encara como religião.

Escalabilidade não tem a ver com interoperabilidade ou performance.

Seria muito produtivo para a discussão analisarmos tecnicamente o que cada um coloca na discussão.

Há tempos, teve uma discussão super bacana no Tectura entre mim o Guilherme Silveira e o Luca Bastos sobre SOAP vs Rest e cenários de uso

http://www.tectura.com.br/topics/rest_vs_soap_para_plataformas_baseadas_em_servicos

#57

[quote=Kenobi]Exatamente, o Alexandre Saudate colocou muito bem.

Mesmo numa arquitetura Rest, você está sob comunicação Client-Server, ou seja, seu cliente precisa respeitar o modelo de dados do outro lado.

Há níveis de maturidade em REST, 5 níveis e o nível de adaptação a clientes, ou seja, esse não precisar ser recompilado ainda não foi atingido. Talvez seria atingido com clientes JavaScript através de JSON, que são Schema Less, mas para todas os outros formatos como XML e tipos Java estáticos (JAXB e Jersey) , você precisaria recompilar seu client de acordo com o servidor. [/quote]

Uma possibilidade é que você está fazendo REST errado.

Não me lembro da última vez que isso aconteceu comigo.

#58

[quote=JoseIgnacio][quote=kicolobo]

Oi JosIgnacio, por que não?[/quote]

Porque o custo por-usuário no sistema aumenta junto com o aumento do número de usuários.[/quote]

E em Rest não existe um modelo de negócio ?

O CDM é uma prática que deve ser aplicada com muito cuidado e uma profunda análise de contextos de negócio. Você poderia argumentar erros em implementações de CDM, agora dizer que isso não escala é um erro.

Aqui vai um artigo bem bacana sobre CDM e espero que dessa vez você leia e pare de argumentar superficialmente - http://soa.dzone.com/articles/top-10-soa-pitfalls-4-incorrec

#59

Porque acha que não li?

Na boa, eu li, mas parei quando disse que HTTP é sobre distribuir processamento entre máquinas. :shock:

#60

[quote=JoseIgnacio][quote=Kenobi]Exatamente, o Alexandre Saudate colocou muito bem.

Mesmo numa arquitetura Rest, você está sob comunicação Client-Server, ou seja, seu cliente precisa respeitar o modelo de dados do outro lado.

Há níveis de maturidade em REST, 5 níveis e o nível de adaptação a clientes, ou seja, esse não precisar ser recompilado ainda não foi atingido. Talvez seria atingido com clientes JavaScript através de JSON, que são Schema Less, mas para todas os outros formatos como XML e tipos Java estáticos (JAXB e Jersey) , você precisaria recompilar seu client de acordo com o servidor. [/quote]

Uma possibilidade é que você está fazendo REST errado.

Não me lembro da última vez que isso aconteceu comigo.[/quote]

Que legal, você poderia citar os projetos que particiou ? Porque até as APIs do Twitter, trouxeram problemas aos desenvolvedores e implementaram um mecanismo de versionamento - http://blog.programmableweb.com/2010/03/22/twitter-to-introduce-versioning-to-their-api/