Escalabilidade com SOA

Você pode resumir tudo em uma frase: SOA não escala.

Escalabilidade em SOA é intimamente ligado a Cloud Computing. Com esquemas de roteamento e load-balancing, você pode fazer miséria, imagine quando isso está numa nuvem.

Pegue a AWS, por exemplo: você coloca seus componentes em instâncias EC2, configura o Auto-Scaling e o Elastic Load Balancer e voilà. Sua arquitetura orientada a serviços escalável horizontalmente.

Mas, quando o stack é Oracle, normalmente se fala em escalabilidade vertical. Aí, você adiciona mais um Managed Servers no seu WebLogic (não sem antes colocar mais uns pentes de memória na máquina) e também dá “certo”.

Se você quiser livros, o Thomas Erl tem um, na série de livros dele, sobre SOA e Cloud Computing.

[]'s

Você pode resumir tudo em uma frase: haters gonna hate.

Alexandre Saudate:

Você pode resumir tudo em uma frase: haters gonna hate.

Infelizmente sistemas baseados nas especificações WS-* não são conhecidos por escalar facilmente.

JoseIgnacio:

Alexandre Saudate:

Você pode resumir tudo em uma frase: haters gonna hate.

Infelizmente sistemas baseados nas especificações WS-* não são conhecidos por escalar facilmente.

JoseIgnacio:

Alexandre Saudate:

Você pode resumir tudo em uma frase: haters gonna hate.

Infelizmente sistemas baseados nas especificações WS-* não são conhecidos por escalar facilmente.

Amigo, meus pontos:

1. SOA não é sinônimo de WS-*;
2. Mostre os fatos. Conte a sua experiência com SOA, quais sistemas implantou, em quais segmentos de mercado, quais problemas teve;
3. O que você conhece de escalabilidade? Quais sistemas você implantou que eram amplamente escaláveis?

Acredito que não exista livro sobre tal ponto…
Faça como o Alexandre falou…
Eu por exemplos tenho comprovados que os protocolos SOAP realmente acrescentam um overhead nas chamadas quando trafegados milhares de objetos.
Vc tb pode pegar as afirmações de escalabilidade REST …
Vc pode tb poder fazer uns testes com benchmarks…etc

Olá amigos,

Vou entrar na discussão como especialista no assunto, pois SOA foi feito para escalabilidade.

O grande truque da escalabilidade é não compartilhar estados, ou seja, não distribuir lei do Dijkstra sobre computação distribuída. Quando você concorre com variáveis mutáveis por exemplo, está montando todo um mecanismo de thread safe e isso tem um custo muitíssimo alto. É o famoso, Synchronize and Suffer Model.

SOA trabalha com representações dos recursos através de objetos imutávies, logo você pode distribuir os objetos sem compartilhar estado, sem necessidade de sincronizar threads aumentando escalando verticalmente sua aplicação.

Quanto à especificação WS*, ela é oriunda do Corba e segue os mesmos princípios, Stub-Skeleton com a vatangem de ser mais simples pois não obriga um datagrama específico como o IIOP. O SOAP não é um bicho papão, todo protocolo até sistemas de ESB, se baseam em UOMs ( Universal Object Message)/Exchange e segue a mesma filosofia. O SOAP é um protocolo lógico que navega embarcado em outros protocolos. Muitos pensam somente em HTTP, mas levar um grafo de HTTP para SNA, você precisa de um mecanismo de transporte/conversão.

Existem uma série de Specs super interessantes, por exemplo - MTOM, que o Bruno Paz acabou de escrever um super artigo para tráfego de dados binários - http://arquiteturacomputacional.blogspot.com.br/2012/09/transferindo-arquivos-binarios-via-web.html , WS-Addressing para Callback de mensageria Assíncrona fora todo mecanismo de segurança etc. Existem muitos cenários que você não consegueria com Restful por exemplo, mas ambos foram feitos para escalabilidade.

Lembrando que há outras abordagens dentro do contexo SOA, como EDA - Event-Driven e nesse aspecto, há implementações como ActorsModel que pode não só escalar, mas performar a mais de 50 milhões de mensagens por segundo.

http://akka.io

Por fim, vou colocar um link de uma apresentação bem interessante do Ebay e como eles conseguiram dar vazão ao número insano de requests que recebem e como SOA os auxiliou nesse processo:

Bom, quem ainda tiver dúvidas, pode entrar em contato comigo via Twitter - @scaphe ou dar um pulo na SOA|EXPERT conhecer nosso trabalho.

Um abraço,

Felipe Oliveira

Kenobi:

…

O grande truque da escalabilidade é não compartilhar estados

…

O nome técnico é arquitetura shared-nothing (http://en.wikipedia.org/wiki/Shared_nothing_architecture), e é possivelmente a arquitetura mais escalável que existe.

Aliás, acabei de lembrar duas fontes excelentes para estudar escalabilidade. Uma é o http://highscalability.com/ . Outra é o livro Release It!, do Michael Nygard (que não é focado exclusivamente em escalabilidade, mas dá alguns cases interessantes envolvendo o assunto, por exemplo, construção de sistemas que sobrevivam à Black Friday americana). Recomendo fortemente a leitura deste livro, pois acho que ele é o melhor livro técnico que eu já lí (e olha que eu já lí Effective Java, Pragmatic Programmer e outros livros de renome).

[]'s

Alexandre Saudate:

Outra é o livro Release It!, do Michael Nygard (que não é focado exclusivamente em escalabilidade, mas dá alguns cases interessantes envolvendo o assunto, por exemplo, construção de sistemas que sobrevivam à Black Friday americana). Recomendo fortemente a leitura deste livro, pois acho que ele é o melhor livro técnico que eu já lí (e olha que eu já lí Effective Java, Pragmatic Programmer e outros livros de renome).

felipeguerra:

JoseIgnacio:

Infelizmente sistemas baseados nas especificações WS-* não são conhecidos por escalar facilmente.

Nunca li nada sobre isso, nem passei por isso na minha vida profissional…poderia indicar alguma bibliografia?

Não tenho no momento, mas não deve ser difícil entender que um protocolo binário, apesar de mais performático, terá mais dificuldade de escalar.

Essa foi a coisa mais sem nexo que eu li hoje, sem dúvida alguma.

Meu caro,

Apelo a autoridade não tem vez em ciencia. O ponto em questão é SOA não escala. ok?

Se vc não concorda, cite seu argumentos ou mostre pra nós um exemplo de sistema que escale usando protocolos binários.

Ou ele não existe e por isso não pode citar?

JoseIgnacio:

Alexandre Saudate:

Amigo, meus pontos:

1. SOA não é sinônimo de WS-*;
2. Mostre os fatos. Conte a sua experiência com SOA, quais sistemas implantou, em quais segmentos de mercado, quais problemas teve;
3. O que você conhece de escalabilidade? Quais sistemas você implantou que eram amplamente escaláveis?

Meu caro,

Apelo a autoridade não tem vez em ciencia. O ponto em questão é SOA não escala. ok?

Se vc não concorda, cite seu argumentos ou mostre pra nós um exemplo de sistema que escale usando protocolos binários.

Ou ele não existe e por isso não pode citar?

Você tanto NÃO conhece que está falando que SOAP é um protocolo binário. Muito bom, continue assim

Agora, sério… vá estudar um pouco antes de falar essas bobagens num fórum público. Não fica bem pra você #ficaadica

P.S: Me diz ONDE, no meu post anterior, está o apelo à autoridade? Se você não sabe, fica mais bonito dizer que não sabe, do que dizer que existe apelo à autoridade onde não tem.

Alexandre Saudate:

Você tanto NÃO conhece que está falando que SOAP é um protocolo binário. Muito bom, continue assim

Agora, sério… vá estudar um pouco antes de falar essas bobagens num fórum público. Não fica bem pra você #ficaadica

O fato é que é “binário” porque é ilegível para caches e outros intermediários na rede, a não ser um cliente programado especificamente para aquele serviço.

Sinceramente, a essa altura sinto que você não esta preparado para discutir sobre escalabilidade e esta apenas tentando desvirtuar a discussão, por exemplo, eu não citei SOAP (que tb não deixa de ser um protocolo binário usando XML como envelope).

E o colega que caiu de paraquedas pra apontar que XML não é só 0 e 1, sério, não brinca?

JoseIgnacio:

O fato é que é “binário” porque é ilegível para caches e outros intermediários na rede, a não ser um cliente programado especificamente para aquele serviço.

Sinceramente, a essa altura sinto que você não esta preparado para discutir sobre escalabilidade e esta apenas tentando desvirtuar a discussão, por exemplo, eu não citei SOAP (que tb não deixa de ser um protocolo binário usando XML como envelope).

E o colega que caiu de paraquedas pra apontar que XML não é só 0 e 1, sério, não brinca?

JoseIgnacio:

O fato é que é “binário” porque é ilegível para caches e outros intermediários na rede, a não ser um cliente programado especificamente para aquele serviço.

Sinceramente, a essa altura sinto que você não esta preparado para discutir sobre escalabilidade e esta apenas tentando desvirtuar a discussão, por exemplo, eu não citei SOAP (que tb não deixa de ser um protocolo binário usando XML como envelope).

E o colega que caiu de paraquedas pra apontar que XML não é só 0 e 1, sério, não brinca?

Parabéns, você foi eleito troll!!!

(Algum moderador, pode trancar isso aqui, por favor?)

Isso o que?

JoseIgnacio:

Kenobi:

SOA trabalha com representações dos recursos através de objetos imutávies, logo você pode distribuir os objetos sem compartilhar estado, sem necessidade de sincronizar threads aumentando escalando verticalmente sua aplicação.

Felipe Oliveira

Essa foi a coisa mais sem nexo que eu li hoje, sem dúvida alguma.

Não faltei em respeito contigo em momento algum, fiz uma explicação didática e citei links.

Tem mais alguns aqui sobre Immutable Objects -

Incluindo no seu modelo Java com JAXB - http://blog.bdoughan.com/2010/12/jaxb-and-immutable-objects.html

Criar uma API eficiente, tem a ver com o seu propósito e conhecimento de diversas outras técnicas.

Você poderia até questionar tecnicamente, discutir o assunto, agora agir como um babaca não ajuda nada e nem ninguém. Evolua, cresça e ganhe maturidade comportamental e técnica antes de entrar numa discussão.

E só pra comentar o outro tópico, SOAP é um protocolo lógico para navegar embarcado em outros protocolos, como SNA, IIOP etc. Você está entendendo sua rede, como se fosse 100% HTTP, falando em cacheamento, mas há diversas técnicas de Grid para fazer cache de dados idempotentes, inclusive isso é um Pattern SOA - Service Grid.

Por fim , o próprio SOAP tem extensões para Otmização e Cache - http://lists.w3.org/Archives/Public/www-ws/2001Aug/att-0000/ResponseCache.html e diversos produtos, como da IBM, Oracle etc, suportam policies específicas para tal. Lembrando que o SOAP é extensível e cada empresa pode fazer sua adição, como foi o caso da proposta da Akamai, que abriu para todos como solução possível.

PS: Por essas e outras parei de escrever no Guj.

O que difere algo escalável com algo escalável em SOA ? Então, sim. SOA escala assim como qualquer outro aplicativo bem feito

Esse é o ponto de vista de quem acredita que existe muita confusão ainda no que se trata de SOA por aí. Ligar SOA a tecnologia em primeiro plano não é uma boa ideia, assim como vender SOA como tecnologia…

Acredito que o estudo faria mais sentido se fosse “Escalabilidade com Webservices”

Abraços.

peerless:

O que difere algo escalável com algo escalável em SOA ? Então, sim. SOA escala assim como qualquer outro aplicativo bem feito

Esse é o ponto de vista de quem acredita que existe muita confusão ainda no que se trata de SOA por aí. Ligar SOA a tecnologia em primeiro plano não é uma boa ideia, assim como vender SOA como tecnologia…

Acredito que o estudo faria mais sentido se fosse “Escalabilidade com Webservices”

Abraços.

Acredito que o que difere SOA de uma aplicação qualquer (inclusive aplicações com web services) são justamente os princípios. Em SOA, a questão de fazer com que os serviços não mantenham estado entre sí é muito presente, o que proporciona uma capacidade de escalabilidade horizontal muito grande (aliás, acabei de escrever sobre isso num livro sobre o assunto =) ).

Na maioria das aplicações tradicionais, há muita manutenção de estado. Pegue uma aplicação de carrinho de compras, por exemplo. O que percebo é que a maioria das aplicações desse tipo mantém o carrinho propriamente dito na sessão, o que tem efeitos drásticos sobre a escalabilidade, já que os servidores têm que conhecer a sessão uns dos outros ou configurar “sticky sessions” (eu realmente não sei o que é pior…). Numa aplicação SOA (quer seja ela WS-* ou REST, realmente não importa aqui), as constraints da modelagem orientada a serviços pediriam que fosse criado algum serviço para fazer essa manutenção. Este serviço poderia “salvar” este estado num cluster memcached ou Redis, de maneira que a aplicação teria uma arquitetura shared-disk, que também é extremamente escalável.

Separei um link para que vocês possam entender melhor como funcionam as arquiteturas shared-nothing e shared-disk (com as quais SOA quase sempre anda de braços dados): http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/

[]'s

peerless:

O que difere algo escalável com algo escalável em SOA ? Então, sim. SOA escala assim como qualquer outro aplicativo bem feito

Esse é o ponto de vista de quem acredita que existe muita confusão ainda no que se trata de SOA por aí. Ligar SOA a tecnologia em primeiro plano não é uma boa ideia, assim como vender SOA como tecnologia…

Acredito que o estudo faria mais sentido se fosse “Escalabilidade com Webservices”

Abraços.

Concordo, SOA é um princípio e não tecnologia e comumente associado aos WebServices tradicionais erroneamente, aliás o precursor foi o Corba, assunto para outro tópico.

Quanto a escalabilidade, o Alexandre Saudate explicou muito bem, SOA tem uma série de princípios que tornam seu software escalável. Pessoal, no começo da discussão eu coloquei algumas referências bacanas da Amazon, Ebay etc. Alguém parou pra assistir ou ler ?

Putz, tinha esquecido do meu tópico e com exceção do troll master a discussão ficou muito boa.

Muito obrigado pessoal, deu uma excelente base com bastante material, inclusive com diversas referências e estudos de caso para começar a escrever o pré-projeto.

Serviu até de revisão pra algumas coisas que o Kenobi já havia mencionado em aula

Kenobi:

Tem mais alguns aqui sobre Immutable Objects -

Incluindo no seu modelo Java com JAXB - http://blog.bdoughan.com/2010/12/jaxb-and-immutable-objects.html

Criar uma API eficiente, tem a ver com o seu propósito e conhecimento de diversas outras técnicas.

Eu sei o que são objetos imutáveis. O que não havia entendido é qual relação disto com SOA.

ps: Dei uma lida nos links que você postou e tampouco vi nada relacionado com escalabilidade, muito menos SOA.

Kenobi:

E só pra comentar o outro tópico, SOAP é um protocolo lógico para navegar embarcado em outros protocolos, como SNA, IIOP etc. Você está entendendo sua rede, como se fosse 100% HTTP, falando em cacheamento, mas há diversas técnicas de Grid para fazer cache de dados idempotentes, inclusive isso é um Pattern SOA - Service Grid.

Por fim , o próprio SOAP tem extensões para Otmização e Cache - http://lists.w3.org/Archives/Public/www-ws/2001Aug/att-0000/ResponseCache.html e diversos produtos, como da IBM, Oracle etc, suportam policies específicas para tal. Lembrando que o SOAP é extensível e cada empresa pode fazer sua adição, como foi o caso da proposta da Akamai, que abriu para todos como solução possível.

PS: Por essas e outras parei de escrever no Guj.

Um protocolo baseado em extensões proprietárias sempre terá mais dificuldade de escalar. E escalabilidade é o que esta sendo discutido aqui. Não qual é o mais flexível, ou mais lucrativo para criadores de extensões.

Na minha opinião, o autor do tópico devia falar de HTTP e formatos abertos na web, já que são uma solução provada e testada que escala. Técnicas SOA não.

Eu sei o que são objetos imutáveis. O que não havia entendido é qual relação disto com SOA.

ps: Dei uma lida nos links que você postou e tampouco vi nada relacionado com escalabilidade, muito menos SOA.

Jose,

Na boa, você leu/viu os links que o Felipe enviou? Tem um exemplo na cara com referência a Amazon, uma das dicas que eles colocaram foi “Use SOA” e então eles explicam o porquê. Como você pode dizer que os exemplos não contém nada relacionado a SOA?

Está parecendo que você está apenas querendo ser teimoso e se fechar a argumentação utilizada no tópico, dessa forma realmente mesmo que o cara poste uma arquitetura SOA escalável aqui você não seria convencido.

Alexandre Saudate:

Acredito que o que difere SOA de uma aplicação qualquer (inclusive aplicações com web services) são justamente os princípios. Em SOA, a questão de fazer com que os serviços não mantenham estado entre sí é muito presente, o que proporciona uma capacidade de escalabilidade horizontal muito grande (aliás, acabei de escrever sobre isso num livro sobre o assunto =) ).

Na maioria das aplicações tradicionais, há muita manutenção de estado. Pegue uma aplicação de carrinho de compras, por exemplo. O que percebo é que a maioria das aplicações desse tipo mantém o carrinho propriamente dito na sessão, o que tem efeitos drásticos sobre a escalabilidade, já que os servidores têm que conhecer a sessão uns dos outros ou configurar “sticky sessions” (eu realmente não sei o que é pior…). Numa aplicação SOA (quer seja ela WS-* ou REST, realmente não importa aqui), as constraints da modelagem orientada a serviços pediriam que fosse criado algum serviço para fazer essa manutenção. Este serviço poderia “salvar” este estado num cluster memcached ou Redis, de maneira que a aplicação teria uma arquitetura shared-disk, que também é extremamente escalável.

Separei um link para que vocês possam entender melhor como funcionam as arquiteturas shared-nothing e shared-disk (com as quais SOA quase sempre anda de braços dados): http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/

[]'s

Sem manter estado, talvez você consiga modelar uma calculadora como serviço SOA.

Ainda assim não vai escalar, que é o assunto do tópico, porque só clientes que forem programados para aquela versão do serviço poderão fazer conta.

HugoMarques:

Eu sei o que são objetos imutáveis. O que não havia entendido é qual relação disto com SOA.

ps: Dei uma lida nos links que você postou e tampouco vi nada relacionado com escalabilidade, muito menos SOA.

Jose,

Na boa, você leu/viu os links que o Felipe enviou? Tem um exemplo na cara com referência a Amazon, uma das dicas que eles colocaram foi “Use SOA” e então eles explicam o porquê. Como você pode dizer que os exemplos não contém nada relacionado a SOA?

Está parecendo que você está apenas querendo ser teimoso e se fechar a argumentação utilizada no tópico, dessa forma realmente mesmo que o cara poste uma arquitetura SOA escalável aqui você não seria convencido.

Se existe alguma relação entre objetos imutáveis e SOA eu sinceramente não vejo, e sim, o link não fala nada de SOA infelizmente.

Poderia citar a parte onde a amazon diz que usa objetos imutáveis?

JoseIgnacio:

HugoMarques:

Eu sei o que são objetos imutáveis. O que não havia entendido é qual relação disto com SOA.

ps: Dei uma lida nos links que você postou e tampouco vi nada relacionado com escalabilidade, muito menos SOA.

Jose,

Na boa, você leu/viu os links que o Felipe enviou? Tem um exemplo na cara com referência a Amazon, uma das dicas que eles colocaram foi “Use SOA” e então eles explicam o porquê. Como você pode dizer que os exemplos não contém nada relacionado a SOA?

Está parecendo que você está apenas querendo ser teimoso e se fechar a argumentação utilizada no tópico, dessa forma realmente mesmo que o cara poste uma arquitetura SOA escalável aqui você não seria convencido.

Se existe alguma relação entre objetos imutáveis e SOA eu sinceramente não vejo, e sim, o link não fala nada de SOA infelizmente.

Poderia citar a parte onde a amazon diz que usa objetos imutáveis?

O link que o Kenobi enviou:

http://www.guj.com.br/java/283292-escalabilidade-com-soa

Facilitando a sua vida:

Amazon

Use SOA
Amazon’s architecture is loosely coupled and built around services. A service-oriented architecture (SOA) gave them the isolation that would allow building many software components rapidly and independently of each other, allowing fast time to market. The application that renders the Amazon.com Web pages is one such application server. So are the applications that serve the Web-services interface, the customer service application, and the seller interface.

Open up your system with APIs and you’ll create an ecosystem around your application. Organizing around services gives you agility - you can now do things in parallel is because the output of everything is a service. Prohibit direct database access by clients. This means you can make you service scale and be more reliable without involving your clients. This is much like Google’s ability to independently distribute improvements in their stack to the benefit of all applications.

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.

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.

Então somos dois porque tb não sei o que isso tem a ver com a discussão sobre SOA.

Se o Kenobi ainda não parou de postar por aqui, quem sabe agente ainda tem uma chance de ouvir uma explicação melhor sobre essa história, fiquei curioso…

O exemplo real é a Amazon? Se for, você teria mais referências sobre o uso de SOA na Amazon além de um resumo num blog?

Primeira regra do SOA é que os clientes vão deixar de funcionar se a descrição do serviço mudar.

Alexandre Saudate:

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.

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.

Alexandre Saudate:

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.

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.

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.

Sério que seu avatar é de um pokemón? :lol:

Sério que seu avatar é de um pokemón? :lol: Tá por dentro hein?!
Só falta falar de qual tipo… Ar? Água? SOA?

Sério que seu avatar é de um pokemón? :lol: Tá por dentro hein?!
Só falta falar de qual tipo… Ar? Água? SOA?

Manjada forte!

:lol:

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?

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?

Hebert Coelho:

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?

Tava legal o assunto aqui até que certo alguém apareceu… =/

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?

JoseIgnacio:

Alexandre Saudate:

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.

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.

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.

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

kicolobo:

Hebert Coelho:

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?

Tava legal o assunto aqui até que certo alguém apareceu… =/

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?

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

Alexandre Saudate:

kicolobo:

Hebert Coelho:

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?

Tava legal o assunto aqui até que certo alguém apareceu… =/

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?

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

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?

kicolobo:

Alexandre Saudate:

kicolobo:

Hebert Coelho:

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?

Tava legal o assunto aqui até que certo alguém apareceu… =/

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?

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

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?

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

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?

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/[telefone removido]/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 :-).

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?

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

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

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

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”.

JoseIgnacio:

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

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”.

Oi José Ignacio,

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

JoseIgnacio:

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

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”.

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

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/[telefone removido]/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 :-).

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

Oi JosIgnacio, por que não?

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.

kicolobo:

Oi JosIgnacio, por que não?

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

kicolobo:

JoseIgnacio:

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

Oi JosIgnacio, por que não?

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

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.

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

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

JoseIgnacio:

kicolobo:

Oi JosIgnacio, por que não?

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

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

Porque acha que não li?

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

JoseIgnacio:

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.

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

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

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/

JoseIgnacio:

Kenobi:

Ignore, ele não leu o que escrevi sobre escalabilidade.

Porque acha que não li?

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

Você reparou que todo post eu cito bibliografias, links e apresentações ?

Vamos fazer assim, para cada afirmação sua, traga uma referência. Será mais produtivo à discussão.

Sendo superficial, usar FMKs como o Oracle AIA, causa um overhead desnecessário?

Estou 98% convencido que sim, mas gosto do contraditório…

um abraço

felipeguerra:

Sendo superficial, usar FMKs como o Oracle AIA, causa um overhead desnecessário?

Estou 98% convencido que sim, mas gosto do contraditório…

um abraço

Arquitetura AIA da Oracle é um conjunto de padrões, CDMs comuns e patterns de integração pré-implementados. A comunicação entre os componentes internamente é feita através de RMI e chamadas JCA.

Na verdade tem uma camada extra, Anti-Corruption Layer, mas o overhead é mínimo já que é tratado tudo como binário internamente.

Alexandre Saudate:

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í.

Creio que não tem credencial para falar de REST, como ficou provado nessa thread.

REST não é baseado em um formato pré-definido. Claro, isso não impede que WADL seja criado por pessoas que, como vc, não entendem como REST funciona.

Alexandre Saudate:

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

O que isso tem a ver com escalabilidade?

.

Quem falou que Twitter é autoridade em questão de sistemas REST?

Kenobi:

Você reparou que todo post eu cito bibliografias, links e apresentações ?

Vamos fazer assim, para cada afirmação sua, traga uma referência. Será mais produtivo à discussão.

Pessoalmente, acho que seria mais produtivo para a discussão se você explicasse termos usando suas próprias palavras, ao invés de copiar e colar citações desencontradas e sem nexo algum.

Guarde links e bibliografias para seu trabalho da escola.

Como sempre, JoseIgnacio tenta discutir sobre um assunto que não possui domínio algum., toma um banho de pessoas com MUITO mais bagagem e fica se esquivando e pedindo “argumentos” sem ao menos se dar ao trabalho de argumentar ou postar fontes como as outras pessoas estão fazendo. Então JoseIgnacio a mesma pergunta que te fiz a um mês atras, você é burro assim mesmo ou você é desonesto?

Pois é. Por isso que eu acho que esse post tinha que se fechado, ou esse cara bloqueado e o posts dele excluído daqui.

O cara só atrapalha. =/

JoseIgnacio:

Ainda assim não vai escalar, que é o assunto do tópico, porque só clientes que forem programados para aquela versão do serviço poderão fazer conta.

JoseIgnacio:

Primeira regra do SOA é que os clientes vão deixar de funcionar se a descrição do serviço mudar.

JoseIgnacio:

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.

JoseIgnacio:

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”.

JoseIgnacio:

Alexandre Saudate:

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

O que isso tem a ver com escalabilidade?

Interessante, não? :shock:

JoseIgnacio:

Alexandre Saudate:

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í.

Creio que não tem credencial para falar de REST, como ficou provado nessa thread.

Ah, sim. E você mostrou como você possui, assim, muito mais credenciais pra falar sobre o assunto. Olhe que eu não preciso nem ir longe, é só ver a frase abaixo:

Ah, REST não é baseado num formato pré-definido? Quer dizer que a web não é REST, e HTML não é um formato pré-definido? Eu estou com o colega: você é burro assim mesmo ou só desonesto?

JoseIgnacio:

Alexandre Saudate:

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

O que isso tem a ver com escalabilidade?

Eu é que te pergunto. Veja:

JoseIgnacio:

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

Pessoal, passou da hora de bloquear esse tópico e/ou banir o JoseIgnacio, né? Eu tinha deixado de postar no GUJ um tempo atrás por causa desse tipo de gente, e estou prestes a me arrepender de ter voltado. Quem concorda que o GUJ precisa começar a ser mais rígido com esses trolls, levante a mão…

Pessoal, passou da hora de bloquear esse tópico e/ou banir o JoseIgnacio, né? Eu tinha deixado de postar no GUJ um tempo atrás por causa desse tipo de gente, e estou prestes a me arrepender de ter voltado. Quem concorda que o GUJ precisa começar a ser mais rígido com esses trolls, levante a mão…

o/

diegosammet:

Pessoal, passou da hora de bloquear esse tópico e/ou banir o JoseIgnacio, né? Eu tinha deixado de postar no GUJ um tempo atrás por causa desse tipo de gente, e estou prestes a me arrepender de ter voltado. Quem concorda que o GUJ precisa começar a ser mais rígido com esses trolls, levante a mão…

o/

Alexandre Saudate:

Pessoal, passou da hora de bloquear esse tópico e/ou banir o JoseIgnacio, né? Eu tinha deixado de postar no GUJ um tempo atrás por causa desse tipo de gente, e estou prestes a me arrepender de ter voltado. Quem concorda que o GUJ precisa começar a ser mais rígido com esses trolls, levante a mão…

Rodrigo Sasaki:

Interessante, não? :shock:

Desculpa, mas para fins de evitar que o tópico fuja do assunto, só respondo a duvidas sobre REST.

Hebert Coelho:

Pois é. Por isso que eu acho que esse post tinha que se fechado, ou esse cara bloqueado e o posts dele excluído daqui.

O cara só atrapalha. =/

Deve haver outro tópico mais apropriado para quem não tem experiência, já tentou o Java Básico?

Muito legal sua posição, realmente você é uma pessoa sensata e racional.

Pena que você não respondeu nenhuma dúvida no tópico até agora, seja sobre REST ou qualquer outro assunto.

.

JoseIgnacio:

Rodrigo Sasaki:

Interessante, não? :shock:

Desculpa, mas para fins de evitar que o tópico fuja do assunto, só respondo a duvidas sobre REST.

Na boa, algum moderador? Por favor?!?!

Acho que você esta sendo desonesto ou burro aqui.

Não. HTML não é um formato pré-definido.

Olá.

Atendendo a pedidos dos próprios usuários dessa thread, tópico trancado.