Escalabilidade com SOA

Programação Arquitetura
#21

[quote=JoseIgnacio][quote=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

[/quote]

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

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.

#22

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

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.

#23

[quote=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 :wink:

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.

[/quote]

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

#24

[quote=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 :wink:

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.

[/quote]

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 ?

#25

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 :slight_smile:

#26

[quote=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. [/quote]

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.

[quote=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. [/quote]

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.

#27

[quote]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.
[/quote]

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.

#28

[quote=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[/quote]

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.

#29

[quote=HugoMarques][quote]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.
[/quote]

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.[/quote]

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?

#30

[quote=JoseIgnacio][quote=HugoMarques][quote]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.
[/quote]

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.[/quote]

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?[/quote]

O link que o Kenobi enviou:

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

Facilitando a sua vida:

[quote]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.[/quote]

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.

#31

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.

#32

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.

#33

[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]Concordo com o Alexandre. [=

#34

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

#35

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

#36

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

#37

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

Manjada forte!

:lol:

#38

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?

#39

[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… =/

#40

[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?