HP e JBoss unem esforços pra SOA

SOA? de novo?

Ainda não enterreram isso não? faz 10 anos que SOA é o “futuro” da computação.

Desculpe a minha ignorância mas o que há de errado com SOA? No começo era a menina dos olhos e agora ouço muita gente xingar como se fosse um verme.
Se não for SOA o que pode ser?
Pq SOA não se concretiza como o “futuro” ou presente?

SOA nunca vai se concretizar como realidade de muita, muita gente. Isso não significa que não seja viável. Então acho que existem vários fatores que colaboram pra essa “decepção”: achar que todo mundo iria ver um “projeto SOA” um dia na vida, achar que SOA é uma técnica de programação, achar que instalar um determinado middleware é usar SOA, e por aí vai. Além disso, nenhum um outro tema foi tão esculhambado e criou tantos especialistas de fim-de-semana como esse nos últimos anos. Qualquer revistinha de programação saía escrevendo uma reportagem de capa sobre SOA recheada de Web Services e frases soltas. O cara que sabia usar XML, REST, JAX-WS e fez um BPEL numa madrugada então, esse já saía dando palestra. E foi nas mãos desses espertões que virou “o futuro da computação”, sendo que nem é assunto de computação. O oba-oba criou uma expectativa imensa, expectativa imensa costuma virar decepção.

Se SOA afundar, vai ser ironicamente no seu próprio sucesso.

“É mais um esforço em busca de padronização da inúmeras tecnologias Java.”

Padrão é algo tão bom que cada um quer ter o seu.

Mas o erro foi na tradução do texto pelo autor desse tópico. Padronização não é o termo correto a ser utilizado. O acordo é para INTEGRAÇÃO dos produtos das duas empresas.

SOA vagabundo!!!

modinha vai modinha vem! modinha XML, modinha SOA, modinha Ajax =P

Modinha? Bom, eu não seria tão superficial, é tudo uma questão de abordagem, SOA para arquitetura, xml para comunicação, ajax para interfaces web mais ricas. Como publicar as suas interfaces sem SOA (Troca de arquivos?)? Como fazer comunicação sem XML(texto posicional?)? Como fazer interfaces mais ricas na web sem ajax(Flex?)?

Vai da sua escolha, qual é a melhor opção?

kikostyle:

Modinha? Bom, eu não seria tão superficial, é tudo uma questão de abordagem, SOA para arquitetura, xml para comunicação, ajax para interfaces web mais ricas. Como publicar as suas interfaces sem SOA (Troca de arquivos?)? Como fazer comunicação sem XML(texto posicional?)? Como fazer interfaces mais ricas na web sem ajax(Flex?)?

Vai da sua escolha, qual é a melhor opção?

guarde essa frase: “Tudo depende do caso”.

[]s

É aquilo né…

Java esta aí e todo mundo esta usando… de repente aparece um Ruby on Rails e o pessoal acha que usar Ruby é a solução.

Então vem o Scala e tanto Ruby como Java não prestam… Quem trabalha com tecnologia tem algum desvio mental que “nos” faz achar (eu estou incluso nessa) que as tecnologias novas são melhores do que as atuais.

Por que eu iria usar SOA na minha empresa se uma aplicação PHP resolve…

Entre outros casos…

“Superficial” é ler algo sobre qualquer um desses assuntos e achar que aquilo é a salvação do mundo sem questionar qual é o seu objetivo e sua necessidade real!

Um simples servlet bem documentado em um simples servletcontainer.

A comunicação padrao é feita sobre HTTP acima de TCP/IP, XML não comunica nada, XML nesse caso serve apenas como um protocolo para serialização de objeto que apos serializado é submetido atraves de http utilizando POST.

Ajax não é interface rica e muito menos uma animação flash desenvolvida por um programador, ajax nada mais é do que uma requisição http consumida por javascript.

a melhor opção é aquela que voce realmente conhece e sabe trabalhar, não a que ecoa por ai!

E assim nunca nos melhoraremos e ficaremos na mesma merda de sempre. Pra que aprender algo novo não é? Por que você aprendeu java? se existia COBOL que era usado a tanto tempo?

Na minha opnião isso é comentario de quem não quer se atualizar.

“Superficial” é ler algo sobre qualquer um desses assuntos e achar que aquilo é a salvação do mundo sem questionar qual é o seu objetivo e sua necessidade real!

Um simples servlet bem documentado em um simples servletcontainer.

A comunicação padrao é feita sobre HTTP acima de TCP/IP, XML não comunica nada, XML nesse caso serve apenas como um protocolo para serialização de objeto que apos serializado é submetido atraves de http utilizando POST.

Ajax não é interface rica e muito menos uma animação flash desenvolvida por um programador, ajax nada mais é do que uma requisição http consumida por javascript.

a melhor opção é aquela que voce realmente conhece e sabe trabalhar, não a que ecoa por ai!

Eu sei o q cada coisa é tecnologicamente, o problema é achar que algo é simplesmente modinha, generalizar, fingir q não está inserido em um contexto muito mais complexo q involve decisões em que se define o q é adequado em cada situação. Quando se define uma tecnologia em um projeto o que MAIS importa é se a tecnologia é adequada e não se vc conhece ela, esse problema se resolve contratando gente que SABE oq vc quer implantar.

Felagund:

benflodin:

a melhor opção é aquela que voce realmente conhece e sabe trabalhar, não a que ecoa por ai!

E assim nunca nos melhoraremos e ficaremos na mesma merda de sempre. Pra que aprender algo novo não é? Por que você aprendeu java? se existia COBOL que era usado a tanto tempo?

Na minha opnião isso é comentario de quem não quer se atualizar.

Leia o que a frase representa dentro do contexto em questão! não a interprete como se fosse independente!

O pior são as críticas de pseudos entendidos do assunto, ou seja, nunca passaram por um projeto do formato e não possuem base para comparar. Também nunca leram um livro se quer do Thomas Erl entre outros especialistas do assunto e como parte da informação saem inflamando sobre o acrônimo … é demais …

“Superficial” é ler algo sobre qualquer um desses assuntos e achar que aquilo é a salvação do mundo sem questionar qual é o seu objetivo e sua necessidade real!

Um simples servlet bem documentado em um simples servletcontainer.

A comunicação padrao é feita sobre HTTP acima de TCP/IP, XML não comunica nada, XML nesse caso serve apenas como um protocolo para serialização de objeto que apos serializado é submetido atraves de http utilizando POST.

Ajax não é interface rica e muito menos uma animação flash desenvolvida por um programador, ajax nada mais é do que uma requisição http consumida por javascript.

a melhor opção é aquela que voce realmente conhece e sabe trabalhar, não a que ecoa por ai!

Eu sei o q cada coisa é tecnologicamente, o problema é achar que algo é simplesmente modinha, generalizar, fingir q não está inserido em um contexto muito mais complexo q involve decisões em que se define o q é adequado em cada situação. Quando se define uma tecnologia em um projeto o que MAIS importa é se a tecnologia é adequada e não se vc conhece ela, esse problema se resolve contratando gente que SABE oq vc quer implantar.

Ai que ta!! nenhuma das tecnologias citadas são adequadas para a maioria dos casos reais, mas se essa solução ai te conforta e se o dinheiro não é o problema do mundo então contrata a IBM para desenvolver sua solução!

por isso eu digo, é modinha e mantenho minha opnião!

Mais uma generalização, eu desisto!

Mais uma generalização, eu desisto!

ja começou morto!

Eu acredito que tudo na vida é questão de proposito. Se alguém gastou o seu tempo criando, foi por que serve para alguma coisa.

Algumas ferramentas ou paradigmas te ajudam a resolver um problema, mas isto não a torna a melhor ou siginica que ela sirva para tudo.

É a lei do custo X beneficio. Por isso é sempre bom avaliar bem a situação antes de tirar quaisquer conclusões.

"

Eu juro que não ía me dar ao trabalho de responder, mas o último post do nosso amigo kizerdrix me fez ter vontade de escrever nesse tópico novamente.

Bom vamos lá benflodin:

[color=brown]
Você disse que SOA nasceu morto, então vou contar um pouco de história. SOA é um acrônimo que faz referência à uma técnica arquitetural que visava a reutilização e integração entre diferentes plataformas. A fim de garantir interoperabilidade, todas as plataformas necessitavam coversar sob o mesmo formato e um contrato estabelecia os tipos, formatos e tudo mais. Daí surgiu o conceito Interface-Driven Design e CORBA por meio da especificação IDL foi a tecnologia que trouxe a interoperabilidade entre mundos distintos. [/color]

Pausa e voltemos a falar dos problemas do cotidiano.

Você na sua empresa, quantas aplicações possuem “partes”, rotinas, e até mesmo softwares redundantes ? Aquele acesso à base de CLIENTE sendo repetido diversas vezes , em VB, Java, C++, Delphi, COBOL e sei lá mais o que…

Cenário de alguns clientes que atendo: Bovespa com fusão da BMF hoje possui 650 sistemas. Agora imagine quantas dessas “pequenas” partes são repetidas, cada uma com um padrão de desenvolvimento, cada uma com uma versão do modelo de dado e por aí vai.

O custo de integrar as duas empresas começa a ficar imenso, mas não vou abordar isso por hora, voltemos a falar de tecnologia.

Outro cliente, Porto Seguro, possui uma equipe de aproximadamente 600 profissionais na área de desenvolvimento. Agora imagine a redução de custos se novos aplicativos surgissem à partir de algo estabelecido ?

Como pode ver SOA ou Service Oriented Architecture e é bom lembrar o nome completo, permite que serviços ou componentes integrem como ativo da empresa e esse pode ser dispobilizado entre departamentos para que à partir desse ponto, o custo de implementação caia drasticamente.

Voltando a falar de Tecnologia, CORBA era muito duro de implementar, gerar seus stubs e skeletons e tudo mais à partir de um contrato era bastante difícil. Nesse momento surgiu a tecnologia EJB, que também se baseava no mesmo princípio, entretanto a mesma era presa à uma plataforma específica.

Muitas empresas desistiram de implementar CORBA pela dificuldade e continuaram com seus sistemas EAI ( troca de arquivos) em um formato que surgira - XML, que garantia a interoperabilidade entre plataformas, o problema que não havia meios de se fazer isso sincronamente ( online) e o custo para redes privadas entre outros.

SOA veio com a idéia de Interface-Driven Design, estruturando o contrato entre os Consumer e Client por meio de uma estrutura de dados intercambiável entre plataformas.

O que veio depois disso foram passos da evolução, como um protocolo SOAP ( Simple Object Acess Protocol), que na época acredite, era mais simples que as soluções de protocolos proprietários implementados pelos vendors de EAI.

Dizer que nasceu morto é engraçado, pq se você parar pra pensar AmazonServices S3 é baseado no mesmo conceito, o que muda é a forma como os serviços são expostos e tecnologias para modelar em cima do conceito.

Por isso entra uma outra definicação do gartner - WOA - http://www.infoq.com/news/2009/06/hinchcliffe-REST-WOA, que na verdade seria uma versão de SOA, entretanto a indústria martelou muito SOA como SOAP + WSDL e todas especifcações WS* que tornam algumas implementações realmente complexas.

Voltando a olhar para cenários de negócio, em muitos casos SOA é overkill em outras WOA não atende, como segurança, cenários transacionais e por aí vai .

Acho que você cometeu um grande equívoco ao dizer que SOA está morto, pois todas as novas plataformas de computação social, cloud computing e por aí vai se baseiam em serviços.

Serviços está firme e forte e o que pode mudar são modelos de implementação dos mesmos, mas aí para falar do assunto, é necessário uma grande conhecimento sobre o tema e know-how até para poder discutir o que cabe ou o que não cabe.

Quem quiser acompanhar uma thread aqui do guj interessante sobre o assunto : http://www.guj.com.br/posts/list/30/127676.java

E outra: http://www.guj.com.br/posts/list/45/129945.java

É isso, escrevi demais e quem quiser ver um debate de alto-nível sobre o tema: http://www.infoq.com/news/2009/01/is-soa-dead

O que acontece é que aqui éa terra do jeitinho, damos um jeito para todos os problemas que aparece, aqui nego roda exploit para fazer deploy em homologação e não precisar abrir chamado. Eu me orgulho do jeitinho.

O problema com SOA é que existe muito conceito, muitas promessas ea realidade que vejo é que as empresas e seus departamentos trabalham para resolver os problemas proprios e não para resolver as necessidades dos outros, ai me questiono como seria possivel tal arquitetura ser implementada a risca tendo esse cenario?

A resposta seria, O jeitinho horas! seu diretor acabou de voltar de um evento sobre SOA, ele volta achando que vai mudar o mundo, mas não tem a minima noção de como se faz, ele apenas quer!! apartir dai todo o departamento passa a ecoar SOA SOA SOA SOA SOA SOA SOA, o resultado final é meia duzia de WS porcamente implementados e que possivelmente nem todos vao ser consumidos e coitado de quem o consumir!

Mas se WS não é SOA, então porque todo mundo sai por ai falando em SOA SOA SOA SOA?, eu sei porque! modismo!
O mesmo modismo que faz as pessoas configurarem o Log4J com xml ao inves de um .properties
O mesmo modismo que faz as pessoas falarem que Ajax são interfaces ricas!

Eu acho que não tem um fórum no mundo com tantas pessoas mal educadas como o GUJ.

E se fosse para medir o ego das pessoas aqui em espaço fisico mesmo, acho que o fórum ia conseguir ocupar a Austrália.

Entenda isso como sendo p/ você, benflodin & cia.

Caso queira discutir, favor por MP.

Kenobi, você afirma que aplicações REST é baseada no mesmo conceito de SOA, mas é importante salientar que seu ponto de vista é baseado apenas nos aspectos que você julga serem comuns com o produto que você suporta, SOA. Mesmo assim ficou muito obscuro, não entendi por exemplo o que Amazon S3 compartilha com soluções SOA que estão no mercado? Na minha opinião nada.

Você ignora aspectos que diferenciam cada arquitetura e que é mais importante para ajudar a entender o que é REST e porque ele importa. Mas você basicamente afirma que REST, SOA e CORBA é tudo igual simplesmente porque são “soluções” para o mesmo problema.

"

AUser:

Eu acho que não tem um fórum no mundo com tantas pessoas mal educadas como o GUJ.

E se fosse para medir o ego das pessoas aqui em espaço fisico mesmo, acho que o fórum ia conseguir ocupar a Austrália.

Entenda isso como sendo p/ você, benflodin & cia.

Caso queira discutir, favor por MP.

Minhas desculpas para as pessoas que se sentiram agradidas com minha opnião PROPRIA!
minha intenção nao eh causar flame muito mesmo ser tachado de troll.

Um atributo que é vital em um ser humano é a opnião!

opiniões para serem aceitas primeiramente precisam de fundamentos.

e fundamentos não se criam vivendo realidades pequenas se equiparado com o que é o todo.

CarlosEduardoDantas:

opiniões para serem aceitas primeiramente precisam de fundamentos.

e fundamentos não se criam vivendo realidades pequenas se equiparado com o que é o todo.

assunto encerrado!

mochuara:

Kenobi, você afirma que aplicações REST é baseada no mesmo conceito de SOA, mas é importante salientar que seu ponto de vista é baseado apenas nos aspectos que você julga serem comuns com o produto que você suporta, SOA. Mesmo assim ficou muito obscuro, não entendi por exemplo o que Amazon S3 compartilha com soluções SOA que estão no mercado? Na minha opinião nada.

Você ignora aspectos que diferenciam cada arquitetura e que é mais importante para ajudar a entender o que é REST e porque ele importa. Mas você basicamente afirma que REST, SOA e CORBA é tudo igual simplesmente porque são “soluções” para o mesmo problema.

Bom, vamos lá, SOA significa Service Oriented Architecture e não SOAP + HTTP ou IDL + CORBA. É um conceito de expor e gerenciar seu software como serviço. Até pq os protocolos podem sim evoluir ou modificar.

O WOA, estilo que é referido com arquitetura REST é uma derivação e a palestra do Gartner, a qual lançou o termo ao mercado, deixa isso bem claro.

Na verdade o Acrônimo SOA para o mercado traz más experiências de implementação, por tal motivo e só por esse estão adotando outra sigla. Esta acabou servindo para referenciar alguns patterns como ATOM,Hypermedia, oAuth e por aí vai …

marcosalex:

mochuara:

Kenobi, você afirma que aplicações REST é baseada no mesmo conceito de SOA, mas é importante salientar que seu ponto de vista é baseado apenas nos aspectos que você julga serem comuns com o produto que você suporta, SOA. Mesmo assim ficou muito obscuro, não entendi por exemplo o que Amazon S3 compartilha com soluções SOA que estão no mercado? Na minha opinião nada.

Você ignora aspectos que diferenciam cada arquitetura e que é mais importante para ajudar a entender o que é REST e porque ele importa. Mas você basicamente afirma que REST, SOA e CORBA é tudo igual simplesmente porque são “soluções” para o mesmo problema.

Acho que você não entendeu o que é SOA.

Poderia fazer o favor de explicar então ? Pois depois de tudo que escrevi, acredito que deixei bem claro o ponto e diferenças de estilos entre SOA-WOA e até de onde vem o acrônimo e suas motivações.

Agora se não entendi nada, explique

"

Poderia fazer o favor de explicar então ? Pois depois de tudo que escrevi, acredito que deixei bem claro o ponto e diferenças de estilos entre SOA-WOA e até de onde vem o acrônimo e suas motivações.

Agora se não entendi nada, explique

Kenobi, VOCE entendeu e explicou. Quem não tinha entendido era o mochuara que te contradisse.

Realmente li errado, valews !! Sorry pela confusçao

Kenobi, não é ouvindo o que o Gartner disse na última semana que você vai aprender o que é REST. Pelo que você explicou WOA não traz nada pra discussão, a não ser mais um acrônimo que, assim como SOA, OO, MER, PUF, PAC, não querem dizer nada…

Mochuara, só pra informe, sei bem o que é REST,aliás, uso Rails + CouchDB, Google Friend Connect, entre outras APIS do gênero e estou montando um framework em Scala utilizando o estilo. Outra o SpringMVC 3.0 falando em Java já vem preparado para tal, que também uso em projetos.

Agora quem não entendeu o começo da discussão foi vc, onde o ponto era SOA morreu !! E só mostrei que não, só estamos enxergando com outros olhos ou outro acrônimo e expliquei onde você não pode usar…

Mas cansei…dê uma linda em blogs como Anne Thomas, Eric Newcomer para começar entender o que tem haver uma coisa com a outra …

Bom, quem pretende analisar as similaridades entre SOA e REST precisa ser capaz de definir cada uma com correção.

SOA não é somente sobre expor serviços assim como REST não é somente expor uma interface HTTP. Os serviços que você menciona como exemplo (S3, CouchDB, Spring, etc.) são somente interfaces HTTP, nenhum deles é exemplo de REST porque lhes faltam o conceito de hypermedia.

Quando começar a falar de REST de verdade talvez possamos discutir o que tem nele que diferencia de SOA. Até lá pode acreditar em mim, existe muita diferença entre as duas arquiteturas.

mochuara:

Bom, quem pretende analisar as similaridades entre SOA e REST precisa ser capaz de definir cada uma com correção.

SOA não é somente sobre expor serviços assim como REST não é somente expor uma interface HTTP. Os serviços que você menciona como exemplo (S3, CouchDB, Spring, etc.) são somente interfaces HTTP, nenhum deles é exemplo de REST porque lhes faltam o conceito de hypermedia.

Quando começar a falar de REST de verdade talvez possamos discutir o que tem nele que diferencia de SOA. Até lá pode acreditar em mim, existe muita diferença entre as duas arquiteturas.

Acho que o confuso aqui é vc. Leu a Wikipedia e acha que pode definir como iteração à hypermedia, então dê um exemplo claro. Pra mim REST é utilizr os verbos HTTP. Leu novamente na Wikipedia que poderia ser sem HTTP e criou até uma mini polêmica sobre o assunto.

Cansei de conversar com pseudo entendido do assunto, pois o próprio Jim Webber em sua palestra pontuou S3 como uma arquitetura nível 2.

E falando de definição, se vc responde numa representação de dados, como JSON, XML, ATOM+XML o que seria Hypermedia pra vc ? Afinal, todos esses serviços respondem nesses formatos…

Aliás, vc podia fundamentar seu ponto de vista, não somente atacar sem demonstrar …

E aonde você leu que rEST é igual utilizar os verbos HTTP?

nivel 2 porque é sem hypermedia, ou seja é o primeiro da categoria não-REST. Porque REST APIs must be hypertext-driven
.

marcosalex:

http://www.redhat.com/about/news/prarchive/2009/hp_on_soa.html

HP e Red Hat unem esforços pra padronizar suas tecnologias de SOA, permitindo utilização integrada dos componentes. É mais um esforço em busca de padronização da inúmeras tecnologias Java.

Ahhh quantas voltas o mundo dá…