SOA agonizando, Servicos triunfando

Programação Arquitetura
#1

[quote]O paciente SOA, tecnicamente, não está oficialmente morto; No entento SOA está deitado sobre o chão frio sofrendo distúrbios do coração. Ao redor do paciente estão os vendedores de software e analistas fazendo massagem cardíaca freneticamente, na esperança de fazer com que o coração volte a bater.

No entanto, SOA vai morrer, independentemente de quantos tratamentos forem destinados ao paciente. SOA é terminal, ou, pelo menos, SOA como o conhecemos. Se você quiser SOA, procure um serviço como Amazon SMS ou Amazon ECS ou S3 (ou seja, SaaS) e use em sua arquitetura. Então você terá SOA.[/quote]

http://www.thecepblog.com/2009/01/11/soa-in-cardiac-arrest-long-live-services/

#2

Alo,

valeu pelo post. acho que vai gerar uma discussão boa aqui no fórum.

Só uma pergunta,

qual é a diferença entre SOA e services?
:roll:

#3

http://blog.marcomendes.com/2009/01/14/soa-morto-mais-uma-da-serie-o-festival-de-bobagens-que-assola-a-internet/

#4

O middleware.

SOA geralmente se manifesta na forma de SOAP-based webservices, WSDL e suas extensoes, que proporcionam um ambiente de neutralidade de plataforma visando a integracao de sistemas heterogeneos.

Services (SaaS) podem ser acessados por um browser convencional.

#5

[quote=cmoscoso][quote=felipe_gdr]
qual é a diferença entre SOA e services?
:roll:

[/quote]

O middleware.

SOA geralmente se manifesta na forma de SOAP-based webservices, WSDL e suas extensoes, que proporcionam um ambiente de neutralidade de plataforma visando a integracao de sistemas heterogeneos.

Services (SaaS) podem ser acessados por um browser convencional.
[/quote]

SaaS?!?!?!

outra sigla? Não aguento mais!!! hehehe

#6

[quote=cmoscoso][quote=felipe_gdr]
qual é a diferença entre SOA e services?
:roll:

[/quote]

O middleware.

SOA geralmente se manifesta na forma de SOAP-based webservices, WSDL e suas extensoes, que proporcionam um ambiente de neutralidade de plataforma visando a integracao de sistemas heterogeneos.

Services (SaaS) podem ser acessados por um browser convencional.
[/quote]

Só para deixar uma coisa bem clara à quem está lendo o tópico, o conceito de SOA é antigo e remete ao IDD - Interface Driven Design. Você pode ter SOA implementado por WSDL como você referiu mas também pode usar outras tecnologias como IDL - CORBA.

Exposição dos serviços é um conceito e muitos o preenderam errôneamente sobre WebServices o que é um grande equívoco.

Quanto à matéria, li vários artigos e posts, inclusive do Anne (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html?cid=144764146) tem thread de discussão no InfoQ, o qual quer enterrar a sigla SOA. Entretanto é consenso entre todos que os serviços estão cada dia mais presente, assim como as soluções baseadas nos mesmos - Cloud Computing por exemplo ou Software como Seviço - Saas.

Há muitas plataformas bem sucedidas, como o CRM SalesForce, AmazonServices e por aí vai.

Particularmente acredito que alguns formadores de opinião estão querendo dar um rótulo novo para o modelo, assim como aconteceu com o AJAX - Pattern que já era implementado, mas precisou de um “Guru” evidenciar isso.

Outro ponto foi o que aconteceu com o movimento por parte dos players que não entendiam direito o modelo, implicações de uma arquitetura desacoplada, como versionamento, performance entre outros problemas que poderiam enfrentar e muitos projetos foram pro espaço, com empresas armagando prejuízo ao invés de um excelente ROI como prometiam.

Fato que serviços vão estar cada dia mais presentes enquanto plataforma de software e agora o povo quer dar um novo nome, alugém tem uma sugestão ?

#7

Http Programming ? HOD (Http Oriented Design) ? HOA (Http Oriented Architecture) ?

#8

[quote=saoj]
Http Programming ?[/quote]

Sinceramente acho REST uma das inúmeras formas de resolver o problema, entretanto não podemos colocar por exemplo todas os problemas em cima do Http.Mesmo na arquitetura REST, existem muitas coisas que ele não cobre, como propagação de policies de segurança. Assim como outras tecnologias, também não é Silver Bullet.

#9

De fato isso mostra que se ignorarmos a historia estamos sujeitos a cometer os mesmos equivocos do passado. CORBA foi uma tentativa anterior de reiventar HTTP sob o pretexto de um ambiente de neutralidade de plataforma.

AWS e Salesforce.com sao aplicacoes web, a plataforma é a internet.

#10

[quote=Kenobi][quote=saoj]
Http Programming ?[/quote]

Sinceramente acho REST uma das inúmeras formas de resolver o problema, entretanto não podemos colocar por exemplo todas os problemas em cima do Http.Mesmo na arquitetura REST, existem muitas coisas que ele não cobre, como propagação de policies de segurança. Assim como outras tecnologias, também não é Silver Bullet. [/quote]

Como primeiro protocolo da internet é de esperar que o HTTP tenha um papel importante, assim como a arquitetura REST.

Sobre a propagacao de politicas de seguranca, vc estaria disposto a abrir mao da escalabilidade do sistema? Entao nao vejo problema em criar uma extensao do protocolo, existem tantas, gdata, APP, twitter! Qual seria a solucao ideal pra vc?

#11

Na verdade, na época ninguém pensava em HTTP como algo mais que um protocolo de transporte de documentos. Se você falasse em transmitir estruturas de dados em chamadas RPC-like sobre HTTP, os entendidos em sistemas distribuídos iam rir da sua cara, por motivos que vão desde o overhead à falta de mecanismos como a segurança que o Kenobi citou. Aliás, um dos motivos pelos quais web services deslancharam foi que ninguém barrava a porta 80 no firewall, porque HTTP era considerado um serviço seguro, e era muitas vezes essa brecha que os desenvolvedores usavam para conectar sistemas em redes diferentes.

Realmente, a neutralidade do CORBA era uma ilusão. Como hoje com os ESBs, a solução era “independente de fornecedor” apenas no sentido de que você podia escolher, entre uma meia dúzia de fornecedores, a qual queria ficar amarrado.

#12

"

#13

[quote=cmoscoso][quote=Kenobi][quote=saoj]
Http Programming ?[/quote]

Sinceramente acho REST uma das inúmeras formas de resolver o problema, entretanto não podemos colocar por exemplo todas os problemas em cima do Http.Mesmo na arquitetura REST, existem muitas coisas que ele não cobre, como propagação de policies de segurança. Assim como outras tecnologias, também não é Silver Bullet. [/quote]

Como primeiro protocolo da internet é de esperar que o HTTP tenha um papel importante, assim como a arquitetura REST.

Sobre a propagacao de politicas de seguranca, vc estaria disposto a abrir mao da escalabilidade do sistema? Entao nao vejo problema em criar uma extensao do protocolo, existem tantas, gdata, APP, twitter! Qual seria a solucao ideal pra vc?[/quote]

HTTP não lhe provém escabilidade, pode lhe prover interoperabilidade, facilidade mas escalabilidade etaríamos falando de outros protocolos. Quando falamos em alto volume de mensagens por exemplo, falaríamos SOAP em cima de JMS, com um design Assíncrono, completamente diferente da estrutura síncrona do Request/Response, Como faria um design para distribuir à diferentes Peers simultaneamente ?

#14

[quote]
De fato isso mostra que se ignorarmos a historia estamos sujeitos a cometer os mesmos equivocos do passado. CORBA foi uma tentativa anterior de reiventar HTTP sob o pretexto de um ambiente de neutralidade de plataforma. [/quote]

Bom, acho que precisa ler um pouco mais sobre CORBA, não foi tentativa alguma de reiventar o HTTP se fosse parar comparar seria IIOP com HTTP.

O conceito central do CORBA era Interface Driven Design e isso você não consegue ter com HTTP. Quero ver você deixar de forma explícita uma operação com estruturas de dados de entrada sem documentação para saber se ele seu “auto-resolve”.

#15

Não, você pode falar que usa um Serviço Exposto. Uma arquitetura SOA teria que trazer todo esse conceito ao Design da aplicação como um todo. Você teria todos os seus principais Módulos, ou fachadas por exemplo, expostos como serviço, seu modelo de estrtura de dados ( canonical data model) aderente ao seu negócio e por aí vai.

Vale à pena ler um pouco sobre SOA - Thomas Erl e o livro SOA Patterns do mesmo.

#16

"

#17

[quote=marcosalex]Minha fachada é toda em Web Services e a aplicação só cuida da interface. Quer dizer que é SOA?
Qual a diferença disso pra Servicos?[/quote]

Nenhuma, se você projetou para que externalize as funções do seu sistema para uma simples integração por outros, é SOA. O que me referi é que existem formas de se desenhar uma aplicação. Entra no mesmo conceito de aplicações em java, não é pq tem java no código que a aplicação vai escalar, ou seja, ser bem feita.

#18

Digamos que vc está sendo simplista Kenobi… E vc com certeza vai concordar comigo… Há muito mais em SOA do que simplesmente expor aplicações como serviço. Há muito mais em SOA que tecnologia. É processo, é negócio, é alinhamento das necessidades de negócio com o pessoal de TI. É CULTURAL, antes de ser tecnológico. E só sabe disso quem realmente trabalhou em projetos SOA que deram certo, ou que deram MUITO errado hehehe.

O Fato é que não adiante ser simplesmente algo tecnológico. Quer um exemplo? Quantas empresas aonde vc trabalhou com SOA, vc viu o conceito de governança aplicado corretamente, principalmente para Gestão???

Vai morrer? Vai trocar de nome? Não, as empresas é que tem que entender o que são as coisas antes de comprar, e treinar seus especialistas de maneira no mínimo satisfatória.

#19

[quote=Kenobi][quote=cmoscoso][quote=Kenobi][quote=saoj]
Http Programming ?[/quote]

Sinceramente acho REST uma das inúmeras formas de resolver o problema, entretanto não podemos colocar por exemplo todas os problemas em cima do Http.Mesmo na arquitetura REST, existem muitas coisas que ele não cobre, como propagação de policies de segurança. Assim como outras tecnologias, também não é Silver Bullet. [/quote]

Como primeiro protocolo da internet é de esperar que o HTTP tenha um papel importante, assim como a arquitetura REST.

Sobre a propagacao de politicas de seguranca, vc estaria disposto a abrir mao da escalabilidade do sistema? Entao nao vejo problema em criar uma extensao do protocolo, existem tantas, gdata, APP, twitter! Qual seria a solucao ideal pra vc?[/quote]

HTTP não lhe provém escabilidade, pode lhe prover interoperabilidade, facilidade mas escalabilidade etaríamos falando de outros protocolos. Quando falamos em alto volume de mensagens por exemplo, falaríamos SOAP em cima de JMS, com um design Assíncrono, completamente diferente da estrutura síncrona do Request/Response, Como faria um design para distribuir à diferentes Peers simultaneamente ? [/quote]

Um sistema de nivel global como a internet nao é escalavel? :shock:

Entao ela que deveria estar entrando em colapso nao acha…

Pra deixar claro, escalabilidade nao esta relacionado com o protoclo utilizado mas a capacidade do sistema de lidar com um grande numero de componentes e interacoes.

Em relacao a sistemas baseado em eventos, nao acho SOAP uma boa sugestao neste caso justamente porque nao oferece interoperabilidade. Eu iria de XMPP.

#20

"